Badlock: SAMR und LSA Protokoll Man-in-the-Middle Angriff auf Samba (CVE-2016-2118)

Red Hat Product Security wurde auf einen Protokollfehler in DCE/RPC-basierten SAMR und LSA Protokollen hingewiesen, die in der Microsoft Windows Active Directory Infrastruktur verwendet werden. Dieses Problem wurde zugewiesen CVE-2016-2118

Hinweis: Dies ist ein Protokollfehler und betrifft alle Anwendungen, die dieses Protokoll implementieren, einschließlich Samba- CVE-2016-2118 und Microsoft Windows - CVE-2016-0128.

Hintergrundinformationen

DCE/RPC ist die Spezifikation für einen Remote-Procedure Call Mechanismus, der sowohl APIs als auch ein Protokoll über das Netzwerk definiert. Das entfernte Protokoll Security Account Manager (SAM) (Client-an-Server) bietet Verwaltungs-Funktionen für einen Account-Speicher oder ein Verzeichnis, das Benutzer oder Gruppen enthält. Das Protokoll exponiert die "Account-Datenbank" sowohl für lokale als auch für entfernte Microsoft Active Directory Domains. Das entfernte Protokoll Local Security Authority (Domain-Richtlinie) wird verwendet, um verschiedene Sicherheitsrichtlinien von Rechner und Domain zu verwalten. Mit wenigen Ausnahmen ermöglicht dieses Protokoll Szenarien entfernter Richtlinien-Verwaltung. Sowohl SAMR als auch LSA Protokolle basieren auf dem DCE 1.1 RPC Protokoll.

Diese Protokolle sind gewöhnlich für alle Windows Installationen sowie für alle Samba Server verfügbar. Sie werden verwendet, um die Datenbank des Security Account Managers zu verwalten. Dies gilt für alle Rollen (beispielsweise Standalone, Domain-Controller oder Domain-Mitglied).

Beschreibung und Auswirkung des Angriffs

Jede authentifizierte DCE/RPC Verbindung, die ein Client an einen Server öffnet, könnte von einem Man-in-the-Middle Angreifer verwendet werden, um die Identität eines authentifizierten Benutzers gegen den SAMR oder LSA Dienst auf dem Server anzunehmen. Auf diese Art würde der Angreifer Lese- und Schreibzugriff auf die Datenbank des Security Account Managers erlangen, wodurch möglicherweise alle Passwörter und weitere sensiblen Informationen offengelegt werden könnten.

Das vom Client ausgewählte Anwendungsprotokoll, Authentifizierungstyp (beispielsweise Kerberos oder NTLMSSP), und Authentifizierungsebene (NONE, CONNECT, SIGN, oder SEAL) sind in diesem Fall unbedeutend. Ein Man-in-the-Middle Angreifer könnte die Authentifizierungsebene auf CONNECT herabstufen und die Kontrolle über die Verbindung erlangen.

Alle Versionen von Samba-Paketen, die mit dem Red Hat Enterprise Linux Server und Red Hat Gluster Storage geliefert werden, sind von diesem Fehler betroffen. Red Hat Product Security hat dieses Problem als Sicherheitsauswirkung Wichtig beurteilt.

Betroffene Konfigurationen

• Eine Active Directory Infrastruktur mit einem Samba Server als Doamain-Mitglied ist anfällig für diesen Fehler. Ein Man-in-the-Middle Angreifer könnte DCE/RPC Datenverkehr zwischen dem Domain-Mitglied und dem Domain-Controller abfangen um die Identität des Clients anzunehmen und dieselben Berechtigungen zu erlangen wie der authentifizierte Benutzer-Account. Der Angreifer könnte geheime Daten in einer AD Datenbank einsehen oder modifizieren, einschließlich Benutzer-Passwort-Hashes oder kritische Dienste herunterfahren.

• Jeder Samba Server, der als Datei- oder Druckserver konfiguriert ist, ist auch anfällig für diesen Fehler. Der Angreifer könnte diesen Fehler ausnutzen, um die Benutzer-Berechtigungen von Dateien oder Verzeichnissen zu modifizieren.

Vorbeugung

Das Risiko kann reduziert werden, indem beim Zugriff auf SMB/CIFS Dienste keine privilegierten Accounts benutzt werden, bis ein Paket zur Fehlerbehebung angewendet wurde. Begrenzen Sie administrativen Zugriff auf physische Hardware (Konsole, Server), damit die Authentifizierung keine Netzwerkkommunikation benötigt.

Lösung

Danksagung

Red Hat möchte dem Samba Projekt für die Meldung dieses Problems danken. Upstream erkennt Stefan Metzmacher (SerNet) als ursprünglichen Berichterstatter an.

Weitere Anmerkungen

Das Sicherheits-Update für diesen Fehler führt eine neue Option ein insmb.conf, die dokumentiert ist als:

  allow dcerpc auth level connect (G)

    Diese Option steuert, ob DCERPC Dienste mit 
    DCERPC_AUTH_LEVEL_CONNECT verwendet werden können, was Authentifizierung bereitstellt, nicht aber Integrität pro-Nachricht (SIGN) oder Datenschutz (SEAL).

    Manche Schnittstellen wie samr, lsarpc und netlogon haben den hartkodierten 
    Standard Nein; epmapper, mgmt und rpcecho haben den hartkodierten Standard Ja.

    Das Verhalten kann überschrieben werden durch den Schnittstellennamen (beispielsweise lsarpc,
    netlogon, samr, srvsvc, winreg, or wkssvc) durch die Angabe von 
    'allow dcerpc auth level connect:interface = yes'.

    Diese Option erteilt Vorrang vor allen Implementations-spezifischen Beschränkungen. 
    Beispielsweise:
    * Die drsuapi und backupkey Protokolle erfordern DCERPC_AUTH_LEVEL_PRIVACY.
    * Das dnsserver Protokoll erfordert DCERPC_AUTH_LEVEL_INTEGRITY.

    Standard: allow dcerpc auth level connect = no
    Beispiel: allow dcerpc auth level connect = yes

Häufig gestellte Fragen

Muss ich sowohl die Samba Server, als auch die Samba Clients in meiner Infrastruktur aktualisieren?

Wenigstens Samba Server sollten aktualisiert werden. Da Badlock ein Protokollfehler ist, können je nach Konfiguration der Samba-Infrastruktur sowohl die Server als auch die Clients betroffen sein. Red Hat Product Security empfiehlt den Kunden sowohl Server als auch Clients zu aktualisieren.

Beeinträchtigen die aktualisierten Pakete meine vorhandenen Clients, die ältere Versionen von Samba betreiben?

Diese Sicherheitsempfehlung verschärft einige Sicherheitsoptionen, die zur Konfiguration von Samba verwendet werden. Dies kann einer Konfiguration schaden, wenn ein Samba Server aktualisiert wird, der Client jedoch nicht. Es ist möglich zu früheren, unsichereren Optionen zurückzukehren, damit die Interoperatibiltät weiterhin möglich ist (zum Beispiel durch die Einstellung allow dcerpc auth level connect = yesin der smb.conf Datei), aber Red Hat Product Security empfiehlt nachdrücklich, das nicht zu tun, da damit auch einige Angriffsvektoren wieder eingeführt werden.

Meine Samba Server Instanzen sind nicht mit Windows Domains verbunden, bin ich dennoch angreifbar?

Ja, wenn ein Admin-Benutzer mit einem Samba Server über einen nicht-sicheren Client kommuniziert oder er einen sicheren Client benutzt um mit einem unsicheren Samba Server zu kommunizieren, könnte ein Man-in-the-Middle Angreifer die Schwachstelle auf diese Art möglicherweise ausnutzen.

Ich habe meine Samba Server und Clients aktualisiert, muss irgendetwas neu gestartet werden?

Nein, wenn das Update auf Ihrem System angewendet wurde, wird dersmb Dienst automatisch neu gestartet.

Schützt Verschlüsselung vor diesem MITM Angriff?

Das SMB Protokoll entschlüsselt standardmäßig nur Anmeldeinformationen und Befehle, während Dateien in einfachem Text übertragen werden. Es wird empfohlen, dass in sicherheitsrelevanten und vertraulichen Szenarien Verschlüsselung verwendet wird, um alle Kommunikationen zu schützen. Verschlüsselung wurde in Samba in Version 3.2 hinzugefügt, aber nur für Samba Clients. Microsoft hat Support für SMB Verschlüsselung zu SMB 3.0 in Windows 8 und Windows Server 2012 hinzugefügt. Dennoch schützen beide Verschlüsselungs-Typen nur Kommunikationen wie Dateiübertragungen, nachdem SMB-Verhandlung und Befehle abgeschlossen wurden. Diese Phase enthält die oben hervorgehobene Schwachstelle. Samba/SMB Verschlüsselung ist eine gute Übung, aber kein ausreichender Schutz vor dieser Schwachstelle.

Verweise

http://badlock.org/