Authentifizierung erzwingen. Was ist das und wie schützt man sich? / Sudo Null IT-Nachrichten

In diesem Artikel erfahren Angreifer, dass Zwang auf mehr als nur Port 445/tcp durchgeführt werden kann, und Verteidiger erfahren, wie Authentifizierungszwang sicher deaktiviert werden kann.

Inhalt

0.0 Einführung
1.0 Authentifizierungsdurchsetzungstechniken
1.1 Authentifizierung erzwingen -> SMB (NTLM)
1.2 Authentifizierung erzwingen -> SMB (Kerberos)
1.3 Authentifizierung erzwingen -> HTTP (NTLM)

2.0 Beispiele für schlechte Verteidigung
2.1 Schließen Sie den 445/tcp-Port
2.2 Umgehen Sie den geschlossenen 445/tcp-Port
2.3 Schließen Sie den 139/tcp-Port
2.4 Umgehung der Ports 445/tcp und 139/tcp geschlossen
2.5 Schließen Sie den 135/tcp-Port
2.6 Bypass geschlossen Ports 445/tcp, 139/tcp und 135/tcp
2.7 Spooler deaktivieren
2.8 Den deaktivierten Spooler umgehen

3.0 SCHUTZ (true way)
3.1 NETSH-RPC-Filter
3.2 Sicherheitstests

0.Intro

Authentication Coercion oder Coerce in englischen Quellen ist eine Funktion von Windows-Systemen, die jetzt recht aktiv bei einer Reihe von Angriffen auf die Active Directory-Infrastruktur eingesetzt wird. So werden Angriffe mit seiner Hilfe umgesetzt:

  • ADCS ESC8 (Schwachstelle)

  • Missbrauch der Kerberos-Delegierung (Fehlkonfiguration)

  • LDAP-Missbrauch (Fehlkonfiguration)

  • diverser ACL-Missbrauch (Fehlkonfiguration)

  • Verfügbarkeit von Computerkonten in lokalen Administratoren explizit oder über Gruppen (Fehlkonfiguration)

  • und vieles mehr.

All diese schrecklichen Worte führen oft sofort zur Erfassung von Domänencontrollern und damit fast der gesamten internen Infrastruktur …

Die Authentifizierungserzwingung liegt in einer Reihe von RPC-Funktionen, die jeder Benutzer (Nicht-Administrator) remote aufrufen kann. In einer Active Directory-Umgebung ist jedes Domänenkonto ein Benutzer in Bezug auf jeden Computer. Dadurch befinden sich alle Hosts in einer gegenseitig vertrauensvollen Beziehung, und jeder und auf jedem Knoten kann solche RPC-Funktionen aufrufen. Das Verhalten dieser Funktionen besteht darin, dass versucht wird, über das SMB- oder HTTP-Protokoll mittels WebDAV auf ein Netzlaufwerk zuzugreifen. Und ein solcher Aufruf erfolgt über die Pass-Through-Authentifizierung und das unbewusste Senden eines Passwort-Hashs in Form von NetNTLM oder eines Kerberos-Tickets. Die Authentifizierung erfolgt in diesem Fall immer unter einem Computerkonto. Darüber hinaus kann der Hash je nach implementiertem Angriff in einem Relay-Angriff und einer Authentifizierungsumgehung wiederverwendet werden, oder es wird ein TGT-Ticket abgerufen. Das Thema Relay-Angriffe ist recht umfangreich und geht nicht in den Rahmen dieses Artikels, mehr darüber können Sie z.B. im Internet nachlesen, hier.

Kurz gesagt, dank der Technik der erzwungenen Authentifizierung können wir rechtmäßig jeden Computer auffordern, sich bei jedem anderen Computer zu authentifizieren. Darüber hinaus können wir jeden Computer auffordern, sich auf unserem Computer zu authentifizieren und seine Authentifizierung auf einen dritten Computer umzuleiten.

Und das Problem ist, dass Microsoft sich geweigert hat, dieses „Feature“ als Schwachstelle anzuerkennen. Und für den Angreifer eröffnen solche Tricks beachtliche Perspektiven.

1.0 Authentifizierungsdurchsetzungstechniken

Derzeit gibt es 4 verschiedene Techniken, um die Authentifizierung zu erzwingen:

Protokoll

SMB-Rohre

SMB-Schnittstellen

Funktionen

Ausbeuten

MS_RPRN

\pipe\spulen

12345678-1234-ABCD-EF00-0123456789AB

opnum=1 RpcOpenPrinter(*pPrinterName, *pDatatype, pDevModeContainer, AccessRequired)

Druckerfehler

MS_EFSR

\PIPE\lsarpc, \PIPE\samr, \PIPE\lsass, \PIPE\netlogon, \PIPE\efsrpc

c681d488-d850-11d0-8c52-00c04fd90f7e, df1941c5-fe89-4e79-bf10-463657acf44d

opnum=0 – EfsRpcOpenFileRaw(*Dateiname, Flag),

Petit Potam

MS_DFSNM

\PIPE\netdfs

4fc742e0-4a10-11cf-8273-00aa004ae673

opnum=13 NetrDfsRemoveStdRoot(*ServerName, *RootShare, ApiFlags),

dfscoerce

MS_FSRVP

\PIPE\FssagentRpc

a8e0653c-2744-4389-a61d-7373df8b2292

opnum=8 IsPathSupported(*ShareName), opnum=9 IsPathShadowCopied(*ShareName),

….

Schattenzwang

Jede der vorgestellten RPC-Funktionen nimmt in einem der Parameter einen vollständigen Pfad der Form “\\IP\Share\path\to\something” an, wodurch Sie den Remote-Host (UNC) angeben können, auf dem die umgekehrte Verbindung hergestellt wird . In Wirklichkeit ist die Liste der RPC-Funktionen, die einen UNC-Pfad akzeptieren, breiter als in Exploits verwendet wird, aber ihre Erwähnung ist immer noch im Code zu sehen.

Je nachdem, wie das Ziel für die Rückwärtsverbindung eingestellt ist, sind 3 verschiedene Verhaltensweisen möglich.

1.1 Authentifizierung erzwingen -> SMB (NTLM)

Wenn die umgekehrte Verbindungsadresse als IP angegeben ist, wird die Verbindung zu einem Netzlaufwerk mit dem SMB-Protokoll unter Verwendung von NTLM hergestellt:

Hier und unten ist 10.0.0.1 der Angreifer, 10.0.0.10 das Ziel des Angriffs.Hier und unten ist 10.0.0.1 der Angreifer, 10.0.0.10 das Ziel des Angriffs.

Die Authentifizierung bei SMB ist in der Regel entweder der Zugriff auf Netzlaufwerke oder die sofortige Kompromittierung des Systems, da. Mit den entsprechenden Rechten kann der Angreifer Dienste über MSRPC starten, das unter SMB ausgeführt wird.

1.2 Authentifizierung erzwingen -> SMB (Kerberos)

Wird die Reverse-Connection-Adresse in Form eines vollqualifizierten Domänennamens (FQDN) angegeben, erfolgt die Verbindung zu einem Netzlaufwerk ebenfalls über das SMB-Protokoll, jedoch unter Verwendung des Kerberos-Authentifizierungsprotokolls:

target.ussc.ru - Knoten mit unbegrenzter Kerberos-Delegierungtarget.ussc.ru – Knoten mit unbegrenzter Kerberos-Delegierung

Diese Authentifizierung ermöglicht es Ihnen, ein TGT-Ticket aus dem Datenverkehr von einem Host zu erfassen, der sich auf einem Knoten mit unbegrenzter Delegierung authentifiziert. Dies ist fast gleichbedeutend damit, ein Passwort von einem Konto zu erhalten.

1.3 Authentifizierung erzwingen -> HTTP (NTLM)

Alle Arbeiten an MSRPC finden über Pipes statt, und eine vollständige Liste aller Pipes kann oft über SMB von einer “Art” Netzlaufwerk IPC$ bezogen werden:

Das Vorhandensein der „DAV RPC“-Pipe bedeutet, dass der WebClient-Dienst ausgeführt wird, wodurch Windows Explorer beginnt, mit dem Web wie mit Ordnern zu arbeiten. Aber diese Bequemlichkeit verbirgt eine große Gefahr, denn Jetzt kann ein Angreifer einen solchen Host dazu zwingen, sich über HTTP zu authentifizieren. Damit die Rückverbindung über das HTTP-Protokoll erfolgt, muss dessen Adresse in Form eines abgekürzten Domainnamens (ohne Suffix) wie im Screenshot angegeben werden:

Die Authentifizierung mit HTTP kann fast überall hin umgeleitet werden, wo NTLM unterstützt wird, insbesondere zu LDAP, wo ein Angreifer mit Rechten eine Menge tun kann. Aber das ist eine ganz andere Geschichte (siehe zum Beispiel LDAP-Missbrauch, https://www.thehacker.recipes/ad/movement/ntlm/relay). Bei HTTP wurde die Authentifizierung für die Umgehung jedoch nur an ADCS ESC8 umgeleitet.

Sehen wir uns nun an, wie Endarbeitsplätze und Server davor geschützt werden können, sich zu authentifizieren.

2.0 Beispiele für schlechte Verteidigung

Mal sehen, wie zuverlässig die beliebten Empfehlungen zum Schutz vor erzwungener Authentifizierung sind.

2.1 Schließen Sie den 445/tcp-Port

Eine ziemlich häufige Empfehlung ist, den 445/tcp-Port als Quelle verschiedener Probleme zu blockieren. Trotzdem kann dieser Port aufgrund der gleichen Netzlaufwerke wirklich benötigt werden, und es ist nicht ganz richtig, ihn irgendwie zu schließen.

Lassen Sie uns überprüfen, wie zuverlässig diese Lösung ist:

Auf der Seite des Angreifers:

Ja, der Angriff hat nicht funktioniert.

2.2 Umgehen Sie den geschlossenen 445/tcp-Port

Aber oft kann RPC auf Port 139/tcp (SMB über NetBIOS) verwendet werden. Dazu müssen wir das Ziel nicht über die IP-Adresse, sondern über den NetBIOS-Namen ansprechen:

Als Ergebnis akzeptieren wir die Authentifizierung vom Host:

Der Netzwerkverkehr zeigt deutlich, wie die Verwendung des Ports 445/tcp umgangen wird:

Wir sehen, dass Port 139/tcp auch SMB sein kann.

2.3 Schließen Sie den 139/tcp-Port

Lassen Sie uns den 139/tcp-Port analog schließen:

Jetzt sind beide Ports 445/tcp und 139/tcp, die MSRPC bereitstellen, geschlossen.

2.4 Umgehung der Ports 445/tcp und 139/tcp geschlossen

Selbst wenn Sie sich entscheiden, die Ports 139 und 445 zu schließen, steht DCERPC dem Angreifer weiterhin zur Verfügung:

Viele RPC-Funktionen sind über verschiedene Transporte verfügbar, sowohl über MSRPC (445/tcp) als auch über DCERPC (135/tcp, 4915x/tcp, …):

Mit dem Endpoint Mapper (135/tcp) können wir die Nummer des dynamischen TCP-Ports herausfinden, an dem die benötigte RPC-Funktion verfügbar ist.

2.5 Schließen Sie den 135/tcp-Port

Schließen wir den 135/tcp-Port:

445/tcp, 139/tcp und 135/tcp sind jetzt geschlossen.

2.6 Bypass geschlossen Ports 445/tcp, 139/tcp und 135/tcp

Mit DCERPC-Blockierung ist alles nicht so einfach, weil. Es verwendet einen dynamischen Pool von TCP-Ports. Das Schließen des 135/tcp-Ports ist keine zuverlässige Maßnahme, weil Ein Angreifer kann eine Liste von RPC-Schnittstellen aus einem dynamischen Port-Pool erhalten, indem er sie zuerst mit nmap scannt und dann jede der gefundenen nach der erforderlichen UUID abfragt:

Jetzt rufen wir die RPC-Funktion auf DCERPC auf:

Auf der Seite des Angreifers akzeptieren wir wieder die Authentifizierung:

Wieder umgangenWieder umgangen

Der Traffic-Dump zeigt, dass weder 135 noch 139 noch 445 Ports beteiligt waren. Es wird nur der dynamische DCERPC-Port verwendet, der auf jedem Computer unterschiedlich sein kann.

Es stellt sich heraus, dass das selektive Blockieren von Ports eine sehr unzuverlässige Lösung ist.

2.7 Spooler deaktivieren

Eine andere alte Empfehlung ist, den Spooler dummerweise zu deaktivieren:

2.8 Den deaktivierten Spooler umgehen

Hier ist alles einfach. Wie wir wissen, ist Printerbug bei weitem nicht der einzige Weg für Zwang:

Authentifizierung erneut erfolgreich angefordert:

3.0 SCHUTZ (true way)

Die in Windows integrierte Firewall, auch bekannt als Firewall, hat auch einige Anwendungs-Firewall-Funktionen und weiß nur, wie man RPC filtert.

Wenn wir uns die Tabelle mit gefährlichen RPC-Funktionen ansehen, werden wir feststellen, dass es die gemeinsame UUID ist, die sie vereint.

3.1 NETSH-RPC-Filter

Basierend auf der Empfehlung Benjamin Delpy Sie müssen lediglich diese Befehle für jede RPC-Schnittstelle methodisch eingeben:

Und so weiter für Schnittstellen:

  • 12345678-1234-ABCD-EF00-0123456789AB

  • c681d488-d850-11d0-8c52-00c04fd90f7e

  • df1941c5-fe89-4e79-bf10-463657acf44d

  • 4fc742e0-4a10-11cf-8273-00aa004ae673

  • a8e0653c-2744-4389-a61d-7373df8b2292

3.2 Sicherheitstests

Und jetzt prüfen wir die Verfügbarkeit aller 64 Funktionen auf der blockierten Schnittstelle, von denen eine von printerbug verwendet wird.

Auf MSRPC haben wir vor und nach der Aktivierung der Filterung Folgendes:

Im ersten Fall haben wir rpc_x_bad_stub_data, was in Ordnung ist, weil falsche Funktionsargumente angegeben wurden, und im zweiten, wie erwartet, rpc_s_access_denied.

Für DCERPC ist der Zugriff auf Funktionen auf der Schnittstelle vor und nach Aktivierung der Filterung ähnlich:

Ebenso können Sie die Verfügbarkeit von Schnittstellen für petitpotam, dfscoerce und shadowcoerce prüfen.

Und es ist ganz natürlich, dass die Exploits selbst auch nicht funktionieren:

Und so weiter für dfscoerce und shadowcoerce.

Keine der Methoden zum Erzwingen der Authentifizierung funktioniert jetzt. Der Schutz kann als zuverlässig angesehen werden.

Durch das Deaktivieren von Coerce erhöhen Sie das Sicherheitsniveau von Servern und Workstations in Ihrer unternehmensinternen Infrastruktur und machen potenziellen Angreifern das Leben schwer.

Similar Posts

Leave a Reply

Your email address will not be published.