md5(md5(...10,000 times...(md5(X + salt)...)) = hash
Or, find a way to calculate
md5(md5(...10,000 times...(md5(X + salt')...))
Or alternatively, attempt a known plain text attack against RC4. Given that a certain amount of plain text is known (4 bytes) at the start of the RC4 payload then it's likely that the first few bytes of the keystream are known and an attack could be mounted via weakness in the RC4 key schedule.
It should be possible to do a brute force search using a couple of days of EC2 or (insert your favorite cloud provider) here. And by bruteforce you can try text search, or just go for the raw bytes. Not sure a collision can work in this case as well.
The input to the RC4 key generator is an MD5 hash which means you'd be looking at doing a brute force attack against an input of 2^128 bits. Assuming you find the answer on average in 2^127 and you are looking at an enormous search space.
According to a recent article EC2 has about 500,000 machines. Now assume that I buy them all and I am able on each machine to check 1,000,000,000 values as inputs to RC4 per second then I should have the answer in 800,000 times the age of the universe. But I think my credit card will have been cancelled first.
Microsoft exception reporting must have a list of all apps ever seen too?
I don't know if the "Program files" path (or the full path) is added to the hash calculation, but at least in Windows XP this is localized
Or who knows, the secret is that it only works in systems where Program files is in D:/
PBKDF2 is SHA-1 and 4096 rounds, this shouldn't be impossible
Bonus points if you use FPGAs to calculate MD5s
I'd be much more tempted to look at the fact that the first four bytes of the RC4 key stream appear to be recoverable and look at key recovery from that.
It seems to me that's a good theory of what it might be looking for, as GUIDs should make good triggers. I wonder if this reduces the search space enough to make brute force feasible now.
If the payload is a zero day for an obscure Iranian made piece of software, no one will ever get that
Public key crypto was discovered on the inside long before it was rediscovered on the outside, and I figure that the insiders must have been amused by Diffie, Hellman, R, S, and A.
In 1997, it was publicly disclosed that asymmetric key algorithms were developed by James H. Ellis, Clifford Cocks, and Malcolm Williamson at the Government Communications Headquarters (GCHQ) in the UK in 1973. These researchers independently developed Diffie–Hellman key exchange, and a special case of RSA. The GCHQ cryptographers referred to the technique as "non-secret encryption". This work was named an IEEE Milestone in 2010.
Name of target software in Program Files is interesting nevertheless. Probably it's mentioned in the encrypted code/data.
I suppose µTorrent is too obvious... Anyway, these kinds of mysteries help re-ignite my interest in Cryptography. I'd love to hear feedback from a fellow HNer about the course from Udacity (perhaps via email since it will probably be considered off-topic here).
It's not much consolation that you now know that you're being targeted by the Program Files entries (they're a major pain to rename). It's likely there are one or more plants inside your operation and they have physical access to the machine, which is considered game over.
Release Gauss into the wild, have your agent in Fordu Nuclear plant be sure he has Gauss on his machine, and then just get him to name the jpgs or text files he wants sent back to the CIA as 'special.jpg' - Gauss nabs them, sends it back through the network of gauss infected machines, and hey presto - deniable, encrypted, distributed Dead Drops.
Wow. Clever. Thank you
1. Its part of a wider eco-system of collecting / infecting / attacking "framework". It seems that attacking uranium enrichment was just a "plug-in".
2. They have designed for multiple infection vectors. Now if it can get in it can also get out. I would not be surprised if the family of malware here is also able to hook into outlook.exe, and even piggy back on IE connections. There is no particular reason why a payload cannot be steganographically put into every photo uploaded to irans' facebook. Which may not be entirely secure of couse :-)
The possibilites when you have the money and time are incredible.
So, no, something as silly as transmitting over UDP from the agents laptop back to www.cia.gov is unlikely, but this things will just keep pushing data around and around till it gets either home, or to a target.
Sadly, much of the code is out in the open. And is surely being pulled apart by other nationstates and the mafia.
Fun times ahead
Seems much more likely that the check is there to confirm that the payload only runs on specific targets. And, perhaps more importantly, to make recovery and dissection of the payload very difficult for someone without access to the target(s).
The key is of course is to lay low and undetected until that trigger fires, otherwise, anti-virus companies will blow the whistle.
"2. Append the pair with the second hard-coded 16-byte salt and bytes 0x15, 0x00 " and assuming point 2 of my message above:
This gives a finger print of all actual used programs. This finger print should be specific in the range of 1 to 10^(-7).
If so specific, it limits the scope to preconfigured systems, which are NOT run under user control.
Might it be, that those targets are embedded systems like ATM, Mobile base stations and again SCADA-systems?
Supposedly an administrator could send an update that inserts random files in program files to foil the system identification method, but given that the attacker has such detailed information about the target systems, this seems like a temporary measure at best.
Edit: It looks like the code is only looking for a specific filename. In that case, the only way to thwart this is to rename that file (and fix any issues that this would cause).
Because it's a tool designed to take out Iranian uranium refining tools.
So, I would be surprised to find this was not also using, say the parts of Unicode with Chinese characters as well.