Man in the Middle Attacks
4.5. Man in the Middle Attacks
4.5.1. What they are
As you already know, MitM is an attack in which the attacker is able to read, modify, or insert arbitrary data in packets transmitted between 2 peers.
The most simple scenario of a MitM attack can be described as follows: The attacker is able to gather the packets sent from the legitimate source of data transfer; these packets would then be redirected unmodified to the legitimate destination peer, which will not be able to understand the path the packet had followed.
MitM is an advanced technique and requires some prerequisites for the attack to be successful. The most common use of this attack is in LAN due to lac of security in Layer 2-3 protocols such as ARP and DHCP.
Let us see the attacks in details.
4.5.2. ARP Poisoning for MitM
ARP poisoning can be exploited to add fake information between 2 communication peers into a local network. In a scenario in which M (the attacker) wants to listen to all the traffic between A and B, M would have to send fake IP-MAC pairs to both A (server) and B (client), making himself the Man in the Middle.
The following are the steps for a successful attack:
M would pretend to be B to A: it will send a gratuitous ARP reply with the pair: IP_B->MAC_M
M would pretend to be A to B: it will send a gratuitous ARP reply with the pair: IP_A->MAC_M
Because of the TTL in hosts ARP caches, an attacker would need to send these packets at interval lower than the timeout (usually every 30 seconds is a good choice).
Once the gratuitous ARP packet is sent, B's ARP cache gets poisoned with the entry: IP_A->MAC_M
Next time B wants to send a packet to A, it will be forwarded to M.
This attack leaves the MAC address of the attacker in the ARP cache of the victims.
Another gratuitous ARP with correct values would restore the correct values after the sniffing is completed.
Countermeasures: Using static ARP is not a feasible approach into a large and always changing networks. Tools like arpwatch or arpcop can detect but not stop such attacks.
4.5.3. Local to Remote MitmM
When a host in a LAN wants to send packets to hosts outside the LAN it uses the default gateway. Default gateway MAC address must be used to forward the packet along with the correct IP address configured by administrator or given by DHCP.
The use of ARP poisoning in this scenario leads to a MitM attack from local to remote.
(See the diagram) Host A sends all the traffic aimed for the internet through the Attacker.
The following describes the steps that take place in the previous scenario:
Host A wants to send packets to the internet. It already has the IP of the gateway (IP_G) and it needs the associated MAC address.
M can use a gratuitous ARP reply to advertise itself as the default gateway: binds IP_G with his own (MAC_M)
All the traffic meant to leave the LAN will pass through M, which will then redirect it to the real gateway
4.5.4. DHCP Spoofing
DHCP is a service usually running on routers to dynamically assign or revoke IP address to new hosts on the network. The protocol is based on the UDP protocol and consists of an exchange of messages that are mostly sent in broadcast and are visible to the entire broadcast domain.
A host trying to enter the network asks for an IP. It will pick the best offer and use that IP address from that point on.
It is important to know hat if the whole communication succeeded, the DHCP server will also set the client default gateway. Due to its implementation, an attacker can spoof the DHCP messages in order to mount a MitM attack.
Before inspecting any further, let us see how DHCP works. The exchange of messages will be ass follows:
A new host is connected to the network: it send a DHCP Discovery broadcast packet using UDP on port 67 Since the host still needs an IP to be assigned, the source address of the packet is 0.0.0.0.
The DHCP server in the same broadcast domain responds with a DHCP offer packet composed as follows
The client responds with another broadcast packet: DHCP REQUEST The destination address is still broadcast since more than one DHCP server may have sent another DHCPOFFER.
The DHCP server that recognizes that itself as the winner sends a DHCPACK packet in broadcast. The YIADDR contains the client IP address while the CHADDR (Client Ethernet Address) contains the client MAC address.
All packets seen so far are sent in broadcast, thus everyone in the network receives the DHCP packets, even those hosts not involved in the communication.
What happens if we are in the same broadcast domain and we act as rogue DHCP server?
What we have to do is send our DHCPOFFER with a greater lease time. This lure the victim to choose our offer and then set configurations we will send.
As you already know, DHCP Servers not only offer IP addresses but they can also provide a default gateway for the network. By competing with legit DHCP servers (and winning by increasing the lease time), we can set ourselves as the default gateway.
In this way all the traffic leaving the network from the client host will reach our machine (attacker) and then the real gateway.
4.5.5. MitM in Public Key Exchange
The following topic will be a bit theoretical, but contain great examples of what MitM attacks can accomplish.
We will see how a man in the middle attack can be mounted to hijack the delivery of a public key into an asymmetric key encryption communication.
Notice that this affects only the key exchange and not the authentication mechanism that may be implemented to defeat MitM, unless you are able to fake root CA's signatures.
This is something that Sotirov did through the MD5 collisions in 2009.
First, you should be aware that asymmetric encryption is based on the encryption/decryption through 2 different keys.
One is the private key and must be kept absolutely confidential. The other is the Public key and can be given to a Key distribution center that will make it available to anyone.
If Alice wants a confidential conversation with Bob, she needs Bob's Public key.
If Bob has not given Alice the key, there is no other way to start a confidential conversation than getting the public key from a key distribution server or from Bob himself through the internet.
The steps Alice must take are:
Alice queries the Key server for Bob's public key
The Key Server returns Bob's public key to Alice
Alice encrypts her message using Bob's public key and sends the message to Bob
In the previous scenario, the MitM must be able to sniff traffic on Alice's network or on the Key Server network (through ARP poisoning or DHCP snooping, etc).
Of course it is far easier that this attack to be performed on Alice's network, since Key Servers have enhanced security measures.
In order for the attack to work, the Attacker (M) should be able to recognize the queries to the Key Server and take following steps to mount a successful MitM attack.
The MitM (attacker) should:
Intercept Alice's query and forward it to the Keys server
Intercept Bob's public key and store it for further use
Send his own Public key to Alice instead of Bob's public key
Alice would encrypt data using M's Public key thinking that she is using Bob's key
MitM would intercept Alice's encrypted messages, decrypting them with his private key and them forward them to Bob using Bob's public key saved at step 2)
4.5.6. LLMNR and NBT-NS Spoofing/Poisoning
LLMNR (Link-Local Multicast Name Resolution) and NBT-NS (NetBIOS Name Service) spoofing are also 2 very effective methods for capturing user's NTLMv1, NTLMv2, or LM (LAN Manager) hashes, through a MitM attack.
LLMNR is the successor of the NBT-NS, and was introduced into the Windows ecosystem starting with Windows Vista.
Both LLMNR and NBT-NS allow for machines within Windows-based network to find one another and is essentially a "fall-back" protocol used for the resolution of hostnames within a network when resolving of hostnames via DNS fails.
This process of hosts reverting to LLMNR or NBT-NS broadcast for host discovery results in NTLMv1/v2 hashes being sent over the network offering an attacker on the same network segment the opportunity to intercept, and replay the hashes to other systems, or alternatively, crack the intercepted hashes offline.
A typical scenario of attacking LLMNR or NBT-NS broadcast is as follows (see diagram):
Host A request an SMB share at the system
\\intranet\files, but instead of typingintranet, misatakenly typesintrnetSince
intrnetcan't be resolved by DNS as it is an unknown host, Host A then falls back to sending an LLMNR or NBT-NS broadcast message asking the LAN for the IP address for hostintrnetAn attacker (Host B), responds to this broadcast message caliming to be the
intrnetsystemHost A complies and sends Host B (the attacker) their username and NTLMv1 and v2 hash to the attacker
4.5.6.1. Responder/Multirelay
Responder is an excellent tool we can utilize for exploiting the LLMNT and NBT-NS weakness for capturing NTLMv1/v2 hashes and relaying them for authentication to other systems.
Responder works by listening for LLMNR or NBT-NS braodcast messages and spoofing responses to targeted hosts, resulting in intercepting hashes we can either pass (relay) to other systems, or crack offline.
We can use it conjunction with its "MultiRelay" tool, which will be responsible for relaying the hashes to other machines on the LAN, and can provide us with MultiRelay shell if successful.
Important: It should be noted that one of the pre-requisites for this attack is that "SMB Signing" has been disabled on the workstations. For determining whether ornnot SMB Signing is enabled on a target, we can use RUnFinger.py tool which is also included with the Responder toolkit.
The steps for launching this attack are generally as follows: 1. Modify the Responder.conf configuration file and disable the "SMB" server and "HTTP" server options by setting the values to "Off" 2. Launch Responder.py with -i (interface) and additionally, using the -lm option can help with downgrading NTLMv1 or v2 to LM hashes where supported: $ python Responder.py -I eth0 --lm Responder should begin responding to LLMNR and NBT-NS requests at this point.
Last updated