[English]Jedes Windows-System ist anfällig für eine bestimmte NTLM-Relay-Attacke, die es Angreifern ermöglichen könnte, die Privilegien vom Benutzer zum Domain-Admin zu erweitern. Diese Schwachstelle besitzt den Status „wird nicht behoben“ und war Gegenstand des PetitPotam-Ansatzes, den ich am Wochenende thematisiert hatte. Nun hat Antonio Cocomazzi auf die RemotePotato0 genannte Schwachstelle hingewiesen. Diese verwendet das Windows RPC Protocol für eine Privilegien-Ausweitung.
Das Ganze ist nicht mehr so neu, hat der Sicherheitsforscher bei Sentinel doch bereits im April 2021 auf diese Schwachstelle hingewiesen. Nun hat er auf Github seine RemotePotato0 Cross Session Activation-Tool veröffentlicht, auf das ich über nachfolgenden Tweet gestoßen bin.
Das auf Twitter veröffentlichte GIF demonstriert den Einsatz des Tools. Der Github-Post gibt für mich nicht so viel her, aber die Sentinel-Sicherheitsforscher um Antonio Cocomazzi haben auf Twitter in diesem Tweet auf den separaten Artikel mit weiteren Erläuterungen hingewiesen.
In diesem Artikel erklären die SentinelLabs-Sicherheitsforscher um Antonio Cocomazzi den „Relaying Potatos“ genannten Angriff über das Windows RPC-Protokoll. Die Aussage:
- Jedes Windows-System ist anfällig für eine bestimmte NTLM-Relay-Attacke, die es Angreifern ermöglichen könnte, die Privilegien vom Benutzer zum Domain-Admin zu erweitern.
- Der aktuelle Status dieser Sicherheitslücke ist von Microsoft auf „wird nicht behoben“ gesetzt.
Im Blog-Beitrag skizzieren die Sicherheitsforscher, wie das Windows RPC-Protokoll für einen NTLM-Relay-Angriff missbraucht werden könnte. In Folge kann der Angreifer mit normalen Benutzerrechten seine Privilegien zum Domain-Admin zu erweitern. Im Blog-Beitrag geben die Sicherheitsforscher aber Hinweise, was Administratoren unternehmen können, um diesen Angriffsvektor zu entschärfen.
Ähnliche Artikel:
Windows 10: SAM-Zugriffsrechte ab 1809 nach Upgrade kaputt, Benutzerzugriff möglich
HiveNightmare: Neue Details zur Windows-Schwachstelle CVE-2021-36934
PoC für Windows Print-Spooler-Schwachstelle öffentlich, hohes RCE-Risiko
Windows Print-Spooler Schwachstelle (CVE-2021-1675, PrintNightmare) von MS bestätigt; CISA warnt
0Patch Micropatches für PrintNightmare-Schwachstelle (CVE-2021-34527)
Notfall-Update schließt PrintNightmare-Schwachstelle in Windows (6. Juli 2021)
PrintNightmare-Notfall-Update auch für Windows Server 2012 und 2016 (7. Juli 2021)
Nachlese: Das Chaos-PrintNightmare-Notfall-Update (6./7.Juli 2021)
PrintNightmare: Point-and-Print erlaubt die Installation beliebiger Dateien
PetitPotam-Angriff erlaubt Windows Domain-Übernahme
Microsofts Workaround gegen Windows PetitPotam NTLM-Relay-Angriffe
der fluch der zeit wenn man über jahrzehnte hinweg aus kompatibilitätsgründen was mitzieht. ein sauberer schnitt wär mal ein hit.
da wird in so mancher firma nun der kopf so manches edv entscheiders knallrot sein. möcht nicht wissen wieviele hier noch immer schwerstens veraltete end of life systeme betreiben und dann nichts härten können, weil das ach so wichtige end of life system ansonsten nicht betreibbar ist.
wars vor jahren noch active x, outlook express und der internet explorer. na so kracht einem halt jetzt rpc mit ntlm aufs dach. und anstatt das mal komplett in die rente zu schicken, wird wieder wo irgend eine pseudo sicherheit drüber gelegt.
Ich wäre dafür die deutsche sprache gänzlich vom ballast zu befreien
d mnschn knnn d sgnnnt knsnntnschrft prblmls hn schwrgktn lsn
oder vielleicht so
usl uʇʞƃɹʍɥɔs uɥ slɯlqɹd ʇɟɹɥɔsuʇuusuʞ ʇuuuƃs p uuuʞ uɥɔsuɯ p
es würde ja schon reichen, wenn man *einfach* prüfen könnte, ob (und von wem) das noch benötigt wird. Gerne auch in Form eines einfach einzurichtenden Logs, also Stufe 1: „warne mich“ setzen, ein paar Tage/Wochen/Monate warten, Stufe 2: die gefundenen Systeme patchen, Stufe 3: „alten Krempel abschalten“ aktivieren.
Ich hab mir damals mit dem Versuch, SMB1 abzuschalten, die Finger verbrannt. Klar, inzwischen ist es deaktiviert, aber als es zum erstenmal „nimm besser SMB2/3“ hieß…
(übrigens waren damals die ganzen Linux-basierenden Systeme die Hauptproblemverursacher)
Ja, schick, gleich wieder das Proof of Concept mit Sourcecode veröffentlicht… Diese Genies!
> We went through a lengthy process of responsible disclosure with Microsoft before publishing. Although Microsoft considers the vulnerability an important privilege escalation, it has been classified as “Won’t Fix”.
Cheffe, Microsoft nix schuld!
Naja, sie müssen es trotzdem gleich den Angreifern nicht so leicht wie nur irgendwie möglich machen…
Ja, das wäre wirklich nicht nötig gewesen von Microsoft.
full disclosure is the only real disclosure. schon aergerlich wenn man 1st und foremost verfaechter von closedsource plattformen und mindsets ist.
Werden die Dinger jetzt im 24h Takt veröffentlicht, inclusive PoC ?
Im Moment ist für die Sicherheitsforscher halt günstig, auf das Thema hinzuweisen. Ist ja im April bereits offen gelegt worden. Nur hat es keinen interessiert.
Wäre interessant, ob und wie MS JETZT darauf reagiert…
Gar nicht – haben sie doch kommuniziert – steht im englischen Artikel der Sicherheitsforscher.
JFTR: ich habe vor laaaanger Zeit das MSRC auf die „hübschen“ Nebenwirkungen eines unter Windows 7 mehrfach(!) und wiederholt(!) ausgeführten Kommandos
ICACLS.exe \\.\pipe\* /C
aufmerksam gemacht. Hat dummerweise NICHT geholfen…
Ich habe mir jetzt mehrere Beiträge zu dem Thema durchgelesen und stoße im Grunde immer wieder darauf, dass die Lücke nur auszunutzen ist, wenn explizit ein Domänen-Admin auf dem jeweiligen System interaktiv oder Remote angemeldet ist. Ist das so richtig?
Ich will darauf hinaus, dass in meiner Umgebung im Grunde nur bei Wartungsarbeiten in der Domäne ein Domänen-Admin verwendet wird und dann in der Regel auch nur auf dem DC. Inwieweit ist die Gefahr da, wenn man seine Adminrollen klar trennt?
Gibt es eigentlich IRGENDEINE Funktionalität in Windows, die MS sicherheitstechnisch nicht völlig vergeigt?
Kann es vielleicht sein, dass bei Standardeinstellung von Windows 10 oder anderen unterstützten Server-Versionen das Thema überhaupt nicht relevant ist? Nur genau dann könnte ich die Antwort von Microsoft verstehen, weil das Problem schon längst gefixt wurde.
Das hieße dann aber, dass die Aussage „Jedes Windows-System ist anfällig für eine bestimmte NTLM-Relay-Attacke, …“ schlichtweg falsch wäre.
Wieso nicht den ganzen Relay Kram per Update hart deaktivieren und Anleitung geben, wie man es aktivieren kann, wenn man es denn wirklich braucht? Oder wird diese Relay Funktionalität denn generell benötigt? Ich glaube nicht… ein „Won’t Fix“ ist einfach nur schwach.
Kann mir nicht vorstellen, dass eine „Relay Funktionalität“ beabsichtigt war, noch dazu gebraucht wird, sondern dass dies einfach nur in einem Angriffs-Szenario missbraucht wird. …und MS nicht auf die Idee gekommen ist, dass man SO (auf diese Weise) das System missbrauchen/kompromittieren kann.
Ich habe mich heute einmal mit der Umsetzung der Mitigations befasst, um jetzt festzustellen, dass Microsoft den Artikel umgeändert hat von der Reihenfolge!?!?
Ich gehe davon aus, dass so mancher wohl stur die erste Empfehlung „NTLM in der Domäne abzuschalten“ umgesetzt hat und elendig Schiffbruch damit erlitten hat…
Jetzt habe ich im Eifer unter dem falschen Beitrag kommentiert. Mein Beitrag gehört natürlich zum Thema PetitPotam…