Auf Youtube gibt es auch ein Video das zeigt, wie schnell der Kurs ins bodenlose sackte:

Ursache des Kurssturzes war, dass ein Account auf einen Schlag 500.000 Bitcoins verkauft hat. Das Handelsvolumen war so gewaltig, dass innerhalb weniger Sekunden sämtliche existierenden Kauforder erfüllt wurden. Zeitgleich wurden von diesem Account mit dem so erzielten Gewinn beim Kurs von 0.01$ wieder massiv Bitcoins zurück gekauft und anschließend versucht, die Bitcoins auf ein anderes Konto zu überweisen. Dies schlug allerdings dann fehl, da Mt. Gox maximal 1000$ pro Tag und Account an Transaktionen erlaubt (bzw. Bitcoins im entsprechenden Gegenwert). Der oder die Täter hat also maximal 1000$ mitgehen lassen. Die komplette Erklärung des Vorganges findet man bei Mt. Gox.

Dort spricht man davon, dass ein Account kompromittiert wurde, was sich zwischenzeitlich aber als absolute Fehleinschätzung herausgestellt hat. Die komplette Accountdatenbank von Mt. Gox ist nämlich inzwischen als CSV-Datei auf Rapidshare und anderen Filehostern aufgetaucht. Im Bitcoin-Forum war für kurze Zeit ein Beitrag zu finden, der auf die Downloads verlinkte. Und es handelt sich tatsächlich um die Account-Datenbank. Glücklicherweise war man dort etwas schlauer als bspw. Sony und speicherte die Passwörter nicht im Klartext in der DB, es sind salted MD5-Hashes. Dennoch ein gewaltiger Gau für Mt. Gox, zumal sich so etwas bereits ankündigte.

Spekuliert wird aktuell, woher die 500.000 Bitcoins kommen, ob sie echt waren oder nur in der Datenbank vorhanden. Mt. Gox will nun einen kompletten Rollback durchführen, wird aber sicher auf den 1000$ sowie auf einem enormen Imageverlust sitzen bleiben. Und natürlich hört man auch jetzt schon genügend Stimmen die davon sprechen, dass das wohl das Ende der Bitcoins sei. Nur muss man hier ganz klar sehen: Mt. Gox ist nichts weiter als ein Handelsplatz für Bitcoins, Mt. Gox ist nicht Bitcoin. Handelsplätze gibt es weitaus mehr (bspw. Bitcoin Market, Bitcoin7 oder TradeHill), so wie es überall auf der Welt Börsen gibt. Allerdings wird der Hack dennoch das Vertrauen in den Bitcoin für die nächste Zeit schwächen, auch weil die Berichterstattung in den nächsten Tagen sicherlich genau in diese Kerbe schlagen wird. Interessanterweise spricht aber niemand vom Ende des Dollars oder Euros, nachdem bei der Citibank 360.000 Kundenkonten gehackt wurden.

Bitcoins wurden erst in den letzten Wochen wirklich attraktiv und bekannt, nachdem alle Welt davon berichtete. Plötzlich wurden die Mining-Pools größer, plötzlich stieg das Handelsvolumen an den Handelsplätzen und natürlich auch der Wert der Bitcoins. Aus einer “Währung für Nerds” wurde plötzlich etwas, was viele interessierte. Insofern müssen die Nerds, die Handelsplätze und dergleichen aus purem Spaß aus dem Boden gestampft haben, nun auch wesentlich professioneller werden und agieren. Das ist das, was wir aus dem heutigen Vorfall bei Mt.Gox lernen sollten.

Update: Inzwischen habe ich auch eine Mail von Mt.Gox erhalten, hier der Inhalt:

Dear Mt.Gox user,

Our database has been compromised, including your email. We are working on a quick resolution and to begin with, your password has been disabled as a security measure (and you will need to reset it to login again on Mt.Gox).

If you were using the same password on Mt.Gox and other places (email, etc), you should change this password as soon as possible.

For more details, please see this:

https://support.mtgox.com/entries/20208066-huge-bitcoin-sell-off-due-to-a-compromised-account-rollback

The informations there will be updated as our investigation progresses.

Please accept our apologies for the troubles caused, and be certain we will do everything we can to keep the funds entrusted with us as secure as possible.

The leaked data includes the following:

- Account number
- Account login
- Email address
- Encrypted password

While the password is encrypted, it is possible to bruteforce most passwords with time, and it is likely bad people are working on this right now.

Any unauthorized access done to any account you own (email, mtgox, etc) should be reported to the appropriate authorities in your country.

Thanks,
The Mt.Gox team

Zumindest reagiert man relativ zeitnah und kehrt nichts unter den Teppich.

Update 2: Inzwischen tauchen offenbar die ersten Spuren des Angreifers auf. Im Forum von InsidePro (einer Password Recovery Software) stellte ein User “georgeclooney” schon seit Anfang Mai dem 16.6. stapelweise MD5-Hashes ein und bat um Unterstützung beim knacken. Fast alle von mir stichprobenartig geprüften Hashes aus seinen Listen finden sich auch in der CSV-Datei, die veröffentlicht wurde. Und dabei musste ich feststellen, dass offenbar nicht alle Passwörter als salted Hash gespeichert wurden, sondern auch jede Menge Standard-MD5 Hashes enthalten sind. Mehrere Hashes wurden im InsidePro-Forum auch geknackt und die zugehörigen Passwörter wurden geposted. Es ist also ziemlich sicher, dass der Angreifer wesentlich mehr als nur ein Konto bei Mt. Gox kompromittieren konnte.

Update 3: Die Accountdaten von Mt. Gox wurden bereits am Samstag bei Pastebin zum Verkauf angeboten:

I have hacked into mtgox database. Got a huge number of logins password combos.Mtgox has fixed the problem now. Too late, cause I’ve already got the data.
Will sell the database for the right price.Send your offers to：gfc06@hotmail.com

Laut DailyTech wird der Angreifer in Hong Kong vermutet, zumindest verwies seine IP-Adresse dorthin. Auch scheinen diverse Bitcoin-Diebstähle (auch bei Mt. Gox) mit dem Vorfall in Zusammenhang zu stehen.

Update 4: Die oben bereits verlinkte Erklärung von Mt. Gox wurde inzwischen mehrfach aktualisiert und dort findet sich auch eine Erläuterung dafür, dass viele Passwörter nur als MD5-Hash gespeichert waren:

Two months ago we migrated from MD5 hashing to freeBSD MD5 salted hashing. The unsalted user accounts in the wild are ones that haven’t been accessed in over 2 months and are considered idle. Once we are back up we will have implemented SHA-512 multi-iteration salted hashing and all users will be required to update to a new strong password.

Darüber hinaus arbeite man mit Google zusammen, Googlemail-Accounts, die mit Mt.Gox-Konten verbunden waren, wurden zurückgesetzt und die Inhaber dieser Mailaccounts müssen ihr Konto neu verifizieren. Die ersten User berichten bereits von zurückgesetzten Passwörtern in ihren Googlemail-Konten.
Inzwischen wurden auch die ersten Mails an die Adressen aus dem Account-Dump versendet. Inhalt:

A few hours ago the Bitcoin trading website Mt Gox has been hacked. Malicious individuals have been able to obtain a database containing usernames, email address and encrypted passwords. This information has been posted publicly on the internet.

As a Bitcoin supporter I’m now sending a message to every email address contained in the hacked database. This is to warn you that your username, email address and password have been leaked. I therefore strongly advice you to change your passwords. If you have used the same password on different websites it’s highly recommended to change your password on all of your accounts!

For a more secure alternative to Mt Gox, the community appears to be moving to TradeHill. So this is no reason to lose faith in Bitcoin itself. It must be seen as a warning that not every website can be trusted with your data however! Their link is http://www.tradehill.com/?r=xxxxxx (Note: You can remove the Referral Code when registering if you want!) This is certainly not the only website where you can exchange Bitcoins, also check out http://www.thebitcoinlist.com/dp_bitcoin/bitcoin-exchange/

Es ist sicherlich nur eine Frage der Zeit, bis Mails mit Links zu irgendwelchen obskuren Tools oder speziellen Attachments bei diesen Adressen landen.
Korrektur: Diese Mails sind bereits im Umlauf:

Dear Mt.Gox user,

Our database has been compromised, how you already know.

To protect your account in the future, please download  the Certificate (self-extracting archive) from Attachment and install it.

If you were using the same password on Mt.Gox and other places (email, mybitcoin.com, etc), you should change this password as soon as possible.

Please accept our apologies for the troubles caused, and be certain we will do everything we can to keep the funds entrusted with us as secure as possible.

Any unauthorized access done to any account you own (email, mtgox, etc) should be reported to the appropriate authorities in your country.

Thanks,
The Mt.Gox team

Es ist hoffentlich überflüssig zu erwähnen, dass man dieses Attachment NICHT herunterladen oder gar installieren sollte…

Update 5: Mt.Gox hatte bereits eine kurze Information dazu verfasst, wie der Angreifer an die Accountdaten gelangt ist, ich hatte aber vergessen, das zu erwähnen. Hole ich hiermit nach:

It appears that someone who performs audits on our system and had read-only access to our database had their computer compromised. This allowed for someone to pull our database.

Man beruft sich also darauf, dass ein direkter Zugriff auf die Datenbank für den Angreifer nicht möglich war, sondern der Rechner einer Person, die einen Audit durchführte, mit Malware infiziert war. Und auf diesem Wege konnte der Angreifer auf die Datenbank zugreifen. Klingt schon nach ein paar komischen Zufällen wenn ich ehrlich sein soll, aber OK.  Warten wir mal ab,welche Informationen noch bekannt werden.

Insgesamt gut 50.000 mal sollen die 21 Apps bis dahin installiert gewesen sein. Kurze Zeit später wurden über 30 weitere Apps gemeldet, meine Stichproben zeigen, dass diese inzwischen ebenfalls nicht mehr im Market verfügbar sind. Ob die Installationen per Kill-Switch von den Geräten entfernt werden, ist im Moment noch unbekannt.

Die komplette Liste der gefundenen Apps gibt es übrigens bei Android Police, die die Malware entdeckt und an Google gemeldet haben. In diesem Zusammenhang macht plötzlich auch die Übernahme von Zynamics durch Google mehr Sinn, die Bochumer sind auf Reverse Engineering zu Analysezwecken von Binär- und Bytecode spezialisiert.

Die Aussage allerdings, mit der der der BSI-Mensch Jens Bender auf die Kritik und Hinweise reagiert ist schon ein wenig amüsant:

“Er räumte ein, wenn ein Benutzer “den großen Fehler” mache, den elektronischen Personalausweis länger als nötig in einem Lesegerät zu lassen, könne sich ein Angreifer im Besitz der PIN tatsächlich für ihn ausgeben, zum Beispiel bei Altersverifizierungsdiensten.”

Erinnert mich an vergleichbare Fehleinschätzungen, die ich früher recht häufig gehört habe:
“Wenn man ihn beim Sex schnell genug raus zieht, dann kann nichts passieren.”

Dass sicheres Verhüten anderes geht, hat sich inzwischen allerdings herum gesprochen.

“In that blog post, and in a technical note sent to data protection authorities the same day, we said that while Google did collect publicly broadcast SSID information (the WiFi network name) and MAC addresses (the unique number given to a device like a WiFi router) using Street View cars, we did not collect payload data (information sent over the network). But it’s now clear that we have been mistakenly collecting samples of payload data from open (i.e. non-password-protected) WiFi networks, even though we never used that data in any Google products.”

Nun, Google gesteht also ein, Fragmente der Nutzdaten von offenen WLANS, anders als zuvor angegeben, ebenfalls gespeichert zu haben. Mit anderen Worten: Wenn Google beim Scannen der WLANs auf ein ungeschütztes und unverschlüsseltes WLAN gestoßen ist, dann liegen Teile des dabei erfassten Datenverkehrs im Klartext auf irgendwelchen Datenträgern bei Google. Das ist nun im Rahmen dieser Diskussion natürlich ziemlich blöd für Google, zugegeben. Auf das “mistakenly” da im Zitat mag ich nicht groß eingehen, einerseits ist ein Versehen schon vorstellbar, aber ebenso kann man hier mit etwas bösem Willen Absicht unterstellen.

Klar ist: Google hat sich damit keinen Gefallen getan und natürlich ist das für Gegner ein gefundenes Fressen. Auch wenn sicherlich mit den Datenfragmenten, die angefallen sind, nicht all zu viel angefangen werden kann. Google wechselt einerseits mehrmals pro Sekunde die Kanäle (“our in-car WiFi equipment automatically changes channels roughly five times a second“), andererseits ist das Fahrzeug in Bewegung und somit permanent in anderen Empfangsbereichen. Was für ein Datensalat da am Ende herauskommt, kann sich sicherlich jeder vorstellen. Trotz allem ist natürlich möglich, dass sich mancher Schnipsel persönlicher Informationen in diesem Datenwust finden lässt, die Möglichkeit einer Zuordnung solcher Datenfragmente halte ich aber dennoch für ausgeschlossen und vor allem für nutzlos.

Trotz allem will Google die Daten wieder los werden (sprich: löschen) und das Ganze sinnvollerweise unter Aufsicht. “We want to delete this data as soon as possible, and are currently reaching out to regulators in the relevant countries about how to quickly dispose of it.” In der Zwischenzeit wurden die Fahrten der Street View Cars gestoppt, weiterhin sollen unabhängige Parteien die Software zum sammeln der Daten sowie die gesammelten Daten selbst sichten können.

Angesichts dieses kleinen “GAUs” sind die vorgeschlagenen und begonnen Maßnahmen sicherlich das einzig sinnvolle, was Google tun kann. Und an meinen bisherigen Ausführungen zu diesem Thema ändern die neuen Erkenntnisse auch nichts. Allerdings wird Google nun damit rechnen müssen, NOCH genauer beobachtet zu werden.

Nachtrag: Heute (warum eigentlich erst heute?) finde ich einen wirklich hervorragenden Artikel dazu, wie man versehentlich WLAN-Daten mitschneiden kann. Sehr saubere und verständliche Erklärung, was technisch beim Erfassen von WLANs überhaupt passiert (bzw. passieren muss) und warum man durchaus von einem echten Versehen sprechen kann. Und ich schließe mich dem Fazit dieses Artikels an: Die Vorgehensweise Googles beim Erkennen dieses Problems ist definitiv vorbildlich. Die meisten anderen Unternehmen hätten solch einen Vorfall schlicht unter den Teppich gekehrt und die Daten stillschweigend entsorgt. Google hat das nicht getan sondern sich im Gegenteil aktiv gezeigt und sich freiwillig ins Target der Datenschützer und Medien gestellt. Was Google nun entgegen schlägt wird jedem anderen Unternehmen, dem Fehler passieren, einfach nur eins sagen: Am besten Klappe halten und still und leise aufräumen.

“Facebook Password Reset Confirmation! Important Message

Dear user of facebook,

Because of the measures taken to provide safety to our clients, your password has been changed.
You can find your new password in attached document.

Thanks,
Your Facebook.”

Schon süß irgendwie.

Hoffentlich unnötig zu erwähnen, dass man den Anhang natürlich NICHT öffnet…

Aussage unter anderem:

“Nach gegenwärtigen Erkenntnissen ist davon auszugehen, dass neben der örtlichen Erfassung, dem Verschlüsselungsstatus der Geräte, der weltweit eindeutigen MAC-Adresse auch der vom Betreiber vergebene Name (sogenannte SSID) gespeichert wurde. Bei letzterer verwenden Privatpersonen nicht selten ihre Klarnamen oder andere auf sie hinweisende Informationen. Sowohl mit Blick auf die Benutzung des eigenen Namens als auch auf die Möglichkeit, die WLAN-Netze aufgrund ihrer örtlichen Lage Bewohnern von Häusern zuzuordnen, handelt es sich um die Erfassung und Speicherung personenbezogener Daten und deren Übertragung in die USA.”

Sacken lassen, kurz drüber nachdenken und – lachen.

Entschuldigung Herr Schaar, aber das, was sie da behaupten, ist einfach nicht korrekt. Aufgrund der Tatsache, dass ein WLAN-Netz im Umfeld von einigen Häusern empfangen werden kann, kann man nur eins erkennen: Dieses WLAN-Netz ist um Umfeld von einigen Häusern empfangbar. Mehr erst einmal nicht. Auf Details hierzu gehe ich weiter unten ausführlich ein.

Zudem kann ich die Behauptung, dass die Benutzung des eigenen Namens als SSID “nicht selten” sei, aus eigener Erfahrung und Praxis nicht mal ansatzweise bestätigen. Ich habe eher festgestellt, dass dieser Umstand sogar “extrem selten” ist. Viel wahrscheinlicher als den Namen des Besitzers als SSID eines WLANs wird man Namen wie beispielsweise “FritzBOX” oder dergleichen antreffen.
Im übrigen muss ich sagen: Wer tatsächlich seinen Namen als SSID seines WLANs nutzt, kann an seinem Fenster direkt ein großes Transparent “Hier wohnt Peter Müller” aufhängen. So viel dazu.

(Unter anderem) im Heise-Forum geht es nun wieder heiß her, es wird diskutiert und auf Google eingeprügelt, dass es eine wahre Pracht ist. Und dabei werden mit Unwahrheiten und technischem Halbwissen Szenarien konstruiert, dass einem schwindelig werden kann. Ich werde versuchen, aus mancherlei Geschwurbel mal die Inhalte heraus zu ziehen und die tatsächlichen Hintergründe zu erläutern.

Behauptung 1: Google kann anhand meiner SSID und der MAC-Adresse meines WLANs meinen Routern eindeutig mit den zu mir gesammelten Daten verknüpfen.

Das ist schlicht Unsinn. Was sehe ich denn, wenn ich mit einem WLAN-tauglichen Gerät mal nach verfügbaren WLANs scanne? Ich sehe die SSID, die MAC-Adresse und den Verschlüsselungsstatus. Das wars. Was kann ich mit diesen Daten nun anfangen?

Halte ich mich innerhalb des Empfangsbereiches dieses Netzes auf, kann ich versuchen, die (wahrscheinlich vorhandene) Verschlüsselung zu knacken. Dafür benötige ich aber nicht Google, dafür setze ich mich einfach irgendwo hin und lege los. Wenn ich für lau auf Kosten der WLAN-Betreiber ins Netz will, dann werde ich das an einem Ort tun, den ich bequem erreichen kann. Heutzutage gibt es sicherlich kaum einen Platz innerhalb einer Stadt, an der ich kein WLAN finden werde.

Aber kann Google diese Daten nun eindeutig einer Person zuordnen? Um es kurz zu machen: Nein.

Selbst wenn Google bereits jede Menge Daten über den Nutzer dieses WLAN-Routers gesammelt und gespeichert haben sollte, kann es diese Daten nicht mit der SSID und der MAC-Adresse eines WLAN-Routers in Verbindung bringen. Der Grund hierfür ist ganz einfach: Weder die SSID noch die MAC-Adresse des WLAN-Interfaces werden je von Google (oder jemand anderem im Netz) gesehen. Die SSID sieht noch Euer Notebook oder Handy, danach niemand mehr. Auch die MAC-Adresse des WLAN-Interfaces wird niemals an einen Anbieter eines Internetdienstes übertragen. Um das erschöpfend zu erklären, müsste ich jetzt das OSI-Modell erläutern und von Routing erzählen, wer da etwas mehr Hintergrundwissen erlangen möchte, mag einfach den Links folgen.

Wenn überhaupt eine MAC-Adresse Richtung Provider(!) übertragen wird, dann ist das die MAC-Adresse des Interfaces, welches direkt mit dem Provider verbunden ist. Beispielsweise das DSL-Interface. Spätestens beim Provider verschwindet diese Adresse aber wieder, sie wird für das Routing nicht mehr benötigt. Hier ist dann einzig Eure IP-Adresse des externen Interfaces interessant, die hat aber mit Eurem WLAN mal überhaupt nichts zu tun, eine Zuordnung ist unmöglich.
Und Google sieht von Euch: Eure IP-Adresse. Zuzüglich der Daten, die Ihr freiwillig im Internet preisgebt.

Behauptung 2: Google kann genau feststellen, wo sich mein WLAN-Router befindet und weiß dann, wo ich wohne.

Das ist gleich 2 mal Unsinn. Ich hatte eben bereits erläutert, warum Google (oder jemand anderes) ein WLAN-Netz keiner Person zuordnen kann (solange die betroffene Person nicht so selten dämlich ist, ihren Namen samt Anschrift als SSID zu verwenden).

Um aber den genauen Standort eines WLAN-Routers zu ermitteln, müsste man schon einen Schritt weiter gehen, als Google es tut. Technisch ist das ein alter Hut, das kann prinzipiell jeder mehr oder weniger genau mit ein paar Bauteilen aus dem Elektronik-Shop theoretisch problemlos tun. Aber Google tut es nicht, wie ich gleich erläutern werde.

Zur Standortermittlung eines Signals bedient man sich einer Peilung. Um möglichst verständlich zu erläutern, wie so etwas funktioniert, werde ich jetzt mal etwas “untechnisch”.

Nehmen wir an, auf einem Hügel steht ein Turm, den man aus großer Entfernung sehen kann. Um heraus zu finden, an welcher Position sich der Turm exakt befindet, gibt es 2 Möglichkeiten.
Variante 1: Ich nehme einen GPS-Empfänger, stelle mich in den Turm und sehe dann ganz genau, wo ich mich befinde und wo somit der Turm gebaut wurde.
Habe ich keine Möglichkeit, auch nur in die Nähe dieses Turms zu gelangen, bediene ich mich der Variante 2: Dazu nehme ich wieder den GPS-Empfänger in die Hand, dazu eine Karte. Nun bewege ich mich an einen Ort, von dem aus ich den Turm sehen kann. Hier schaue ich zunächst auf meinen GPS-Empfänger und sehe, wo ich mich befinde. Das zeichne ich in eine Karte mit einem Punkt ein. Nun ziele ich mit einem Kompass auf den Turm (dieses Zielen nennt man peilen) und merke mir die exakte Richtung. Diese kann ich nun als Linie, ausgehend von meinem aktuellen Standort, ebenfalls in meine Karte einzeichnen (die rote Linie in der folgenden Skizze). Wenn ich nun in die Karte schaue weiß ich: Der Turm befindet sich irgendwo auf dieser Linie.

Jetzt fahre ich einfach ein Stück um den Turm herum und wiederhole das Ganze, in der folgenden Skizze als grüne Linie dargestellt. Und nun stelle ich fest: Die beiden Linien kreuzen sich an einem bestimmten Punkt. Dieser Schnittpunkt ist der Standort des Turms. Für noch mehr Genauigkeit wiederhole ich das ein drittes Mal (blaue Linie). Dieses Verfahren nennt man übrigens auch Dreieckspeilung.

Übertragen wir das nun mal auf ein Funknetz wie beispielsweise ein WLAN, dann bedeutet das: Neben meinem aktuellen Standort muss ich zusätzlich auch noch die Richtung feststellen, aus der das Signal eintrifft. Genau das ist bei Funkwellen aber nicht ganz trivial, dafür gibt es spezielle Fahrzeuge. Die hierbei verwendete Spezialantenne ist drehbar und kann somit die Richtung, aus der das Signal am stärksten einfällt, feststellen. Damit wäre die Standortbestimmung eines WLAN-Routers/Accesspoint möglich. Nur: Das geht nicht im Vorbeifahren, hierfür muss sich das Fahrzeug eine gewisse Zeit an einem fixen Standort befinden, um genau einpeilen zu können.

Vergleichen wir nun den Peilwagen im obigen Bild mal mit einem dieser Fahrzeuge: Klick hier. Na, irgendwo eine vergleichbare Antenne zu finden? Eben, nix da.

Nun wird einfach zur Sicherheit behauptet: Braucht Google nicht, anhand der Signalstärke können die errechnen, wo sich der Sender befinden muss. Bis auf wenige Zentimeter genau. Tjaaa…ganz falsch ist das natürlich nicht. Aber eben auch nicht richtig.

Um anhand der Signalstärke an verschiedenen Orten errechnen zu können, muss man folgende Faktoren kennen: Mit welcher Leistung sendet der Sender das Signal überhaupt aus? Und wie breitet sich das Signal in der Umgebung aus?

Letzteres weiß man, wenn man sich auf einer freien Fläche befindet und irgendwo dort steht der Sender. Dann weiß man anhand der physikalischen Gesetzmäßigkeiten, wie stark das Signal in Entfernung zum Sender abnimmt. In einer Stadt ist genau das aber unmöglich zu bestimmen. Jedes Material schirmt die Signale unterschiedlich stark ab. Denkbar ist also, dass ein Signal in 2km Entfernung stärker zu empfangen ist als aus einer anderen Richtung in 100m Entfernung. Weil sich eben bei der 2. Messung ein Gebäude dazwischen befindet, welches die Signale wesentlich stärker abschirmt, als andere. Und schon sind die Messwerte nichts mehr wert.

Wir sehen also: Die Behauptungen sind wieder einmal Blödsinn. Nur, weil man irgendwo mal etwas aufgeschnappt hat, meinen nun manche, daraus ganz schlimme Szenarien konstruieren zu können. Ich denke ich habe gezeigt, dass da mehr Paranoia als Sachverstand im Spiel ist.

Wozu benötigt nun aber Google die Daten, die beim scannen der WLANs gesammelt werden?

Die Antwort ist ganz leicht: Die gesammelten Daten ermöglichen es, eine Standortbestimmung ganz ohne GPS durchzuführen.

Wenn ich an verschiedenen Punkten immer wieder überprüfe, welche WLANs mit welcher Signalstärke empfangen werden können, dann kann ich mit diesen Daten ziemlich exakt meinen eigenen Standort bestimmen, sofern exakt diese Informationen zuvor gespeichert wurden. Jeder Punkt innerhalb einer Stadt hat ein gewisses Schema, eine Art Fingerabdruck. Ich stehe beispielsweise mit dem Notebook vor meiner Haustür und stelle fest: Hier empfange ich die folgenden 8 WLAN-Netze, jedes mit einer ganz bestimmten Signalstärke. Jetzt gehe ich 50 Meter weiter und stelle fest: Es hat sich etwas geändert. Die Signalstärke der einzelnen Netze ist anders, 2 empfange ich hier nicht mehr, dafür ist ein neues hinzu gekommen. Speichere ich diese beiden Ergebnisse zusammen mit meiner aktuellen Position ab, kann ich später erkennen, wann ich mich wieder an dieser Position befinde. Ich kann also ziemlich exakt orten, wo ich mich gerade aufhalte, unabhängig davon, ob ich einen GPS-Empfänger besitze oder nicht. Ich kann allerdings nicht feststellen, wo sich die Sender befinden. Ich weiß nur, wo ich sie empfangen kann.

Dieses Verfahren ist nicht mal neu. Diverse Smartphones nutzen es bereits seit Jahren, allen voran das iPhone. Huch, Apple macht das auch? Dann kann es ja nicht schlimm sein… *hust

Schlimm finde ich an dieser Stelle, dass Peter Schaar sich nicht mal vernünftig informiert, bevor er eine solche Pressemitteilung verfasst. Mindestens seit 2008 ist bekannt, dass die Streetview Cars auch die Handy- und WLAN-Netze erfassen. Daran war nix “heimlich”, wie man nun behauptet. Und genau mit solchen Aktionen schadet Herr Schaar in meinen Augen dem Datenschutz wesentlich mehr, als er ihm nützt. Er sorgt dafür, dass Datenschützer mehr und mehr den Ruf von Paranoikern bekommen, die außer Panik verbreiten nichts können. Und das ist bitter.

Erstaunt hat mich allerdings, dass ausgerechnet der Spiegel in diesem Zusammenhang tatsächlich mal Sachverstand bewiesen hat und nicht einfach auf den Panikzug aufspringen wollte. Kreuz im Kalender.

Update: Ah, Basic Thinking springt auf den Panikzug auf und erzählt uns etwas von “unerlaubterweise“. Jungs, Jungs, Jungs… Euch hätte ich etwas mehr Recherche zugetraut. Siehe oben: Das ist seit 2008 bekannt, also alles andere als eine plötzliche Überraschung.

Noch mehr Panikmache und technischen Unsinn findet Ihr übrigens hier, hier, hier, hier und hier (für die, die drauf stehen), wesentlich mehr Augenmaß zeigen hingegen z.B. Telemedicus und zuihitsu.

Virenscanner würden nämlich nicht mal ansatzweise irgend eine Hilfe sein, wenn der Hersteller Eures Betriebssystems die Hintertüren und Rootkits frei Haus liefert. Wofür braucht man da noch Viren?

Apple hat mal eben auf einen Schlag 88 Sicherheitslücken in OS X geschlossen. Fefe hat die Highlights mal heraus gepickt:

• Code Execution in Rechtschreibprüfung
• Nach dem Reboot ist manchmal die Firewall aus
• Wenn man bei AFP den Gastzugang abschaltet, ist er noch an, und man kann auf Dateien außerhalb der Share zugreifen
• Code Execution durch Audio oder Video abspielen
• Code Execution durch Plattenimage Mounten
• Rootzugriff über Directory Service oder eine der Lücken in OS Services
• Auch per FTP kann man Dateien außerhalb des FTP-Verzeichnisbaumes abrufen
• beim Chatten kann man den Server ownen
• Bilder aufmachen haben sie anscheinend einmal bei jedem verfügbaren Bildformat verkackt, sogar bei RAW-Bildern.
• Das Konvertieren von Fließkommazahlen führt zu Code Execution
• Man kann sich remote über ein altes Passwort einloggen, und Login-Restriktionen wirken auch nicht
• Postscript-Dateien öffnen führt zu Code Execution
• Quicktime ist eh eine einzige Trojaner-Deployment-Plattform

Hey, das nenn ich echt mal sicher. So sicher wie das Amen in der Kirche ist hier, dass nicht mal ein Bruchteil der User weiß, was auf ihrem System so alles passiert. Von genau solchen Fehlern in der Software rede ich seit Jahren, aber keiner der Apple-Maniacs nahm das je wahr. Hier habt ihr es Schwarz auf Weiß. Liebe Leute, mit so etwas habt ihr die ganze Zeit über “gearbeitet”!

Ich bin gespannt auf den nächsten Schwung. Glaubt mir, das war noch lange nicht alles …

Den Authenticator führte Blizzard vor geraumer Zeit ein, um das weit verbreitete Ausspähen von Accountdaten der World of Warcraft-Spieler zu erschweren und so für mehr Sicherheit zu sorgen. Beim Authenticator handelt es sich um ein bedrucktes DIGIPASS GO 6 von Vasco, einem belgischen Hersteller. Er generiert abhängig von der aktuellen Zeit One-time Passwörter, also Passwörter, die exakt 1 Mal innerhalb eines bestimmten Zeitfensters gültig sind. Das eigentliche Zeitfenster, innerhalb dessen das OTP gültig ist,  ist ungefähr 30 Sekunden groß. Um dieses Zeitfenster herum existiert ein weiteres, etwas größeres Zeitfenster, in dem das OTP nicht mehr gültig ist, aber dennoch akzeptiert wird. Letzteres Zeitfenster hat den Zweck, auch Token, deren interne Uhr nicht ganz genau läuft, verwenden zu können. Auftretende Abweichungen der internen Uhr werden so vom Server erkannt und kompensiert.

Die Gültigkeit eines OTP verfällt automatisch, sobald der generierte Code einmal verwendet wurde. Dies erschwert das Ausspähen von Daten enorm, kann es aber nie ganz verhindern. Üblicherweise werden Accountdaten durch Keylogger ausgespäht, die sich auf dem Rechner des Opfers befinden. Bei der Verwendung statischer Kennwörter gestaltet sich das recht einfach: Die Daten werden ausgespäht, an den Angreifer gesendet und dieser hat nun alle Zeit der Welt, die Accountdaten zu benutzen.

Durch die Verwendung von OTPs wird dieser Vorgang für einen Angreifer erheblich aufwändiger. Zum Einen muss hierbei eine Reaktion durch den Angreifer nahezu in Echtzeit erfolgen, da, wie oben beschrieben, die Gültigkeitsdauer eines OTPs nur wenige Minuten beträgt. Zudem muss der Angreifer verhindern, dass das OTP zum Server gesendet werden kann, da anderenfalls das OTP ungültig würde.

Diese Methoden sind nicht neu, die Gefahr eines solchen Angriffs ist seit langem bekannt und keinesfalls auf Token des Herstellers Vasco beschränkt, alle Token basieren letztlich auf dem gleichen Grundprinzip. Hier irgendeine Verantwortlichkeit beim Hersteller zu suchen wäre also keinesfalls gerechtfertigt. Letztlich bleibt bei jeder Sicherheitsvorkehrung immer ein gewisses Restrisiko erhalten.

Neu ist hingegen, dass ein solcher Angriff erstmalig von einem WoW-Spieler beobachtet werden konnte (musste). Der Spieler versuchte, sich mit seinen Accountdaten und dem OTP im Spiel anzumelden. Unmittelbar nachdem er das OTP eingegeben hatte, crashte der WoW-Client. Und genau in diesem Moment reagierte der Angreifer und loggte sich mit den gerade eben ausgespähten Daten ein. Das deutet darauf hin, dass der eingesetzte Keylogger in Echtzeit kommuniziert. Zudem scheint er die weitere Anmeldung des Spielers zu verhindern, denn Zarakiteque schreibt in seinem Beitrag, dass er sich nach diesem Crash nicht mehr einloggen konnte. Dies gelang ihm erst dann wieder, nachdem er den vermutlichen Schädling auf seinem System identifiziert und unschädlich gemacht hatte. In seinem Fall handelte es sich um eine Datei namens emcor.dll, die sich in seinem Appdata/Temp-Verzeichnis befand.

Blizzard hat inzwischen bestätigt, dass es sich hierbei um eine Man-in-the-middle attack handeln muss und untersucht den Fall, weitere Informationen wird es sicherlich in naher Zukunft geben. Interessant finde ich, dass es sich hierbei offenbar um einen recht neuen Schädling handelt, Virenscanner entdeckten ihn noch nicht und via Google konnte der Spieler nur wenige Tage alte Informationen im Web finden (aktuell führen nahezu alle Suchergebnisse bei einer Suche nach emcor.dll zu Beschreibungen dieses Vorfalls).

Der Fall führt wieder deutlich vor Augen, dass jegliche Sicherheitsvorkehrungen auch umgangen werden können. Es wird sicherlich nie eine Lösung geben, die das Ausspähen von Logindaten (und die anschließende Nutzung) vollkommen verhindern kann. Jede Lösung wird letztlich nur den Aufwand erhöhen, der von einem Angreifer betrieben werden muss. Wenn der Aufwand irgendwann den Nutzen übersteigt, wird ein Angriff möglicherweise uninteressant.

Auch wenn ich es weiter oben bereits schrieb, möchte ich abschließend trotzdem noch einmal darauf hinweisen, dass für derartige Angriffe nicht allein die Produkte des Herstellers Vasco anfällig sind. Die Angriffe sind auch bei Token von RSA oder anderen Herstellern möglich. Vasco steht allein deshalb nun im Rampenlicht, weil dessen Produkte von Blizzard eingesetzt werden. Die Funktionsweise derartiger Token ist immer identisch, demzufolge funktioniert exakt diese hier eingesetzte Methode auch in der Praxis mit jedem beliebigen OTP-Generator sämtlicher Hersteller. Vasco ist hier also kein Vorwurf zu machen.

Dumm wäre es jetzt, OTPs generell abzulehnen, wie es in manchen Foren bereits geschieht. Auch wenn ein Angriff möglich bleibt: Er ist wesentlich schwieriger und mit höherem Aufwand durchführbar, als wenn allein Benutzername und Kennwort genutzt würden. Die Verwendung von OTPs erhöht in jedem Fall die Sicherheit, auch wenn sie Angriffe nicht vollends ausschließen kann. Hier ist (wieder einmal) der Anwender gefragt, der genügend Aufmerksamkeit und zusätzliche Absicherungen aufbringen muss, um das Einnisten eines Schädlings zu vermeiden. Sich allein auf die Verwendung einer bestimmten Maßnahme zu verlassen, reicht eben nicht.

Im übrigen setzen auch Paypal und eBay die Token von Vasco ein, diverse Banken nutzen sie ebenfalls und an vielen Stellen werden Lösungen von RSA eingesetzt. Ich bin gespannt, wann hier die ersten vergleichbaren Vorfälle bekannt werden.

Wie einfach es beispielsweise ist, eine Backdoor in ein Template zu integrieren, welche einen Benutzer in WordPress anlegt und diesem Administrator-Rechte zuweist, zeigt der Beitrag “How-To: Create Backdoor Admin Access in WordPress“. Der Code sitzt in der functions.php des Templates und wird durch einen speziellen Aufruf der Zielseite aktiviert. Mittels der Funktion wp_create_user aus wp-includes/registration.php wird nun ein neuer Benutzer in der Datenbank angelegt und zum Administrator gemacht. Fertig, die Tür ist offen. Egal, ob die Registrierung von neuen Benutzern erlaubt ist oder nicht.

Um solch eine Backdoor nachträglich in eine WordPress-Installation zu integrieren, benötigt ein Angreifer natürlich Zugriff auf die Daten, beispielsweise via FTP. Allerdings ist man darauf nicht zwingend angewiesen, was hindert einen potentiellen Angreifer daran, eine Seite aufzusetzen, von der man Unmengen an WordPress-Templates herunter laden kann, die durch die Bank mit einer solchen Funktion präpariert sind? Oder warum sollte ein Entwickler nicht ein solches Hintertürchen in sein wunderbares WordPress-Plugin integrieren? Hand aufs Herz: Wie groß wird der Anteil an WordPress-Nutzern wohl sein, die PHP beherrschen und ein solches Hintertürchen erkennen könnten? 10%? Und wie viele prüfen denn tatsächlich jedes Plugin oder Template auf potentiellen Schadcode? 1%? Weniger?

Aktuell überwiegt einfach das Vertrauen. Vertrauen in die Redlichkeit der Entwickler und Vertrauen in die Ehrlichkeit der Betreiber von Template-Portalen. Sicherlich löblich, offenbar ist noch nicht zu viel passiert in der Vergangenheit. Aber ein wenig Vorsicht sollte dennoch angebracht sein und somit sind vorbeugende Maßnahmen sicherlich nicht falsch.

Den oben beschriebenen “Exploit” (um einen “echten” Exploit handelt es sich meiner Meinung nach nicht wirklich) kann man auf verschiedene Weisen aushebeln.

Variante 1: Wir benennen die Datei wp-includes/registration.php einfach um. Damit hebeln wir allerdings automatisch sämtliche Funktionen zur Bearbeitung bereits existierender Benutzer aus. Also nicht so schick. Zudem ist das nach jedem WordPress-Update zu wiederholen.

Variante 2: Wir kommentieren die Funktion wp_create_user in der Datei wp-includes/registration.php aus. Das Gleiche müssten wir mit der Funktion wp_insert_user in der gleichen Datei tun. Auch hier sind verschiedene Funktionen in der Admin-Oberfläche anschließend defekt und auch dieses Procedere müsste nach jedem Update wiederholt werden. Also auch nicht wirklich schön…

Variante 3 (empfohlen): Wir legen einen zusätzlichen Verzeichnisschutz für das Verzeichnis /wp-admin/ an. Die meisten Provider bieten diese Funktion in der Admin-Oberfläche an, wer diese Funktion bei seinem Provider nicht findet, dem empfehle ich Punkt 8 dieses Artikels. Hier wird die Vorgehensweise recht gut erläutert, auch die anderen Tipps sind prinzipiell sehr zu empfehlen.
Dieser zusätzliche Verzeichnisschutz sorgt nun dafür, dass für den Zugriff auf /wp-admin/ eine zusätzliche Anmeldung erforderlich ist. Bevor also ein Angreifer, der bspw. die oben beschriebene Backdoor ausführen konnte, sich mit seinem neuen Benutzer an Eurem Blog anmelden könnte, müsste er eine weitere, von WordPress unabhängige Authentifizierung erfolgreich vollziehen. Wenn Ihr hier mit einem ausreichend starken Passwort arbeitet, wird das (relativ) schwierig.

Wie weiter oben bereits geschrieben, sehe ich die im verlinkten Beitrag aufgezeigte Möglichkeit zum Anlegen eines administrativen Benutzers nicht als “echten” Exploit an sondern sehe die Problematik allgemein in der Möglichkeit der Erweiterbarkeit. Und sicherlich beschränkt sich das Problem somit nicht allein auf WordPress. Allerdings ist es natürlich durch die von WordPress zur Verfügung gestellten Funktionen wesentlich einfacher, erfolgreich eine Hintertür einzurichten. Möglicherweise sollten gerade die Funktionen zur Erstellung und Änderung von Benutzern gekapselt werden und eben nicht von jedem xbeliebigen Addon genutzt werden können. Aktuell ist es aber möglich, daher sollten WordPress-Nutzer sich nicht allein auf die mitgelieferten Sicherheitsfunktionen verlassen, sondern selbst Hand anlegen. Und sicherlich auch hin und wieder mal nachschauen, ob plötzlich neue Benutzer in der Datenbank auftauchen, obwohl die Registrierung nicht erlaubt ist.

Getestet wurde gegen Systeme, die auf dem aktuellsten Patchstand waren. Am schnellsten war Safari unter Mac OS X offen, ganze 2 Minuten dauerte der Spaß. Schnell verdientes Geld Auch der Internet Explorer 8 und Firefox wurden geknackt, Googles Chrome hingegen blieb bis zum Ende standhaft, nicht ein Exploit konnte erfolgreich durchgeführt werden.

Safari wurde im übrigen gleich 2 mal erfolgreich exploited. Nils, der einen dieser Exploits durchführte, war derjenige, der auch beim IE8 und Firefox erfolgreich war. 15.000$ Preisgeld konnte er so einstreichen, nicht übel.

Und was macht Conrad? Präsentiert einen Service namens “Sofortüberweisung“, bei dem ausgerechnet PIN und TAN abgefragt werden. Das schönste in diesem Zusammenhang ist dieses Zitat aus der Beschreibung (Hervorhebung durch mich):

“Bei dem Dienst “Sofortüberweisung” ist es bisher zu keinen Missbräuchen gekommen (TÜV- zertifiziertes-Online-Zahlungssystem).”

Der Krug geht so lange zum Brunnen… kennen wir ja. Fefe, bei dem ich diesen Hinweis gefunden habe, meint dazu:

“Sagt mir mal: bin ich da zu altmodisch, wenn ich die Idee für eine Katastrophe halte? Vor allem: sie haben da ein Banner, “TÜV Geprüfte Transaktionssicherheit”. Huh? Der TÜV prüft die Transaktionen? Oder hat der TÜV die Idee geprüft und fand sie gut? Kann ich beides kaum glauben.”

Es ist tatsächlich zum heulen. Da versuchen alle, die auch nur ansatzweise Wert auf Sicherheit legen, die Weitergabe von TAN und PIN zu verhindern und Conrad, oder richtiger: die Payment Network AG, ignoriert das glücklicherweise inzwischen gestiegene Sicherheitsbewusstsein und weicht das Ganze auf. Und nicht allein Conrad wickelt die Online-Zahlungen über diesen Dienstleister ab, eine ganze Menge mehr Onlinedienste nutzen offenbar diesen Service, darunter auch das Deutsche Rote Kreuz.

Ganz ehrlich: Ich würde nie im Leben irgendeinem mir unbekannten oder auch bekannten Dienst PIN und TAN übermitteln. Würde mir im Traum nicht einfallen. Und einem Online-Anbieter, der diese Zahlungsmethode anbietet, vertraue ich persönlich nicht. Man mag mich gern paranoid nennen…

Update: Fefe hat ein paar weitere Details veröffentlicht. Auch Banken und Verbraucherschutz warnen im Zusammenhang mit dieser Zahlungsmethode davor, PIN und TAN heraus zu geben.

Versteht mich nicht falsch, ich will jetzt hier keine Lanze für Google brechen, aber ich finde es gelinde gesagt erschreckend, welche Paranoia gepaart mit absoluter Ahnungslosigkeit und Sensationsgier hier zu den unmöglichsten, sachlich einfach falschen Aussagen führt. Deshalb will ich, basierend auf meinen gestrigen Untersuchungen, mal einige falsche Aussagen richtig stellen. Ich werde hier allerdings keinen der Beiträge verlinken, die diese vollkommen haltlosen Aussagen verbreiten.

Aussage 1: Chrome sendet meine eMail-Adresse an Google-Server.

Falsch! In keinem meiner Mitschnitte war auch nur ansatzweise eine Mailadresse zu finden. Ich habe gezielt verschiedene Online-Formulare ausgefüllt (und die dort verwendeten Adressen dann natürlich auch im HTTP-Stream gesehen, sofern die Formulare nicht per SSL übermittelt wurden), darüber hinaus jedoch nichts dergleichen finden können.

Aussage 2: Chrome übermittelt alles, was ich in die Adresszeile tippe, an Google-Server.

Diese Aussage ist nur halb wahr. Richtig ist: Chrome sendet sämtliche Eingaben in der Adresszeile an die voreingestellte Suchmaschine. Und das auch nur dann, wenn die Autosuggest-Funktion aktiviert ist! Ja, es ist ungeschickt, diese Funktionalität als Opt-Out zu gestalten, also in der Grundeinstellung aktiv zu lassen. Allerdings, und da werden mir sicherlich viele zustimmen, das ist es nun mal, was Otto-Normaluser wünscht. Falsch ist definitiv, dass Chrome diese Eingaben immer an Google-Server übermittelt. Die Anfragen werden in jedem Fall nur an die Suchmaschine übertragen, die als Standard eingestellt wurde (bei der Installation wird da auch nachegefragt). Stelle ich hier Yahoo ein, ist keine Kommunikation mehr mit Google-Servern zu sehen, dafür plötzlich jede Menge Verkehr mit Yahoo-Servern. Logisch, wie sollte solch eine Funktion auch anders realisiert werden? Hier aber zu behaupten, alles was man eintippt, landet bei Google, ist sachlich einfach nicht richtig.

Im übrigen passiert exakt das gleiche, wenn man Firefox nutzt. Nicht bei der Eingabe im Adressfeld (hier greift der Firefox ja auf die Browser-Historie zu), aber bei der Eingabe im Suchfeld. Auch hier gehen exakt die gleichen Anfragen übers Netz – zur voreingestellten Suchmaschine.

Verwendet man die Auto-Vervollständigen-Funktion im Chrome, dann wird die letzte, endgültige Eingabe NICHT mehr an die eingestellte Suchmaschine gesendet.

Aussage 3: Google speichert meine Surf-Historie auf seinen Servern.

Ebenfalls vollkommen falsch! Um dies zu realisieren, müsste jeder angeklickte Link zu einem der Google-Server übertragen werden, anderenfalls entgingen Google Unmengen an besuchten Seiten. Dies geschieht jedoch faktisch nicht. Wie in 2. bereits beschrieben, werden lediglich Anfragen an die voreingestellte Suchmaschine gesendet, wenn man etwas in die Adresszeile eintippt und die Autosuggest-Funktion noch aktiv ist.

Aussage 4: Google sendet mit jeder meiner Anfragen eine Identifikationsnummer, anhand derer der Browser eindeutig zu identifizieren ist.

Falsch! Googles eindeutige Identifikationsnummer wird lediglich bei Update-Check durch den GoogleUpdater gesendet. In keiner weiteren Anfrage von Chrome konnte ich sie entdecken. Im übrigen, wie bereits geschrieben: Firefox macht exakt das gleiche (und nahezu jede andere Software auch). Siehe unter anderem auch hier und hier.

Also: sicherlich ist es schön zu sehen, dass das Bewusstsein für Privacy und Datensicherheit steigt. Keine Frage, vor nicht all zu langer Zeit sah das noch vollkommen anders aus. Es ist allerdings nicht mal im Ansatz hilfreich, aufgrund vollkommen falscher Behauptungen eine Hysterie zu erzeugen, so etwas gibt über kurz oder lang sämtliche Bemühungen in dieser Richtung der Lächerlichkeit preis. Denn es ist tatsächlich erschreckend zu sehen, wie uninformiert viele hier in die Diskussion einsteigen: Ein Löwe brüllt es falsch vor (ja, manche Löwen gestehen es selbst immer wieder ein, von der Technik nicht wirklich viel Ahnung zu haben) und die ganzen Kojoten heulen es nach. Sorry, das hilft auf keinen Fall dabei, eine sachliche Diskussion zum Thema zu führen.

Hallo, Eigentümer der E-Mailadresse xxxxx,

Sie erhalten diese Mail von uns, weil wir auf einen datenschutzrechtlich problematischen Sachverhalt aufmerksam gemacht wurden, der Ihre E-Mail-Adresse betrifft.

Ihre E-Mail-Adresse und das Passwort *xxxx* (Zu Ihrer Sicherheit wurde das Passwort gekürzt) befinden sich nach unseren Recherchen auf einem im Internet frei zugänglichen, in China beheimateten Server.

Die Daten scheinen aus einem Datendiebstahl zu stammen, die Datendiebe haben versucht, sich mit Hilfe dieser Kombination aus Mail-Adresse und Passwort Zugang zu Online-Bezahldiensten zu verschaffen.

Die Daten selbst stammen nach ersten Erkenntnissen aus einer Datenbank, die nichts mit Finanzdienstleistungen zu tun hat und bei der Sie sich in der Vergangenheit einmal angemeldet haben.

Möglicherweise nutzen Sie diese Kombination aus E-Mail-Adresse und Passwort für weitere Internet-Dienste, etwa für Ihren Mail-Account, zum Anmelden bei Online-Shops oder auf anderen Webseiten. In diesem Fall raten wir Ihnen dringend, auf jeder einzelnen dieser Seiten Ihr Passwort unverzüglich zu ändern, bevor irgendjemand aus dem Vorhandensein dieser Daten im Internet einen Vorteil ziehen kann.

Hinweise zur Verwendung von Passwörtern und für die sichere Passworterstellung erhalten Sie untenstehend.

Diese Mail geht zurück auf Recherchen der ZDF-Sendung WISO, die am Montag den 8. September ausführlich über diesen Datendiebstahl berichten wird. Informationen erhalten Sie spätestens dann auch unter http://www.wiso.de/  Bitte beachten Sie, dass wir keine Einzelfallberatung durchführen können – E-Mails an diese Versandadresse werden nicht beantwortet.

Wir werden die uns vorliegenden Daten nach Ausstrahlung des Beitrags löschen, Sie erhalten keine weitere Mail von uns an diese Adresse (es sei denn, Sie haben sich bei einem ZDF-Informationsdienst angemeldet.) Wir informieren das vom Datendiebstahl betroffene Unternehmen sowie die entsprechende für den Datenschutz zuständige Behörde von dem Vorfall. Allerdings haben wir keinen Einfluss darauf, die auf einem chinesischen Webserver liegenden Daten zu löschen.

Um über die Brisanz des Datendiebstahls qualifiziert berichten zu können bittet Sie die WISO-Redaktion, an einer kurzen Umfrage zum Datendiebstahl teilzunehmen, selbstverständlich anonym (Beachten Sie die Hinweise am Ende der Mail).
Ihre Angaben können dabei helfen, dass die Zuschauer der Sendung für Probleme rund um die Datensicherheit im Internet sensibilisiert werden.

http://vote.wiso.zdf.de/

Mit freundlichen Grüßen

Zweites Deutsches Fernsehen / Redaktion WISO

Solch eine Mail schockiert natürlich zunächst, viele gehen sicherlich auch von einer Phishing-Aktion aus, auch wenn hier typische Phishing-Elemente fehlen. Diese Mail ist allerdings echt. Einerseits bestätigt das inzwischen WISO, andererseits fanden viele Empfänger dieser Mail tatsächlich bis auf 2 ausge-X-te Stellen ihr Passwort in der Mail. Die Daten stammen offenbar aus der Registrierung für einen Online-Service. Robert und der EDV-Blogger haben inzwischen einige Details hierzu zusammen getragen. Es wurde offenbar tatsächlich in mehreren Fällen versucht, sich mit diesen Daten bei Paypal einzuloggen. Da viele Internetnutzer ein und das selbe Passwort für die unterschiedlichsten Online-Dienste verwenden, kann das in einigen Fällen also auch durchaus geklappt haben. Wer diese Mail also ebenfalls erhalten hat, sollte schleunigst sämtliche Passwörter ändern, die er/sie online benutzt.

Die Mail an sich ist äußerst ungewöhnlich, aber durchaus eine gute Idee der Redaktion. Ich persönlich hätte es allerdings besser gefunden, direkt auf eine Informationsseite zu verlinken, statt nur auf eine kommende Sendung zu verweisen und einen Link auf eine Voting-Seite zu setzen. Das hätte der Glaubwürdigkeit gut getan, so wirkte die Mail offenbar für viele als Spam.

Update: Inzwischen ist zu erfahren, dass die Daten bei PricewaterhouseCoopers geleaked sind. In einer Pressemitteilung heisst es unter anderem:

“Das Wirtschaftsprüfungs- und Beratungsunternehmen PricewaterhouseCoopers (PwC) hat heute Strafanzeige gegen bislang unbekannte Daten-Hacker gestellt, die eine externe Servicedatenbank für Jobsuchende angegriffen und dabei Daten gestohlen haben. Diese von einem externen Serviceprovider betriebene Internet-Seite diente interessierten Nutzern zur vereinfachten Erstellung ihrer Bewerbung bei PwC.

Auf die Spur der Hacker kam PwC nach Hinweisen der ZDF-Redaktion Wiso am gestrigen Mittwoch. Unmittelbar eingeleitete Stichproben-Untersuchungen legen die Vermutung nahe, dass die Hacker die gestohlenen Adressen vor allem für Spam-Mails missbrauchen. Darüber hinaus sind E-Mail-Adressen und Passwörter neben Daten aus den Beständen anderer Unternehmen auf einem chinesischen Server aufgetaucht. PwC veranlasste seinen externen Serviceprovider umgehend zur Stilllegung der betroffenen Internet-Seite. PwC hat bereits damit begonnen, alle möglicherweise betroffenen Nutzer direkt über den Vorfall zu informieren und Hinweise zur eigenen Datensicherheit zu geben. PwC hat vorsorglich die Aufsichtsbehörde für den Datenschutz sowie die Berufsaufsicht von dem Hacker-Angriff und den eingeleiteten Sicherheitsmaßnahmen in Kenntnis gesetzt. Das Unternehmen wird die Ermittlungsbehörden in vollem Umfang bei der Aufklärung der Straftat unterstützen.

Nicht betroffen von dieser Hacker-Attacke sind sämtliche Internetangebote, die von PwC selbst betrieben werden. Dazu zählt vor allem der eigene Internetauftritt www.pwc.de. Ebenfalls nicht von der Attacke betroffen sind sämtliche Kunden- sowie alle übrigen Daten von Mitarbeitern und Bewerbern. …”

Blizzard geht nun einen in meinen Augen sehr eleganten Weg, um seine Kunden zu schützen: Sie bieten in Zukunft die Möglichkeit, optional einen Token für die Benutzerauthentisierung zu erwerben. Dieser generiert ein OTP (One Time Password), welches zusätzlich zu den Anmeldeinformationen eingegeben werden muss. Die Token sind dem jeweiligen Account fest zugeordnet und jedes durch diese Token generierte Passwort ist genau ein einziges Mal gültig, Keylogger werden somit ausgehebelt. Selbst wenn nun jemand Anmeldeinformationen mitschneiden kann – das OTP ist inzwischen ungültig und somit klappt die Anmeldung nicht mehr. Dieses Verfahren ist nicht neu, ich selbst habe es schon unzählige Male bei Kunden implementiert und auch für eBay gibt es seit einiger Zeit Token. Lobenswert finde ich aber, dass ein Hersteller eines Online-Games nun diese Möglichkeit für seine Kunden bietet. Sicher, auch OTPs sind nicht die ultimative und unknackbare Lösung, ein gewisses Restrisiko bleibt immer. Aber für mich ein erwähnenswerter Schritt, der den Kunden zudem gerade mal 6,50$ kosten soll.

Ob, wann und zu welchem Preis diese Token auch für deutsche Spieler verfügbar sein werden konnte ich auf die Schnelle nicht feststellen, ich glaube aber nicht, dass Blizzard diese Lösung nur auf den amerikanischen Markt beschränken wird.

Update: Der Token soll in Europa für 6 Euro verfügbar sein lese ich gerade…

Update 2: Inzwischen ist auch die deutsche Version der FAQ verfügbar. Blizzard wird den Token unter der Bezeichnung Blizzard Authenticator demnächst über den Blizzard Shop vertreiben.

Der Trick ist ein ganz einfacher:  Die Firewall in Leopard definiert Verbindungsregeln nicht auf Portebene (“erlaube Zugriff von aussen auf Port 80″ zum Beispiel), sondern auf Programmebene. Ein installiertes Mailprogramm erhält dann zum Beispiel die Erlaubnis, mit dem Netzwerk zu kommunizieren. Ist das Programm noch nicht bekannt, wird der Benutzer um Erlaubnis gefragt. Bestätigt dieser die Freigabe für die Kommunikation mit dem Netzwerk, dann trägt OS X Leopard eine passende Regel in die Firewall ein. Zudem wird das Programm signiert, um es später eindeutig identifizieren zu können. Prinzipiell keine vollkommen dumme Idee, zugegeben.

Das Dumme an dieser Lösung ist jedoch: Mac OS X Leopard modifiziert bei der Signierung die eigentliche Programmdatei. Manche Programme merken davon nichts und starten wie gewohnt, andere Programme hingegen prüfen ihre Integrität beim Programmstart, wie beispielsweise Skype (und eine Vielzahl von kommerziellen Programmen, die so beispielsweise Crack-Versuche verhindern wollen). Und was passiert nun, wenn ein solches Programm feststellt, dass es modifiziert wurde? Richtig! Es startet nicht mehr. Was natürlich auch eine Methode ist, für Netzwerksicherheit zu sorgen