English
The Internet threat alert status is currently normal. At present, no major epidemics or other serious incidents have been recorded by Kaspersky Lab’s monitoring service. Internet threat level: 1

The Mystery of the Encrypted Gauss Payload

GReAT
Kaspersky Lab Expert
Posted August 14, 13:00  GMT
Tags: Data Encryption, Cyber espionage, Gauss
0.9
 

There are many remaining mysteries in the Gauss and Flame stories. For instance, how do people get infected with the malware? Or, what is the purpose of the uniquely named “Palida Narrow” font that Gauss installs?

Perhaps the most interesting mystery is Gauss’ encrypted warhead. Gauss contains a module named “Godel” that features an encrypted payload. The malware tries to decrypt this payload using several strings from the system and, upon success, executes it. Despite our best efforts, we were unable to break the encryption. So today we are presenting all the available information about the payload in the hope that someone can find a solution and unlock its secrets. We are asking anyone interested in cryptology and mathematics to join us in solving the mystery and extracting the hidden payload.

The containers

Infected USB sticks have two files that contain several encrypted sections. Named “System32.dat” and “System32.bin”, they are 32-bit and 64-bit versions of the same code. These files are loaded from infected drives using the well-known LNK exploit introduced by Stuxnet. Their primary goal is to extract a lot of information about the victim system and write it back to a file on the drive named “.thumbs.db”. Several known versions of the files contain three encrypted sections (one code section, two data sections).

The decryption key for these sections is generated dynamically and depends on the features of the victim system, preventing anyone except the designated target(s) from extracting the contents of the sections.

By the way, the 64-bit version of the module has some debug information left in it. The module contains debug assertion strings and names of the modules:

.\loader.cpp
NULL != encSection
Path
NULL != pathVar && curPos < pathVarSize
NULL != progFilesDirs && curPos < progFilesDirsSize
NULL != isExpected
NULL != key
(NULL != result) && (NULL !=str1) && (NULL != str2)
.\encryption_funcs.cpp

The data

The mysterious encrypted data is stored in three sections:

The files also contain an encrypted resource “100” that seems to be the actual payload, given the relatively small size of the encrypted sections. It is most likely that the section “.exsdat” contains the code for decrypting the resource and executing its contents.

The algorithm

The code that decrypts the sections is very complex compared to any regular routine we usually find in malware. Here is a brief description of the algorithm:

Validation

1. Make a list of all entries from GetEnvironmentVariableW(“Path”), split by separator “;”
2. Append the list with all entries returned by FindFirstFileW / FindNextFileW by mask “%PROGRAMFILES%\*”, where cFileName[0] > 0x007A (UNICODE ‘z’)

Note: in essence, this means the specific program which is installed in “%PROGRAMFILES%” has a name which starts either with a special char such as “~”, as in our example, or uses an UNICODE special char table, such as Arabic or Hebrew, where all chars are higher than 0x007A.

3. Make all possible pairs from the entries of the resulting list.
4. For each pair, append the first hard-coded 16-byte salt and calculate MD5 hash.

Example of the string pair, second string starting from “~dir” and first salt

5. Calculate MD5 hash from the hash ( i.e. hash = md5(hash) ), 10000 times.
6. Compare if the MD5 hash matches the hard-coded value. If not, then exit.

Decryption

The sections are decrypted in the following order: .exsdat, .exrdat, .exdat

1. Use the PATH/PROGRAMFILES pair that was used to generate the expected MD5 hash in the validation code above.
2. Append the pair with the second hard-coded 16-byte salt and bytes 0x15, 0x00

Example of the string pair, second string starting from “~dir” and first salt

3. Calculate MD5 hash from the resulting buffer.
4. Calculate MD5 hash from the hash ( i.e. hash = md5(hash) ), 10000 times.
5. Derive the RC4 key from the resulting hash using WinAPI’s CryptDeriveKey(hProv, CALG_RC4, hBaseData, 0, &hKey).
6. Decrypt the section (RC4), treating its first DWORD as the length of the buffer to decrypt and encrypted buffer starting at offset 4 of the section.
7. Compare DWORDs in the decrypted buffer at positions 0 or 7 with magic value “0x20332137”. Proceed only if any of the DWORDs match.
8. Increase the last WORD in the pair+salt buffer (the one initially set to 0x0015) by 1.
9. Decrypt another section, goto 3.

After all the sections are decrypted: call the function at the beginning of the .exsdat section.

Sample data for validating the algorithm:

The string pair is created by concatenating the strings. The strings and the salt buffer are not separated by any character.

Sample test Strings, Unicode (without quotes):

  • “C:\Documents and Settings\john\Local Settings\Application Data\Google\Chrome\Application”
  • “~dir1”

First salt, hex dump : 97 48 6C AA 22 5F E8 77 C0 35 CC 03 73 23 6D 51
MD5 at validation step 6: 76405ce7f4e75e352c1cd4d9aeb6be41
Second salt, hex dump : BB 49 4E 77 F9 25 EE C0 3B 89 FC ED C2 22 4A 21
MD5 at decryption step 5: 00916031b3e9513044436ee42b6aa273

Join the quest

We have tried millions of combinations of known names in %PROGRAMFILES% and Path, without success. The check for the first character of the folder in %PROGRAMFILES% indicates that the attackers are looking for a very specific program with the name written in an extended character set, such as Arabic or Hebrew, or one that starts with a special symbol such as “~”.

Of course, it is obvious that it is not feasible to break the encryption with a simple brute-force attack. We are asking anyone interested in breaking the code and figuring out the mysterious payload to join us.

The resource section is big enough to contain a Stuxnet-like SCADA targeted attack code and all the precautions used by the authors indicate that the target is indeed high profile.

We are providing the first 32 bytes of encrypted data and hashes from known variants of the modules. If you are a world class cryptographer or if you can help us with decrypting them, please contact us by e-mail: theflame@kaspersky.com.

Source data

We are providing up to 32 bytes from the beginning of each encrypted section, skipping the DWORD that contains the length of the encrypted buffer. Please contact us by e-mail theflame@kaspersky.com if you need more encrypted data.

Sample 56e4fb972828fafbbdc11158a1b5fa72
Salt 1 97 48 6C AA 22 5F E8 77 C0 35 CC 03 73 23 6D 51
Reference MD5 758EA09A147DCBCAD6BD558BE30774DE
Salt 2 BB 49 4E 77 F9 25 EE C0 3B 89 FC ED C2 22 4A 21
Exsdat 4C CC BA E2 E0 BA 2E 44 C7 60 17 9A 72 F4 2F 27 DD FD DB 11 03 94 E3 4B 0A 16 66 F3 36 97 6C D8
Exrdat C9 27 BE 67 4D 3B 39 36 AB 14 44 32 88 60 7A 64 B0 92 9B 3A A1 5B C5 21 A7 6E 09 0C F8 71 84 87
Exdat B8 EB 6D 61 2B 4F 70 65 75 A2 1C 03 1C DF 26 2F

Sample 695056ffacef1fdaa326d7c8bb0f88ba
Salt 1 6E E3 47 2C 06 A5 C8 59 BD 16 42 D1 D4 F5 BB 3E
Reference MD5 EB2F172398261ED94C8D05216650919B
Salt 2 8F 42 B5 87 E8 9A B2 32 C8 1C 1A EC B5 2D 55 19
Exsdat CE 31 D0 5D 7D CB 57 9A 83 06 09 8D 42 2B 44 34 24 13 B2 39 22 48 8F F3 76 E5 9C DA 87 8F BC 42
Exrdat 50 1F F8 BA 18 1B 3E 36 23 9D 95 DC 5A 07 E4 EC 76 38 78 79 BA 84 A5 4E 24 BA 0E 27 94 63 F7 3D
Exdat 9D 5B B8 3B B2 17 00 DC 76 81 1D 4E 54 80 9B 31

Sample 089d45e4c3bb60388211aa669deab26a
Salt 1 0E A5 01 D1 24 71 CD CD 0E 9E AC 6E 48 5A F9 32
Reference MD5 52DD4D6B792D84C422E6A08E4272ACB8
Salt 2 38 F9 A6 5B 82 08 E7 61 1D 10 73 53 50 BC B4 F0
Exsdat D3 CA 9D 9F 87 FB 25 43 7E C6 57 7C D9 06 10 8D D2 5B B2 88 18 6E FD B4 C4 30 12 2E 1E EC E0 64
Exrdat B4 43 8F B8 0A 67 7D 88 C1 CD F3 E8 D9 61 1B E9 5A 8A 41 16 8B 8A 18 AD 25 5A 81 87 8F 8D 1A 40
Exdat F6 C9 81 C9 86 27 16 0C B7 33 93 AB 3E 71 5B E2

Sample 8d90e3c68030fbb91ad5b920d5e17b32
Salt 1 C3 23 4D 51 5D 52 A5 8E 81 46 FA 8A 6D 93 DF 7D
Reference MD5 53B3FAEA53CC1B90AA2C5FCF831EF9E2
Salt 2 21 9D 04 35 7B 96 74 53 B0 9C CD 7F 2F E6 63 AA
Exsdat AB 01 6A 8E 42 F0 F2 92 1D F1 4A 42 01 63 72 78 D6 F7 A5 0C 54 37 21 2C B8 59 6A D0 7E 68 19 2D
Exrdat 6C 2D D7 E4 F6 08 15 C0 69 D9 9E FF EA 68 63 4F 56 59 DA 28 E5 2E A1 EF 21 FB F9 2B C2 BC E7 CE
Exdat 55 A7 F3 93 E0 AF 5B 7E 17 22 7E 82 8A 6F 25 21 3D 64 D7 E8


163 comments

Oldest first
Threaded view
 

Hans Adams

2012 Aug 14, 20:03
0
 

Questions arose! About character sets.


"...
1. Make a list of all entries from GetEnvironmentPathW(“Path”), split by separator “;”
2. Append the list with all entries returned by FindFirstFileW / FindNextFileW by mask “%PROGRAMFILES%\*”, where cFileName[0] > 0x007A (UNICODE ‘z’)

Note: in essence, this means the specific program which is installed in “%PROGRAMFILES%” has a name which starts either with a special char such as “~”, as in our example, or uses an UNICODE special char table, such as Arabic or Hebrew, where all chars are higher than 0x007A.
..."
?????

Does this not mean, that the names must start with a character outside the US-ASCII character set BUT including {}|~?

Now,

-1) if it is an ISO European character set (8Bit), it would include ALL European "Sonderzeichen", including ÄÖÜäöü Â Á À and so on, including the whole Cyrillic and Keltic char set...

-) (Simplified) Arabic is encoded in ISO8859-6
-) (Simplified) Hebrew is encoded in ISO8859-8

If the character set is indeed UTF8, everything from above holds. For heaven's sake nothing indicates, that the file names have to start with an Arabic or Hebrew character.

HA

Edited by adamsh, 2012 Aug 14, 20:30

Reply    

mihi

2012 Aug 14, 22:12
0
 

Re: Questions arose! About character sets.

The FindFileFirstW function (like most other Winapi functions ending with W) will return a UTF-16 encoded string as a wchar* (pointer to a 16-bit character) Therefore, it will match any Unicode characters larger than U+007A (including those that are represented by two byte surrogate pairs). Yes, in fact, this includes ÄÖÜÁá and so on, and Cyrillic and Keltic and so on, but what exactly is the difference (for American people) between those scripts and Hebrew or Arabic or Chinese or Devanagari or anything else that is not Latin?

To put it differently, it just means it does not use plain old Latin characters A-Z as first character. And it does not even need to be a letter, something like ® (although more likely as last letter) would work too.

Reply    

Hans Adams

2012 Aug 14, 22:44
0
 

Re: Re: Questions arose! About character sets.


{}|~ are above 7a, but below 7f ;->

and there are more than enough files starting with "{" and "~"... How about:
"/cygdrive/c/ProgramData/Kaspersky Lab/~PRCustomProps#2d2.dat" and
"/cygdrive/c/ProgramData/Microsoft/Microsoft Antimalware/Definition Updates/{03892A1F-D13E-4405-BCF4-D3CD039720F9}"

There is indeed absolutely no need even to assume an extended character set. (A)

"but what exactly is the difference (for American people) between those scripts and Hebrew or Arabic or Chinese or Devanagari or anything else that is not Latin? ..."

Simple: These may be genuine French or German or Polish or Russian or ... program names. (B)

From (A) and (B): There is no reason which allows to focus search of names on Middle East.

best, HA

BTW: EPIC Fail!
'The check for the first character of the folder in %PROGRAMFILES% indicates that the attackers are looking for a very specific program with the name written in an extended character set, such as Arabic or Hebrew, or one that starts with a special symbol such as “~”.'

Edited by adamsh, 2012 Aug 15, 10:01

Reply    

Donkey

2012 Aug 15, 03:08
1
 

Re: Re: Re: Questions arose! About character sets.

this sohuld be easy, it looks in the program files dir for a file/folder that start with a higher ASCI value.

Well simply, compare the program files dir of infected machines. If it is no longer there, then take a low level look at the disk. >> ! >> Note also that not all computers are infected in those countries, so there must be potential victims who have this folder/file name.. on their system, you only need a viruss canner to report the folder/file names who might be candidates and collect them.

I think you will solve it fast this way, faster then trying to decrypting it.

once you colected the name, you debug the virus.

Reply    

lszel

2012 Aug 15, 16:22
0
 

Re: Questions arose! About character sets.

Is it possible to try emulate the positive answer of the OS meanwhile the code is running? Maybe is it possible to create an extension for windows to answer true value for all search inside the %PROGRAMFILES%

Reply    

aNaBrUoÃiGeL

2012 Aug 16, 06:25
0
 

Re: Questions arose! About character sets.

CONSEGUI DECIFRAR ESSE CÓDIGO !
Por mais incrível que possa parecer, é uma criptografia fácil de ser descoberta. O mais surpreendente nas longas pesquisas e testes que realizei é: Já que eles disponibilizaram poucos dados que pesquisamo, tem algo...
Comecei a ver que muitos se perdiam com a falta de informações precisam ou faltando, estranho!?!?!
Claro que não, não foi descuido deles, com uma dica do criador percebi que se tratava de uma isca pra chagar à pessoa que o programou. Conclusão, o interesse da Kaspersky, não é saber como o programa funciona, por que eles já sabem, eles querem mesmo é saber quem anda usando esse tipo de linguagem pouco convencional....
Com certeza isso despertou interesses para chegar ao programador em pessoa..

Reply    

Michael_Mike

2012 Aug 16, 09:55
0
 

Re: Re: Questions arose! About character sets.

(for what google translate make me understood)
If the creators of that virus will come and ring at the door, then they are stupid, and incompetent. They would have all interest to ask a bonus for the missing fame and shut up.

For the unconventional language, I suppose you are talking of Lua used in flame? Someone have already said that any good software engineer could learn a programming language in a few weeks. Isn't gauss written all in C++?

(edit)
Beside, my modest theory of choosing a potentially broken md5 for generating an rc-4 key hint me that they opted to compromise the least innovation possible, a good enough solution. Opting for an all new hash algorithm with a brand new encryption algorithm -lets say they are derived of SHA-2 and AES- the effort to find a weakness is going to be much, much greater, and significantly require more time, by supposing that there is no fundamental flaw in the algorithm; on the attacker side it induce a problem of cost of development and justification of needed features, unless it was funded with a blank check.

So it yield some theory:
-Doing something that anybody with a good understanding of cryptography could do. So it imply some deniability, though very limited since we all know it's state sponsored.
-Using it to probe the cryptanalysis capability of the enemy (whoever it is). If yes then create a much bigger nightmare.
-Infecting ourself in order to provide deniability? If the attacker have been able to successfully infect a specific geographic region, they why trying to attack both the liban and Israel with the same virus?

Edited by Michael_Mike, 2012 Aug 16, 10:18

Reply    

Hans Adams

2012 Aug 14, 20:17
0
 

Questions arose! Matches or Cartesian Product.

"Make all possible pairs from the entries of the resulting list."

Do you mean

1) to calculate the Cartesian product of both the lists,

This gives a list all possible paths to a specific executable files, whose names start with a character above 0x7a... This would be quite unspecific....

2) just to match all the members of the lists against each other? Which means "paths" against executable files, whose
names start with a character above 0x7a....

Second point would indicate, that those are searching for specific valid executable files (including some configuration), located at exactly one point in directory hierarchy , which are actually run.

HA

Edited by adamsh, 2012 Aug 14, 22:53

Reply    

The Cornishman

2012 Aug 15, 00:26
-1
 

Re: Questions arose! Matches or Cartesian Product.

Adam: You've restricted yourself to executable files, but my understanding is that FindFirstFileW / FindNextFileW return both directory and file names. A _directory_ with a cFilename[0] > 0x007a will also be in The Listing.

GReATeam: I too would like clarification: are we looking at PATH x PROGRAMFILES_CONTENTS or really at all possible pairs, i.e. LISTING x LISTING ?

Reply    

Hans Adams

2012 Aug 15, 01:14
0
 

Re: Re: Questions arose! Matches or Cartesian Product.

"Re: Questions arose! Matches or Cartesian Product.

Adam: You've restricted yourself to executable files, but my
"

Right. BUT executable files are not characterized by their extensions..... Executable means, that --- at least one --- interpreter is available for the contents of the file.

"
understanding is that FindFirstFileW / FindNextFileW return both directory and file names. A _directory_ with a
"

http://msdn.microsoft.com/en-us/library/windows/desktop/aa365740%28v=vs.85%29.aspx tells you

"TCHAR cFileName[MAX_PATH];"
"cFileName The name of the file."

"cFilename[0] > 0x007a will also be in The Listing."

No, it returns the file name.... according to msdn...

best, HA

Reply    

The Cornishman

2012 Aug 15, 01:36
0
 

Files only, or directories too

OK, I was relying on http://msdn.microsoft.com/en-us/library/windows/desktop/aa364418%28v=vs.85%29.aspx, which describes FindFirstFile by saying "Searches a directory for a file OR SUBDIRECTORY with a name that matches a specific name (or partial name if wildcards are used)" [emphasis added]. Even in the given examples, the %PROGRAMFILES% element is called ~dir

Reply    

Igor Soumenkov

2012 Aug 15, 15:29
1
 

Re: Files only, or directories too

Both files and directories are found by FindFirst/FindNext, no recursion.

Reply    

Igor Soumenkov

2012 Aug 15, 15:29
0
 

Re: Questions arose! Matches or Cartesian Product.

The pairs are actually a Cartesian square of the complete list of gathered strings.

Reply    

Hans Adams

2012 Aug 14, 20:27
0
 

Questions arose! Limited scope....

"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 the paths to specific programs actually used. 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?

asks HA

Edited by adamsh, 2012 Aug 14, 21:22

Reply    

angry.toopse

2012 Aug 14, 21:23
0
 

Chinese Lottery

I'd say this is a very good problem to apply the chinese lottery method to.
Either legally by providing a testcase application and convincing as many people as possible to run it on their very systems or illegally by another piece of replicating code that infects other systems and checks for the same condition.
Have this as a download-able application, promote it, put a serious bounty for those that report a match and you are in business.Heck,this code could be even integrated in antiviruses(from all companies eventually) and tested "for free" on a huge number of test machines. Of course, if the target is so high profile they might never call back to report their finding :) But on the other side the target might be very happy to learn that they are being watched .

Reply    

Hans Adams

2012 Aug 14, 21:37
0
 

Re: Chinese Lottery. NO!


NO! The code searches for executables, whose names start with a character above 0x7a.... Which windows installation has such programs?

And the code expects those programs at few or many places in the hierarchy.

Best approach would be to identify such programs (and systems)....

best, HA

Reply    

devmasterjpc

2012 Aug 14, 23:36
0
 

Re: Chinese Lottery

I don't think that would work given that the main application checks for typical AntiVirus/System/network tools and exits (and deletes itself?) if found. I could be mixing up malwares but I'm pretty sure that's the case here.

My understanding is that Kaspersky labs has a massive database of file names that are all known/unknown. I'd assume they also have the paths where these files were located as part of that db. I'm not sure how extensive this DB is, if it's only things that were sent to them as suspected viruses or if it's for every application on the mkt, but if they were using that massive db to iterate over the known paths (having filename > 0x007A) to get values to plug into the hash generation and still couldn't find a match then the file/path is probably something nobody else would have anyway (that's making certain assumptions about their file db).

Could it be a path created by another part of the malware (or a separate payload that was fetched from a server to decrypt then deleted)?

Reply    

angry.toopse

2012 Aug 15, 01:05
0
 

Re: Re: Chinese Lottery

The point is not to run the malware itself, but a custom made (and safe) piece of code that replicates the decoding algorithm on as many hosts as possible - the algorithm being already known.

With enough luck - and exposure - some will sooner or later run this code (let's call it "the test") on one of the machines that were actually targeted by the original malware. As the test replicates the algorithm, if ran on a targeted machine, the algorithm will correctly decode the payload. Now, if the target is high profile, even if they run the test and find out that they were the original target of the malware, they may never announce the world about it. You can be sneaky and insert a callback into the test that makes a simple call home announcing the success, but this quite another discussion. So the point in this case is not to have enough machines to run the decoding algorithm by sheer distributed brute force, but rather to try with the help of chance to have one of the targeted machines run such a test. On a targeted machine the conditions will be right so the resulting decoding key actually decodes the payload (or at least a part of it enough to validate the successful decoding )

Reply    

Donkey

2012 Aug 15, 03:23
0
 

Re: Re: Chinese Lottery

if the virus de-installs, then you would still have found that foldername /filename. (and just be happy that it didnt infect it).

BTW why looking for an executable ? it might look for
~temp.txt
~dump.log
@dump.log
etc..

Reply    

Hans Adams

2012 Aug 15, 09:36
0
 

Re: Re: Re: Chinese Lottery

"
BTW why looking for an executable ? it might look for
~temp.txt
~dump.log
@dump.log
etc..
"

1) In my OP. I told "... and some configuration"
2) They are matching against components of "PATH".
3) "@dump.log" would not work, as "@" is encoded in 0x40 < 0x7a!

HA

Reply    

jas88

2012 Aug 15, 14:55
-1
 

Re: Re: Re: Re: Chinese Lottery

Yes, it is using items from PATH, but - from the description here - it is NOT searching for something executable - rather, it's cunningly (ab)using PATH entries as additional salt for the hash.

It's looking for the existence of a specific, unusual file/directory entry within PROGRAMFILES. It's using these path-filename tuples as further obfuscation, rather than to build an actual working path - apart from anything else, PROGRAMFILES itself isn't normally in PATH, meaning the paths being hashed don't even exist on the file system!

It's an interesting clue there - either there is a specific path entry known to exist on the target system, making this more or less an inside job (Windows installed on a non-default drive letter/directory, such as D:\WINXP?) OR they are using either C:\WINDOWS\system32 or C:\WINDOWS as an extra piece of salt. Bear in mind some industrial-control setups will come with their own Windows installation; I have a centrifuge at work like that. Does anyone know of SCADA or ATM vendors shipping Windows installations with a systempath other than C:\WINDOWS?

My gut feeling at this point is that it's using C:\WINDOWS(\system32) and looking for something in programfiles which starts with { - probably a GUID/UUID. Windows does treat these specially as file extensions (some malware is already known to exploit this to good effect as a way of hiding), but not as the actual filename. I'm sure I remember some software that installed itself in a GUID-named folder in programfiles, but can't seem to find a reference to it now.

(The other option would be that one of those ~ tmp files from the dropper gets put in programfiles at some point, perhaps as an indirect triggering mechanism, but I imagine Kaspersky Labs have checked that thoroughly?)

Reply    

waterhouse

2012 Aug 15, 11:25
0
 

Re: Chinese Lottery

I think angry.toopse has a point here. You could even do it in parallel, just in case, since distributing the testcase application would probably not take a lot of time and expertise.
The question is of course, whether you would advertise it, if you already did that.

Reply    

ravengamer

2012 Aug 14, 22:48
-2
 

Question

I would like to know if its only targeting windows xp or if it will attack say Linux vista and 7. I would also like to know where I can get this malware so I can infect a test machine to pull any and all data from the source vs asking a ton of questions.

or you could ask Fujitsu Laboratories (see Link)
http://www.maximumpc.com/article/news/researchers_crack_923-bit_encryption_set_new_world_r ecord

Reply    

Hans Adams

2012 Aug 14, 23:04
0
 

Re: Question --- OS

' “%PROGRAMFILES%\*”, where cFileName[0] > 0x007A (UNICODE ‘z’)'

says it MUST BE a Windows NT *. Native Linux should not work.

HA

Reply    

mkrio

2012 Aug 15, 00:38
0
 

Software in Program Files

Is anyone aware of any piece of software that creates any file or directory directly under %PROGRAMFILES% that is not starting with an ASCII character < 7A? How many did you have and try in the labs?

Reply    

Hans Adams

2012 Aug 15, 01:02
0
 

Re: Software in Program Files

"Is anyone aware of any piece of software that creates any file or directory directly under %PROGRAMFILES% that is not starting with an ASCII character < 7A? How many did you have and try in the labs? "

Malware! HA

Reply    

mkrio

2012 Aug 15, 02:19
0
 

Re: Re: Software in Program Files

Only found two dirs "in the wild" by a brief Google:
C:\Program Files\µTorrent
C:\Program Files\ #26234; #33021; #39537; #21160;

I find it really difficult to find software that breaks out of ASCII for naming installation dirs.

On the other hand, why would a proper attack rely on the target software being installed below the default installation path? Seems to be more plausible that it's looking for a file indicating an infection of the machine with another malware.

Reply    

Donkey

2012 Aug 15, 03:25
0
 

Re: Re: Re: Software in Program Files

hmm utorrent, well maybe RIAA is behind it.

Reply    

rezonant

2012 Aug 15, 06:38
0
 

Re: Re: Re: Software in Program Files

The path for uTorrent (at least on my machines) is \Program Files\uTorrent, just the normal ASCII 'u' character, not the "micro" character.

Reply    

noperand

2012 Aug 15, 00:44
0
 

Default Cryptographic Service Provider?

Is the default cryptographic service provider used? I'm wondering if a 128-bit derived key for RC4 is implied.

Reply    

Igor Soumenkov

2012 Aug 15, 15:47
0
 

Re: Default Cryptographic Service Provider?

They use PROV_RSA_AES and zero flags in CryptDeriveKey.

Reply    

__fred__

2012 Aug 16, 12:28
0
 

Re: Re: Default Cryptographic Service Provider?

That would indicate that only 40 bits of the md5 hash are used to derive the key and 88 zero bits of salt. My best bet would be to attack RC4 directly.

My bad, default key length for PROV_RSA_AES seems to be 128 bit.

Edited by __fred__, 2012 Aug 16, 13:45

Reply    

la7ong9E

2012 Aug 16, 17:05
0
 

Re: Re: Default Cryptographic Service Provider?

What it the third argument (pszProvider) to CryptAcquireContext() used in the samples?

Have you seen any set of samples with the same "Salt 2"?

Reply    

ycombinator1

2012 Aug 15, 01:08
0
 

ycombinator.com has a good guess on InstallShield GUID

"InstallShield Installation Information" subfolders

Lots of GUID there. Would make sense for a targeted attack.

http://news.ycombinator.com/item?id=4381924

Reply    

Hans Adams

2012 Aug 15, 01:17
0
 

Re: ycombinator.com has a good guess on InstallShield GUID

Like

/cygdrive/c/Program Files (x86)/InstallShield Installation Information/{01FB4998-33C4-4431-85ED-079E3EEFE75D}
/cygdrive/c/Program Files (x86)/InstallShield Installation Information/{0F796312-289C-40CA-856C-9FBCF5E83342}
/cygdrive/c/Program Files (x86)/InstallShield Installation Information/{145DE957-0679-4A2A-BB5C-1D3E9808FAB2}
/cygdrive/c/Program Files (x86)/InstallShield Installation Information/{17283B95-21A8-4996-97DA-547A48DB266F}
/cygdrive/c/Program Files (x86)/InstallShield Installation Information/{40FEF622-6E0F-46B6-824B-A40C178FD4CD}
/cygdrive/c/Program Files (x86)/InstallShield Installation Information/{4A331D24-A9E8-484F-835E-1BA7B139689C}
/cygdrive/c/Program Files (x86)/InstallShield Installation Information/{BAE68339-B0F6-4D33-9554-5A3DB2DFF5DA}
/cygdrive/c/Program Files (x86)/InstallShield Installation Information/{D1434266-0486-4469-B338-A60082CC04E1}
/cygdrive/c/Program Files (x86)/InstallShield Installation Information/{D3F2FAA5-FEC4-42AA-9ABA-1F763919A2B5}
/cygdrive/c/Program Files (x86)/InstallShield Installation Information/{D50300AA-D25A-463B-98BF-E09585325711}
/cygdrive/c/Program Files (x86)/InstallShield Installation Information/{EF367AA4-070B-493C-9575-85BE59D789C9}
/cygdrive/c/Program Files (x86)/InstallShield Installation Information/{F132AF7F-7BCA-4EDE-8A7C-958108FE7DBC}

Smiling HA

Reply    

The Cornishman

2012 Aug 15, 01:51
0
 

Re: Re: ycombinator.com has a good guess on InstallShield GUID

Yes, but according to the GReATeam, above, step 2 of validation is using %PROGRAMFILES%\*. Unless they've left something out of the description, that's not recursive, so would return the subfolder 'InstallShield Installation Information' but none of its subsidiaries.
It's a compelling idea, so much so that I suspect the search in Validation Step 2 must in fact be recursive. Clarification, please?

Reply    

Hans Adams

2012 Aug 15, 10:42
-2
 

Re: Re: Re: ycombinator.com has a good guess on InstallShield GUID


Would you PLEASE have a look at the search path?
' "%PROGRAMFILES%\*”, where cFileName[0] > 0x007A (UNICODE ‘z’).'

Didn't you see the asterisk following %\...

SEARCH IS RECURSIVE!

HA

Reply    

YourselfMe

2012 Aug 15, 13:44
1
 

Re: Re: Re: Re: ycombinator.com has a good guess on InstallShield GUID

No, the search is not recursive.

Why are you trying so hard to derail this thread?

Reply    

Igor Soumenkov

2012 Aug 15, 15:48
2
 

Re: ycombinator.com has a good guess on InstallShield GUID

The malware looks only in the %PROGRAMFILES% directory, without recursion.

Reply    

aNaBrUoÃiGeL

2012 Aug 16, 06:07
0
 

Re: ycombinator.com has a good guess on InstallShield GUID

O programa em questão, usa essa referência para instalar uma réplica do código em todas as instalações novas que utilizam o INSTALL SHIELD INSTALLER, dessa forma passam despercebidos no sistema e receberam permissões pelo própio usuário no ato da instalação...
"C:\Program Files\Common Files\InstallShield"
se não existir esta referência ele intalará uma cópia devidamente preparada..

Reply    

rGiht

2012 Aug 15, 01:44
0
 

Just an idea

Cannot Godel have connection with Gödel numbering (http://en.wikipedia.org/wiki/G%C3%B6del_numbering)

Reply    

Michael_Mike

2012 Aug 15, 02:08
0
 

What happen if at validation step 2, the code does not find any occurrences 'where cFileName[0] > 0x007A'?

-Will it cancel the procedure?
-Will it simply append 0x0000 and continue?
-Will it append nothing and continue?

Reply    

LSD4me

2012 Aug 15, 02:22
0
 

Is the Sample MD5 validation correct?

Is the MD5 posted above for the Sample data for validating the algorithm at step 6 correct?

76405ce7f4e75e352c1cd4d9aeb6be 41

I am having difficulty verifying the sample data for validating algorithm after 10,000 md5 iterations which when everything is concatenated together, results in a value of

C.:.\.D.o.c.u.m.e.n.t.s. .a.n.d. .S.e.t.t.i.n.g.s.\.j.o.h.n.\.L.o.c.a.l. .S.e.t.t.i.n.g.s.\.A.p.p.l.i.c.a.t.i.o.n. .D.a.t.a.\.G.o.o.g.l.e.\.C.h.r.o.m.e.\.A.p.p.l.i.c.a.t.i.o.n.~.d.i.r.1..Hl."_.w.5..s#mQ

and results in a hex value of

43003A005C0044006F00630075006D 0065006E0074007300200061006E00 64002000530065007400740069006E 00670073005C006A006F0068006E00 5C004C006F00630061006C00200053 0065007400740069006E0067007300 5C004100700070006C006900630061 00740069006F006E00200044006100 740061005C0047006F006F0067006C 0065005C004300680072006F006D00 65005C004100700070006C00690063 006100740069006F006E007E006400 69007200310097486CAA225FE877C0 35CC0373236D51

My initial MD5 hash of the concatenated strings is

3A18082A8D0C8727C843AAB34A1B46 96 (UPPER CASE)
3a18082a8d0c8727c843aab34a1b46 96 (LOWER CASE)

Is this correct?

After 10,000 iterations, i get

794e07601f17cebd2915b92042fd17 58 (UPPER CASE)
bd86a99f1e5a4f39f3a4a9074678dc b2 (LOWER CASE)

Edited by LSD4me, 2012 Aug 15, 02:42

Reply    

Michael_Mike

2012 Aug 15, 02:57
0
 

Re: Is the Sample MD5 validation correct?

the 'MD5 at validation step 6: 76405ce7f4e75e352c1cd4d9aeb6be 41' is the hard-coded value. Should you find a md5 hash being equals to that value after performing the steps described above, then you have just found the key.

Reply    

LSD4me

2012 Aug 15, 02:59
0
 

Re: Re: Is the Sample MD5 validation correct?

Then what is the purpose of :

Sample test Strings, Unicode (without quotes):

“C:\Documents and Settings\john\Local Settings\Application Data\Google\Chrome\Application”

“~dir1”

?

Reply    

Michael_Mike

2012 Aug 15, 06:38
0
 

Yes we need clarification

After verification, I am getting the same initial md5sum as yours, for lower-cap letter only.

First I was thinking that the part where md5sum were given was apart from the example, but it seems not, since there is no md5 hash to validate for decryption.

It seems that we need more information, since we don't have the hard-coded value. Or was it a typo, that we got the hard-coded value but the expected md5sum is missing?

I will wait before asking question for problem that doesn't exist...

Here is the code I used, as I had previously calculated the first hash with a chained command.

with Ada.Text_IO, gnat.md5, ada.characters.handling;
use Ada.Text_IO, gnat.md5, ada.Characters.handling;

procedure hash_p is
Lower_case:string:="3a18082a8d0c8727c843aab34a1b46 96";
Upper_case:string:=to_upper(Lower_case);

begin

for Count in 1 .. 10000 loop
Lower_case:=GNAT.MD5.Digest(Lower_case);
Upper_case:=to_upper(GNAT.MD5.Digest(Upper_case));
end loop;

Put_line(Lower_case);
Put_line(Upper_case);
end hash_p;

Which give an output:
>./hash_p
bd86a99f1e5a4f39f3a4a9074678dc b2
4E98E462BFB199BD48A635D8B932A6 C7

Edited by Michael_Mike, 2012 Aug 15, 06:51

Reply    

YourselfMe

2012 Aug 15, 13:48
0
 

Re: Yes we need clarification

What is the purpose of messing with upper/lower case here?
The repeated hashing is done over binary data, not md5 digest expressed as base16!

Reply    

ilya

2012 Aug 15, 09:28
0
 

Re: Is the Sample MD5 validation correct?

I would imagine that the MD5 digest is computed and kept as binary throughout the loop. It is probably never converted to a hex string.

Some sample C# code that matches the validation at step 6:

var s = @"C:\Documents and Settings\john\Local Settings\Application Data\Google\Chrome\Application~dir1" + System.Text.UnicodeEncoding.Unicode.GetString(new byte[]
{ 0x97,0x48, 0x6c,0xAA,0x22,0x5F, 0xE8,0x77,0xC0,0x35, 0xcc,0x03,0x73,0x23, 0x6D, 0x51
});

var bytes = System.Text.UnicodeEncoding.Unicode.GetBytes(s);

var md5 = System.Security.Cryptography.MD5.Create();
var firstHash = md5.ComputeHash(bytes);

var secondHash = new byte[16];
Array.Copy(firstHash, secondHash, 16);

for (var i = 0; i < 10000; i++)
{
secondHash = md5.ComputeHash(secondHash);
}

Console.WriteLine(BitConverter.ToString(secondHash));

The output is: 76-40-5C-E7-F4-E7-5E-35-2C-1C-D4-D9-AE-B6-BE-41

Reply    

Michael_Mike

2012 Aug 15, 10:33
0
 

Re: Re: Is the Sample MD5 validation correct?

Pretty strange. The first hash that I wrote in my code have been validate digit by digits, hex by hex, and it match both the image on the top and it's the hex value as LSD4me.

I don't have C# at home, can you show me the output in hexadecimal value of the string that you created, and on the first md5sum?

I got the same initial hash by running by using bash. I have written the hexadecimal to a file and removed the 0x0a at the end of the file by specifying xxd to only use the first 404 characters, this output have been verified also with the picture and it's a 100% match.

1. I created a file, and copied all the hex values, and removed all the space.
2.I validated the content of the file with xxd (a stream hexadecimal viewer) and it matche (plus a 0x0a at the end).
3.I read the file to standard output, and by specifying xxd to only keep the first 404 characters, removing the 0x0a. From that point, the hex value readable with vi = the hex value printed by xxd = the hex values on the image.

(file is name is 'hex')
>cat hex | xxd -p -r -l 404
C:\Documents and Settings\john\Local Settings\Application Data\Google\Chrome\Application~dir1 #65533;Hl #65533;"_ #65533;w #65533;5 #65533;s#(no new line character)

(switch -c specify to create an output of 32 columns per line)
>cat hex | xxd -p -r -l 404 | xxd -c 32
--output matche picture--

>cat hex | xxd -p -r -l 404 | md5sum
3a18082a8d0c8727c843aab34a1b46 96 -

a little more here
http://pastebin.com/LEJukXV3

Reply    

ilya

2012 Aug 15, 10:36
0
 

Re: Re: Re: Is the Sample MD5 validation correct?

Original bytes are:

43-00-3A-00-5C-00-44-00-6F-00-63-00-75-00-6D-00-65-00-6E-00-74-00-73-00-20-00-61-00-6E-00-64-00-20-00-53-00-65-00-74-00-74-00-69-00-6E-00-67-00-73-00-5C-00-6A-00-6F-00-68-00-6E-00-5C-00-4C-00-6F-00-63-00-61-00-6C-00-20-00-53-00-65-00-74-00-74-00-69-00-6E-00-67-00-73-00-5C-00-41-00-70-00-70-00-6C-00-69-00-63-00-61-00-74-00-69-00-6F-00-6E-00-20-00-44-00-61-00-74-00-61-00-5C-00-47-00-6F-00-6F-00-67-00-6C-00-65-00-5C-00-43-00-68-00-72-00-6F-00-6D-00-65-00-5C-00-41-00-70-00-70-00-6C-00-69-00-63-00-61-00-74-00-69-00-6F-00-6E-00-7E-00-64-00-69-00-72-00-31-00-97-48-6C-AA-22-5F-E8-77-C0-35-CC-03-73-23-6D-51

First hash is:

3A-18-08-2A-8D-0C-87-27-C8-43-AA-B3-4A-1B-46-96

This matches your output.

After 10K hashes, the hash value is:

76-40-5C-E7-F4-E7-5E-35-2C-1C-D4-D9-AE-B6-BE-41

Reply    

Michael_Mike

2012 Aug 15, 12:22
0
 

There is something wrong

A bash script give me the same output, note that finally the -l 404 switch serve no purpose since neither the new_line (0x0a) is present, nor the count is = 404 after being processed by xxd. At least it did not affected the result. :)

#!/bin/bash
declare -i count

a=$(cat hex | xxd -p -r | md5sum | awk '{print $1}' | xxd -l 32 | xxd -r)
for (( count = 0 ; count < 10000; count++))

do
a=$(echo -en "$a" | md5sum | awk '{print $1}' | xxd -l 32 | xxd -r)
done
echo " done"
echo "$a"
exit 0

>bash test.sh
done
bd86a99f1e5a4f39f3a4a9074678dc b2

Again the same string as before. Is it possible that C# does not handle the string appropriately? Like still producing utf-16 for what is now utf-8? Can someone try it with another programming language?

I pasted all the 10,001 outputs of my previous program and the modified source code, to avoid any confusion.
http://pastebin.com/Y6YznLz4

Reply    

ilya

2012 Aug 15, 19:42
0
 

Re: There is something wrong

The point is that all hashes should be generated from the binary representation, not the hex string, of the digest. This would work in any language regardless of unicode encoding since, after the first hash, there's no more textual treatment at all.

Reply    

Michael_Mike

2012 Aug 15, 20:34
0
 

I did something wrong

I missed that message from Igor.
(edit)
My bash script now get the same result as yours :)

#!/bin/bash
declare -i count

a=$(cat hex | xxd -p -r | md5sum | awk '{print $1}')
for (( count = 0 ; count < 10000; count++))

do
a=$(echo -en "$a" | xxd -p -r | md5sum | awk '{print $1}')
done
echo " done"
echo "$a"
exit 0

>bash script.sh
done
76405ce7f4e75e352c1cd4d9aeb6be 41

Edited by Michael_Mike, 2012 Aug 15, 21:10

Reply    

Igor Soumenkov

2012 Aug 15, 15:50
0
 

Re: Re: Re: Is the Sample MD5 validation correct?

The hash is indeed kept in binary form.

Reply    

Ignatio

2012 Aug 15, 20:37
0
 

Re: Re: Re: Is the Sample MD5 validation correct?

Here is Delphi Source code that does the validation check

sPath should be set to 'C:\Documents and Settings\john\Local Settings\Application Data\Google\Chrome\Application'
and sFile should be set to '~dir1' in the ValidationHashFromStringPair function

Consecutive hashes should be done on the resulting byte arrays, not on the string hex representation. That's why some people are not getting the results.

uses IdHashMessageDigest;

function ValidationHashFromByteArray(b : TBytes) : string;
var
idmd5 : TIdHashMessageDigest5;
i: integer;
begin
idmd5 := TIdHashMessageDigest5.Create;
try
for i := 1 to 10000 do
b := idmd5.HashBytes(b);

{after doing the final hash, also convert to a hex string}
result := idmd5.HashBytesAsHex(b);
finally
idmd5.Free;
end;
end;

function ValidationHashFromStringPair(const sPath,
sFile: WideString): string;
const
hSalt: array[0..15] of Byte =
($97, $48, $6C, $AA, $22, $5F, $E8, $77, $C0,
$35, $CC, $03, $73, $23, $6D, $51);
var
StringPair: WideString;
StringPairByteCount: Integer;
Buffer: TBytes;
begin
StringPair := sPath + sFile;
StringPairByteCount := Length(StringPair) * SizeOf(WideChar);

{Fill an array of bytes from string pair and salt}
SetLength(Buffer, StringPairByteCount + Length(hSalt));
Move(StringPair[1], Buffer[0], StringPairByteCount);
Move(hSalt, Buffer[StringPairByteCount], Length(hSalt));

Result := ValidationHashFromByteArray(Buffer);
end;

Reply    

__fred__

2012 Aug 15, 20:22
0
 

Re: Re: Is the Sample MD5 validation correct?

Anyone who wants to check his own system. I've created a pastebin that pretty much does the same validation against the given samples.

http://pastebin.com/Kf4jsti4

Anyone from the region with access to highly classified computers that is able to check a few? ;-)

Reply    

Dennis Farr

2012 Aug 15, 10:15
0
 

Re: Is the Sample MD5 validation correct?

Your values for the hash should not differ for upper case or lower case. If they do, then the string you are passing in is not being interpreted as 32 hex digits (128 bits) but as 32 characters (256 bits).

Reply    

Michael_Mike

2012 Aug 15, 10:45
0
 

Well it depend of how the output is interpreted. It should remain in lower-case considering how the md5 hash is usually produced, but the exact implementation details are unknown, and by reffering to rft 1321, output in cap-letter is not forbidden; it doesn't change the value of the hash since 0xF=0xf, but it will change the value of the next computation, since the previous hash is not treated as a string composed of character [0-f] or [0-9,A-F] .

I think it's a valid question, even if the odds are in favor of lower-case letter, it have to be taken in consideration.

Reply    

0xCC

2012 Aug 15, 05:38
0
 

sp00ff

Hulk smash .. Cryptographers? The brute force method=java is not strong with that one. !u!z

Another Flamer? Reads more like this requires the help of an ass.cracker.

Get your h3AD out of the gutter.

If there's a hard coded value, why not just sp00ff the key?

Or use the likes of softice to trick it into decoding itself?

XOR ... so much more.

Maybe if there were a decent bounty then you'd actually get more qualified people to help.

Godel was German, btw.
Gauss is German, too.
Enigma? German.

Hmmm ... thanks for the entertainment.

Good Luck

Reply    

0xCC

2012 Aug 15, 06:05
0
 

Re: sp00ff

Oh, yeah ...

Lagrange succeeded Euler as the director of mathematics at the Prussian Academy of Sciences in Berlin, where he stayed for over twenty years.

(Kurt == Godel) was born April 28, 1906, in Brno, Austria-Hungary into the ethnic German family of Rudolf Gödel.

Taylor's an odd ball. He's a Brit.

007's a Brit, too.

On second thought, maybe it's the Brits trying to target Germany, after all. Isn't the ECB in Germany? !0!

Edited by 0xCC, 2012 Aug 15, 07:11

Reply    

0xCC

2012 Aug 15, 06:46
0
 

Re: Re: sp00ff

The moral of the story? Think outside the box.

Kurt Gödel demonstrated that within any given branch of mathematics, there would always be some propositions that couldn't be proven either true or false using the rules and axioms ... of that mathematical branch itself. You might be able to prove every conceivable statement about numbers within a system by going outside the system in order to come up with new rules and axioms, but by doing so you'll only create a larger system with its own unprovable statements. The implication is that all logical system of any complexity are, by definition, incomplete; each of them contains, at any given time, more true statements than it can possibly prove according to its own defining set of rules.

Gödel's Theorem has been used to argue that a computer can never be as smart as a human being because the extent of its knowledge is limited by a fixed set of axioms, whereas people can discover unexpected truths ... It plays a part in modern linguistic theories, which emphasize the power of language to come up with new ways to express ideas. And it has been taken to imply that you'll never entirely understand yourself, since your mind, like any other closed system, can only be sure of what it knows about itself by relying on what it knows about itself.

Reply    

Hans Adams

2012 Aug 15, 09:21
1
 

OT: Wittgenstein ----- Re: Re: Re: sp00ff

". It plays a part in modern linguistic theories, which emphasize the power of language to come up with new ways to express ideas. And it has been taken to imply that you'll never entirely understand yourself, since your mind, like any other closed system, can only be sure of what it knows about itself by relying on what it knows about itself"

Ludwig Wittgenstein, Logsich-philosophische Abhandlungen, Vorwort: „Die Grenzen meiner Sprache bedeuten die Grenzen meiner Welt“.

HA

Reply    

Michael_Mike

2012 Aug 15, 06:46
0
 

Re: sp00ff

From my own understanding, the hardcoded value is there for reliability, otherwise the code would execute regardless it's the good or the wrong key.

Decrypting this algorithm will need more than asm programming! Brute forcing the key seems very hard to do, since the throughput is expected to be diminished by thousands of times so what you were able to do in 1 hours will now take you more than 41 day, unless you want to directly brute-force the rc-4 key.

Edited by Michael_Mike, 2012 Aug 15, 07:18

Reply    

0xCC

2012 Aug 15, 07:00
0
 

Re: Re: sp00ff

Clearly, you missed my point. Do you even know what an ICE is?

I said ass, not asm.

She-Hulk smash, too?

Simple. Loader. Override. CryptGetHashParam.

Reply    

Michael_Mike

2012 Aug 15, 07:09
0
 

RE:0xCC

Well I have supposed too much.

And how do you think that getting the program to decrypt with a different key will give you anything useful? My bet is that you will end up with a bunch of randomized 0 and 1, which are totally useless; the very reason of the existence of the hard-coded value, to make sure that this situation won't happen, to not have all currently known to be infected user to get their computer crashing, yielding to a much, much sooner detection.

Edited by Michael_Mike, 2012 Aug 15, 07:28

Reply    

0xCC

2012 Aug 15, 07:43
0
 

Re: RE:0xCC

I'll just assume you don't know what an RNG is either.

Cogito ergo sum. I think therefore I am.

I'm sure you'll have it figured out in no time.

Random's an algorithm.

Security is a feeling.

I wont end up with anything.

If, then. It's a contingency.

I'm so happy somebody gets me.

God el only knows what I'd do without a computer.

Reply    

Michael_Mike

2012 Aug 15, 08:17
0
 

Re: Re: RE:0xCC

Reading all the BS that you wrote, I am not sure whether it's a Random Number Generator, or a Rated Next Generation.

I politely suggest that you find the meaning of the word encryption. It's not about jump-wiring a car, or by-passing a control in the software, it's encrypted, period, encrypted.

I have lost enough time trying to discuss with you.

Reply    

Dennis Farr

2012 Aug 15, 09:47
0
 

Re: Re: sp00ff

The 10000 iterations of MD5 seems weird. The name Gauss can conjure up many things, including the story about finding a quick way to add the first 100 numbers, when he was a schoolchild.

Since MD5 pads a short string with zeroes to get a 512-bit block to hash, and since it outputs 128 bits, the last 384 bits of each of the 10000 iterations are going to be all zeroes.

Since MD5 itself is broken, I would imagine there are faster ways of getting the result of 10000 iterations of MD5, and possibly of even walking the matching hash back 10000 times to an original value. Due to (possible) hash collisions, there might be multiple input hashes that result in the output hash, in which case walking it back looks less feasible.

I DO NOT KNOW HOW TO DO THIS. I suspect some people might know how, or that the work to figure out how might be faster than doing all those hashes in a search for the file pair(s) that trigger decryption.

Reply    

Michael_Mike

2012 Aug 15, 10:53
0
 

I think like you. I have never done this, but I am sure it can be done, it's exciting.

Someone could manage to directly break the RC-4 key, and find out the content and purpose of the encrypted data. I am a bit surprised that the Mossad cannot manage to break an encryption like this; not that it's weak, but I think they are very good at cryptanalysis.

For the collision problem, I am not sure it would be an issue, though not impossible. Since the result of the key produced is validate with a hard-coded value, it must significantly reduce the risk of collision - I can't quantify it but it should be a very low probability.

Reply    

sisyphus

2012 Aug 16, 18:42
0
 

Re: Re: Re: sp00ff

I think the 10k iterations of md5 hashing is very significant as well. It seems the emphasis thus far has been on the target having some static pair in their path/program files as part of some known configuration of the target, but is it not possible that the combo is written dynamically by an as yet undiscovered companion exploit?

It seems to me that the hashing iteration is done to widen the number of of possible collisions (various inputs lead to the same key such that there isn't a single path/file pair leading to the key, but rather any number of a dynamically generated set leading to the final hash). Note that the pair itself isn't used as the encryption key, but again a statically-salted, iterated hash.

The attacker now has an intentionally imprecise method for retrieving the key, such that there may be many, many combinations leading to the iterated hash, but perhaps only a smaller subset of those that lead to the 2nd iterated hash once the second salt is used (perhaps someone with better knowledge of md5 can chime in on whether that is a property of md5 collisions, i.e. two inputs resulting in collision when appended with a suffix not yielding another collision).

If it is, cracking by generating a collision for the static hashes will be more difficult, but it seems like that's the route to go down at the moment to this amateur.

Reply    

sisyphus

2012 Aug 16, 19:10
0
 

Perhaps I'm being a bit naive

From everyone's favorite source:

On December 24, 2010, Tao Xie and Dengguo Feng announced the first published single-block (512 bit) MD5 collision.[16] Previous collision discoveries relied on multi-block attacks. For "security reasons", Xie and Feng did not disclose the new attack method. They have issued a challenge to the cryptographic community, offering a US$ 10,000 reward to the first finder of a different 64-byte collision before January 1, 2013.

Maybe someone should talk to Xie and Feng.

Reply    

Michael_Mike

2012 Aug 15, 07:24
0
 

Re: sp00ff

Enigma is not german. It have been invented by two Dutch naval officer in 1915. The patent have been filed by a german though.

Where are you going to? Germanic supremacy?

Reply    

0xCC

2012 Aug 15, 07:44
0
 

Re: Re: sp00ff

Enigma was invented by German engineer Arthur Scherbius at the end of World War I.

Reply    

Michael_Mike

2012 Aug 15, 08:13
0
 

Re: Re: Re: sp00ff

As I said, the dutch invented it, a german patented it.

http://plus.maths.org/content/os/issue34/features/ellis/index
"
In 1915 two Dutch Naval officers had invented a machine to encrypt messages. This encryption tool became one of the most notorious of all time: the Enigma cipher machine. Arthur Scherbius, a German businessman, patented the Enigma in 1918 and began selling it commercially to banks and businesses."

Reply    

0xCC

2012 Aug 15, 08:26
0
 

Re: Re: Re: Re: sp00ff

Hugo Alexander Koch (9 March 1870, Delft – 3 March 1928, Düsseldorf) was a Dutch inventor who conceived of and patented an idea for machine encryption — the rotor machine, although he was not the first to do so. He is sometimes erroneously credited as the originator of the Enigma machine, although this has been shown to be the work of German engineer Arthur Scherbius.

Reply    

0xCC

2012 Aug 15, 08:35
0
 

Re: Re: Re: Re: Re: sp00ff

Ditto the bit about reading every word.

If you are really precise you will do the German translation.

You are citing the erroneous bit.

Check your fat.

Reply    

Michael_Mike

2012 Aug 15, 09:06
0
 

>You are citing the erroneous bit.
>
>Check your fat.

Get some decent documentation. You may consider a German as being the inventor of enigma if you want to see it that way (no offense), but from the words you are using (i.e. check my fat), then you don't have the required rigor for discussing about this technicality.

The same apply for the encryption. Get some decent documentation.

>If you are really precise you will do the German translation.
If you were really precise then you will find that language fail to contain idea. Why bothering to do a translation that will erase even more accuracy? I got many sources, you got only one, and you erased most of it because it was contradictatory; it clearly rely on the patent aspect to name Scherbius "the inventor". And again, it's from wikipedia, everybody can fix it, or distord it. The page have not received any quality rating.

Reply    

Michael_Mike

2012 Aug 15, 08:53
0
 

No link?

Sure, it came from wikipedia. And you purposely removed the following part,saying that they developed their machine independently. Arthur Scherbius patented it in 1918, while Koch patented it in 1919. Interestingly, Scherbius bought his patent later. Note the year I gave before: 1915.

www.cimt.plymouth.ac.uk/resources/codes/codes_u20_text.pdf
"In 1915, two Dutch Naval officers invented a machine to encrypt messages. This encryption tool became one of the most notorious of all time, the Enigma cipher machine. Arthur Scherbius, a German businessman, patented the Enigma in 1918 and began selling it commercially to banks and businesses.
"

Now a second source: Britanica. Note the term independently
http://www.britannica.com/EBchecked/topic/320845/Hugo-A-Koch

"...both cryptomachines and techniques for the analysis of machine ciphers. At almost the same time that Hebern was developing the rotor cipher machine in the United States, European engineers, notably Hugo A. Koch of the Netherlands and Arthur Scherbius of Germany, independently discovered the rotor concept and designed machines that became the precursors of the best-known cipher machine in..."

And now your own link
http://en.wikipedia.org/wiki/Hugo_Koch
" .......
in 1927, he assigned the rights to Arthur Scherbius, the inventor of the Enigma machine. Scherbius had developed the idea of rotor machine encryption independently from Koch, and had filed for his own patent in 1918. Bauer (1999) writes that Scherbius bought Koch's patents "obviously not because he did not own patents before; presumably he wanted to protect his patents"."

The fact that a lawyer will say that Scherbius invented it because he possess the patents (and the first one) doesn't necessarily mean that it was the first one to invent it. He just patented it faster.

Beyond all that, this **comment** section is about Gauss virus, not for history correction.

Reply    

0xCC

2012 Aug 15, 07:50
0
 

Re: Re: sp00ff

It's James Bond and the Brits trying to frame Germany, remember?

I know, reading every word can be a chore some times.

Though now that you mention it ... the Germans did supremely loose their ass in WWII. This is WWW.

Reply    

cachuar

2012 Aug 15, 06:41
0
 

i need the file

hello!
I need the ifection file. where can i get it?
send to my e-mail: josecachuar@hotmail.com
thanks.

Reply    

dude12345678

2012 Aug 15, 11:10
-1
 

weakness in step 5 of validation?

i think we could bruteforce it...

we need to kill step5, so we just need 1 md5 calculation and not 10001.

the idea is to calculate evry 128bit md5. yes, damn big rainbow table. but we should get h[1]=md5(input) very easy, and step 5 never have to be done again.

after that we can bruteforce the shit out of it to find the initial input for step 4.

perhaps we can do it distributed? or in the cloud?

we need to organize if we want to break it. anyone interested to try this? send me a mail...

dude12345678

Reply    

__fred__

2012 Aug 15, 15:04
0
 

Re: weakness in step 5 of validation?

The numbers are way too big to create a rainbow table. 2^128 hashes = 3,4 * 10^38. With modern GPU's you could probably calculate around 100-110 MHash/s. it would still take around 9 * 10^25 hours to calculate all hashes. That's way too much.

And then you'd have to test all possibilities...

Edited by __fred__, 2012 Aug 15, 15:49

Reply    

dude12345678

2012 Aug 15, 20:06
0
 

Re: Re: weakness in step 5 of validation?

"And then you'd have to test all possibilities..."

simpliy find a way throu the table...have h[10000] the table gives us h[9999] then h[9998] and so on... with luck there exactly 10000 hashes needed to be calculated ;)

Reply    

M F

2012 Aug 15, 11:46
2
 

encrypted payload eyh?

Maybe AC/DC's thunderstruck player? :)

Reply    

Dutchman

2012 Aug 15, 12:52
0
 

Combinations

We have tried millions of combinations of known names in %PROGRAMFILES% and Path, without success.

Hope you also tried combinations of only Paths and only %PROGRAMFILES% ;-)

Reply    

Hans Adams

2012 Aug 15, 13:20
0
 

Re: Combinations ---- Yet unclear....

Do you calculate a Cartesian product of the concatenated list (from elements from %PATH% and %PROGRAMFILES%\*")with itself, or what do you do?

Would you please clarify this?

regards, HA

Reply    

Igor Soumenkov

2012 Aug 15, 15:52
0
 

Re: Re: Combinations ---- Yet unclear....

The algorithm requires us to calculate a Cartesian square of the combined list of strings from Path and %PROGRAMFILES%.

Reply    

Hans Adams

2012 Aug 15, 16:17
0
 

Re: Re: Re: Combinations ---- Yet unclear....

"The algorithm requires us to calculate a Cartesian square of the combined list of strings from Path and %PROGRAMFILES%." Which I already have called APPENDED_SQUARE.

APPENDED_SQUARE=APPENDED X APPENDED =
{A, B, C ....a, b, c ...} X {A, B, C ... a, b, c ...}
={AA, AB, ...CC,...Aa, Ab, ..., aA, aB, ..,Cc, .,aa,ab,..cc..}

Shouldn't the first element be AA, with A being the very first element of (list) APPENDED, which in turn must be the very first element of (list) PATH?

asks HA

Reply    

Igor Soumenkov

2012 Aug 23, 00:30
0
 

Re: Re: Re: Re: Combinations ---- Yet unclear....

Yes, it will be AA, AB, AC, etc.

Reply    

Hans Adams

2012 Aug 15, 13:51
-1
 

Re: Combinations --- To say it LOUD AND CLEAR


Lets have two lists, one from %PATH%, the second from %PROGRAMFILES%\*. We encode the lists as ordered sets in a well known manner.

PATH={A,B,C,D.....}
PROGRAMFILES={a,b,c,d,e}

"2. Append the list with all entries returned by FindFirstFileW / FindNextFileW by mask “%PROGRAMFILES%\*”, where cFileName[0] > 0x007A (UNICODE ‘z’)" will result in the list APPENDED.

APPENDED={PATH|PROGRAMFILES}={A,B,C ......a,b,c .....}

"3. Make all possible pairs from the entries of the resulting list." will establish the Cartesian product of the lsit "APPENDED" with itself. Let us call it

APPENDED_SQUARE=APPENDED X APPENDED =
{A, B, C ....a, b, c ...} X {A, B, C ... a, b, c ...}
={AA, AB, ...CC,...Aa, Ab,..., Cc..., aA, aB, ..,cC, .,aa,ab,..cc..}
(Sorry for the typos)

The first element of this list must be a pair only from the FIRST element of the list APPENDED which is even the FIRST element of PATH....

BUT in contradiction to your own points 1,2,3 the dump shows the first element being Aa, indicating that the resulting list might have following structure {Aa, Bb ....}, Take the first element from PATH and concatenate the first element of PROGRAMFILES, perhaps take the second of both and so on....

How should cases like |PATH| <> |PROGRAMFILES| be handled ?

What is right?

Or has simply one more EPIC Fail occurred at Kapersky?

asks HA

Edited by adamsh, 2012 Aug 15, 19:09

Reply    

cschramm

2012 Aug 15, 13:33
1
 

A Programmer's Psychology

Imagine you want to find an extended character without being too verbose about it. I'm sure, you'd check for > 0x7f (or >= 0x80).

Since Gauss is testing > 0x7a, I'd expect it to _not_ look for any extended character, but { | } ~. I don't think | and } make too much sense at the beginning of the name (is | even allowed by the file system?), so I guess it's either {, which indicates a Microsoft-style GUID, or ~, quite common for files, unusual for directories.

Of course, this only holds for 0x7a over 0x7f. Since it's obviously written in C, it could also mean 'z' vs. 0x7f where 'z' would probably win.

A guess on the combination: I'd expect the PATH entry to match the program containing the > 0x7a file. It's probably either the program's directory or a bin subfolder.

Aren't there any infected machines reported where the code found what it was looking for, one could inspect?

Reply    

Igor Soumenkov

2012 Aug 23, 00:33
0
 

Re: A Programmer's Psychology

The original code does not look into subfolders.

Reply    

JT

2012 Aug 15, 15:34
0
 

Userbase

Kaspersky can easily solve the problem, by querying all the previous victims with the list of folders in their %programfiles% which starts with '{' and then debugging the malware again with the correct folder names.

I believe the stats in the blogreport above regarding OS infection rate was received from kaspersky customers who was infected by Gauss malware. So Kaspersky can just release a patch for their Kaspersky AV product so that Kaspersky will receive the list of folder names starting with { or ~

Reply    

__fred__

2012 Aug 15, 15:48
0
 

Re: Userbase

Problem is that there could be many more infections than executions of the payload. So only a tiny fraction of the infected systems will meet the criteria for execution of the payload. It could theoretically be that none of the systems that reported infection so far meet the validation criteria.

And i think there would be some privacy issues as well, so i'd at least ask user consent before submitting their folder structure.

But it's the most likely way to get the data.

Reading more carefully the previous and this blog post, it seems that this is the data of the spy module that is written to USB drives.

It seems to target machines that are offline, i.e. not connected to the internet, so these machines probably don't have kaspersky installed and if they do, they probably do not get their definititions through the internet.

But you need only one machine that does.

Edited by __fred__, 2012 Aug 15, 16:01

Reply    

Hans Adams

2012 Aug 15, 19:26
0
 

Re: Re: Userbase -----


Implementin all points of chapter "Validation" is not worth a PhD thesis at all.....

Wouldn't it be wise to publish (GPLed?) source code in many programming languages, form Scala and F# to C and gcc down to ASM and gas.

So everyone feeling in danger could compile his own tools on his own, hopefully trustworthy, systems and check these.

So everyone could detect this threat and may send directory listings voluntarily in his sole responsibility to Kapersky.

best, HA

Edited by adamsh, 2012 Aug 15, 19:38

Reply    

__fred__

2012 Aug 15, 19:06
0
 

%PROGRAMFILES% in 32bit and 64bit versions

I have a question. How is the %PROGRAMFILES% environment variable defined in the 64bit version of the malware? Because if the 32bit and 64bit version of the malware use the "%PROGRAMFILES%" environment variable (as opposed to using %ProgramFiles(x86)% in 64bit version), it means it would search for 64bit program files entries on a 64bit system.

There is not that much software that is available in both 32bit and 64bit variants and can seriously limit the possibilities.

Reply    

Igor Soumenkov

2012 Aug 23, 00:54
0
 

Re: %PROGRAMFILES% in 32bit and 64bit versions

32bit and 64bit versions of malware use different salts and hashes; it is not possible to determine whether they reference same folder names.

Reply    

Medals

2012 Aug 15, 19:15
0
 

Bruteforcing?

Sure you can't bruteforce?
Googles new Compute Engine can use upto 770,000 engines.

Reply    

Hans Adams

2012 Aug 15, 19:31
0
 

Re: Bruteforcing?

If Kapersky is right, you would have to compute over the (algebraic) hull... This is one of the least efficient methods known.

FORGET it.

If Kapersky is right, the key itself is a fingerprint of the victim.

You need not try to get the key, but you SHOULD discover more potential victims.

HA

Reply    

keithmo

2012 Aug 15, 19:28
1
 

Files in %PROGRAMFILES%

Some people seem to be (IMO) too focused on finding applications that install into %PROGRAMFILES% in a directory starting with a character above 0x7a. If I understand the algorithm description correctly, then it depends only on the existence of such files/dirs in %PROGRAMFILES%; whether or not they're actually installed applications is irrelevant. This seems like little more than an elaborate and obfuscated trigger mechanism (that conveniently also provides the decryption key).

Note also that it would possible to create the illusion of these files in %PROGRAMFILES% via a file system filter driver, in which case the physical file/dir need not exist on disk, but only appear when triggered by some other mechanism.

Reply    

Hans Adams

2012 Aug 15, 19:36
0
 

Re: Files in %PROGRAMFILES%

"....Note also that it would possible to create the illusion of these files in %PROGRAMFILES% via a file system filter driver, in which case the physical file/dir need not exist on disk, but only appear when triggered by some other mechanism...."

WISE!

This would even preclude any reasonable static analysis and renders my own proposal worthless!

Thanks, HA

BTW: Why should we examine the file system and might have to rely upon a file filter in the kernel?

We could install the trigger into PATH-environment variable... ;->

Edited by adamsh, 2012 Aug 15, 19:56

Reply    

Myth

2012 Aug 15, 20:24
-2
 

Purpose of Gauss

I was just looking over the Gauss descriptions on the front page, and i'm a bit confused about the purpose and the parts we are looking into.

Gauss looks for something in a folder with a filename starting with 0x7a before executing it's payload. It is also known that it can infect a usb stick for some purpose.

But what is the big plan - the machines where it looks for the trigger is typicaly windows 7 machines located in the middle east. There has been talks of it using the usb drive to infect an offline system - but then it would at least have to get executed on this offline target, to infect or possible copy something from this target back to the usb drive.

So it steals something - or changes files on the target, and since the target is an offline system, stealing something seems to be the only way to gain anything from this.

This would require Gauss to be able to send this back to somewhere when back on a host that has an internet connection and again it would have to be triggered somehow and be able to deliver it's stolen goods to a reciever and get it back to who ever made Gauss.

Is this the same purpuse you guys read out of the information we have? Because this would also imply that there is a stolen payload that could possible be sniffed.

Reply    

JT

2012 Aug 15, 21:57
0
 

Re: Purpose of Gauss

Good idea.
So basically, just allow Gauss to infect and steal all those precious data (ie probably credit card, bank password, photos, domain name etc..). And then the international community just sinkhole the server (probably use zinkhole.org) and then study all the stolen Gauss data in the sinkhole.

Reply    

Hans Adams

2012 Aug 15, 22:24
0
 

??????

"Yes, it is using items from PATH, but - from the description here - it is NOT searching for something executable - rather, it's cunningly (ab)using PATH entries as additional salt for the hash. "

"PROGRAMFILES itself isn't normally in PATH, meaning the paths being hashed don't even exist on the file system! "

1) Ever thought, that just a rogue file entry is located in %PROGRAMFILES%, but the executable is hidden elsewhere in %PATH%....sharing the same file name....|-<

BTW: We are searching for files with names like [{}\~]*....

2. Finger printing of target: Already mentioned

3. Perhaps (additional) trigger, already mentioned...

"It's an interesting clue there - either there is a specific path entry known to exist on the target system, making this more or less an inside job (Windows installed on a non-default drive letter/directory, such as D:\WINXP?) OR they are using either C:\WINDOWS\system32 or C:\WINDOWS as an extra piece of salt. Bear in mind some industrial-control setups will come with their own Windows installation; I have a centrifuge at work like that. Does anyone know of SCADA or ATM vendors shipping Windows installations with a systempath other than C:\WINDOWS? "

Preconfigured systems, ATM, Mobile Base Stations, already mentioned.

HA

Reply    

__fred__

2012 Aug 16, 00:15
0
 

Re: ??????

Since the gauss malware is targetting lebanese bank transactions, the payload could very well be for an ATM of these banks. Monitoring bank transactions of Palistinian / Lebanese organisations seems plausible.

Reply    

Myth

2012 Aug 16, 00:42
0
 

Re: Re: ??????

The big question would then be, how to get information from the ATM which normaly runs in an isolated enviroment with no access to anything but the database..

Most ATM's do not run windows 7, which is what is most often infected. So i would rather believe it targets online banking credentials, credit card information and perhaps personal information. But the question still remains what it actually does. My best guess right now is that they are collection personal information hoping to get access to certain peoples various online accounts - or gathering information used for tranfers or money loundring.

Reply    

Hans Adams

2012 Aug 16, 01:58
0
 

Re: Re: Re: ??????


"The big question would then be, how to get information from the ATM which normaly runs in an isolated enviroment with no access to anything but the databas.."

Over a side channel. Those able to deploy "Gauss" will be able to establish a side channel.....

"Most ATM's do not run windows 7, ..." ATMs are often run under XP.... and Gauss runs on XP .....

HA

Reply    

Myth

2012 Aug 16, 10:19
-1
 

Re: Re: Re: Re: ??????

Over a side channel. Those able to deploy "Gauss" will be able to establish a side channel.....

I was working in a bank for a few years, and there are no side channels on an ATM. In Denmark, many ATM's run OS2 and NT, and they still use a token ring network, that only allows the ATM to access a database through a lot of security. There would be no ways to create any side channels, since there is no chance of getting anywhere from the ATM.

"Most ATM's do not run windows 7, ..." ATMs are often run under XP.... and Gauss runs on XP .....

But most of the infected computers are running W7 - and Gauss even has a module for 64 bit. It uses a .lnk exploit, which also would make no knows sense on anything other then XP->W7.

Even if it could move from an ATM to a backend server, these in Denmark at least, often run different Unix versions which are also unsupported.

Reply    

Michael_Mike

2012 Aug 16, 10:56
0
 

I have seen many ATM running XP (embedded?) in Canada for the error message I have seen.

Reply    

Mr. T

2012 Aug 16, 11:31
0
 

Re: Re: Re: Re: Re: ??????

It could be x86_64 or IA64. The x86_64 can ( at least usually ) run both 32 and 64-bit code and IA64 cannot. So maybe they are really targeting server side rather than desktops or it is multipurpose virus: collect banking information from the desktops and execute the encrypted part on the limited target server systems.

I doubt the real target is Windows 7 or Windows Vista. Vista was so bad no industrial system would be developed for it. And it usually takes some years before any system with significant meaning is adopted to the new OS. The end users want all the bells and whistles, but "One does not simply upgrade business or industrial systems without a real reason" and with enterprise systems -> "if it is not broken, do not try to fix it" which also means do not upgrade.

As many users have stated before, a lot of systems are running on old OS's. And as this kind of viruses have been developed against countries and their companies and institutions, the real target could be something like Windows 2003 Server

Reply    

Myth

2012 Aug 16, 12:29
0
 

Re: Re: Re: Re: Re: Re: ??????

But still the infection statistics from here:

https://www.securelist.com/en/analysis/204792238/Gauss_Abnormal_Distribution

Does not really indicate any large scale infections on servers, or other os'es then xp-w7. So it looks like it mainly affect home users, since i agree that many larger companies like finasial institutes, banks and so on would probably still run XP.

Perhaps it waits and tries to find a specific environment before delivering it's still secret payload - but i would imagine we should see some infections on W2003->2008 servers or something commonly used at the targetet environment for this to be the case.

Reply    

Hans Adams

2012 Aug 16, 12:36
0
 

Oh indeed! Re: Re: Re: Re: Re: ??????

" I was working in a bank for a few years, and there are no side channels on an ATM. In Denmark, "

Oh indeed, one more clerk.

"many ATM's run OS2 and NT, and they still use a token ring network, that only allows the ATM to "

Oh indeed. Those ATM run TokenRing over WAN or Metropolitan Area Networks (MAN). Sounds like quite a challenge to daisy chain ATMs over two wires....

"There would be no ways to create any side channels, since there is no chance of getting anywhere from the ATM."

Indeed, the bank rules the whole fabric of all Telcos and knows everything about their routers, switch fabrics and so on....

"But most of the infected computers are running W7 - and Gauss even has a module for 64 bit. It ..." Please have a look at another article here concerning Win7 and XP....

And the best. I already told you, that I suppose, that this malware is targeted at preconfigured, embedded systems, LIKE (but not only) ATMs, mobile base stations, SCADA-systems...

HA

Reply    

Myth

2012 Aug 16, 13:36
-1
 

Re: Oh indeed! Re: Re: Re: Re: Re: ??????

No need to be rude.. You know actually don't know anything about me or my background, and NO i am no clerk.

I am not saying that there are no possibly holes in the security around there system - i just stated that in my experience they are very closes, and often quite different from a normal client server setup. I gave the example of how they run in Denmark at least just to clarify this.

The ATM systems we run in Denmark, are very insulated from the rest of the world, and i honestly do not believe there is ant possible way software executed on any of those, can find a way out of the closed environment. But ofcourse i'm not going to explain how the exact setup is over the internet like this.

What i was trying to point out, is that the infections known, the behaviour known all looks to med as if it is trying to do something on home computers or workstations, rather than going for servers or embedded systems.

What is interesting is the information it is trying to gather, and what it actually infects right now whichs according to this:

https://www.securelist.com/en/blog/208193767/Gauss_Nation_state_cyber_surve illance_meets_banking_Trojan

It is targetting home users to steal online banking information..

"The key characteristic of Gauss is the online banking Trojan functionality. The ability to steal online banking credentials is something we haven’t previously seen in nation-state sponsored malware attacks."

Reply    

Hans Adams

2012 Aug 16, 13:54
0
 

Indeed! Re: Re: Oh indeed! Re: Re: Re: Re: Re: ??????

"I am not saying that there are no possibly holes in the security around there system - i just stated that in my experience they are very closes, and often quite different from a normal client server setup. I gave the example of how they run in Denmark at least just to clarify this."

Oh indeed, banks in Denmark run their own physically isolated and temper proof network. They even control bending of each LWL. They do not rely in ITU protocols, BUT communicate over continuous wide band.

"...the behaviour known all looks to med as if it is trying to do something on home computers or workstations, rather than going for servers or embedded systems. .."

Indeed you would take such efforts and make infections possible over mobile data storage mediums to compromise a non-hardened system, which MUST have Internet connectivity, as it will do Internet banking as you have assumed.

"https://www.securelist.com/en/blog/208193767/Gauss_Nation_state_cyber_surve illance_meets_banking_Trojan "

Do not both the articles tell us, that even Kapersky does not really know what is going on? The digital war head has not yet been decrypted not to mention understood.

HA

Edited by adamsh, 2012 Aug 16, 14:31

Reply    

Hans Adams

2012 Aug 16, 14:26
0
 

Oh indeed, for HEAVEN'S SAKE! Re: Re: Oh indeed! Re: Re: Re: Re: Re: ??????


"...can find a way out of the closed environment. But ofcourse i'm not going to explain how the exact setup is over the internet like this. ..."

Ever thought, that the note to payee gives you plenty of room to send interesting information to someone else , e.q. encoded in a bill number?

This is one of the oldest cracks I know against electronic bookkeeping and cashless payment transactions.

Autumn this year this crack will celebrate its thirty fifth birthday.

"There would be no ways to create any side channels, since there is no chance of getting anywhere from the ATM. "

So much about "clerk"...

HA

Edited by adamsh, 2012 Aug 16, 14:41

Reply    

jas88

2012 Aug 16, 13:30
1
 

Re: Re: Re: Re: Re: ??????

There's a nice easy front-channel if it's a public ATM though.

Use the modified font as a marker for infected devices. On vulnerable ATMs, the payload could covertly harvest data - then spit it out again when accessed with a specific card or key sequence. Even if the Windows side is locked down to the point it can't write to the inserted card, it could dump the harvested data on-screen: a sequence of QR codes for example, a bit like the old PDA-watches which could be programmed via an on-screen pattern.

(An ATM target could explain why the files are off the radar to Kaspersky, too: no Internet connectivity, so an infected device won't be phoning home or otherwise detectable - and the software on them is much less likely to have been encountered by their AV software to get into the Kaspersky database, too.)

Reply    

Myth

2012 Aug 16, 13:44
1
 

Re: Re: Re: Re: Re: Re: ??????

This is true - and all ATM's have printers, which in theory could print information.

But i still don't think that ATM's are worth the hard work of doing all this - and with all the inside information needet to reprogram the ATM, i think that person would have an easier time just going for the servers behind the ATM.

Reply    

Hans Adams

2012 Aug 16, 15:00
0
 

True for many embedded systems. Re: Re: Re: Re: Re: Re: ??????

(An ATM target could explain why the files are off the radar to Kaspersky, too: no Internet connectivity, so an infected device won't be phoning home or otherwise detectable - and the software on them is much less likely to have been encountered by their AV software to get into the Kaspersky database, too.)

Some targets: ATM, mobile base stations, SCADA, machine control (!) like Heidenhains' double processor systems, programming systems for plants and machines....

HA

Reply    

Mr. T

2012 Aug 15, 22:38
1
 

2. Append the pair with the second hard-coded 16-byte salt and bytes 0x15, 0x00

It's been years since I have used SoftICE/WinICE but if I remember correctly 0x00 used to mark end of string literal? So that "some words\x00more words" is seen by software as "some words".

My thoughs was that should or shouldn't the 0x00 be in the buffer that is used for MD5 hashing or is it just end of string that should be hashed?

I was also thinking about why would someone search for >0x007A and couple of things comes to my mind

1. they are looking for CLSID ( {BD84B380-8CA2-1069-AB1D-08000948534} ) of a specific application (from InstallShield folders etc). And part of the PATH + CLSID is the encryption/decryption key. Why do it like this? The CLSID may/should be unique in all versions of the software so it's quite good identifier that the target machine has the software and the version they are looking for. Many installers do append new folders to PATH. So they are looking for the combination of PATH + CLSID like "c:\program files\SecretApplication\{BD84B380-8CA2-1069-AB1D-08000948534}" This wuold guarantee that the software version exists in the target machine and there is no need to hardcode anything into the source code which could reveal the real target application or systems.

2. Windows has special CLSID's that can be used for multiple purposes. Try this: create a new folder somewhere in Windows 7 and rename it to ".{20d04fe0-3aea-1069-a2d8-08002b30309d}". Then access the folder with Windows Explorer => it will display "My Computer" instead of the contents of the new folder. Could it be that they are using CLSID in the folder name to prevent users to see the actual content of the folder? I also have some memories that some windows versions allowed to completely hide folders from windows explorer by using some CLSID in some specific way. There is also special CLSID for the Windows fonts folder and GAUSS has a font file attached.

3. Why the font anyway? There could be some security hole related to windows font handling, wouldn't be the first time. But there are test pages to detect if your computer is infected and has palida font installed. This of course also means that we can use the palida font to track infected machines and the web pages visited from those computers. Is there a way to search ( like using Google ) javascript and CSS-files of the web for the the magic word palida?

Edited by Mr. T, 2012 Aug 16, 10:03

Reply    

R&D_Mike

2012 Aug 16, 12:41
1
 

magic value “0x20332137”

I took a closer look at the check magic value in ...

"
7. Compare DWORDs in the decrypted buffer at positions 0 or 7 with magic value “0x20332137”. Proceed only if any of the DWORDs match.
"

... well, if you split this value into two 16bit values, possibly representing two Unicode Chars (since it seems the whole system is dealing with Unicode chars all the way) you get:

2033 -> Unicode DOUBLE PRIME (http://www.fileformat.info/info/unicode/char/2033/index.htm)
2137 -> Unicode GIMEL SYMBOL (http://www.fileformat.info/info/unicode/char/2137/index.htm)

That may be of interest, since it possibly checks for a hebrew char (or maybe a number representation (which would be 3 for that symbol), because U+2033 also is the European Number Terminator [ET]), and the "0 or 7" position check may be a sign for the possible right-to-left order writing of the hebrew language.

Greets,
R D_Mike

Reply    

oio

2012 Aug 16, 13:47
1
 

Anyone thought of ADS

Not sure whether this has been looked at or indeed is possible, but could the path be to an Alternate Data Stream? This technique is fairly common for 'hiding' malware with one notable sample being Poison Ivy.

Just a thought

Reply    

Lun4r

2012 Aug 16, 14:08
0
 

Using SSIDs instead of filenames

One could use the same encryption approach but use specific SSIDs instead of file names. This way the virus would turn into something like a 'proximity bomb' and decrypts and executes its payload only in a specific location. It wouldn't be hard to sniff out a few SSIDs near a target and it would be very hard to decrypt the payload w/o knowing the target location. (:

Reply    

Lun4r

2012 Aug 16, 14:45
1
 

%PROGRAMFILES%

See http://en.wikipedia.org/wiki/Program_Files
Windows localizes the name of this folder for some languages. If the encrypted payload contains its spreading mechanism (afaik it hasn't been found yet) it might explain why there are significantly more infections in Lebanon than anywhere else. Subfolders and values in $PATH may also have been localized.

Reply    

kilmiana

2012 Aug 16, 16:56
0
 

not default path for %PROGRAMFILES%

Likely %PROGRAMFILES% is a special path, and not the default one. This would ensure that only a specific target is hit. Interesting enough, this path could be large, I don't know enough about the involved code; but maybe a large string is just cut off and only a part is used for generation of the key.

Reply    

Vladimir Baranov

2012 Aug 16, 17:32
-1
 

Without Decryption

I am not world class cryptographer, however my suggestion is as follows:

Create a virus with identical code as Gauss, but with a disarmed warhead. Notify the research community that you are doing this step and send the specimen to Lebanon. Include instructions to phone home the decrypted version whenever it has an internet connection with using the currently infected computer as a key. At most you should have 100M decrypted samples, which should be easy to go through at home base. Alternatively, you can include filtering logic in the specimen and send back only content that you perceived was declared validly. This way you don’t need to spend considerable brain and computing resources to decrypt the obfuscated code.

Reply    

If you would like to comment on this article you must first
login


Bookmark and Share
Share

Analysis

Blog