The basic idea behind Man-In-The Middle attacks is that an intruder manages to position themselves right within the communication pathway of two hosts. Imagine it like someone wedging themselves right in the middle of your phone call with a friend – they’re hearing everything you’re saying, pretending to be you and repeating it to your friend, all while eavesdropping on your friend’s responses back to you. This is the essence of a MITM attack.
The approach for MITM attacks can vary, but one frequently used point of entry is something called ARP spoofing. ARP (Address Resolution Protocol) is a protocol that matches IP addresses to MAC addresses for devices in a local network. Here’s the kicker: if you’re on a network with a bunch of other devices, all an attacker needs to do is ask, and they’ll get the MAC address of a target device.
To paint a clearer picture, let’s create a scenario. Imagine we have three characters: a router, a user named Bob, and another user named Mike. Now, Bob is the attacker in this story. He’s just joined a local network, and his sights are set on executing a MITM attack on Mike.
Bob’s grand plan involves making the router think he’s Mike, and, simultaneously, convincing Mike that he’s the router. If Bob pulls this off, Mike will send all his outgoing data through Bob, and the router will reroute all data back through Bob. Bob has effectively become the Man-In-The-Middle of their conversation.
Bob’s method? Well, he uses the router’s IP address to send out an ARP request, fetching the router’s MAC address. Armed with this, Bob uses a tool called arpspoof to shoot out ARP requests to Mike with the router’s MAC address. Bob’s basically trying to persuade Mike that he’s the router. If Mike falls for it, thinking Bob is the router, Bob repeats the same trick with the router, making it believe he’s Mike. Now, Bob’s sitting in the middle, orchestrating the flow of data like a puppet master. This is also called ARP Poising because Bob has successfully poisoned Mark and the routers ARP table by convincing them he is another host.
This is a textbook example of a successful MITM attack. Bob has weaseled his way into the conversation, and now all the data packets are making their way through him.
Now, you might think, why doesn’t modern tech prevent this sort of thing? Well, you’re right to a certain extent. The modern online architecture, particularly for secure websites, uses a security protocol known as HTTPS, which encrypts all the data being exchanged. So even if someone intercepts the messages, they can’t easily make heads or tails of the content – it’s like trying to read a coded message.
However, don’t let your guard down just yet. MITM attacks can still succeed even when HTTPS is in play. They can exploit weaknesses in the way connections are set up, how certificates are validated, or even how users behave.
HTTP Strict Transport Security (HSTS)
Making online communication secure is crucial, and HTTPS plays a vital role by using SSL to authenticate server certificates and encrypt communication channels. Despite encryption, the attacker aims to decode the encrypted channel to intercept the traffic flowing back and forth.
The goal of the MITM isn’t just to pass messages along , but to act as an intermediary that captures valuable readable data and then forwards the traffic. To achieve this, the MITM needs to find a way to decrypt the encrypted traffic and extract useful information.
One technique that the MITM can employ is called SSL stripping or HTTP downgrade. Essentially, this technique removes the SSL encryption from the traffic, effectively reducing the HTTPS connection to an unsecured HTTP connection. This allows the attacker to access important data.
Most modern web servers support both HTTP and HTTPS connections, but the HSTS (HTTP Strict Transport Security) standard adds a layer of security. It automatically converts any HTTP requests to HTTPS, guarding against eavesdropping and various network attacks. Often, users enter only the domain name in their browser, like typing “jcawl.com” instead of the complete “https://www.jcawl.com“. Unfortunately, this leads the browser to send an insecure HTTP request to the server, leaving it vulnerable to manipulation.
HSTS counters this issue by responding to such requests with a 307 internal redirect via HTTPS with directives instructing the browser to include all subdomains and always use a secure HTTPS connection when accessing the site. This protection remains in place for a specified time, ensuring that the website is accessed solely via HTTPS. While HSTS offers defense against several attacks, its effectiveness is limited if an attacker has compromised the router’s ARP (Address Resolution Protocol) and executed a successful poisoning attack.
HSTS Preload is an additional security feature that takes the protective power of HSTS to a higher level. By working with website operators and browser developers, HSTS Preload tells browsers to automatically establish secure connections with a website from the very first visit.
Here’s how it operates: Website administrators submit their domains to browser vendors’ HSTS Preload lists. Upon approval, the website’s HSTS policy becomes part of the browser software, making it enforce secure HTTPS connections right away. This means that users experience the security benefits from their initial interaction with the site, eliminating the vulnerability window that attackers might exploit.
HSTS Preload offers several advantages, including immediate security confidence for users, reduced susceptibility to SSL Stripping attacks, and improved overall trust in your website. Once added to the preload list, the domain will always be accessed via HTTPS.
Once a Man-in-the-Middle (MITM) attacker establishes themselves between a host and a router, they can employ two methods for carrying out SSL Stripping. It’s important to note that both of these methods are effective only when the targeted client is visiting a website for the first time and it is not on the HSTS preload list.
The presence of HSTS has significantly impeded the effectiveness of SSL Stripping. Once a user’s browser receives an HSTS packet, the MITM’s options become limited.
- Intercepting First-Time HTTPS Connection
The first method involves scenarios where a user accesses a website using HTTPS for the first time. This is quite common since search engines like Google often initiate secure HTTPS connections automatically when you click on links. In this approach, the MITM intercepts the data packet, directs the client to an unencrypted HTTP connection, and then forges an HTTPS link with the website. This allows the MITM to establish an unencrypted HTTP connection with the client while remaining connected to the server.
In a typical HTTPS connection, the browser and the server engage in a process called the SSL/TLS handshake, during which they exchange cryptographic keys and establish a secure communication channel. This handshake includes a step where the server provides its SSL certificate to the browser to prove its identity.
If a MITM attacker were to intercept this traffic, they could potentially try to present their own forged SSL certificate to the user’s browser, posing as the legitimate website. However, for this to work effectively, the attacker’s certificate needs to be trusted by the browser.
This is an older technique that has become less effective due to the widespread adoption of security measures like HSTS and improvements in browser security. Modern security practices such as certificate transparency, browser warnings, and ongoing browser updates have significantly reduced the effectiveness of this attack. These measures prevent automatic downgrades to HTTP, detect forged SSL certificates, and warn users about potential security risks, making it difficult for attackers to successfully carry out such attacks.
- HSTS Redirection Manipulation
The second method, which is more practical involves instances where a client directly types in a domain name like “jcawl.com” to visit a site. If it’s the client’s first visit, the server sends an HSTS redirect with directives instructing the browser to use an HTTPS connection. In this case, the MITM needs to intercept this packet before it reaches the client, remove the HSTS directives, and consequently establish an unencrypted HTTP connection with the client.
Browsers employ various mechanisms to warn users about using insecure HTTP connections. When users attempt to access a website over HTTP, modern browsers display conspicuous messages, such as “Not Secure” indicators located in the address bar.
These warnings signal that the connection is vulnerable to eavesdropping and potential data manipulation.
Additionally, browsers may utilize color-coded indicators, such as red or grey lock icons, to visually highlight the lack of encryption. These visual cues immediately alert users to the risks associated with the connection.
This article sheds light on how attackers can pull off MITM attacks through methods like ARP spoofing and SSL stripping. By pretending to be both the router and the user, they create a secret hub where your data unknowingly passes through.
Yet, there are defenses in place. Concepts like HTTPS and HSTS add layers of security to make this once very simple attack much more difficult. They encrypt conversations and ensure that your browser always connects safely. Still, it’s a game of cat and mouse; attackers constantly seek new paths to breach security.