Man-in-the-middle attack

Last updated

In cryptography and computer security, a man-in-the-middle [lower-alpha 1] (MITM) attack or in-path attack is a cyberattack where the attacker secretly relays and possibly alters the communications between two parties who believe that they are directly communicating with each other, as the attacker has inserted themselves between the two parties. [9]

Contents

One example of a MITM attack is active eavesdropping, in which the attacker makes independent connections with the victims and relays messages between them to make them believe they are talking directly to each other over a private connection, when in fact the entire conversation is controlled by the attacker. [10] In this scenario, the attacker must be able to intercept all relevant messages passing between the two victims and inject new ones. This is straightforward in many circumstances; for example, an attacker within range of an Wi-Fi access point hosting a network without encryption could insert themselves as a man in the middle. [11] [12] [13]

As it aims to circumvent mutual authentication, a MITM attack can succeed only when the attacker impersonates each endpoint sufficiently well to satisfy their expectations. Most cryptographic protocols include some form of endpoint authentication specifically to prevent MITM attacks. For example, TLS can authenticate one or both parties using a mutually trusted certificate authority. [14] [12]

Example

An illustration of the man-in-the-middle attack Man in the middle attack.svg
An illustration of the man-in-the-middle attack

Suppose Alice wishes to communicate with Bob. Meanwhile, Mallory wishes to intercept the conversation to eavesdrop (breaking confidentiality) with the option to deliver a false message to Bob under the guise of Alice (breaking non-repudiation). Mallory would perform a man-in-the-middle attack as described in the following sequence of events.

  1. Alice sends a message to Bob, which is intercepted by Mallory:
    Alice"Hi Bob, it's Alice. Give me your key."  Mallory  Bob
  2. Mallory relays this message to Bob; Bob cannot tell it is not really from Alice:
    Alice  Mallory"Hi Bob, it's Alice. Give me your key."  Bob
  3. Bob responds with his encryption key:
    Alice  Mallory  [Bob's key]Bob
  4. Mallory replaces Bob's key with her own, and relays this to Alice, claiming that it is Bob's key:
    Alice  [Mallory's key]Mallory  Bob
  5. Alice encrypts a message with what she believes to be Bob's key, thinking that only Bob can read it:
    Alice"Meet me at the bus stop!" [encrypted with Mallory's key]  Mallory  Bob
  6. However, because it was actually encrypted with Mallory's key, Mallory can decrypt it, read it, modify it (if desired), re-encrypt with Bob's key, and forward it to Bob:
    Alice  Mallory"Meet me at the van down by the river!" [encrypted with Bob's key]  Bob
  7. Bob thinks that this message is a secure communication from Alice.

This example shows the need for Alice and Bob to have a means to ensure that they are truly each using each other's public keys, and not the public key of an attacker. [15] Otherwise, such attacks are generally possible, in principle, against any message sent using public-key technology.

Defense and detection

MITM attacks can be prevented or detected by two means: authentication and tamper detection. Authentication provides some degree of certainty that a given message has come from a legitimate source. Tamper detection merely shows evidence that a message may have been altered.

Authentication

All cryptographic systems that are secure against MITM attacks provide some method of authentication for messages. Most require an exchange of information (such as public keys) in addition to the message over a secure channel. Such protocols, often using key-agreement protocols, have been developed with different security requirements for the secure channel, though some have attempted to remove the requirement for any secure channel at all. [16]

A public key infrastructure, such as Transport Layer Security, may harden Transmission Control Protocol against MITM attacks. In such structures, clients and servers exchange certificates which are issued and verified by a trusted third party called a certificate authority (CA). If the original key to authenticate this CA has not been itself the subject of a MITM attack, then the certificates issued by the CA may be used to authenticate the messages sent by the owner of that certificate. Use of mutual authentication, in which both the server and the client validate the other's communication, covers both ends of a MITM attack. If the server or client's identity is not verified or deemed as invalid, the session will end. [17] However, the default behavior of most connections is to only authenticate the server, which means mutual authentication is not always employed and MITM attacks can still occur.

Attestments, such as verbal communications of a shared value (as in ZRTP), or recorded attestments such as audio/visual recordings of a public key hash [18] are used to ward off MITM attacks, as visual media is much more difficult and time-consuming to imitate than simple data packet communication. However, these methods require a human in the loop in order to successfully initiate the transaction.

HTTP Public Key Pinning (HPKP), sometimes called "certificate pinning," helps prevent a MITM attack in which the certificate authority itself is compromised, by having the server provide a list of "pinned" public key hashes during the first transaction. Subsequent transactions then require one or more of the keys in the list must be used by the server in order to authenticate that transaction.

DNSSEC extends the DNS protocol to use signatures to authenticate DNS records, preventing simple MITM attacks from directing a client to a malicious IP address.

Tamper detection

Latency examination can potentially detect the attack in certain situations, [19] such as with long calculations that lead into tens of seconds like hash functions. To detect potential attacks, parties check for discrepancies in response times. For example: Say that two parties normally take a certain amount of time to perform a particular transaction. If one transaction, however, were to take an abnormal length of time to reach the other party, this could be indicative of a third party's interference inserting additional latency in the transaction.

Quantum cryptography, in theory, provides tamper-evidence for transactions through the no-cloning theorem. Protocols based on quantum cryptography typically authenticate part or all of their classical communication with an unconditionally secure authentication scheme. As an example Wegman-Carter authentication. [20]

Forensic analysis

Captured network traffic from what is suspected to be an attack can be analyzed in order to determine whether there was an attack and, if so, determine the source of the attack. Important evidence to analyze when performing network forensics on a suspected attack includes: [21]

Notable instances

A Stingray phone tracker is a cellular phone surveillance device that mimics a wireless carrier cell tower in order to force all nearby mobile phones and other cellular data devices to connect to it. The tracker relays all communications back and forth between cellular phones and cell towers. [22]

In 2011, a security breach of the Dutch certificate authority DigiNotar resulted in the fraudulent issuing of certificates. Subsequently, the fraudulent certificates were used to perform MITM attacks. [23]

In 2013, Nokia's Xpress Browser was revealed to be decrypting HTTPS traffic on Nokia's proxy servers, giving the company clear text access to its customers' encrypted browser traffic. Nokia responded by saying that the content was not stored permanently, and that the company had organizational and technical measures to prevent access to private information. [24]

In 2017, Equifax withdrew its mobile phone apps following concern about MITM vulnerabilities. [25]

Other notable real-life implementations include the following:

See also

Notes

  1. Also known as a monster-in-the-middle, [1] [2] machine-in-the-middle, [3] meddler-in-the-middle, [4] manipulator-in-the-middle, [5] [6] person-in-the-middle [7] (PITM), or adversary-in-the-middle [8] (AITM) attack.

Related Research Articles

<span class="mw-page-title-main">Diffie–Hellman key exchange</span> Method of exchanging cryptographic keys

Diffie–Hellman key exchange is a mathematical method of securely exchanging cryptographic keys over a public channel and was one of the first public-key protocols as conceived by Ralph Merkle and named after Whitfield Diffie and Martin Hellman. DH is one of the earliest practical examples of public key exchange implemented within the field of cryptography. Published in 1976 by Diffie and Hellman, this is the earliest publicly known work that proposed the idea of a private key and a corresponding public key.

<span class="mw-page-title-main">HTTPS</span> Extension of the HTTP communications protocol to support TLS encryption

Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). It uses encryption for secure communication over a computer network, and is widely used on the Internet. In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL). The protocol is therefore also referred to as HTTP over TLS, or HTTP over SSL.

Kerberos is a computer-network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner. Its designers aimed it primarily at a client–server model, and it provides mutual authentication—both the user and the server verify each other's identity. Kerberos protocol messages are protected against eavesdropping and replay attacks.

<span class="mw-page-title-main">Public-key cryptography</span> Cryptographic system with public and private keys

Public-key cryptography, or asymmetric cryptography, is the field of cryptographic systems that use pairs of related keys. Each key pair consists of a public key and a corresponding private key. Key pairs are generated with cryptographic algorithms based on mathematical problems termed one-way functions. Security of public-key cryptography depends on keeping the private key secret; the public key can be openly distributed without compromising security.

Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.

In cryptography, a certificate authority or certification authority (CA) is an entity that stores, signs, and issues digital certificates. A digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others to rely upon signatures or on assertions made about the private key that corresponds to the certified public key. A CA acts as a trusted third party—trusted both by the subject (owner) of the certificate and by the party relying upon the certificate. The format of these certificates is specified by the X.509 or EMV standard.

In computer security, challenge-response authentication is a family of protocols in which one party presents a question ("challenge") and another party must provide a valid answer ("response") to be authenticated.

<span class="mw-page-title-main">Key exchange</span> Cryptographic protocol enabling the sharing of a secret key over an insecure channel

Key exchange is a method in cryptography by which cryptographic keys are exchanged between two parties, allowing use of a cryptographic algorithm.

End-to-end encryption (E2EE) is a private communication system in which only communicating users can participate. As such, no one, including the communication system provider, telecom providers, Internet providers or malicious actors, can access the cryptographic keys needed to converse.

FTPS is an extension to the commonly used File Transfer Protocol (FTP) that adds support for the Transport Layer Security (TLS) and, formerly, the Secure Sockets Layer cryptographic protocols.

In cryptography, the interlock protocol, as described by Ron Rivest and Adi Shamir, is a protocol designed to frustrate eavesdropper attack against two parties that use an anonymous key exchange protocol to secure their conversation. A further paper proposed using it as an authentication protocol, which was subsequently broken.

In cryptography, forward secrecy (FS), also known as perfect forward secrecy (PFS), is a feature of specific key-agreement protocols that gives assurances that session keys will not be compromised even if long-term secrets used in the session key exchange are compromised, limiting damage. For HTTPS, the long-term secret is typically the private key of the server. Forward secrecy protects past sessions against future compromises of keys or passwords. By generating a unique session key for every session a user initiates, the compromise of a single session key will not affect any data other than that exchanged in the specific session protected by that particular key. This by itself is not sufficient for forward secrecy which additionally requires that a long-term secret compromise does not affect the security of past session keys.

Authenticated Encryption (AE) is an encryption scheme which simultaneously assures the data confidentiality and authenticity. Examples of encryption modes that provide AE are GCM, CCM.

In public-key cryptography, the Station-to-Station (STS) protocol is a cryptographic key agreement scheme. The protocol is based on classic Diffie–Hellman, and provides mutual key and entity authentication. Unlike the classic Diffie–Hellman, which is not secure against a man-in-the-middle attack, this protocol assumes that the parties have signature keys, which are used to sign messages, thereby providing security against man-in-the-middle attacks.

Opportunistic encryption (OE) refers to any system that, when connecting to another system, attempts to encrypt communications channels, otherwise falling back to unencrypted communications. This method requires no pre-arrangement between the two systems.

Email encryption is encryption of email messages to protect the content from being read by entities other than the intended recipients. Email encryption may also include authentication.

A TLS termination proxy is a proxy server that acts as an intermediary point between client and server applications, and is used to terminate and/or establish TLS tunnels by decrypting and/or encrypting communications. This is different from TLS pass-through proxies that forward encrypted (D)TLS traffic between clients and servers without terminating the tunnel.

In cryptography, the Salted Challenge Response Authentication Mechanism (SCRAM) is a family of modern, password-based challenge–response authentication mechanisms providing authentication of a user to a server. As it is specified for Simple Authentication and Security Layer (SASL), it can be used for password-based logins to services like LDAP, HTTP, SMTP, POP3, IMAP and JMAP (e-mail), XMPP (chat), or MongoDB and PostgreSQL (databases). For XMPP, supporting it is mandatory.

A downgrade attack, also called a bidding-down attack, or version rollback attack, is a form of cryptographic attack on a computer system or communications protocol that makes it abandon a high-quality mode of operation in favor of an older, lower-quality mode of operation that is typically provided for backward compatibility with older systems. An example of such a flaw was found in OpenSSL that allowed the attacker to negotiate the use of a lower version of TLS between the client and server. This is one of the most common types of downgrade attacks. Opportunistic encryption protocols such as STARTTLS are generally vulnerable to downgrade attacks, as they, by design, fall back to unencrypted communication. Websites which rely on redirects from unencrypted HTTP to encrypted HTTPS can also be vulnerable to downgrade attacks, as the initial redirect is not protected by encryption.

Identity-based conditional proxy re-encryption (IBCPRE) is a type of proxy re-encryption (PRE) scheme in the identity-based public key cryptographic setting. An IBCPRE scheme is a natural extension of proxy re-encryption on two aspects. The first aspect is to extend the proxy re-encryption notion to the identity-based public key cryptographic setting. The second aspect is to extend the feature set of proxy re-encryption to support conditional proxy re-encryption. By conditional proxy re-encryption, a proxy can use an IBCPRE scheme to re-encrypt a ciphertext but the ciphertext would only be well-formed for decryption if a condition applied onto the ciphertext together with the re-encryption key is satisfied. This allows fine-grained proxy re-encryption and can be useful for applications such as secure sharing over encrypted cloud data storage.

References

  1. Gabbi Fisher; Luke Valenta (March 18, 2019). "Monsters in the Middleboxes: Introducing Two New Tools for Detecting HTTPS Interception".
  2. Fassl, Matthias (April 23, 2018). Usable Authentication Ceremonies in Secure Instant Messaging (PDF) (Dipl.-Ing.). Technische Universität Wien.
  3. "Fact Sheet: Machine-in-the-Middle Attacks". Internet Society. March 24, 2020.
  4. Poddebniak, Damian; Ising, Fabian; Böck, Hanno; Schinzel, Sebastian (August 13, 2021). Why TLS Is Better Without STARTTLS: A Security Analysis of STARTTLS in the Email Context (PDF). 30th USENIX Security Symposium. p. 4366. ISBN   978-1-939133-24-3. When a Meddler-in-the-Middle (MitM) attacker removes the STARTTLS capability from the server response, they can easily downgrade the connection to plaintext.
  5. "Manipulator-in-the-middle attack". OWASP Community Pages. OWASP Foundation. Retrieved August 1, 2022.
  6. "MitM". MDN Web Docs . Mozilla. July 13, 2022. Retrieved August 1, 2022.
  7. "Person-in-the-middle". October 11, 2020.
  8. "From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud". Microsoft . July 12, 2022.
  9. Elakrat, Mohamed Abdallah; Jung, Jae Cheon (June 1, 2018). "Development of field programmable gate array–based encryption module to mitigate man-in-the-middle attack for nuclear power plant data communication network". Nuclear Engineering and Technology. 50 (5): 780–787. doi: 10.1016/j.net.2018.01.018 .
  10. Wang, Le; Wyglinski, Alexander M. (October 1, 2014). "Detection of man-in-the-middle attacks using physical layer wireless security techniques: Man-in-the-middle attacks using physical layer security". Wireless Communications and Mobile Computing. 16 (4): 408–426. doi:10.1002/wcm.2527.
  11. 1 2 "Comcast continues to inject its own code into websites you visit". December 11, 2017.
  12. 1 2 Callegati, Franco; Cerroni, Walter; Ramilli, Marco (2009). "Man-in-the-Middle Attack to the HTTPS Protocol". IEEE Security & Privacy Magazine. 7: 78–81. doi:10.1109/MSP.2009.12. S2CID   32996015.
  13. Tanmay Patange (November 10, 2013). "How to defend yourself against MITM or Man-in-the-middle attack". Archived from the original on November 24, 2013. Retrieved November 25, 2014.
  14. 1 2 "Comcast still uses MITM javascript injection to serve unwanted ads and messages". December 28, 2016.
  15. "diffie hellman - MiTM on RSA public key encryption". Cryptography Stack Exchange.
  16. Merkle, Ralph C (April 1978). "Secure Communications Over Insecure Channels". Communications of the ACM. 21 (4): 294–299. CiteSeerX   10.1.1.364.5157 . doi:10.1145/359460.359473. S2CID   6967714. Received August, 1975; revised September 1977
  17. Sasikaladevi, N. and D. Malathi. 2019. “Energy Efficient Lightweight Mutual Authentication Protocol (REAP) for MBAN Based on Genus-2 Hyper-Elliptic Curve.” Wireless Personal Communications 109(4):2471–88.
  18. Heinrich, Stuart (November 28, 2013). "Public Key Infrastructure based on Authentication of Media Attestments". arXiv: 1311.7182v1 [cs.CR].
  19. Aziz, Benjamin; Hamilton, Geoff (2009). "Detecting Man-in-the-Middle Attacks by Precise Timing" (PDF). 2009 Third International Conference on Emerging Security Information, Systems and Technologies. pp. 81–86. doi:10.1109/SECURWARE.2009.20. ISBN   978-0-7695-3668-2. S2CID   18489395.
  20. Cederlöf, Jörgen. "5. Unconditionally secure authentication". liu.se.
  21. "Network Forensic Analysis of SSL MITM Attacks". NETRESEC Network Security Blog. March 27, 2011. Retrieved March 27, 2011.
  22. Zetter, Kim (March 3, 2014). "Florida Cops' Secret Weapon: Warrantless Cellphone Tracking". Wired.com . Retrieved June 23, 2014.
  23. Zetter, Kim (September 20, 2011). "DigiNotar Files for Bankruptcy in Wake of Devastating Hack". Wired. ISSN   1059-1028 . Retrieved March 22, 2019.
  24. Meyer, David (January 10, 2013). "Nokia: Yes, we decrypt your HTTPS data, but don't worry about it". Gigaom, Inc. Archived from the original on April 8, 2019. Retrieved June 13, 2014.
  25. Weissman, Cale Guthrie (September 15, 2017). "Here's Why Equifax Yanked Its Apps From Apple And Google Last Week". Fast Company.
  26. Moyer, Edward (September 12, 2013). "NSA disguised itself as Google to spy, say reports". CNET . Archived from the original on September 15, 2013.
  27. "Comcast using man-in-the-middle attack to warn subscribers of potential copyright infringement". TechSpot. November 23, 2015.