Registrierte Services

Oder: Woher ein Hacker weiß, auf welchen Pornoseiten Sie angemeldet sind

Stellen Sie sich vor, Sie erhalten eine Mail, in der Sie darüber informiert werden, dass Ihr Konto bei der ABC Bank mit sofortiger Wirkung wegen Betrugsverdacht gesperrt wurde. Um es wieder freizuschalten, müssen Sie über den angegebenen Link einen Verifizierungsprozess durchlaufen. Im ersten Moment ploppen vielleicht diverse Horrorszenarien in Ihrem Kopf auf: Wie soll ich jetzt Geld abheben um morgen Nachmittag den Wocheneinkauf zu bezahlen? Was passiert mit dem Dauerauftrag der Mietüberweisung? Können mir meine Kunden oder mein Arbeitgeber überhaupt noch Geld überweisen? Doch dann, nach einem Moment des Schreckens, fällt Ihnen ein, dass Sie ja gar kein Konto bei der ABC Bank haben, sondern bei der XYZ Bank. Glück gehabt.

In diesem Fall ist der Angreifer mit seiner Phishingmail also nach dem Schrotflintenprinzip vorgegangen: Möglichst viel raushauen und irgendwas wird man dabei schon treffen. Dabei liegt die Erfolgsquote allerdings ganz automatisch relativ niedrig: Da der Inhalt der Mails nur für einen Teil der Adressaten überhaupt relevant ist und von diesen dann auch wieder nur ein Teil die Mail öffnen und nur ein weiterer Teil tatsächlich seine Daten eingeben wird, müssen in diesem Fall sehr viele Mails verschickt werden, um eine nennenswerte Zahl an Zugangsdaten abgreifen zu können.

Es geht allerdings auch anders. Herauszufinden, bei welchen Webservices eine Emailadresse registriert ist, ist vergleichsweise einfach. Einerseits gibt es dafür bestehende Tools, andererseits kann der Prozess auch manuell durchgeführt werden, sodass die technologische Hürde äußerst gering ist.

Wie ein Angreifer herausfinden kann, wo eine Emailadresse zur Registrierung verwendet wurde und was er damit alles anstellen könnte, schauen wir uns in diesem Teil unserer „Emails als Waffe“ Serie an.

Registrierte Services enumieren - Holehe

Ein wunderbares Tool um herauszufinden, bei welchen Webservices eine Emailadresse zur Registrierung verwendet wurde, ist Holehe.

Nach der Installation (eine Erklärung dazu findet sich auf der GitHub Seite), kann das Tool einfach wie folgt genutzt werden: holehe [Emailadresse]:

Dadurch wird die vorgegebene Liste an Webseiten daraufhin überprüft, ob die eingegebene Emailadresse dort registriert ist. Drei verschiedene Ausgaben sind dabei möglich:

Wie im Screenshot zu sehen, wurden 121 Webseiten überprüft (die genaue Liste samt der Methode die zur Überprüfung genutzt wurde, kann im GitHub Repository eingesehen werden). Das Plus bedeutet, dass die Emailadresse bei der betreffenden Webseite zur Registrierung verwendet wurde (in diesem Fall also bei Xnxx, Xvideos und Zoho). Das Minus bedeutet, dass die Emailadresse nicht zur Registrierung verwendet wurde (der User hat also kein Xing Konto). Das X bedeutet, dass die Anfrage durch ein Rate Limit der Webseite blockiert wurde, sodass hier keine eindeutige Aussage möglich ist. Wenn die entsprechende Seite (in diesem Fall Yahoo) für unsere Zwecke relevant ist, müsste sie gegebenenfalls nochmals manuell überprüft werden.

Auf diese Weise lässt sich also innerhalb weniger Sekunden (im Test knapp mehr als 14) herausfinden, wo eine Emailadresse zur Registrierung verwendet wurde.

Holehe automatisieren

In der obigen Form ist Holehe ein schönes Tool, um für einzelne Emailadressen herauszufinden, wo sie überall registriert sind. Möchte man allerdings eine größere Anzahl an Adressen (z.B. mehrere Millionen) nach denjenigen filtern, die bei einer bestimmten Seite ein Konto haben, wäre dies kaum möglich, weil man ewig dafür brauchen würde, manuell den Output auf der Kommandozeile zu überprüfen.

Für diesen Use Case bietet es sich also an, Holehe zu automatisieren. Dafür verwenden wir zunächst die Python Standard Libray subprocess:

Testweise überprüfen wir vier Mails, zwei Testmails und zwei nicht existierende Mails. Für jede Mail wird Holehe aufgerufen. Der Output, den wir dabei erhalten, ist ein Bytes Objekt, sodass wir dieses zunächst noch decodieren müssen.

Anschließend können wir nach einzelnen Inhalten im Output suchen. Im obigen Beispiel prüfen wir etwa, ob die getestete Mail bei WordPress.com registriert ist. Falls ja, geben wir dies zusammen mit der Mail aus, falls nicht geben wir explizit aus, dass WordPress.com nicht genutzt wird.

Das führt dann zu folgendem Ergebnis:

Wie erwartet, sind die beiden bekannten Testmails (test@test.de und example@example.com) irgendwann zur Registrierung verwendet worden, die beiden nicht existierenden Zufallsmails aber nicht.

Statt diese Information auf der Kommandozeile auszugeben, könnten wir damit nun auch eine neue Liste „wordpress_user.txt“ erstellen, sodass nur diese User unsere Phishingmail zum Thema WordPress erhalten.

Nachteil der Subprocess Methode ist allerdings, dass Holehe für jede Mail die komplette Liste von 121 Webseiten überprüft, obwohl uns ja eigentlich nur eine einzige interessieren würde.

Um dieses Problem zu umgehen, können wir die Holehe Funktionen auch direkt in unseren Code einbinden. Nachdem die Library installiert wurde (pip3 install holehe) können wir gezielt die Funktion „wordpress“ aus dem modules.cms.wordpress File nutzen:

Den Output erhalten wir in diesem Fall als JSON Objekt. Da uns nur der Parameter „exists“ interessiert, geben wir nur diesen aus. Enthalten sind allerdings auch noch weitere Informationen, wie beispielsweise ob ein Rate Limit festgestellt wurde. Diese könnten wir ebenfalls nutzen, falls wir das Programm weiter ausbauen möchten (beispielsweise um Webseiten mit Rate Limit auf einem alternativen Weg zu testen). In diesem Fall reicht uns aber die Aussage, ob die Email registriert ist (oder nicht) vollkommen aus.

Das führt dann zur folgenden Ausgabe:

Die beiden Testmails sind also wieder korrekt erkannt worden, während die beiden Zufallsmails ebenfalls das korrekte Ergebnis (nicht registriert) erzeugen. Die Ausführungszeit des Skripts hat sich allerdings deutlich verringert, da nun nur noch eine einzige Webseite überprüft wird und nicht mehr 121.

Eigene Versionen

Holehe verwendet eine vorgegebene Liste an bekannten Webseiten, die daraufhin überprüft werden, ob die Emailadresse dort registriert ist. Da der Code von Holehe auf GitHub zu finden ist, kann sich prinzipiell jeder einen eigenen Fork erstellen und Holehe dann nach seinen eigenen Vorstellungen erweitern. Beispielsweise um noch zusätzliche Webseiten zu testen.

Dies tatsächlich im Code umzusetzen, würde ein wenig den Rahmen dieses Blog Beitrags sprengen, ein möglicher Ansatz dafür ist aber nachfolgend aufgeführt:

Zunächst muss auf einer Webseite (z.B. test.de) eine Registrierung vorgenommen werden
Der entsprechende Request muss mit einem Interception Proxy wie Burp Suite abgefangen und dann weitergeleitet werden (die Antwort der Anwendung merken wir uns als Response 1)
Anschließend wird der Request unverändert ein weiteres Mal verschickt. Da die eingegebene Emailadresse nun aber bereits verwendet wird, gibt die Seite mit hoher Wahrscheinlichkeit eine Fehlermeldung aus bzw. zumindest eine Antwort, die sich von der Antwort auf den ersten Request unterscheidet (diese Antwort merken wir uns als Response)
Durch den Vergleich der beiden Request (bzw. deren Responses) kann nun ermittelt werden, ob eine Emailadresse bei test.de registriert ist: Falls nein, sollte Response 1 zurückkommen, falls ja, sollte Response 2 zurückkommen
Eine zu überprüfende Emailadresse muss dann nur noch in den Registrierungsrequest eingefügt werden, anschließend kann aus der Response der Anwendung abgeleitet werden, ob die Adresse bereits registriert ist oder nicht

Das für eine Vielzahl von Seiten umzusetzen, ist im Grunde nicht schwer, sondern eher Fleißarbeit, da sich das Vorgehen jedes Mal wiederholt.

Alternativ zur Registrierungsfunktion kann auch die Login Funktion oder die Passwort Rücksetzungsfunktion verwendet werden.

Auf diese Weise könnte beispielsweise ein Programm geschrieben werden, dass gezielt abprüft, ob die eingegebene Emailadresse bei bekannten Pornoseiten, Fetischforen oder ähnlichen Diensten verwendet wird. Die entsprechende Information kann dann von einem Angreifer verwendet werden, um den User zu erpressen. Diesem Szenario werden wir uns im Laufe des Blog Beitrags noch ausführlicher widmen.

Fehlermeldungen

Nun ist sicherlich nicht jeder in der Lage, mal eben neue Software zu schreiben, oder bestehende Software an seine individuellen Bedürfnisse anzupassen. Und auch ein Tool, das nicht über eine grafische Benutzeroberfläche verfügt, sondern über die Kommandozeile genutzt wird, mag für manche abschreckend sein.

Doch auch ohne jegliche Programmier- und IT-Kenntnisse kann man manuell recht leicht herausfinden, ob eine bestimmte Emailadresse bei einer bestimmten Webseite registriert ist. Dazu muss der oben beschriebene Ablauf lediglich manuell über den Browser durchgeführt werden. Das ist zwar recht zeitaufwendig (insbesondere, wenn man mehrere Emailadressen oder Webseiten überprüfen möchte), erfordert allerdings keinerlei „Hacker Skills“ und sollte somit grundsätzlich für jeden möglich sein.

Exemplarisch kann dies für den Email Service GMX gezeigt werden, der Ablauf ist aber grundsätzlich für jede Webseite gleich:

Wie im Screenshot zu sehen, wird durch die Fehlermeldung bei der Registrierung explizit bestätigt, dass diese Emailadresse bereits vergeben ist, also zu einem existierenden Konto gehört.

Gibt man dagegen einfach zusätzliche Buchstaben ein, könnte diese Adresse noch registriert werden, was im Umkehrschluss bedeutet, dass momentan kein GMX Konto mit dieser Adresse existiert:

Diese manuelle Überprüfung ist zwar zeitaufwendig, dafür aber auch für jeden möglich, da keine besonderen Fähigkeiten erforderlich sind.

Was kann man damit machen?

Nun sind wir also soweit, dass wir, ob nun manuell oder automatisiert, herausfinden können, welche Services mit einer bestimmten Emailadresse genutzt werden. Nun stellt sich also die Frage, was können wir als Angreifer mit dieser Information anfangen?

Phishing

Wie im Eingangsbeispiel erwähnt, kann man Tools wie Holehe verwenden, um realistischere Phishingmails zu erstellen. Um beim Beispiel zu bleiben, würden dann etwa nur noch diejenigen User die ABC Bank Phishingmail erhalten, die auch tatsächlich mit ihrer Emailadresse dort registriert sind. Entsprechend wären die Streuverluste deutlich geringer.

Dem Thema Phishingmails werden wir uns in einigen weiteren Blog Beiträgen noch ausführlicher widmen, sodass dieser Punkt hier nur kurz angesprochen wird. Interessanter, (weil deutlich erfolgsversprechender) für den Angreifer und deutlich verheerender für den User den es betrifft, ist die Möglichkeit, die erhaltenen Informationen über Registrierungen zu Erpressungszwecken zu nutzen.

Blackmailing

Man kann das Ganze natürlich auch noch auf eine ganz andere Ebene heben und die obigen Techniken zur Erpressung (engl. Blackmailing) von Usern verwenden. Dies ist insbesondere dann interessant, wenn man herausfindet, dass die Emailadresse bei einem Webservice registriert ist, dessen publik werden für den User möglicherweise unangenehm ist. Dies könnte beispielsweise sein:

Seiten mit pornografischen Inhalten (insbesondere natürlich wenn diese extreme oder sogar illegale Formen annehmen)
Seiten mit medizinischen Informationen (wer sich bei einer Selbsthilfegruppe für HIV-positive angemeldet hat, möchte vermutlich nicht, dass diese Information jedem bekannt ist)
Seiten mit extremen Inhalten, seien es nun Verschwörungstheorien, politische Meinungen oder sexuelle Fetische
Generell könnte man sagen, dass alles was von der Norm bzw. vom Mainstream abweicht, zumindest potenziell die Basis für einen Erpressungsversuch sein kann

Was genau als unangenehm empfunden wird, hängt natürlich auch von verschiedenen Faktoren ab:

Persönliches Schamempfinden: Dem einen mag es vollkommen egal sein, wenn alle Welt weiß, dass er regelmäßig in den Swingerclub geht, einem anderen ist vielleicht schon die Tatsache peinlich, dass er auf einer stinknormalen Datingseite angemeldet ist.
Persönliche Situation: Offensichtlich macht es einen gewaltigen Unterschied, ob man als Single auf einer Datingseite angemeldet ist, oder als „glücklich“ Verheirateter. Im ersten Fall dürfte kaum Potenzial für eine Erpressung bestehen, im zweiten dagegen eine ganze Menge.
Persönliches Umfeld: Abhängig davon, in welchem Umfeld man sich bewegt, können Informationen sehr unterschiedlich wahrgenommen werden. Ein Politiker einer rechten Partei der in einem rechten Forum registriert ist, ist eher nicht der Stoff für einen großen Skandal. Bei einem Politiker einer linken Partei sieht die Sache dagegen möglicherweise schon ganz anders aus.
Persönliche Bekanntheit: Je mehr eine Person in der Öffentlichkeit steht, umso größer ist letzten Endes auch die Wahrscheinlichkeit, dass selbst kleine Verfehlungen im großen Rahmen ausgeschlachtet werden. Eine schlecht produzierte Neujahrsansprache wird dem Chef eines kleinen Handwerksbetriebes vermutlich kaum auf die Füße fallen. Ist man dagegen die Verteidigungsministerin, kann ein solches Video sogar in Rücktrittsforderungen gipfeln (was zwar nichts mit dem Thema Erpressung an sich zu tun hat, aber das Prinzip veranschaulicht).

Case Study (fiktiv)

Um ein wenig zu verdeutlichen, wie die Enumerierung von genutzten Webservices durch einen Angreifer zur Erpressung genutzt werden kann, schauen wir uns eine kleine Case Study an. Diese ist fiktiv, eventuelle Ähnlichkeiten mit tatsächlichen Fällen sind also rein zufällig und nicht beabsichtigt.

Max Mustermann arbeitet als IT-Systemadministrator bei einem großen Rüstungshersteller. Aufgrund seiner Berufsbezeichnung kann vermutet werden, dass er über sehr hohe Rechte im System seines Arbeitgebers verfügt.
Entsprechend stellt Max ein sehr hochwertiges Ziel für Angreifer da. In unserem Fall handelt es sich bei dem Angreifer um eine staatlich finanzierte Hackergruppe eines ausländischen Staates, die Zugriff auf die Technologien erhalten möchte, die Max Arbeitgeber entwickelt.
Da die staatliche Hackergruppe auf große personelle und monetäre Ressourcen zurückgreifen kann, haben sie schon nach wenigen Tagen Informationen über alle interessanten Mitarbeiter zusammengetragen, unter ihnen auch Max.
Entsprechende Informationen finden sich etwa in Karrierenetzwerken (Berufsbezeichnung, Arbeitgeber, evtl. Abteilung und Standort, Kenntnisse und Berufserfahrung), sozialen Netzwerken (Geburtstage, Wohnort, Beziehungsinformationen, Interessen und Hobbys), Online Telefonbüchern (Telefonnummer, Adresse evtl. Lebenspartner), Suchmaschinen (allgemeine Informationen, private Webseiten oder Blogs) etc.
Da Max sein Privatleben recht freizügig im Netz teilt, erfahren die Angreifer, dass er seit 10 Jahren mit seiner Frau verheiratet ist und sie zwei gemeinsame Kinder haben. Die kleine Familie wohnt in einem Reihenhaus am Stadtrand, von dem aus Max in ca. 20 Minuten das Firmengelände seines Arbeitgebers erreichen kann.
Was (scheinbar) niemand weiß: Max sehnt sich schon seit einiger Zeit nach mehr Abwechslung in seiner Ehe und hat daher beschlossen, sich auf einer speziellen Datingseite zu registrieren, um sich dort eine Affäre zu suchen.
Da er dies, aus offensichtlichen Gründen, nicht zu Hause am Küchentisch machen kann, bei seinem Arbeitgeber aber über ein abschließbares Büro verfügt, liegt der Gedanke nahe, nach dem Ende der regulären Arbeitszeit noch ein wenig länger im Büro zu bleiben, um die Registrierung dort durchzuführen.
Da er nun schon mal in seinem Büro an seinem Dienstrechner sitzt, verwendet Max auch kurzerhand seine Firmenemailadresse, um die Registrierung vorzunehmen. Außerdem denkt sich Max, kennt seine Frau nach 10 Jahren Ehe vermutlich auch das Passwort für seinen privaten Email Account und es wäre sicher nicht von Vorteil, wenn sie dabei auf Mails eines Dating Services stoßen würde.
Durch die Verwendung seiner Firmenadresse (die den Angreifern bekannt ist, da sie einem gleichbleibenden Schema folgt) wird es den Angreifern ermöglicht, herauszufinden, dass sich Max bei einem Dating Service angemeldet hat. In Kombination mit der Tatsache, dass er laut seinen Social Media Kanälen glücklich verheiratet ist, ergibt dies also bereits ein erstes Potenzial zur Erpressung.
Zusätzlich könnten die Angreifer auch noch einen Schritt weiter gehen und selbst ein Profil bei dem Dating Service anlegen. Das ermöglicht a) weitere Informationen zu sammeln die nur registrierten Usern zugänglich sind (unter Umständen hat Max ungewöhnliche Sexualpraktiken in seinem Profil angegeben) und b) mit Max zu interagieren und davon Screenshots anzufertigen (beispielsweise könnten sich die Angreifer als Interessentin für eine Affäre ausgeben und Max weitere belastende Informationen entlocken).
In den nächsten Tagen erhält Max dann eine Email (möglicherweise auch einen Brief) in dem das gesammelte Material aufgeführt ist: Die Tatsache, dass Max ein Konto bei dem Dating Service hat. Profilbilder auf denen er eindeutig zu erkennen ist. Screenshots einer Konversation in denen er diverse weitere private Dinge preisgibt etc.
Weiterhin werden Max die möglichen Auswirkungen aufgezeigt, wenn das entsprechende Material seiner Frau oder seinen Kollegen bekannt werden sollte: Eine mögliche Scheidung mit allen monetären und emotionalen Folgen. Unter Umständen der Verlust des Sorgerechts für seine Kinder. Hohn und Spott im Kollegen- und Bekanntenkreis.
Aber direkt darunter auch ein Ausweg: Max muss nichts weiter machen, als den beigefügten USB Stick in den Firmenrechner zu stecken bzw. den beigefügten Dateianhang auszuführen. Dann wäre alles vorbei und niemand müsste je von dieser Episode in Max Leben erfahren.
Da Max nicht auf den Kopf gefallen ist, ist ihm klar, dass er mit dieser Aktion seinem Arbeitgeber massiv schaden würde. Andererseits, wenn er nicht kooperiert, muss er mit heftigen Konsequenzen für sein Privatleben rechnen.
Wie Max sich letzten Endes entscheidet, lassen wir an dieser Stelle offen. Möglicherweise agiert er als Komplize der Angreifer gegen seinen Arbeitgeber. Möglicherweise akzeptiert er die persönlichen Konsequenzen. Möglicherweise sucht er den Ausweg auch im Suizid.

Die letzte, überaus drastische, Möglichkeit ist dabei kein Produkt meiner Fantasie: nach dem Hack der Seitensprung Plattform Ashley Madison, begingen mehrere Personen Suizid.

Das Ganze ist also alles andere als ein Spiel. Aber eben auch alles andere als eine rein theoretische Bedrohung, sondern ein Szenario mit dem sich insbesondere diejenigen Unternehmen beschäftigen sollten, die extrem sensible Daten verarbeiten (z.B. im Bereich Gesundheitswesen, Finanzen, Rüstung und Hochtechnologie) bzw. die Mitarbeiter, die in den entsprechenden Unternehmen Zugriff auf die jeweiligen Daten haben (Geschäftsführung, Systemadministration, Forschung & Entwicklung).

Gegenmaßnahmen

User: Keine Firmenadresse verwenden

Im dritten Teil unserer Blog Serien Emails als Waffe haben wir ja bereits gesehen, dass es im Grunde trivial ist, die geschäftliche Emailadresse eines beliebigen Mitarbeiters zu enumerieren. Das bedeutet: Jeder Angreifer kennt Ihre Firmenemailadresse und kann über ein Tool wie Holehe (oder eine selbstgeschriebene Variante mit erweitertem Funktionsumfang) herausfinden, bei welchen Webseiten Sie ein Konto haben.

Im Umkehrschluss bedeutet dies also: Wenn Sie irgendwelche Webseiten nutzen, bei denen es Ihnen unangenehm wäre, wenn diese Nutzung publik würde, dann verwenden Sie zur Registrierung unter keinen Umständen Ihre Firmenemailadresse!

Stattdessen sollten Sie für entsprechende Services eigene Emailadressen anlegen, die weder Ihren Namen enthalten, noch für weitere Registrierungen verwendet werden. In diesem Fall ist es für einen Angreifer wesentlich schwieriger, wenn nicht gar unmöglich, Ihnen diese Emailadresse überhaupt zuzuordnen. Entsprechend wird damit sowohl die Erstellung realistischerer Phishingmails, als auch die Sammlung von Informationen zum Zwecke der Erpressung deutlich erschwert.

User: Gesunde Skepsis

Zugegeben, Fälle wie der von Max sind in der Realität glücklicherweise selten, da hier einige Faktoren zusammenkommen müssen.

Wesentlich wahrscheinlicher ist, dass ein Tool wie Holehe genutzt wird, um Phishingmails nur an diejenigen Personen zu verschicken, die bei dem betreffenden Service, dessen Zugangsdaten abgegriffen werden sollen, auch tatsächlich ein Konto haben.

Das bedeutet, nur weil man ein Konto bei der XYZ Bank hat, ist eine Mail die scheinbar von dieser Bank versandt wurde, noch lange nicht legitim, da es für einen Angreifer ein leichtes ist herauszufinden, bei welchen Services eine Mailadresse zur Registrierung verwendet wurde.

Im zweiten Teil unserer Blog Serie haben wir darüber hinaus bereits gesehen, wie leicht die Absenderadresse einer Email gespooft werden kann. In weiteren Beiträgen werden wir noch sehen, wie man auch das restliche Erscheinungsbild der Mail möglichst gut an das Original anpassen kann.

Für User bedeutet das also vor allem eins: Erhaltene Emails sollten immer mit einer gehörigen Portion Skepsis betrachtet werden.

Anbieter: Generische Fehlermeldungen

Während sich die obigen beiden Maßnahmen an End-User richten, kann man auch als Betreiber einer Webseite dazu beitragen, seine User vor entsprechenden Angriffen zu schützen. Grundsätzlich sollte dies bei allen Webseiten umgesetzt werden, besonders relevant ist es allerdings für Webseiten mit sensiblen Themen und Daten.

Eine relativ einfache Möglichkeit Enumerierungsmaßnahmen durch einen Angreifer zu erschweren, ist dabei die Ausgabe möglichst generischer Fehlermeldungen.

Die folgenden drei Funktionen können üblicherweise genutzt werden, um die Registrierung einer Mailadresse zu bestätigen und sollten daher hinsichtlich der Fehlermeldung überarbeitet werden:

Login: Wenn sich die Fehlermeldung bei einem Login Versuch mit einer vergebenen Emailadresse von der Fehlermeldung bei einer nicht vergebenen Emailadresse unterscheidet („Das Passwort das du für den Usernamen XY eingegeben hast ist nicht korrekt“ vs. „Der Username XY ist nicht vergeben, klicke hier um dich zu registrieren“), ist es für einen Angreifer ein leichtes herauszufinden, welche Usernamen (bzw. Emailadressen) bei diesem Service registriert sind und welche nicht.
- Lösung: In beiden Fällen sollte die gleiche Fehlermeldung angezeigt werden (z.B. „Login Informationen nicht korrekt, bitte überprüfe Username und Passwort“). In diesem Fall kann der Angreifer keine Aussage darüber treffen, ob der Username registriert ist oder nicht.
Passwort vergessen: Während sich gleichlautende Fehlermeldungen bei Login Seiten zunehmend durchsetzen, sind sie bei der „Passwort vergessen“ Funktion noch eher selten zu finden (was die Maßnahme bei der Login Seite natürlich ad absurdum führt, in etwa so als würde man seine Haustür sicher abschließen und verriegeln, direkt daneben aber das Fenster offenstehen lassen).
- Lösung: Nachdem ein User eine Emailadresse in das „Passwort vergessen“ Feld eingetragen hat, sollte ihm immer dieselbe Meldung angezeigt werden (z.B. „Wenn diese Emailadresse registriert ist, senden wir dir einen Rücksetzungslink zu“). Intern kann dann geprüft werden, ob die eingegebene Emailadresse zu einem korrekten Konto gehört und entsprechend ein Link verschickt werden.
Registrierung: Während im Fall der „Passwort vergessen“ Funktion und des Logins nur die Fehlermeldung angepasst werden muss, gestaltet sich die Sache bei der Registrierung ein wenig schwieriger. Falls die Adresse bereits zur Registrierung verwendet wurde, kann eine erneute Registrierung nicht durchgeführt werden. Es ist relativ wahrscheinlich, dass ein Angreifer diese Funktionalität in irgendeiner Weise nutzen kann, um herauszufinden, ob die Adresse verwendet wird oder nicht. Als Betreiber der Webseite kann man dem Angreifer aber zumindest die Arbeit ein wenig schwerer machen.
- Lösung: Man könnte dem Angreifer die Arbeit z.B. dadurch erschweren, dass man die Registrierung leicht abändert: Der User gibt seine Emailadresse ein, anschließend wird ihm, wie bei der „Passwort vergessen“ Funktion, folgende Meldung angezeigt „Wenn diese Adresse noch nicht zu einem gültigen Konto gehört, schicken wir dir die Registrierungsdetails zu“. Das bringt aus Usability Sicht allerdings den Nachteil mit sich, dass dadurch die Registrierung nicht mehr in einem Stück auf der Webseite möglich ist, sondern der User nun zunächst in seinem Emailaccount auf die Registrierungsdetails zugreifen muss, bevor er fortfahren kann. Generell ist es zudem hilfreich, wenn die Registrierung in möglichst viele Unterschritte aufgesplittet ist (z.B. zuerst Anschrift eingeben, auf Weiter klicken, einen Usernamen wählen, auf Weiter klicken, ein Profilbild hochladen, auf Weiter klicken etc. Dadurch kann der Prozess durch einen Angreifer schwieriger automatisiert werden, was zumindest einen gewissen Schutz vor Tools bietet, die automatisch Emailadressen überprüfen, bei manuellen Tests aber zugegebenermaßen wenig bringt. Zudem ergeben sich auch hier negative Folgen für die Usability der Seite, sodass man als Webseitenbetreiber abwägen muss, ob man den Fokus eher auf Security oder Usability legen will.

Arbeitgeber: Schlüsselpersonen durchleuchten

Um entsprechende Fälle wie den des fiktiven Max zu verhindern, sollten Arbeitgeber aus den oben genannten kritischen Bereichen ihr Schlüsselpersonal sorgfältig durchleuchten.

Das heißt, im Idealfall sollte bereits vor dem Beginn des Arbeitsverhältnisses, oder zumindest bevor der Zugang zu sensiblen Daten freigegeben wird, geprüft werden, ob irgendwelche Erpressungspotenziale bestehen.

Arbeitgeber: Ausweg schaffen

Eine lückenlose und dauerhafte Überprüfung aller Mitarbeiter dürfte indes kaum möglich sein. Dementsprechend muss auch für den Fall vorgesorgt werden, dass das Kind einmal in den Brunnen fällt.

Nehmen wir an, Max informiert seinen Chef über den Erpressungsversuch und dass von ihm verlangt wird, die Firma mit Malware zu infizieren. Max Chef hätte dann im Prinzip zwei Möglichkeiten:

Sofort alle Zugänge von Max zum System deaktivieren und Max nach Hause schicken. Das unterbindet zwar den Angriff, Max hätte in diesem Fall aber vermutlich dennoch die persönlichen Folgen zu tragen, da er der Aufforderung der Angreifer nicht nachgekommen ist und somit mit der Veröffentlichung des belastenden Materials rechnen muss. Im besten Fall also eine Win/Lose Situation.
Ein vom eigentlichen Netzwerk getrenntes System aufsetzen, in dem Max die Malware dann ausführt. Durch die Trennung besteht keine Gefahr für reale Daten, im Gegenzug kann aber das Verhalten der Angreifer (z.B. welche Tools und Exploits werden genutzt) bzw. der Malware (z.B. mit welchen IP-Adressen werden Verbindungen aufgebaut) analysiert werden. Die daraus gewonnenen Informationen können überaus wertvoll sein, um die eigene Verteidigung zu stärken. Unter Umständen könnten den Angreifern auch gezielt falsche Informationen zur Verfügung gestellt werden, beispielsweise um den tatsächlichen Entwicklungsstand einer Technologie zu verschleiern. Da Max in diesem Szenario den Anweisungen des Angreifers, zumindest scheinbar, Folge leistet, besteht für ihn eine gewisse Hoffnung, dass es nicht zur Veröffentlichung des belastenden Materials kommt. Im besten Fall ergibt sich also ein Win/Win Situation.

Offensichtlich ist die zweite Möglichkeit mit einem erheblich größeren Aufwand verbunden. Ein komplett echt wirkendes Netzwerk mit glaubhaften Daten und Systemen kann kaum in ein paar Minuten aufgesetzt werden, sondern erfordert einiges an Vorlaufzeit. Andererseits bietet diese Möglichkeit aber eben auch die Chance, direkte Informationen über die Vorgehensweise der Angreifer zu erhalten. Die erste Möglichkeit blockt den Angriff dagegen lediglich ab, was vielleicht für einen kurzen Moment der Ruhe sorgt, vermutlich aber nicht ausreicht, dass der Angreifer seine Bemühungen wirklich einstellt. Im ersten Szenario ist der nächste Versuch also nur eine Frage der Zeit. Und irgendwann wird der Angreifer vermutlich einen Mitarbeiter finden, der mit ihm kooperiert.

Fazit

Wie wir in diesem Beitrag gesehen haben, ist es vergleichsweise leicht herauszufinden, bei welchen Webservices eine Emailadresse registriert ist. In Verbindung damit, dass geschäftliche Emailadressen sehr leicht in Erfahrung gebracht werden können und private Mailadressen teilweise recht freizügig geteilt werden, können sich damit extreme Risiken für die eigene Privatsphäre ergeben.

Wenn man sich irgendwo registriert, sollte man sich also immer der Tatsache bewusst sein, dass diese Information auch anderen zugänglich werden könnte, die möglicherweise nicht die besten Absichten haben.