What is Man in the Middle Hacking and Transport Layer ProtectionIn this tutorial we take a look at Man in the Middle Hacking and how we can protect data sent over the internet from these kinds of attacks.
This article is part of a series of articles. Please use the links below to navigate between the articles.
- An Introduction to Hacking and Cyber Security - Complete Guide
- An Introduction and Brief History of Cryptography and Codebreaking
- Online Privacy and Why it Matters in Today's Hyper-Connected World
- What Are Supercookies? The Web's Latest Tracking Device
- How to Spot Scam and Phishing Emails And Avoid Being Scammed
- How Internet Security and SSL Works to Secure the Internet
- What is Man in the Middle Hacking and Transport Layer Protection
- What is Social Engineering And How Is It Used To Hack Systems
- Cookie Security and Session Hijacking in Web Applications
- What is Cross Site Scripting? (XSS) How is it Used to Attack Websites
- What is Internal Implementation Disclosure?
- What is Parameter Tampering and How to Protect Against It
- What is SQL injection - With Examples & Prevention
Man in the Middle Hacking is when an attacker can intercept communications between a client and server and alter the contents of the transmission. This could range from data theft to request tampering to alter or inject malicious code, or they could redirect the request to another server without the client's knowledge.
What is Man in the Middle Hacking?
Transport Layer Protection is protecting the data we send over the internet. When you request a page from a server, your browser will send a request header to the server; any sensitive information is not, by default, secured. We must enable security before sending data over the internet.
What are Request Headers?
This request header typically contains information such as the resource you want to view, the method for viewing the resource, information about the browser you are using, languages, the referrer and any cookies the website has set. In response, the server will send a response, starting with a header and then the actual content. The response headers normally contain hidden information about the server (version and OS), content types, caching information, and cookies.
This information can be read and manipulated by various means in the long communication chain between your browser and the server. These links are illustrated in the diagram below.
Browser > OS > NIC > Router > Exchange > ISP > Global ISP > Remote ISP > Local Exchange > Router > NIC > OS > Web Server Application.
At any point along the line, data on the wire can be intercepted, read or even manipulated.
Between your browser and your network card (Ethernet or Wi-Fi), there is a possibility that malware, viruses or spyware can intercept communications to and from your browser. It is in this layer that Fiddler acts, capturing HTTP traffic. This layer is relatively easy and cheap to attack, as seen by the prevalence of computer viruses and malware.
After the request has left your computer through the NIC, the next step is the router. Is this configured correctly? Have the DNS entries been hijacked? It's not an issue for your home connection, but what has been configured or hacked on a public network? Website addresses are converted to numerical IP addresses, which computers use to communicate. DNS hijacking means that when you request a website, for example, www.google.com, a different IP address is used instead of the real one. The result is that instead of going to the Google server, you are going to another malicious server pretending to be Google.
Once the router has passed the request, it will be out in the wild. Normally, the data is transmitted over telephone wires or fibre optic lines to an exchange or network of exchanges. Any of these exchanges or the line itself can be attacked and compromised. Attacks on this kind of infrastructure require much more specialised knowledge and access to the hardware, so they are more costly and generally much less likely.
The third main vulnerable area is the ISP itself. The ISP can log, analyse and record every packet of information sent and received by your router. It is also capable of manipulating the DNS. Although this is often for legitimate reasons, there are cases when this is not the case (see Turkish Hijacking of DNS Providers).
The request is then sent through cables to the ISP of the web server and then to the server itself. The server processes the request, and the response data is transmitted along the same lines.
These types of hacks are called Man in the Middle (MitM).
Using Fiddler to Intercept Request Headers
Let's look at Fiddler to see what kind of information is readable and potentially open for attack by a man in the Middle.
Firstly, open up Fiddler if you haven't done so already. The screen is divided into two sections. The left-hand side shows each HTTP request and response event. The right-hand side shows information about the currently selected event. You can start or stop capturing traffic using F12 (or File > Capture Traffic). Ctrl + X (or Edit > Remove > All Sessions) can clear the list. This is useful as you can quickly fill the screen up.
Start capturing traffic and browse a website. You should see an entry for the site request and probably quite a few for the other resources on the page - images, web fonts, stylesheets, scripts and so on. Stop capturing traffic now, and we'll have a look at the request header. Select the event whose host and URL match the address you navigated to. On the right side, click the Inspectors tab, then the headers tab underneath. You can see all the data sent to the server in this view.
A request to this website looked like the content below.
GET http://timtrott.co.uk/ HTTP/1.1
Host: timtrott.co.uk
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6 From this, we can see that the HTTP method was GET; the request was to http://timtrott.co.uk/ using the HTTP/1.1 protocol. We can see what data formats my browser accepts, the user agent, and the languages supported.
Underneath this request header is the response header. From here, you can see the information sent back to the browser. Below the header is the body content - the actual page content requested.
HTTP/1.1 200 OK
Date: Wed, 09 Mar 2016 15:58:49 GMT
Server: Apache
Last-Modified: Wed, 09 Mar 2016 15:57:25 GMT
Accept-Ranges: bytes
Content-Length: 30188
Cache-Control: max-age=3, must-revalidate
Expires: Wed, 09 Mar 2016 15:58:52 GMT
X-Clacks-Overhead: GNU Terry Pratchett
Vary: Accept-Encoding,Cookie
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8 From this, we can see information about the response - the first line is the status code (status 200 means everything is ok). We can see the date and time the page was served, the server software used, how much data was sent and a few other bits of header information. Everything seems to be inconspicuous here, but let's see what happens when we try to log in to a website.
Insecure vs Secure Login Pages
I will hit the login page, and the request I get back from the server gives a status code of 401. This indicates that authorisation is required. Because my browser detected this status code, it showed me a login box asking for my username and password. I carefully entered these and clicked the login button after restarting network capture in Fiddler.
Below is the captured request header for the login page. Some data has been omitted to protect my security.
GET http://timtrott.co.uk/login HTTP/1.1
Host: timtrott.co.uk
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6
log=myusername&pwd=password&submit=Log+In Looking at this, we can see the body of the request contains the login name and the password sent in plain clear text. Some sites will encode this using Base64. However, most tech-savvy people should be able to recognise a string ending with = or == as a Base64 encoded string. This isn't a secure way of sending login details; imagine what a hacker can do with this information!
This illustrates why login forms should not be loaded insecurely, that is, over HTTP. Any page which deals with sensitive information should be served using secure HTTPS. This encrypts data transferred between two machines using public key cryptography. It isn't easy to decrypt the information if it is intercepted.
Developers Note: Every page that uses SSL should check to see if it IS running over SSL. If not, redirect to the SSL version. Too many sites link to the login or registration pages using the HTTPS protocol. However, the pages fail to check if SSL is active, meaning the page can be loaded insecurely.
Now, when we make the same request to the login page, now secured using an SSL certificate, we can see in Fiddler that there are now no details contained within the request body nor the request header and so these details are secure.
This is a really simple method to demonstrate the risks of sending data over an insecure connection.
