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.
Malware Hidden Inside JPG EXIF Headers
11–20 of 65 posts
Re: Malware Hidden Inside JPG EXIF Headers
#12From PHP documentation ( http://php.net/manual/en/function.preg-replace.php ) 5.5.0 The /e modifier is deprecated. Use preg_replace_callback() instead.
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.
Re: Malware Hidden Inside JPG EXIF Headers
#13So 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…
[deleted]
Re: Malware Hidden Inside JPG EXIF Headers
#14If 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)?
Re: Malware Hidden Inside JPG EXIF Headers
#15So 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…
[deleted]
Re: Malware Hidden Inside JPG EXIF Headers
#16Eval in replace funtion.. But why?!
Because PHP.
Re: Malware Hidden Inside JPG EXIF Headers
#17Wow, 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.
Only if someone modifies an executable file to call preg_replace with exif headers.
Re: Malware Hidden Inside JPG EXIF Headers
#18Although 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'],'');
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)."
Re: Malware Hidden Inside JPG EXIF Headers
#19Earlier quoted context omitted.
Because PHP.
http://docs.python.org/2/library/functions.html#eval
Re: Malware Hidden Inside JPG EXIF Headers
#20If 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.