The most effective system break-ins often happen without a scene. Instead of disrupting central network devices with DDoS attacks or sneaking through onto operating systems with Trojan horse techniques, hackers increasingly try to exploit the human security gap. There are various such methods that fall within the broader category of social engineering: a technique that sees hackers gather publicly...
Ever since people started sending e-mails to each other, there have been other people trying to intercept or manipulate these messages with the recipient being none the wiser. Whereas in earlier times people intercepted the mail, or resorted to tapping wires, the internet today offers more subtle ways of performing espionage. The majority of data traffic worldwide is transmitted via public networks for one thing. Sometimes even encryption is not enough to deter criminals and it also doesn’t help that the transmission paths within the global network are often quite suspect. Data packets end up stopping at many different stations along the way, with each station having differing levels of security.
This is where hackers (as well as secret services) position themselves, with their aim being to read sensitive information and use their findings for their own gain. This has led to more and more users trying to find ways to make online transport routes more secure. But what if the attacker is posing as the legitimate recipient that you want to transmit information to? This kind of method of espionage is known as a man-in-the-middle attack.
What is a man-in-the-middle-attack?
A man-in-the-middle attack (MitM attack) refers to the method where a hacker intercepts the data traffic between two communication partners, leaving both parties to think that they are only communicating with each other. These kinds of attacks were previously carried out by manipulating physical communication channels. In times of shared public communication networks, the third party used to position themselves between two or more communication partners. MitM attacks are primarily seen in computer networks where there is an attempt to overturn SSL/TLS encryptions with the aim of obtaining secret information, usernames, passwords, or bank details. The basic course of a man-in-the-middle attack is as follows:
System A attempts to establish an encrypted connection with System B. Instead, the data flow is redirected by a criminal third party, which results in the encrypted connection running from system A to system C and only then is it redirected to System B. This means that the one in control of System C (usually the attacker) can see the data traffic in its entirety, record it, or manipulate it – often with the communication partners being unaware of anything fishy having taken place. In the world wide web context, System C would present itself to System A as a web server, and as a web browser to System B.
In order to infiltrate data traffic between two or more systems, hackers use various techniques that target known vulnerabilities in the world of online communication. A place to carry out LAN internal man-in-the-middle attacks is, for example, the DHCP (Dynamic Host Configuration Protocol) service, which is responsible for allocating local IP addresses, as well as the ARP system (Address Resolution Protocol), which determines hardware addresses (Media Access Control, MAC). Man-in-the-middle attacks can be performed on a global scale by manipulating DNS servers, which are responsible for the resolution of internet address in public IPs. Hackers also exploit security gaps in outdated browser software or provide corrupted WiFi access to unsuspecting internet users. These attack patterns are typically automated by software. If attacks are performed by people, then these are known as human-assisted attacks.
DHCP starvation attack
When it comes to DHCP-based attacks, a hacker’s own computer (one that’s under their control) is issued as a DHCP server within a Local Area Network (LAN). This kind of server is a central component of the local network and is responsible for allocating the network configuration to other computers in the LAN. This is usually done automatically: as soon as a computer builds the first connection to the LAN, the DHCP client of the operating system asks for information such as a local IP address, network mask, default gateway address, and the address of the responsible DNS server. It sends out a broadcast to all devices on the LAN and waits for the confirmation from the DHCP server. The first detailed answer is accepted.
This fake DHCP server gives hackers the possibility to control the allocation of local IP addresses, enter default gateways and DNS servers on the swapped computer and redirect outbound traffic on any computer in order to intercept or manipulate content.
Since this attack pattern is based on manipulating the DHCP system, it is known as DHCP spoofing. This kind of man-in-the-middle attack does, however, require the attacker to be on the same LAN as the victim. Hotel LANs or public WiFi networks are therefore at risk of becoming targets of DHCP-based attacks. If the attacker wants to infiltrate a wired corporate network, they must first obtain physical access to the LAN in order to infiltrate the fake DHCP server.
Internet users can take measures against DHCP spoofing such as being cautious when using unknown networks. It is advisable to use secure web applications from online banks or shopping portals only in known and trusted LANs such as your private home network or the one at work.
ARP cache poisoning
ARP is a network protocol, which is used to map IP network addresses to the hardware addresses used by data link protocols. So that a computer can send data packets within a network, it must know the hardware address of the recipient system. For this purpose, an ARP request is sent as a MAC broadcast to all systems in the LAN. This includes both the MAC and IP address of the inquiring computer as well as the IP address of the requested system. If a computer in the network receives one of these ARP requests, it checks whether the packet contains its own IP address as recipient IP. If this is the case, an ARP reply is sent back with the sought MAC address to the requested system.
The allocation of this MAC address to the local PC is stored in table form in the so-called ARP cache of the requested computer. This is where ARP cache poisoning starts. The aim of this attack pattern is to manipulate the ARP tables of various computers in the network through fake ARP replies, for example, displaying a computer, which is under the attacker’s control, as a WiFi access point or gateway to the internet.
If ARP spoofing is successful, attackers are able to read, record, or manipulate all outbound data traffic from infected computers before it’s sent to the real gateway. Just like with DHCP spoofing, ARP cache poisoning can only happen if the attacker is in the same LAN as the victim’s system. This kind of man-in-the-middle attack can be performed using simple programs like the freeware tool, Cain & Abel, which was originally developed to trace lost passwords, or an alternative is to use the software, Ettercap.
As with DHCP-based attacks, users that are in a corrupted LAN don’t have a chance to defend themselves against ARP spoofing. This means that in order to prevent this from happening, users should avoid unfamiliar networks or ensure they use them wisely.
While ARP cache poisoning targets vulnerabilities in the address resolution in the Ethernet, cache poisoning on a DNS basis focuses on the internet’s domain name system, which is responsible for URL resolution in public IP addresses. With this kind of attack, hackers manipulate entries in the cache of a DNS server so that they can answer requests with fake target addresses. The hacker can redirect internet users (unbeknown to them) to any site in the network. They usually use known security gaps of older DNS servers.
Basically, DNS information is not stored on a single DNS server, but rather on numerous computers in the network. If a user wants to visit a site, they generally use a domain name. In order to access the appropriate server however, an IP address is needed. The user’s router determines this IP by sending a DNS request to the standard DNS server specified in the configuration. This is usually the DNS server of the internet service provider (ISP). If Resource Records on the requested URL are found, the DNS server answers the request with the appropriate IP address. Otherwise, the DNS server determines the requested IP with the help of other servers with DNS tasks. The server additionally sends a relevant request to other DNS servers and stores their responses temporarily in a cache.
Servers that use an old version of the DNS software primarily fall victim to hacking attacks. They accept and generally store not only information that has specifically been requested, but also information that has been supplied. If hackers have captured a single DNS server, it is easy to deliver fake records with every correct IP address and thus poison the cache of the requesting DNS server.
The effectiveness of man-in-the-middle attacks can be seen by incidents in the past where whole namespaces were redirected. It’s practically impossible for users to protect themselves against such attacks because they are carried out directly in the internet’s infrastructure. It is therefore the responsibility of the operator to ensure that the DNS servers provided are using up-to-date software and are sufficiently secure. Under the name, DNSSEC (Domain Name System Security Extensions), various internet standards were developed in order to enhance the DNS system with various security mechanisms and to improve data authenticity and integrity. Distributing these standards is taking a long time, unfortunately.
Simulating WiFi access points
An attack pattern that especially targets mobile device users, is based on simulating an access point in a public WiFi network like those provided in cafés or airports. Here, the hacker has configured their computer so that this additional route promises to lead to the internet – perhaps one with a better signal quality than the real access point. If an attacker succeeds and deceives the unsuspecting user into using their access point, they can see the whole data traffic that runs through the system and are then able to read it and manipulate it before it reaches the real access point. If the access point requires authentication, the hacker can also get their hands on all user names and passwords that the user enters during registration. It’s especially dangerous and you’re more likely to become a victim of a man-in-the-middle attack if your device is configured so that it automatically connects to the access point with the strongest signal.
In order to protect yourself from these attack patterns, internet users should only let their devices connect to familiar WiFi networks and ensure that they only use official access points.
A variant of the man-in-the-middle attack, in which an attacker installs malware in an internet user’s browser in order to intercept data traffic, is known as a man-in-the-browser attack. Computers that aren’t fully updated provide security gaps, which give attackers the perfect opportunity to infiltrate the system. If particular programs infiltrate the user’s browser, they hide in the background and record all data that is exchanged between the victim’s system and various websites in the network. This attack pattern allows hackers to intercept a large number of systems with relatively little effort. The data espionage usually takes place before a possible transport encryption via TLS/SSL can take effect.
Internet users can prevent man-in-the-browser attacks effectively by making sure that all of the system’s software components are up-to-date and any known security gaps are closed by running security updates.
A human-assisted-attack refers to when an attack pattern is not purely automatic, but is instead controlled by one or more attackers in real-time. This type of man-in-the-middle attack could go as follows: once an internet user logs onto the website of their bank, the hacker (who has placed themselves between the user’s browser and the bank’s server) receives a signal. They now have the ability to steal session cookies and authentication information in real-time and use them to gain access to usernames, passwords, and TANs.
Data theft despite encryption?
With the growing importance of internet-based communication in nearly all areas of life, the interest in data encryption techniques is also increasing. The communication protocol HTTPS has been established for communicating between browsers (clients) and servers on the world wide web. This checks the authentication of the web server on the basis of the SSL handshake and builds an encrypted transport channel based on a common symmetric session key. Server authentication is performed using an SSL certificate.
In theory, this authentication provides a reliable protection against man-in-the-middle attacks: in order to transfer as with the basic pattern mentioned above, System C would need a trustworthy SSL certificate in order to appear as System B to System A. This protection, however, depends on the integrity of the utilized certificate. When it comes to the SSL handshake, the browser checks whether the server’s certificate is recognized by a trustworthy certification authority (CA). However, many of these CAs have been infiltrated over the past few years, meaning that hackers, secret services, and governments have been able to create seemingly trustworthy certificates and abuse them by performing man-in-the-middle attacks.
Alternatively, hackers have the option to issue SSL certificates themselves. A self-signed certificate of this type leads to a warning appearing in the browser, explaining that the website is unsafe, but many users don’t take much notice of it and visit the site anyway.
By using a fake SSL certificate, hackers are able to act as the desired target server even with SSL encrypted websites. In order to intercept or manipulate data without being noticed, the certificate must also be faked. The attacker redirects the original request (similar to how a proxy works) to the actual recipient – encrypted if needs be. In principle, the SSL handshake also makes a client-side authentication possible via the certificate. However, this is rarely used in practice.