Downadup—Advanced Crypto Protection

Editor’s Note: This is the concluding article in Symantec’s multi-part series covering specific and interesting aspects of W32.Downadup.

The conclusion of my previous blog posed an interesting question to readers: “...seeing as the list of the future domains was publicly disclosed on the Web, why hadn’t any other cyber criminals taken advantage of the predictions?” Antivirus companies and many independent security researchers were able to crack the domain prediction algorithm used by the worm, so it is reasonable to believe that other people were able to achieve the same result, but with different intentions. In fact, predicting what the next domain will be creates the perception that someone can take control over the botnet, and, for example, start pushing a bank Trojan to these millions of machines infected with Downadup. We already know that there’s no honor among thieves, and so it won’t be a surprise if we see future Downadup domains registered by other criminals. There are also credible reports that this is already happening because some of the future domains pointed to well-known IP addresses used by the ASProx gang in the past.

Unfortunately, the takeover is not such a simple job. Registering a domain with the intent of stealing the Downadup botnet is not enough. Nobody, except Downadup’s authors, will be able to push files to the botnet because of some advanced security measures utilized by the gang.

We analyzed the downloading routine of Downadup.B and we found that is secured by asymmetric cryptography. The digital signature and very long crypto keys make this job impossible. The payload downloaded from one of the domains is encrypted with RC4 (using a 64-bytes key) and then digitally signed by the authors using their private key. In fact, the worm binary contains the corresponding public key (4096-bit) and a value that looks like the public exponent. The algorithm looks similar to RSA encryption, or perhaps it’s just one of the asymmetric algorithms available today.

Figure 1. Public crypto key hardcoded in the worm binary

At the moment, no download has been observed from Downadup infected machines, so nobody is able to tell you what the payload is, presumed to be downloaded over HTTP at some point in the future by the botnet. So, we can’t tell you today what the unwanted gift will be, but we can tell you what it will look like:

Figure 2. Code snippet of the header-parsing routine

Looking at the code snippet above, we can say that “package” downloaded by Downadup will have a general header with a size of 12 bytes, followed by multiple instances of encrypted and digitally signed payloads. Each of these payloads will have its own header (20 bytes) and will contain an appended blob of data at the end (512 bytes), which is the unique digital signature of the payload. The following diagram shows the structure of the whole package and that of a single payload.

Downadup authors tried to put basic safety checks in place so the code verifies that the received package is bigger than 12 bytes, and also that the size stored in the general header matches the size of data received. There are also checks to avoid reading after the end of the data (ironically, they seem very afraid of having buffer overflows in the code!).

The structures and the fields of the headers are defined below:

GENERAL_HEADER (size = 12 bytes)

00    DW    num_of_entries    ; num of payloads in the package
04    DW    size_of_data        ; size of data without this header
08    DW    (not_used)        ; ?

PAYLOAD_HEADER (size = 20 bytes)

00     DW    dwFileNumber    ; unique identifier for this payload
04     DW    dwUnknownX        ; ?
08     DW    dwExpTime_lo    ; expiration time (low)
0C     DW    dwExpTime_hi    ; expiration time (high)
10     DW    dwLengthOfFile      ; size of encrypted data

The verifier routine runs a loop that parses the header of each payload to locate the end of the encrypted data (dwLengthOfFile) where the Digital Signature is stored. Using the asymmetric algorithm and public exponent/modulus values, the code decrypts the 512-bytes digest and extracts two important things: the real decryption key (64-bytes, used later with RC4 algorithm) and the hash value of the encrypted data (64-bytes). The following diagram shows what the worm expects after asymmetric decryption of the digital signature. 

Finally, the worm performs all of the validations that will allow it to verify if the payload is trusted and has been created by the real author, by following these steps:

1.    It verifies that the hash extracted from the signature matches with the hash calculated over the encrypted data (the encrypted message has not been altered);
2.    It runs RC4 decryption over the encrypted data with the 64-bytes key extracted from the signature;
3.    It calculates the hash of the decrypted data after RC4 and verifies that this new hash matches with the decryption key (i.e., the encryption key is the hash of the plaintext message).

The hashing algorithm used by the worm does not look similar to any of the well-known algorithms. It produces a hash value of 64-bytes (512-bits), but it’s not the popular SHA-512. We just know that the hash value of null (=empty file) produced by this custom algorithm is the following sequence:

6B 7F 33 82 1A 2C 06 0E CD D8 1A EF DD EA 2F D3 C4 72 02 70 E1 86 54 F4 CB 08 EC E4 9C CB 46 9F
8B EE EE 7C 83 12 06 BD 57 7F 9F 26 30 D9 17 79 79 20 3A 94 89 E4 7E 04 DF 4E 6D EA A0 F8 E0 C0

After all of this analysis, the conclusion is that the Downadup authors have taken extreme measure to protect their job and this again demonstrates the level of professionalism of these criminals. We suppose that these crooks are afraid of just two things right now: the $250K bounty reward offered by Microsoft, and the risk of having an exploitable buffer overflow in their code. In fact, while the crypto protection can’t be easily bypassed, it may be possible that their code has some exploitable overflow condition that can allow some other bad guy to push a malformed package that will DoS or exploit the worm. The code seems to have basic checks against large buffers; but, for example, there could be problems with a buffer smaller than expected or with integer wrap caused by invalid sizes. But, that’s another story.

Note: Big thanks to Eric Chien for his help with this analysis.