Mitternachtshacking

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.

C:\>nslookup

> set type=NS
> arcor.de

Server: dns1.meinprovider.de
Address: 1xx.7.30.125

Nicht autorisierte Antwort:
arcor.de nameserver = ns2.arcor-ip.de
arcor.de nameserver = ns3.arcor-ip.de
arcor.de nameserver = ns1.arcor-ip.de

ns3.arcor-ip.de internet address = 145.253.3.171
ns2.arcor-ip.de internet address = 145.253.2.80
ns1.arcor-ip.de internet address = 145.253.2.19
> server ns1.arcor-ip.de
Standardserver: ns1.arcor-ip.de
Address: 145.253.2.19

> ls -d arcor.de > arcor-zone.txt
[ns1.arcor-ip.de]
#
Erhalten 388 Eintrags.
>

Sehr schön, man kann sich auf einen Schlag die komplette Arcor-Zone ziehen. Das betrifft übrigens gerade alle Arcor-Kunden, deren Secondary DNS-Server auf einem der drei Arcor-Nameserver gespeichert ist.

Seagate/Maxtor hat in Taiwan ein paar mobile 500 GB Festplatten ausgeliefert, die mit zwei Trojanern (autorun.inf und ghost.pif) infiziert waren. Ich finde die Idee ja cool, darauf bin ich nicht mal bei meinen Virenideen gekommen.

„The tainted portable hard disc uploads any information saved on the computer automatically and without the owner’s knowledge to www.nice8.org and www.we168.org, the bureau said.“

Die Taiwanesen verdächtigen jetzt die Chinesen der Spionage. Angeblich werden solche großen Platten hauptsächlich von Regierungsbehörden verwendet. Mehr in der Teipei Times.

(via Fefe)

… zumindest wenn man sich an Salesforce wendet. Da hat ein Mitarbeiter doch tatsächlich eine Kundendatenbank rausgegeben.

„Salesforce management said it has been re-educating its staff to the dangers of phishing.“

Das kursive finde ich jetzt nett. Awareness ist halt alles.

Aber meine Rede ist ja schon die ganze Zeit, man gibt keine solchen Daten extern. Egal ob es sich um ein Blog oder sonstige Daten handelt. Ich könnte wetten, auch in den Salesforce-AGB steht drin, dass die Daten eh Salesforce gehört haben und Kunden halt Pech hatten.

Ein Amerikanischer Security Consultant (alles Verbrecher, alleine wer sich schon als „Security Consultant“ bezeichnet … wo ist mein Bullshit Bingo?), John Kenneth Schiefer (kennt den irgendwer?) ist mit einem Botnetz von 250.000 Rechnern erwischt worden. Er hat damit Identitäten gestohlen und Bankdaten ausgespäht.

Ich frage mich ja ab und an, wo der Nutzen dabei liegt. Bankdaten schön und gut, aber irgendwann muss man auch irgendwie das Geld cash auf die Tatze bekommen. Die vielen Phisher haben ja das gleiche Problem. PINs und TANs ausspähen scheint recht einfach zu sein. Irgendwelche Idioten zu finden, die das Geld auf ihrem Privatkonto entgegennehmen und dann mit Western Union nach Estland verschicken ist offensichtlich schwieriger. Und auf das eigene Konto überweisen lassen ist leider auch keine Lösung. Das Geld ist schneller wieder weg als man es ausgeben kann.

Und wie groß war der Gewinn? Er zahlt 19.128,35 USD zurück, die Summe die er mit Affiliate-Gebühren eingenommen hat. Ich vermute mal, ein brauchbarer Security Consultant kann das mit (halbwegs) ehrlicher Arbeit in einem Monat verdienen. Erinnert sich noch jemand an Andreas von Zitzewitz, den ehemaligen Vorstand von Infineon der sich bei einem Millionengehalt mit müden 300.000 Euro mutmaßlich hat bestechen lassen und dann zurücktreten musste? Ich denke, jeder ist käuflich oder würde für genug Geld kriminell werden. Aber dann muss die Summe auch stimmen. Ein schlappes Monatsgehalt wäre mir da zu wenig.

Mehr bei The Register.

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?

Es gibt mehrere Möglichkeiten, einen Benutzer einer Webseite zu authentisieren. Die klassischen beiden Methoden sind:

• HTTP Basic/Digest Authentication
• Form-based Authentication mit Cookies

Die meisten Webseiten verwenden heute formularbasierte Authentisierung, d.h. irgendwo in der Webseite ein Eingabeformular für Login und Passwort, das an ein Programm auf dem Webserver geschickt wird der die Eingabe überprüft und bei korrekter Anmeldung ein Session-Cookie zurückgibt, das als Nachweis der erfolgreichen Anmeldung fungiert. Praktisch alle Seiten die ich kenne und auch alle Freemailer, egal ob z.B. web.de, GMX, Hotmail, etc. und alle Banken arbeiten so. Das hat mehrere Gründe:

1. Das Formular lässt sich beliebig im Design der Webseite unterbringen während das HTTP Authentication Popup durch den Browser dargestellt wird und sich nicht im Corporate Design darstellen lässt.
2. Die formularbasierte Authentisierung wird von einem serverseitigen Programm angenommen, das die Benutzer z.B. gegen eine SQL-Datenbank verifizieren lässt. Eine große Anzahl von Benutzern lässt sich so einfach verwalten.
3. Die formularbasierte Authentisierung unterstützt problemlos auch Einmalpasswörter, Token (z.B. RSA SecurID) und Zertifikate. Die HTTP Basic/Digest Authentisierung wird meistens direkt vom Webserver durchgeführt und verwendet einfache Passwort-Dateien (ja, es gibt z.B. für den Apache Module die starke Authentisierung ermöglichen aber dann wird es schnell beliebig kompliziert).
4. Das HTTP Basic/Digest Authentication Passwort wird vom Browser ohne eine Lebenszeit gespeichert während sich einem Cookie trivial eine Lebenszeit und damit eine Gültigkeitsdauer mitgeben lässt.

Wenn auf einer Webseite dann doch noch HTTP Basic/Digest Authentisierung verwendet wird ist das folglich ein Grund, einmal genauer nachzuschauen. Als Beispiel verwende ich hier eine Seite des CCC, das Paper Submission System für den 24C3 Kongress auf Pentabarf.org, viele andere Seiten leiden aber unter dem gleichen Problem.

Die Anmeldung auf der Seite nach Anlegen eines Benutzers und eines Passworts erfolgt über das Popup-Fenster des Webbrowsers: „Geben Sie Benutzernamen und Passwort für Pentabarf ein“. Das Fenster selbst wird durch den Browser erzeugt, hier wird offensichtlich HTTP Basic/Digest Authentisierung verwendet:

Firefox bietet mir hier an, das Passwort im Passwort-Manager zu speichern aber das will ich normalerweise lieber nicht haben. Nach der Anmeldung kann man dann seinen Vortrag für den 24C3 eintragen.

Ich will ja eigentlich schon seit geraumer Zeit mal was erzählen aber bisher habe ich weder ein ausreichend spannendes Thema noch genug Zeit gefunden, einen ansprechenden Vortrag vorzubereiten. Naja, vielleicht 2008 😉

Die Seite bietet in der linken Spalte einen Menüpunkt „Logout“. Das ist interessant, weil es keine triviale Methode gibt, das im Browser gespeicherte Passwort zu löschen. Mal sehen, was passiert:

Hier fangen die Probleme an. Da es keine einfache Möglichkeit gibt, den Browser das Passwort vergessen zu lassen, versucht die Seite hier einen etwas unsauberen Trick. Die einzige Möglichkeit, einen Browser das Passwort einer Domain vergessen zu lassen ist, den Browser für die gleiche Domain eine neue Login/Passwort-Kombination speichern zu lassen. Dafür richtet man üblicherweise eine spezielle Seite ein, für die z.B. die Kombination logout/<kein Passwort> gültig ist. Der Nutzer klickt auf den Logout-Link, das alte Passwort ist ungültig und wenn der Nutzer bestätigt, wird die gespeicherte Login/Passwort-Kombination im Browser überschrieben.

Leider kann man dabei ein paar Sachen falsch machen:

Wenn der Anwender oben auf „nein“ bzw. „cancel“ klickt, übernimmt der Browser die neuen Anmeldedaten nicht, das alte Login/Passwort bleibt weiterhin gültig.

Die Logout-URL verwendet „logout@cccv.pentabarf.org“, Benutzername in einer URL wird jedoch vom Internet Explorer seit dem kumulativen Sicherheitsupdate für den Internet Explorer (832894) vom 2. Februar 2004 nicht mehr unterstützt. Da gab es leider zu viele Phishing-Versuche und ahnungslose Nutzer sind reihenweise auf URLs wie www.postbank.de@xyz.hk reingefallen und haben ihre PINs und TANs eingegeben. Das Verfahren funktioniert mit dem Internet Explorer so folglich gar nicht.

Mein Firefox (2.0.0.9) ist davon auch nicht beeindruckt, er scheint sich das alte Passwort und das neue Passwort auch gleich zu merken. Jedenfalls komme ich mit der „Back“-Taste oder einem Relogin ohne Eingabe des Passworts wieder auf die Inhalte:

In meinem Firefox kann ich via Extras -> Private Daten löschen (Strg+Umschalt+Entf) alle gespeicherten Daten löschen, dann sind die Passwörter auch weg. Auf meinem Arbeitsplatzrechner ist mir das eigentlich auch egal, da kommt niemand außer mir hin. Im Internet Café muss man leider dran denken, die Passwörter niemals in den Passwort-Manager zu übernehmen und den Browser nach dem Zugriff auf so eine Seite immer schließen, damit die gespeicherten Daten verloren gehen.

Das ist jetzt sicher keine gefährliche Lücke aber mit den aufkommenden Cross Site Request Forgeries (CSRF) sollte man auf solche Probleme vermehrt achten. Ach ja, ich schätze die Schwachstelle nicht so kritisch ein, dass ich sie vorher hätte melden müssen.

Ein nettes Gedankenspiel neulich während eines Workshops:

Aufgabe: Programme bzw. Schadcode unter Mithilfe eines internen Mitarbeiters an allen Sicherheitsvorkehrungen vorbeizuschleusen.

Problem: Nur E-Mail ist erlaubt, ein Virenscanner aktiv, Attachments außer PDF verboten. USB-Sticks und CD-ROM-Laufwerke sind abgeschaltet. Der Helfer im LAN hat nur den Acrobat Reader und Winzip zur Verfügung.

Meine Idee lässt sich wie folgt skizzieren:

1. Man nehme ein nützliches Executable, z.B. nmap.exe
2. Dieses Binary kodiert man mittels mimencode als Base64-File (-> nmap.b64)
3. Das Base64-File lädt man in einen Texteditor, z.B. Word (-> nmap.doc)
4. Aus dem Word-Dokument erzeugt man ein PDF (-> nmap.pdf)

Das PDF enthält jetzt reinen Text, kein embedded Executable oder sonstwas, notfalls kann man auch noch ein paar Leerzeilen manuell einfügen, um den Text zu maskieren. Kein mir bekannter Virenscanner schlägt an.

Das zurückkonvertieren ist ebenfalls recht einfach:

1. Das PDF mit dem Acrobat Reader öffnen und „Datei -> als Text speichern“ (-> nmap.txt)
2. Das daraus resultierende Textfile in file.b64 umbenennen
3. Das Base64-File mit Winzip öffnen, wenn die Verknüpfungen passen mit Doppelklick
4. Das darin befindliche File Unknown.001 extrahieren
5. Das File Unknown.001 wieder in nmap.exe umbenennen

Das konvertieren in ein PDF ist etwas komplizierter, ich hab bisher auch kein mimencode für Windows gefunden. Das zurückkonvertieren ist jedoch so einfach, das kann ich sogar meiner Freundin einer Kollegin erklären.

Fertig 🙂

Die verschieden konvertierten Nmap-Versionen enthält dieses Zip-File, so kann das jeder selbst nachvollziehen. Ich habe mimencode verwendet, weil das Base64-Format im Gegensatz zum Beispiel zu uuencode keinen Header benötigt. Allerdings unterstützt nicht jedes Zip-Programm Base64.

Edit: Mist, meine Freundin liest mein Blog.

Video von Frank Rosengart vom CCC:

SIPVicious hat ein paar coole Tools zum VoIP-Hacken veröffentlicht:

• svmap – this is a sip scanner. Lists SIP devices found on an IP range
• svwar – identifies active extensions on a PBX
• svcrack – an online password cracker for SIP PBX
• svreport – manages sessions and exports reports to various formats

und ein PDF „How to get the job done„.

(via Security4All)