c't deckt auf: Webmail-Oberfläche von All-Inkl.com angreifbar

Inhaltsverzeichnis

Der deutsche Hosting-Anbieter All-Inkl.com hat Sicherheitslücken in seinen Webmail-Oberflächen für Desktop- und Mobilgeräte geschlossen. Angreifer hätten die Lücken nutzen können, um JavaScript innerhalb einer Mail im Kontext des angemeldeten Nutzers auszuführen – so wäre es möglich gewesen, über einen entsprechend präparierten Link das gesamte Postfach unbemerkt zu kopieren.

Als Angreifer hätte man eine Mail an einen Empfänger verschicken müssen, der bekanntermaßen die Weboberfläche nutzt und ihn davon überzeugen müssen, den Link auch anzuklicken – etwa über eine nachgebaute Versandstatus-Mail. Kunden, die ihre All-Inkl-Mails über einen Mailclient wie Thunderbird oder Outlook abgerufen haben, waren nicht betroffen. Die Lücken wurden jetzt geschlossen und es gibt keine Anhaltspunkte dafür, dass sie ausgenutzt wurden.

Aufmerksam auf die Schwachstellen wurde der Softwareentwickler Leo Dessani, selbst Kunde von All-Inkl.com, der sich mit seinen Erkenntnissen an c't wandte, nachdem er vom Support keine Antwort mehr bekam – zuvor hatte er diesen auf eine kleinere Lücke im Zusammenhang mit Mailanhängen hingewiesen. Zusammen mit dem Tippgeber konnten wir den Angriff anhand eines Test-Accounts nachvollziehen.

Cross-Site-Scripting

Anders als die meisten anderen deutschen Hosting-Anbieter, die auf Open-Source-Mailoberflächen wie Roundcube setzen, hat All-Inkl.com zwei Eigenentwicklungen im Einsatz: eine Mobil- und eine Desktop-Seite. In der Desktop-Oberfläche basierte der Angriff auf klassischem Cross-Site-Scripting. Gefiltert wurden, wie es sich für eine solche Oberfläche gehört, auf der HTML von externen Quellen auf der Seite angezeigt wird, sämtliche <script>-Tags. Nicht gefiltert wurde jedoch das JavaScript-Ereignis onpointerup. Ein manipulierter Link war leicht zu erzeugen:

<span onpointerup="alert('XSS!')"><a href='https://schadcode.example.org'>klicken Sie hier für die Sendungsverfolgung</a></span>

Weil sich das Skript im Kontext des angemeldeten Nutzers bewegte, war es kein Problem, andere Befehle innerhalb des Postfachs abzusetzen. Dem Hinweisgeber gelang es mit etwas Programmieraufwand, im Hintergrund komplette Postfächer auszulesen und die Inhalte auf einen externen Server zu verschicken. Für den Nutzer passierte all das unbemerkt. Ein gegen Cross-Site-Scripting im HTML eingebautes Token konnte diesen Angriff nicht verhindern, da das eingeschleuste Skript auf das HTML zugreifen und dieses problemlos auslesen konnte.

Mobiler Angriff

In der mobilen Ansicht wurden die Inhalte von Mails von einem Formular umgeben. Um aus diesem auszubrechen, musste ein Angreifer ein <input>-Element in eine Mail einbauen und diesem ein formaction-Attribut übergeben. Klickt der Empfänger darauf, hätte im Hintergrund zum Beispiel eine Mail verschickt werden können.

Reaktion

Zusammen mit der Dokumentation der Lücken bat c't den Anbieter um eine Stellungnahme. Die Reaktion erfolgte vergleichsweise schnell. Der Inhaber des Unternehmens, René Münnich, meldete sich per Mail. Die Lücken wurden beseitigt, was unsere Tests bestätigen.

Nach Angaben von Münnich werden die Webmailer nur von etwa drei Prozent der angemeldeten Mailadressen benutzt. Ein nicht näher genannter Prozentsatz habe statt der HTML-Ansicht auf die reine Textansicht von Mails umgestellt und sei damit nicht betroffen.

Kunden, die sich jetzt in der Webmailoberfläche anmelden, sehen einen Hinweis zum Vorfall. Nach Angaben des Unternehmens wurde der zuständige Landesdatenschutzbeauftragte des Landes Sachsen informiert.

Häufiges Problem

Entwickler, die selbst eine vergleichbare Oberfläche oder gar einen eigenen Mailclient entwickelt haben, sollten ihre Systeme auf das Einschleusen sämtlicher JavaScript-Ereignisse prüfen, die mit "on" beginnen und solche unschädlich machen. Eine Übersicht gibt es bei w3schools.com – noch sicherer ist es, fremdes HTML gänzlich zu verbieten.

Nutzer sind vor solchen Cross-Site-Scripting-Angriffen nie zu 100 Prozent sicher. Selbst in Thunderbird, das schon seit 2004 entwickelt wird, finden sich immer wieder Lücken. Die sicherste Mail bleibt die HTML-freie reine Text-E-Mail.

[Update vom 8.4.] Hinweis ergänzt, dass der Tippgeber sich zunächst mit einer anderen Lücke an den Kundendienst wandte und erst nachdem er dort keine Antwort mehr bekam, den Kontakt zu unserer Redaktion aufnahm. (jam)