Mitternachtshacking

IPv6 hat ein lustiges Sicherheitsproblem mit einem Routing Header.

Dazu muss man erst einmal 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ässt 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ß, dass 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 umsehe, 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 🙂

Das ZDF hat ein paar der Abenteuer von Ijon Tichy verfilmt.

Für die Banausen: Ijon Tichy, Weltraumfahrer, ist die Hauptfigur der Sterntagebücher von Stanislaw Lem. Und der wiederum gehört zu meinen Lieblingsautoren.

Meine Lieblingsepisode mit den relativistischen Effekten ist auch dabei und man kann sich die Kurzfilme als Videostream ankucken.

Ein paar Gedanken zum Scannen:

TCP- und UDP-Scanning ist durch Nmap weitgehend erschlagen. Da gibt es nicht mehr ganz so viel zu ergänzen. Interessant sind jedoch spezielle Scanner, die nur ein einzelnes Protokoll berücksichtigen, dafür jedoch erweiterte Möglichkeiten anbieten.

SNMP beispielsweise. Der SNMP-Scanner von Foundstone (jetzt McAfee) ist schon ganz brauchbar. Man kann mittels Dictionary Community Strings testen und sehr schnell und effizient Netzwerke nach SNMP-Agenten durchscannen.

Richtig beeindruckt hat mich aber der IKE-Scanner von NTA. Man kann damit IKE Phase 1 Pakete mit diversen IKE-Parametern erzeugen und auswerten wie der VPN-Gateway darauf reagiert. Ein paar Sachen zu IKE kann man bei der Gelegenheit auch gleich lernen. Richtig cool.

Unglaublich, Microsoft hat tatsächlich gelegentlich sogar brauchbare Informationen auf ihrer Webseite. Gut, der Untertitel „Verbessern Sie Ihr Netzwerk mit Microsoft Technologien“ ist offensichtlich als Gag gemeint. Aber der Rest ist echt empfehlenswert.

Der Cable Guy erklärt jeden Monat einen Dienst oder ein Protokoll im Netzwerk und in der Regel so, dass man das gut verstehen kann. Die meisten Artikel sind leider Vista Werbung, aber ab und zu ist eine echte Perle dabei.

Ich war auf der Suche nach der Explicit Congestion Notification (ECN) Erweiterung von TCP/IP. Nmap verwendet das als eine der Methoden zum OS Fingerprinting. Beschrieben wird ECN in RFC 3168, erklärt jedoch nicht. Eine brauchbare Beschreibung hatte freundlicherweise der Beitrag von Oktober 2006.

Weitere interessante Themen sind IPv6, hier gibt es eine Vielzahl von Erklärungen sowie diverse Beiträge zu Wireless LAN. Am besten einfach mal durch die Themen stöbern und in die interessant klingenden Artikel reinschnuppern. Ich kann das sehr empfehlen.

Die IP-Adressen werden irgendwann knapp. Nicht so sehr bei uns, aber in China, Indien, etc. wird es irgendwann (und zwar relativ bald) ein Problem geben. Deshalb ist ja IPv6 in der Pipeline und wird irgendwann das aktuelle IPv4 ablösen.

Stuart Brown von Modern Life hat sich die Mühe gemacht, das mal auf Länder und Einwohner runterzubrechen. Mit interessanten Ergebnissen. Die meisten IP-Adressen, zumindest umgerechnet auf die Anzahl der Einwohner hat ….. der Vatikan.

Die komplette Liste mit netter Grafik gibt es bei hier.

OSCON 2005 Keynote – Identity 2.0 von Dick Hardt

genial … unbedingt anschauen

und in diesem Zusammenhang: The Laws of Identity

Die häufigste Komponente die bei Servern zur Zeit ausfällt sind Festplatten. Und meistens sind das auch die Komponenten die am ärgerlichsten sind. Netzteile lassen sich einfach austauschen. Modul raus, neues Modul rein, fertig. Man braucht nichts neu installieren, alles läuft wieder. Motherboards sind schon schlimmer. Eventuell bootet das System nicht richtig, weil Treiber fehlen und bei einigen Computerspiel-Betriebssystemen benötigt es sogar eine „Reaktivierung“, weil sich die Hardware geändert hat. Defekte Festplatten aber sind ärgerlich (sofern kein RAID die Daten rettet).

Das System muss neu installiert werden; wenn Backups nicht regelmäßig laufen, sind auch noch Daten verloren (irgendwas ist immer futsch, weil die Backups ja nicht minütlich stattfinden) und der Arbeitsaufwand ist immens höher als nur ein Netzteil zu tauschen. Neulich erst ist einem Kunden die (nicht gespiegelt) Platte des Mailservers abgeraucht. Da ist schnell ein dreiviertel Tag um, bis ein neuer Mailserver installiert und konfiguriert ist. Selbst wenn der Datenverlust keine Rolle spielt.

Zum Glück gibt es inzwischen halbwegs brauchbare statistische Daten, um die Fehlerwahrscheinlichkeit der Platten abzuschätzen. Google hat beispielsweise einen Bericht zu Festplattenfehlern in ihren Serverfarmen veröffentlicht (Failure Trends in a Large Disk Drive Population, PDF). Die Carnegie Mellon University wiederum hat sich mit dem Begriff MTTF auseinandergesetzt (Disk failures in the real word: What does an MTTF of 1,000,000 hours mean to you, PDF). Beide Arbeiten sind auf der 5. USENIX Konferenz für File und Storage Technologien (2007) veröffentlich worden.

Die Kernaussagen sind:

• Festplatten gehen viel schneller kaputt gehen, als anhand der Datenblätter zu erwarten wäre
• es gibt keinen relevanten Unterschied zwischen SCSI und SATA
• es gibt sehr wohl relevante Unterschiede zwischen den einzelnen Herstellern (aber die besseren Hersteller werden leider nicht genannt)
• wenn eine Platte mal die ersten Macken zeigt, ist sie ruck zuck ganz kaputt
• die meisten Platten gehen entweder im ersten Jahr (early failure period) oder nach fünf Jahren (wearout period) kaputt

Und mein Fazit: bei gespiegelten Platten ist der Datenverlust (meistens, Controllerfehler mal außen vor) zu vermeiden und Backups sollte man auch ab und zu machen.

Jetzt am Wochenende ist im Kulturzentrum Scheune das vierte Symposium Datenspuren des CCC Dresden. Wer Zeit hat soll hingehen. Der Eintritt ist frei.

Sehr zu empfehlen (weil sehr amüsant) ist der Vortrag „Biometrics in Science Fiction“ von Constanze Kurz. Und vorher am besten von Frank Rieger noch den Vortrag über Wahlcomputer anhören. Das öffnet Euch die Augen.

Hier ist der komplette Fahrplan.

Ja geht’s denn schon wieder los?

Die Month of the irgendwas Bugs scheinen langsam eine Institution zu werden. Alleine wenn wir schauen, was schon alles war:

• Month of Browser Bugs im Juli 2006
• Month of Kernel Bugs im November 2006
• Month of Apple Bugs im Januar 2007
• Month of PHP Bugs im März 2007

Und dann gibt es natürlich noch die Spaßvögel die auf den Zug aufspringen wollen: McAfee mit dem Month of Bug Bugs (Aprilscherz) und ein paar Spaßvögel mit dem Month of MySpace Bugs.

Und jetzt im Mai gibt es also den Month of ActiveX Bugs.

Bei ActiveX bin ich mir gar nicht sicher, ob da ein einzelner Monat reicht oder ob es ein Jahr der ActiveX Bugs braucht. HD Moore hatte letztes Jahr mit einem (inzwischen veröffentlichten) Fuzzer nach eigener Auskunft über 100 Fehler in ActiveX gefunden. ActiveX selbst gehört vermutlich zu den schlechtesten und unsichersten Techniken, die überhaupt für das Internet veröffentlicht wurden (ok, flashbasierte Homepages sind auch eine Seuche).

Alleine die Idee, dass lokal auf einem Rechner installierte Programme von einer Webseite aus ausgeführt werden dürfen und mit den Rechten des Benutzers ablaufen … da reicht ein billiger Buffer Overflow oder Format String Fehler und schon ist der Rechner unter der Kontrolle einer fremden Webseite. Natürlich kann man einzelne ActiveX Controls „Safe for Scripting“ erklären, oder eben nicht. Aber selbst die angeblich sicheren ActiveX Controls verursachen schon viele Probleme. Selbst wenn man sie nachträglich mit einem Kill Bit in der Windows Registry wieder deaktivieren kann.

Die Sicherheit einer Ausführung in einer Sandbox wie bei Java fehlt ActiveX. Ein böser Designfehler, der eigentlich nur durch die Hektik erklärt werden kann, mit der Microsoft diese Technologie gegen Java platzieren musste.

Am besten in meiner Ansicht nach daher, einen Browser zu verwenden der einfach gar kein ActiveX unterstützt.

Zertifizierungen gibt es wie Sand am Meer und der Deutsche Michel schwört auf jedes Stück Papier, das er sich an die Wand hängen kann. Besonders beliebt sind Herstellerzertifizierungen. Egal ob MCSE, Check Point CCSA/CCSE, Cisco CCNA/CCIE oder irgendeine andere Urkunde … so kann man zeigen, was man angeblich alles kann. An zweiter Stelle stehen dann die Zertifizierungen eines mehr oder weniger unabhängigen Instituts (klingt besser als Marketingklitsche, ist aber meist das gleiche). Da gibt es dann den Certified Ethical Hacker (CEH) von EC-Council, den OSSTMM Professional Security Expert (OPSE) von ISECOM und für die Leute mit mehr Geld (und meist noch weniger Wissen) so tolle Sachen wie CISSP, CISA und CISM.

Aber am besten sind die, für die es auch einen schönen Braindump gibt, den man auswendig lernen kann. Das hat den positiven Effekt, dass man das Zertifikat bekommt, ohne auch nur im geringsten was zu wissen oder verstanden zu haben.

Ich habe schon mit Kollegen gearbeitet die theoretisch alles hätten wissen müssen. Zumindest wenn man der langen Liste von Titeln auf der Visitenkarte hätte glauben wollen. Die Praxis sah leider genau umgekehrt aus. Die Kollegen bei denen auf der Visitenkarten nur der Namen und vielleicht noch „System Engineer“ stand, das waren meistens die, die am meisten drauf hatten. Und je größer das Unternehmen um so krasser die Erfahrung.

Ich vermute, das Problem hängt mit den Personalabteilungen der großen Unternehmen zusammen. Der Abteilungsleiter aus der Technik kann höchstens auf Basis der Papierunterlagen eine Vorauswahl treffen und hat da wenig andere Anhaltspunkte als die Zertifikate. Der Personalverantwortliche wiederum nimmt halt den, der im Gespräch am besten abschneidet. Und das sind öfter die Blender und seltener die Techniker. Aber gut, so haben kleinere Firmen mit einer klugen Mitarbeiterauswahl eine reelle Chance im Markt. Die großen Unternehmen kaufen für viel Geld die Blender weg und die richtig guten bekommt man manchmal für ’nen Appel und ein Ei.

Zumindest ist es bei uns im Unternehmen so. Wir sind nur ein paar Leute, aber jeder von uns kann leicht 3 oder 4 Pappnasen der großen Riesen in die Tasche stecken. Und wenn die nicht mehr weiter wissen, dann kommen sie ja doch immer wieder auf uns zu und fragen nach Unterstützung.