Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Malware Hidden Inside JPG EXIF Headers

blog.sucuri.net

Post reply on HN
Print view View original

21–30 of 65 posts

Re: Malware Hidden Inside JPG EXIF Headers

#21

Post by pjungwir »

savories wrote: post #11

Important to note the jpg is just one part of the malware. It is harmless by itself. It still requires some other file to actually execute it. The jpg just contains further instructions for the backdoor. The jpg is really just an obfuscator.

Exactly. The attacker-added PHP code to run preg_replace is still there. But it does look quite innocuous! This really points to why when compromised you need to wipe the box and start over from scratch, not assume you can find all the backdoors by auditing the filesystem.

Re: Malware Hidden Inside JPG EXIF Headers

#22

Post by devicenull »

devrelm wrote: post #20
morpher wrote: post #14

If I'm reading this correctly, someone compromised a site (by other means) and then added the exif_read_data() and preg_replace() lines to the code somewhere as a back door? If a site was compromised, wouldn't any modified files be replaced with canonical source? Or do people manually scan through files looking for code that looks suspicious? Or am I misunderstanding and this site for some reason legitimately called…

The code in question seems to be removing any occurrences of the Make from the Model. This might be useful if you have a camera that sets the Model to contain the Make name, like setting Make="Nikon" and Model="Nikon D5000". If we want to know the actual model number, then we have to remove the Make from the Model, giving us " D5000". Using preg_replace() might just as good as anything to do this.

No, the signature for preg_replace is ( $pattern , $replacement , $subject) . So, given the call as preg_replace($exif['Make'],$exif['Model'],'') it would replace any occurances of Make with Model within the empty string ''. This is essentially a noop unless your exif data contains exploit code.

Re: Malware Hidden Inside JPG EXIF Headers

#23

Post by devicenull »

kghose wrote: post #10

So the real hole is in `preg_replace` which can execute arbitrary strings on the server if the /e flag is found? Why does this exist? Any how, this seems to be a genius exploit! If a site lets users upload photos and they use this function, a user could do this. Basically a good frame work should have 'safe' functions that are designed to accept 'user input' i.e arbitrary strings and never set up a situation where th…

Uh what? If a site lets users upload photos and puts their uploaded content into a preg function without validation, they are indeed vulnerable. However, just loading the exif data is not enough to trigger this.

Putting untrusted input into a regular expression pattern is something you shouldn't do in the first place (even without the /e modifier)

Re: Malware Hidden Inside JPG EXIF Headers

#24

Post by deadreturns2 »

chrsstrm wrote: post #8
amitparikh wrote: post #6

From PHP documentation ( http://php.net/manual/en/function.preg-replace.php ) 5.5.0 The /e modifier is deprecated. Use preg_replace_callback() instead.

True, but most value hosting platforms run anything between 5.2.x and 5.4.x. with no option to upgrade.

Read: deprecated. Stop acting like it's removed in 5.5.

Re: Malware Hidden Inside JPG EXIF Headers

#25

Post by infinity »

vog wrote: post #18

Although this obfuscation is very clever, I think the article overstates a bit. The author claims that the following two commands "harmless by themselves": $exif = exif_read_data('/homepages/clientsitepath/images/stories/food/bun.jpg'); preg_replace($exif['Make'],$exif['Model'],''); I don't agree with that. While the first command is indeed harmless, the second one is executing a REGEX machine with a dynamic regex pa…

I think that the main point or cleverness is to avoid an explicit eval ( base64decode ( blahblah ...) ) in the PHP source code, which might be detected. A preg_replace call is also easy to spot, but may occur naturally in the source.

Constructs using a sequence of eval with base64decode and often gzip compression are very common for obfuscating malicious PHP code. I would expect that people are much more likely to look for these in the source code to find out if a website has been compromized rather than looking at EXIF data. So I think, yes, this is something different.

In the article they call this a steganographic malware. But actually the information is not embedded in the picture content, but in the meta or EXIF data. It would be an application of steganography, if the malicious code would be extracted from information that is part of the actual picture and it is not obvious that this information is present in the first place. For example, there could be the drawing of a house in the picture with a cow and a horse and the grass blades in front of it represent 1s and 0s. Then some clever program executes the grass blades code.

It seems that the authors were among the first to detect this kind of attack using the EXIF data in the wild. And of course the want to advertise that their product detects this kind of compromize.

Re: Malware Hidden Inside JPG EXIF Headers

#26

Post by infinity »

amitparikh wrote: post #6

From PHP documentation ( http://php.net/manual/en/function.preg-replace.php ) 5.5.0 The /e modifier is deprecated. Use preg_replace_callback() instead.

From the perspective of an attacker it doesn't really matter if the malicious code contains deprecated things or lacks elegance or is generally ugly.

Re: Malware Hidden Inside JPG EXIF Headers

#29

Post by Arnor »

infinity wrote: post #26
amitparikh wrote: post #6

From PHP documentation ( http://php.net/manual/en/function.preg-replace.php ) 5.5.0 The /e modifier is deprecated. Use preg_replace_callback() instead.

From the perspective of an attacker it doesn't really matter if the malicious code contains deprecated things or lacks elegance or is generally ugly.

You can configure your server to log usage of deprecated features in PHP so that the attack would ultimately appear in the log. Admittedly, it would still take a pretty vigilant Sys Admin to catch it.
Post reply on HN