Unzureichende Kontrolle des Netzwerknachrichtenvolumens (Netzwerkverstärkung)

Beschreibung

Unzureichende Kontrolle des Netzwerknachrichtenvolumens ist eine Schwachstelle, bei der ein Produkt das übertragene Netzwerkverkehrsvolumen nicht ausreichend überwacht oder kontrolliert, wodurch Akteure das Produkt dazu bringen können, mehr Verkehr zu übertragen, als für die Eingaben des Akteurs zu erwarten wäre. Das Produkt kann nicht zwischen legitimen Übertragungen und für Verstärkungsangriffe konzipiertem Verkehr unterscheiden. Systeme ohne Ressourcenzuweisungsrichtlinien können asymmetrischen Verbrauch nicht einschränken, was sie anfällig für Missbrauch zur Übertragung von Verkehr macht, der das, was der Client erlauben sollte, bei weitem übersteigt. Dies ist besonders verbreitet bei UDP-basierten Protokollen, bei denen Quelladressen gefälscht werden können.

Risiko

Netzwerkverstärkungsschwachstellen ermöglichen verheerende Distributed-Denial-of-Service-(DDoS)-Angriffe mit minimalen Angreiferressourcen. Durch Ausnutzung offener Resolver oder falsch konfigurierter Dienste können Angreifer kleine Anfragen zu massiven Antworten verstarken, die an Opfer gerichtet werden. DNS-Verstärkung kann Verstärkungsfaktoren von 28-54x erreichen, während NTP-monlist-Befehle 556x erreichen können. Diese Angriffe können Terabits an Verkehr erzeugen und Netzwerkinfrastruktur überlasten sowie weitreichende Dienstausfälle verursachen. Organisationen, die verstärkungsanfällige Dienste hosten, sind auch rechtlichen und Reputationsrisiken ausgesetzt, da ihre Infrastruktur gegen andere als Waffe eingesetzt wird.

Lösung

Implementieren Sie Rate-Limiting für Netzwerkantworten, um übermäßige Verkehrserzeugung zu verhindern. Konfigurieren Sie DNS-Server als nur-autoritativ oder beschränken Sie rekursive Abfragen auf vertrauenswürdige Clients. Deaktivieren Sie unnötige UDP-Dienste wie NTP-monlist oder CHARGEN. Implementieren Sie BCP38/BCP84-Ingress-Filterung, um IP-Spoofing zu verhindern. Überwachen Sie ausgehende Verkehrsmuster auf Anomalien. Verwenden Sie Response-Rate-Limiting (RRL) auf DNS-Servern. Weisen Sie Netzwerkressourcen proportional zu Clientzugriffsstufen zu. Setzen Sie Netzwerk-Level-Schutzmaßnahmen wie Scrubbing-Dienste für kritische Infrastruktur ein.

Häufige Auswirkungen

Auswirkung

Details

Verfügbarkeit

Umfang: Verfügbarkeit DoS: Verstärkung - Die primäre Konsequenz ist die Fähigkeit, massive Mengen an Netzwerkverkehr aus kleinen Eingaben zu erzeugen. DoS: Ressourcenverbrauch (CPU/Speicher/Netzwerk) - Systemressourcen können schnell verbraucht werden, was zu schlechter Anwendungsleistung oder Systemabsturz führt. Das Produkt kann verwendet werden, um andere Systeme anzugreifen und deren Verfügbarkeit zu beeinträchtigen.

Beispielcode

Anfälliger Code

# Anfällig: DNS-Resolver, der auf jede Quell-IP antwortet
import socket

def vulnerable_dns_server():
    sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    sock.bind(('0.0.0.0', 53))

    while True:
        data, addr = sock.recvfrom(512)
        # Anfällig: Antwortet auf jede Quell-IP ohne Verifikation
        # UDP erlaubt Fälschung der Quell-IP
        # Angreifer sendet Abfrage mit IP des Opfers als Quelle
        # Antwort (größer als Abfrage) geht an Opfer

        response = process_dns_query(data)  # Antwort ist größer als Abfrage

        # Anfällig: Kein Rate-Limiting
        # Anfällig: Keine Quellverifikation
        # Anfällig: Antwortet auf rekursive Abfragen von jedem
        sock.sendto(response, addr)

// Anfällig: NTP-Server mit aktiviertem monlist
#include <sys/socket.h>

void vulnerable_ntp_handler(int sock, struct sockaddr_in *client) {
    char buffer[48];
    recv(sock, buffer, sizeof(buffer), 0);

    // Anfällig: monlist-Befehl gibt Liste der letzten 600 Clients zurück
    // Kleine Anfrage erzeugt massive Antwort (Verstärkungsfaktor ~556x)
    if (is_monlist_request(buffer)) {
        // Anfällig: Keine Zugriffskontrolle auf monlist
        // Anfällig: Antwortet auf gefälschte Quelladressen
        char response[65000];  // Viel größer als Anfrage
        int len = generate_monlist_response(response);
        sendto(sock, response, len, 0,
               (struct sockaddr*)client, sizeof(*client));
    }
}

# Anfällig: Memcached-Server mit aktiviertem UDP
import socket

def vulnerable_memcached():
    sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    sock.bind(('0.0.0.0', 11211))  # Anfällig: An alle Interfaces gebunden

    while True:
        data, addr = sock.recvfrom(1024)

        # Anfällig: 'stats'-Befehl gibt große Antwort zurück
        # Verstärkungsfaktor bis zu 51.200x
        if data.startswith(b'stats'):
            # Anfällig: Keine Authentifizierung
            # Anfällig: UDP erlaubt Spoofing
            response = get_all_stats()  # Kann Megabytes sein
            sock.sendto(response, addr)  # An gefälschtes Opfer gesendet

Korrigierter Code

# Korrigiert: DNS-Resolver mit Rate-Limiting und Zugriffskontrolle
import socket
import time
from collections import defaultdict

class SecureDNSServer:
    def __init__(self):
        self.rate_limits = defaultdict(list)
        self.max_requests_per_second = 10
        self.allowed_networks = ['10.0.0.0/8', '192.168.0.0/16']

    def is_rate_limited(self, ip):
        now = time.time()
        # Alte Einträge bereinigen
        self.rate_limits[ip] = [t for t in self.rate_limits[ip] if now - t < 1]

        if len(self.rate_limits[ip]) >= self.max_requests_per_second:
            return True

        self.rate_limits[ip].append(now)
        return False

    def is_allowed_network(self, ip):
        # Korrigiert: Nur Abfragen von vertrauenswürdigen Netzwerken erlauben
        import ipaddress
        client_ip = ipaddress.ip_address(ip)
        for network in self.allowed_networks:
            if client_ip in ipaddress.ip_network(network):
                return True
        return False

    def run(self):
        sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
        # Korrigiert: An spezifisches Interface binden, nicht 0.0.0.0
        sock.bind(('10.0.0.1', 53))

        while True:
            data, addr = sock.recvfrom(512)
            client_ip = addr[0]

            # Korrigiert: Prüfen ob Client aus erlaubtem Netzwerk ist
            if not self.is_allowed_network(client_ip):
                continue  # Still verwerfen

            # Korrigiert: Rate-Limiting anwenden
            if self.is_rate_limited(client_ip):
                continue  # Übermäßige Anfragen verwerfen

            # Korrigiert: Rekursion für externe Abfragen deaktivieren
            response = process_dns_query(data, allow_recursion=False)

            # Korrigiert: Response Rate Limiting (RRL) implementieren
            if len(response) > len(data) * 10:
                response = truncate_response(response)

            sock.sendto(response, addr)

// Korrigiert: NTP-Server mit deaktiviertem monlist und Zugriffskontrolle
#include <sys/socket.h>

// Korrigiert: monlist in ntp.conf deaktivieren:
// disable monitor
// restrict default noquery nomodify notrap nopeer

void secure_ntp_handler(int sock, struct sockaddr_in *client,
                        struct access_list *allowed) {
    char buffer[48];
    recv(sock, buffer, sizeof(buffer), 0);

    // Korrigiert: Zugriffskontrollliste prüfen
    if (!is_allowed_client(client, allowed)) {
        return;  // Anfrage verwerfen
    }

    // Korrigiert: monlist-Befehl vollständig deaktivieren
    if (is_monlist_request(buffer)) {
        // Korrigiert: Fehler statt Daten zurückgeben
        send_error_response(sock, client, "Befehl deaktiviert");
        return;
    }

    // Korrigiert: Antworten Rate-Limiten
    if (is_rate_limited(client)) {
        return;
    }

    // Nur Standard-NTP-Zeitabfragen verarbeiten
    if (is_valid_time_query(buffer)) {
        char response[48];  // Korrigiert: Antwort gleiche Größe wie Anfrage
        generate_time_response(response);
        sendto(sock, response, 48, 0,
               (struct sockaddr*)client, sizeof(*client));
    }
}

# Korrigiert: Memcached mit deaktiviertem UDP und Authentifizierung
import socket

def secure_memcached():
    # Korrigiert: Nur TCP verwenden, UDP vollständig deaktivieren
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

    # Korrigiert: Nur an localhost binden
    sock.bind(('127.0.0.1', 11211))
    sock.listen(10)

    while True:
        conn, addr = sock.accept()

        # Korrigiert: SASL-Authentifizierung erfordern
        if not authenticate_sasl(conn):
            conn.close()
            continue

        # Korrigiert: Verbindungslimits pro IP implementieren
        if connection_count(addr[0]) > MAX_CONNECTIONS_PER_IP:
            conn.close()
            continue

        handle_authenticated_connection(conn)

---

Ausgenutzt in der Praxis

Spamhaus DDoS-Angriff (Spamhaus, 2013)

Der Spamhaus-Angriff war einer der größten DDoS-Angriffe, die zu dieser Zeit jemals aufgezeichnet wurden, und erreichte 300 Gbps. Angreifer nutzten offene DNS-Resolver aus, um Verkehr zu verstarken, der an die Anti-Spam-Organisation gerichtet war, und verursachten Kollateralschäden, die Internetverbindungen weltweit verlangsamten. Der Angriff demonstrierte das verheerende Potenzial von DNS-Verstärkung.

• Cloudflare Blog - The DDoS That Almost Broke the Internet

GitHub Memcached-Angriff (GitHub, 2018)

GitHub erlebte den größten DDoS-Angriff, der zu dieser Zeit jemals aufgezeichnet wurde, mit einem Spitzenwert von 1,35 Tbps. Angreifer nutzten falsch konfigurierte Memcached-Server mit aktiviertem UDP aus und erreichten Verstärkungsfaktoren von bis zu 51.200x. Der Angriff dauerte nur 20 Minuten vor der Mitigation, demonstrierte aber einen neuen Verstärkungsvektor.

• Wired - GitHub Survived the Biggest DDoS Attack Ever Recorded

Amazon Web Services Angriff (AWS-Kunde, 2020)

AWS mitigierte einen 2,3 Tbps DDoS-Angriff, der auf einen Kunden abzielte - den größten, der zu dieser Zeit jemals gemeldet wurde. Der Angriff verwendete CLDAP-Reflexion mit Verstärkungsfaktoren von 56-70x. Er dauerte drei Tage und erforderte AWS Shield Advanced zur Mitigation.

• ZDNet - AWS said it mitigated a 2.3 Tbps DDoS attack

Dyn DNS-Angriff (Dyn, 2016)

Der Mirai-Botnet-Angriff gegen den DNS-Anbieter Dyn kombinierte traditionellen Botnet-Verkehr mit Verstärkungstechniken und störte große Websites wie Twitter, Netflix und Reddit. Obwohl primär ein Botnet-Angriff, hob er die kritische Rolle der DNS-Infrastruktur hervor.

• Krebs on Security - DDoS on Dyn Impacts Twitter, Spotify, Reddit

---

Tools zum Testen/Ausnutzen

• hping3 — Netzwerktool zum Erstellen benutzerdefinierter Pakete, um Verstärkungsschwachstellen und Antwortverhältnisse zu testen.
• Scapy — Python-Paketmanipulationsbibliothek zum Erstellen gefälschter UDP-Pakete, um DNS/NTP-Verstärkung zu testen.
• dnsenum — DNS-Enumerationstool, das offene Resolver identifizieren kann, die für Verstärkung anfällig sind.

---

CVE-Beispiele

• CVE-1999-0513 — Smurf-Angriff mit gefälschten ICMP-Paketen an Broadcast-Adressen zur Verstärkung.
• CVE-1999-1379 — DNS-Abfrageverstarkung über gefälschte Quelladressen.
• CVE-2013-5211 — NTP-monlist-Befehl ermöglicht Verstärkung mit Faktor 556x.
• CVE-2000-0041 — Große Datagramme als Antwort auf fehlerhafte Eingabe ermöglichen Verstärkung.

---

Referenzen

1. MITRE Corporation. "CWE-406: Insufficient Control of Network Message Volume (Network Amplification)." https://cwe.mitre.org/data/definitions/406.html
2. CISA. "DNS Amplification Attacks." https://www.cisa.gov/news-events/alerts/2013/03/29/dns-amplification-attacks
3. Cloudflare. "DNS amplification DDoS attack." https://www.cloudflare.com/learning/ddos/dns-amplification-ddos-attack/