DDoS looking for power
I think many have heard of DNS amplification and NTP amplification attacks. Much has been written about these two special cases of UDP-based Amplification attacks. What other protocols can be used for amplification? In this context, in the article I propose to consider the tftp protocol.
Let's go back a bit and remember what the UDP-based Amplification attack represents. The whole implementation comes down to two points:
Thus, it turns out that every bit we send to the victim comes “amplified” by a factor. Here is a list of protocols and their gains according to us-cert.gov:
')
This is not a complete list, there are other "interesting" protocols, for example, tftp. My article will be further devoted to him.
Trivial File Transfer Protocol (tftp) is really very trivial, the name describes all the functionality. Tftp does not support authentication, and indeed no security mechanisms. To implement the UDP-based Amplification attack, we need to understand which tftp packet will return “enhanced”. The packet initiating the receipt / transmission looks like this:
After reviewing RFC 1350 , it becomes clear that only the package initiating the receipt of the file meets our requirements. According to the standard, the first packet of the sender address in which it is possible to forge can be RRQ (Read request) or WRQ (Write request). In response to the WRQ, the server sends a small confirmation packet, but the first packet of requested data, no larger than 512 bytes, comes to the RRQ. The format we need is:
\ x01 - opcode RRQ
octet - type of transmission, in our case it is not important
To create such a package and subsequent testing, I will use Scapy . I propose to test the possibility of using tftp amplification, for a start in ideal conditions.
On the host OS, tftpd32 is running, on guest scapy, the laptop plays the role of a victim. The first test, sending such a package:
The following traffic appeared on the victim side:
Thus, the 62 bytes we sent generated traffic of 1306 bytes, which is 21 times greater than the original. It turned out a small coefficient, but let's ban icmp traffic, as it often happens.
This time the following traffic will appear:
The total volume is 3415 bytes, the coefficient is 55 this time. This is already something comparable to DNS amplification.
The number of available tftp servers does not exceed 200 thousand, as estimated by shodanhq.com, and on its own "sensations". Compared to 28 million "dangerous" DNS servers, the threat from tftp servers is negligible. Additionally, to use the gain, you must know the file name on the server or be able to write. It also reduces the number of servers that can be used. To find suitable servers a simple script was written.
Of the 10,000 servers tested by me, only 1.5 thousand turned out to be suitable, but I think this figure can be increased by making a competent list of file names that are checked for availability.Unfortunately, fortunately, my provider did not give the opportunity to test the increase in load on the interface of paid vps, as the equipment dropped packets with the "wrong" sender address. I had to use the means at hand. On a guest machine with scapy, the speed of the tc program was limited, and the victim was still a laptop with a traffic monitor. By remaking the script, in practice, the gain was achieved by a factor of 31 (according to the scheme without an icmp response). It is difficult to speak about the veracity of practical indicators, since the provider may be making adjustments to the priorities of the speed of traffic.
I believe that tftp UDP-based Amplification, although comparable in gain, to DNS amplification, is not so critical, due to the lower prevalence and properties of operation. It is possible to use as part of a hybrid attack, and the use as the only attack vector, I think, is justified only on weak data transmission channels.
It seems to me that some experts might have a wrong understanding of “Amplification” -atac, according to the principle “I have no public DNS, NTP, it will not affect me.” In this article I want to draw your attention to the fact that the main problem of “Amplification” of attacks is not only in the implementation of DNS, NTP, tftp, etc. services, but lies a lower level, according to the TCP / IP protocol stack - the UDP protocol. To solve this problem, work on many levels is necessary, programmers when creating services on UDP should try to reduce the gain, network specialists should put a ban on changing the sender's IP address in their zones, and system administrators should limit access to services on the basis of sufficiency.
Analysis of other services running on UDP:
Quake 3 server
SSDP
SNMP, NTP, Chargen
PS There are readers who can tell about cases from practice, which met UDP-based Amplification attacks, in addition to DNS and NTP, whether there were hybrid, what power, please share your experiences in the comments.
Let's go back a bit and remember what the UDP-based Amplification attack represents. The whole implementation comes down to two points:
- 1) Sending to the vulnerable service a special UDP packet with a fake sender address (the address of the victim
- 2) The response of the service to the address of the victim by a package several times larger than the initial one.
Thus, it turns out that every bit we send to the victim comes “amplified” by a factor. Here is a list of protocols and their gains according to us-cert.gov:
')
This is not a complete list, there are other "interesting" protocols, for example, tftp. My article will be further devoted to him.
Theory
Trivial File Transfer Protocol (tftp) is really very trivial, the name describes all the functionality. Tftp does not support authentication, and indeed no security mechanisms. To implement the UDP-based Amplification attack, we need to understand which tftp packet will return “enhanced”. The packet initiating the receipt / transmission looks like this:
After reviewing RFC 1350 , it becomes clear that only the package initiating the receipt of the file meets our requirements. According to the standard, the first packet of the sender address in which it is possible to forge can be RRQ (Read request) or WRQ (Write request). In response to the WRQ, the server sends a small confirmation packet, but the first packet of requested data, no larger than 512 bytes, comes to the RRQ. The format we need is:
\ x01 - opcode RRQ
octet - type of transmission, in our case it is not important
To create such a package and subsequent testing, I will use Scapy . I propose to test the possibility of using tftp amplification, for a start in ideal conditions.
On the host OS, tftpd32 is running, on guest scapy, the laptop plays the role of a victim. The first test, sending such a package:
The following traffic appeared on the victim side:
Thus, the 62 bytes we sent generated traffic of 1306 bytes, which is 21 times greater than the original. It turned out a small coefficient, but let's ban icmp traffic, as it often happens.
# iptables -I OUTPUT -p icmp --icmp-type destination-unreachable -j DROP
This time the following traffic will appear:
The total volume is 3415 bytes, the coefficient is 55 this time. This is already something comparable to DNS amplification.
Practice
The number of available tftp servers does not exceed 200 thousand, as estimated by shodanhq.com, and on its own "sensations". Compared to 28 million "dangerous" DNS servers, the threat from tftp servers is negligible. Additionally, to use the gain, you must know the file name on the server or be able to write. It also reduces the number of servers that can be used. To find suitable servers a simple script was written.
Script itself
name_list.txt is a list of file names whose presence is to be checked on tftp, my list is EUPL-EN.pdf; tftpd32.ini; .bash_history; startup-config; running-config; pxelinux.cfg; linux.bin; boot.bin
#/usr/bin/env python from scapy.all import * from random import randint import os, time import multiprocessing as mp def send_udp(ip): name_list = open('name_list.txt', 'r') wr_str = os.urandom(511) tftp_wrq = IP(dst=ip)/UDP(sport=2222, dport=69)/TFTP()/TFTP_WRQ(filename='filename', mode='octet') p_wrq = sr1(tftp_wrq, timeout=2, verbose=0) try: if p_wrq.payload.payload.load: if p_wrq.payload.payload.load[1] == '\x04': tftp_data = IP(dst=ip)/UDP(sport=2222, dport=p_wrq.sport)/TFTP()/TFTP_DATA(block=0)/wr_str send(tftp_data, verbose=0) res = (ip, 'filename') return res elif p_wrq.payload.payload.load[1] == '\x05': for name in name_list.read().split('\n'): tftp_rrq = IP(dst=ip)/UDP(sport=2222, dport=69)/TFTP()/TFTP_RRQ(filename=name, mode='octet') p_rrq = sr1(tftp_rrq, timeout=2, verbose=0) if p_rrq.payload.payload.load[1] == '\x03': res = (ip, name) return res except AttributeError: return False def save(res): if res: fo.write('%s:%s\n' % res) def main(ip_mas): pool = mp.Pool(5) for ip in ip_mas: pool.apply_async(send_udp, args=(ip, ), callback=save) pool.close() pool.join() if __name__ == '__main__': f = open('tftp_list.txt', 'r') fo = open('results.txt', 'a') ip_mas = [] for line in f.read().split('\n'): if line: if len(line.split('.')) == 4: ip_mas.append(line) main(ip_mas) f.close() fo.close() name_list.txt is a list of file names whose presence is to be checked on tftp, my list is EUPL-EN.pdf; tftpd32.ini; .bash_history; startup-config; running-config; pxelinux.cfg; linux.bin; boot.bin
Of the 10,000 servers tested by me, only 1.5 thousand turned out to be suitable, but I think this figure can be increased by making a competent list of file names that are checked for availability.
Conclusion
I believe that tftp UDP-based Amplification, although comparable in gain, to DNS amplification, is not so critical, due to the lower prevalence and properties of operation. It is possible to use as part of a hybrid attack, and the use as the only attack vector, I think, is justified only on weak data transmission channels.
It seems to me that some experts might have a wrong understanding of “Amplification” -atac, according to the principle “I have no public DNS, NTP, it will not affect me.” In this article I want to draw your attention to the fact that the main problem of “Amplification” of attacks is not only in the implementation of DNS, NTP, tftp, etc. services, but lies a lower level, according to the TCP / IP protocol stack - the UDP protocol. To solve this problem, work on many levels is necessary, programmers when creating services on UDP should try to reduce the gain, network specialists should put a ban on changing the sender's IP address in their zones, and system administrators should limit access to services on the basis of sufficiency.
Analysis of other services running on UDP:
Quake 3 server
SSDP
SNMP, NTP, Chargen
PS There are readers who can tell about cases from practice, which met UDP-based Amplification attacks, in addition to DNS and NTP, whether there were hybrid, what power, please share your experiences in the comments.
Source: https://habr.com/ru/post/247707/
All Articles