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
Malware Hidden Inside JPG EXIF Headers
41–50 of 65 posts
Re: Malware Hidden Inside JPG EXIF Headers
#42So 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…
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.
Re: Malware Hidden Inside JPG EXIF Headers
#43If 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…
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?)
Re: Malware Hidden Inside JPG EXIF Headers
#44This 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-F...
Re: Malware Hidden Inside JPG EXIF Headers
#45Earlier quoted context omitted.
Because PHP.
You mean Perl, right? Because that's what PCRE is, Perl Compatible Regular Expressions, and the e modifier does in fact come from Perl.
In Perl wouldn't the /e modifier live outside the replacement string, as part of the literal regexp, and therefore out of harms way? The issue here is the "/e" modifier in PHP can be injected in to a context where the programmer didn't expect it. The preg_replace function should take the eval modifier as a flag parameter.
Perl does have a ?{} eval expression, but it has to be enabled with an extra 'use' directive. The documentation also suggests enabling taint checking or "constrained evaluation within a Safe compartment".
Contrast this to PHP, where /e appears to be on by default and there's no mention of it whatsoever in the documentation, except in the change log to say it's deprecated in 5.5.
Also PCRE, which PHP uses, is a C library... so I doubt it has any eval functionality. PHP implements this on top of PCRE to mimic Perl.
No I'm afraid it's another shoddy PHP design decision to blame here.
Re: Malware Hidden Inside JPG EXIF Headers
#46Earlier quoted context omitted.
Because PHP.
http://docs.python.org/2/library/functions.html#eval
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.
Re: Malware Hidden Inside JPG EXIF Headers
#47Although 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…
Why do you have to dog on the post? I've ran into malware attacks in the past, and none of the things I've seen on the net caution you to look for pre_replace instances gone wrong. eval(), base_64_decode() and the like get all the press.
Re: Malware Hidden Inside JPG EXIF Headers
#48Earlier quoted context omitted.
You mean Perl, right? Because that's what PCRE is, Perl Compatible Regular Expressions, and the e modifier does in fact come from Perl.
In Perl wouldn't the /e modifier live outside the replacement string, as part of the literal regexp, and therefore out of harms way? The issue here is the "/e" modifier in PHP can be injected in to a context where the programmer didn't expect it. The preg_replace function should take the eval modifier as a flag parameter. Perl does have a ?{} eval expression, but it has to be enabled with an extra 'use' directive. Th…
Cute rant. But PHP uses /e in exactly the same way: The /e is part of the literal regexp.
> Contrast this to PHP, where /e appears to be on by default
No, /e is not enabled by default.
> and there's no mention of it whatsoever in the documentation
Yah, that's because it's not on by default. Do you expect them to document every idea you make up?
> is a C library... so I doubt it has any eval functionality
pcre_callout()
> No I'm afraid it's another shoddy PHP design decision to blame here.
No I'm afraid it's just another ignorant PHP basher to blame here. Do you just like to make stuff up about PHP, then bash it?
PS. To anyone reading this: Don't use /e with untrusted input, it's not safe. But if must assign blame, then blame perl for it, not php.
Re: Malware Hidden Inside JPG EXIF Headers
#49Although 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 completely agree with your assessment. I would like to add that there's probably no reason regex would even be needed for this task. str_replace() would be the more appropriate call. In ##php on Freenode we often have to tell people that you don't need to use preg_* functions if you are not using the power of regular expressions. If you don't need the power of regular expressions, you should be using str_replace()…
> In this case, str_replace() would be not only be more appropriate, it would have helped remove the risk of exploit.
Actually, the exploit was a backdoor planted by the hacker, so the system was already compromised. The recommendation to use str_replace in this instance would be useless, as it appears the victim didn't even put the code there in the first place.
Re: Malware Hidden Inside JPG EXIF Headers
#50Earlier quoted context omitted.
In Perl wouldn't the /e modifier live outside the replacement string, as part of the literal regexp, and therefore out of harms way? The issue here is the "/e" modifier in PHP can be injected in to a context where the programmer didn't expect it. The preg_replace function should take the eval modifier as a flag parameter. Perl does have a ?{} eval expression, but it has to be enabled with an extra 'use' directive. Th…
Cute rant. But PHP uses /e in exactly the same way: The /e is part of the literal regexp. > Contrast this to PHP, where /e appears to be on by default No, /e is not enabled by default. > and there's no mention of it whatsoever in the documentation Yah, that's because it's not on by default. Do you expect them to document every idea you make up? > is a C library... so I doubt it has any eval functionality pcre_callout…
| Don't use /e with untrusted input
preg_replace($VAR1 + "/e", $VAR2,'');