Windows 11: Defender-Bypass mit Ausbruch aus der Sandbox

Windows[English]Es sieht so aus, als ob der Windows Defender durch Schwachstellen ausgehebelt werden kann, so dass Schadprogramme aus der Sandbox ausbrechen und auf das Betriebssystem zugreifen können. Mir ist gerade eine Information unter die Augen gekommen, wo ein Sicherheitsforscher genau dieses Szenario für Windows 11 skizziert.


Anzeige

Der nachfolgende Tweet des Sicherheitsforschers @an0n_r0 enthält nur wenige Informationen, die aber diverse Schlüsse ermöglichen.

Windows 11: Defender bypass

Der Sicherheitsforscher hat sich Windows 11 vorgenommen, um dort die Sicherheit des Windows Defender zu testen. Es geht darum, in einem überprüften Programm per Schadfunktion in der Sandbox, die genau diesen Schadcode isolieren soll, auszubrechen. Im Anschluss gilt es, einen vorher verschlüsselt im Schadcode enthaltenen Shell-Code in den Speichern zu schreiben. Gelingt dies, ist dann noch ein Prozess im supendierten Zustand zu erzeugen, und der im Speicher bereits vorliegenden Shell-Code in den zugewiesenen Speicherbereich zu kopieren.

Sind diese Schritte bewältigt, kann der betreffende Prozess remote angestoßen und der Shell-Code ausgeführt werden. In obigem Tweet zeigen die Screenshots, dass genau diese Schritte geklappt haben und der Shellcode in der Lage ist, Daten aus Windows abzurufen und in einem Eingabefenster anzuzeigen.


Anzeige

Der Meterpeter-Ansatz

Der Sicherheitsforscher nennt keine Details, wie er diese Schritte bewältigt hat, lässt aber die Bemerkung "das funktioniert mit Meterpeter" fallen. Meterpreter ist laut dieser Seite eine Nutzlast für Metasploit-Angriffe, und stellt eine interaktive Shell bereit. Über diese Shell kann ein Angreifer den Zielcomputer erkunden und Code ausführen kann. Meterpreter wird mittels In-Memory-DLL-Injection bereitgestellt und der Schadcode befindet sich vollständig im Speicher. Es wird nichts auf die Festplatte geschrieben, d.h. es handelt sich um file less malware. Es werden in der Ursprungsfassung auch keine neuen Prozesse erstellt, da Meterpreter sich selbst in den kompromittierten Prozess injiziert. Von dort kann er dann zu anderen laufenden Prozessen migrieren. Der forensische Fußabdruck eines solchen Angriffs sehr begrenzt.

Auf dieser Seite erfährt man noch, dass Meterpreter für eine dynamisch erweiterbare Nutzlast steht, die speicherinterne DLL-Injection-Stager verwendet und zur Laufzeit über das Netzwerk erweitert wird. Meterpeter kommuniziert über den Stager-Socket und bietet eine umfassende clientseitige Ruby-API. Es bietet eine Befehlshistorie, Tabulatorvervollständigung, Kanäle und mehr.

Meterpeter wurde ursprünglich von skape für Metasploit 2.x geschrieben, gemeinsame Erweiterungen wurden für 3.x zusammengeführt und werden derzeit für Metasploit 3.3 überarbeitet. Der Serverteil ist in einfachem C implementiert und wird jetzt mit MSVC kompiliert, was ihn einigermaßen portabel macht. Der Client kann in jeder beliebigen Sprache geschrieben werden, aber Metasploit verfügt über eine voll funktionsfähige Ruby-Client-API.

Metasploit ist ein Projekt zur Computersicherheit, das Informationen über Sicherheitslücken bietet und bei Penetrationstests sowie der Entwicklung von IDS-Signaturen eingesetzt werden kann. Das bekannteste Teilprojekt ist das freie Metasploit Framework, ein Werkzeug zur Entwicklung und Ausführung von Exploits gegen verteilte Zielrechner. Andere wichtige Teilprojekte sind das Shellcode-Archiv und Forschung im Bereich der IT-Sicherheit.

Kleiner C-Code-Loader

Offenbar reichen die in diesem Projekt enthaltenen Frameworks und Tools, um den oben skizzierten Ansatz eines Ausbruchs aus der Sandbox des Windows Defenders zu ermöglichen und sich dann im Betriebssystem umzusehen. Inzwischen hat sich der Sicherheitsforscher @an0n_r0 aber gemeldet und schreibt, dass es seine Motivation gewesen sei, einen minimalen Bypass ohne Verwendung eines Frameworks zu ermöglichen. Der verwendete Loader sei klein und in C geschrieben. Zur Obfuscation wurde eine einfache rc4-Verschlüsselung für den Shell-Code im Loader implementiert. Der eigentliche Bypass setzt auf einer grundlegenden Überprüfung des Benutzernamens auf. Um eine Erkennung durch den Defender zu verhindern, erfolgt keine gültige rc4-Entschlüsselung des Shell-Codes, wenn der aktuelle Benutzername nicht das Ziel ist.

Aktuell gibt es keinen Proof of Concept Code, der veröffentlicht wurde – der Tweet zeigt aber, dass auch dieses abgesicherte Windows 11 wohl mit einfachsten Mitteln über den Defender angegriffen werden kann. Ein weiterer Sicherheitsforscher kündigt an, dass er an etwas vergleichbarem arbeite und für Ende Oktober 2021 eine Veröffentlichung mit Details plane.


Anzeige

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

19 Antworten zu Windows 11: Defender-Bypass mit Ausbruch aus der Sandbox

  1. janil sagt:

    Das ging schnell und ist interessant. Bin gespannt, ob MS schneller ist mit Gegenmaßnahmen als die Hackergemeinde mit Angriffen und ob jetzt den "Fanboys und Betatestern" bald die Rechner lahm gelegt werden. Peinlich für MS, gelungene Unterhaltung für Beobachter.
    Endlich wieder ein "Blockbuster"

  2. Herr IngoW sagt:

    Ist die Schwachstelle an MS gemeldet oder wird wieder mal was ohne Sinn und Verstand veröffentlicht.
    Sinnvoller ist es doch sicher, solche Sachen erst an den Hersteller (egal welche Firma) zu melden und erst wenn der nicht reagiert an die Öffentlichkeit zu gehen oder?
    Schließlich ist es für die Sicherheit aller User (ob eine Firma oder Private) besser, das solche Schwachstellen behoben werden bevor sie Ausgenutzt werden.
    Denn es gibt ja keinen Hersteller die nicht irgendwo das eine oder andere (Sicherheits-) Problem hat. Manche reagieren einfach und bedanken sich beim Entdecker und wieder andere verklagen den Entdecker.

    Noch einen Problemfreien Tag.

    • Günter Born sagt:

      Da der Betreffende keine Details veröffentlicht hat, ist der obige Kommentar letzendlich nicht relevant. Der Blog-Beitrag ist auch als Pflock gegen die Volksverdummung des MS-Marketings "Windows 11 und dessen neue HW-Anforderungen machen endlich alles sicher" zu verstehen. Und der Beitrag hat den Zweck, den Admins aufzuzeigen, welche Gefahren potentiell schlummern.

  3. Markus K sagt:

    Ich kanns mir einfach nicht verkneifen und muss wieder einmal den Link auspacken und auf den Titel verweisen :):
    https://news.microsoft.com/de-at/windows-11-bietet-security-by-design-vom-chip-bis-zur-cloud/

  4. 1ST1 sagt:

    Und nirgends ist die Rede davon, dass der gante TPM-Zweipunktnull-Sicherheitsmechanismus umgangen werden musste. Der ist nämlich schlicht nicht existent und würde Windows keinen Millimeter sicherer machen.

    • Günter Born sagt:

      Die Sache ist noch trauriger – das, was Markus oben verlinkt, ist schlicht Marketing. Mir fehlte die Zeit, das mal aufzugreifen: Aber da wurde eine gewaltige Nebelkerze mit den Windows 11-Hardware-Anforderungen geworfen.

      Nur mal so: Die HW-Anforderungen gelten für alle Windows 11 SKUs, also Business- und Consumer-Systeme. Aber nur Windows 11 Pro, Enterprise und Education haben offiziell die Hyper-V-Optionen, um bestimmte Dinge zu tun. Die Windows 11 Home Edition-Nutzer gehen bisher leer aus …

      und schaut man sich die Mindestanforderungen an RAM sowie Festplattenspeicher an, passt das vorne und hinten auch nicht.

  5. Bolko sagt:

    Solche Angriffe sollte man eigentlich mit dem "Enhanced Mitigation Experience Toolkit" (EMET) mit dessen Funktion "Export address table Address Filter" (EAF) verhindern können.
    EMET ist aber leider seit Juli 2018 aus dem Support raus und Microsoft hat zwar einige Funktionen des EMET in Windows 10 und 11 direkt in den "Exploit-Schutz" eingebaut, aber eben nicht diese EAF und EAF+ Funktionen.

    Der Hacker schreibt:
    "copy shellcode into allocated mem in remote process"

    Dazu müsste sein Tool normalerweise in der "export address table" nachlesen, wo die Prozesse im RAM liegen und das würde dann EAF des EMET aktivieren und den Angriffsversuch unterbrechen.

    Das Problem war, dass das NET-Framework nicht kompatibel war mit den EAF-Funktionen und anstatt NET kompatibel zu machen, hat Microsoft dann die EAF-Funktionen rausgeschmissen aus dem Exploitschutz und dadurch einige Türen für Hacker offen gelassen.
    Beim EMET in Win7 konnte man genau einstellen, für welche Programme man welche Funktionen aktiviert oder deaktiviert (zB EAF) und dann die inkompatiblen NET-Programme ausschließen.
    In er Beziehung ist Windows 7 mit EMET sicherer als Windows 10 oder 11.

    Vermutlich würde ein aktives EAF beim Defender-Prozess aber auch das System spürbar ausbremsen.

    Secure-Boot oder TPM machen keinen Unterschied bei dieser Art von Angriff.

    • Darius F. sagt:

      > Secure-Boot oder TPM machen keinen Unterschied bei dieser Art von Angriff

      Sollte nicht durch Secure-Boot/TPM sichergestellt werden, dass gar kein unsignierter (Schad-)Code auf dem System läuft? Und damit auch kein Hacker Tool?

      • Günter Born sagt:

        Nur, was den Boot-Prozess und die OS-Komponenten betrifft – imho. Aber dummerweise verstehen die Anwender das nicht, und wollen Mails mit Anhängen oder Downloads oder was weiß ich mit diesem Windows nutzen oder gar E-Mails und Internetseiten zu lesen. Und die Dateien werden vom Defender gescannt. In einer Sandbox versucht der ggf. auch Code, den er in der Probe gefunden hat, auszuführen und zu beobachten. In meiner Lesart hat der Defender dann aber verloren, wenn es dem Angreifer gelingt, den Code zu zu gestalten, dass der Defender nicht anspringt.

        • Darius F. sagt:

          > Nur, was den Boot-Prozess und die OS-Komponenten betrifft – imho.

          Das führt das ganze TPM Theater im Argumentationspunkt Sicherheit dann aber ad absurdum. Entweder es läuft ausschliesslich signierter Code, eine Signatur kann auch ein Defender ohne Ausführung des Codes feststellen, oder man kann sich komplett alles sparen.

          Lässt den Schluss zu, dass das Theater wie von Bolko unten angemerkt, offenbar nur für eindeutiges Benutzertracking und alles was man dann damit anstellen kann veranstaltet wird.

          War da nicht was mit persönlicher globaler digitaler ID für alles und jedes und überall und social score usw.? Oder ist das nur eine dieser abstrusen Theorien… die Zeit wird es zeigen, nichts ist wie es scheint. Lesetipp: id2020.org

          • Günter Born sagt:

            Signaturen funktionieren nur für Exe, DLL und Treiber. Aber es gibt jede Menge andere Dateien, die ausführbaren Code enthalten können.

          • Darius F. sagt:

            Alles andere darf dann logischerweise gar nicht mehr ausgeführt werden, sonst ist doch das ganze Konzept sinnfrei wenn es der Sicherheit dienen soll, oder verstehe ich das nur einfach nicht?

          • Zocker sagt:

            Dateisignaturen sind tw. nur bis zu einem gewissen Datum gültig. Würde man diese Voraussetzung ausweiten bzw. verschärfen, hätte man wahrscheinlich ein Verfallsdatum für Software und ggf. auch Hardware. Ein vernünftiger Ansatzpunkt ist das nicht, es macht aus praktischer Sicht nur beim Bootprozess Sinn.

            Theoretisch müsste man wahrscheinlich sogar noch Fotos signieren, da man auch mit Bilddateien Lücken ausnutzen kann.

      • Bolko sagt:

        Secure-Boot gilt nur beim Starten, aber nicht im laufenden Betrieb, wo die Malware auch über Browser oder email ins System kommen können.

        TCP würde nur dann etwas nützen, wenn Windows dieses TCP benutzen würde, um eine Hashliste zu speichern, die dann mittels SRP oder Applocker für Application-Whitelisting benutzt würde, was aber offensichtlich nicht der Fall ist.

        Vermutlich benutzt Microsoft das TCP nur zur Benutzeridentifizierung und für DRM-Keys.

  6. Zocker sagt:

    Da ist er wieder, der ach so sichere Defender. Interessanterweise liest man (gefühlt) bei ihm von mehr Sicherheitslücken als bei allen Drittherstellern zusammen.
    Nebenbei zeigt sich, dass die hohen Hardwareanforderungen von Win11 die Sicherheit nicht entscheidend verbessern. Wahrscheinlich wird das, was benötigt wird, gar nicht richtig genutzt. Oder es ist nutzlos.

  7. deoroller sagt:

    Der Defender wird wie IE (aufgegeben), Adobe Flash Player (aufgegeben) und PDF Reader mit aktiven Inhalten aufgrund der monopolartigen Marktduchdringung alle Angreifer magisch anziehen, so dass auch kleine Lücken fatale Folgen haben können. Ähnliche Lücken wird es auch bei anderen AV-Lösungen geben, die aber mangels Masse für Angreifer uninteressant sind.
    Manchmal kann es sogar besser sein, keinen zusätzlichen und anfälligen Code einer AV-Lösung im System zu haben, weil dann weniger Lücken vorhanden sind, die das System direkt tangieren.
    AV-Lösungen, die out of the box filtern, sind eine Lösung, die aber Kontrolle aus der Hand geben, für Private ehr unpraktisch erscheinen und da sie auch auf einem anderen System laufen, bei dem die Codeanfälligkeit erhöht wird, nur das Problem verschieben. Aber es kann sich ein Profi darum kümmern und er muss vertrauenswürdig sein, weil man sonst nur den Bock zum Gärtner macht.

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.