What is a man-in-the-middle attack?

Man-in-the-middle attack

Wikipedia, the free encyclopedia

In the fields of cryptography and computer security, Man-in-the-middle attack , abbreviation: MITM) means that the attacker creates independent connections with both ends of the communication and exchanges the data they receive, making the two ends of the communication think that they are talking directly to each other through a private connection, but in fact The entire session is fully controlled by the attacker. In a man-in-the-middle attack, the attacker can intercept the communication between the two parties and insert new content. In many cases this is simple (for example, a man-in-the-middle attacker within range of an unencrypted Wi-Fi access point could insert himself into the network as a man-in-the-middle).

The prerequisite for a successful man-in-the-middle attack is that the attacker can disguise himself as every terminal participating in the session and not be seen through by other terminals. A man-in-the-middle attack is a (lack of) mutual authentication attack. Most encryption protocols incorporate special authentication methods to prevent man-in-the-middle attacks. For example, the SSL protocol can verify whether the certificate used by one or both parties participating in the communication is issued by an authoritative and trusted digital certificate certification authority, and can perform two-way identity authentication.

Directory

1 Additional transmission needs to be done through a secure channel

2 Attack examples

3 Defense against attacks

4 Forensic analysis of man-in-the-middle attacks

5 Other non-encrypted man-in-the-middle attacks

6 Implementation

7 See also

8 References

Requires additional transmission through a secure channel

Unlike chain protocols, all encryption systems that can resist man-in-the-middle attacks require some transmission or exchange through a secure channel. Additional information. In order to meet the different security requirements of different secure channels, many key exchange protocols have been studied.

Attack Example

Suppose Alice wants to communicate with Bob. Mallory, meanwhile, hopes to intercept the conversation to eavesdrop and possibly deliver a false message to Bob at some point.

First, Alice will ask Bob for his public key. If Bob sends his public key to Alice, and Mallory is able to intercept the public key, a man-in-the-middle attack can be carried out. Mallory sends Alice a forged message claiming to be Bob and attaching Mallory's own public key (instead of Bob's).

After receiving the public key, Alice believed that the public key belonged to Bob, so Alice encrypted her message with Mallory's public key (Alice thought it belonged to Bob) and The encrypted message is sent back to Bob. Mallory intercepts Alice's message back to Bob again and uses Mallory's own private key to decrypt the message. Mallory can also modify the message if she wishes, and then Mallory uses Bob's original The public key sent to Alice re-encrypts the message. When Bob receives the newly encrypted message, he will believe that it is from Alice.

1. Alice sent a message to Bob, but was intercepted by Mallory: Alice "Hi, Bob, I'm Alice. Give me your public key" --> Marlowe Bob

2. Mallory forwarded the intercepted message to Bob; at this time Bob could not tell whether the message was from the real Alice: Alice Malory Lori "Hi Bob, I'm Alice. Give me your public key" --> Bob

3. Bob responds to Alice's message and attaches his public key :Alice Mallory<--[Bob's public key]--Bob

4. Mallory replaced Bob's key in the message with her own key and changed the message Forward to Alice, claiming it is Bob's public key: Alice <-- [Mallory's public key] -- Mallory Bob

5. Alice uses what she thinks is Bob's public key Alice encrypted her message with Bob's public key, thinking only Bob could read it: Alice "Let's meet at the bus stop!" --[Encrypted using Mallory's public key] --> Marlowe Lee Bob

6. However, since this message is actually encrypted with Mallory's key, Mallory can decrypt it, read it, and modify it if he wishes. He re-encrypts using Bob's key and forwards the re-encrypted message to Bob: Alice Mallory "Wait for me at home!" --[Encrypted using Bob's public key] --> Bob < /p>

7. Bob believes that this message came from Alice through a secure transmission channel.

This example shows that Alice and Bob need some way to determine that they actually have the public key that belongs to each other and not the public key from the attacker. Otherwise, this type of attack is generally feasible and, in principle, can be launched against any communication message using public key-key technology. Fortunately, there are a variety of different techniques that can help protect against MITM attacks.

Defense against attacks

Many technologies to defend against man-in-the-middle attacks are based on the following authentication technologies:

Public Key Infrastructure

In PKI schemes, The main solution to defend against man-in-the-middle attacks is the mutual authentication mechanism of PKI. Using such a mechanism and having the application authenticate the user, the user device authenticates the application. But in the case of some rogue applications, this is not very useful, so care needs to be taken to distinguish rogue software from legitimate software.

Stronger mutual authentication, such as:

Keys (usually high entropy keys and therefore more secure), or passwords (usually low entropy keys) key, thereby reducing security)

Latency testing, such as using complex cryptographic hash functions to calculate to cause delays of tens of seconds; if both parties usually take 20 seconds to calculate, and the entire communication It takes 60 seconds to calculate to reach the other party, which indicates the existence of a third-party middleman.

Verification of the second (secure) channel

One-time pads are immune to man-in-the-middle attacks and are built on the security and trust of one-time pads. The integrity of the public key system must usually be guaranteed in some way, but confidentiality does not need to be maintained. Passwords and shared keys have additional confidentiality requirements. Public keys can be verified by certificate authorities, which are distributed through secure channels (for example, installed with a web browser or operating system). Public keys can also be verified online via Web Online Trust, and public keys can be distributed through secure means (for example, through face-to-face means).

View Key Exchange Protocols to learn about the different classes of protocols that use different key forms or ciphers to protect against man-in-the-middle attacks.

Forensic analysis of man-in-the-middle attacks

Capturing and analyzing network packets from links suspected of being man-in-the-middle attacks can determine whether there is a man-in-the-middle attack. When conducting network analysis and forensics for suspected SSL man-in-the-middle attacks, important analysis evidence includes:

The IP address of the remote server

DNS domain name resolution server

X.509 Certificate Server

Is the certificate a self-signed certificate?

Is the certificate issued by a trusted authority?

Has the certificate been revoked?

Has the certificate been changed recently?

Are other clients on the Internet also getting the same certificate?

Other non-encrypted man-in-the-middle attacks

A well-known example of a non-encrypted man-in-the-middle attack was caused by a 2003 version of the Belkin wireless router. It periodically takes over HTTP connections passing through it, preventing packets from reaching their destination. and returns its own response to the request as the reply. The response it sent was to display an ad for other Belkin products where the user would have been shown a web page. After outcry from users who knew the technical details, the feature was removed by Belkin from subsequent versions of the router's firmware. [1]

Another typical example of a non-encrypted man-in-the-middle attack is the "Turing Porn Farm". Brian Warner said this was a "conceivable attack" that spammers could use to bypass CAPTCHAs. The spammer has set up a pornographic website, and accessing the pornographic website requires the user to solve some authentication issues. These verification questions are actually verification questions from other websites. This can achieve the purpose of bypassing website verification and sending spam emails. [2] However, Jeff Atwood pointed out that this attack was only theoretical - there is no evidence that the spammers ever created the Turing porn farm in 2006. [3] However, there were news reports in October 2007 that spammers had indeed created a Windows game that would reward users with pornographic images after they typed in the verification code they received from Yahoo for their registered email address. [4] This will allow spammers to create temporary free email accounts to send spam.

Implementation

dsniff - A tool to implement SSH and SSL man-in-the-middle attacks

Cain and Abel - A Windows graphical interface tool that can perform man-in-the-middle attacks, sniffing Detection and ARP poisoning

Ettercap - a LAN-based man-in-the-middle attack tool

Karma - a tool that uses 802.11 Evil Twin to perform MITM attacks

AirJack - A tool to demonstrate 802.11 MITM attacks

SSLStrip A tool to demonstrate SSL-based MITM attacks.

SSLSniff is a tool for SSL-based MITM attacks. It was originally implemented by exploiting a flaw in Internet Explorer.

Intercepter-NG -- A Windows network password sniffer with ARP poisoning attack capabilities. SSL-based MITM attacks including SSLStrip can be carried out.

Mallory - A transparent TCP and UDP MiTMing proxy. Extensions to MITM SSL, SSH and many other protocols.

wsniff - A tool for 802.11 HTTP/HTTPS based MITM attacks

Additional card reader installed on the bank card slot of the ATM and additional password installed on the keyboard logger.