Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Malware Hidden Inside JPG EXIF Headers

blog.sucuri.net

Post reply on HN
Print view View original

51–60 of 65 posts

Re: Malware Hidden Inside JPG EXIF Headers

#51

Post by randomdrake »

ceol wrote: post #49
randomdrake wrote: post #33

Earlier quoted context omitted.

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()…

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

I see. I didn't read it as a back door attack but an injection attack against bad code.

Re: Malware Hidden Inside JPG EXIF Headers

#53

Post by vog »

infinity wrote: post #25
vog wrote: post #18

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 pa…

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 lo…

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.

Re: Malware Hidden Inside JPG EXIF Headers

#54

Post by nly »

ars wrote: post #48
nly wrote: post #45

Earlier quoted context omitted.

In Perl wouldn't the /e modifier live outside the replacement string, as part of the literal regexp, and therefore out of harms way? The issue here is the "/e" modifier in PHP can be injected in to a context where the programmer didn't expect it. The preg_replace function should take the eval modifier as a flag parameter. Perl does have a ?{} eval expression, but it has to be enabled with an extra 'use' directive. Th…

Cute rant. But PHP uses /e in exactly the same way: The /e is part of the literal regexp. > Contrast this to PHP, where /e appears to be on by default No, /e is not enabled by default. > and there's no mention of it whatsoever in the documentation Yah, that's because it's not on by default. Do you expect them to document every idea you make up? > is a C library... so I doubt it has any eval functionality pcre_callout…

> Cute rant.

It wasn't a rant.

> But PHP uses /e in exactly the same way: The /e is part of the literal regexp.

PHP doesn't have literal regexps as part of the language. The regexps in PHP are string arguments to the preg_* family of functions. Perl has literal regexps. e.g. $var =~ s/$pattern/$replacement/e. If you inject "/e" in to $replacement variable, what happens? I don't know, my Perl is rusty, but I'm thinking that that would be either an unevaluated context, or a syntax error.

> No, /e is not enabled by default.

Only as of 5.5. That doesn't make the decision to enable it by default in the past excusable.

> pcre_callout()

This doesn't look like it has anything to do with /e or code evaluation. It's a callback mechanism that users of the library can use. How it's used is irrelevant, the topic at hand is PHPs behaviour.

> To anyone reading this: Don't use /e with untrusted input, it's not safe.

You missed the point. Programmers can use preg_replace poorly and not know that /e even exists. That was one point in the article: that this little function has a surprising and potentially dangerous feature. Just saying "oh well, don't use untrusted input" is naive.

Re: Malware Hidden Inside JPG EXIF Headers

#55

Post by devgutt »

Dylan16807 wrote: post #46
devgutt wrote: post #16

Earlier quoted context omitted.

http://docs.python.org/2/library/functions.html#eval

Just curious, how many points does your comment have right now even though it's completely wrong? I'm not insulting you for making a tiny mistake, I'm wondering why a 7 hour old post with multiple 6 hour old corrections attached to it still has a positive score.

because eval is the real source of the problem

Re: Malware Hidden Inside JPG EXIF Headers

#57

Post by daviddede »

vog wrote: post #18

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 pa…

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.

Re: Malware Hidden Inside JPG EXIF Headers

#58

Post by devrelm »

devicenull wrote: post #22
devrelm wrote: post #20

Earlier quoted context omitted.

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.

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.

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.

Re: Malware Hidden Inside JPG EXIF Headers

#59

Post by nikic »

nly wrote: post #45
jasonlotito wrote: post #35

Earlier quoted context omitted.

You mean Perl, right? Because that's what PCRE is, Perl Compatible Regular Expressions, and the e modifier does in fact come from Perl.

In Perl wouldn't the /e modifier live outside the replacement string, as part of the literal regexp, and therefore out of harms way? The issue here is the "/e" modifier in PHP can be injected in to a context where the programmer didn't expect it. The preg_replace function should take the eval modifier as a flag parameter. Perl does have a ?{} eval expression, but it has to be enabled with an extra 'use' directive. Th…

> Contrast this to PHP, where /e appears to be on by default and there's no mention of it whatsoever in the documentation, except in the change log to say it's deprecated in 5.5.

The preg_replace documentation says "Several PCRE modifiers are also available, including 'e' (PREG_REPLACE_EVAL), which is specific to this function" with a link to the PCRE modifiers page: http://de2.php.net/manual/en/reference.pcre.pattern.modifier.... This page has a bunch of warnings on the /e modifier :)

Generally putting user input into any regular expression function without running preg_quote over it first is a bad idea. Not just because of /e, but also various other issues, e.g. causing pathologically slow matches (DOS) or segfaults by deep recursion (DOS and maybe security relevant).

Re: Malware Hidden Inside JPG EXIF Headers

#60

Post by Dylan16807 »

devgutt wrote: post #55
Dylan16807 wrote: post #46

Earlier quoted context omitted.

Just curious, how many points does your comment have right now even though it's completely wrong? I'm not insulting you for making a tiny mistake, I'm wondering why a 7 hour old post with multiple 6 hour old corrections attached to it still has a positive score.

because eval is the real source of the problem

Would you remove the ability to load libraries, too? Because that's as dangerous as eval when it comes to purposely writing code to run external commands. The ability of a programming language to run code is not the cause of the problem, it's having domain-breaking misleading functions like a string replacer that can compile and execute.
Post reply on HN