Analysing vulnerabilities in the network infrastructure
Using honeypots to map attacks against routers and identify attackers' intentions
Together with the University of Twente, we are investigating the effects of vulnerable network devices on internet security. As an example, we studied the impact of two publicly known vulnerabilities in widely deployed MikroTik routers, which were first reported in early/mid 2018. We used honeypots to analyse the actions performed by attackers once a device has been compromised. Our study case focused on “tunnel attacks” which allow attackers to intercept and redirect all of a router’s traffic. While MikroTik provided firmware updates to fix the vulnerabilities in 2018, we find that the attacks are still occurring today, which further demonstrates the importance of patching.
The problem: a growing number of vulnerable devices
Vulnerable devices are an increasing problem on the internet. Internet-connected devices are often poorly secured, for instance because their manufacturers are no longer updating their firmware, or because owners do not upgrade the firmware for their devices. This is a well-known problem with Internet of Things (IoT) devices, but it can also affect devices in the internet infrastructure, such as routers and switches. Attacks targeting such devices are particularly problematic since they can affect large numbers of users. Since network routers have become increasingly programmable and based on general-purpose hardware, manufactures can more easily update their functionality while they are in operation. Yet, there are numerous types of malware that abuse vulnerabilities. For example, VPNFilter, Navidade and SonarDNS have recently been used to compromise vulnerable network routers and commit all sorts of cybercrimes ranging from DDoS attacks to ransomware deployments. At the same time, it is generally believed that not everyone updates their devices with the latest patches, so we asked ourselves the question: to what degree are known and patchable router vulnerabilities still being exploited?
Case Study: MikroTik routers
As an example of a router with publicly known vulnerabilities, we investigated the MikroTik router. We considered this router family to be a good candidate for our study because the routers are in widespread use. We analysed one month of data from publicly available Shodan scans (4 terabytes of data) and found 4,742,944 distinct IP addresses and 6,484,420 distinct records related to MikroTik routers. That number is likely an underestimate, because we only analysed routers that were reachable by Shodan. We were not able to analyse MikroTik routers sitting behind filters and running in closed infrastructures (e.g. in home networks or Internet Exchanges).
CVE-2018-7445 and CVE-2018-1156-vulnerable routers
We specifically concentrated on MikroTik routers with vulnerabilities CVE-2018-7445 and CVE-2018-1156. We selected those vulnerabilities because they are critical (they both enable remote execution of arbitrary code) and because they were first reported around two years ago (March and August 2018, respectively). Both CVEs are in the public NIST vulnerability database (NVD). The two vulnerabilities have been fixed by MikroTik through software updates in March and August 2018 respectively, but some owners have not upgraded their devices, leaving them vulnerable to attackers.
Measurements made using honeypots
Based on our analysis of the Shodan data, we found the deployment of a honeypot to be the best way of studying attacks on compromised MikroTik routers, since it allows us to measure the so-called “tunnel attacks” (details below).. By using honeypots, we simulated a vulnerable router that had not been properly updated by its owner. Based on the popularity statistics, we determined where to place our custom-designed honeypots in order to maximise the number of attack attempts. We deployed six honeypots (in Australia, Brazil, China, India, Netherlands and the United States of America) and we collected and logged all the connections to them for 120 days. We ended up logging over 44 million packets (12 million flows) and 3.8 million log records.
What is a tunnel attack?
A tunnel attack is an attack that aims to forward network traffic from the router to an external server controlled by the attacker. One example of malware that allows such behaviour is VPNFilter, where network traffic is sniffed, encrypted and exfiltrated through Tor. The use of tunnels is not exclusive to MikroTik attacks; it is a well-known technique for attacking routers. Tunnel attacks may become particularly serious when the compromised routers are part of critical infrastructures, such as data centres, registry operations, or Internet Exchange Points (IXPs). For example, if an exploited router is responsible for BGP routing, attackers could take down or reroute the traffic from an entire autonomous system.
So, what did we get out of our honeypots?
Since our honeypot emulated a vulnerable MikroTik router, we could analyse the tunnel itself – for example, by looking at the protocol used and the endpoint of the tunnel. The protocol is the technology used to set up the tunnel, and endpoints are computer servers used to establish the tunnel. In our honeypots, we observed (Figure 1) that the most common tunnelling protocols were the Point-to-Point Tunneling Protocol (PPTP) and the Simple Service Discovery Protocol (SSDP).
Figure 1: Numbers of established tunnels as observed by our honeypots, grouped by protocol (SSDP/PPTP).
It was up to the attacker to choose the protocol because our honeypots supported both protocols. We presume that PPTP is more popular due to easy setup (it does not require SSL configuration).
In Figure 2, we show the distribution of the tunnel endpoint country codes for each honeypot. Usually, endpoints are dedicated servers controlled by the attacker. These servers could be computers in the cloud or compromised devices controlled by the attacker. We found that IP addresses located in the United States, Russia and the Netherlands together represent more than 50% of all IP addresses exploiting traffic tunnels.
Figure 2: Tunnel endpoint country code (x-axis) and per honeypot location.
Figure 3 shows the distribution of IP addresses relative to tunnel endpoint country codes. IP addresses located in the United States, Russia and the Netherlands represent more than 50% of all IP addresses exploiting traffic tunnels. Just five IP addresses are responsible for almost 50% of the total number of tunnels. The IP address 46.X.X.122 was used as an endpoint in all the honeypots and it was used on 116 days of analysis (out of 120 days). Our honeypots were rebuilt/re-initiated every day, forcing an attacker to compromise the system again to establish a tunnel, indicating that the IP address 46.X.X.122 was very active.
Figure 3: Endpoint IP address and honeypot correlation.
Our endpoint investigation reveals that attackers are using dedicated machines to redirect traffic from various compromised routers. The motivation for doing so is still is not clear; it may be to modify traffic or to acquire sensitive information that has not been encrypted.
What did we learn?
Our analysis illustrates that vulnerable routers pose a risk to internet security, which can be particularly serious where critical infrastructures are concerned. We empirically confirmed the general belief that not all router owners update their firmware, even within two years of vulnerabilities being publicly reported and the vendor providing fixes. We also illustrate that attackers continue to exploit the vulnerabilities, making a robust approach to patching of paramount importance for the owners of all kinds of devices, not only MikroTik routers. We intend to follow up our study by investigating the tunnelled traffic in order to better understand the attackers’ intentions.
Ethical considerations
When doing research with honeypots, it is important to consider the ethical aspects of using honeypots. A secure honeypot should meet the requirements laid down by EU law should have the following five features:
Firewall: allow connections only to certain ports.
Dynamic connection redirection mechanism: only trusted connections should have access to services outside the honeypot.
Emulated private virtual network: the honeypot should be run in a restricted private network to restrict attackers.
Testbed: a controlled environment should be used to analyse vulnerabilities in applications.
Control centre: the administrator of the honeypot should monitor connections and quickly respond to incidents.
Those features were used to guide the design of the honeypot used in this research. Furthermore, we have notified the Dutch National Cyber Security Centre about the Dutch IP addresses that reached out to our honeypots to carry out attacks, and about the IP addresses that served as endpoints for tunnels.
Full details
We have described our work in more detail in a paper (PDF) that we presented at the IEEE Network Operations and Management Symposium (NOMS). An extended version of the analysis is also available in the public technical report. As usual, we’d be very pleased to receive any feedback you may have on our work.
