Tuesday, 9 August 2011

Man-In-The-Middle Attacks

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.

Man-In-The-Middle (MITM) Attack – an overview

An MITM attack is an attempt to intercept the communication between two computers, with the purpose of reading or altering the information passing between them, preventing the data to be sent to either or both parties, or creating (“crafting”) data and sending to either or both parties.


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)
  • Burp
  • Spike Proxy
  • ProxyFuzz
  • Odysseus
  • Fiddler
MITM attack tools
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.
  • PacketCreator
  • Ettercap (http://ettercap.sourceforge.net/download.php)
  • Dsniff

MITM risks with clear-text protocols

The 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.

Protocols Port Numbers
Telnet TCP 23
FTP TCP 20/21
POP3 TCP 110
HTTP TCP 80
IMAP TCP 143
SMTP TCP 25
MySQL TCP 3306
Of particular concern is Telnet to administratively sensitive devices. This is common in the management of routers and switches. Several UNIX hosts have the telnet service running as well as some network infrastructure. Being located within an internal network should not be seen as a fix. The MySQL protocol is also of concern. This can be easily secured using SSL or through other forms of encryption.

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:
  1. 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.
  2. The client logs in to the server using Telnet.
  3. The attacker is alerted of a new connection.
  4. 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.
  5. 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.
  6. 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.
  7. If the account has administrator privileges, the attacker can install more malicious tools such as rootkits to further compromise the integrity of the server.
Attack Mitigation:
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 SSL

Secure 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:
Firefox:

Google Chrome


Internet Explorer:


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.

Attack Mitigation:
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 SSH

Secure 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.
  1. 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.
  2. The client initiates a request for an SSH connection to the SSH server. Usually, it requests for an SSH2 connection.
  3. The attacker sends a reply back to the client saying that the server supports only SSH1.
  4. 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.
It should be noted that this attack is only successful if the server has SSH1 enabled and that the the client accepts the request to “downgrade” from SSH2 to SSH1.

Attack Mitigation:
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.

No comments: