Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Encryption

Researchers Seek Help Cracking Gauss Mystery Payload 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."
This discussion has been archived. No new comments can be posted.

Researchers Seek Help Cracking Gauss Mystery Payload

Comments Filter:
  • by v1 ( 525388 ) on Tuesday August 14, 2012 @10:17AM (#40984221) Homepage Journal

    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)

  • by bolek_b ( 246528 ) on Tuesday August 14, 2012 @10:24AM (#40984307) Homepage
    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.
  • by jpmorgan ( 517966 ) on Tuesday August 14, 2012 @10:29AM (#40984381) Homepage

    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.

  • From the Article (Score:5, Informative)

    by cryptizard ( 2629853 ) on Tuesday August 14, 2012 @10:35AM (#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.
  • by Xest ( 935314 ) on Tuesday August 14, 2012 @10:36AM (#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.

  • by cryptizard ( 2629853 ) on Tuesday August 14, 2012 @10:39AM (#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.
  • by tgd ( 2822 ) on Tuesday August 14, 2012 @10:47AM (#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.

  • by ledow ( 319597 ) on Tuesday August 14, 2012 @11:23AM (#40985051) Homepage

    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.

All seems condemned in the long run to approximate a state akin to Gaussian noise. -- James Martin

Working...