Another DoS vulnerability

Hello, my name is Yevgeny Uskov, I represent Qrator Labs. Today, we will address another vulnerability, potentially leading to a denial of service. This problem may seem obvious to you, however, we found more than a million vulnerable devices.


To begin with, let's imagine a typical router. It performs various tasks, for example: building a routing table, it communicates with other devices using a variety of protocols, and, finally, it deals with direct forwarding of network packets. There is a well-known abstraction, according to which all these tasks can be divided into two levels with different properties: the transmitting level and the controlling level.


At the management level, decisions are made about where to send traffic. It uses various protocols for this, such as the Spanning Tree Protocol (STP), OSPF, or BGP. Packets reach the transmitting level if the router is the destination or source of the packet. Nevertheless, it is important to note here that the controlling level processes everything by the central processor and, moreover, since these operations, in general, are performed for a relatively small part of the packets, there is no hard time limit on their processing.


The transmitting level is also known as the level of forwarding and, as its name implies, it provides primarily forwarding.
')

An important difference between these levels is that the packets of the transmitting layer are processed by hardware, while at the control level the packets are processed by the central processor. Leaving the control level open to the entire Internet is traditionally a bad idea - it can be used by an attacker to attack on the CPU.

A typical scenario of gaining access to a control level is based on the utilization of an open TCP port. What TCP port is typically open on a network device? This is, of course, the port of some kind of network service or protocol. So we decided to take the BGP port (179) and check how dangerous this problem is.


We first conducted a simple experiment to check whether such an open port is a real vulnerability and can be used to attack a denial of service. The victim was an ordinary Cisco router, to which we made a SYN flood attack, which is intentionally quite simple.

We launched 32 hping syn-flood processes, which allowed us to generate an average traffic load of about 720,000 packets per second at about 0.5 Gb / s.


Even this volume was enough to cause serious consequences. Here is a graph of the CPU load on the device. On the X axis, we have time, on the Y axis, the CPU load. We see that the first 45 minutes, while the attacks did not occur, the processor was practically inactive, but in the last 15 minutes - under attack, it was loaded almost 100%. But looking at this chart, you can still ask - so what? What is it about loading the CPU?

In fact, the processor load level itself was not the only consequence of the attack, and far from the most dangerous.


First, we observed several restarts of the BGP session. Screenshot log on the screen. In addition, we saw several failures in the operation of the OSPF dynamic routing protocol, which resulted in unstable traces to the device. In addition to all this, the overloaded device is simply difficult to reach.


This experiment shows that the open network port vulnerability can be used for denial of service attacks. I want to emphasize the fact that this means a denial of service to more than one individual host - since we are talking about a network device, its unstable operation can lead to more concomitant damage, such as the unavailability of the entire network.


The solution to this problem is simple, as always. Just do not leave control ports open to the entire Internet. Use an access control list (ACL) or at least private addresses. It seems to be nothing complicated.


However, we found that in most situations the control level of the router looks like this. Offers a hug to anyone.


Let's take a look at some statistics on vulnerable hosts. We collected this data with the following methodology: having scanned the available IPv4 space for open BGP ports, we filtered out those ports that answered across all open ports, then check if their behavior is similar to BGP — for example, an instant session reset.


So, here are the numbers. There are over a million vulnerable hosts. About a tenth of all prefixes and about a third of all autonomous systems are at risk. Moreover, about 5,000 of these autonomous systems are suppliers of IP transit, so problems with them will be inherited by customers. We also checked the behavior of these ports and found that most of them close the connection. But there are special cases - for example, about 60,000 hosts sent a notification. And about 70,000 hosts before the end of the connection sends an open message, which is definitely a hug offer to anyone they meet.


_{radar.qrator.net}

The conclusion is simple - despite the fact that the problem of open ports to the whole world has been known for at least several years, it still remains relevant and can lead to bad consequences. I repeat once again that we are talking about the possible inaccessibility of a network device.

We have a tool to test autonomous systems for such vulnerabilities. The tool is free, available to anyone. You only need to register your own autonomous system and confirm ownership to eliminate the use of this information by the attacker. If you have feedback, any opinion or suggestion, please write it.

Thank you very much, if you have any questions, I will be happy to answer them.

PS Colleagues, attention! Already the second week, on our initiative to introduce an automatic protection mechanism against the occurrence of “route leaks” (route leaks), the BGP protocol is making a call.

This means that starting from May 21, 2017, for two weeks on the IETF mailing list (you can subscribe to it here ), all the pros and cons of accepting the proposals proposed by the authors to the working group are discussed. Depending on the voting results, the work on this document will continue until the status of a standard (RFC) is received or frozen.

We ask all those who are not indifferent to the state of BGP issues to express their own arguments in English, in the thread of letters under the heading “draft-ymbk-idr-bgp-open-policy-03”. Remember that when expressing an opinion, you must express your own opinion as an engineer, and not the opinion of your employer. It is highly desirable that your opinion be reasoned - for this we recommend once again to familiarize ourselves with our proposals (refer to the draft: one , two ).

We remind you that anyone can express their opinions on the IETF mailing list - there is no qualification.

We are in advance grateful to every technical specialist, system administrator, developer, and simply interested person who is ready to support our initiative to modernize one of the key protocols that ensure the efficient operation of modern networks.

Thank.