Blow from the past: DIPS-attack RIPv1, or the old routers are dangerous
Attacks using the outdated routing protocol RIPv1 have been seen again since May 16, 2015, after more than a year of oblivion. They were recorded first by Akamai, and after a couple of days - by DDoS-GUARD.
RIPv1 was first introduced in the “historical” RFC1045 (the original specification is no longer supported). The protocol only supports class routing. Thus, if the network advertised via RIPv1 belongs to class “A” (for example, 10.1.2.0/24), then the actual announcement sent will look like 10.0.0.0/8. This, among other things, significantly limits the use of RIPv1 by internal networks, it is of little use for the Internet.
The main characteristics of the attack under consideration
')
• traffic volume: up to 12.8 Gbps
• packets per second: up to 3.2 million
• attack vector: amplification of RIPv1
• outgoing port: UDP: 520
• incoming port: random
RIPv1 (Routing Information Protocol, version 1) has been around for many years and is considered a quick and easy way to exchange information about routes in a small network with several routers.
A router supporting RIP sends a request upon initial setup or upon power-up. Any other device that accepts such requests will respond with a route list. Route table updates are periodically broadcast.
To change the behavior of RIPv1 for conducting a DdoS attack, an attacker can send the same request by replacing the outgoing IP address of the attack object. The addressees are selected according to a previously prepared list of routers with RIPv1 support, which have a suspiciously large number of routes in the tables.
As a result of a single request, a large number of packets with a 504-byte load are sent to the address being attacked. Multiple responses can be sent to one request due to the restriction of 25 routes per RIP packet.
In the listing below, the RIP responses are taken from a real attack. From the side of the attacker, only responses to RIPv1 requests are visible, which he, of course, did not do.
Load examples
A typical RIPv1 request contains 24 bytes. The answer given is 504 bytes. This particular router responds with ten replies of 504 bytes and one in 164 bytes.
When calculating the gain by the above requests, taking into account the Ipv4 [IP (IP (10) UDP10) UDP (8)] headers, the final gain for a single RIPv1 request is 131.24 (more than 13,000%). The coefficient will vary depending on the number of routes in the router table. During the first attack, most routers responded with multiple 504-byte responses to each request.
A surface scan of the attack sources suggests that the victims used to create the storm of RIP responses used primitive routers (of the SOHO class). The RIPv1 implemented on them works in accordance with the specification, the attackers simply use its features for their own purposes.
Poisoning RIPv1
Can an attacker further increase the gain by forcing the router to learn new routes? The idea seems feasible. But there are three main factors that prevent the effective use of such a scenario in DdoS-attacks.
The first factor is the “split horizon” used by default on some devices supporting RIPv1. Simply put, a router that receives an update of routes will not send it back through the same interface it received. This means that a device connected to the Internet will not send spurious routes to the object of attack. However, it will update these routes when they become obsolete until the 16th metric.
This results in another overwhelming factor. Route tables are often cleared, and too old routes will not persist for long. As they become obsolete, another update will be required in order for the router to save them. For example, in Cisco devices, the routes that arrived with an injection will not appear until they become unused (metric 16) and remain only 1 minute after they are marked unused, after which they will be erased from the route table.
Thus, continuous regular updates will be required to maintain the “poisoning” of the tables. The need for repeated injections leads to a decrease in the gain, because instead of a single 24-byte request, you will have to send multiple announcements up to 504 bytes each (depending on the number of routes per injection) in order to maintain route tables in the desired attacker state.
The third problem is that RIPv1 responses coming from networks not directly connected to the router will be ignored. This means that the address of the source of updates must be falsified so as to get into the network directly connected with the “poisoned” router so that the update is at least just accepted.
All this together makes attempts to poison RIPv1 route tables unprofitable and unattractive for an attacker.
With local access to a device (router), routes can be manipulated within the capabilities of the device itself. Such a scenario is possible in the case when the control of the roadizer is available with default credentials or no user identity at all. Such shortcomings in configuring routers are more common than we would like.
Considered attack
The attack on May 16, 2015, with a peak load of 12.81 Gbit and 3.2 million packets per second. In the table below, the load, broken down by geographical location of traffic sources, shows that the largest traffic came from Europe. London and Frankfurt recorded a total of 4.75 Gbps.
RIPv1 scan results on the Internet
According to Akamai, a total of 53,693 devices responded to RIPv1 requests on the Internet. Although many of them are not suitable as DdoS amplifiers, they are still vulnerable to repel and other attacks, due to the low security of the protocol. In general, about 500 unique sources were identified, sending 504-byte responses.
Most of the 53,693 possible sources respond with a single route — which makes them the usual “reflectors”, without additional amplification.
Considering the sizes of RIPv1 responses received on the Internet, a sufficiently large number of devices can be seen that provide at least a small gain factor. It was possible to identify 24,212 devices providing a gain of at least 83%. The table below shows the 5 most common packet lengths obtained during testing.
Another interesting finding is that when RIPv1 implementations are detected, an incorrectly structured request is answered with a message that does not contain real information about their routing tables. Although this eliminates the gain, reducing the attack to a simple reflection, this effect can be used to mask the true source of malicious traffic .
Identified addresses were sorted to identify device models. Of the 53,693 devices that responded to the request, more than 20,000 also listened to the TCP port: 80 (often used by the web-based administrator interface). An attempt was made to extract and record the results of queries in the search for leaks of information about models (authentication requests, HTTP headers, model numbers on the home pages, etc.). Below are the three most common devices (among those discovered) that support RIPv1. Netopia devices are probably old equipment that became popular during the ADSL boom.
The following figure shows the distribution by providers (based on whois answers) of the addresses of detected Netopia devices. Most of them are used by AT & T customers.
Most of the devices are geographically located in the USA, as shown in the following figure. As mentioned above, the sources of malicious traffic recorded during recent attacks were mainly in Europe. This means that there is a significant potential (not yet used) resource that can be used for attacks with amplification and reflection.
The distribution of traffic sources by country is shown in the following figure. What unites them is that each of them, in response to a request, reports an unusually large number of routes.
Recommended Protective Measures
For victims of such attacks, for example, sources of “reflected” traffic, there are several ways to protect against this method.
Switch to RIPv2 or later using authentication.
If RIPv1 is needed, reconsider the need for RIPv1 support on external interfaces. If it is not needed there, mark external interfaces as passive for RIPv1 (where this feature is supported).
Access to the RIP can also be limited by using an ACL, allowing access only to well-known routers.
Objects of attack by reflected RIPv1 traffic can use ACLs to prohibit traffic from an outgoing UDP port: 520 on the Internet. If the attack is too powerful, then you may need the services of a security provider against DdoS.
findings
The list of possible attack vectors is considerable, and some are harder to control than others because of their ubiquitous distribution (for example, DNS, SSDP). As already mentioned, RIPv1 has certain opportunities to remain an attractive resource for organizing DDoS attacks. Most of the sources of this resource are outdated routers that have been working in homes or home offices for years.
A large number of Netopia devices illustrates this well. Providers will not replace previously installed equipment if it performs its functions properly. If there are no problems - why change something?
Thus, devices that support obsolete protocols and contain known software vulnerabilities remain in service. Providers will have the greatest influence on this situation. First of all, you should close the UDP: 520 port from the Internet. This will significantly reduce the possibility of implementing the described DDoS attacks. Another option, more expensive, is to organize the upgrade of client equipment, its replacement with new routers (with the correct configurations); This will be especially true for devices that are no longer supported by manufacturers.
Adapted translation prepared by DDoS-GUARD technical specialists
RIPv1 was first introduced in the “historical” RFC1045 (the original specification is no longer supported). The protocol only supports class routing. Thus, if the network advertised via RIPv1 belongs to class “A” (for example, 10.1.2.0/24), then the actual announcement sent will look like 10.0.0.0/8. This, among other things, significantly limits the use of RIPv1 by internal networks, it is of little use for the Internet.
The main characteristics of the attack under consideration
')
• traffic volume: up to 12.8 Gbps
• packets per second: up to 3.2 million
• attack vector: amplification of RIPv1
• outgoing port: UDP: 520
• incoming port: random
RIPv1 (Routing Information Protocol, version 1) has been around for many years and is considered a quick and easy way to exchange information about routes in a small network with several routers.
A router supporting RIP sends a request upon initial setup or upon power-up. Any other device that accepts such requests will respond with a route list. Route table updates are periodically broadcast.
To change the behavior of RIPv1 for conducting a DdoS attack, an attacker can send the same request by replacing the outgoing IP address of the attack object. The addressees are selected according to a previously prepared list of routers with RIPv1 support, which have a suspiciously large number of routes in the tables.
As a result of a single request, a large number of packets with a 504-byte load are sent to the address being attacked. Multiple responses can be sent to one request due to the restriction of 25 routes per RIP packet.
In the listing below, the RIP responses are taken from a real attack. From the side of the attacker, only responses to RIPv1 requests are visible, which he, of course, did not do.
Load examples
A typical RIPv1 request contains 24 bytes. The answer given is 504 bytes. This particular router responds with ten replies of 504 bytes and one in 164 bytes.
When calculating the gain by the above requests, taking into account the Ipv4 [IP (IP (10) UDP10) UDP (8)] headers, the final gain for a single RIPv1 request is 131.24 (more than 13,000%). The coefficient will vary depending on the number of routes in the router table. During the first attack, most routers responded with multiple 504-byte responses to each request.
A surface scan of the attack sources suggests that the victims used to create the storm of RIP responses used primitive routers (of the SOHO class). The RIPv1 implemented on them works in accordance with the specification, the attackers simply use its features for their own purposes.
Poisoning RIPv1
Can an attacker further increase the gain by forcing the router to learn new routes? The idea seems feasible. But there are three main factors that prevent the effective use of such a scenario in DdoS-attacks.
The first factor is the “split horizon” used by default on some devices supporting RIPv1. Simply put, a router that receives an update of routes will not send it back through the same interface it received. This means that a device connected to the Internet will not send spurious routes to the object of attack. However, it will update these routes when they become obsolete until the 16th metric.
This results in another overwhelming factor. Route tables are often cleared, and too old routes will not persist for long. As they become obsolete, another update will be required in order for the router to save them. For example, in Cisco devices, the routes that arrived with an injection will not appear until they become unused (metric 16) and remain only 1 minute after they are marked unused, after which they will be erased from the route table.
Thus, continuous regular updates will be required to maintain the “poisoning” of the tables. The need for repeated injections leads to a decrease in the gain, because instead of a single 24-byte request, you will have to send multiple announcements up to 504 bytes each (depending on the number of routes per injection) in order to maintain route tables in the desired attacker state.
The third problem is that RIPv1 responses coming from networks not directly connected to the router will be ignored. This means that the address of the source of updates must be falsified so as to get into the network directly connected with the “poisoned” router so that the update is at least just accepted.
All this together makes attempts to poison RIPv1 route tables unprofitable and unattractive for an attacker.
With local access to a device (router), routes can be manipulated within the capabilities of the device itself. Such a scenario is possible in the case when the control of the roadizer is available with default credentials or no user identity at all. Such shortcomings in configuring routers are more common than we would like.
Considered attack
The attack on May 16, 2015, with a peak load of 12.81 Gbit and 3.2 million packets per second. In the table below, the load, broken down by geographical location of traffic sources, shows that the largest traffic came from Europe. London and Frankfurt recorded a total of 4.75 Gbps.
RIPv1 scan results on the Internet
According to Akamai, a total of 53,693 devices responded to RIPv1 requests on the Internet. Although many of them are not suitable as DdoS amplifiers, they are still vulnerable to repel and other attacks, due to the low security of the protocol. In general, about 500 unique sources were identified, sending 504-byte responses.
Most of the 53,693 possible sources respond with a single route — which makes them the usual “reflectors”, without additional amplification.
Considering the sizes of RIPv1 responses received on the Internet, a sufficiently large number of devices can be seen that provide at least a small gain factor. It was possible to identify 24,212 devices providing a gain of at least 83%. The table below shows the 5 most common packet lengths obtained during testing.
Another interesting finding is that when RIPv1 implementations are detected, an incorrectly structured request is answered with a message that does not contain real information about their routing tables. Although this eliminates the gain, reducing the attack to a simple reflection, this effect can be used to mask the true source of malicious traffic .
Identified addresses were sorted to identify device models. Of the 53,693 devices that responded to the request, more than 20,000 also listened to the TCP port: 80 (often used by the web-based administrator interface). An attempt was made to extract and record the results of queries in the search for leaks of information about models (authentication requests, HTTP headers, model numbers on the home pages, etc.). Below are the three most common devices (among those discovered) that support RIPv1. Netopia devices are probably old equipment that became popular during the ADSL boom.
The following figure shows the distribution by providers (based on whois answers) of the addresses of detected Netopia devices. Most of them are used by AT & T customers.
Most of the devices are geographically located in the USA, as shown in the following figure. As mentioned above, the sources of malicious traffic recorded during recent attacks were mainly in Europe. This means that there is a significant potential (not yet used) resource that can be used for attacks with amplification and reflection.
The distribution of traffic sources by country is shown in the following figure. What unites them is that each of them, in response to a request, reports an unusually large number of routes.
Recommended Protective Measures
For victims of such attacks, for example, sources of “reflected” traffic, there are several ways to protect against this method.
Switch to RIPv2 or later using authentication.
If RIPv1 is needed, reconsider the need for RIPv1 support on external interfaces. If it is not needed there, mark external interfaces as passive for RIPv1 (where this feature is supported).
Access to the RIP can also be limited by using an ACL, allowing access only to well-known routers.
Objects of attack by reflected RIPv1 traffic can use ACLs to prohibit traffic from an outgoing UDP port: 520 on the Internet. If the attack is too powerful, then you may need the services of a security provider against DdoS.
findings
The list of possible attack vectors is considerable, and some are harder to control than others because of their ubiquitous distribution (for example, DNS, SSDP). As already mentioned, RIPv1 has certain opportunities to remain an attractive resource for organizing DDoS attacks. Most of the sources of this resource are outdated routers that have been working in homes or home offices for years.
A large number of Netopia devices illustrates this well. Providers will not replace previously installed equipment if it performs its functions properly. If there are no problems - why change something?
Thus, devices that support obsolete protocols and contain known software vulnerabilities remain in service. Providers will have the greatest influence on this situation. First of all, you should close the UDP: 520 port from the Internet. This will significantly reduce the possibility of implementing the described DDoS attacks. Another option, more expensive, is to organize the upgrade of client equipment, its replacement with new routers (with the correct configurations); This will be especially true for devices that are no longer supported by manufacturers.
Adapted translation prepared by DDoS-GUARD technical specialists
Source: https://habr.com/ru/post/263503/
All Articles