Mitternachtshacking

… 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, daß 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 muß 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 offensichtlichs 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 mußte? Ich denke, jeder ist käuflich oder würde für genug Geld kriminell werden. Aber dann muß die Summe auch stimmen. Ein schlappes Monatsgehalt wäre mir da zu wenig.

Mehr bei The Register.

Vor einigen Tagen hat der schwedische Sicherheitsexperte Dan Egerstad in seinem Blog eine Liste von Passwörtern einiger ausländischer Botschaften veröffentlicht. Hier ein kleiner Ausschnitt:

Uzbekistan Foreign Affairs 57.66.151.179 Qohira 5gx7n1e4w9
Iran Embassy in Ghana 217.172.99.19 iranemb_accra@mfa.gov.ir accra
Iran Embassy in Kenya 217.172.99.19 iranemb_kenya@mfa.gov.ir kenya
Iran Embassy in Oman 217.172.99.19 iranemb_muscat@mfa.gov.ir muscat
Iran Embassy in Tunisia 217.172.99.19 iranemb_tunisia@mfa.gov.ir tunisia
Iran Ministry of Foreign Affairs 217.172.99.19 bagheripour@mfa.gov.ir amir1368
Kazakhstan Embassy in Italy 213.21.159.23 kazakstan.emb@agora.it rfywkth
Kazakhstan Embassy in Egypt 213.131.64.229 kazaemb piramid

Die vollständige Liste findet sich in Dans Blog. Ich will jetzt nicht über die Qualität der uzbekischen Passwörter und die tollen iranischen Passwörter reden, das ist dann doch ein wenig langweilig.

Irgendeine wichtige US-Behörde hat die Seite dann ein paar Tage aus dem Netz nehmen lassen, aber natürlich viel zu spät. Die Passwort-Liste hatten ich und viele andere natürlich längst gespeichert. Wenn der Geist erstmal aus der Flasche und im Internet ist, läßt er sich kaum noch wieder einfangen. Das ist wie mit dem geheimen Virtual Earth Bildern.

Interessant ist eigentlich die Art und Weise, wie Dan an die Passwörter gekommen ist. Er hat fünf Exit-Nodes des Anonymisierungsnetzwerks Tor modifiziert und einen Passwort-Sniffer für POP3 und IMAP integriert. Tor bietet halt nur anonymen Zugriff auf einen Client, aber keinen Schutz der übermittelten Daten. Das Problem ist, eigentlich ist das jedem bewußt, aber so richtig Gedanken macht sich keiner darüber.

Egerstad vermutetn außerdem, daß einige der Exit-Nodes von staatlichen Behörden, beispielsweise aus den USA, Russland oder China betrieben werden und so gezielt eine große Menge von Daten abgefischt wird. Wichtige Daten sollte man deshalb nur verschlüsselt, per SSL oder HTTPS übertragen.

Der komplette Blog-Eintrag und Heise hat es auch schon gemerkt.

Ach ja, bevor ihr jetzt alle einen Tor Exit-Node aufsetzt: StGB § 202b sagt dazu, wer unbefugt sich oder einem anderen unter Anwendung von technischen Mitteln nicht für ihn bestimmte Daten (§ 202a Abs. 2) aus einer nichtöffentlichen Datenübermittlung oder aus der elektromagnetischen Abstrahlung einer Datenverarbeitungsanlage verschafft, wird mit Freiheitsstrafe bis zu zwei Jahren oder mit Geldstrafe bestraft, wenn die Tat nicht in anderen Vorschriften mit schwererer Strafe bedroht ist.

Also 1. Hacker-Gebot nicht vergessen: Laß Dich nicht erwischen!

F-Secure pusht mal wieder die Idee einer Toplevel-Domain .bank die nur für Banken zur Verfügung stehen soll. Auf den ersten Blick klingt das gar nicht so schlecht und F-Secure sucht wohl auch gerade einen Sponsor, der das Thema bei ICANN weitertreiben soll. Auf den zweiten Blick wird das ingesamt nicht viel bringen.

1. Die Leute klicken sowieso auf alles was sich bewegt, selbst wenn extra dabei steht, daß man sich damit seinen Rechner infiziert
2. Die Phisher basteln sich auch weiterhin lustige URLs wie www.postbank.bank.secure.hk und die Leute fallen auch weiterhin drauf rein
3. Weil es immer wieder Lücken im Browser gibt, mit denen z.B. durch JavaScript falsche URLs in der Kopfzeile angezeigt werden können
4. Weil sogar die Default-Einstellungen von Firefox nichts taugen

Das einzige, was eine solche Toplevel-Domain bringt ist, daß sich die Hersteller von Virenscannern und Personal Firewalls leichter tun. Wenn es nach .bank geht ist es ok, braucht man schon mal nicht mehr kontrollieren. Und irgendwann ist einfach alles andere suspekt und fertig.

Hey F-Secure, macht Eure Hausaufgaben

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 daß 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,daß 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!