Categories: Cryptography, Malware, Web Security

Comments (25)

  1. amirbudicecep
    1

    Except it’s not relatively new:
    http://blog.nihilogic.dk/2008/05/compression-using-canvas-and-png.html

    Also, see this:
    http://jsunpack.jeek.org/

    And I wonder where the “injection” is.. the entire code is ran from the attacker’s page. If the objective is to obfuscate the code, and the attacker already controls the code, he can put whatever techniques, obfuscated or not, in that loadFile() function.

    So, yeah, not exactly a new PNG script packer, and a dubious claim of “injection” here.

    Reply
    • puevigi
      3

      It appears you only read the first half of the article?
      “The strategy isn’t exactly new; Mario Heiderich, a researcher and pen tester at the German firm Cure 53 warned that image binaries in Javascript could be used to hide malicious payloads in his “JavaScript from Hell” con talk back in 2009.”
      That gives us a better understanding of the author’s “x” for relative here.
      The article itself is about the exploit being refined to allow for detection avoidance under current scanning methods.

      Reply
    • ZZooooooLL
      4

      i agree with amir. steganography is not new by any stretch of the imagination. i was taught about it in college 3 years ago.
      I am also in agreement about the sceptical claims of “injection”.

      Reply
    • Anonymous
      5

      I assumed the attack vector was some compromised png file, like artwork for a game. In that case it would inject the iframe for anyone who happens to play it.

      Reply
  2. MrCR
    6

    Unless you’re injecting this into advertisements you’re distributing via an ad network that would otherwise check for malware.

    Reply
  3. darthba11z
    10

    Only old people run javascript anyway

    Here’s a tip, never install javascript. The only websites I even see using it are shady anyway.

    Congrats, you’ve just become immune to 99% of these ‘threats’

    Reply
    • Bungalou
      11

      Actually, you don’t install Javascript. You must be thinking of Java, which is entirely different than Javascript.

      Reply
  4. amn
    12

    I am always amazed how most security researchers are totally incapable of explaining their findings to a general audience. At least this article doesn’t. I am a computer programmer, and I know my way around web technology, as well as pretty much anything down to how machine instructions and CPUs work, but I failed to understand what details this article tried to explain – does the JavaScript code decode PNG? Does it “run” metadata encoded in PNG? What does the iframe do, besides being shown off screen.

    C’mon, people, it is not that difficult to talk human language – try a point by point description of the problem. Somewhere between raising your head from looking at the keyboard and your laptop screen, you lost that fine ability to FORMULATE YOURSELVES.

    Neither this trojan nor being able to explain yourself are well, rocket science. The latter is far more important, too.

    Reply
  5. rpsw
    14

    Looking at the code listing, is the payload not in fact in the image data, rather than the meta data as said in the article. It seems to be retrieving a character from every red pixel.

    Metadata would usually imply it was coming from header information of the image, such as EXIF info or in the case PNG maybe the iTXt/tEXt chunks.

    Reply
  6. Ambidex
    15

    Shouldn’t / Couldn’t this be something that browser’s intercept? I find it a bit troublesome that this kind of code execution is even possible from a image file.

    Reply
  7. Paul Fletcher
    16

    @amirbudicecep Isn’t the point of this, that most anti-virus software wouldn’t bother to scan the png file, which then in turn runs another js file? So it’s both a new packer and an injection

    Reply
  8. Jeff
    17

    To summarize without the sky is falling drama: “If you encrypt javascript in your page, you can decrypt that code and execute it.”

    You don’t have to worry about PNGs hosted on your site harming your users because of this.

    If there already is code on your site that tries to pull data from PGNs in a specific way, decode it, and execute it, then you have bigger issues.

    As for the idea that obfuscation is a good means of avoiding detection of malicious code for antivirus scanners: no kidding.

    Encoding data in PNGs is nothing new. Using normal encrpytion to encrypt code also works.

    Reply
  9. Jeff
    21

    @amn: I’ll have to defend the article in that point. You mentioned that the article doesn’t explain how to get this data or how it’s stored.

    The article included an easy to read sample method called LoadPNGData that loads a string from a PNG.

    Reply
  10. SoothSayer
    22

    Heh, doesn’t matter how they hide the virus when you run FortHoodAV, it still detects and removes the threat. Even if its “FUD”.

    Reply
  11. Brian m
    23

    Understand how the hidden code can be introduced, but not so sure why this should be a threat as it’s held within the web browser/JavaScript environment which in ‘theory’ is a sandboxed environment? Or is this environment no longer safe due to gratuitous features being added.

    Reply
    • Brian m
      24

      Just got it! The image is somehow loaded on to an innocent web site and the injected code messes with the way the site works etc.

      Reply
  12. amirbudicecep
    25

    I didn’t realize this post invited quite a number of comments..
    As I happened to do a search on my throwable pseudonym, it’s been 5 months but here’s my reply to some of the follow up comments:

    @puevigi (#3)
    Both this threatpost and the original article mentioned “[relatively] new” and they’re written in Feb 2014. Even if he mentioned Heiderich’s 2009 talk towards the end of the article, the “new” verbiage was used to frame the technique as something novel.. which is not. Gramantik didn’t even seem to bother searching of the code snippet to get the SAME EXACT code from the links I included above.

    So, nope, I didn’t read only the first half of the article. While I appreciate it gives more people better understanding, this is completely not a new technique. To some people may be, but it’s not new.

    @fed (#8)
    It doesn’t matter or it’s not relevant. If you allow user to upload *something*, and that something will just be stored somewhere (i.e. not processed), you can upload any contents with any file extension, obfuscated or not. Yes, steganography or image processing is a convenient avenue to be processed by existing/available web library. But that’s it: it’s a convenience and not a compulsory vector. For example, as an attacker, if you can write/run some code to load external files, you don’t need steganography. Just upload a .png with some obfuscated JavaScript/JSON contents and include it in a . It will not be a valid PNG file but you’ll avoid “detection” the same way.

    @amn (#12)
    loadPNGData() use HTML Canvas library to load (decode) the PNG. The actual script payload is in the byte values of the pixels, see the loop in line 28-31. To run the payload, loadFile() will need to use something like eval(strData) in line 49 instead of merely alert-ing it.

    @Paul Fletcher (#16)
    It’s not a new packer (see the links from 2008 I included in my first comment, they even generate/are the SAME EXACT code as what the researcher “found”). As for the “injection”, I failed to see where the injection happened. If the attacker can upload their own code (talking about the loadFile(), not the PNG itself), it’s pretty much game over. If the loadFile() is the attacker’s own controlled code, what injection then?

    Reply

Leave A Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>