Mitternachtshacking

Ich muss mal ein paar Zeilen über Fuzzing schreiben. Wikipedia schreibt dazu nicht ganz zutreffend:

Fuzzing ist eine spezielle Technik für Software-Tests. Hierfür werden automatisch mit Tools zufällige Daten erzeugt, die über Eingabeschnittstellen eines Programms verarbeitet werden.

Das ist so nicht ganz richtig. Fuzzer sind nicht auf Dateien beschränkt, es gibt natürlich auch Fuzzer für Netzwerkdienste, die beispielsweise durch fehlerhafte oder zufällig erzeugte Datenpakete zum Absturz gebracht werden können. Fuzzer wurden lange Zeitlang kaum beachtet, haben jedoch u.a. durch die Arbeit von HD Moore eine Renaissance erlebt. Auf der Webseite des Month of the Browser Bug sind einige Fuzzer, u.a. AxMan, Hamachi, CSS-die, DOM-Hanoi und MangleMe verlinkt. Insbesondere der ActiveX-Fuzzer AxMan hat sich als sehr wirkungsvoll erwiesen, vermutlich weil die meisten ActiveX-Controls nur auf Funktionalität und nicht in Hinblick auf Sicherheit entwickelt wurde. ActiveX von Microsoft gehört meines Erachtens generell zu den Technologien, die besser nicht entwickelt worden wären.

Das beliebteste Ziel von Fuzzern sind weiterhin offensichtlich Browser, hier gibt es auch die größte Auswahl wie die Seite von HD Moore beweist. Sehr spannend finde ich auch SIP-Fuzzer, mit denen man beispielsweise Telefonanlagen und IP-Telefone sehr gut angreifen kann. Als Fuzzer gegen Webserver gibt es beispielsweise den Spike Proxy oder Wapiti, und kommerzielle Produkte wie beStorm sind natürlich auch nicht weit.

Aus Deutschland gibt es jetzt auch einen Browser-Fuzzer:

JdM (Jacques de Molay, ein großer Name) hat einen neuen Browser-Fuzzer aufgelegt, den BrowserCrashTest Ride the Monkey, aktuell in der Version 0.2 und komplett im Source Code unter der GPL freigegeben. Der Fuzzer ist in Visual Basic programmiert und lässt sich daher nur unter Windows kompilieren. Ich persönlich würde ja eine leichter portierbare Software z.B. in Java bevorzugen. Dafür integriert er Funktionen wie DLL-Injection von iDefense und kann damit recht mächtige Funktionen ausführen. Insgesamt jedoch durchaus ein interessantes Tool.

Ob es ökonomisch Sinn macht, sich mit Browsern zu beschäftigen wage ich jetzt mal zu bezweifeln. Bei Browsern gibt es nur wenige Anbieter (Microsoft IE, Mozilla Firefox, Opera, Konqueror, Safari und ein paar Nischenprodukte), wenn man da Lücken im Browser findet ist das für das Ego sicher gut, lässt sich aber kaum in klingende Münze umwandeln. Viel interessanter finde ich Fuzzer für Dienste oder Protokolle die neu und in vielen Unternehmen eingesetzt werden. Und da stößt man unweigerlich auf Dienste wie VoIP (SIP, SCCP, H.323) mit vielen verschiedenen Telefon- und Anlagenanbietern und immer wieder VPN (IKE, IPSEC, PPTP, HTTPS), das inzwischen überall verbreitet ist. Ich denke, angefangen mit diesen Protokollen ließe sich leicht auch ein kommerziell erfolgreicher Fuzzer entwickeln.

Die Finnen sind da schon auf dem richtigen Weg.

TheRegister bezeichnet es als Worms 2.0, aber eigentlich steckt viel mehr dahinter:

Wade Alcorn von NGSSoftware hat einen Bericht (PDF) veröffentlicht, wie JavaScript innerhalb des Browsers verwendet werden kann, um Metasploit-ähnliche Angriffe durchzuführen.

In der Praxis bedeutet das, ein harmloser User mit aktiviertem JavaScript braucht nur auf eine Schadwebseite surfen und schon wird im Browser ein Angriff gegen einen anderen Dienst (mit einem anderen Protokoll, daher Interprotocol Exploitation) ausgeführt. Das spannende dabei, der Angriff erfolgt vom PC des Users aus, d.h. bereits hinter der Firewall. Man kann sich leicht ausmalen, was das bedeutet.

Viele Firmen verzichten darauf, Patches schnell in internen Netzen auszurollen, da immer wieder Funktionsprobleme auftauchen. Da viele Angriffe von außen passieren und sich Mitarbeiter meistens (aber nicht immer) zurückhalten, ist das eine angemessene Strategie für das Risikomanagement. Bisher. Komplexe Sachen wie SSH-Handshake dürften lt. Alcorn schwierig werden, IMAP Brute Force beispielsweise oder einfache Exploits die nur ein paar Pakete benötigen dürften einfach zu programmieren sein.

Mal sehen, wann das erste echte Framework veröffentlicht wird.

Die Telekom (bzw. T-Online) hat ihren Kunden da einen ADSL-WLAN-Router Speedport W 700V angedreht, der per Browser aus dem Internet konfigurierbar ist. So etwas ist bekanntlich keine besonders gute Idee. Dieses Konfigurationsinterface lässt sich leider auch nicht abschalten und wenn die Anwender schlechte Passwörter verwenden oder sogar das Standardpasswort („0000“) lassen, kann man z.B. die Zugangsdaten klauen oder anderen Unsinn anstellen. Das Gerät wird von Arcadyan, einem Joint Venture von Accton und Philips hergestellt. Verbockt haben das beide:

1. Arcadyan hat, es musste wohl billig sein, schlicht ein paar Konfigurationsoptionen oder eine brauchbare ACL-Implementierung weggelassen. (Vielleicht wollten sie auch nur nicht von Harald Welte verklagt werden.)
2. T-Online hat das eigentlich übliche Due Dilligence beim Abschluss eines solchen Liefervertrags grob vernachlässigt, bereits bei einfachen Tests der Geräte hätte so etwas auffallen müssen.

Nun gut, jetzt gibt es ein Firmware-Update auf 1.16, das dieses Problem löst. Das laden die Router sogar automatisch (ich hoffe das hat T-Online vorher auch getestet), es dauert nur eine ganze Weile bis das auf allen Geräten drauf ist. Nicht jeder ist schließlich rund um die Uhr online.

Und da ist T-Online auf die geniale Idee gekommen, einfach komplett für alle User, vermutlich auf allen Routern, den TCP-Port 8085 zu sperren. Den Port verwendet normalerweise eh keiner. Herausgekommen ist das, weil eine Bank für ihr Online-Banking zufällig genau diesen Port nutzt, lt. IANA ist der Port „unassigned“. Im Prinzip ist das nichts neues. Das Leibniz Rechenzentrum der Münchner Hochschulen macht so ettwas auch, da nennt sich das Sicherheitspaket D und sperrt von außen den Zugriff auf bestimmte Microsoft-Ports.

Nur, das LRZ kommuniziert mit den angeschlossenen Instituten. Da weiß jeder Bescheid. T-Online sperrt einfach und gibt niemandem Bescheid. Auch wenn eine solche Maßnahme im Sinne der meisten Kunden ist, halte ich es für absolut inakzeptabel, dass solche Sperren nicht öffentlich bekanntgegeben werden. Für jeden sonstigen Werbekäse verschickt T-Online ja auch eine E-Mail.

Ach ja, die Kollateralschäden: World of Warcraft braucht in vielen privaten Server-Installationen die Ports 3724, 8080 und 8085. Sipgate bietet über Port 8085 anscheinend eine Abfrage des Onlinestatus und Sun Java will den Port auch für irgendwas verwenden. Dumm gelaufen.

Andererseits könnte das auch eine clevere Geschäftsidee sein:

• Internet-Zugang Basisanschluss (nur Port 80 HTTP): 19,90 Euro
• Aufpreis Mailabruf per POP3: 4,95 Euro
• Aufpreis WoW Ports: 4,95 Euro

Da kann man richtig was verdienen. Beim Mailversand mit eigenen Mailadressen kassiert T-Online ja schon länger. Das war übrigens einer der Hauptgründe, warum ich nicht mehr bei T-Online bin. Da bleibt es dem Verbraucher unbelassen, mit den Füßen abzustimmen. Aber das passiert eh schon.

Ist das eigentlich noch mit Netzneutralität vereinbar?

Anmerkung: Der SpeedPort W701V von AVM ist davon übrigens nicht betroffen.

Theo de Raadt, genialer aber selten diplomatischer Chefentwickler von OpenBSD hat offensichtlich einen neuen Lieblingsgegner ausgemacht: die Intel Core 2 CPUs. In einer Mail an die OpenBSD-Liste beschreibt er die Entwicklerprobleme mit der Intel-CPU.

These processors are buggy as hell, and some of these bugs don’t just cause development/debugging problems, but will *ASSUREDLY* be exploitable from userland code.

Eine coole Vorstellung … Sicherheitslücken, die zu Root-Exploits führen können treten nicht mehr nur im Betriebssystemcode auf sondern inzwischen vermehrt auch in Prozessoren. Und wenn es sich um richtig fiese Fehler handelt, ist unter Umständen gar kein funktionierender Workaround möglich. Der berüchtigte Pentium-FDIV-Bug ist harmlos dagegen.

Im einzelnen führt Theo de Raadt folgende Fehler auf:

• AI56: Update of Read/Write (R/W) or User/Supervisor (U/S) or Present (P) Bits without TLB Shootdown May Cause Unexpected Processor Behavior
• AI79: REP Store Instructions in a Specific Situation may cause the Processor to Hang
• AI43: Concurrent Multi-processor Writes to Non-dirty Page May Result in Unpredictable Behavior
• AI39: Cache Data Access Request from One Core Hitting a Modified Line in the L1 Data Cache of the Other Core May Cause Unpredictable System Behavior
• AI90: Page Access Bit May be Set Prior to Signaling a Code Segment Limit Fault
• AI99: Updating Code Page Directory Attributes without TLB Invalidation May Result in Improper Handling of Code #PF

Theo de Raadt schreibt dazu:

„We bet there are many more errata not yet announced — every month this file gets larger. Intel understates the impact of these erraata very significantly. Almost all operating systems will run into these bugs.Basically the MMU simply does not operate as specified/implimented in previous generations of x86 hardware. It is not just buggy, but Intel has gone further and defined „new ways to handle page tables“ (see page 58).Some of these bugs are along the lines of „buffer overflow“; where a write-protect or non-execute bit for a page table entry is ignored. Others are floating point instruction non-coherencies, or memory corruptions — outside of the range of permitted writing for the process — running common instruction sequences.All of this is just unbelievable to many of us.“

Oder anders ausgedrückt: Wir werden in Zukunft vermutlich eine komplett neue Klasse von Exploits sehen, die sich gar nicht auf ein Betriebssystem ausrichten sondern auf die darunterliegende CPU. Sehr spannend, das werde ich mal im Auge behalten.

Zum Nachschlagen: die komplette Liste der Intel Core 2 Fehler

Gerade bei der Recherche für den nächsten Beitrag gefunden:

You got owned by IMC

Sehr nett 🙂

Heise hat es gestern Abend nochmal zusammengefasst, ich mache das daher auch mal:

1. Lücke: Fehler in PHPMailer mit Remote Code Execution in Verbindung mit Sendmail

2. Lücke: SQL-Injection in xmlrpc.php, benötigte jedoch einen gültigen Account

3. Lücke: File Upload Problem, anscheinend nur teilweise behoben, benötigt jedoch ebenfalls einen gültigen Account

4. Lücke: Cross Site Scripting im Default Theme von WordPress

Also für meine Installation keine Schwachstellen mit hohem Risiko. Es gibt nur ein paar Benutzer mit Accounts, die sind alle persönlich bekannt und Sendmail kommt auch nicht zum Einsatz.

Bisher kann ich mit WordPress gut leben. Bisher. Ich hoffe, das bleibt so.

Ach ja, die Exploits bitte nicht gegen dieses Blog ausprobieren, ich bin längst auf 2.2.1 🙂

Ein weiteres Thema der Mitternachtsreihe war WEP-Cracking. Darum folgt hier auch die Präsentation zum Mitternachtshacking WEP Un-Security (PDF; 1,0 MB). Die Angriffe wurden alle mit der BackTrack 2.0 CD-ROM durchgeführt, daher stammen auch die Screenshots in der Präsentation.

WEP, Wired Equivalent Privacy, ist die veraltete Verschlüsselungstechnik in Wireless LANs. Bereits kurz nach der Veröffentlichung wurden erste Schwächen in WEP aufgezeigt, die dazu führten, dass durch das Mitsniffen ausreichend vieler Pakete der statische Teil des Verschlüsselungskeys rekonstruiert werden kann. Während Anfangs noch mehrere Millionen Pakete und schwache Initialisierungsvektoren (IVs) notwendig waren, wurden die Angriffe im Laufe der Zeit verfeinert, so genügen inzwischen wenige hunderttausend Pakete und schwache IVs die von vielen Access Points gefiltert werden, sind gar nicht mehr notwendig.

Die Präsentation zeigt eine übliche Angriffsfolge. Dabei wird zuerst die SSID ermittelt, die von vielen Netzwerken nicht mehr in Broadcast-Frames übertragen wird. Anschließend wird, sofern nötig, die MAC-Adresse angepasst, um MAC-Filter zu umgehen. Danach findet eine Paketinjektion von ARP-Paketen statt. Dadurch werden innerhalb von wenigen Minuten die nötigen Pakete erzeugt, die zum Cracken des Keys notwendig sind. Das eigentliche Cracken des WEP-Keys erfolgt zum Abschluss, danach steht das WEP-geschützte WLAN offen.

Die FON-Nutzer beschweren sich über Wireless LAN Probezugänge, die anonym 15 Minuten genutzt werden können. Für die Registrierung ist nicht einmal eine gültige E-Mail Adresse notwendig und die Authentisierung basiert alleine auf der MAC-Adresse.

Ok, den Rechtsverdrehern ist klar, die Risiken eines solchen Konstrukts sind in Deutschland nicht kalkulierbar. Das Abmahnunwesen und die ausufernde Mitstörerhaftung (das es so übrigens in keinem anderen Land der Welt gibt) führen dazu, dass jeder vernünftig denkende Mensch solche Dienste am besten komplett abschaltet.

Und den Hackern ist natürlich klar, die MAC-Adresse aller modernen Netzwerkkarten lässt sich sowohl unter Windows als auch Unix beliebig verändern. So wird aus dem 15 Minuten Zugang schnell ein kostenfreier dauerhafter internationaler WLAN-Zugang. Sehr praktisch eigentlich.

Ich frage mich ja, wie die Haftung von Hotels aussieht, die ihren Kunden einen kostenfreien Wireless LAN Zugang anbieten. Kommentare irgendwer?

Die russische Firma Elcomsoft, bekannt geworden durch diverse Key Recovery Programme und die cleveren Hacks in Adobes eBook hat eine Hintertür in der weit verbreiteten Finanzsoftware Quicken von Intuit gefunden. Laut Mitteilung von Elcomsoft und diversen Berichten (und ich glaube denen, die Leben davon) gibt es die Hintertür seit 2003, als Intuit angefangen hat, Dateien mit starker Verschlüsselung zu sichern um gleichzeitig einen Passwort Recovery Service anzubieten.

Da fallen mir doch gleich mehrere Sachen auf:

1. Sichere Verschlüsselung in Kombination mit Password Recovery Service sollte einen stutzig machen. Entweder die Verschlüsselung ist sicher, dann kann aber keiner mehr herankommen, oder eben nicht. Und nur dann ist Password Recovery Service überhaupt realistisch. Wenn die Verschlüsselung tatsächlich mit einem starken, standardisierten Algorithmus erfolgt, z.B. AES-128, muss eine Hintertür vorhanden sein, anders ist ein Password Recovery innerhalb von 10 Minuten wie von Intuit versprochen gar nicht möglich.

2. Password Recovery wird von Intuit seit 2003 angeboten. Vernünftig denkenden Menschen sollte daher auch seit 2003 klar sein, dass die Quicken Software eine Hintertür haben muss. Aber erst jetzt 2007 kommt Elcomsoft mit der nötigen Software zum Ausnutzen der Hintertür. Entweder haben die Jungs aus Russland so lange gebraucht, um die Hintertür zu finden (was ich nicht glaube) oder auch erst vor ein paar Monaten angefangen zu suchen. Warum hat eigentlich sonst niemand seit 2003 darauf hingewiesen?

3. Die Hintertür ist laut Elcomsoft mit einem 512-Bit RSA Schlüssel geschützt. Also bitte, wer ist den so blöd, 2003 noch einen 512-Bit RSA Schlüssel zu verwenden? 512-Bit RSA Schlüssel wurden schon 1999 erfolgreich faktorisiert (d.h. in ihre Primfaktoren zerlegt, woraus sich dann problemlos der zugehörigen private Schlüssel ermitteln lässt). Das mindeste, was man für eine solche Hintertür hätte erwarten können ist ein sicherer Schutz durch ausreichend lange und starke Schlüssel. 1024 Bit hätte ich noch akzeptiert, lieber aber 2048 Bit.

Ich bin ja mal gespannt, wie Intuit darauf reagiert …

Anmerkung: 2001 wurde Dmitry Sklyarov auf der Def Con Hackerkonferenz nach seinem Vortrag über die Schwächen in Adobes eBook Software verhaftet und mit einer Anklage gegen den DMCA belegt. Sklyarov wurde im Dezember 2001 unter der Voraussetzung wieder freigelassen, gegen seinen Arbeitgeber auszusagen. Im Dezember 2002 wurde Elcomsoft von allen Anklagepunkten freigesprochen.

Das US Department of Defense musste also 1500 Computer stillegen, weil das Mailsytem von Hackern angegriffen wurde. Weitere Details: Fehlanzeige.

Soso