Skip to content

Wenn Metadaten Spammern verraten, wo Heartbleed zu Datenlecks in Ransomware führt. Oder so.

Heute gibt es Kommentare zu verräterischen Metadaten, Spammern, einem auf die Heartbleed-Schwachstelle zurückzuführenden Datenleck und Cyberkriminellen, die nicht halten, was sie versprechen.

Metadaten verraten verborgene Daten

Sean Sullivan von F-Secure erklärt, warum die Verwendung von HTTPS für Googles Suchmaschine nicht ausreicht, um die Suchanfragen vor dem Ausspähen durch jeden mit Zugriff auf den Netzwerkverkehr des Benutzers zu schützen: "Data vs. Metadata". Als Beispiel dienen im DNS-Abfrage: Wenn jemand erst google.com aufruft, dort etwas sucht und im Anschluss die Website der Anonymen Alkoholiker besucht, dann hat er wohl danach gesucht. Wenn die aus den Suchergebnisse aufgerufene Website kein HTTPS verwendet kann der Lauscher alle damit ausgetauschten Daten beobachten, ansonsten weiß er zumindest, dass danach gesucht wurde. Und es gibt sicher noch mehr Metadaten, über die sich auf die durch HTTPS verborgenen Daten schließen lässt.

Ach ja: Bei den meisten Lesern, die über Google meine Websites finden, wird kein Suchbegriff übertragen. Mir ist das relativ egal, da ich keine gezielte SEO mache, im Allgemeinen kann man aber schon aus der ersten besuchten Seite auf den Suchbegriff schließen. Wer zum Beispiel von Google zum Text über MitM-Angriffe auf HTTPS kommt, wird mit ziemlicher Sicherheit nach MitM-Angriffen gesucht haben.

Spammer, die nicht wissen, was sie tun, zum ersten

Und weil ich gerade bei SEO bin: Da gibt es ein paar Spammer, die mir unbedingt SEO-Dienstleistungen verkaufen wollen. Warum? Weil meine Website angeblich bei den angeblich relevanten Suchbegriffen "carsteneilers angebotsspektrum" nicht unter den ersten Google-Ergebnissen ist. Also:

  1. Bei der Google Suche nach "Carsten Eilers Angebotsspektrum" (ohne Anführungszeichen) steht meine entsprechende Seite im Allgemeinen an erster Stelle.
  2. bezweifle ich stark, dass irgend jemand überhaupt nach diesen Begriffen suchen wird. Und
  3. wird wohl erst Recht niemand nach "carsteneilers angebotsspektrum" suchen. Aber selbst wenn das passieren sollte erkennt Google den Fehler, und welch Wunder, auf Platz 1 ist die gesuchte Seite.

SEO-Optimierung? Wieso? Weshalb? Warum? Vor allem: Warum von jemanden, der 1. regelmäßig meinen Spamfilter füttert und der 2. nicht mal merkt, dass er Blödsinn schreibt? "carsteneilers angebotsspektrum" sind relevante Suchbegriffe? Das glaube ich nicht.

Spammer, die nicht wissen, was sie tun, zum zweiten

Aber die SEO-Spammer sind nicht die einzigen, die für Erheiterung sorgen. Vor einiger Zeit meinte ein anderer Spammer, mich vor einer gefährlichen SQL-Injection-Schwachstelle auf meiner Website warnen zu müssen, über die sich ein Dump der gesamten Datenbank anfertigen lässt. Die gut gemeinte Warnung hat er gleichzeitig mit dem Angebot verknüpft, für einen Dumping-Preis nach weiteren Schwachstellen zu suchen. Der Spammer hat nur zwei klitzekleine Kleinigkeiten übersehen. Erstens: www.ceilers-it.de ist eine statische Website. Da gibt es keine SQL-Abfragen, also auch keine SQL Injection. Und natürlich auch keine Datenbank, von der man einen Dump machen könnte. Und dann mal ganz scharf überlegen: Mit was befasse ich mich beruflich? Rein zufällig ebenfalls mit der Suche nach Schwachstellen. Also, ich bin durchaus selbst in der Lage, Schwachstellen in einer Website zu finden. Nur eben nicht in den statischen Seiten auf www.ceilers-it.de. Das sind reine Textdateien, da gibt es nicht mal JavaScript auf der Client-Seite. Da läuft nichts, gar nichts. Wenn man mal vom Webserver selbst absieht. Hätte der Spammer behauptet, darin eine Schwachstelle gefunden zu haben, wäre er glaubwürdiger gewesen. Aber bei mir an der falschen Stelle, denn für den ist der Hoster zuständig.

Heartbleed-Bug Ursache eines großen Datenlecks

Der Angriff auf den US-Krankenhausbetreiber Community Health Systems (CHS) aus Tennessee, bei dem die Daten von ca. 4,5 Millionen Patienten ausgespäht wurden, soll mit der Ausnutzung der Heartbleed-Schwachstelle in OpenSSL begonnen haben. Die Angreifer konnten über die Heartbleed-Schwachstelle auf einem nicht gepatchten Juniper-Gerät Zugangsdaten ausspähen und darüber über VPN auf das Netzwerk von CHS zugreifen. Interessant ist der Zeitrahmen: Die Heartbleed-Schwachstelle wurde am 7. April öffentlich bekannt, als die Patches dafür von OpenSSL veröffentlicht wurden. Juniper hat die letzten Patches für die eigenen Geräte am 6. Mai veröffentlicht. Die Angriffe erfolgten im April und im Juni. Damit gibt es mehrere Möglichkeiten für den Ablauf der Angriffe, fangen wir mit denen im April an:

Das nicht näher bezeichnete Juniper-Gerät kann angreifbar gewesen sein, weil es noch keinen Patch von Juniper gab oder weil der nicht installiert war. Dass die Angreifer mit den ausgespähten VPN-Zugangsdaten auf das CHS-Netz zugreifen konnten ist nicht weiter bemerkenswert.

Interessanter wird es im Juni, denn nun gab es Patches für alle Juniper-Geräte. Damit gibt es mehrere Möglichkeiten für einen Angriff:

  • Das Juniper-Gerät wurde gepatcht, die VPN-Zugangsdaten danach aber nicht geändert. Die Angreifer konnten dann einfach mit den bereits im April ausgespähten Zugangsdaten auf das CHS-Netz zugreifen.
  • Das Juniper-Gerät wurde nicht gepatcht, die VPN-Zugangsdaten haben sich aber geändert (was unwahrscheinlich ist, sofern die nicht routinemäßig in einem bestimmten Zeitabstand gewechselt werden und der Wechsel zufällig in diesen Zeitraum fällt). Die Angreifer konnten dann die neuen Zugangsdaten über die nicht gepatchte Heartbleed-Schwachstelle ausspähen.
  • Im April wurde eine Hintertür installiert, über die im Juni erneut auf das CHS-Netz zugegriffen wurde. Ob das Juniper-Gerät gepatcht wurde oder nicht und ob die Zugangsdaten geändert wurden oder nicht ist dann völlig egal.

Wie hätte der Angriff verhindert werden können? Im April wäre das nur möglich gewesen, wenn es einen Patch gab und der installiert worden wäre. Gab es keinen, war das Juniper-Gerät den Angriffen hilflos ausgeliefert. Im Juni hätte der dann vorhandene Patch installiert sein müssen, außerdem hätten die VPN-Zugangsdaten geändert sein müssen. Und es durfte keine beim Angriff im April installierte Hintertür geben, sonst waren die ganzen Schutzmaßnahmen an der "Vordertür" vergebliche Liebesmüh. Die Frage, ob/wie der Angriff hätte erkannt werden können lasse ich dabei mal ganz außen vor. Ich hoffe, es wird noch ein detaillierte Bericht über die Angriffe veröffentlicht, die Analyse scheint ja noch nicht abgeschlossen zu sein. Ich persönlich gehe davon aus, dass im April eine Hintertür installiert wurde. Warum sollte der Angreifer, nachdem er einmal erfolgreich ins CHS-Netz eingedrungen war, die Gefahr eingehen, wieder ausgesperrt zu werden, weil die ausgespähten Zugangsdaten geändert wurden?

SynoLocker - Die Cyberkriminellen halten nicht, was sie versprechen

Es gibt schlechte Nachrichten für die Opfer von SynoLocker, der ersten NAS-angreifenden Ransomware (zu der F-Secure übrigens eine ausführliche Beschreibung veröffentlicht hat): Die Entschlüsselung funktioniert nicht. Teilweise war der von den Cyberkriminellen gelieferte Schlüssel für die Entschlüsselung falsch, teilweise funktionierte der Entschlüsselungsprozess nicht. Für diejenigen, die den richtigen Schlüssel haben, ihre Daten aber wegen des fehlerhaften Entschlüsselungsprogramms nicht entschlüsseln können, hat F-Secure ein Tool zur Entschlüsselung bereit gestellt. Warnt aber gleichzeitig ausdrücklich davor, das Lösegeld zu zahlen. Denn zum einen kann es gut sein, dass man für sein Geld nur einen falschen Schüssel bekommt und zusätzlich zu seinen Daten auch noch Geld verloren hat, zum anderen bestärkt man die Cyberkriminellen damit nur in ihren kriminellen Tun.

Damit ist nun genau die Situation eingetreten, vor der ich anfangs bereits gewarnt habe: Die Cyberkriminellen sind zumindest teilweise nicht in der Lage, den für die Entschlüsselung nötigen Schlüssel zu liefern. Und aufgrund der Verschlüsselung mit RSA und AES ist an ein Brechen der Verschlüsselung nicht zu denken. Sofern es nicht auch im Code für die Verschlüsselung Fehler gibt. Was ja durchaus sein kann, denn im Code für die Entschlüsselung ist ja mindestens einer drin, so dass die trotz korrektem Schlüssel teilweise fehl schlägt.

Carsten Eilers

Trackbacks

Dipl.-Inform. Carsten Eilers am : 2014 - Das Jahr, in dem die Schwachstellen Namen bekamen

Vorschau anzeigen
2014 wird als das Jahr in die Geschichte eingehen, in dem die Schwachstellen Namen bekamen. Vorher gab es bereits Namen für Schadsoftware, aber für Schwachstellen haben die sich erst dieses Jahr wirklich durchgesetzt. Die Schwachstelle von