MITM attacks have always been a favourite of the average hacker as it is relatively easy to perform using readily-available tools. Furthermore, once an MITM assault has been launched successfully, it opens the way for more malicious and aggressive types of attacks, potentially resulting to more damage and irreversible harm.
Several areas of concern exist around MiTM attacks. These include administrative systems (such as Databases and UNIX servers) that run insecure protocols. This post, in the end, hopes to raise awareness and thus improve the overall site security at your organisation.
In the ideal scenario above, information within a session passes privately between the client and server, and vice versa.
In a man-in-the-middle attack, an attacker hijacks the supposedly private session. The attacker makes it appear to the client that it is still communicating directly with the server, while in truth, any information being sent to, and received from, the server is being read and maybe even being modified by the attacker. The same deception is performed on the server, where it thinks that it is still communicating with a valid source (the client) when in fact the requests for information are coming from the attacker.
MITM proxy tools
As the term implies, these tools generally perform “proxy only” functions, where they merely act as “sniffers” to read the data passing between the Client and the Server. The harvested information can be used for more aggressive attacks later on.
- Achilles (http://www.mavensecurity.com/achilles)
- WebScarab and its followers
- Paros Proxy (http://www.parosproxy.org)
- Spike Proxy
These tools are used for more aggressive, and usually more licentious, attacks. Aside from establishing a proxy between the Client and the Server, these tools can also re-route traffic, inject commands, introduce specially-crafted packets, and alter information in the data stream.
- Ettercap (http://ettercap.sourceforge.net/download.php)
MITM risks with clear-text protocolsThe table below lists some protocols that send information in plain or “clear” text that have been noted to be used within the networks in I have audited.
Obviously, sending information in unencrypted form makes it possible for an attacker employing MITM to easily obtain that information. With relative ease using various tools and techniques, the attacker can then tamper with the data’s integrity (modify the data) and authenticity (make it appear that the data came from a legitimate source).
As an example, let us say that the Client has been using telnet to connect to a remote Server. Let us also assume that an Attacker has previously done some reconnaissance and obtained the IP addresses of the client and the remote server. The following is a likely scenario for carrying out the MITM attack:
- The attacker launches a TCP sniffer tool such as Hunt, Juggernaut or Ettercap and waits for a session to be established between the Client and the Server.
- The client logs in to the server using Telnet.
- The attacker is alerted of a new connection.
- The attacker performs packet sniffing (read all information passing through the session). With Ettercap, usernames and passwords can be easily obtained. The attacker saves the harvested information for later use.
- The attacker can then inject commands into the data stream without the Client knowing, and which the Server will interpret as valid commands from the Client.
- When the session is terminated by the client, the attacker can log in into the server using the previously obtained username and password of the Client.
- If the account has administrator privileges, the attacker can install more malicious tools such as rootkits to further compromise the integrity of the server.
To mitigate MITM attacks against clear-text protocols, it is advised that their use be minimised or discontinued altogether. There are also more secure protocols that can be used in their place as listed below:
|Protocols / Port Numbers||Encrypted / Port Numbers|
|Telnet / 21||SSH / 22|
|FTP / 20, 21||SCP or SFTP / 22|
|POP3 / 110||POP3S / 995|
|HTTP / 80||HTTPS / 443|
|IMAP / 143||IMAPS / 993|
|SMTP / 25||SMTP over TLS/SSL / 465|
|MySQL / 3306||Encrypt the traffic|
MITM risks with SSLSecure Sockets Layer (SSL) protocol was designed to provide security for client/server communications over networks. This is accomplished by providing endpoint encryption and authentication.
SSL is widely implemented in web (HTTP) sessions, such as in online banking and eCommerce. Despite its well-publicised susceptibility to MITM attacks, HTTPS (HTTP over SSL) continues to be a popular choice for web security implementations.
The main flaw with SSL (without client side certificates – which are still rare) is it only authenticates the server, not the client. The client is given a level of assurance of the authenticity of the server using a validation process of the server’s digital certificate by the browser, but not vice versa.
The MITM attack is carried over an HTTPS connection by establishing independent SSL sessions – one between the Attacker and the Server, and another between the Attacker and the Client. When the Client attempts to establish an HTTPS connection with the Server, it is actually the Attacker it is connecting to, which at this point is masquerading as the Server. Usually, the client’s browser warns the user that the digital certificate used is not valid. Below are some examples of warnings issued by some of the more common web browsers:
Some users particularly the less-savvy may ignore the warning, usually because of lack of understanding of the risks involved. In some cases there are no warnings at all, as in situations when the Server certificate itself has been compromised by the attacker or, although less likely but still possible, when the attacker certificate was authenticated by a trusted Certificate Authority or CA (such as VeriSign, Thawte, etc) and the Common Name (CN) is the same with the original web site.
When the warning is ignored, the user in effect accepts the site as legitimate. The browser will then proceed with loading the website. If the website is in fact a bogus site, every transaction performed by the Client will be read and open to tampering by the man-in-the-middle attacker. From the Server’s point of view, since it does not authenticate the client, it does not know or care whether the computer it is transacting with is legitimate or not, so it treats every transaction as valid.
To mitigate MITM attacks against SSL, users are advised to at least pause and investigate warnings issued by their browsers before proceeding on accessing a website, particularly when the website will be used to facilitate confidential and/or sensitive transactions.
On the server-side of things, it is recommended that all SSL protocols be upgraded to the latest versions, which is currently SSL version 3 or ideally be replaced with TLS 1.0.
MITM risks with SSHSecure Shell (SSH) was designed as a replacement to some of the clear-text protocols specifically Telnet, rsh and rlogin which have been proven to be vulnerable to MITM attacks.
In an SSH environment, computers or network devices exchange information inside a secure channel. SSH uses a public-key (PK) to encrypt the data, which then requires a private key to decrypt it.
Currently SSH version 1 (SSH1) and its upgrade SSH2 exist, however the two are regarded as entirely different protocols. Furthermore, SSH2 is deemed more secure than SSH1, the latter being known to be vulnerable to MITM attacks. Fortunately, very few SSH servers use SSH1 nowadays.
One of the more popular MITM attacks exploits the weaknesses of the SSH1 protocol, in what is known as an “SSH downgrade” attack. This type of attack tricks the server and the client to communicate via SSH1 instead of SSH2.
The following is a likely SSH downgrade attack scenario.
- The attacker, using Ettercap or other ARP poisoning tools, sends fake ARP requests across the network which will enable the attacker to capture and modify the packets intended for the target machine.
- The client initiates a request for an SSH connection to the SSH server. Usually, it requests for an SSH2 connection.
- The attacker sends a reply back to the client saying that the server supports only SSH1.
- If the client accepts, it will establish an SSH1 connection with the server. Due to the weak encryption protocols of SSH1, any information such as usernames and passwords can be read by the attacker.
To mitigate MITM attacks against SSH, server and client configurations should be made to support SSH2 only. Any transaction requests to the contrary should be treated with suspicion and should warrant an elevated level of caution and investigation.
There are also tools that can be employed to detect ARP and DNS poisoning.