Skip to main content

Computer Systems Security Planning for Success

Dr. Jan Pearce, Editor

Section 5.1 Interception Attacks

Interception attacks rely on the ability to intercept network communications. This may be due to the nature of the network being used or sometimes other methods may leveraged to better position the attacker. These attacks generally involve forging fictitious messages, recording transmitted data, or altering the contents of messages while on a network. This family of attacks places all parts of the CIA triad at risk.
🔗

Subsection 5.1.1 MitM

Diagram illustrating a Man-in-the-Middle (MitM) attack where an attacker intercepts communication between a user and a web server.
The diagram shows three entities: a "User" depicted on the left, a "Man in the Middle" in the center, and a "Web Server" on the right. An "Old Connection" is shown as a dashed grey line with arrows at both ends, directly connecting the "User" and the "Web Server", representing their original, direct communication path. Below this, a "New Connection" illustrates the MitM attack. This path shows a solid black line with an arrow from the "User" pointing to the "Man in the Middle", and another solid black line with an arrow from the "Man in the Middle" pointing to the "Web Server". This indicates that the "Man in the Middle" is positioned to intercept and potentially alter the communication flowing between the "User" and the "Web Server".
🔗
Figure 5.1.1. Man-in-the-Middle (MitM)
🔗
A man in the middle attack (MitM) is a blanket term applied when an attacker is intercepting communication. A typical attack involves eavesdropping and possibly modifying messages between two parties. Encryption can be used to mitigate the attack, making it impossible for an attacker to decrypt the messages they are intercepting. That being said, particular attention must be paid to the handshaking/key exchange protocol to be sure that an attacker does not gain access to the key(s) being used. What follows is an example of MitM being used to intercept and modify the public key exchange:
🔗
Diagram illustrating a Man-in-the-Middle (MitM) attack during a public key exchange, where the attacker substitutes their own public key.
The diagram depicts a sequence of communications involving "Bob" on the left, "Alice" on the right, and a "MitM" (Man-in-the-Middle) attacker positioned centrally. Initially, Bob requests Alice’s public key by sending a message, "Send me your public key so I can send a secret," indicated by an arrow from Bob to Alice. Alice attempts to respond with her public key, "My public key is ABCD"; however, this message, shown as an arrow from Alice towards Bob, is intercepted by the MitM attacker. The attacker then deceives Bob by sending their own public key, "My public key is WXGZ," as if it came from Alice (arrow from MitM to Bob). Consequently, when Bob sends his "Secret (encrypted w/WXGZ)," believing he is communicating securely with Alice, the message (arrow from Bob towards Alice) is actually intercepted by the MitM. The MitM, possessing the corresponding private key to WXGZ, can decrypt this secret. Finally, the diagram shows the MitM forwarding a message "Secret (encrypted w/ABCD)" to Alice (arrow from MitM to Alice), implying the attacker has decrypted Bob’s original secret, possibly altered it, and then re-encrypted it using Alice’s genuine public key (ABCD) to complete the deception and maintain the flow of communication.
🔗
Figure 5.1.2. Man-in-the-Middle Sequence of Communications
🔗
In the above example the MitM allows the first message to pass unmolested, but tampers with the exchange of the public key. By passing it’s own public key to Bob, the MitM has to ability to decrypt the messages that Bob sends and can still use Alice’s public key to re-encrypt the messages at pass them to her. You can see how if two public keys are exchanged in this manner it would be possible to set up a MitM attack where despite encryption all messages can be seen.
🔗
🔗

Subsection 5.1.2 MitB

MitB stands for man in the browser and is typically caused by a trojan installing malware that allows the attacker to intercept/modify communications between the browser and the server. This can be used to capture data on forms, modify input, or modify the response from the server. Often the software used in MitB attacks lays dormant until the victim browses to a targeted website. What follows is an example of how a MitB attack can be used to modify an online banking request to send money:
🔗
Diagram illustrating a Man-in-the-Browser (MitB) attack where malware on a user’s workstation alters a financial transaction without the user’s knowledge.
The diagram shows a Man-in-the-Browser attack involving a "User," their "Work Station," a "Browser" (represented by a Chrome-like icon), an "Attacker" (icon of a figure in a hat and trench coat), and a "Web Server." The attack unfolds as follows: First, malware is downloaded to the "User’s" "Work Station," indicated by an arrow from the "User" to the "Work Station." The "User" then attempts a transaction; an arrow from the "Work Station" to the "Browser" shows an "approved $1,000" payment, and a corresponding arrow from the "Browser" back to the "Work Station" shows "transfer $1,000," representing the user’s intended action and what they believe is happening. However, due to the malware, the "Browser" is compromised. An "Attacker" is depicted above the "Browser" with a bidirectional arrow, signifying control or interaction. The compromised "Browser" then communicates with the "Web Server." An arrow from the "Browser" to the "Web Server" shows a modified request for an "approved $10,000 to Attacker," and a corresponding arrow from the "Web Server" back to the "Browser" indicates "transfer $10,000 to Attacker." This illustrates that the attacker, through the malware in the browser, has secretly changed the transaction details, redirecting a larger sum of money to themselves, while the user remains unaware of the alteration.
🔗
Figure 5.1.3. Man-in-the-Browser Attack
🔗
As you can see the attacker ended up with $10,000 and the victim simply thought they authorized a payment of $1,000 to someone else. These attacks can be difficult to detect because they take place within the browser and are opportunistic.
🔗
🔗

Subsection 5.1.3 Replay Attacks

This family of attacks typically involves a MitM making a copy of the transmission and replaying it to impersonate the victim. Logon credentials, simple hashes, and specific commands are sometimes susceptible to this type of attack. The solution is to use timestamps, nonces (random number for that particular session), rotating keys, or a counter to make sure commands cannot be executed outside of context.
🔗

Example 5.1.4. One-time Passwords.

To help mitigate replay attacks, an online banking application may require that client use a one-time password (OTP) when submitting transactions. An OTP is a frequently changing value that is known to both the client and the server. Several one-time password schemes exist, most of which make use of a cryptographic hash function with a shared seed between client and server. Periodically the client and server update to a new hash based on the seed and without the seed it is impossible to know what the next hash will be. By using an OTP anyone who intercepts the traffic will not be able to perform a replay attack as the password will not be current.
🔗
🔗
🔗

Subsection 5.1.4 SSL Circumvention

Sequence diagram illustrating an SSL Man-in-the-Middle attack where an attacker intercepts communications, prevents an HTTPS upgrade for the victim, and captures plaintext credentials.
The diagram shows interactions between a "Victim," an "Attacker," and a "Server" to illustrate an SSL circumvention attack. The Victim initiates a connection by sending a "GET http://njit.edu" request, which is intercepted by the Attacker. The Attacker forwards this GET request to the Server. The Server responds with a "301 Moved" redirect, typically indicating a move to HTTPS. The Attacker receives this redirect but does not forward it to the Victim. Instead, the Attacker initiates its own "GET https://njit.edu" request to the Server, establishing a secure HTTPS connection. The Server responds to the Attacker with "200 OK (HTTPS)". The Attacker then sends a "200 OK (HTTP)" response back to the Victim, deceiving the Victim into believing they are communicating over a standard HTTP connection with the server and that no HTTPS upgrade occurred. Subsequently, the Victim sends their credentials, "POST http://njit.edu username=admin password=admin," over this unencrypted HTTP connection to the Attacker. The Attacker, having captured the plaintext credentials, can then forward this POST request, potentially over a secure HTTPS connection ("POST https://njit.edu username=admin password=admin"), to the legitimate Server. This allows the attacker to intercept sensitive information while the victim believes their session is normal, albeit unencrypted as presented by the attacker.
🔗
Figure 5.1.5. SSL Circumvention Attack
🔗
If you think about the intercepted key exchange given in the above MitM example, a similar attack can allow attackers to view SSL traffic. The attacker gives the victim a bogus certificate authority (CA) certificate which the victim installs. This is often accomplished via a trojan. Then the attacker places themselves in the middle of an uninitiated secure connection. During the key exchange the attacker creates a custom certificate signed by a bogus CA for the connection between attacker and victim. The attacker also makes an actual HTTPS connection to the service and proxies data for the victim. All of the victims data will show up in plaintext for the attacker but the connection will appear to be secure for the victim. This is used in the Fiddler
 1 
www.telerik.com/fiddler
debugging proxy to decrypt HTTPS traffic and is also used in some network appliances that perform deep packet inspection.
🔗
Another MitM attack on SSL is simply to maintain or downgrade to an HTTP connection with the victim and proxy data to an actual HTTPS connection with the server. Most servers will upgrade an insecure connection, but by intercepting that exchange the attacker can continue to monitor the victim’s traffic.
🔗
🔗
You have attempted 1 of 1 activities on this page.
🔗
PrevTopNext