8. April 2007
Als Nachtrag zum Artikel „Mitternachtshacking The Art of Portscanning“ noch ein paar Gedanken zum Portscanning in IPv6 Netzwerken.
Das reine Portscanning, d.h. das Scannen einer einzelnen IP-Adresse nach allen offenen UDP- und TCP- Ports wird natürlich genauso funktionieren wie bisher auch. Problematisch wird es jedoch beim Scannen eines kompletten Netzwerks. Während ein typisches Subnetz bei IPv4 nur aus 8 Bit Hostadresse (256 Rechner) besteht, haben die bei IPv6 vergebenen Subnetze zur Zeit eine 64 Bit Hostadresse. Zum Vergleich, das gesamte(!) aktuelle Internet hat jetzt einen 32 Bit Adressraum. Während man ein IPv4 Subnetz lokal in weniger als 5 Minuten scannen kann (mit Scanrand sogar noch viel schneller) benötigt man für ein IPv6 Subnetz geschätzte 5 Milliarden Jahre. Da kommt es auf einen Faktor 1000 hin oder her nicht mehr an.
Es gibt ein paar Tricks, um den Adressraum zu reduzieren:
- Wenn die Administratoren Adressen manuell vergeben, ist sehr wahrscheinlich, dass an einem Ende des Adressbereichs angefangen wird, z.B. bei „[prefix]::1“ aufwärts. Insbesondere für Server mit festen IP-Adressen ist diese Vergabe von Adressen recht wahrscheinlich.
- Wenn das bei IPv6 eingeführte Stateless Autoconfiguring (RFC 2462) verwendet wird, leitet sich die IP-Adresse aus der Ethernet-Adresse der Netzwerkkarte ab. Wenn der Hersteller der Systeme bekannt ist oder vermutet werden kann, reduziert das den Suchraum deutlich.
- Wenn 6to4 konfiguriert ist, leitet sich die IPv6 Adresse aus der IPv4 Adresse ab. Die aktuelle 6to4 Implementierung von Microsoft verwendet „2002:v4addr::v4addr“, einige Linux und FreeBSD Implementierungen „2002:v4addr::1“. Allerdings kann man dann meistens auch gleich wieder nach IPv4-Adressen scannen.
Die Problematik betrifft nicht nur Angreifer sondern auch Administratoren die ihre eigenen Netze überprüfen möchten. Allerdings haben die meistens den Vorteil, ihre Infrastruktur und damit ihre Adressen zu kennen.
Der IETF-Draft „IPv6 Implications for TCP/UDP Port Scanning“ beschreibt die Problematik, mögliche Ansätze für optimiertes Scanning sowie weitere Schutzmaßnahmen für Systembetreiber sehr schön.
7. April 2007
Es zeigt sich immer wieder, dass die meisten Hacker erwischt werden, weil sie in Systeme einbrechen, die „vor ihrer Haustüre“ liegen. Zuletzt hat sich das wieder einmal bei Jerome Heckenkamp gezeigt, der in die Rechner der eigenen Universität eingebrochen ist und dadurch identifiziert werden konnte.
Mit den vorhandenen Tools und dem nötigen Wissen betrachtet man plötzlich alles als mögliches Angriffsziel. Der Wireless LAN Access Point des Nachbarn, der Server im Hotel, die öffentlichen Kioskrechner am Flughafen, in fast alle diese Systeme könnte man versucht sein einzudringen. Wer als Hacker jedoch in diese Systeme einbricht, erzeugt dadurch eine Signatur in etwas, das militärisch als „Information Battlespace“ bezeichnet wird.
Gute Hacker erkennt man auch daran, dass sie wissen wann sie ein System besser in Ruhe lassen. Oder wie es Dave Aitel formuliert hat:
„Good opsec requires that nothing connected to the hacker personally is
ever touched, no matter how tempting. You never own anything you would
care about. Don’t pee in your own pool.“
Alles klar?
Portscanning, obwohl es dafür Tools wie Sand am Meer gibt, ist manchmal erheblich schwieriger als sich das gewöhnliche Script Kiddies so denken. Insbesondere die Interpretation der Ergebnisse verlangt zumindest ein grundsätzliches Verständnis der Kommunikationsprotokolle TCP (RFC 793) und UDP (RFC 768). Warum lässt sich ein offener UDP-Port nur selten von einem durch eine Firewall blockierten Port unterscheiden? Wie (und warum) kann man anhand eines TCP-XMAS-Scan ein Microsoft Windows Betriebssystem von einem Linux Kernel 2.6.x unterscheiden?
The Art of Portscanning (PDF, 680 KB) von März 2005 war der zweite Vortrag aus der Mitternachtshacking-Reihe.
Die verschiedenen Arten von Portscans wurden erläutert und an Testrechnern praktisch ausprobiert. Besonders spannend finde ich immer wieder die Advanced Tools, insbesondere Scanrand von Dan Kaminsky. Damit kann man innerhalb von wenigen Sekunden ein komplettes Class A Netzwerk scannen und Sender und Empfänger der Pakete sogar auf verschiedenen Rechnern betreiben. Die ganze Paketto Keiretsu Suite ist eigentlich einen genaueren Blick wert.
6. April 2007
Die meisten Präsentationen der Black Hat Europe 2007 Sicherheitskonferenz sind inzwischen Online. Die Konferenz in Amsterdam ist relativ teuer (zumindest im Vergleich zum Chaos Communication Congress jedes Jahr im Dezember in Berlin) und daher war ich nicht live dabei. Andererseits ist der Vista-Bootkit-Hack von Nitin und Vipin Kumar auch schnell durch die Medien gegangen.
Viel spannender finde ich aber die Themen, die keine große Medienaufmerksamkeit geniessen. Beispielsweise ist Adam Laurie immer wieder für ein paar Lacher gut. Auf dem 22C3 hat er einen hervorragenden und sehr amüsanten Vortrag mit dem Titel „Old Skewl Hacking – InfraRed updated“ gehalten. Auf der Black Hat Europe 2007 hatte Laurie einen Vortrag mit dem Titel „RFIDIOts!!! – Practical RFID hacking“. Sehr lustig ist die vorletzte Seite der Präsentation mit der Reaktion der Firma ACG:
„Unfortunately your companies activities seem to be counter to ACG’s interests so we will not be able to support you any further.“
Manche Firmen scheinen immer noch nicht kapiert zur haben, wie das mit der IT-Sicherheit funktioniert. Abstreiten, blind und taub stellen ist leider keine Lösung.
Die weiteren wichtigen Themen sind immer noch Web-Application Security, mal wieder Oracle und natürlich dominiert Vista den Ring. Der Trend geht offensichtlich ganz klar zu immer weiter automatisierten Vulnerability Scannern, insbesondere Fuzzer sind groß dabei.
Und in SS7 werde ich mich demnächst mal ein wenig einlesen.
5. April 2007
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 Präsentation mit allen Screenshots der verwendeten Tools wird Anfang Mai nachgereicht. Die Teilnehmer der ArchITecture sollen durch ihren Besuch ja einen Wissensvorsprung bekommen 🙂 .
Im Jahr 2005 haben ein Kollege und ich eine Reihe von Vorträgen zu unterschiedlichen Hacking-Themen bei CBT Training & Consulting gehalten. Diese Präsentationen wurden zeitweise auf der alten Mitternachtshacking-Seite veröffentlicht. Nach dem Redesign und weil es diese Vorträge nicht mehr gibt, wurde Mitternachtshacking.de inzwischen zum privaten Blog. Die Präsentationen möchte ich trotzdem gerne wieder hier bereitstellen, allerdings aufgrund des neuen § 202c im StGB ohne Links auf die bzw. Download der verwendeten Hacking-Tools.
Hier ist daher das erste PDF vom Januar 2005: Mitternachtshacking Firewall Tunneling (500 KB)
An diesem Abend ging es um die verschiedenen Möglichkeiten, eine Firewall zu umgehen, in dem beliebiger Datenverkehr über HTTP, HTTPS, SSH, ICMP und DNS getunnelt wird. Eine ähnliche Anleitung findet der geneigte Leser auch bei Heise.de unter dem Titel „Schleichpfade„