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.
See also
Man-in-the-browser attack - a web browser man-in-the-middle attack
Boy-in-the-browser - a simple web browser man-in-the-middle attack
Aspidistra transmitter - a radio transmitter used in the British World War II "Invasion" operation, an early man-in-the-middle attack.
Computer Security - The design of secure computer systems.
Security analysis - Cracking encrypted information without fully knowing the encryption method.
Digital signature - a guarantee of the authenticity of an encrypted text, usually the result of a calculation that only the author is expected to be able to perform.
Interlocking protocol - a specific protocol that circumvents possible man-in-the-middle attacks when the key may have been compromised.
Key Management - How to manage keys, including generating, exchanging and storing them.
Key agreement protocol - also known as key exchange protocol, a protocol that negotiates how to create a key suitable for communication between two parties.
Mutual Authentication - How communicating parties create confidence in each other's identities.
Cryptographically authenticated key agreement - Creates a protocol that uses a cryptographic key.
Quantum cryptography - The use of quantum mechanics to provide secure encryption (older methods, which relied on one-way functions).
Secure Channel - A means of making communications resistant to interception and tampering.
Spoofing Attack
HTTP Strict Transport Security
Reference Materials
1. ^ Leyden, John. Help! my Belkin router is spamming me. The Register. 2003-11-07.
2. ^ Petmail Documentation: Steal People's Time To Solve CAPTCHA Challenges. [2008-05-19].
3. ^ CAPTCHA Effectiveness. 2006-10-25.
4. ^ PC stripper helps spam to spread. BBC News. 2007-10-30.
Retrieved from "https://zh .wikipedia.org/w/index.php?title=Man-in-the-Middle Attack&oldid=40088488”
This page was last revised at 03:04 on Friday, May 13, 2016.
All text on this site is provided under the terms of the Knowledge Copyright Attribution-Share Alike 3.0 Agreement, and additional terms may also apply (see Terms of Use).
Wikipedia? and the Wikipedia logo are registered trademarks of the Wikimedia Foundation; Wikipedia? is a trademark of the Wikimedia Foundation.
The Wikimedia Foundation is a 501(c)(3) tax-exempt, non-profit, charitable organization registered in the state of Florida, USA.