4 ms·

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

by 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?)

by morpher 13y ago

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?)