Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Researchers Seek Help Cracking Gauss Mystery Payload

timothy posted more than 2 years ago | from the fabulous-prizes-await dept.

Encryption 229

An anonymous reader writes "Researchers at Kaspersky Lab are asking the public for help in cracking an encrypted warhead that gets delivered to infected machines by the recently discovered Gauss malware toolkit. They're publishing encrypted sections and hashes in the hope that cryptographers will be able to help them out." Adds reader DavidGilbert99: "The so-called Godel module is targeting a specific machine with specific system configurations, and Kaspersky believes the victim is likely a high-profile target. The decryption key, Kaspersky believes, will be derived from these specific system configurations, and so far it has been unable to find out what they are."

cancel ×

229 comments

Sorry! There are no comments related to the filter you selected.

Geez, just ask the NSA (4, Funny)

crazyjj (2598719) | more than 2 years ago | (#40984047)

What did you guys put in it, again?

Re:Geez, just ask the NSA (5, Interesting)

Anonymous Coward | more than 2 years ago | (#40984129)

And notice they're only giving out pieces, no nobody knows what they're working on. Nice way to keep secrets while exploiting cheap labor from "the crowd"

Re:Geez, just ask the NSA (3, Funny)

jhoegl (638955) | more than 2 years ago | (#40985209)

I wonder if they tried "GOD" for the password.
Hey... it worked in hackers.

Re:Geez, just ask the NSA (1, Interesting)

chemosh6969 (632048) | more than 2 years ago | (#40985211)

Consider this. This time they don't want to be as dumb as they were in the past when they let our nation's enemies have all the information they need about the attacks we were doing to them. In this case, once they find out exactly what it's doing and can determine if it's some retarded hacking team that wants to steal CC info or it's something the government's involved in. If it's the latter, there's no need to release info on who's being targeted and other specifics. They were probably also contacted in regards to what happened previously. Some countries feel a need to have some form of national security, regardless of what some bearded basement dweller thinks.

Of course there isn't anything to stop another country that finds code like this to setup something to let IT people do the work for them to tell them exactly what it does. In this case, if things go right, that country can then start setting up fake systems and start feeding bad info through the exploit.

Re:Geez, just ask the NSA (1)

Anonymous Coward | more than 2 years ago | (#40985435)

the attacks we were doing to them

Its hard to feel like the good guys when "we" are doing all those attacks to "them"

Re:Geez, just ask the NSA (-1)

Anonymous Coward | more than 2 years ago | (#40984363)

har har har you so funny!

But it's not NSA, idiot. It's military.

Re:Geez, just ask the NSA (0)

gmuslera (3436) | more than 2 years ago | (#40984455)

If they probably are using a GPL library for decoding/uncompressing, they could be sued to release the code to be compliant with the license.

Re:Geez, just ask the NSA (2)

jpmorgan (517966) | more than 2 years ago | (#40984585)

Probably? Of all people and organizations in the world, I suspect the NSA is the least likely to be relying on GPL'd third party code for their encryption needs.

Re:Geez, just ask the NSA (3, Informative)

tgd (2822) | more than 2 years ago | (#40984619)

If they probably are using a GPL library for decoding/uncompressing, they could be sued to release the code to be compliant with the license.

That seems to be a common misconception. That's not how the GPL works. They need to make the code available to their customers on demand. You aren't their customer, you can't demand anything.

Re:Geez, just ask the NSA (1)

gmuslera (3436) | more than 2 years ago | (#40984965)

If you got it, no matter if got activated or not because your machine is not the full target system, then you should be able to demand it (specially if got delivered to you in the way that the maker intended to, is not like you stole it)

Re:Geez, just ask the NSA (2)

tgd (2822) | more than 2 years ago | (#40985131)

If you got it, no matter if got activated or not because your machine is not the full target system, then you should be able to demand it (specially if got delivered to you in the way that the maker intended to, is not like you stole it)

Laws, contracts and licenses aren't made of "shoulds"

Re:Geez, just ask the NSA (0)

Anonymous Coward | more than 2 years ago | (#40984997)

We are now.

Re:Geez, just ask the NSA (2)

ceoyoyo (59147) | more than 2 years ago | (#40985319)

The GPL v3 contains the word "customer" in only one place, and it precedes "support" and is talking about the period of time you offer customer support for a hardware device.

The requirement is that if you "convey" the code in binary form you must also "convey" the source. Sending it to someone over a network or on, for example, flash drives purposely left in parking lots, would seem to be "conveying" it.

The GPL v2 uses the word "distribute" in the same context, which seems to be functionally identical to "convey" in this context.

Dear God, I've figured it out, but... (0)

Anonymous Coward | more than 2 years ago | (#40984057)

It's Cthulhu, he's in our Internet, eating our code!

Beware!

can someone please explain (1, Informative)

v1 (525388) | more than 2 years ago | (#40984221)

why these things are hard to decrypt? They're computer programs. The computer has to be able to decrypt them to run them. So either the computer has the key, doesn't need the key, or the key is going to be delivered to it later.

So I'm assuming the authors sent the payload and will be activating it later when they send the decryption key? Otherwise, this shouldn't be such a big deal to figure out. There's no reason to need to break the encryption if the key is IN the payload or in the malware shell.

The only time where this sort of thing works is in places like the sat boxes, where they've hardcoded the key in a chip that uses its hardware engine to decrypt data. In that case you have to physically get the key from the chip itself with a purpose-built microscope. But that sort of defense isn't possible with a purely-software thing like this. (I read today that's also what the iphone is doing, and I assume other smart-devices like crackberries)

Re:can someone please explain (5, Informative)

bolek_b (246528) | more than 2 years ago | (#40984307)

The trick in this case is that the key is already available at the targeted machine - the virus tries to combine various pairs of %PATH% paths and names from %PROGRAMFILES% and if some combination has an expected checksum, that's the key. To make cryptanalysis a bit more difficult, it seems that the second part of the key is not in plain ASCII. Therefore the "key distribution problem" is nicely solved - if the code runs on targeted system, the key will be easily generated. On any other machine you won't obtain any information about the key.

Re:can someone please explain (5, Interesting)

TheCarp (96830) | more than 2 years ago | (#40984601)

Its a very clever hack indeed. We always think of encryption keys as something that we make up randomly and need to be transmitted.... but this isn't even an unusual style of use.

This is kind of like... taking some shared knwoledge, using it to make a key, then sending the encrypted data to someone, giving them a riddle only they can solve.

"The key is the date we first met, plus the date you left your first job, plus the name of the resteraunt we went to after your mothers funeral".

Except...its based on system configs. I have to wonder with path elements and program files how well balanced they are between identification of the specific machine(s) they want, against the possibility those configs will change before the payload goes off.

Re:can someone please explain (5, Interesting)

bolek_b (246528) | more than 2 years ago | (#40984767)

One of my guesses is that both the PATH element and the Program Files item are linked to a single application. That way, as long as the application is installed, the payload would be decryptable. The name check suggests that the application is some in-house project, probably not publicly released.

But maybe the "trigger" is an application in certain environment. Then the Program File would determine application presence. Then the expected item of PATH could refer to some network share, mapped disk, e.g. T:\Repository\bin. Such combination would be pretty unique and therefore an ideal "trigger", IMHO.

Re:can someone please explain (2)

TheCarp (96830) | more than 2 years ago | (#40985309)

That would make a lot of sense. Of course... while we are speculating... hows this one...

Perhaps there is no payload. The real action is the moles at kaspersky....

"Nope we haven't found it yet.... we have even asked the internet for help. Are you SURE there aren't any more program names/file paths we should be checking against?"

  I would count that as unlikely, given the sophistication, but, its a possibility.

The really neat thing here is that.... the payload could have already gone off. Unless someone figures out the key, the chances of catching it "in the act" is pretty slim.

Re:can someone please explain (1)

sunking2 (521698) | more than 2 years ago | (#40985373)

Really? This is what we consider clever now a days? It seems like a rather obvious way to do things to me.

Re:can someone please explain (-1, Flamebait)

Anonymous Coward | more than 2 years ago | (#40984327)

The fucking article explains this. Read it.

Re:can someone please explain (0, Offtopic)

Dunbal (464142) | more than 2 years ago | (#40984917)

You must be new here.

Re:can someone please explain (1)

Anonymous Coward | more than 2 years ago | (#40984355)

The key is derived from the system configuration and environment. When the program runs on the machine with the target configuration the correct key is derived and the payload is decrypted. Nobody knows what the correct configuration is so the payload has yet to be decrypted.

Re:can someone please explain (0)

Anonymous Coward | more than 2 years ago | (#40984523)

Dion't be silly. "State Level DoJ" != NSA.

Just that your "business as usual law enforcement" cannot break the iphone as easy as they need to to include it in their daily business in finding drug dealers does not mean the world's most advanced math-and-crypto-organisation also could not it.

Maybe they can, maybe they can't - but the statement from the DoJ (even if true) is no indicatior at all for either.

Re:can someone please explain (4, Informative)

jpmorgan (517966) | more than 2 years ago | (#40984381)

The program doesn't have the key, the target computer does! When it runs, it collects various information about the computer's configuration and uses that to generate a possible key. It tries to decrypt its payload with that, and if the decryption works, the payload runs. If the decryption doesn't, then the key was wrong, and it's not the target computer, and the payload doesn't run.

It's a very clever approach, and depending on how specific the target configuration is, we may never see the decrypted payload in the public world.

Re:can someone please explain (2)

Xest (935314) | more than 2 years ago | (#40984407)

I think the answer is in the summary.

Don't quote me on this, but judging from what the summary is saying, the key is derived from a piece or combination of information on the host machine. That is, the key itself could be derived from for example, the currently logged in user, combined with their MAC address, combined with some identifier from the motherboard or whatever.

As such yes, the computer has the key, but you need to know what computer. Presumably you can figure out what the malware is building the key from so you know what information it's extracting from it's host and how it's building a candidate key from that, but you can't figure out the actual key unless your system provides it with the information to generate a candidate key that is actually the correct key. It may be that the malware is reading the logged in user's username and using that as a key such that it only decrypts succesfully if the user is logged in as mahmadinejad or whatever.

It's quite clever really, because it means you can make a targetted virus that only unloads the payload if it detects some parameters that you know about the target user or system (i.e. their e-mail address, and that they use Outlook (e.g. read their e-mail address setting for Outlook from the registry)) and remain harmless for everyone else and as is demonstrated here, no one else even if they find the virus will be able to figure out easily what is actually in the payload.

It sounds like a targetted virus has been uncovered, but all clues as to who or what it is targetting are hidden away in the encrypted payload. It'd be nice to know what the malware is using as the key as that narrows it down somewhat i.e. if it's trying to read something from the registry you know it's targetting Windows PCs which narrows it down to 90% of computers, if it also then tries to combine that with whether the system has a specific piece of software installed (like centrifugre control software ;)) then it narrows it down further and so on, but it's still probably a large search space to find the correct target(s).

Re:can someone please explain (1)

Xiph (723935) | more than 2 years ago | (#40984617)

I think the answer is, that the payload is a command and control utility.
That way, the people who deployed it can use it at any / from any location, which is infected.

It could be used to escalate privileges on the local computer or many more useful things, and would reduce the need to be tied.
Sure similar things have been achieved in different ways, this is just speculation

Re:can someone please explain (0)

Anonymous Coward | more than 2 years ago | (#40984417)

RTFA. the key is made up of the target systems configuration, so only a machine with the target configuration will generate the correct decryption key.
Sounds like its time to wind up a few thousand S3 VMs and brute force it.

Re:can someone please explain (1)

Anonymous Coward | more than 2 years ago | (#40984449)

Security: something you have, something you know, something you are.

So either the computer has the key, doesn't need the key, or the key is going to be delivered to it later.

Or the computer (i.e. target) *is* the key. From the blurb: "targeting a specific machine with specific system configuration". All you need to do is convert "specific system configuration" settings into a key and voila, your target can decrypt while the rest of the world is none the wiser.

Proudly answered without RTFA'ing.

Cracking might be impossible (3, Funny)

cvtan (752695) | more than 2 years ago | (#40984243)

If the DOJ and NSA can't get into an Apple iPhone, what chance is there of cracking this?

Re:Cracking might be impossible (0)

Anonymous Coward | more than 2 years ago | (#40984335)

Everybody's a comedian.

Re:Cracking might be impossible (2, Insightful)

Anonymous Coward | more than 2 years ago | (#40984357)

Pfft. You actually believed that story about the iPhone?

Re:Cracking might be impossible (1)

Anonymous Coward | more than 2 years ago | (#40984635)

Pfft. You actually believed that story about the iPhone?

That's funny and so true.

Burglar to home owner: "Oh God! You're using that latch and string, there's no way I can break into that! Oh jeeze! I''ll have to get a legitimate job!"

Re:Cracking might be impossible (2)

cvtan (752695) | more than 2 years ago | (#40985151)

I read it on Slashdot so it must be true!

Re:Cracking might be impossible (0)

Anonymous Coward | more than 2 years ago | (#40984531)

Kaspersky Lab is not asking the US government for help, rather they are asking the general Internet public for help. The latter might actually be capable of coming up with a workable solution.

Re:Cracking might be impossible (0)

Anonymous Coward | more than 2 years ago | (#40984771)

Also with the history of stuxnet, flame etc the government may also be the ones who released it.At the very least they had a hand in creation of the original code.

Degauss? (3, Funny)

MatrixCubed (583402) | more than 2 years ago | (#40984245)

Clever of the tech world, to obsolete CRT monitors. Perhaps shaking one's head rapidly from side to side would help solve this mystery.

Re:Degauss? (1)

SQLGuru (980662) | more than 2 years ago | (#40984683)

You also have to make that sound: BRrrrrrrrrrdddddddTick.

I've Got It!!! (4, Funny)

MasterOfGoingFaster (922862) | more than 2 years ago | (#40984293)

I just ran the code and something about my system is causing it to decrypt, and it appears be tr***CARRIER LOST***

Re:I've Got It!!! (-1)

cyborg_monkey (150790) | more than 2 years ago | (#40984885)

Wow, those ***CARRIER LOST*** jokes are fucking hilarious!

irc bot author (0, Interesting)

Anonymous Coward | more than 2 years ago | (#40984323)

It looks like validation of one of my first creation irc bot (war bot, for taking over channels, not for spamming people and stealing their CCs).

It was also doing validation, to verify it binary has not been altered using MD5 and some kind of computation of the binary itself.

And then it was loading a userfile (payload), which was ecnypted using system specific key. In my case it was a physical location of a file on a disk (i-node, blocks, etc.. all you could get from file info syscall), nicely md5 hased to get good blowfish key.

The userfile contained list of people (ident@host.com) with their rights, and passwords for their accounts + information about how to link to the botnet...

I am pretty sure here you have the same thing, so. do I get candy as a reward?

Re:irc bot author (1)

Ash-Fox (726320) | more than 2 years ago | (#40985001)

Cool story, bro.

Obligatory (0)

devilsdean (888911) | more than 2 years ago | (#40984385)

"Be sure to drink your Ovaltine."

Re:Obligatory (-1)

Anonymous Coward | more than 2 years ago | (#40984991)

Son of a bitch.

Why ask cryptographers when the key is in there? (0)

hAckz0r (989977) | more than 2 years ago | (#40984403)

The problem as I see it is to figure out how to exercise the code that unlocks the key used to decrypt the payload. Brute force to crack the payload is going about it the hard way. When dealing with criminals, never play by their rules.

The reason the payload exists is so that it can be decrypted and used. Both the algorithm and the key are in there somewhere. The problem is discovering under what conditions it is exercised and halt the process after the decryption but before the key is removed from memory. Timing is the key to success.

Load the code in a hardware virtualization monitoring environement with an emulated CPU clock and let it run. Analyse the code execution and discover the branches not taken and then force it to take each branch the next time around, and watch/trace what it does. If you find ant-debugging protections along that path then you are probably on the right track to recover the key. There is no singular trick in their little-black-bag-of-tricks that can't be worked around. Be persistant and the key will be recovered, and a lot sooner than trying to brute-force decrypt the payload without the key.

Re:Why ask cryptographers when the key is in there (4, Informative)

Xest (935314) | more than 2 years ago | (#40984469)

No, the key isn't in there. The algorithm to generate the key from specific information on the host system is in there, but the key can only be correctly generated from the host system having the right information for which the algorithm can properly derive the correct key.

Re:Why ask cryptographers when the key is in there (1)

hAckz0r (989977) | more than 2 years ago | (#40984725)

Yes, as I said, you exercise the algorithm to produce the key. The key is just 'in the algorithm' that derives the key. The software is quite capable of deriving its own key given the proper host parameters. The examiners can and will know what system the code was taken from, and can collect any parameters from that system that are needed. In a harware virtual environemnt you can inject any host attribute you like, at any time you like, and the code running in it will never know the difference if you take certain steps, like making the CPU clock instruction cycle correct for the given hardware. The malware code will only know what you tell it, so the trick is figuring out what parameters you need to tell it, and that comes from excercising the code as well to see what it tries to access. Locically everything it needs to defeat itself is already in there, except the host parameters, and we just need to be smart enough and persistant enough to figure it out.

Re:Why ask cryptographers when the key is in there (0)

Anonymous Coward | more than 2 years ago | (#40984839)

Yes, that's obvious to every programmer everywhere. But after you know the parameters you still need to bruteforce them, just as if the key generation input was a password. Do you know anything at all about cryptography?

Re:Why ask cryptographers when the key is in there (1)

Baloroth (2370816) | more than 2 years ago | (#40984883)

The examiners can and will know what system the code was taken from, and can collect any parameters from that system that are needed.

No, they can't. They don't know what machines the payload code runs on, and if the target (as is very very likely) was a government system somewhere in the Arab world, they probably never will. In other words, they have no clue what the parameters are for decrypting the payload: if they did, they wouldn't need to issue this challenge, which BTW isn't a brute-force, it's more like a distributed dictionary attack (testing various parameters that might be the target). They found the malware with encrypted payload in the wild, but never in it's decrypted state.

Re:Why ask cryptographers when the key is in there (1)

Ash-Fox (726320) | more than 2 years ago | (#40984975)

They know the system they took it from was not the target, because the parameters don't match. With all due respect, your suggestions have been unhelpful.

Re:Why ask cryptographers when the key is in there (1)

Depili (749436) | more than 2 years ago | (#40984503)

Read the FA :) The key isn't in the package, but is generated by characteristics of the intended target machine, you either need to brute-force it or find out what the target was.

Re:Why ask cryptographers when the key is in there (3, Informative)

cryptizard (2629853) | more than 2 years ago | (#40984507)

This is not at all how it works. Nobody has the key, the key is derived from local configuration values using a cryptographic hash function. Just as your hard drive may be encrypted with a key that is generated from your password, this payload is encrypted with a key that is generated from a very long password which is a combination of specific settings on the machine. If you run it on a machine with the settings exactly right, it will unlock. If you run it on any other machine, it will not and you will get no information about what they key is. Since there are so many possible combinations of settings (particularly it is looking at all the programs in your program files folder in combination with all the directories in your path variable) it is unlikely that people will just stumble across the correct one.

Re:Why ask cryptographers when the key is in there (1)

jpmorgan (517966) | more than 2 years ago | (#40984555)

The key is not in there. It's generated dynamically, based on information pulled from local computer's configuration. The key generating algorithm isn't obfuscated, but it will only generate the correct key on the target computer (or one very similar).

The only way this will be cracked will be by finding a computer with a sufficiently similar configuration (unlikely), or by a herculean feat of cryptanalysis (incredibly unlikely).

Wrong. (2)

gr8_phk (621180) | more than 2 years ago | (#40984573)

The reason the payload exists is so that it can be decrypted and used. Both the algorithm and the key are in there somewhere.

You didn't read carefully. The key is on the target machine and is not part of the attack software.
Dumb old way to do this:
1) Check for certain system configurations.
2) Use some key in the malware to decrypt and run the payload.

New hot way to do this:
1) Use some combination of system configuration to decrypt the payload
2) If that worked, run it.

See that? it hides both the decryption key AND the definition of the system it's meant to attack. Unless you have the target configuration (or can guess it) you can't decrypt the payload or figure out what it's meant to attack. Brilliant.

Re:Why ask cryptographers when the key is in there (1)

tgd (2822) | more than 2 years ago | (#40984665)

Load the code in a hardware virtualization monitoring environement with an emulated CPU clock and let it run. Analyse the code execution and discover the branches not taken and then force it to take each branch the next time around, and watch/trace what it does. If you find ant-debugging protections along that path then you are probably on the right track to recover the key. There is no singular trick in their little-black-bag-of-tricks that can't be worked around. Be persistant and the key will be recovered, and a lot sooner than trying to brute-force decrypt the payload without the key.

Its guys like you being involved insecurity that makes people like the NSA get all warm and fuzzy.

Do you really think you're smarter than people at Kapersky? Or whatever shadowy group created the payload? I'm sure on the offence or defence side of things, no one has ever thought about debuggers.

Really?

Re:Why ask cryptographers when the key is in there (0)

Anonymous Coward | more than 2 years ago | (#40984919)

Hey, don't be so vicious on him. If it had been a simple logical mistake regarding any other programming problem he'd not get so much flak - so why get worked up about it? Not to mention that reverse engineering isn't something most people think about or specialize in.

Re:Why ask cryptographers when the key is in there (0)

Anonymous Coward | more than 2 years ago | (#40985045)

you're seeing it wrong
they are asking for help in reversing a hash, as if that's gonna happen.
and even if there's a reversed hash, its just as likely to be a 'random' collision as anything that can serve as a decrytion key.

what you have there is an idea for bounds on the key, a means of validating possible keys and a lock to try the key on.

can you see it now?

Re:Why ask cryptographers when the key is in there (1)

jimbolauski (882977) | more than 2 years ago | (#40985161)

The problem as I see it is to figure out how to exercise the code that unlocks the key used to decrypt the payload. Brute force to crack the payload is going about it the hard way. When dealing with criminals, never play by their rules.

The reason the payload exists is so that it can be decrypted and used. Both the algorithm and the key are in there somewhere. The problem is discovering under what conditions it is exercised and halt the process after the decryption but before the key is removed from memory. Timing is the key to success.

Load the code in a hardware virtualization monitoring environement with an emulated CPU clock and let it run. Analyse the code execution and discover the branches not taken and then force it to take each branch the next time around, and watch/trace what it does. If you find ant-debugging protections along that path then you are probably on the right track to recover the key. There is no singular trick in their little-black-bag-of-tricks that can't be worked around. Be persistant and the key will be recovered, and a lot sooner than trying to brute-force decrypt the payload without the key.

The algorithm can be know and still does not make it easier to decrypt, the key does not have to be know by the program rather is it used to decrypt the actual code. There are two parts to the code the encrypted and the unencrypted, the unencrypted will use certain settings on the target computer that are unique as the key. The program then decrypts the encrypted part of program, verifies that the decryption was successful using a hash function and comparing it to a different section of the encrypted data, then executes the formerly encrypted payload. At no point does the program verify the key, the hash can be used to verify a successful brute force decryption but the hash will not lead you to a complete decryption. At no time does the program need a copy of the true key to work is simply runs the code through a hash function and compares it.

Re:Why ask cryptographers when the key is in there (1)

nedlohs (1335013) | more than 2 years ago | (#40985179)

Do you always rave about completely unrelated crap? That doesn't apply to this case as not just the article but the summary explain.

Never overlook the obvious (0)

vlm (69642) | more than 2 years ago | (#40984421)

Never overlook the obvious. Want to piss off a small security team? Put a small sample of /dev/urandom into a binary blob and release it. They'll spend all their time trying to decrypt that white noise source and never notice the Really Interesting thing nearby it.

Researchers at Kaspersky Lab ... publishing encrypted sections and hashes

Ha ha they fell for it. The interesting stuff is going to be around or nearby the distractor, not the distractor itself.

This part makes no sense:

They're publishing encrypted sections and hashes in the hope that cryptographers will be able to help them out.

If that happens it'll be a first in the serious crypto field. How do they expect that to happen? This being from a worm or whatever doesn't make it special.

Look I'll give you a baby example.

"13cbffe03010f846f46f123675bfc3c3"

I'll even make it more baby by telling you its a md5 hash and the plaintext is 11 chars of letters and spaces. The ultimate in baby examples and its still utterly hopeless.

P.S. its not a rickroll URL although that would be funnier than hell. The only thing funnier than the worm designers using /dev/random would be embedding a rickroll or a goatse instead of real worm payload.

Re:Never overlook the obvious (2)

jpmorgan (517966) | more than 2 years ago | (#40984511)

Never overlook the obvious. Want to piss off a small security team? Put a small sample of /dev/urandom into a binary blob and release it. They'll spend all their time trying to decrypt that white noise source and never notice the Really Interesting thing nearby it.

That doesn't even make sense. You're suggesting that the author, instead of actually encrypting the payload, is only pretending to, to distract attention from a different unencrypted portion elsewhere? That makes about as much sense as a 'the moon landing was a hoax' conspiracy theory.

Just ignore the moron (1)

Anonymous Coward | more than 2 years ago | (#40984809)

Of course it doesn't make sense, but you're looking at this from a perspective of sanity and rationality, and not that of a mouthbreathing waste of oxygen with the IQ of a braindead petunia.

Remember: no one is as smart as the Conspiracy Theorist. The Conspiracy Theorist alone has the insight to discern signal from noise, and even if what they see is completely harebrained, nonsensical and discredited by others. In fact, being discredited is proof that the Conspiracy Theorist is on to something, because facts and that sort of jargon is Them trying to Cover Things Up. And the more harebrained the better---how else would They hide things from the ignorant masses?

So, yes, the Conspiracy Theorist has determined that the "encrypted" stuff is merely noise to distract from the unencrypted code. Encryption after all can be broken with a few keystrokes (and possibly a blowjob); if it was encrypted it wouldn't actually be all that secure, would it? So, it's the unencrypted stuff to be wary of. Innocuous code that does nothing is the worst: it fools the so-called "experts" and is actually a devious plan for Them to accomplish their true goals.

If all this doesn't make sense, or sounds like a bad movie plot, you're not a Conspiracy Theorist ... or a complete moron.

Re:Never overlook the obvious (1)

cryptizard (2629853) | more than 2 years ago | (#40984565)

Agreed, I don't see how they think cryptographers could have some kind of magic to break this. The designers of Gauss did everything right, salting and stretching their hashes, so there is not much we can do but try and stumble across that correct configuration.

Re:Never overlook the obvious (1)

djdanlib (732853) | more than 2 years ago | (#40984639)

Perhaps the security team KNOWS this. And perhaps the authors knew that they would know that.

Reminds me of a scenario played out in a movie. "Clearly, I cannot drink from the cup in front of you."

Re:Never overlook the obvious (0)

Anonymous Coward | more than 2 years ago | (#40984689)

There's already a distraction in Gauss. what do you think the font is?

Re:Never overlook the obvious (1)

kav2k (1545689) | more than 2 years ago | (#40984745)

Obviously, you haven't read the original article here [securelist.com] .

Just embedding a binary blob doesn't help. Having a complex routine to decrypt it, verify the extracted data, and run it if verification succeeds is another story.

Though, arguably, you CAN put such a loader and throw in random data just for trolling.

Re:Never overlook the obvious (1)

vlm (69642) | more than 2 years ago | (#40985277)

Though, arguably, you CAN put such a loader and throw in random data just for trolling.

Exactly.

Re:Never overlook the obvious (1)

Ragnulf (2708103) | more than 2 years ago | (#40985409)

That makes absolutely no sense. Using malware for targeted attacks is a frail enough scheme as it is, why would anyone complicate it further?

free jobs (-1)

Anonymous Coward | more than 2 years ago | (#40984441)

what Mike implied I'm amazed that you can profit $6543 in one month on the internet. have you read this webpage makecash16.com

From the Article (5, Informative)

cryptizard (2629853) | more than 2 years ago | (#40984461)

According to Kaspersky, the way it works is:

1) Enumerate all directories in the computers PATH variable
2) Enumerate all files in the %PROGRAMFILES% directory whose file name starts with a non-latin-alphabet unicode character (i.e. arabic)
3) Hash every pair from the previous two lists with MD5 and check against a known hash

If the hashes match, then it has found the correct configuration. This means it is looking for a computer with a specific directory or file in the %PROGRAMFILES% directory, in combination with a specific directory in its path variable. This hash is salted and stretched so they obviously knew what they were doing.

Once it knows it has the correct configuration, it rehashes that pair with a different salt to get an RC4 encryption key which unlocks the payload. Different salts are used in the validation and decryption stages so that the validation hash (which is stored in the binary and known to everybody) does not give any information about the target configuration or the encryption key. Given the number of possible combinations of known files that could be in %PROGRAMFILES% and directories that could be in %PATH%, combined with the fact that the target configuration is likely one that is not publicly known, it will be very difficult to break this unless the targeted party comes forth.

Re:From the Article (3, Interesting)

vlm (69642) | more than 2 years ago | (#40984567)

it will be very difficult to break this unless the targeted party comes forth.

Difficult to break it legally, you mean... All you need do is release a new virus/worm that only does the first hash step, then if by some miracle a match is found the victim gets a popup "You won, to collect your winnings please contact contest@nsa.gov" or whatever.

As sort of a running joke / meme I can imagine black hats doing this purely for fun. The IRC channel for the bot net gets spammed with the PATH and PROGRAMFILES once it finds a match.

Might also make a hilarious "antivirus update" as part of perfectly legit anti-virus suites. Run this test to see if you're vulnerable to the "whatever its called" targeted worm.

Re:From the Article (4, Insightful)

medcalf (68293) | more than 2 years ago | (#40984851)

How large is the universe of Windows programs not named in Latin characters? I have to think it's in the low millions at most, and probably less than that. Maybe the way to do this is to try the paths and filenames of those programs, and see if you get a match. As a first try at reducing the things you have to check, you could eliminate anything widely used, since this is likely targeted at a rare configuration. I'd start by looking at SCADA control programs, personally, because there's a good chance that this is targeted at industrial control systems, based on the last few weaponized software bits that have been found (stuxnet, et al).

Re:From the Article (0)

Anonymous Coward | more than 2 years ago | (#40985101)

Even in a small "universe" this may be impossible to find. It could be custom software that is not distrubuted comercially. So after a relatively "quick" check you are in a world of pain trying to test all posible combination of the UTF character set. In addion the software has to be installed in a specific context as the hash is made from the file name and what appears to be unrelated string in the path variable.

Re:From the Article (1)

Jeremy Erwin (2054) | more than 2 years ago | (#40985395)

Usually, program names, even in non english languages, are non random-- so this does reduce the search space.

Re:From the Article (3, Interesting)

cryptizard (2629853) | more than 2 years ago | (#40985119)

The problem is that the specific program they are targeting is likely not known publicly. It could be a secret program developed by another country, which our intelligence services happen to know about through espionage but the public sector would not.

set of programs have to match (1)

schlachter (862210) | more than 2 years ago | (#40985361)

I'm assuming that the set of programs names have to match; it's not sufficient for the system to contain a single program of interest. So then you have to look at all the possible subsets of the programs available...a much larger space.

Re:From the Article (1)

pmathew (1597155) | more than 2 years ago | (#40984861)

Hmm .. My guess is it is targeted at an enterprise than an individual .. because if an individual install something the payload doesn't see light .. However in an enterprise they tend to preload their new machines with an OS image with a common utility set it may work as machines are always added as part of hiring or upgrade .. May be we just need to test against the few machines in that obscure "nuke facility" in "wadiya" .. :)

Easy to defend against (1)

Dan East (318230) | more than 2 years ago | (#40984875)

This would be trivial to defend against. Simply add an empty directory (starting with a non-latin-alphabet character) to Program Files, or to the PATH variable. However, if this targets the control computers of industrial machines (as it most certainly does) then all of that is probably static and locked down.

I'm slightly surprised that the signature involves non-latin directory names for programs. Stuxnet targeted Siemens equipment, and it is very, very likely that the directory names their control software resides in are in English, even if the software is localized for some other language. So this seems to be targeting home grown software / hardware this time around.

The next question is how did the author know *exactly* what the PATH and program files folders are configured on the target machine. That's the work of spies and moles. Someone probably stuck a USB drive into a target machine, which did a quick scan to grab the necessary info. That could be done in just a few seconds.

This configuration this software targets could be so extremely specific that there may only be a handful of computers in the world running the specific industrial control software the payload is designed to destroy.

Re:Easy to defend against (1)

Anonymous Coward | more than 2 years ago | (#40984967)

It tries ALL combinations of path parts and program files directories. Adding stuff to your program files or path doesn't work, only removing one of the two parts of the pair would work.

So if the path is c:\a\bin;c:\b\bin and in the program files there are the directories "alpha and "beta" and these two directories both start with a non-latin character, it tests the following combinations:

c:\a\bin - alpha
c:\a\bin - beta
c:\b\bin - alpha
c:\b\bin - beta

Re:Easy to defend against (1)

Anonymous Coward | more than 2 years ago | (#40985075)

From what I am reading.. Adding an empty path wont help.. It takes Every individual Item in the path, and every individual directory in %PROGRAMFILES%.. Pairs them (so if you have 10 directories in your path statement and 15 directories in %PROGRAMFILES% it would look at all 150 Pairs. then "Hash every pair from the previous two lists with MD5 and check against a known hash" when it finds one that matches, it performs a second function on that pair to generate the Key.

-J

Re:From the Article (0)

Anonymous Coward | more than 2 years ago | (#40984981)

"a non-latin-alphabet unicode character (i.e. arabic)"

or maybe Chinese.

Re:From the Article (0)

Anonymous Coward | more than 2 years ago | (#40985053)

It's me! I'm the target!

I confess!

Complete noob question (1)

Rastl (955935) | more than 2 years ago | (#40984543)

If the malware is looking for a specific MD5 hash why not look for the possible variations on that instead of the source of the hash? Once that's identified then the research can go both ways - looking for the source and looking for the next hash.

I freely admit I've never done any cryptography but from a process perspective this seems like a reasonable way to approach the problem.

I look forward to hearing why this can't work. Honestly I do. It will help my understanding of how these things are picked apart by the experts.

Re:Complete noob question (1)

cryptizard (2629853) | more than 2 years ago | (#40984743)

Not sure what you mean by variations. The problem is that hash functions are one-way or "preimage resistant", meaning that if they are secure then you cannot get any information about the input from only the output. Additionally, they have an avalanche property where small changes in the input produce large changes in the output. This makes it difficult to analyze hashes by tweaking the input piece by piece until you get the desired hash.

I could be confused about what you are suggesting, maybe you could clarify?

Re:Complete noob question (0)

Anonymous Coward | more than 2 years ago | (#40984757)

your question is unintelligible.

Re:Complete noob question (1)

Ash-Fox (726320) | more than 2 years ago | (#40984873)

Because you can't. You either get the exact hash right or fail. It's not like in the "hacker" movies, where you see each character 'unlock' individually while 'hacking'.

Alternatively, there are side channel attacks that might be feasable if there was some depth to work with, but from what I can see, there isn't any here.

Re:Complete noob question (0)

Anonymous Coward | more than 2 years ago | (#40985039)

Brute force RC4 decrypting process illustrated:

Pick a number between 1 and 2^128... Nope, try again.
Pick a number between 1 and 2^128 - 1... Nope, try again.
Pick a number between 1 and 2^128 - 2... Nope, try again. ...
Pick a number between 1 and 2^128 - 2^64... On average, you might have it by now.

Okay, now count (simpler than picking, and checking) to 2^64, AS FAST AS YOU CAN (don't hold your breath, and maybe get your affairs in order first).

Warhead? (4, Insightful)

gr8_phk (621180) | more than 2 years ago | (#40984607)

Since when did we start calling a payload a warhead, especially when it hasn't been decrypted?

Re:Warhead? (4, Insightful)

Loughla (2531696) | more than 2 years ago | (#40984989)

When we started the propaganda about how evil technology and evil hackers are ruining the world.

Re:Warhead? (0)

Anonymous Coward | more than 2 years ago | (#40985153)

Since when did we start calling a payload a warhead, especially when it hasn't been decrypted?

About the same time that anyone with a gun and mental condition is considered to be a 'terrorist'. And, entertainingly, just around the time the 'Transportation Safety Administration' was conceived.

Holy Hyperbolic Homonyms; Batman! (0)

Anonymous Coward | more than 2 years ago | (#40984751)

Could we get past the hyperbolic exaggerations when referring to computer code; please?

cracking an encrypted warhead

Really?

Another aspect of this mystery (2)

bolek_b (246528) | more than 2 years ago | (#40984893)

By the way, TFA says that the virus even installs some font. This unusual step confuses me quite a lot. Is it for some kind of "exposed but not obvious" document watermarking. Or is it preparation for some future infection vector? Questions :-(

Does somebody know whether there is that font ("Palida Narrow") available?

Re:Another aspect of this mystery (5, Informative)

ledow (319597) | more than 2 years ago | (#40985051)

Google it.

Last time I did, it's basically believed to be a vector for detecting infection by simply making a target navigate to a web page that tries to load the font. If it's there, you can tell the PC has the font and (therefore) the infection. If it's not, it just gets substituted and you can tell from the CSS etc. what's happened.

Probably a way for the author to see if their target machine actually ended up getting infected or not.

Re:Another aspect of this mystery (2)

bolek_b (246528) | more than 2 years ago | (#40985261)

Pity. I was hoping that this would be a clever part of systemic offensive. Like forcing laser printer to release deadly toner fumes by downloading evil curves of this font. Or making its kerning so bad that the users would collapse with severe headaches.

Judging from the infection vector (i.e. USB sticks), I suspect that the targets are off-line, or at least heavily firewalled. Mind you, the target is most probably some military facility, likely in Iran. I don't think navigating to a non-white-listed web page wouldn't raise alarm, from the virus author's point of view an unnecessary complication.

Re:Another aspect of this mystery (0)

Anonymous Coward | more than 2 years ago | (#40985201)

van eck friendly font?

Fewer targets than keys (0)

Anonymous Coward | more than 2 years ago | (#40984913)

Looks like they have narrowed the possible keys quite a bit.

Simulating the target in a virtual platform and running the combinations might be easier than attempting to decrypt the key.

Intercept the system calls looking for parameters and loop them over and over again.

The goal isn't necessarily to decipher the key as it is to get the payload.

If it were to get the key, I guess that would be more about finding the target. that would scare me.

Who ever it is intended for, even if its a test flight should reflect the system that created it and you would be able to use the key to track down the source.

I don't think I would want to have that information. or tell anyone that i had it.

Naive request? (1)

Framboise (521772) | more than 2 years ago | (#40985037)

Of course confirmed world class cryptographers might think twice before showing what they can do, especially if they are hired by national labs to do precisely this.

Kaspersky Lab's request might also be an easy cover to discover new
talents in the field.

 

Program name (2)

jones_supa (887896) | more than 2 years ago | (#40985141)

Notice how in the article it says that the code wants to find a program name with the first letter being over 0x007A (Unicode ‘z’). What possibilities could there be?

Why can't Kaspersky just ask for infected machine? (2)

MasaMuneCyrus (779918) | more than 2 years ago | (#40985291)

Couldn't Kaspersky Labs just post a Gauss detection tool or instructions to determine if your computer has been compromised, then just ask people/companies with infected machines to come forward and contact them? I'm sure the people who Gauss is targeting are probably paranoid of CIA and Mossad plots against them, but if they're infected with Gauss, they probably are already a victim of a CIA or Mossad plot to get them. They're already screwed, so it certainly couldn't hurt much more to trust Kaspersky.

easy (1)

fredan (54788) | more than 2 years ago | (#40985343)

hunter2
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?