4 ms·

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

• 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.