Alice and Bob can easily compute KA and KB, respectively, by computing the powers of group elements. Mallory, on the other hand, would have to solve the discrete logarithm problem for computing KA or KB, which is believed to be computationally hard. However, if Alice and Bob do not authenticate each others’ public keys, Mallory can place herself in the middle and create two communication channels, as shown in Figure 19.10.
In this attack, Mallory intercepts Bob’s public key B = gβ, replaces it with her own public key M = gμ, and sends M to Alice. Because no message authentication is used, Alice cannot verify that M is not Bob’s public key and replies to Mallory (who she erroneously believes to be Bob) with her public key A = gα. In the meantime, Mallory sends Bob her public key M instead of Alice’s public key A. Bob also cannot detect that he is actually talking to Mallory and not to Alice.
Figure 19.10: Example of a man-in-the-middle attack on unauthenticated Diffie-Hellman key exchange (see also Figure 7.3)
Finally, Alice and Bob compute the shared secret key as KA′ = Mα and KB′ = Mβ without noticing that they exchanged a key with Mallory rather than with each other. Instead of communicating with each other, Alice and Bob now communicate with Mallory. From this moment on, Mallory can decrypt Bob’s messages using KB′, re-encrypt them using KA′, and pass them to Alice (and vice versa by re-encrypting Alice’s messages using KB′). Moreover, Mallory can insert any message of her choice by encrypting it using KA′ or KB′.
A high-profile example of a man-in-the-middle attack is the incident that followed the compromise of Dutch certification authority DigiNotar in 2011. The attack started when one or more hackers breached DigiNotar’s web server hosting a vulnerable content management application. The hackers then moved laterally, eventually gaining access to a network segment where all of DigiNotar’s root secrets were stored [150].
The root secrets were used to generate the first batch of 128 rogue certificates. This was followed by several more batches, resulting in at least 531 certificates for 53 unique entities. Because the logs of the compromised servers were found to be manipulated and a large number of certificates later discovered in the wild were absent from appropriate databases, it is unknown how many rogue certificates the attackers generated in total.
Because the rogue certificates were generated with embedded OCSP information, the subsequent forensic investigation of DigiNotar’s breach was able to track the certificate deployment by examining DigiNotar’s OCSP responder logs [150]. The rogue certificates, as it turned out, were used to compromise Iranian Gmail users.
In the days following the breach, an estimated 300,000 IP addresses – the actual man-in-the-middle attack – were presented with fake certificates. Almost all of those IP addresses were located in Iran. The attackers intercepted users attempting to connect to Google’s Gmail server and, with the help of a rogue certificate, presented the users with a fake website to collect their Gmail passwords. In total, a staggering 654,313 OCSP requests for the rogue Google certificate were submitted from 298,140 unique IP addresses, 95% of which were within Iran.
Leave a Reply