La sicurezza in Mastodon, tra configurazioni errate e bug di gestione degli utenti

Le ultime settimane, segnate per lo più da azioni e Tweet controversi di Elon Musk (dopo il suo acquisto di Twitter), hanno visto una crescita esponenziale delle istanze Mastodon, gestite individualmente e volontariamente dai singoli amministratori che vogliono contribuire alla crescita del Fediverso. Anche inSicurezzaDigitale ha la sua istanza: mastodon.insicurezzadigitale.com

All’aumento del traffico, aumenta anche l’interesse della comunità infosec sull’argomento. In effetti sempre più esperti utilizzano la piattaforma e ne ricercano problemi al fine di migliorare l’ecosistema del social network open source.

Configurazioni errate del server portano a facili compromissioni

Non è una novità, ma forse è meglio sottolinearlo, visto che l’esperto di sicurezza Lenin Alevski, ha indagato la vicenda e scoperto che il problema è parecchio diffuso.

Da sempre un server esposto in Rete è soggetto a controlli che possono arrivare da diversi fronti, i più preoccupanti sono ovviamente quelli malevoli. Se la configurazione del server non rispetta neppure gli standard minimi di sicurezza è quasi implicito avere dei problemi con attacchi che la piattaforma ospitata possa ricevere.

Quello che è stato scoperto è che l’istanza infosec.exchange di Mastodon (molto nota) carica i propri contenuti in bucket di archiviazione senza alcun vincolo di accesso. Sfruttando questa vulnerabilità, il ricercatore è stato in grado di sostituire l’immagine del profilo di tutti gli utenti con un meme archiviato nell’istanza infosec.exchange.

Una breve occhiata al codice sorgente della pagina indica che https://media.infosec.exchange/infosecmedia è la sorgente dei dati. Sembra una risposta XML di AWS S3 e la risposta del server dice anche “minio” per indicare che MinIO è in uso. MinIO è un applicativo compatibile con Amazon AWS S3 e permette lo storage mediante API.

In definitiva, con l’occasione si scopre che i bucket non hanno alcun tipo di autenticazione per l’accesso e tutti i contenuti non sono bloccati al pubblico, quindi accessibili e facilmente reperibili con qualsiasi client MinIO.

Inoltre la disattivazione del blocco degli accessi pubblici di AWS S3, interessava anche i permessi in scrittura, infatti qualsiasi attore delle minacce può (in questo caso) ottenere tutti i file sul server sfruttando questa “vulnerabilità”, compresi quelli scambiati tramite messaggi diretti, eliminare tutti i file del server e anche possibile modificare l’immagine del profilo di tutti.

Grazie a questa ricerca e segnalazione, l’istanza ha potuto correggere il problema, tuttavia Alevski ha constatato e segnalato la stessa errata configurazione ad altre istanze Mastodon, ricercando tra le più popolari nel Fediverso.

A titolo esemplificativo, una configurazione di un bucket AWS S3, che deve ospitare dati degli utenti Mastodon, deve specificare il seguente dettaglio nel tab Autorizzazioni delle informazioni del bucket:

Due bug nella gestione degli utenti

Diversa natura sono invece i problemi riscontrati su altre istanze, nostra compresa, per la quale risoluzione, dipende meno l’amministratore dell’istanza e più lo sviluppo del progetto Mastodon. Sono infatti considerati bug aperti e non ancora risolti.

Il caso del reset password utenti LDAP non-LDAP

Il problema principale su Github si chiama #20655 (https://github.com/mastodon/mastodon/issues/20655) ed è un bug della piattaforma che non consente, agli utenti che si registrano ed autenticano su un’istanza che utilizza sistemi esterni di autenticazione, di modificare la propria password, resettarla o eliminare il proprio account.

Questo problema è grosso, soprattutto per il fatto che impatta sulle istanze che implementano buone pratiche di sicurezza informatica.

Utilizzare infatti un sistema terzo di autenticazione (supportato dalla piattaforma), in questo caso LDAP, circoscritto al container che fa il deployer dell’applicazione Mastodon, è una buona pratica di sicurezza. Visto che normalmente i dati degli utenti sarebbero invece parte del server che ospita l’istanza.

Questa interoperabilità che Mastodon offre, per autenticazione di terze parti, non è completa e produce i non semplici disservizi appena elencati.

Se un utente dimentica la password e fa la procedura di reset, la piattaforma invierà correttamente l’email con il link di conferma, ma il token non sarà in grado di completare la richiesta per comunicare a LDAP la password nuova dell’utente esterno (quindi non-LDAP di sistema, ma LDAP di container).

“You are logged in via an external service, so password and e-mail settings are not available”, questa la dicitura che Mastodon restituisce.

Il problema era noto già da maggio 2020, ma è stato chiuso senza approfondimenti optando per la disabilitazione di LDAP e mantenere l’autenticazione interna come unico modo di gestione degli utenti.

Mentre invece il 14 novembre 2022, con l’apertura del track #20655 si è avanzata l’ipotesi di correzione pratica di questa problematica che, evidenzio, è insita nella funzione use_seamless_external_login, in questo punto del codice di Mastodon.

Diversi amministratori di istanze stanno impattando contro questo bug, sperando in una possibile correzione a livello di sviluppo.

Il caso della validazione degli utenti LDAP

Il secondo che invece voglio segnalare, ha sempre a che fare con l’autenticazione esterna di Mastodon, quando LDAP è attivo. Si chiama #12020 ed è conosciuto dal 30 settembre 2019, senza mai esser stato ancora chiuso.

In sostanza Mastodon permette, in tutti i casi, anche quando l’autenticazione esterna è abilitata, di creare utenti con diversi caratteri, maiuscole e minuscole, punti all’interno dell’handle. Questi caratteri però, che non creano problemi con l’autenticazione interna, non sono compatibili con LDAP, quindi quando un utente, impossibilitato a resettare la propria password, viene forzato su LDAP, ma presenta anche una maiuscola nel proprio UID (o anche qualcosa come firstname.lastname), l’autenticazione, con la password correttamente impostata su LDAP, non funzionerà e non produrrà nemmeno un errore lato utente, semplicemente una risposta (pagina bianca) HTTP ERROR 422.

Andando poi a spulciare i log dell’istanza Mastodon, troviamo che l’errore viene registrato:

ActiveRecord::RecordInvalid (Validation failed: Account username only letters, numbers and underscores):

Capirete bene che, questo bug, associato al primo che rende impossibile il reset password, creano una bomba esplosiva non da poco.

La soluzione, per ora

Personalmente non ho trovato ancora una soluzione indolore a queste due problematiche sull’autenticazione Mastodon con LDAP attivo e autenticazione esterna attiva. I due bug non sono infatti risolti e l’unica soluzione “artigianale” che mi viene in mente è molto drastica.

Consisterebbe nel radere al suolo la base utenti dell’istanza configurata con autenticazione esterna, installare nuovamente l’istanza con configurazione di autenticazione interna e invitare i vecchi utenti a registrare nuovamente la propria presenza nella nuova istanza.

La vicenda è da seguire per eventuali soluzioni meno tragiche da riportare.