Mitternachtshacking

Und ich habe gedacht, wenn Microsoft Word mal wieder abgestürzt ist, dass es sich vermutlich um einen kleinen Bug, einen Programmierfehler oder etwas ähnliches handelt.

Nein, das ist alles ganz anders. Microsoft „versucht“ laut eines Artikels bei Computerpartner.nl (engl.) IT-Sicherheit zu erreichen, in dem Office bei einem möglichen Fehler abstürzt, wenn es nicht genau weiß was richtig ist und was nicht.

David LeBlanc, einer der Code Gurus von Microsoft hat in seinem Blog einen netten Artikel dazu geschrieben. Es gibt eine SafeInt-Klasse, die unterschiedliche Exceptions werfen kann, darunter den Programmcrash. Die Theorie dahinter ist, dass es für das Betriebssystem möglicherweise sicherer ist, einen erfolgreichen Exploit zu verhinden, wenn die Anwendung einfach nur abstürzt. Die Praxis dahinter ist, dass es für den Anwender genauso unangenehm ist, wenn wichtige Daten verloren gehen, weil die Anwendung crashed.

Für Microsofts Secure Computing Werbecampagne Initiative ist es natürlich optisch besser, wenn der Anwender bei den vielen Programmierfehlern „nur“ Daten verliert und sich kein weiteres System einem Botnet anschließt. Für den kritischen Anwender zeigt das leider nur, dass „Secure Computing“ bei Microsoft mehr mit Marketing und PR und weniger mit realer IT-Sicherheit zu tun hat. OpenOffice irgendwer?

„Google ist das wichtigste Hacker-Tool!“ Diese Aussage hört man immer wieder, besonders wenn es um die Suche von Lücken in Webservern geht. Johnny Long hat auf seiner Webseite in der Google Hacking Database eine Vielzahl von sogenannten „Googledorks“ zusammengestellt. Damit sind Suchanfragen gemeint, mit denen man sensible Daten wie Passwörter, Vulnerabilities und anderes finden kann.

Wir haben dieses Thema im April 2006 aufgegriffen und einen Abend Mitternachtshacking zu typischen Sicherheitslücken auf Webanwendungen veranstaltet. Die Inhalte decken z.B. kostengünstig Shoppen in schlecht gemachten Webshops ab, Spamversand über E-Mail-Kontaktseiten von Firmen und natürlich, wie man all das möglichst einfach und bequem per Google finden kann.

Unsere eigene Präsentation (PDF, 1200 KB) und natürlich die Originalpräsentation von Johnny Long auf der Black Hat Europe Konferenz 2005 in Amsterdam sind sehr spannend anzusehen.

Ich reise zu viel. Und ich mag unpersönliche Riesenhotels nicht. Darum meide ich, wenn möglich, die ganzen Hotels der Accor-Gruppe, also Ibis, Mercure, Dorint Novotel und Sofitel. In diesen Häusern habe ich ganz subjektiv immer das Gefühl, zwar Kunde aber nicht Gast zu sein. Und für den Preis des Ibis bekommt man in der Regel auch ein nettes, kleines und sympathisches Hotel in dem oft auch das Frühstück besser ist (z.B. gibt es dann Rührei mit Speck).

Darum habe ich mal wieder in einem neuen Hotel übernachtet, dieses Mal im Hotel Europa in Münster. Und mit den City Partner Hotels war ich bisher meistens zufrieden.

Ich reise ja immer gerne sehr spät an, selten vor Mitternacht. Da freut es mich, wenn ein Hotel die Rezeption 24×7 besetzt hat, die Bar in der Nacht noch offen ist und es für die spät anreisenden Gäste sogar kostenlos eine leckere Mitternachtssuppe gibt. Das Frühstück war auch in Ordnung, für den Preis sogar sehr gut.

Für Reisende mit dringendem Internet-Bedarf ist das Hotel jedoch nicht zu empfehlen, da es wie so viele andere Hotels auf die frech überteuerten Hotspots der Telekom zurückgreift. Ich frage mich ja, was so schwer ist eine DSL-Flatrate zu bestellen, zwei Access Points im Haus zu montieren und den Internet-Zugang wie in Norwegen allen Gästen kostenfrei anzubieten.

So ein Hardware Security Modul zur Verwaltung der privaten Schlüssel hat schon was. Ich habe heute mal wieder so ein Modul in eine Sun eingebaut, Solaris installiert, gepatcht und gehärtet, HSM-Treiber installiert und konfiguriert. In diesem Fall ein nCipher nShield F3 500. Ich finde die Teile schon praktisch.

Auf einem Webserver gibt es beispielsweise immer das Problem, dass private Schlüssel irgendwo rumliegen, damit der Server nach dem nächsten Reboot auch ohne manuelle Eingabe wieder funktioniert. Wenn der private Schlüssel jedoch sicher in einem HSM gespeichert ist, aus dem er nicht herausgelesen werden kann, ist zumindest dieser Teil der Verschlüsselungsinfrastruktur bei einer Kompromittierung geschützt.

Das Einrichten in Verbindung mit einem RSA Certificate Manager war erfreulich einfach:

./enquiry
./nfkminfo
./new-world -i -o -S -m 1 -Q 1/2 r p
./createocs -m 1 -Q 1/2 -N OperatorCard -p –pp-recovery

Nur schade, dass die Module so teuer sind.

Beim Aufsetzen eines neuen DNS-Servers die Tage habe ich nebenbei bei Securityfocus nach bekannten Sicherheitslücken und Konfigurationsempfehlungen geschaut. Dabei bin ich über einen ganz anschaulichen Kommentar von Thomas Ptacek gestoßen, warum DNSSEC nicht zu gebrauchen ist.

Ich habe die DNSSEC-Diskussion dann ein wenig zurückverfolgt und bin auf folgende interessante Phising-Anleitung von D. J. Bernstein gestoßen:

1. Der Angreifer beschafft sich zwei IP-Adressen, z.B. 1.2.3.4 und 9.8.7.6. Er besorgt sich außerdem einen sprechenden Domainnamen, z.B. secure-banking.com.
2. Der Angreifer richtet einen DNS-Record für hugebank.secure-banking.com ein, der auf 1.2.3.4 verweist. Er beantragt bei Verisign ein Zertifikat im Namen von „HugeBank Secure Banking“. Er setzt einen SSL HTTP Server auf 1.2.3.4 auf, der genauso aussieht wie der von hugebank.com.
3. Der Angreifer richtet einen HTTP-Server auf 9.8.7.6 ein, der auf Anfragen nach hugebank.com antwortet und auf hugebank.secure-banking.com weiterleitet.
4. Hier kommt die Modifikation: Statt DNS-Anfragen zu fälschen wie im Original, schicken wir Phishing-Mails aus, mit dem Hinweis, sich mit hugebank.secure-banking.com zu verbinden. Alternativ können wir auch DNS-Anfragen an hugebank.com verfälschen, so dass auf die Adresse 9.8.7.6 verwiesen wird.
5. Das Opfer verbindet sich mit hugebank.secure-banking.com. Die Seite sieht aus, wie von Hugebank gewohnt. Der Browser zeigt eine sichere, verschlüsselte Verbindung zu hugebank.secure-banking.com an.
6. Ok, nun bin ich paranoid und prüfe das Zertifikat. Aber das Zertifikat ist gültig, von Verisign ausgestellt und sagt mir, dass hugebank.secure-banking.com tatsächlich „Hugebank Secure Banking“ gehört.

Sieht alles korrekt aus und ist gar nicht mal so abwegig. Die Raiffeisenbank verweist zum Beispiel für ihr Internetbanking auf die Seite finanzportal.fiducia.de …

Eigentlich also nichts neues. Nur, die Anleitung ist von 1999!

Im April erscheinen ein paar neue Bücher zur IT-Sicherheitsthematik, die folgenden sind mir dabei aufgefallen:

Handbuch Penetration Testing
von Marc Ruef
C & L Computer- u. Literaturverlag
ISBN-10: 3936546495
ISBN-13: 978-3936546491

Das Vorwort hat Max Moser geschrieben, könnte also interessant sein. Ich bin gespannt, wie Marc da den Schwerpunkt setzt. Zum Thema Hacking gibt es schon genug Bücher, das Hacking Exposed Standardwerk ist mir persönlich immer noch am liebsten. Zum Absichern der Systeme gibt es auch Bücher wie Sand am Meer und für die Penetrationstest-Methoden kann man auf OSSTMM oder die BSI Penteststudie verweisen. Mal sehen, was dann noch übrigbleibt.

Die Linux Security Box
Ralf Spenneberg
Addison Wesley
ISBN-13: 978-3827325211

Ralf kenne ich von ein paar Vorträgen, das ist jemand der Ahnung hat von dem was er schreibt. Und mit 1600 Seiten könnte das (wenn es gut ist) zum Referenzwerk werden. Ich hoffe, da ist auch was zu Xen mit dabei, weil die Xen-Virtualisierung in aktuellen Linux-Distributionen ist gerade der ganz große Hype. Und da kann man viel falsch machen.

Und dann ist für Juni noch eine Neuauflage angekündigt:

Hacken für Dummies
von Oliver Rochford
Wiley Verlag
ISBN-13: 978-3527703524

Ob man das Buch wirklich braucht, wage ich ja zu bezweifeln. Aber man trifft halt immer wieder so Leute, die man besser nicht an Computer ranlassen sollte. Für die ist auch der Untertitel „hier geht es nicht um Holz“ notwendig. Und genau die kommen dann immer mit: „kannst mir mal zeigen, wie das Hacken geht“. Ich glaube ich schenke das Buch meiner Freundin zum Geburtstag 🙂

In Hamburg fand bekanntlich vom 6. bis 9. April das vom Chaos Computer Club Hamburg organisierte Easterhegg 2007 statt. Leider sind es ja nun von München nach Hamburg ein paar Kilometer und die Referenten sind nicht ganz so hochkarätig wie auf dem Chaos Communication Congress in Berlin. Daher war an eine persönliche Anwesenheit nicht zu denken.

Andererseits lohnt es sich immer, einen Blick in den Fahrplan und sofern bereits Online auch in die Vorträge zu werfen. Besonders interessant finde ich den Vortrag zum Bluetooth-Hacking von Martin Kager. Die Präsentation zeigt zwar keine wirklich neuen Angriffe, bietet aber einen schönen Überblick des aktuellen Stands der Technik. Alle Tools und Angriffsszenarien sind übersichtlich zusammengefasst und bieten einen guten Einstieg in die Thematik.

Bei dieser Gelegenheit kann ich auch noch auf die Arbeit (PDF) von Max Moser hinweisen, der einen Weg gefunden hat, einen gewöhnlichen Bluetooth-Dongle mit CSR Chipsatz durch ein Firmware-Update in einen Bluetooth-Sniffer zu verwandeln. Interessant ist das insbesondere, weil günstige Bluetooth-Dongles schon für unter 20 € im Laden zu haben sind während für einen Bluetooth-Sniffer bisher rund 10.000 € fällig werden. Mal sehen, vielleicht gibt es demnächst auf der BackTrack 3.0 auch einen Linux-Bluetooth-Sniffer 🙂 .

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:

1. 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.
2. 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.
3. 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.

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.