Earlier quoted context omitted.
Because PHP.
http://docs.python.org/2/library/functions.html#eval
note: “... in replace function”
Malware Hidden Inside JPG EXIF Headers
31–40 of 65 posts
Re: Malware Hidden Inside JPG EXIF Headers
#32Re: Malware Hidden Inside JPG EXIF Headers
#33Although 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() for your operation. In this case, str_replace() would be not only be more appropriate, it would have helped remove the risk of exploit.
That aside, there have been reports of people exploiting metadata in images for years with PHP and other languages. This is not new in any way.
I'm disappointed that the article seems to stress that JPEGs are somehow inherently insecure when, in fact, it should be stressing that one should always be extremely careful dealing with user-submitted input.
In this example, one could simply replace the image uploading aspect with any sort of submitted data. If you're going to be dynamically passing user input into functions of your application, you should always be certain to appropriately clean and escape those situations. Whether that data is hidden in the EXIF data on an image, is going to be put into a database, or is dynamic regex, a healthy level of distrust for all user submitted data is necessary.
Re: Malware Hidden Inside JPG EXIF Headers
#34Re: Malware Hidden Inside JPG EXIF Headers
#35Re: Malware Hidden Inside JPG EXIF Headers
#36Although 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…
and if you do need a dynamic pattern, this is what preg_quote() is for.
Re: Malware Hidden Inside JPG EXIF Headers
#37Interesting... 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 , etc).
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.
Re: Malware Hidden Inside JPG EXIF Headers
#38Although 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()…
The point of the post seems to be to advertise their product. The comments seem to confirm that.
Re: Malware Hidden Inside JPG EXIF Headers
#39Interesting... 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 , etc).
How about tricking the server into generating the payload like this?
https://www.idontplaydarts.com/2012/06/encoding-web-shells-i...
Re: Malware Hidden Inside JPG EXIF Headers
#40Surely any file format with metadata can contain malware if there is a bug in the program reading it...