9 ms·

Malware Hidden Inside JPG EXIF Headers

221 points by cubictwo 13y ago

bbsec 13y ago
Great discovery!
3327 13y ago
As malicious as this may be it is pure genius. It should include a message as such: Elk Cloner: The program with a personality It will get on all your disks It will infiltrate your chips Yes, it's Cloner! It will stick to you like glue It will modify RAM too Send in the Cloner!
trebor 13y ago
Wow, this would bypass the execution constraints we put on the upload directories. Usually I make an uploads folder rw-rw-rw (0666); it would take another attack in conjunction with it, but that's really something.
- morpher 13y ago
  Only if someone modifies an executable file to call preg_replace with exif headers.
jeltz 13y ago
Seems like itt was possible to hide it so well due to an oversight in the API for preg_replace. In-band signaling in general makes it easy for people to accidentally add security holes. What they should have done is pass the regex options as a separate parameter, then it would have been obvious that something fishy was going on here.
amitparikh 13y ago
From PHP documentation (http://php.net/manual/en/function.preg-replace.php http://php.net/manual/en/function.preg-replace.php) 5.5.0 The /e modifier is deprecated. Use preg_replace_callback() instead.
- chrsstrm 13y ago
  True, but most value hosting platforms run anything between 5.2.x and 5.4.x. with no option to upgrade.
  - deadreturns2 13y ago
    Read: deprecated. Stop acting like it's removed in 5.5.
- ajross 13y ago
  Indeed. Yet it appears we are afflicted with lazy malware authors who continue to use deprecated APIs instead of updating their exploits. To be serious: According to the article, the call to preg_replace() was part of the backdoor added by the attackers, it wasn't a pre-existing hole in the site code.
- infinity 13y ago
  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.
  - Arnor 13y ago
    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.
lcedp 13y ago
Eval in replace funtion.. But why?!
- Afforess 13y ago
  Because PHP.
  - devgutt 13y ago
    http://docs.python.org/2/library/functions.html#eval http://docs.python.org/2/library/functions.html#eval
    - echohack 13y ago
      https://github.com/thijsdezoete/noevil https://github.com/thijsdezoete/noevil
    - deadreturns2 13y ago
      He's talking about the preg_replace /e modifier not eval, the function.
    - valleyer 13y ago
      note: “... in replace function”
    - pjscott 13y ago
      Yes, Python has eval, but it doesn't hide in the bushes and ambush you. The same can not be said for preg_replace and the /e option.
    - Dylan16807 13y ago
      Just curious, how many points does your comment have right now even though it's completely wrong? I'm not insulting you for making a tiny mistake, I'm wondering why a 7 hour old post with multiple 6 hour old corrections attached to it still has a positive score.
      - 13y ago
kghose 13y ago
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 these strings are executed
- deleted 13y ago
  [deleted]
- deleted 13y ago
  [deleted]
- devicenull 13y ago
  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)
- A1kmm 13y ago
  It isn't an exploit, but rather a code obfuscation technique. The attacker compromised the site first (the exploit used isn't disclosed in the article), and then tried to conceal the malware they installed on the compromised system by putting most of the malware in an EXIF header. The malware code used a hardcoded image path, so for someone else to replace the code to be executed, they would need to have access replace the particular image file that contains the malware. One interesting aspect is that the malware images are public, and probably already referenced to from the site (since the attacker used an existing image), so it might be possible to write a spider (or something based on Common Crawl perhaps) that finds many compromised sites.
savories 13y ago
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.
- pjungwir 13y ago
  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.
morpher 13y ago
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 preg_replace() with exif make/model parameters (which seems pretty unlikely to do anything useful)?
- devrelm 13y ago
  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.
  - devicenull 13y ago
    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.
    - devrelm 13y ago
      In that case I agree that it would never be used as it was written, and suggest that the author must have jumbled the parameters. Calling the method as preg_replace($exif['Make'], '', $exif['Model']) would correct the behavior to something useful, while keeping the vulnerability in place.
- bigiain 13y ago
  I suspect it's a way of hiding backdoors in "free" themes/plugins. It's a technique that's not the usual obvious eval(base64decode("0xabad1dea")) that people might scan for (either by eye or with automated tools). That means this exploit might well be _in_ the "canonical source" - where the user doesn't suspect the "Super awesome social shopping comparison plugin" they downloaded is likely to be trojaned. (I wonder if anyone's running a scan over the WordPress.org plugins/themes librarys looking for unexplainable exif_read_data() and preg_replace() calls?)
vog 13y ago
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 param. This is almost like having a user-defined format string to printf(), and thus very suspicious and should be found by any decent security analysis tool. Even without the "/e" feature of preg_replace, this could result at least in a denial of service attack via some specially crafted regex parameters. So I agree that this is clever, but I don't agree that this call to preg_replace() should normally be considered harmless by itself. So the question remains why the authors overstate the cleverness of this attack, and I think they give the answer in the last sentence of the article: "Note: Any of Sucuri clients using Server Side Scanning are protected against this type of injection (detected by us)."
- infinity 13y ago
  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.
chrisweekly 13y ago
Interesting... but clueful site owners already strip all EXIF headers anyway, for performance reasons. Options for doing this abound (e.g. mod_pagespeed, grunt imagemin, http://smush.it http://smush.it, etc).
- diminoten 13y ago
  Ingress wasn't through EXIF headers, obfuscation is the goal. If this post effects your environment, you've already been compromised, and the hackers are merely attempting to avoid detection by hiding in the EXIF headers. This file wasn't uploaded through any legitimate means, it was replaced with malicious intent.
- philrt 13y ago
  How about tricking the server into generating the payload like this? https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/ https://www.idontplaydarts.com/2012/06/encoding-web-shells-i...
ebarock 13y ago
nice post!
smegel 13y ago
Surely any file format with metadata can contain malware if there is a bug in the program reading it...
ibudiallo 13y ago
This is not a bug in php that is being exploited. The server has already been compromised. The code look harmless enough for most people to ignore it, this is the point here. It's a clever obfuscation
martin_ 13y ago
This isn't new, and it certainly isn't specific to JPGs. It's quite frequent for people to embed malicious code into files masquerading as images. There has also been instances where hacked WordPress instances[1] hide code inside images so they aren't so obviously found ready for execution at a later date The most common way to exploit this however is by uploading an image with a valid magic number (e.g. GIF89a) which will any mime type checks and then finding a way to rename that file to one with an executable extension, or finding a way to include it through an LFI vuln. A simple solution is to simply load the image up in ImageMagick (or GraphicsMagick, GD) and re-write the image to disk. Disclaimer: Former lead developer of an image hosting service [1] https://media.blackhat.com/bh-eu-12/Be'ery/bh-eu-12-Be'ery-FYI_you_got_LFI-WP.pdf https://media.blackhat.com/bh-eu-12/Be'ery/bh-eu-12-Be'ery-F...
nice2kn0w 13y ago
saw this already? http://ninjafirewall.com/malware/index.php?threat=2013-05-28.01 http://ninjafirewall.com/malware/index.php?threat=2013-05-28...
jheriko 13y ago
i don't see how this is anything more than yet another lesson in why you should escape strings from external data soures unless you have a very good reason not to... interesting example though.
equiknox 13y ago
If I understand this correctly, there is PHP code (preg_replace) in the jpg exif header filled into the preg_replace function in the executable. The executable looks clean that way. The executable finds the jpg via hard-coded file path. Seems possible that the malicious code could appear in an image itself and be flagged with a simple but distinct header. The executable could just scan display memory for the simple header and execute subsequent code when header is found. Then when a user browses the image on a website, the code is executed without hard-coding the location. Pure speculation. Such an executable may be too visible. In any case it seems the essential problem of the preg_replace or some kind of PHP executable command would still be the red flag to find such malware.

221 points by cubictwo 13y ago

bbsec 13y ago

Great discovery!

3327 13y ago

As malicious as this may be it is pure genius. It should include a message as such: Elk Cloner: The program with a personality It will get on all your disks It will infiltrate your chips Yes, it's Cloner! It will stick to you like glue It will modify RAM too Send in the Cloner!

trebor 13y ago

Wow, this would bypass the execution constraints we put on the upload directories. Usually I make an uploads folder rw-rw-rw (0666); it would take another attack in conjunction with it, but that's really something.

morpher 13y ago
Only if someone modifies an executable file to call preg_replace with exif headers.

jeltz 13y ago

Seems like itt was possible to hide it so well due to an oversight in the API for preg_replace. In-band signaling in general makes it easy for people to accidentally add security holes. What they should have done is pass the regex options as a separate parameter, then it would have been obvious that something fishy was going on here.

amitparikh 13y ago

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

chrsstrm 13y ago
True, but most value hosting platforms run anything between 5.2.x and 5.4.x. with no option to upgrade.
- deadreturns2 13y ago
  Read: deprecated. Stop acting like it's removed in 5.5.
ajross 13y ago
Indeed. Yet it appears we are afflicted with lazy malware authors who continue to use deprecated APIs instead of updating their exploits. To be serious: According to the article, the call to preg_replace() was part of the backdoor added by the attackers, it wasn't a pre-existing hole in the site code.
infinity 13y ago
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.
- Arnor 13y ago
  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.

lcedp 13y ago

Eval in replace funtion.. But why?!

Afforess 13y ago
Because PHP.
- devgutt 13y ago
  http://docs.python.org/2/library/functions.html#eval http://docs.python.org/2/library/functions.html#eval
  - echohack 13y ago
    https://github.com/thijsdezoete/noevil https://github.com/thijsdezoete/noevil
  - deadreturns2 13y ago
    He's talking about the preg_replace /e modifier not eval, the function.
  - valleyer 13y ago
    note: “... in replace function”
  - pjscott 13y ago
    Yes, Python has eval, but it doesn't hide in the bushes and ambush you. The same can not be said for preg_replace and the /e option.
  - Dylan16807 13y ago
    Just curious, how many points does your comment have right now even though it's completely wrong? I'm not insulting you for making a tiny mistake, I'm wondering why a 7 hour old post with multiple 6 hour old corrections attached to it still has a positive score.
    - 13y ago

kghose 13y ago

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 these strings are executed

deleted 13y ago
[deleted]
deleted 13y ago
[deleted]
devicenull 13y ago
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)
A1kmm 13y ago
It isn't an exploit, but rather a code obfuscation technique. The attacker compromised the site first (the exploit used isn't disclosed in the article), and then tried to conceal the malware they installed on the compromised system by putting most of the malware in an EXIF header. The malware code used a hardcoded image path, so for someone else to replace the code to be executed, they would need to have access replace the particular image file that contains the malware. One interesting aspect is that the malware images are public, and probably already referenced to from the site (since the attacker used an existing image), so it might be possible to write a spider (or something based on Common Crawl perhaps) that finds many compromised sites.

savories 13y ago

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.

pjungwir 13y ago
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.

morpher 13y ago

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 preg_replace() with exif make/model parameters (which seems pretty unlikely to do anything useful)?

devrelm 13y ago
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.
- devicenull 13y ago
  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.
  - devrelm 13y ago
    In that case I agree that it would never be used as it was written, and suggest that the author must have jumbled the parameters. Calling the method as preg_replace($exif['Make'], '', $exif['Model']) would correct the behavior to something useful, while keeping the vulnerability in place.
bigiain 13y ago
I suspect it's a way of hiding backdoors in "free" themes/plugins. It's a technique that's not the usual obvious eval(base64decode("0xabad1dea")) that people might scan for (either by eye or with automated tools). That means this exploit might well be _in_ the "canonical source" - where the user doesn't suspect the "Super awesome social shopping comparison plugin" they downloaded is likely to be trojaned. (I wonder if anyone's running a scan over the WordPress.org plugins/themes librarys looking for unexplainable exif_read_data() and preg_replace() calls?)

vog 13y ago

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 param. This is almost like having a user-defined format string to printf(), and thus very suspicious and should be found by any decent security analysis tool. Even without the "/e" feature of preg_replace, this could result at least in a denial of service attack via some specially crafted regex parameters. So I agree that this is clever, but I don't agree that this call to preg_replace() should normally be considered harmless by itself. So the question remains why the authors overstate the cleverness of this attack, and I think they give the answer in the last sentence of the article: "Note: Any of Sucuri clients using Server Side Scanning are protected against this type of injection (detected by us)."

infinity 13y ago
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.

chrisweekly 13y ago

Interesting... but clueful site owners already strip all EXIF headers anyway, for performance reasons. Options for doing this abound (e.g. mod_pagespeed, grunt imagemin, http://smush.it http://smush.it, etc).

diminoten 13y ago
Ingress wasn't through EXIF headers, obfuscation is the goal. If this post effects your environment, you've already been compromised, and the hackers are merely attempting to avoid detection by hiding in the EXIF headers. This file wasn't uploaded through any legitimate means, it was replaced with malicious intent.
philrt 13y ago
How about tricking the server into generating the payload like this? https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/ https://www.idontplaydarts.com/2012/06/encoding-web-shells-i...

ebarock 13y ago

nice post!

smegel 13y ago

Surely any file format with metadata can contain malware if there is a bug in the program reading it...

ibudiallo 13y ago

This is not a bug in php that is being exploited. The server has already been compromised. The code look harmless enough for most people to ignore it, this is the point here. It's a clever obfuscation

martin_ 13y ago

This isn't new, and it certainly isn't specific to JPGs. It's quite frequent for people to embed malicious code into files masquerading as images. There has also been instances where hacked WordPress instances[1] hide code inside images so they aren't so obviously found ready for execution at a later date The most common way to exploit this however is by uploading an image with a valid magic number (e.g. GIF89a) which will any mime type checks and then finding a way to rename that file to one with an executable extension, or finding a way to include it through an LFI vuln. A simple solution is to simply load the image up in ImageMagick (or GraphicsMagick, GD) and re-write the image to disk. Disclaimer: Former lead developer of an image hosting service [1] https://media.blackhat.com/bh-eu-12/Be'ery/bh-eu-12-Be'ery-FYI_you_got_LFI-WP.pdf https://media.blackhat.com/bh-eu-12/Be'ery/bh-eu-12-Be'ery-F...

nice2kn0w 13y ago

saw this already? http://ninjafirewall.com/malware/index.php?threat=2013-05-28.01 http://ninjafirewall.com/malware/index.php?threat=2013-05-28...

jheriko 13y ago

i don't see how this is anything more than yet another lesson in why you should escape strings from external data soures unless you have a very good reason not to... interesting example though.

equiknox 13y ago

If I understand this correctly, there is PHP code (preg_replace) in the jpg exif header filled into the preg_replace function in the executable. The executable looks clean that way. The executable finds the jpg via hard-coded file path. Seems possible that the malicious code could appear in an image itself and be flagged with a simple but distinct header. The executable could just scan display memory for the simple header and execute subsequent code when header is found. Then when a user browses the image on a website, the code is executed without hard-coding the location. Pure speculation. Such an executable may be too visible. In any case it seems the essential problem of the preg_replace or some kind of PHP executable command would still be the red flag to find such malware.