5 ms·

Let's not jump to conclusions. If Symantec's characterization of the sophistication of this malware is accurate, then surely they could have afforded some crypt

by alister 12y ago

Let's not jump to conclusions. If Symantec's characterization of the sophistication of this malware is accurate, then surely they could have afforded some crypto expertise. First, can we agree that any encryption algorithm better than a Caesar cipher is good enough for this particular application? That's because nobody who's analyzing this malware is going to bother with cryptanalysis because there's an easier approach. The encrypted data has to get decrypted before it runs. Therefore, you watch the execution with a debugger until it gets decrypted and executed, and then just capture the plaintext data (and the key if you want). Given that resisting serious cryptanalysis is off the table, I can suggest several reasons for RC5: - It has much smaller code size (500 bytes vs 15000 for AES). - It's less vulnerable to fingerprinting. That is, anti-virus software might have checks for AES but not RC5. The malware writer would know this because they actually tested their malware against all the anti-virus products and found that none of them have signature or heuristic checks for RC5 but do against AES. (I'm just fleshing out the thought; I don't know if AV software checks for AES and RC5.) - AES runs faster than RC5 in general, but maybe the particular platform or instruction set for this malware makes RC5 faster.

tptacek 12y ago
I'm having trouble parsing this comment. Your suggestion is that the author is sophisticated and that's why they chose RC5? RC5 is a broken 1990s cipher. If the authors wanted to minimize code size, they'd have used a native stream cipher, not a 64-bit block cipher. I'm also having trouble with the idea that the author of this trojan might be GCHQ or NSA (or sponsored by them), but that cryptanalytic techniques from the late 1970s are off the table.
- alister 12y ago
  > the author is sophisticated and that's why they chose RC5 I'm saying that because the author is sophisticated, they know that the strength of the algorithm doesn't matter (so long as it's not something ridiculously simple). DES, AES, RC5, RC6, whatever. They're all good enough because Symantec (or whoever is analyzing the malware) is going to get the plaintext no matter what. Symantec is not going to do any cryptanalysis whatsoever. Symantec is going to run the sample malware in a debugger and watch it get decrypted. The malware must decrypt itself in order to run.
  - AlyssaRowan 12y ago
    The malware must decrypt the parts that it runs. (There's an obfuscation technique that's apparently quite strong in existence, but it produces gigabyte executables for simple 5-condition if statements you can brute force by hand, so it's ludicrously impractical.) This could be worse. It could have encrypted routines for which the commands are the decryption keys. It doesn't appear to be particularly polymorphic. If there's a BIOS/PCI dropper, it's (sadly) long gone here.
- pbsd 12y ago
  Choosing RC5 is an irrelevant implementation detail; they probably used whatever was in hand at the time. The only requirement is that the function makes things random-looking, really. I agree with alister in that the reason---if there was any reasoning applied here---was likely code size / simplicity. Look at Flame's encryption functions [1, §4]. This is the malware that burned a chosen-prefix MD5 collision elsewhere, but still went ahead and used the simplest mangling functions possible. You also find plenty of other 'state-sponsored' malware using similarly stupid/weak/outdated encryption. [1] http://www.crysys.hu/skywiper/skywiper.pdf http://www.crysys.hu/skywiper/skywiper.pdf
  - tptacek 12y ago
    I guess if you're saying you can't read RC5 as being a point in favor of or against GCHQ, I find your argument plausible. RC5 is more plausible at least than RC6, which (a) few people have at hand and (b) calls significantly more attention to itself.
- erglkjahlkh 12y ago
  It's not supposed to really encrypt anything. It's an obfuscation method. It doesn't matter how "broken" it is, as long as anti-virus applications have no idea about how to "decrypt" it. They might as well XOR'ed the data, but opted in for RC5 for some reason.
AlyssaRowan 12y ago
The term you're looking for is "crypter". Heuristics may be more sensitive to the executable-packer-like behaviour than the crypter itself. Signatures which look for crypters will obviously target constants if they're around. Speed is not a factor - size is. Cryptographic security is far less important than fingerprint evasion: rolling your own is not therefore as insane as it usually sounds. RC5 is therefofe a slightly odd choice. Block function's a small Feistel, but the key schedule is a pain which totes constants around, which is poor especially from a polymorphic/metamorphic crypter's perspective, because that means you'll have to calculate them or include literals, and they're distinctive constants which make it pop out. AES has a similar issue with the distinctive S-boxes - include or calculate them. RC4 variants are more common (but you need scratch space), as are smaller more native stream ciphers, right down to good old XOR-based crypters, which will do the job. RC5 is just not the first thing that'd spring to mind to me. It obviously was what sprang to mind to the author of that particular bit. Code styles differ, as do skill levels. Big team. They speak English. It's big. They're interested in Ireland. US or UK is a good guess. I don't think this matches the Detica one for GCHQ, so my early suspicion still remains NSA. We're missing huge chunks though.
- AlyssaRowan 12y ago
  Got more payload chunks. Wow, they were sloppy with this - found plenty of symbol references still in them! So far, that makes references to LEGSPIN, WILLISCHECK, HOPSCOTCH, STARBUCKS, FOGGYBOTTOM, SALVAGERABBIT. I believe this may be NSA's UNITEDRAKE implant architecture, specifically.
  - tptacek 12y ago
    Well then! Totally ready to believe that I am 0 for 2 on attributing state-sponsored malware. :)
    - AlyssaRowan 12y ago
      It appears that GCHQ have used this too. Maybe they've shared some work (via BAE Systems Detica?) after all? Who names this stuff?! ANGRYFERRET? (Probably no relation to FERRETCANNON; whoever named that one is clearly a Sluggy Freelance fan.) SQUEAKYTOY?

by alister 12y ago

tptacek 12y ago

I'm having trouble parsing this comment. Your suggestion is that the author is sophisticated and that's why they chose RC5? RC5 is a broken 1990s cipher. If the authors wanted to minimize code size, they'd have used a native stream cipher, not a 64-bit block cipher. I'm also having trouble with the idea that the author of this trojan might be GCHQ or NSA (or sponsored by them), but that cryptanalytic techniques from the late 1970s are off the table.

alister 12y ago
> the author is sophisticated and that's why they chose RC5 I'm saying that because the author is sophisticated, they know that the strength of the algorithm doesn't matter (so long as it's not something ridiculously simple). DES, AES, RC5, RC6, whatever. They're all good enough because Symantec (or whoever is analyzing the malware) is going to get the plaintext no matter what. Symantec is not going to do any cryptanalysis whatsoever. Symantec is going to run the sample malware in a debugger and watch it get decrypted. The malware must decrypt itself in order to run.
- AlyssaRowan 12y ago
  The malware must decrypt the parts that it runs. (There's an obfuscation technique that's apparently quite strong in existence, but it produces gigabyte executables for simple 5-condition if statements you can brute force by hand, so it's ludicrously impractical.) This could be worse. It could have encrypted routines for which the commands are the decryption keys. It doesn't appear to be particularly polymorphic. If there's a BIOS/PCI dropper, it's (sadly) long gone here.
pbsd 12y ago
Choosing RC5 is an irrelevant implementation detail; they probably used whatever was in hand at the time. The only requirement is that the function makes things random-looking, really. I agree with alister in that the reason---if there was any reasoning applied here---was likely code size / simplicity. Look at Flame's encryption functions [1, §4]. This is the malware that burned a chosen-prefix MD5 collision elsewhere, but still went ahead and used the simplest mangling functions possible. You also find plenty of other 'state-sponsored' malware using similarly stupid/weak/outdated encryption. [1] http://www.crysys.hu/skywiper/skywiper.pdf http://www.crysys.hu/skywiper/skywiper.pdf
- tptacek 12y ago
  I guess if you're saying you can't read RC5 as being a point in favor of or against GCHQ, I find your argument plausible. RC5 is more plausible at least than RC6, which (a) few people have at hand and (b) calls significantly more attention to itself.
erglkjahlkh 12y ago
It's not supposed to really encrypt anything. It's an obfuscation method. It doesn't matter how "broken" it is, as long as anti-virus applications have no idea about how to "decrypt" it. They might as well XOR'ed the data, but opted in for RC5 for some reason.

AlyssaRowan 12y ago

The term you're looking for is "crypter". Heuristics may be more sensitive to the executable-packer-like behaviour than the crypter itself. Signatures which look for crypters will obviously target constants if they're around. Speed is not a factor - size is. Cryptographic security is far less important than fingerprint evasion: rolling your own is not therefore as insane as it usually sounds. RC5 is therefofe a slightly odd choice. Block function's a small Feistel, but the key schedule is a pain which totes constants around, which is poor especially from a polymorphic/metamorphic crypter's perspective, because that means you'll have to calculate them or include literals, and they're distinctive constants which make it pop out. AES has a similar issue with the distinctive S-boxes - include or calculate them. RC4 variants are more common (but you need scratch space), as are smaller more native stream ciphers, right down to good old XOR-based crypters, which will do the job. RC5 is just not the first thing that'd spring to mind to me. It obviously was what sprang to mind to the author of that particular bit. Code styles differ, as do skill levels. Big team. They speak English. It's big. They're interested in Ireland. US or UK is a good guess. I don't think this matches the Detica one for GCHQ, so my early suspicion still remains NSA. We're missing huge chunks though.

AlyssaRowan 12y ago
Got more payload chunks. Wow, they were sloppy with this - found plenty of symbol references still in them! So far, that makes references to LEGSPIN, WILLISCHECK, HOPSCOTCH, STARBUCKS, FOGGYBOTTOM, SALVAGERABBIT. I believe this may be NSA's UNITEDRAKE implant architecture, specifically.
- tptacek 12y ago
  Well then! Totally ready to believe that I am 0 for 2 on attributing state-sponsored malware. :)
  - AlyssaRowan 12y ago
    It appears that GCHQ have used this too. Maybe they've shared some work (via BAE Systems Detica?) after all? Who names this stuff?! ANGRYFERRET? (Probably no relation to FERRETCANNON; whoever named that one is clearly a Sluggy Freelance fan.) SQUEAKYTOY?