7. April 2007
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
Ich bin gerade dabei, ein Seminar „IT-Sicherheit in der Produktion“ zusammenzustellen. Das Thema scheint im Gegensatz zu den USA in Europa generell noch nicht richtig angekommen zu sein. Während drüben das US Department of Homeland Security richtig aktiv ist und Unternehmen dazu nötigt Sicherheitskonzepte für ihre Produktionsanlagen zu erstellen und zertifizieren zu lassen, basiert hier bei uns noch alles auf freiwilliger Basis. Das einzig brauchbare Konzept das ich bisher finden konnte, ist vom Bundesamt für Sicherheit in der Informationstechnik und hat den Titel „Schutz kritischer Infrastrukturen in Deutschland„.
Den meisten Administratoren und IT-Sicherheitsbeauftragten ist nicht mal klar, warum man die normalen Sicherheitskonzepte hier einfach nicht anwenden kann. Darum wird das Seminar mit folgender Übersicht eingeleitet:
|
Unternehmens-IT |
Leittechnik |
| Hauptrisiko |
Verlust von Daten |
Schaden an Leib und Leben, Umweltschäden, Zerstörung von Produktionsanlagen |
| Risikomanagement |
Wiederherstellung durch Reboot;
Betriebssicherheit (safety) ist kein Schwerpunkt |
Fehlertoleranz überlebenswichtig;
Explizite Gefährdungsanalysen (oft sogar gesetzlich vorgeschrieben) |
| Ausfallsicherheit |
Gelegentliche Ausfälle tolerierbar;
Betatest im Betrieb akzeptabel (und bei Standard-Software oft üblich) |
Ausfälle nicht tolerierbar;
Umfassende Qualitätssicherung notwendig |
| Leistungsanforderungen |
Hoher Durchsatz (Bandbreite) vom Benutzer verlangt;
Verzögerungen und Schwankungen in der Qualität akzeptiert |
Bescheidene Durchsatzraten sind oft akzeptabel;
Zeitverzug ist bei Produktionsanlagen ein Sicherheitsrisiko |
| Sicherheit |
Viele Standorte physikalisch kaum gesichert (Besuchsverkehr, etc.);
Kaum Segmentierung interner Netzwerkbereiche;
Fokus liegt in der Absicherung zentraler Dienste und Server |
Hohe physische Sicherheit;
Unternehmensnetze von Produktionsnetzen oft streng getrennt (noch);
Fokus liegt in der Zugangskontrolle sowie Betriebssicherheit und Verfügbarkeit |
Ich bin ja mal gespannt, ob diese Übersicht dem einen oder anderen Teilnehmer die Unterschiede in den notwendigen Sicherheitskonzepten klar macht.
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„
