How Exploit Kit Operators are Misusing Diffie-Hellman Key Exchange

By Brooks Li, Stanley Liu and Allen Wu

Feedback from the Trend Micro™ Smart Protection Network™ has allowed us to discover that the notorious Angler and Nuclear exploit kits have included the latest Flash vulnerability (CVE-2015-5560) in their regular update. This means that systems with Adobe Flash Player 18.0.0.209 and earlier are vulnerable; however users running the latest version of Flash (18.0.0.232) are not affected.

This falls in line with our findings regarding the Angler exploit kit in our 2Q security roundup, where we noted Angler was very aggressive in its implementation of new Adobe Flash vulnerabilities. Frequently, the exploit kits are updated soon after an Adobe update to include any just-patched vulnerabilities. This coincides with a recently-discovered malvertisement campaign where Angler was also involved.

In a first for exploit kits, both Angler and Nuclear are now using the Diffie-Hellman key exchange protocol to help hide their network traffic from security researchers. This is also designed to help get around against security products that utilize PCAP replay to detect exploit-related malicious network traffic.

This means that even if a security researcher or an IT admin was able to detect and intercept the malicious network traffic tied to an exploit kit, they will not be able to simply replay the PCAP recording and decrypt the intercepted data. The data would be protected with an encryption key exchanged via the Diffie-Hellman protocol. This change was done solely to make life more difficult for researchers; it has no practical effect on the actual victims of these exploit kits.

How does the DH protocol work?

The simplest way we can explain the DH protocol is as follows:

Figure 1. Diffie-Hellman protocol

In this example, let’s identify the two sides in this communication process, namely Alice and Bob. Alice has the following information sets: a, g, p, A and B. Bob, on the other hand, has b, g, p, A and B. We note here that the information sets a and b will not be transferred across both parties, as they are private and random.

Using their own known parameters through the DH algorithm, Alice and Bob can each perform calculations and get the information set K. This K is the same for both parties, and serves as the key which each party can use to send data securely to the other party.

This setup prevents anyone who manages to intercept the data being transferred from decrypting said data, even with the use of applications such as Wireshark. The interception would only yield an incomplete list of information sets (namely, only g, p, A and B). As the two information sets a and b are not involved in the transfer process at all and remain with Alice and Bob, the interceptor is unable to obtain K and thus is unable to decrypt the raw data.

How to overcome the DH protocol

The DH protocol can be overcome via a man-in-the-middle (MITM) attack. This intercepts the DH key exchange in both directions, as seen in the example below:

Figure 2. Diffie-Hellman protocol, with man-in-the-middle Eve

Figure 2. Diffie-Hellman protocol, with man-in-the-middle

As in the original example, Alice has a, g, p, A and X while Bob has b, g, p, B and X. Our MITM program, which we’ll call Eve, has the information sets m, g, p, A, B and X through its interception of the exchange. Also like before, the information sets a, b,and m will not be involved in the data transfer, as they are private and random.

Using their own parameters and through the DH algorithm, Alice and Eve can each calculate and come up with the K1 information set. By the same token, Bob and Eve can also calculate and come up with K2. With these two information sets, they can then obtain the key needed to encrypt or decrypt the raw data, thus facilitating a secure data exchange. Our MITM program Eve can now decrypt the raw data as well.

Man-in-the-Middle Program

We can use Fiddler’s “Customize Rules” to implement this program, so that the whole saz file that we obtain can be used to replay the entire data transfer.

Finally, we can easily decrypt the second encrypted json data like following:

{ "Il": "flash.utils.ByteArray", "lll": "flash.system.Capabilities", "l": "flash.utils.Endian", "llI": "flash.media.Sound", "II": "flash.display.BitmapData", "lI": "win ", "lIl": "os",

……

"lllI": "activex", "IIII": "plugin", "llII": "windows 8", "llll": "windows 8.1", "IllI": "position",

……

"IIlI": "clear", "IIll": "loadCompressedDataFromByteArray", "llIl": "lock", "IlIll": "id3", "IlIII": "getPixel",

……

"IllII": "setPixel32", "IIIlI": "uncompress",

……
……
}

The encrypted data includes id3 in the head, as seen below:

Figure 3. Encrypted data (Click to enlarge)

The full Angler EK saz snapshot is below:

Figure 4. Encrypted data (Click to enlarge)

Trend Micro is already able to protect users against this threat. The existing Sandbox with Script Analyzer engine, which is part of Trend Micro™ Deep Discovery, can be used to detect this threat by its behavior without any engine or pattern updates. The Browser Exploit Prevention feature in our endpoint products such as Trend Micro™ Security, OfficeScan, and Worry-Free Business Security blocks the exploit once the user accesses the URL it is hosted in. Browser Exploit Prevention protects against exploits that target browsers or related plugins. And we also recommend that users stay up-to-date with the latest Flash Player version.

The SHA1s of the malicious Adobe Flash exploits are: