SHREE LEARNING ACADEMY

A man-in-the-middle attack refers to a type of eavesdropping attack where the attackers intercept the communication between two entities, such as a client and server, by placing themselves in the communication stream. During a man-in-the-middle attack, both the client and server are under the impression that they are communicating with each other directly, and may even have established secure or encrypted communication links. However, the attacker is able to gain access to and potentially manipulate the communication.

Man-in-the-middle attacks can range from relatively straightforward to highly sophisticated. In certain instances, attackers can take advantage of DHCP vulnerabilities to distribute incorrect IP configurations, which may involve setting the attacker's IP address as the default gateway for the victim. From the various types of Man-in-the-Middle (MitM) attacks, some of them involve tampering with name-resolution systems like Domain Name System (DNS), Address Resolution Protocol (ARP), NetBIOS, and Windows Internet Name Service (WINS). Another approach to MitM attacks is to trick victims by employing fake proxy server settings or by spoofing the media access control (MAC) address.

The attacker, through any type of Man-in-the-Middle attack, can deceive both the client and server. This could result in the client mistakenly identifying the attacker as the server and the server mistaking the attacker for the client. Alternatively, the attacker could simply act as a transparent node along the communication pathway. If the deception is effective, the client will provide its login details to the imposter server (i.e., the attacker posing as the real server), who will then transmit the credentials to the authentic server while pretending to be the genuine client. Consequently, the client forms a connection (which could be encrypted) with the attacker, and the attacker establishes a connection with the server. While data is being sent back and forth between the genuine client and server systems, the attacker can intercept and view all the data, and may opt to alter the traffic to advance his/her deceitful scheme.

These types of attacks tend to be most effective when the attacker gains control over routing and name-resolution systems to position themselves prior to the initiation of client-to-server communication. Nonetheless, there are instances where man-in-the-middle attacks can be executed on current client-server communication connections (typically if they are unencrypted). An example of such a situation is with unsecured wireless networks. An attacker can send a deauthentication packet(the red packet in the figure below) to a wireless client, causing the victim system to disconnect. Afterwards, when the victim attempts to reconnect, the attacker can deceive the system into establishing a connection through itself, rather than connecting with the legitimate base station. This type of MitM attack can still be successful as the entire process can occur in just a fraction of a second. Unless the brief disconnection causes an interruption in an ongoing data transfer, the user may not even be aware of the event.

Prevention

To prevent man-in-the-middle attacks, effective countermeasures include implementing robust encryption protocols like IPsec, SSH, and TLS, as well as utilizing strong authentication methods, such as Domain Name System Security Extensions (DNSSEC) and mutual certificate authentication.

Transitive Access Attack

The transitive access attack, or exploitation, is closely linked to the man-in-the-middle attack. It involves leveraging transitive access as a potential backdoor or workaround for traditional access control methods. The concept behind transitive access is that User A is able to utilize Process B, and Process B in turn can use or trigger Process C, which has the ability to access Object D (as shown in Figure). In case Process B becomes unavailable or terminates before Process C finishes, Process C may unintentionally grant access to Object D back to User A, even if User A does not have direct or explicit access to Object D (as demonstrated in Figure). Certain types of access control measures may not address this issue directly. Therefore, it is crucial to validate all subject to object accesses before granting access, rather than solely relying on previous verifications.