Una catena di vulnerabilita in FreeIPA e 389 Directory Server puo consentire a un client anonimo di creare credenziali amministrative riutilizzabili in un dominio Linux. FreeIPA e spesso usato come soluzione di Identity Management per controllare chi puo autenticarsi e quali privilegi possiede, appoggiandosi a un database LDAP gestito da 389 Directory Server.
In scenari di installazione predefinita, un attaccante che non ha mai effettuato login potrebbe riuscire a inserire nel directory una identita Kerberos scelta a piacere e farla risultare membro del gruppo administrators, ottenendo cosi privilegi elevati.
Origine del problema: ACI di FreeIPA
Il punto di partenza e una regola di controllo accessi di FreeIPA, una ACI pensata per permettere agli utenti di gestire il proprio token one time password. Il problema e che questa regola non richiede che il client sia autenticato e non limita in modo stretto quali altri attributi possano essere scritti insieme al token. Da sola questa condizione sarebbe meno critica, ma diventa pericolosa quando si combina con un difetto nel motore di access control di 389 Directory Server.
Combinazione con il difetto in 389 Directory Server
In particolare, 389 Directory Server supporta una tipologia di regola che dovrebbe consentire modifiche solo al proprietario autenticato di una entry. Il confronto tra il nome del client e un valore memorizzato avviene come semplice testo e, se il client non e autenticato, il suo nome risulta vuoto. Se anche il campo ownership nella entry e vuoto, il controllo puo essere superato, permettendo a un client anonimo di scrivere attributi sensibili. In questa catena, l attaccante puo creare una entry di token con campi di proprieta lasciati vuoti, superare il controllo come utente nessuno e aggiungere identita Kerberos e password, arrivando a credenziali con potenziale accesso amministrativo.
Correzioni e mitigazioni
La correzione lato FreeIPA e disponibile nella versione 4.13.4, mentre le patch per 389 Directory Server vengono distribuite tramite aggiornamenti specifici delle piattaforme. In attesa di aggiornamenti completi, misure di mitigazione efficaci includono:
- Restrizione dell accesso al servizio LDAP: consentire l accesso solo a host fidati tramite firewall o segmentazione di rete.
- Disabilitazione dei bind LDAP anonimi: verificando prima eventuali dipendenze applicative.
- Verifiche in ambienti container: controllare che password iniziali non restino esposte come variabili di ambiente del processo.