Man-in-the-Middle Attack

In a man-in-the-middle (MITM) attack, the attacker eavesdrops on the communications between two targets, and then secretly relays and possibly alters the messages between the two parties who believe they are directly communicating with each other. In this scenario, the attacker successfully masquerades as another entity. The attacker also knows the content of the communication and can potentially tamper the message. It is quite akin to a mail carrier, who reads the content of the letter, or even replaces the content with their version.

Potential outcomes of a man-in-the-middle attack include theft of a user ID and password for an online account, a local FTP ID and password, or a secure shell (SSH) or telnet session. An MITM attack targets an application, exploiting an application vulnerability such as a faulty secure sockets layer (SSL) configuration. In the man-in-the-middle MITM attack, weaknesses and vulnerabilities in application code and configuration are leveraged to compromise the security of the application.

Differences between Man-in-the-Middle attacks and Meet-in-the-Middle attacks

The man-in-the-middle attack is sometimes confused with a meet-in-the-middle attack. But they are completely different. Man-in-the-middle attacks are an active attack on a cryptographic protocol. In this case, MITM attackers can intercept, relay, and even alter messages. 

A meet-in-the-middle attack involves a time-space trade-off to drastically reduce the effort to perform a brute-force attack. For example, if one can devise a mechanism to reduce an operation with a 64-bit key that would need 2^64 brute-force operations to 2^32 operations, a brute-force attack becomes feasible. Such a cryptanalytic attack is called the meet-in-the-middle attack. Because of the meet-in-the-middle attack, a brute-force attack, which was considered earlier as impossible, can become feasible.

Different types of Man-in-the-Middle attacks

Man-in-the-middle attacks exploit a number of different vulnerabilities, including:

1. Address Resolution Protocol (ARP) Cache Poisoning

2. Domain Name System (DNS) Spoofing

3. Session Hijacking

4. Secure Sockets Layer (SSL) Hijacking

ARP cache poisoning and Man-in-the-Middle attacks

Address Resolution Protocol (ARP) is used to dynamically map between internet host addresses and 10 Mb/s Ethernet addresses. ARP caches internet-Ethernet address mappings. In the normal ARP communication, the host computer sends a packet that has the source and destination IP address inside the packet. The host will broadcast it to all the devices connected to the network. The device, which has the target IP address, will only respond with the ARP reply with its MAC address in it. Then, communications take place between source and destination nodes. 

ARP is not a secure protocol, and it does not provide any authentication. As a result, the ARP reply packet can be easily spoofed. The spoofed ARP packet can be sent to the machine that sent the ARP request without knowing that this is not the actual machine but rather an MITM attack. This results in data breaches. The ARP cache table is updated by the attacker, which routes all network traffic to the attacker.

In ARP cache poisoning, the MITM attacker controls the network router, monitors the network traffic, and spoofs the ARP packets between the host and the destination. This enables the attacker to perform a man-in-the-middle attack. ARP poisoning is a hacking technique that sends a forged ARP request or ARP reply. ARP protocol is a stateless protocol. The protocol processes ARP replies without assigning or considering authentication. As a result, the ARP cache can be infected with records that contain wrong mappings of IP-MAC addresses.

A MITM hacker can exploit ARP cache poisoning to capture network traffic between two nodes. In a local network, the attacker uses ARP poisoning to make a node think the attacker’s machine is a router. Then, the hacker turns on an operating system feature called IP forwarding. This feature enables the hacker's system to forward any network traffic it receives. The hacker forwards the traffic to the actual router, but the attacker captures all network traffic between the victim's node and router. 

DNS spoofing and Man-in-the-Middle attacks

When someone tries to access a website in a browser, a Domain Name System (DNS) request is sent to the DNS server, and as a response, a DNS reply is obtained. This request-response exchange is mapped to a unique identification number. If the attacker can access the unique identification number, the attacker distributes a corrupt packet containing the identification number to the victim, thereby enabling the attack to be launched.

DNS spoofing is a kind of man-in-the-middle attack, where the hacker intercepts a DNS request. The attacker returns a DNS record that leads to the attacker’s server instead of the actual intended server. As DNS protocol uses unencrypted request/reply, a secure version of the protocol called DNSSEC should be used to mitigate DNS spoofing.

Man-in-the-Middle attacks and session hijacking

To avoid users needing to provide their credentials all the time, sessions are used in client-server settings. When the user authenticates to the application, the server remembers the user for a set amount of time. Sessions make the application convenient to use. But sessions allow MITM attackers to bypass the authentication scheme, and there are multiple attack methods designed specifically to steal user sessions.

When cookies are used as a session identifier, secure handling of the cookies needs to be ensured. Attackers will try to steal cookies, or more specifically, the session token information stored in those cookies. This MITM attack is called session hijacking because it relies on stealing the token to access the victim’s authenticated session.

Mitigation techniques for MITM session hijacking

Some of the techniques used to mitigate MITM session hijacking include:

• Anonymizing the session ID prevents attackers from enumerating the session ID and guessing the next session ID. There are well-documented patterns to implement this in the web application back end developed in technologies such as .NET, Ruby, Node.js, Python, and Java.

• Set a time-to-live session so that it gets invalidated after the elapse of this time. Session timeout defines the action window time for the user of the web application. If the session timeout is set to the minimal value in the context of the application, the time duration for the attacker to steal sensitive data in case of a security breach is limited to this time window.

• Implement a two-tier session system with two states—one for a short period immediately after a user logs in, and another that keeps users logged in but with a lower access level. Users can access less-secure areas for a longer period of time, but when trying to access more privileged areas, the user must authenticate again. A new session is created with privileged access for a short period of time and then degrades to a low-level session again.

• Secure the cookies. Secure cookies are a type of HTTP cookie that has secure attribute set. This limits the scope of the cookie to “secure” channels. For example, web browsers include secure cookies only when a request is made over an HTTPS connection and not on the HTTP connection.

• Use HTTPS over the entire site and not just for login and registration pages. If one must set up HTTPS, then the cookie should be set as secure. This will stop the cookie from being sent unless it is part of an HTTPS request. It prevents situations where insecure content from the same domain is sent over HTTP along with the session ID.

In addition to the above, extra measures need to be taken to avoid session hijacking attacks by binding the session to various user information such as the IP address, location information, or user agent. Since the information typically does not change in mid-use, these tactics can be used as a way to check if the session or account has been hijacked.

Secure sockets layer (SSL) hijacking and Man-in-the-Middle attacks 

For proper security, cryptography needs authentication. In the context of secure sockets layer/transport layer security (SSL/TLS), certificates are used for authentication. When attempting to connect to a particular hostname in the browser, the expectation is that the server will present a certificate that proves it has the right to handle traffic for that hostname. If the user receives an invalid certificate, the right thing to do is to abandon the connection attempt as part of the SSL/TLS handshake. Unfortunately, browsers do not do so. Because the web is full of invalid certificates, it is almost guaranteed that none of the invalid certificates a user encounters will be the result of an attack. Thus, web browsers do not enforce SSL security as part of the SSL handshake. Instead, browsers issue a certificate warning. If the user ignores the certificate warning, it can potentially result in a man-in-the-middle attack.

In mobile applications, a man-in-the-middle attack can be prevented with certificate pinning. This will prevent a data breach caused by the man-in-the-middle attack due to SSL/TLS hijacking. At the beginning of the SSL/TLS session, the client sends a “ClientHello” message. This indicates to the server that the client intends to begin an SSL/TLS communication. The client tells what cryptographic and compression algorithm to use and which SS/TLSL version it supports. The server responds with a “ServerHello” message that contains equivalent information that is present in the client's hello. Thus, both the client and server establish the version and algorithms to be used.

The server sends its certificate to the client, and if the server wants the client to authenticate itself, then it will send a request for the client’s certificate. The identity of the certificate is established using the certificate authority (CA) model. Unfortunately, this may result in the CA being compromised, and it is difficult to determine whether a remote system is operated by the correct party, even when the

authenticated certificate is presented. In applications, developers control both the client and the server software involved in the construction of the SSL/TLS channel. Therefore, the exact certificate the application expects to see can be set up. The CA signed certificates can be eliminated, and identities that the developer notarizes can be distributed. This is called pinning the certificate. 

Other SSL Man-in-the-Middle attack methods

Other man-in-the-middle attack methods related to SSL/TLS include:

• Exploitation of validation vulnerabilities. This man-in-the-middle attack uses a bug in the client when validating the credentials presented during the SSL/TLS handshake. If the validation is not implemented correctly, a bad actor can use a special invalid certificate or a certificate chain that cannot be distinguished from a valid one. 

• Rogue certificates. Rogue certificates are fraudulent CA certificates that are accepted by clients as genuine. They are difficult to obtain, but they are still a possibility. 

• Self-signed certificates. This attack presents the victim with a self-signed certificate that has most fields copied from the real one. Such a certificate is bound to generate a warning, but users are generally known to click through such warnings.

How to prevent Man-in-the-Middle attacks

Traditionally, static and dynamic vulnerability scanners have been used to detect vulnerabilities that are exploited during a man-in-the-middle attack. However, static and dynamic scanners simply cannot scale to support the requirements of modern software—whether in development or production. They lack the requisite accuracy, instead generating a huge number of false positives and false negatives. The reports they produce require significant time to triage, diagnose, and remediate. Finally, specialized skills and staff are required to manage the scans and review the reports. Security professionals with these skill sets often hard to recruit and retain. 

A different approach is required to uncover SSL/TLS vulnerabilities in applications that lead to man-in-the-middle attacks—one that embeds security instrumentation within the software. Interactive application security testing (IAST) enables security teams to shift left for security testing and to automate detection of vulnerabilities. Real-time analysis of results and virtual elimination of false positives and false negatives make IAST more suitable for detecting and mitigating vulnerabilities. IAST can be made part of the continuous integration/continuous deployment (CI/CD) pipeline and can be automated. Also, the process can be integrated with an issue-tracking system like Jira and other development and QA tools.