Angriffe auf und über Tools, die überall vorhanden sind

Admin-Tools – Verwaltungswerkzeuge und Sicherheitslücken
Keine Kommentare

Alles, was ein Admin zur Verwaltung eines Rechners oder Netzes verwendet, ist für einen Angreifer von besonderem Interesse. Zum einen, weil diese Tools im Allgemeinen mit erhöhten Rechten laufen – und die möchten die Angreifer natürlich auch haben. Zum anderen, weil sie für genau die Aufgaben zuständig sind, die die Angreifer benötigen, um die vollständige Kontrolle über System und/oder Netzwerk zu erlangen.

Dass diese Tools von besonderem Interesse für Angreifer sind, wissen natürlich auch die Sicherheitsforscher, weshalb sie immer wieder prüfende Blicke auf diese Tools werfen. Dabei finden sie allerdings auch immer wieder Möglichkeiten für einen Angriff. Einige Tools waren bereits Thema früherer Artikel, zum Beispiel: Dass diese Tools von besonderem Interesse für Angreifer sind, wissen natürlich auch die Sicherheitsforscher, weshalb sie immer wieder prüfende Blicke auf diese Tools werfen. Dabei finden sie allerdings auch immer wieder Möglichkeiten für einen Angriff. Einige Tools waren bereits Thema früherer Artikel, zum Beispiel:

  • Windows Update, z. B. mit dem Windows Server Update Services (WSUS), in Ausgabe 1.17 [1]
  • die Windows Management Instrumentation (WMI) in Ausgabe 12.16 [2]
  • Active Directory in Ausgabe 11.16 [3]
  • Shims in Ausgabe 6.16 [4]

Dieser Artikel gibt einen Überblick über eine Auswahl weiterer Angriffe sowie teilweise Updates zu den genannten Artikeln; wir bewegen uns dabei chronologisch rückwärts in Richtung Vergangenheit.

März 2018: Black Hat Asia

Das Anti Malware Scan Interface (AMSI) richtet sich gegen Schadsoftware in Form von Skripten und dabei insbesondere Skripten von während der Laufzeit erzeugtem Schadcode. Jedes Mal, wenn Code zur Ausführung an den Scripting-Host übergeben wird, schreitet das AMSI ein und scannt den Code auf bösartige Inhalte. Dabei ist es egal, ob der Code durch Obfuscation oder sogar eine Verschlüsselung geschützt ist, denn an den Skripting-Host muss er ausführbar, d. h. als ungetarnter Klartext, übergeben werden [5].

AMSI unterlaufen oder ganz ausschalten

Tai Liberman hat gezeigt, wie dieser Schadcode das AMSI unterlaufen, teilweise sogar einfach ausschalten kann. Dazu werden teilweise Implementierungsfehler ausgenutzt, die Microsoft zum Teil bereits behoben hat, zum Teil noch beheben wird. Es werden aber auch vorhandene Möglichkeiten zur Steuerung des AMSI missbraucht, die sich nicht so einfach abstellen lassen – jedenfalls nicht ohne Verzicht auf gewünschte Funktionalitäten. Dazu gehört u. a. die Steuerung über PowerShell, ein Thema, das uns in diesem Artikel noch des Öfteren begegnen wird.

Matt Graber hatte schon 2016 gezeigt, wie sich das AMSI durch einen Einzeiler ausschalten lässt, den er in einem Tweet veröffentlicht hat:

[Ref].Assembly.GetType('http://System.Management .Automation.AmsiUtils').
      GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true)

In solchen Fällen gibt es dann ein Wettrennen zwischen Schadcode und AMSI: Erkennt das AMSI den Schadcode, kann es ihn stoppen. Ansonsten stoppt der Schadcode das AMSI.

Sicheres Booten: Nein – sicheres Aufwachen: Ja

Um Strom zu sparen, unterstützen Rechner mit Advanced Configuration and Power Interface (ACPI) sechs „Sleeping States“ (S0-S5), in denen mehr oder weniger viele Teile ausgeschaltet sind:

  • S0: Normaler Betrieb
  • S1: Standby, der CPU-Cache geht verloren
  • S2: Standby, die CPU ist ausgeschaltet
  • S3: Suspend, CPU und Devices sind ausgeschaltet
  • S4: Hibernate, CPU, Devices und RAM sind ausgeschaltet
  • S5: Soft Off, alle Teile sind ausgeschaltet

Unterstützt das Betriebssystem die Sleeping States, muss das auch die Securityhardware tun. Wurde sie ausgeschaltet, muss ihr Status beim Aufwachen wiederhergestellt werden. Seunghun Han und Jun-Hyeok Park haben gezeigt, wie sich durch eine Manipulation des Ablaufs des Sleeping States S3 Intels TXT (Trusted eXecution Environment) neutralisieren lässt.

TXT ist die hardwarebasierte Implementierung für das Dynamic Root of Trust Measurement (DRTM) und damit während des Bootens und Startens für die Prüfung der Vertrauenswürdigkeit der Plattform zuständig. TXT arbeitet dabei mit dem Trusted Platform Module (TPM) zusammen und speichert die Hashes der Software in den Platform Configuration Registers (PCR). Die von TXT gesetzten PCR-Werte des TPM können vom laufenden System nicht geändert werden. Durch die Manipulation des Ablaufs des Sleeping State S3 ist es möglich, das Wiederherstellen der PCR während des Schlafens und Aufwachens des Systems zu manipulieren.

Dezember 2017: Black Hat Europe 2017

Windows 10 Enterprise und Server 2012/2016 enthalten mit der Windows Defender Advanced Threat Protection (ATP) Möglichkeiten, einen erfolgreichen Angriff zu erkennen. Die Advanced Threat Protection kann mit der Verhaltensanalyse der Microsoft Advanced Threat Analytics (ATA) zur Erkennung laufender Angriffe kombiniert werden. Die ATP profitiert von den Verbesserungen im Bereich Sicherheit des Windows Management Frameworks (PowerShell) 5.1 und setzt ihrerseits clientseitig auf den Einsatz des AMSI zur Erkennung PowerShell-basierter und anderer skriptbasierter Angriffe.

ATP unterlaufen, und ATA gleich mit

ATP erkennt nur erfolgreiche Angriffe (Post Breach), wenn der Angreifer versucht, sich auf dem kompromittierten System häuslich einzurichten. Chris Thompson hat gezeigt, wie sich der Schutz durch ATP und ATA unterlaufen lässt. Das Problem der ATP ist, dass manche bösartigen Aktionen bzw. Aktionsmuster nicht erkannt werden, und ein Angreifer, der sich nur auf diese Aktionen beschränkt, dadurch ebenfalls nicht erkannt wird.

So werden z. B. Obfuscated JScript-/VBscript Payloads nicht erkannt, wenn sie keine Kernel32-API-Deklarationen verwenden. Das Gleiche gilt für einige Executables, die mit dem Go-basierten Veil und Shellter erzeugt wurden. Bei der Erkundung des Hosts wird WMI nicht als Angriff und auch keine rein Host-bezogene Erkundung durch direkten Aufruf des Windows-API erkannt. Persistenz im Userland lässt sich unerkannt über Component Object Model (COM) Hijacking erlangen. Und so weiter, und so fort.

Juli 2017: Black Hat USA 2017 und DEF CON 25

Angriffe auf Windows-Update-Funktionen habe ich im Windows Developer 1.17 vorgestellt [1]. Wer den Inhalt eines Updatepakets kontrolliert, hat damit auch die Kontrolle über das zugehörige System bzw. Programm. Entweder automatisch und sofort nach der Veröffentlichung des Updates, wenn die automatische Installation stattfindet; oder mit etwas Verzögerung, nachdem ein Benutzer oder Admin das Update installiert hat.

Über WSUS Active Directory Forrest kompromittieren

Den vielen in [1] aufgeführten Angriffen sind weitere hinzuzufügen. Romain Coltel und Yves Le Provost haben auf der Black Hat USA und der DEF CON 25 neue Angriffe über die Windows Server Update Services (WSUS) vorgeführt.

Das Enhanced Security Administrative Environment (ESAE) verhindert, dass ein Angreifer nach der Kompromittierung eines Rechners in eine Active-Directory-Domäne den gesamten Active-Directory-Forrest kompromittiert. Werden die Domain Controller von einem WSUS mit Updates versorgt, kann der Forrest darüber kompromittiert werden. Dabei greifen die beiden Forscher auf den in [1] vorgestellten Angriff WSUSpect von der Black Hat USA 2015 zurück. WSUSpect schleust ein bösartiges Update in die WSUS-Infrastruktur ein, sodass die WSUS-Clients sich die Schadsoftware freiwillig herunterladen und installieren, da sie sie für Microsoft-Updates halten.

Das reicht aber nicht aus, um die Kontrolle über einen DC zu übernehmen. Dafür ist ein weiterer Angriff nötig, den Romain Coltel und Yves Le Provost WSUSpendu genannt haben. Dieser kann nicht nur den Forrest in Form der DC kompromittieren, sondern manchmal auch die ESAE-Server selbst. Eigentlich sollten sie ihre Updates ausschließlich von Microsofts Server laden, tatsächlich laden sie sie je nach WSUS-Infrastruktur aber auch von einem lokalen WSUS-Server, z. B. in isolierten Netzwerken ohne Verbindung zum Microsoft Server.

PowerShell-Schadcode erkennen

PowerShell ist bei Administratoren ebenso wie bei Angreifern sehr beliebt. Kein Wunder, handelt es sich dabei ja auch um ein sehr mächtiges Tool. Darum ist es umso wichtiger, legitime Aktivitäten von Angriffen zu unterscheiden – woran normale Virenscanner meist scheitern und weshalb Microsoft ja auch das AMSI entwickelt hat. Und wie wir gesehen haben, lässt sich das ja auch austricksen.

Daniel Bohannon und Lee Holmes haben auf der Black Hat USA 2017 und DEF CON 25 gezeigt, wie PowerShell-Schadcode getarnt werden kann und wie diese Tarnung mithilfe des erweiterten Loggings in PowerShell 5.0 aber auch erkannt werden kann. Für diesen Zweck haben die beiden das PowerShell-Obfuscation-Detection-Framework Revoke-Obfuscation entwickelt.

Microsoft Office sorgt für Persistenz des Angreifers

Microsoft Office ist zwar kein Admin-Tool, es ist aber auf den meisten Windows-Rechnern vorhanden. William Knowles hat auf der DEF CON 25 gezeigt, wie ein Angreifer Office nutzen kann, um Persistenz zu erreichen, den Rechner also dauerhaft unter seine Kontrolle zu bringen. Vorgestellt wurden die folgenden Möglichkeiten:

  • WLL und XLL Add-ins für Word und Excel: Diese veralteten Add-ins erlauben das Laden beliebiger DLLs.
  • VBA Add-ins für Excel und PowerPoint sind eine Alternative zu Templatedateien mit Hintertür und werden bei jedem Laden der Anwendung ausgeführt.
  • COM Add-ins für alle Office-Programme
  • Automation Add-ins für Excel: Die benutzerdefinierten Funktionen erlauben die Ausführung von Befehlen über Spreadsheet-Formulare.
  • VBA Editor (VBE) Add-ins für alle VBA nutzenden Office-Programme
  • VSTO Add-ins für alle Office-Programme: Diese neuen Cross-Application-Add-ins verwenden eine spezielle Visual Studio Runtime.

Alle Möglichkeiten haben ihre speziellen Vor- und Nachteile, erlauben dem Angreifer aber immer das Einschleusen seines Schadcodes. Als Schutz vor Angriffen über XLL, COM, Automation und VSTO Add-ins können die Add-ins generell ausgeschaltet werden, sofern sie nicht benötigt werden. Ein Schutz vor WLL und VBA Add-ins ist dagegen kaum möglich. Die vertrauenswürdigen Speicherorte für sie können entfernt oder verschoben und auf Änderungen überwacht werden, ebenso können die Registry Keys zum Aktivieren der Add-ins überwacht werden.

Per BITS Schadcode einschleusen

Der Background Intelligent Transfer Service (BITS) dient der asynchronen Übertragung einer Datei zwischen einem Client und einem Server im Hintergrund. BITS wird z. B. von Windows Update verwendet. Möglichkeiten zum Missbrauch des BITS sind schon seit Langem bekannt, z. B. für den Download von Schadsoftware, als Persistenzmechanismus (z. B. von DNSChanger/Zlob.Q verwendet) und als Command-and-Control-Kommunikationskanal.

Der BITS verwaltet seine Job-Queue in einer Datei auf der Platte. Dor Azouri hat auf der DEF CON 25 beschrieben, wie ein lokaler Admin diese Datei manipulieren und dadurch z. B. eigene Downloads und damit Schadcode einschleusen kann. Er hat das Python-Skript BITSInject entwickelt, mit dem ein Job mit Local-System-Rechten in die Queue eingefügt werden kann, der nach dem Download gelöscht wird. Außerdem können einige Parameter manipuliert werden. Für eigene Experimente steht mit dem SimpleBITSServer auch ein einfacher BITS-Server zur Verfügung.

Auch die Harten werden gehackt!

Das Remote Management von Windows Server kann durch PowerShell Just Enough Administration (JEA) gehärtet werden. Korrekt konfiguriert stellen JEA-gehärtete Endpunkte eine große Hürde für Angreifer dar: Es gibt nur eine Whitelist zulässiger Befehle ohne administrativen Zugriff auf das darunter liegende Betriebssystem.

Lee Holmes hat diesen Schutz auf der DEF CON 25 durch das Ausnutzen unsicheren Codes und komplexer Konfigurationen Schritt für Schritt demontiert. Das von ihm angekündigte Tool PowerShell Injection Hunter für die Suche solcher Schwachpunkte wurde bisher leider nicht veröffentlicht. Es wird auch in einem im Oktober 2017 veröffentlichten Eintrag in Microsofts PowerShell Team Blog von Lee Holmes nicht erwähnt. Vermutlich ist es also, wie so oft, gar nicht erst fertig entwickelt worden.

Office-365-Command-and-Control-Kanal

Oben diente Microsoft Office als Mittel zum Erreichen von Persistenz. Craig Dods hat auf der Black Hat USA 2017 allerdings gezeigt, wie Office 365 und PowerShell zur Kommunikation mit dem Command-and-Control-Server missbraucht werden können. Dazu wird mithilfe von PowerShell-Befehlen ein in File Explorer, WMI, COM und .NET unsichtbares Office-365-Laufwerk gemountet. Für einen Schreib-/Lesezugriff darauf ist normalerweise eine Benutzerinteraktion nötig. Indem die Möglichkeiten zum Zugriff auf den IE über die PowerShell missbraucht werden, ist der Zugriff aber auch ohne aktive Beteiligung des Benutzers möglich. Dadurch kann dieses Laufwerk unbemerkt zum Datenaustausch mit dem Command-and-Control-Server genutzt werden.

So ein Angriff wird durch die meisten Sicherheitslösungen mit signaturbasierter Erkennung oder statischer Analyse nicht erkannt. Die nötigen Browser- und Registry-Manipulationen werden in einer Sandbox im Allgemeinen als bösartig erkannt – aber auch das lässt sich durch ein paar Anpassungen zumindest erschweren.

ATA stört? Nicht!

Microsofts Advanced Threat Analytics (ATA) zur Erkennung laufender Angriffe wurde oben bereits erwähnt, der Schwerpunkt lag auf dem Unterlaufen der Advanced Threat Protection (ATP), die erst in der Post-Breach-Phase, also nach der erfolgreichen Kompromittierung, greift. Auf der Black Hat USA 2017 hat Nikhil Mittal gezeigt, welche Angriffe von der ATA ohnehin nicht erkannt werden und wie andere Angriffe vor ihr verborgen werden können.

Diesmal geht es also um die tatsächlichen Angriffe, mit denen der Angreifer seinen virtuellen Fuß in die Tür bekommen will. Die ATA wertet eine Vielzahl von Protokolldaten aus und setzt sowohl anomalie- als auch verhaltensbasierte Erkennungsroutinen ein. ATA erkennt z. B. Active-Directory-basierte Erkundungen anhand der an den Domain Controller gesendeten Anfragen. Es stört sich aber nicht daran, dass der DC für den Angreifer hilfreiche Informationen ausgibt, solange kein Angriff auf den DC erkannt wird. Greift der Angreifer bei der Erkundung also nicht direkt auf den DC zu, wird er nicht erkannt.

Brute-Force-Angriffe auf Active Directory, bei denen nur ein einzelnes Passwort für mehrere Benutzer ausprobiert wird, werden ebenfalls nicht erkannt. Auch sogenannte Overpass-the-Hash-Angriffe, bei denen Kerberos-Tickets aus NTLM-Hashes und AES-Schlüsseln erzeugt werden, werden nicht in jedem Fall erkannt.

Und so geht es einige Zeit weiter. Es gibt etliche Möglichkeiten, das Erkennen eines Angriffs durch die ATA zu verhindern, oder, wenn das nicht möglich ist, die Beobachtung durch ATA zu vermeiden, z. B. indem niemals direkt auf den DC zugegriffen wird.

April 2017: HITBSecConf Amsterdam 2017

Das Enhanced Mitigation Experience Toolkit (EMET) zum Erschweren von Angriffen durch Mitigations wurde vom Microsoft abgekündigt. Seit dem Fall Creators Update für Windows 10 sind die EMET-Funktionen Bestandteil des neuen Windows Defender Exploit Guard.

EMET ist tot, aber so was von!

Wie es mit der Sicherheit des Windows Defender Exploit Guards aussieht, ist noch nicht bekannt; dass EMET sich austricksen ließ, jedoch schon. Wie das geht, hat Niels Warnars für die Version 5.52 gezeigt. Prinzipiell stehen verschiedene Möglichkeiten zur Verfügung: Es können individuelle Mitigations umgangen, Hooks übersprungen und die Systemaufrufe direkt verwendet, oder Implementierungsfehler ausgenutzt werden. Niels Warnars hat sich für die letzte Möglichkeit entschieden und herausgefunden, dass die Struktur EMET_SETTINGS mit der Konfiguration nicht schreibgeschützt ist. Durch die Ausnutzung bekannter Schwachstellen konnte er in die Konfiguration schreiben und dadurch das EMET umkonfigurieren – was ein Angreifer natürlich zum Ausschalten nutzen würde. Darüber hinaus hat er noch weitere Möglichkeiten aufgeführt, EMET ganz oder teilweise auszuhebeln.

März 2017: Black Hat Asia 2017

Durch das Prüfen von Codesignaturen wird zum einen festgestellt, von wem der Code stammt, und zum anderen, dass er nach dem Signieren nicht verändert wurde. Signierter Code, der die Prüfung besteht, ist daher vertrauenswürdig (sofern man dem Signierer vertraut) und kann bedenkenlos ausgeführt werden. Theoretisch jedenfalls. In der Praxis gab es immer wieder Fälle von korrekt signiertem Schadcode, z. B. weil bei einem Entwickler unbemerkt der Signierschlüssel ausgespäht worden war.

Angriffe mit signiertem Schadcode

Pierre-Alexandre Braeken hat demonstriert, wie ein Angreifer nur mithilfe der PowerShell und einem signierten Debugger diesen Schutz unterlaufen kann. Ausgangspunkt seiner Beispiele ist das Programm PowerMemory, mit dem das Spiel Minesweeper gelöst werden kann. Das nutzt die PowerShell und einen von Microsoft signierten Debugger, um sowohl im Userland als auch im Kernelland alles zu erreichen, was ein Angreifer erreichen wollen könnte. PowerManager sendet dabei Text an den Debugger und empfängt selbst Text vom Debugger – mehr ist nicht nötig. Der Angriff läuft folgendermaßen ab: PowerMemory ruft erstens den Debugger auf und sendet ihm einen auszuführenden Befehl, empfängt zweitens die Bytes der Antwort darauf, parst diese drittens und sendet viertens einen neuen Befehl mit Bytes, die an eine bestimmte Adresse geschrieben werden müssen, an den Debugger.

Dabei passiert Folgendes: Im ersten Schritt fordert PowerMemory einen Dump eines Programms an, den es im zweiten Schritt vom Debugger erhält. Im Dritten wertet es diese Daten aus und sucht darin z. B. nach Zugangsdaten oder Stellen, die geändert werden müssen, um die Ziele des Angreifers zu erreichen. Und im vierten Schritt lässt es diese Änderungen durchführen.

PowerMemory ist ein Angreifer aus dem UserLand und kann Windows-Passwörter aus dem Speicher ausspähen, Shellcode in einen entfernten Prozess einschleusen und ausführen und den Speicher eines Prozesses modifizieren. PowerMemory ist mithilfe der Direct Kernel Object Manipulation (DKOM) auch ein Angreifer aus dem Kernelland und kann dadurch einen Prozess sichtbar oder unsichtbar machen, alle Privilegien in einen Prozess mit SYSTEM-Identität einfügen, Pass-the-Token-Angriffe durchführen und Prozesse schützen.

Sie haben es sicher schon erraten: PowerMemory ist lediglich offiziell nur ein Tool zum Lösen von Minesweeper. Tatsächlich ist es ein Tool für das Ausspähen und Angreifen von ActiveDirectory.

August 2016: Black Hat USA – mit EMET gegen EMET

EMET ist wirklich tot, denn es kann nicht nur von außen lahmgelegt werden, sondern auch mit sich selbst, also quasi von innen. Wie das möglich ist, haben Abdulellah Alsaheel und Raghav Pande gezeigt: Die EMET.dll enthält eine Funktion, um EMET zu entfernen. Bei ihrem Aufruf werden alle EMET-Hooks entfernt und die Debugging-Register mit Nullen überschrieben (um EAF- und EAF+ Mitigations auszuschalten). Außerdem gibt es Funktionen, um die EMET-Hooks zu entfernen und die CONTEXT-Struktur mit Nullen zu überschreiben. Abdulellah Alsaheel und Raghav Pande haben über Return-oriented Programming (ROP) diese Funktionen aufgerufen und damit EMET ausgeschaltet.

Fazit

Diese Angriffe sind nur eine Auswahl; es gab noch viele weitere ebenso relevante Vorträge auf den verschiedenen Sicherheitskonferenzen. Sie machen vor allem eines deutlich: Es gibt anscheinend nichts, was sich nicht für einen Angriff missbrauchen lässt. Deshalb ist es äußerst wichtig, immer die gesamte Software aktuell zu halten. Aber das ist bei den Microsoft-Programmen ja weiter kein Problem, seit Microsoft Updates nach dem „Alles-oder-nichts“-Prinzip ausspielt – da bekommt man die Updates notgedrungen ja automatisch mit. Aber auch separat installierte Software anderer Hersteller muss immer aktuell sein, um zumindest keine bekannten Schwachstellen als Einfallstor offen zu lassen. Entsprechende Angriffe, wie zum Beispiel das Extrahieren von Tastendrücken über VoIP beispielsweise über Google Hangouts oder Angriffe auf und über BYOD-Sicherheitslösungen, haben keinen Platz in diesem Artikel gefunden – es gibt sie aber.

[1] Eilers, Carsten: „Ist es ein Update oder ein Schädling?“; Windows Developer 1.17
[2] Eilers, Carsten: „WMI in Angreiferhand“; Windows Developer 12.16
[3] Eilers, Carsten: „Angriffsziel Active Directory“; Windows Developer 11.16
[4] Eilers, Carsten: „The Good, the Bad, the Ugly“; Windows Developer 6.16
[5] Eilers, Carsten: „Windows 10: Sicherheit für Entwickler“; Windows Developer 12.15
Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -