© complize, Photocase.com

Eine Firma veröffentlicht eine vorgeblich skandalöse Sicherheitslücke im E-Mail-Dienst von T-Online, Web.deund anderen Providern. Wer das Marketing-Gedöns beiseite schiebt und technischen Sachverstand walten lässt, erkennt: Alles alter Nippes.

“Neuer Telekom-Datenskandal – Bis zu 14 Millionen Kunden betroffen” – solche Meldungen mögen Journalisten. Denn von der Pressemitteilung [1] der Firma Resisto GmbH mit Sitz in Mainz scheinen viele Bundesbürger persönlich betroffen zu sein. Außerdem geht es gegen einen Konzern, der schon früher mit Datenschludereien aufgefallen ist. Im Kern weiß Resisto zu berichten, ein Sicherheitsteam unter Aufsicht neutraler Sicherheitsexperten habe bewiesen, dass jeder technisch Bewanderte bei der Telekom die E-Mail-Adressen der Kunden ausspähen kann. Die Lücke sei auch bei GMX und Web.de anwendbar.

Bei T-Com sei dieser Angriff wegen der numerischen E-Mail-Adresse besonders effizient, da der rosa Riese E-Mail-Adressen automatisch vergibt, die den Hauptbenutzernummern entsprechen. Die Pressemitteilung verweist gleich auf ein Tool bei [http://www.resisto.com], mit dem Kunden der Provider prüfen könnten, ob sie selbst betroffen sind.

Die Firma Resisto und ihr Geschäftsführer Tobias Huch (Abbildung 1) haben in Deutschland bereits einen Namen, wenn es um Datenskandale geht. Huch bekam nach eigener Aussage 2006 eine Kundenliste der Telekom angeboten (Interview unter [2]), die unter 17 Millionen anderen auch die geheimen Telefonnummern von Prominenten enthielt, was 2008 den so genannten T-Mobile-Datenskandal aufdecken half. Allein deshalb ist die neue Äußerung der Firma der Beachtung wert.

Abbildung 1: Tobias Huch, Geschäftsführer von Resisto IT, half den T-Mobile-Skandal ins Rollen zu bringen und sorgt nun selbst für die Schlagzeilen.

Adresse gültig?

Die Pressemitteilung beschreibt einen Brute-Force-Angriff auf die Telekom-Server, der eine hinlänglich bekannte und viel diskutierte Eigenschaft von SMTP ausnutzt: Ein Server meldet im Dialog mit dem jeweiligen Client unmittelbar zurück, ob er überhaupt E-Mails für die übergebene Zieladresse annimmt. Listing 1 zeigt den Ablauf der SMTP-Kommunikation, nachgeahmt mit Telnet.

In Zeile 4 begrüßt der Server den Client, in Zeile 5 stellt sich der Client vor. Bereits hier darf der Client im Prinzip jeden beliebigen Rechnernamen verwenden, da SMTP über keine Authentifizierung verfügt. Die Zeilen 6 bis 8 zeigen eine (verkürzte) Antwort des Servers, in der er verfügbare Befehle auflistet. Anschließend gibt der Client seine Absenderadresse für die einzuliefernde E-Mail-Adresse an. Auch die prüft der Server in der Regel nicht. Die Serverantwort in Zeile 10 ist insofern etwas irreführend.

Mit »RCPT TO:« in den Zeilen 11 und 13 versucht nun der Client die Adressaten der E-Mail zu übergeben. Dabei prüft der Server, ob er für die Domains zuständig ist, was hier zutrifft, und ob die Adressen auch lokal eingerichtet sind (Zeilen 12 und 14). Diese Rückmeldung ist das, was die Pressemitteilung als Brute-Force-Angriff meint. Tatsächlich lässt sich der Mechanismus nutzen, um zu versuchen die Adressen unter einer Domain aufzuzählen oder auch nur zu checken, ob eine Zieladresse gültig ist.

Dafür bietet jedes besser sortierte Downloadportal im Bereich »E-Mail-Tools« Programme wie E-Mail-Verifier, die eine Adressenliste gegen die zuständigen Mailserver prüfen. Das sind klassische Spammertools, deren Beschreibungen sie meist als “Adressbuch-Prüfprogramm” tarnen. Mehr tut die Webapplikation der Resisto-Website auch nicht – eher weniger (siehe Kasten “Resistos Testskript”).

Lohnt der Aufwand?

Die Telekom vergibt an jeden Kunden eine E-Mail-Adresse, die sich aus der elf- beziehungsweise zwölfstelligen so genannten T-Online-Nummer und der vierstellige Mitbenutzernummer zusammensetzt [3]. Da die Mitbenutzernummer in der Regel »0001« lautet, muss ein Angreifer maximal die ersten zwölf Stellen der Mailadresse raten. Das begrenzt die Menge nötiger Versuche auf 1012, also eine Billion.

Ende 2008 hatte die Telekom (mit Ausland) knapp 15 Millionen Breitbandkunden, was statistisch einen Treffer pro rund 70 000 geratenen Nummern erwarten lässt. Richtig ist: Würde die Telekom Adressen nicht fest vorgeben, wäre die Treffer-Wahrscheinlichkeit geringer.

Trotzdem gibt es effizientere Methoden, Millionen E-Mail-Adressen eines Landes mit einer guten Trefferquote zu generieren: Spammer können eine Telefonbuch-CD erwerben, daraus sämtliche Namen extrahieren und »Vorname.Nachname@t-online.de«, »…gmx.de« und »…web.de« gegen die jeweiligen SMTP-Server testen. So ein Skript müsste weit weniger als eine Billion Abfragen tätigen und würde darum nicht Wochen oder gar Jahre laufen wie beim Resisto-Vorschlag.

Trend zur Wahrheit

In der Antispam-Community flammt immer wieder die Diskussion auf, ob es zum Vermeiden dieser Brut-Force-Variante nicht besser sei, Server so zu konfigurieren, dass sie für alle lokalen Mailadressen behaupten, sie existierten – zumindest im SMTP-Dialog. Im Gegenzug bekäme aber ein legitimer Absender, der sich bei der Zieladresse nur vertippt hat, keine Fehlermeldung mehr. Er geht fälschlich davon aus, seine Mail sei zugestellt. Das ist nicht nur unschön, sondern damit verletzt der Mailprovider möglicherweise das Fernmeldegeheimnis durch Unterdrücken (§206 Abs. 2 Alt. 2 StGB).

Darum müsste der Server zu einem späteren Zeitpunkt eine Fehlermeldungs-E-Mail generieren und an die Absenderadresse verschicken. Das ist nett gedacht, führt aber bei Spam meist dazu, dass diese an einen Falschen geht – Spammer missbrauchen gern Adressen unbeteiligter Dritter als Absender. Der erhielte nun alle Fehlermeldungen – locker mehrere 10000 Stück am Tag. Das überflutete Postfach verursacht unter Umständen weitere Fehlermeldungs-Mails, was das Volumen weiter anschwellen lässt. Daher besteht weitgehend Einigkeit darüber, im SMTP-Dialog die Adressenvalidierung weiterhin wahrheitsgemäß abzuwickeln.

01 Trying 192.0.2.3...
02 Connected to 192.0.2.3.
03 Escape character is '^]'.
04 220 mx.example.net; ESMTP Mon, 13 Apr 2009 00:09:58 +0200 (CEST)
05 EHLO example.org
06 250-mx.example.net Hello [192.0.2.137], pleased to meet you
07 250-ENHANCEDSTATUSCODES
08 250 HELP
09 MAIL FROM:<testuser@example.org>
10 250 2.1.0 <testuser@example.org>... Sender ok
11 RCPT TO:<info@example.net>
12 250 2.1.5 <info@example.net>... Recipient ok
13 RCPT TO:<nonexistent@example.net>
14 550 5.1.1 <nonexistent@example.net>... User unknown
15 QUIT
16 221 2.0.0 mx.example.net closing connection

Was tun?

Um solche Brute-Force-Angriffe zu stoppen, gibt es verschiedene Ansätze. Sendmail zum Beispiel lässt sich so konfigurieren, dass es nach einer Anzahl von falschen Adressaten verzögert antwortet. Die folgende Zeile in der »sendmail.mc« erzwingt das nach drei Fehlversuchen:

define(`confBAD_RCPT_THROTTLE',3)dnl

In [4] hat der Autor dieses Beitrags ein Sendmail-Patch vorgestellt, das abhängig vom Verhältnis falscher zu richtigen Adressaten eine Verzögerung einbaut. Legitime Newsletter-Versender profitieren davon; sie müssen mit einem niedrigen Prozentsatz ungültiger Adressen leben – einige Empfänger deaktivieren immer einen alten Mailaccount, auf den der Newsletter zielt. Bei beliebten Newslettern summieren sich deaktivierte Accounts für einen großen E-Mail-Provider wie GMX durchaus auf mehrere Tausend.

Hier ist eine starre Bremse ungünstig. Das Patch berücksichtigt dies und bremst Spammer, deren Falsch-zu-richtig-Verhältnis näher an 100 Prozent liegt, mehr aus als legitime Versender, die im niedrigen Prozentbereich liegen. So lässt sich der Brute-Force-Angriff elegant bremsen, ohne Kollateralschäden zu verursachen. Ein schneller Test zeigte, dass die Telekom diese Technik noch nicht verwendet. Dazu hat das Linux-Magazin gut 67 000 zufällige E-Mail-Adressen generiert und gegen den Mailserver validiert. Trotz Druckbetankung mit Netcat und rabiatem Vorgehen blieben die Tester ungestraft.

Abbildung 2: Das angepriesene Test-Tool fordert scheinbar dazu auf, die eigene Mailadresse abzuliefern.

Luft raus

So ärgerlich es für Journalisten auch sein mag: Einmal angepiekt, bleibt von dem angekündigten Skandal wenig übrig. Dass ein SMTP-Server über jede ihm vorgelegte E-Mailadresse wahrheitsgemäß Auskunft erteilt, war und ist sinnvoll. Und dass die Telekom Mailadressen numerisch zuteilt, ist wahrlich keine neue Erkenntnis. Dass sie Spammern das Raten etwas leichter macht, leitet sich auf simpelste Weise her.

Was bringt das Ganze nun? Zumindest die Firma Resisto IT, Betreiberin des “Jugendschutzsystems” Ueber18.de, positiv in die Schlagzeilen. Vielleicht drohte der Ruhm, den T-Mobile-Datenskandal vor einem Jahr mit aufgedeckt zu haben, wegen anhaltender Berichterstattungen über die Freizeitaktivitäten Huchs [5] zu verblassen? Meldungen wie “Polizei legt Porsche Turbo an die Kette” mögen Journalisten nämlich auch. (jk)