Mitternachtshacking

Auf meinem Server hier ist Logging ja weitgehend abgeschaltet (zumindest das Access-Log, nicht jedoch das Error-Log). Das hat den Vorteil, Daten die nicht vorhanden sind, muss (und kann) man im Zweifel nicht rausrücken. Der Apache schreibt die Logfiles standardmäßig sowieso nur in eine Datei und die kann man auch gut auf /dev/null verlinken. Dann ist das Log so zuverlässig weg wie die Daten auf einem Windows Home Server.

Manche machen das ja ein wenig anders. Der TÜV Rheinland zum Beispiel. Für den sind die Logfiles offensichtlich so wichtig, dass er sie direkt in eine SQL-Datenbank schreibt. Nicht ganz sauber programmiert zwar, aber das fällt meistens eh nicht nicht auf. Dieser Link (aus dem 24C3 Hacks-Wiki) zeigt das Problem auf. Als PHPSESSIONID einfach „‚UNION‘„übergeben und schon kackt das Logging ab. Ein wundervolles Beispiel für SQL-Injection. Wenn man sich den Sourcecode der Webseite direkt anschaut sieht man ganz unten das Problem:

„You have an error in your SQL syntax near ‚UNION“)‘ at line 1<br>INSERT INTO accesslog (mandantid, mapid, sprachid, arbeitsbezeichnung, userip, userhost, useragent, referer, zeit, session)VALUES (1, 26, 1, ‚Impressum‘, ‚xx.xx.xx.xx‘, ‚dslb-xxx-xxx-xxx-xxx.pools.arcor-ip.net‘, ‚Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11‘, ‚http://events.ccc.de/congress/2007/Hacks‘, ‚2008-01-06 23:04:33‘, “UNION“)<br>“

Das muss nicht nur die PHPSESSIONID sein, das kann jeder andere Parameter auch sein. SQL-Injection durch einen modifizierten User-Agent beispielsweise 🙂

Der TÜV Rheinland offeriert seinen Kunden übrigens auch Penetrationstests und Software Entwicklung an. Ich würde mich ja schämen, meine eigenen Seiten nicht im Griff zu haben. Und noch peinlicher, das Problem ist mindestens seit einer Woche auf dem Wiki veröffentlicht. Kuckt denn beim TÜV Rheinland niemand in irgendwelche Logfiles?

Aber keine Sorge: wir bieten gerne jedem einen Sonderpreis auf unsere eigenen Penetrationstests an, der vorher den TÜV Rheinland beauftragt hatte und sich nun nicht mehr ganz sicher fühlt. Einfach eine Mail an mich mit dem Hinweis „TÜV Rheinland“ und es gibt 10% auf alle Leistungen 😉

Ich habe neulich bei der Durchsicht des neuen Telepolis-Hefts schon Prof. Beyerer vom Fraunhofer IITB kritisiert, der glaubt alles wäre gut, sicher und toll und bemängelt, es gäbe generell von Fraunhofer praktisch keine relevanten und brauchbaren Veröffentlichungen zur IT-Sicherheit in kritischen Infrastrukturen.

Jetzt durfte sich Prof. Beyerer bei Spiegel Online (der Link fliegt wieder raus, sobald der Artikel Geld kostet!) auslassen:

„Der Informatiker Jürgen Beyerer plädiert dafür, so manche Ergebnisse geheim zu halten.“

Ich nehme an, er meint da insbesondere seine eigenen. Die sind so gut, so toll und so fortschrittlich, die müssen geheimgehalten werden weil wenn die Bösen(TM) seine Forschung in die Finger bekommen würden, dann würde natürlich die Welt untergehen.

Und dann seine Kernaussage:

„Sicherlich muss man für Sicherheitsforschung an besonders sensiblen Themen, deren Ergebnisse man einer breiten Öffentlichkeit nicht im Detail zugänglich machen möchte, Kontrollmechanismen festlegen, die wissenschaftliche Qualität und prinzipiell gesellschaftliche Akzeptanz sichern. Die Beteiligten bei der Sicherheitsforschung für kritische Infrastrukturen – Wissenschaftler, Betreiber kritischer Infrastrukturen, Bedarfsträger, Fördermittelgeber, öffentliche Auftraggeber und Politik – bilden auch selbst schon eine recht große Community, in der meines Erachtens sehr verantwortungsbewusst auch kritische Fragen, insbesondere Fragen der gesellschaftlichen Akzeptanz, diskutiert werden. Man sollte daher die Kontrollmechanismen innerhalb dieser Community nicht unterschätzen und auch darauf vertrauen.“

Den Absatz sagt eigentlich alles über das Verständnis von Prof. Beyerer aus. Der Staat soll seine Arbeit finanzieren (das sind die öffentlichen Auftraggeber, also der Steuerzahler) und ein möglichst kleines Konsortium kontrolliert die Geldvergabe (an sich selbst) und die Veröffentlichung der Ergebnisse. Unternehmen aus der freien Wirtschaft kommen in seinem staatlich gelenkten Weltbild schon gar nicht mehr vor. So wird jedem Dritten die Möglichkeit genommen, die Verwendung der Gelder zu kontrollieren aber dafür ist die Welt von Hr. Beyerer ein wenig sicherer.

Ich hoffe die Haltung von Prof. Beyerer ist nicht repräsentativ für die gesamte Fraunhofer Gesellschaft.

Reverse Engineering ist eine der nützlichsten Techniken um zu verstehen, wie Programme in ihrem Inneren funktionieren. Im Allgemeinen ist Reverse Engineering daher in den Lizenzbedingungen untersagt. In den USA gibt es jedoch die Ausnahem des „fair use“, in Europa sind dafür die „Shrink Wrap Licenses“, die man vor der Installation der Software gar nicht zu Gesicht bekommt zumindest umstritten, wenn nicht gar automatisch unwirksam.

Eine Reihe von Dokumenten im Internet beschäftigen sich mit Reverse Engineering und ein paar Link über die ich in den letzten Tagen gestolpert bin, möchte ich hier kurz aufführen:

The Ethical Hacker Network

• Intro to Reverse Engineering – No Assembly Required
• Intro to Reverse Engineering – Part 2

Wikibooks

• Reverse Engineering

Communities

• Reverse Code Engineering Community

Sonstige Quellen

• Reverse Engineering Hostile Code
• Reverse Engineering Malware
• Reverse Engineering Links

Weitere Links, sobald ich noch was interessantes finde oder in den Kommentaren …

Schon einige Zeit online aber bisher übersehen, die aktuelle neue SANS Top 20 ist online.

Client-side Vulnerabilities in:

• C1. Web Browsers
• C2. Office Software
• C3. Email Clients
• C4. Media Players

Server-side Vulnerabilities in:

• S1. Web Applications
• S2. Windows Services
• S3. Unix and Mac OS Services
• S4. Backup Software
• S5. Anti-virus Software
• S6. Management Servers
• S7. Database Software

Security Policy and Personnel:

• H1. Excessive User Rights and Unauthorized Devices
• H2. Phishing/Spear Phishing
• H3. Unencrypted Laptops and Removable Media

Application Abuse:

• A1. Instant Messaging
• A2. Peer-to-Peer Programs

Network Devices:

• N1. VoIP Servers and Phones

Zero Day Attacks:

• Z1. Zero Day Attacks

Webbrowser und Webapplikationen ganz oben sind natürlich kein Wunder. Office hat die zweite Stelle bei Client-side Vulnerabilities gewonnen, aber mein Eindruck ist eher, die Angreifer ziehen bereits weiter (z.B. Quicktime). Neu ist der Punkt H3, unverschlüsselte Laptops und Datenträger. Mal sehen, ob das bei Ernst & Young jemand zur Kenntnis nimmt.

Nein, es geht diesmal nicht um Kollisionen, da schreibe ich ein andermal was dazu.

Steven Murdochs (muss man nicht kennen) Webseite ist gehackt worden und der Angreifer hat einen Account mit einem Passwort hinterlassen. Das Passwort war leider nur als MD5-Hash gespeichert und Steven kam nicht hinter das richtige Passwort. Also hat er den Hash bei Google eingegeben und mit ein wenig kucken, was da angezeigt wird kam er tatsächlich auf das richtige Passwort. So weit so langweilig.

Ich nutze die Gelegenheit nur, auf zwei Sachen hinzuweisen:

1. Salted Passwords!

2. MD5 Online Cracker (Rainbow Tables)

• http://md5.rednoize.com/
• http://passcracking.com/index.php
• http://md5.cryptobitch.de/
• http://www.hashserver.com/
• http://www.md5oogle.com/
• http://md5.noisette.ch/
• http://us.md5.crysm.net/

Ach ja, der Hash war „20f1aeb7819d7858684c898d1e98c1bb“ und das Passwort „Anthony“.

bei Technology Review. Für 6,80 Euro. Muss ich mal im Bahnhofskiosk durchblättern, ob sich das lohnt.

Nachtrag (Sonntag, 25.11.07, 17:04)

Es lohnt sich nicht. Ich habe mir das Heft vorhin am Flughafen angeschaut. Es liegt da interessanterweise nicht bei den Computerzeitschriften, darum habe ich es anfangs nicht gefunden sondern bei Wirtschaft, direkt neben dem Manager Magazin.

Eine Doppelseite wird verwendet, um in einer tollen Infografik zu erklären wie unser Trinkwasser aufbereitet wird, eine zweite Doppelseite liefert dann ein wenig Text dazu und wie einfach Terroristen doch unser Trinkwasser vergiften könnten. Im Grunde ein Aufwasch des Vortrags „How safe is a glass of water„, 2003 auf der Brum2600 Konferenz in Birmingham.

Eine dritte Doppelseite braucht es für ein Bild der Norwegian Pearl und einen Bericht, warum in Europa der Strom ausgefallen ist, als bei Papenburg eine Leitung von Eon abgeschaltet wurde. Kernaussage hier, die Stromkonzerne investieren viel zu wenig in ihre Infrastruktur, also eigentlich auch nichts neues.

Auf einer weiteren Doppelseite darf sich Prof. Beyerer vom Fraunhofer IITB darüber auslassen, wie toll sie doch bei Fraunhofer sind und alles super im Griff haben. Nur komisch, dass ich von denen (egal ob IITB, IPK oder IFF) praktisch noch keine relevante Veröffentlichung zur Sicherheit in der Prozessautomation gesehen habe. Ich habe ja den Verdacht, dass die von den vielen Fördergeldern hauptsächlich heiße Luft produzieren.

Und schließlich kommt noch Bruce Schneier zu Wort, der zur ganzen Thematik einen kurzen Kommentar abgeben darf.

Meiner Meinung nach investiert man da sein Geld lieber in die KES 2006#1, da gibt es einen guten Artikel zur Sicherheit in Leittechnik von Stefan Kubik und von mir. Falls es das Heft nicht mehr gibt, wir haben einen Nachdruck unseres Artikels, einfach eine kurze Mail an mich, dann schicke ich eine Kopie zu.

Am Freitag hat Kollege Matthias wieder eine Hacking-Show … Hacking VoIP auf der CBT Security Tagung in Garmisch-Partenkirchen.

Beim Update der Tools und allgemein so beim Herumschauen was es noch so alles gibt, ist mir SIPvicious aufgefallen, das mir bisher nicht auf dem Radar aufgetaucht ist.

SIPvicious besteht aus vier Hauptprogrammen:

• svmap, der SIP-Scanner. Er findet und identifiziert SIP-Geräte und SIP-Server und kann SIP-Methoden wie REGISTER oder INVITE verwenden, um die Geräte zu aktivieren.
• svwar, ein SIP-Wardialer. Damit lassen sich interessante und aktive Rufnummern auffinden.
• svcrack, ein SIP-Cracker. Damit lässt sich die SIP Digest Authentication brechen. svcrack verwendet dazu eine Reihe von Wörterbüchern mit gängigen Passwörtern.
• svreport, das Reporting-Tool. Mit diesem Programm lassen sich die Aufrufe der anderen Tools verwalten und fast automatisch Berichte als PDF, XML, CVS und TXT erzeugen.

Alle Programme sind in Python geschrieben, d.h. sie kommen auch komplett im Source Code.

Zu den Tools gibt es ein Blog, das über aktuelle Entwicklungen informiert und Aufrufe dokumentiert, mit denen relevante Informationen gefunden werden können. Sehr lesenswert ist das PDF „How to get the job done„, das beschreibt wie mit Hilfe von SIPvicious und der SIP-Telefonanlage erfolgreich in ein Netzwerk eindringt.

Ein echtes „must see“!

Langsam fängt mir dieses lustige „Ethical“ auf den Senkel zu gehen … gerade aus dem angelsächsischen Raum schwemmt es da lauter so Unsinn herüber.

Certfied Ethical Hacker zum Beispiel. Ich hab so ein Zertifikat. Ich glaube, das darf ich sogar auf meine Visitenkarte drucken. Mach ich natürlich nicht, wäre mir peinlich. Ich weiß auch gar nicht, worauf sich das Zertifikat nun bezieht … bin ich jetzt zertifizierter Hacker der (hoffentlich) ethisch ist oder zertifiziert ethisch und (hoffentlich) Hacker? Und wie zertifiziert man ethisch? Beichten musste ich jedenfalls nicht.

Oder mein CISSP. Der Certified Information Systems Security Professional. Da muss man auch angeben, dass man keinen kriminellen Hintergrund hat sondern sich immer ethisch verhalten hat. Nach US-Recht oder nach russischem Recht?
Und jetzt gibt es bei den Briten ganz neu CREST, das Council of Registered Ethical Security Testers. Das sind vermutlich die, die sich vor lauter Ethik gar nicht mehr trauen, Hackingtools aus dem Internet herunterzuladen. Die Mitgliederliste ist jedenfalls bezeichnend: KPMG, Ernst & Young (genau, das sind die mit den verlorenen Notebooks), Insight (Siemens), Symantec und Co. Die einzigen relevanten Pentester die ich da finde sind NTA Monitor (von denen ist z.B. ike-scan) und vielleicht noch NGS Software (mit David Lichtfield, der die ganzen Oracle Bugs findet).

Ich persönlich glaube ja mehr an das 11. Gebot: „Lass Dich nicht erwischen“. Andererseits … mit so einem Dachverband könnte man vielleicht bessere Lobby-Arbeit gegen den StGB 202c und ähnliche Schwachsinnsgesetze unserer Bummelregierung machen. Von der Bitkom kann man ja leider nichts brauchbares erwarten, solange der Laden von Branchengrößen wie Microsoft und SAP dominiert wird, die natürlich gegen Hackertools sind, weil besonders die eigenen Produkte angegriffen werden.

Naja, solange es nicht den Dachverband der ethischen Windows-Administratoren („Viren ausrotten? Das geht nicht,  auch diese Geschöpfe von Gottes Gnaden haben ein Recht zu leben!“) oder den Dachverband der ethischen Mac-Anbeter („Unser täglich iTunes gib uns heute“) gibt muss ich wohl noch damit leben.

Die Raiffeisenbank wird mal wieder Opfer einer Spam-Phishing-Attacke:

Die Titelzeile gefällt mir: „eBanking Private Edition“. Die Angreifer sind auch recht ausführlich bei den Daten, die sie abfragen:

• Herr/Frau
• Vorname
• Familienname
• 10 unbenutzte TAN-Nummern
• Kontonummer
• VR-NetKey
• Alias
• PIN
• Bankleitzahl
• Postleitzahl
• E-mail

Ein wenig gierig sind sie dann natürlich schon:

„Geben Sie 10 unbenutzte TAN-Nummern ein. Wenn Sie weniger als 10 unbenutzte TAN-Nummern haben, so geben Sie alle unbenutzten TAN-Nummern ein“

Die Raiffeisenbank (zumindest meine) ist bezüglich Online-Banking offensichtlich keine besonders gute Wahl:

Problem 1: Die URL des Bankings ist für die Kunden kaum verifizierbar. Jede Raiffeisenbank hat ihre eigene Homepage, die Banking-Startseite liegt auf vr-networld.de, Teile des Internetbankings wiederum beim Dienstleister fiducia.de … wie soll der unbedarfte Bankkunde da erkennen, dass vr-networld.de.hrymn.cn in China liegt?

Problem 2: Die Raiffeisenbank hat neulich erst zur Anmeldung von der Kontonummer (die oft allgemein bekannt ist, z.B. wenn sie auf dem Briefpapier steht) zu einem VR-Netkey, einer davon unabhängigen UserID gewechselt. Vorher konnte man mit der Kontonummer und dreimal falscher PIN problemlos Denial-of-Service Angriffe durchführen.

Problem 3: iTAN, mTAN, TAN-Generator, egal was nur sicherer als die normale TAN ist immer noch komplett Fehlanzeige. Meine Bank konnte mir nicht einmal sagen, bis wann die Einführung von iTAN geplant ist.

Naja, die Deutsche Bank hat das Problem ja bereits per AGB auf die Kunden abgewälzt. Mal sehen, wie das bei der Raiffeisenbank weitergehen soll.

Es gibt viele Sicherheitslücken für die keine öffentlichen Exploits verfügbar sind und scheinbar auch nicht mehr entwickelt werden. Ein Beispiel ist eine der aktuellen Sicherheitslücken in Apple Quicktime. Hier gibt es auf SecurityFocus eine Meldung „Apple QuickTime Panorama Sample Atoms Remote Heap Buffer Overflow Vulnerability“ mit der Bugtraq-ID 26342 und wenn man nach dem Exploit schauen möchte erhält man die Meldung:

„Currently we are not aware of any exploits for this issue. If you feel we are in error or if you are aware of more recent information, please mail us at: vuldb@securityfocus.com.“

Klingt gut. Die Risikobewertung sieht dann vielleicht so aus:

Das Problem mit dieser Risikobewertung ist der zeitliche Verlauf. Aufgrund der Einstufung einer Schwachstelle als „normal“ unterbleibt gerade bei Systemen in einer Produktionsanlage oft das Testen und Installieren eines Patches. Gerne auch mal für einige Jahre. Wenn dann sehr viel später ein Exploit programmiert wird, springt das Risiko von „normal“ auf „hoch“, es gibt jedoch niemanden mehr, der diese Schwachstelle und das zugehörige Exploitpotential beobachtet.

Ein sehr schönes Beispiel ist gerade auf SecurityFocus zu finden. Die Schwachstelle „Sun Solaris RWall Daemon Syslog Format String Vulnerability“ mit der BID 4639 ist schon etwas älter, genau genommen 2002 von Gobbles (kann sich eigentlich noch jemand an den Gobbles-Krieg gegen Theo de Raad und den Apache-scalp.c chunked encoding Bug Exploit erinnern?) entdeckt worden und hat lange keine größere Rolle gespielt.

Jetzt steht diese uralte Lücke plötzlich ganz weit oben mit dem Vermerk „Updated: Nov 08 2007 12:05 AM“ und auf der Exploit-Seite findet man den Hinweis:

„UPDATE: Core Security Technologies has developed a working commercial exploit for its CORE IMPACT product. This exploit is not otherwise publicly available or known to be circulating in the wild.“

Den gleichen Vermerk findet man in mehreren Einträgen, vermutlich Folge eines neuen Releases von Core Impact. Betroffen sind mindestens die BID 3681, 4639 und 1480.

Beobachtet eigentlich noch irgendwer die alten ungepatchten Lücken über die man vor vier oder fünf Jahren mal lange diskutiert hatte?