Mitternachtshacking

Diesen Link zu Coding Horror habe ich schon länger archiviert, als Nachtrag zu meinem DoS-Artikel kann ich ihn endlich verwenden.

Rate Limiting, d.h. die Beschränkung von gleichzeitig ausgeführten Operationen z.B. Datenbankabfragen in einer Webapplikation kann ebenfalls als Maßnahme gegen Denial-of-Service Angriffe genutzt werden. Das Problem ist nur, zu wissen wann “zu viel” wirklich zu viel ist. Was ist normales Verhalten (das sich im Laufe der Zeit ändern kann) und was ist ein tatsächlicher Angriff?

Jeff Atwood visualisiert das Problem mit einem Schild an der Eingangstür eines Ladens:

All the signs have various forms of this printed on them: Only 3 students at a time in the store please

Die Vorstellung ist aber auch zu lustig:

• Couldn’t three morally bankrupt students shoplift just as effectively as four?
• How do you tell who is a student? Is it based purely on perception of age?
• Do we expect this rule to be self-enforcing? Will the fourth student walk into the store, identify three other students, and then decide to leave?

Das kann gar keine präzise Wissenschaft sein

Ich überlege gerade für einen Freund, wie man eine Beschreibung von Denial-of-Service Angriffen (DDoS ist nur ein Randthema) und möglichen Gegenmaßnahmen sinnvoll gliedern kann. Meine Idee geht dazu, die verschiedenen Angriffsebenen als Gliederungspunkt heranzuziehen, weil man auf Netzwerkebene halt andere Gegenmaßnahmen hat und braucht als auf Anwendungsebene.

1. Einleitung
2. Definitionen
3. DoS im Systembetrieb
   1. Redundante Netzverbindungen
   2. Redundante Stromversorgung
   3. Sonstige Hardware-Fehler
4. DoS in der Netzwerkkommunikation
   1. DoS auf Layer 2 (ARP, …)
      Praktisch irrelevant, da Angreifer vor Ort sein müssten
   2. DoS auf Layer 3/4 (Smurf, Fraggle, Land, SYN-Flooding, …)
      Praktisch irrelevant, da von Firewalls zuverlässig erkannt und im OS gefixt (SYN-Flooding)
5. DoS auf Betriebssystemebene
   1. OS resource exhaustion (RAM, CPU, …)
      Mehr eine Frage der Kapazitätsplanung
   2. Implementierungsprobleme
      Lösung könnte ein OS-Wechsel oder Stack-Tuning bringen
6. DoS auf Anwendungsebene
   1. Application resource exhaustion (Memory Allocation, …)
      Programmierfehler, Code Analyse hilft
   2. Sonstige Fehler in Anwendungen
      Logikfehler, Concurrency, …
7. DoS auf sonstigen Ebenen
   1. Benutzeraccounts blockieren
      DoS gegen Sicherheitsmaßnahmen
   2. Überlastung durch überraschendes Benutzerverhalten
      “Heise-DoS”, Frage der Kapazitätsplanung
8. Distributed DoS
   1. DDoS auf Netzwerkebene
   2. DDoS auf Betriebssystemebene
   3. DDoS auf Anwendungsebene
9. Gegenmaßnahmen
   1. Schutz auf Layer 2
   2. Schutz auf Layer 3/4
   3. Schutz auf Betriebssystemebene
   4. Schutz auf Anwendungsebene
10. Kosten/Nutzen-Relation

Ist das sinnvoll? Habe ich was wichtiges vergessen?

Nachtrag:

Ideen von Tobias bereits eingearbeitet.

Hihi, laut BBC hat eine durchgeknallte Zentralverriegelung eines Autos dazu geführt, daß auf einem Parkplatz in England alle anderen Funkschlüssel nicht mehr funktioniert haben.

“Ofcom was finally called and a survey found a small family car was intermittently sending out signals blocking other fobs in a 164ft (50 m) radius.”

Ich finde, da kann man mehr draus machen … Irgendwelche Hardware-Hacker irgendwo? Milosch Meriac vielleicht?

Endlich wird so eine Smurf Attack einmal anschaulich erklärt

Microsoft Vista mag Dateien nicht löschen. Oder kopieren. Oder verschieben. Oder ab und zu doch, aber dann sehr sehr langsam. Ich kann das leider nicht testen, “isch ‘abe gar kein Vista”. Jedenfalls kocht es gerade in den Microsoft Foren hoch. Und The Register hat mal wieder was zum Lästern.

Erstaunlich ist, daß Microsoft dafür keinen Fix anbieten kann. So kompliziert erscheint mit das löschen, verschieben und kopieren von Dateien nicht zu sein. Was kann man da eigentlich falsch machen?

Eigentlich ist mit das Thema auch egal. Ich überlege nur gerade, wie man das für einen Denial-of-Service Angriff ausnützen könnte … Ideen, irgendwer?

IPv6 hat ein lustiges Sicherheitsproblem mit einem Routing Header.

Dazu muß man erstmal wissen, wie IPv6 funktioniert. Bei IPv6 sind die Adressen nicht mehr nur 32 Bit lang, wie aktuell im Internet Protokoll sondern 128 Bit, also gerade vier mal so lang. Das Problem dabei ist, damit steigt natürlich für jedes Datenpaket der Overhead an. Ein normaler IPv4 Header hat üblicherweise 20 Byte (ohne IP-Optionen, aber die läßt eh kaum eine Firewall durch), mit den neuen Adressen hätte der Header plötzlich 44 Byte, also mehr als doppelt so groß. Mögliche Header-Optionen sind dabei noch nicht eingerechnet.

Man hat sich nun entschieden, den IPv6-Header etwas anders zu strukturieren. Der Standardheader ist immer gleich groß, nämlich 40 Byte. Durch die konstante Größe wird u.a. das Offloading, d.h. die Verarbeitung in einem extra Chip vereinfacht, der Durchsatz der Netzwerkkarten steigt. Optionen werden in IPv6 durch sogenannte “Extension Header” an den Standardheader angehängt.

Einer dieser Extension Header ist nun der Routing Header 0, kurz RH0 und der hat ein kleines Problem. Man kann da nämlich Adressen angeben, via die ein Paket geschickt werden soll. Bei IPv4 gibt es das auch, entweder als Strict oder Loose Source Routing und jeder weiß, daß das ein Problem sein kann.

Der Witz bei IPv6 ist nun, mittels RH0 kann man bis zu 88 Adressen angeben, via die ein Paket geschickt werden soll. Das ist richtig cool wenn man clevere Denial-of-Service Angriffe fahren will. Dann gibt man einfach 88 Adressen an und kann die im günstigsten Fall alle gleichzeitig DoSen. In der Praxis wird das nicht so einfach sein.

Interessant ist jedenfalls die Lösung der IETF, die für den Standard zuständig ist: Abschalten der Option. Fertig. Das hätte ich vorher auch schon sagen können.

PS:

Wenn ich mich so umkucke, scheinen die klassischen TFN, Stacheldraht und Trinoo immer noch die bekanntesten DDoS-Programme zu sein. Es scheint an der Zeit, mal was geeignetes für IPv6 zu basteln

Ich hatte neulich mal wieder die beliebte Diskussion zur letzten Regel einer Check Point Firewall: “Was ist besser? Drop oder Reject?” Ich finde, die Frage läßt sich gar nicht so einfach beantworten.

Drop, das ist klar, läßt ein Datenpaket einfach verschwinden. Weg. Futsch. Keine Antwort. Für einen NMap SYN-Scan schön erkennbar: open, closed, filtered. Keine Antwort = filtered. Bei UDP ist das jedoch ein wenig komplizierter, da läßt sich zwischen open und filtered nur schwer unterscheiden. Die IP-Adresse der Firewall krieg man meist trotzdem raus, zum Beispiel oft mit einem TCP-Traceroute. Cain& Abel kann sowas.

Reject schickt eine Antwort zurück. Nur … welche? Und ist das konfigurierbar wie bei Netfilter?

• ICMP Type 3, Code 0 (Network Unreachable)
• ICMP Type 3, Code 1 (Host Unreachable)
• ICMP Type 3, Code 3 (Port Unreachable)
• ICMP Type 3, Code 13 (Communication Administratively Prohibited)

Zumindest die letzte Fehlermeldung gibt schon sehr genau Aufschluß darüber, daß ein Paketfilter vorhanden ist.

Andere Überlegung: Im Idealfall sollte es eigentlich egal sein, ob der Angreifer weiß, daß eine Firewall vorhanden ist, welche IP-Adresse die Firewall hat, von welchem Hersteller sie ist und welcher Regelsatz implementiert ist. Gut, in der Praxis trifft das oft nicht zu, aber wir glauben heute mal an das Gute im Firewall-Administrator.

Dann bleibt für mich übrig: Bei einem Reject schickt die Firewall Pakete an eine fremde (d.h. nicht näher bekannte) IP-Adresse. Wenn die Absenderadresse nun gefaked ist, kann man die Firewall leichter z.B. für einen DoS-Sturm mißbrauchen und das will ich lieber nicht.

Das ist so ähnlich wie mit den Rückmeldungen per E-mail, daß eine angeblich von mir verschickte Mail einen Virus enthalten hätte. Nur verwenden viele Viren gefälschte Absenderadressen aus den Adressbüchern und meistens ist genau der, der als Absender drinsteht für den Virus gar nicht verantwortlich. Und ich freue mich bestimmt nicht über die penetrante Werbung einzelner Virenscannerhersteller, daß sie wieder einen Virus vernichtet haben (aber nicht in der Lage sind zu erkennen, daß die Abenderadresse gefälscht war und eine Rückmeldung daher sinnlos).

Am 24. April findet wieder die ArchITecture (PDF), eine Fachhändlermesse von Ingram Micro in Neuss statt. Wie letztes Jahr bin ich mit einer Hacking Show vertreten, dieses Jahr sogar zwei Mal unter dem Titel “Hacking Reloaded VoIP”. Warum ich das schreibe? Weil Kollege Matthias gerade seine Testergebnisse geschickt hat.

• Scannen und anschließende Enumeration der Geräte
• ARP Spoofing, um den Traffic im geswitchten Netz umzuleiten
• Anmeldung mit SIPDump mitsniffen und mit SIPCrack das Password rauslesen
• Gespräche mit Cain & Abel als WAV mitschneiden
• Vulnerability Scan auf die Telefone (DoS-Angriff)

Faszinierend ist dabei, wie einfach und reibungslos das alles funktioniert. Die Hacking-Software ist inzwischen richtig gut ausgereift. Damit kann im Grunde jeder umgehen. Ich will gar nicht wissen, welche Möglichkeiten dann erst den legalen Abhördiensten zur Verfügung stehen. Schutz bietet lediglich die konsequente Trennung von Daten- und VoIP-Verkehr über VLANs im LAN sowie die Ende-zu-Ende-Verschlüsselung der Gespräche.

Die Päsentation mit allen Screenshots der verwendeten Tools wird Anfang Mai nachgereicht. Die Teilnehmer der ArchITecture sollen durch ihren Besuch ja einen Wissensvorsprung bekommen .