© Mariok / 123RF.com

Nicht zuletzt aufgrund der Querelen im Zug der Twitter-Übernahme wird die Alternative Mastodon immer beliebter. Das versuchen auch Angreifer auszunutzen.

Der verteilte Microblogging-Dienst Mastodon hat sich in den letzten Monaten zu einer populären Alternative zu Twitter entwickelt. Als Anwender erstellt man einen Account auf einem der vielen verschiedenen Mastodon-Server (Instanzen) und kann von dort aus Nutzern auf allen anderen Servern sowie anderen Diensten des Fediverse (eine Art Netz aus Netzen) folgen. Mastodon-Toots (das Gegenstück zu Tweets) dürfen neben gewöhnlichem Text auch HTML-Anweisungen enthalten. Damit lassen sich nicht nur einfache Textnachrichten posten, sondern auch grafisch gestaltete HTML-Inhalte.

Allerdings muss man dabei darauf achten, dass Angreifer dieses Feature nicht für Cross-Site-Scripting- oder HTML-Injection-Attacken nutzen. Über derartige Attacken könnten sie HTML- oder Javascript-Anweisungen im Webbrowser des Opfers ausführen und damit Schaden anrichten. Gewöhnlich basieren passende Schutzmechanismen auf Filtern, die beispielsweise den HTML-Code genau inspizieren und sicherstellen, dass es zu keiner solchen Attacke kommt.

Angreifer haben allerdings einen Weg gefunden, diesen Schutz in Mastodon zu umgehen und damit unter Umständen an die Passwörter von Anwendern zu gelangen [1]. Die Attacke setzt bei dem Verified-Icon an, das einige Benutzer in ihrem Namen verwenden. Dabei wird der »:verfified:« Text durch eine HTML-Bildelement-Anweisung ersetzt. Konkret wird beim Einsetzen von »:verified:« der HTML-Code aus Listing 1 eingefügt.

<img draggable="false" class="emojione custom-emoji" alt=":verified:" ... >

Die Idee der Attacke beruht nun darauf, dass Werte von HTML-Attributen immer in Anführungszeichen stehen. Gelingt es dem Angreifer nun, innerhalb des Attributs selbst wieder ein Anführungszeichen einzuschmuggeln, dann geht der HTML-Interpreter davon aus, dass das Attribut dort bereits endet. Nachfolgenden HTML-Code interpretiert er folglich nicht mehr als Attributwert, sondern als regulären HTML-Code, den er dann auszuführen versucht.

Damit liegt eine typische HTML-Injection-Attacke vor, bei der der Angreifer von ihm gewünschten Code vom HTML-Interpreter ausführen lässt. So wird beispielsweise der Code aus der zweiten Zeile von Listing 2 nach der Ersetzung von »:verified:« durch den HTML-Code für das Bildelement zu der Variante aus Zeile 4. Der HTML-Interpreter zählt nun die Anführungszeichen und denkt, dass der Attributwert für das Attribut »title« bereits nach dem zweiten Anführungszeichen endet. Der Interpreter versteht also das HTML-Attribut so wie in der letzten Zeile des Listings.

### Originalcode
title="<a href='https://blah'>:verified:</a>"
### Ersetzung
title="<a href='https://blah'><img draggable="false" ... ></a>"
### Interpretiertes Resultat
title="<a href='https://blah'><img draggable="

Jeglicher nachfolgende HTML-Code wird dann als nicht mehr zum »title«-Attribut gehörend interpretiert. Hier kann der Angreifer seinen eigenen Code einfügen, den der Interpreter dann ausführt. Allerdings kann das kein beliebiger Code sein: Das verhindert die Content Security Policy (CSP) der Webseite. Sie sorgt dafür, dass keine Inhalte von außerhalb der Domain geladen werden können.

Trotzdem ermöglicht die Attacke es Angreifern, unter Verwendung von iFrames an die Passwörter von Anwendern zu gelangen. Dazu erzeugt der Schadcode über iFrames ein Passwortformular, das dann der Webbrowser via Autofill automatisch ausfüllt. Zusätzlich kann der Angreifer noch eine Toolbar in den HTML-Injection-Code einfügen, die die Passwörter seinen Server schickt.

Das beschriebene Angriffsszenario betrifft laut Entwicklern lediglich den Glitch-Fork von Mastodon. Der Mastodon-Programmcode dieses Forks wurde kürzlich entsprechend korrigiert. (jcb)