Translated message

A translation of this page exists in English.

Badlock: Attacco man-in-the-middle ai protocolli SAMR e LSA in Samba (CVE-2016-2118)

Red Hat Product Security è venuta a conoscenza di una vulnerabilità relativa ai protocolli LSA e SAMR basati su DCE/RPC usati nell'infrastruttura Microsoft Windows Active Directory. Alla suddetta vulnerabilità è stata assegnata un CVE-2016-2118

Nota bene: Questo è un problema relativo al protocollo e interessa tutte le applicazioni relative, incluso Samba CVE-2016-2118 e Microsoft Windows - CVE-2016-0128.

Informazioni supplementari

DCE/RPC si riferisce ad un meccanismo di chiamata per una procedura remota in grado di definire il protocollo over-the-network e API. Il protocollo remoto Security Account Manager (SAM) (Client-a-Server) fornisce una funzionalità di gestione per un archivio account o directory contenente gruppi e utenti. Il protocollo espone un "database dell'account" per i domini locali e remoti del Microsoft Active Directory. Il Local Security Authority (Domain Policy) Remote Protocol viene utilizzato per gestire le varie politiche di sicurezza del dominio e della macchina. Questo protocollo, con alcune eccezioni, abilita scenari di gestione della politica remota. I protocolli SAMR e LSA si basano sul protocollo DCE 1.1 RPC.

Questi protocolli sono generalmente disponibili su tutte le installazioni Windows e sui server Samba. Essi vengono utilizzati per gestire il database del Security Account Manager, e interessa tutti i ruoli (per esempio, standalone, controller di dominio o membro del dominio).

Descrizione e impatto

Qualsiasi connessione DCE/RPC autenticata che un client inizializza con un server potrà essere utilizzata da un aggressore di tipo man-in-the-middle, e agire come un utente autenticato con il servizio SAMR o LSA sul server. Così facendo l'aggressore sarà in grado di accedere in modalità lettura/scrittura al database del Security Account Manager, e ottenere tutte le password e qualsiasi altra informazione riservata.

Non ha importanza il tipo di protocollo dell'applicazione scelto dal client, il tipo di autenticazione (per esempio Kerberos o NTLMSSP), o il livello di autenticazione (NONE, CONNECT, SIGN, o SEAL). Un attacco di tipo man-in-the-middle è in grado di ridurre il livello di autenticazione a CONNECT e prendere il controllo della connessione.

Tutte le versioni dei pacchetti di Samba disponibili con Red Hat Enterprise Linux server e Red Hat Gluster Storage sono interessati a questo tipo di vulnerabilità. Red Hat Product Security ha classificato questa vulnerabilità con un impatto sulla sicurezza Importante.

Configurazioni interessate

  • Una infrastruttura dell'Active Directory con un server Samba come membro del dominio è vulnerabile a questo tipo di falla. Un aggressore di tipo man-in-the-middle è in grado di intercettare il traffico DCE/RPC tra il membro del dominio e il controllore del dominio, comportandosi come client e ottenendo così gli stessi privilegi di un account utente autenticato. L'aggressore potrà visualizzare o modificare informazioni riservate presenti all'iterno di un database dell'AD, incluso la cifratura della password o arrestare servizi critici.

  • Qualsiasi server Samba configurato come un file o server di stampa è vulnerabile a questo tipo di falla. Un aggressore potrà sfruttare questa vulnerabilità per modificare i permessi dell'utente sui file e sulle directory.

Come attenuare i rischi

Per ridurre i rischi, non utilizzare account privilegiati per accedere ai servizi SMB/CIFS fino a quando non sia stato implementato un pacchetto con la correzione. Limitare l'accesso amministrativo all'hardware fisico (console, server), così facendo l'autenticazione non avrà bisogno di comunicare con la rete.

Risoluzione

Prodotto Componente Advisory
Red Hat Enterprise Linux 5 samba (3.0) RHSA-2016:0621
Red Hat Enterprise Linux 5 samba3x (3.6) RHSA-2016:0613
Red Hat Enterprise Linux 6 samba (3.6) RHSA-2016:0611
Red Hat Enterprise Linux 6 samba4 (4.2) RHSA-2016:0612
Red Hat Enterprise Linux 7 samba (4.2) RHSA-2016:0612
Red Hat Gluster Storage 3 (EL6) samba (4.2) RHSA-2016:0306
Red Hat Gluster Storage 3 (EL7) samba (4.2) RHSA-2016:0306

Riconoscimenti

Red Hat desidera ringraziare il progetto Samba per aver segnalato questo problema. Upstream riconosce Stefan Metzmacher di (SerNet), come la persona che ha segnalato per primo questa vulnerabilità.

Note aggiuntive

Questo aggiornamento introduce una nuova opzione in smb.conf, documentata:

  allow dcerpc auth level connect (G)

Questa opzione controlla se i servizi DCE/RPC possono essere utilizzati con
DCERPC_AUTH_LEVEL_CONNECT, la quale fornisce una autenticazione ma nessuna integrità del messaggio (SIGN) o protezione della privacy (SEAL).

Alcune interfacce come samr, lsarpc, e netlogon hanno una impostazione predefinita protetta
su no; epmapper, mgmt, e rpcecho presentano una impostazione predefinita protetta su yes.

Il comportamento può essere modificato in base al nome dell'interfaccia (per esempio, lsarpc
netlogon, samr, srvsvc, winreg o wkssvc) specificando
    'allow dcerpc auth level connect:interface = yes'.

Questa opzione ha precedenza su qualsiasi limitazione specifica al tipo di implementazione. Per
    esempio:
 * I protocolli drsuapi e backupkey necessitano di DCERPC_AUTH_LEVEL_PRIVACY.
 * Il protocollo dnsserver necessita di DCERPC_AUTH_LEVEL_INTEGRITY.

    Default: allow dcerpc auth level connect = no
    Esempio: allow dcerpc auth level connect = yes

Domande frequenti

Devo applicare il patch sia sui client che sui server Samba nella mia infrastruttura?

È consigliato aggiornare almeno i server Samba. Poichè Badlock è una falla che riguarda il protocollo, in base alla configurazione dell'infrastruttura di Samba, sia i server che i client possono essere interessati a questa vulnerabilità. Red Hat Product Security consiglia ai propri utenti di aggiornare sia i client che i server.

I patch aggiornati possono danneggiare i miei client esistenti con versioni più vecchie di Samba?

Questa security advisory limita alcune delle opzioni di sicurezza usate per configurare Samba. Ciò può impattare negativamente sulle configurazioni quando un server Samba viene aggiornato senza aggiornare il client. È possibile implementare le opzioni più vecchie e meno sicure per continuare ad avere una certa interoperabilità (per esempio impostando allow dcerpc auth level connect = yes nel file smb.conf), tuttavia Red Hat Product Security consiglia vivamente di non eseguire questa operazione poichè, così facendo, è possibile esporsi nuovamente ad alcuni degli attacchi precedentemente corretti.

Le mie istanze del server Samba non sono collegate ad alcun Dominio Windows, questa vulnerabilità mi può ancora riguardare?

Si poichè se un utente amministrativo comunica con un server Samba usando un client non-sicuro, o utilizza un client sicuro per comunicare con un server Samba non sicuro, un aggressore di tipo man-in-the-middle sarà in grado di sfruttare questo tipo di vulnerabilità.

Ho aggiornato i miei server e client Samba, devo aggiornare qualcos'altro?

No, dopo aver aggiornato il sistema il servizio smb verrà riavviato automaticamente.

La cifratura è in grado di proteggermi da questo attacco MITM?

Per impostazione predefinita il protocollo SMB cifra solo le credenziali e i comandi, mentre il trasferimento dei file avviene in testo semplice. Per proteggere tutte le comunicazioni è consigliato utilizzare un sistema di cifratura ogni qualvolta si è in presenza di informazioni riservate. La cifratura è stata introdotta con la versione 3.2 di Samba, ma solo per i client di Samba. Microsoft ha implementato il supporto per la cifratura SMB per SMB 3.0 in Windows 8 e Windows Server 2012. Tuttavia questi due tipi di cifratura proteggono solo le comunicazioni, come ad esempio il trasferimento dei file, dopo aver completato i comandi e la negoziazione SMB. Questa è la fase più delicata durante la quale è possibile sfruttare la vulnerabilità sopra indicata. La cifratura Samba/SMB è un buon inizio ma non è sufficiente per una protezione contro questo tipo di vulnerabilità.

Riferimenti

http://badlock.org/

Comments