RemotePotato0: Privilege Escalation-Schwachstelle im Windows RPC Protocol

Windows[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.


Anzeige

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.

RemotePotato0-Schwachstelle in Windows

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.

RemotePotato0-Schwachstelle in Windows


Anzeige

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


Anzeige

Dieser Beitrag wurde unter Sicherheit, Windows abgelegt und mit , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

20 Antworten zu RemotePotato0: Privilege Escalation-Schwachstelle im Windows RPC Protocol

  1. MOM20xx sagt:

    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.

    • Manuhiri sagt:

      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

    • GPBurth sagt:

      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)

  2. 1ST1 sagt:

    Ja, schick, gleich wieder das Proof of Concept mit Sourcecode veröffentlicht… Diese Genies!

  3. Robert Richter sagt:

    Werden die Dinger jetzt im 24h Takt veröffentlicht, inclusive PoC ?

    • Günter Born sagt:

      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.

      • Robert Richter sagt:

        Wäre interessant, ob und wie MS JETZT darauf reagiert…

        • Günter Born sagt:

          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…

          • Christian sagt:

            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?

  4. Garfield sagt:

    Gibt es eigentlich IRGENDEINE Funktionalität in Windows, die MS sicherheitstechnisch nicht völlig vergeigt?

  5. Oliver L sagt:

    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.

  6. Markus sagt:

    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.

    • Robert Richter sagt:

      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.

  7. Stefan A. sagt:

    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…

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.

Du findest den Blog gut, hast aber Werbung geblockt? Du kannst diesen Blog auch durch eine Spende unterstützen.