4 ms·

Although this obfuscation is very clever, I think the article overstates a bit. The author claims that the following two commands "harmless by themselves": $

by vog 13y ago

Although 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 param. This is almost like having a user-defined format string to printf(), and thus very suspicious and should be found by any decent security analysis tool. 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)."

infinity 13y ago
I think that the main point or cleverness is to avoid an explicit eval ( base64decode ( blahblah ...) ) in the PHP source code, which might be detected. A preg_replace call is also easy to spot, but may occur naturally in the source. Constructs using a sequence of eval with base64decode and often gzip compression are very common for obfuscating malicious PHP code. I would expect that people are much more likely to look for these in the source code to find out if a website has been compromized rather than looking at EXIF data. So I think, yes, this is something different. In the article they call this a steganographic malware. But actually the information is not embedded in the picture content, but in the meta or EXIF data. It would be an application of steganography, if the malicious code would be extracted from information that is part of the actual picture and it is not obvious that this information is present in the first place. For example, there could be the drawing of a house in the picture with a cow and a horse and the grass blades in front of it represent 1s and 0s. Then some clever program executes the grass blades code. It seems that the authors were among the first to detect this kind of attack using the EXIF data in the wild. And of course the want to advertise that their product detects this kind of compromize.
- vog 13y ago
  Indeed, that's another overstatement in the article: Calling this kind of embedding "steganographic", although the malicious code appears clear text within the image raw data.
randomdrake 13y ago
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.
- d23 13y ago
  The point of the post seems to be to advertise their product. The comments seem to confirm that.
- ceol 13y ago
  > 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.
  - randomdrake 13y ago
    I see. I didn't read it as a back door attack but an injection attack against bad code.
munger 13y ago
and if you do need a dynamic pattern, this is what preg_quote() is for. http://php.net/manual/en/function.preg-quote.php http://php.net/manual/en/function.preg-quote.php
dangayle 13y ago
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.
daviddede 13y ago
I think you are over thinking a bit. We do many blog posts per month sharing what we find in the "wild". If you go to the blog, you will see the amount we have. This is just another one that our team found interesting enough to share.

by vog 13y ago

infinity 13y ago

I think that the main point or cleverness is to avoid an explicit eval ( base64decode ( blahblah ...) ) in the PHP source code, which might be detected. A preg_replace call is also easy to spot, but may occur naturally in the source. Constructs using a sequence of eval with base64decode and often gzip compression are very common for obfuscating malicious PHP code. I would expect that people are much more likely to look for these in the source code to find out if a website has been compromized rather than looking at EXIF data. So I think, yes, this is something different. In the article they call this a steganographic malware. But actually the information is not embedded in the picture content, but in the meta or EXIF data. It would be an application of steganography, if the malicious code would be extracted from information that is part of the actual picture and it is not obvious that this information is present in the first place. For example, there could be the drawing of a house in the picture with a cow and a horse and the grass blades in front of it represent 1s and 0s. Then some clever program executes the grass blades code. It seems that the authors were among the first to detect this kind of attack using the EXIF data in the wild. And of course the want to advertise that their product detects this kind of compromize.

vog 13y ago
Indeed, that's another overstatement in the article: Calling this kind of embedding "steganographic", although the malicious code appears clear text within the image raw data.

randomdrake 13y ago

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.

d23 13y ago
The point of the post seems to be to advertise their product. The comments seem to confirm that.
ceol 13y ago
> 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.
- randomdrake 13y ago
  I see. I didn't read it as a back door attack but an injection attack against bad code.

munger 13y ago

and if you do need a dynamic pattern, this is what preg_quote() is for. http://php.net/manual/en/function.preg-quote.php http://php.net/manual/en/function.preg-quote.php

dangayle 13y ago

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.

daviddede 13y ago

I think you are over thinking a bit. We do many blog posts per month sharing what we find in the "wild". If you go to the blog, you will see the amount we have. This is just another one that our team found interesting enough to share.