Signatur für Windows 0-day EPATHOBJ Exploit

Am gestrigen Tage wurde eine 0-day Schwachstelle am Microsoft Windows Betriebssystem bekannt, die für sich allein betrachtet bereits als schwerwiegend betrachtet wird, in Zusammenhang mit den uns bekannten Angreifer-Werkzeugen wie dem Windows Credential Editor allerdings als kritisch für jede größere Microsoft Windows Domänen-Infrastruktur angesehen werden muss.
Die im heise Artikel “Google-Forscher veröffentlicht Zero-Day-Exploit für Windows” erwähnte Schwachstelle ermöglicht es jedem Benutzer einer Windows Plattform, sich höchste Rechte auf dem System zu beschaffen. Durch Einsatz des Exploits kann sich selbst ein Gast Benutzer zu dem Benutzer “LOCAL_SYSTEM” eskalieren. Die Anwendung es Exploit ist simple und kann von Personen ohne Fachwissen durchgeführt werden.
Alle Windows Versionen und Architekturen sind betroffen.
Der Schadcode wird von kaum einem Virenscanner erkannt.
0day exploit EPATHOBJ

Ein einfacher Kommandozeilenaufruf erlaubt es, ein Program als LOCAL_SYSTEM zu starten


Folgende Szenarien sind durch das Exploit möglich:

  • Benutzer von Windows Client können sich lokale, administrative Rechte verschaffen
  • Benutzer auf Servern können sich dort administrative Rechte verschaffen
  • Benutzer auf Citrix Farmen können sich dort administrative Rechte verschaffen
  • Malware verwendet das Verfahren, um sich bei Ausführung im eingeschränkten Benutzerkontext lokale Systemrechte zu verschaffen und das System tiefgreifend zu verändern
  • Hacker (z.B. in APT Umfeldern) erhalten so auf Systemen das Recht, auf die gespeicherten LSA Sitzungen von Administratoren zuzugreifen (s.h. Windows Credential Editor Präsentation – Post-Exploitation)

Zusammenspiel mit Windows Credential Editor

Im Zusammenspiel mit dem “Windows Credential Editor” (WCE) wirkt diese Schwachstelle besonders verheerend. Mit dem Windows Credential Editor ist es möglich, LSA Sitzungstokens (NTML Hashes) und Klartextpassworte aus dem Speicher eines Systems zu dumpen. Diese Sitzungsinformationen bleiben teilweise Tage und Wochen im Speicher eines Systems zurück. Es reicht, dass der Angreifer Zugriff auf einen Mitgliedsserver erhält, um NTLM Hashes von Domänenadministratoren aus dem Speicher zu extrahieren.
Übliche Methoden zum Schutz vor diesen Attacken, wie die Wahl eines komplexen Passwortes, welches aus dem Hash nicht zurück berechnet werden kann, greifen nicht. Der WCE stellt Funktionen bereit, die einen einfachen Pass-the-Hash Angriff umsetzen. Dazu muss das Passwort nicht geknackt, sondern nur der Hash weitergereicht werden. In unserem Kundenumfeld setzen Angreifer diese Methode ein, um von Serversystemen in unbedeutenden Außenstandorten, Kommandozeilen mit Rechten eines Domänen-Administrators auf den Domänen-Controllern zu öffnen.
Diese Präsentation beschreibt die Funktionsweise des WCE im Detail.
Zur Ausführung des WCE sind allerdings administrative Rechte erforderlich, über die die Angreifer nicht immer verfügen. Mit dem neuen Windows Exploit erhalten sie diese aber einfach und schnell. Eine gesamte Windows Domäne fällt so in kürzester Zeit.

Gegenmaßnahmen

Wir haben auf Grund der Dinglichkeit eine Signatur für das von Tavis Ormandy veröffentlichte Windows Zero-Day-Exploit erzeugt. Andere Methoden zur Erkennung werden derzeit evaluiert. Wir werden Sie hier im Blog informieren, wenn wir andere Wege zur Erkennung (z.B. Windows Eventlogging) finden konnten.
Sie können ihre Systeme mit Hilfe von YARA manuell scannen.

rule Windows_0day_Exploit_1 {
meta: description = "Windows 0day EPATHOBJ local ring0 Exploit"
strings:
$a = "PATHRECORD" fullword
$b = "HRGN" fullword
$c = "FlattenPath" fullword
$d = "EndPath" fullword
$e = "PolyDraw" fullword
condition:
all of them
}

Nachdem Sie “yara-1.7-winXX.zip” heruntergeladen und entpackt haben, können sie über die Kommandozeile den Scan mit der oben angegeben Signatur starten.
Diese Signatur ist auch Teil unseres Incident Response Scanners THOR, zu dem Sie hier mehr Informationen finden können.
Einen Schutz auf kritischen Systemen bietet eine Lösung wie “AppSense Application Manager“, zu dem wir auch Support anbieten. Er setzt das “Trusted Ownership” Modell um, welches auf Windows Systemen sicherstellt, dass nur diejenigen Executables ausgeführt werden dürfen, die von einer vertrauenswürdigen Gruppe auf das System gebracht wurden (z.B. Administratoren). So können z.B. die Benutzer von Citrix Systemen weiterhin ihre dort abgelegten Anwendungen verwenden, aber keine eigenen, eingebrachten Executables zur Ausführung bringen.

Exploitcode

Der Exploitcode wurde von uns kompiliert und untersucht.
Eine von uns veranlasste Analyse des Exploitcodes durch Malwr.com finden Sie hier.
(die kompilierte Executable kann von dieser Seite heruntergeladen werden – wir übernehmen keine Haftung für Schäden, die durch die Ausführung entstehen)

Update

Wir konnten den bereitgestellten Code nur auf 32bit Betriebssystem Versionen zum Laufen bringen. Es steht jedoch außer Frage, dass die Schwachstelle nach Anpassungen auch auf 64bit Systemen ausnutzbar sein muss.
Interessant ist auch, das Tavis Ormandy den lauffähigen Exploitcode von einem chinesischen Studenten bereitgestellt bekommen hat.

Checkpoint Firewall Support und Fehleranalyse mit dem fw.log

Checkpoint Firewall Support und Fehleranalyse mit dem fw.log

Die Erfahrung hat gezeigt, dass es im Umfeld von Checkpoint Firewalls immer wieder dazu kommen kann, dass Firewalls ohne ersichtlichen Grund Anzeichen einer Überlastung aufweisen, indem sie für kurze Zeit nicht mehr erreichbar sind und Verbindungen mit Timeouts abbrechen. Besonders in großen Firewall-Umgebungen, mit mehreren Gigabyte an Logdaten pro Tag, stellt die Analyse derart unbestimmter Fehlerzustände ein erhebliches Problem dar.

Die Werkzeuge der Herstellers sind meist nicht in der Lage, spezifische statistische Analysen zu erzeugen. Entweder erweisen sich die Auswertungen als zu grob, indem Angaben zu stark kumuliert wurden oder als zu detailliert, sodass zwar Einzelheiten erkennbar waren, aber die Übersicht verloren ging.
Der mit der Checkpoint Firewall ausgelieferte “SmartView Tracker”, der sich für die Detailanalyse einzelner Logs durchaus eignet,  erlaubt beispielsweise keine sinnvolle Auswertung bezüglich kurzfristiger Lastspitzen. Die Funktion des Trackers beschränkt sich im Wesentlichen auf die Darstellung und die Filterung von Logzeilen.

Checkpoint SmartView Tracker

Checkpoint Fehlersuche im SmartView Tracker

Das von Checkpoint angebotene Produkt “SmartEvent” kann u.a. statistische Analysen erzeugen, die allerdings in den meisten Fällen nicht die Flexibilität aufweisen, die für die Eruierung des Problems erforderlich ist. Besonders im Bezug auf mehrdimensionale Auswertungen, wie beispielsweise der Auswertung der Top-Speaker pro Zeiteinheit, sind in den Werkzeugen starre Grenzen gesetzt.

Checkpoint SmartEvent

Checkpoint SmartEvent (Source: http://www.ictsecurity.cz/)

Loganalysesoftware wie etwa Splunk, Sawmill oder Firewall Analyzer bieten jeweils andere und oftmals auch detailliertere Sichten auf diese Protokolldaten, sind aber oftmals in der jeweiligen Situation nicht verfügbar, laden aus Performancegründen nicht das gesamte Firewall Log  oder sind nicht so konfiguriert, dass eine einfache Fehlersuche ermöglicht wird.
Mit Hilfe von uns entwickelter Analyseskripte ist es auf einfache Weise möglich, auch sehr große (getestet bis 10GB Dateigröße) Checkpoint Firewall Logs zu parsen und eine statistische Auswertung zu Zeitabschnitten und Ereignissen innerhalb dieser Zeitabschnitt zu erhalten.
Die Skripte eignen sich vor allem für folgende Analysen:

  • Checkpoint Firewall Top Speaker Analysis
  • Checkpoint Firewall Time Frame based Top Speaker Statistics
  • Checkpoint Firewall Anomaly Detection
Da Firewall-Logs anderer Hersteller bis auf Spaltentrenner und Positionen der Werte in aller Regel gleich aufgebaut sind, ist eine Anpassung auf andere Firewall-Typen mit minimalem Aufwand möglich.

Die Skripte sind stark parametrisierbar und erlauben es beispielsweise Peaks im Traffic zu erkennen, also Zeitabschnitte, in denen durch ein oder mehrere Systeme besonders viele Verbindungen pro Zeiteinheit aufgebaut werden. Diese Peaks gehen meist in einer Tagesstatistik unter, da sie nur kurz, aber dafür umso stärker auf die Firewall einwirken und damit Fehlerzustände verursachen können. In der Gesamtzahl der Ereignisse pro Quellsystem und Tag müssen diese “Peeks” nicht auffällig werden.
Nachfolgendes Bild zeigt eine Topspeakeranalyse mit Sekundenzeitfenstern. Mögliche Werte für die Analysezeitfenster sind 1 Sekunde, 10 Sekunden, 1 Minute, 10 Minuten, 1Stunde.

Checkpoint Top Speaker Analysis per Time Frame

Checkpoint Top Speaker Analysis per Time Frame

Unsere Skripte erlauben es uns, durch die Verwendung des Standard-Inputs als zu lesenden Datenstrom, bereits gepackte Dateien auf einfache Art und Weise zu verarbeiten und schon vor der Verarbeitung durch das Skript eine Filterung vorzunehmen.
Im folgenden Beispiel wird ein gepacktes Checkpoint-Log mittels “zcat” entpackt und in die Standard-Ausgabe geschrieben, die durch “grep” alle Ereignisse des Typs “Accept” herausfiltert und nur die übrigen Zeilen an das Skript zu Analyse übergibt. Es handelt sich dabei nur um ein Demo-Log, aber man erkennt die Struktur der Analyse bereits recht gut.

zcat fw_280812.gz | grep -v accept | perl ./checkpoint-peak-detector.pl > report.htm

Die Ausgabe besteht aus deinem HTML-Report und CSV-Dateien. Der Kopf des HTML Outputs aus dem Demo-Daten ist im folgenden Screenshot zu sehen.

Checkpoint FW1 Analysis

Checkpoint Peek Analyse Kopf – Systeme mit Gesamtzahl der Verbindungen und dazugehörige “Actions” (Demo-Log)

Wenn Zeilen nicht verarbeitet werden können, weil sie keine Quell-IP enthalten, werden sie nicht einfach ausgelassen, sondern finden Beachtung in einer gesonderten Auswertung der “Unreadable lines”. Der Begriff trifft die Bedeutung nicht ganz, denn “SmartDefense” Ereignisse sind sicher “lesbar”, allerdings können einige nicht vom Skript ausgewertet werden, wenn sie keine Quell-IPs enthalten.
Andere Zeilen des Typs “control” oder “monitor” oder gar gänzlich unbekannte Typen werden hier statistisch ausgewertet. Im folgenden Beispiel sind leider nur wenige solche Ereignisse enthalten. Die Zeitabschnitte in denen besonders viele dieser Zeilen gefunden wurden, werden nach oben sortiert. In den Zeilen wird dann aufgeschlüsselt, um welchen Typ es sich dabei gehandelt hat. Selbst wenn hier noch keine genaue Auswertung des eigentlichen Problems erfolgt, so lassen sich doch wertvolle Hinweise auf die Quelle und denjenigen Zeitabschnitt herauslesen, der es lohnt, in anderen Werkzeugen genauer untersucht zu werden.

Checkpoint Unreadable Lines

Auswertung der Checkpoint Log Zeilen ohne Source IP

Die Werkzeuge werden immer auf die spezielle Kundenumgebung angepasst und können in der Regel sehr kurzfristig zum Einsatz kommen.
Bei Interesse an den Skripten oder Unterstützung in Sachen Fehleranlyse von Checkpoint Firewalls können Sie sich jederzeit über das Kontaktformular mit uns in Verbindung setzen.

Logit – Windows Log Tool für Eventlog und MySQL

Logit – Windows Log Tool für Eventlog und MySQL

Die neue Version 0.3 des Kommandozeilenwerkzeugs zur Protokollierung von Programmausgaben in Dateien und das Windows Eventlog namens Logit unterstützt jetzt auch die Protokollierung in MySQL Datenbanken.
Logit erwartet einen Ausgabestrom oder führt selbst ein Programm aus und protokolliert alle Ausgaben des Programms. Es konnte bisher bereits in Dateien und das Windows Eventlog schreiben. Neu ist die Funktion der Protokollierung in eines MySQL Datenbanktabelle.
Ein Besipiel:

tasklist | logit -p mysqltest -my

Log Windows MySQL

Logit Daten in MySQL Datenbank

Hier die Übersicht über die Funktionen von Logit im Gegensatz zu Neolog – dem anderen Werkzeug der Collection.

NeoLog Collection Übersicht

NeoLog Collection Übersicht

Die Werkzeuge befinden sich in unserer Download-Sektion inklusive einer genauen Beschreibung.

SIDMaster Windows SID to Username Tool

SIDMaster Windows SID to Username Tool

Das Werkzeug “SIDMaster” ermöglicht, einen Windows Benutzernamen in eine SID (Windows Security Identifier) aufzulösen. Das Programm ist einige Kilobyte groß und benötigt keine Installation. Es erfordert ein installiertes .NET 3.5 oder 4.0 auf dem System, auf dem es ausgeführt wird.
SIDMaster Man Page

SIDMaster Man Page


Folgende Funktionen sind integriert:

  • SID to User name
  • User name to SID
  • All user info inklusive SIDs
  • Liste mit allen Benutzernamen und SIDs

Beispiele

SID to User

User to SID

Download

Sie finden die aktuelle Version von SIDMaster in der Download Sektion.

Neue Version 0.5 unseres Windows Syslog Client "NeoLogger"

Neue Version 0.5 unseres Windows Syslog Client "NeoLogger"

Die neue Version 0.5 von NeoLogger überwacht jetzt auch ein Verzeichnis (-dir) und Unterverzeichnisse (-sub) auf Änderungen an Dateien mit Endung “.log” (-ff) und sendet alle neuen Zeilen (-tail) mit dem Dateinamen der geänderten Datei als Prefix (-fn) an den angegebenen Server (-t) per Syslog.
neolog.exe -d -t 10.0.0.1 -dir “C:\logfiles” -sub -ff “*.log” -fn -tail
Das sieht dann so aus:

Sending to 127.0.0.1 Port 514 : C:\logfiles\test.log : First new line in log file
Sending to 127.0.0.1 Port 514 : C:\logfiles\test.log : Second new line in log file
Sending to 127.0.0.1 Port 514 : C:\logfiles\subdirectory\another.log : Another line in a log file

Neologger überwacht das Verzeichnis (-d) auf Änderungen (-watch) und zeigt an, mit welcher Datei WAS passiert ist. (Changed, Created, Deleted, Renamed)
nelog.exe -d -t 10.0.0.1 -dir “C:\fileshare” -watch
Das sieht dann so aus:

Sending to 127.0.0.1 Port 514 : NeoLogger: File C:\logfiles\windows.log - Changed
Sending to 127.0.0.1 Port 514 : NeoLogger: File C:\logfiles\super.log - Deleted
Sending to 127.0.0.1 Port 514 : NeoLogger: File C:\logfiles\readme.txt C:\logfiles\readme-new.txt - Renamed

NeoLogger finden Sie in unserer Download Sektion. Eine ausführliche Beschreibung aller Funktionen findet sich hier.

Citrix Systeme absichern bzw. härten

Citrix Systeme absichern bzw. härten

In zahlreichen Projekten hatten wir die Aufgabe, Mehrbenutzersysteme auf Windows-Basis wie Citrix oder VDI Systeme zu härten. In vielen Fällen wurde eine Windows-Applikation wie z.B. ein Anwendung für die Bauplanung oder eine Finanzkalkulation auf einem Terminal Server System bzw. Citrix System bereitgestellt, um mehreren Nutzern den Zugriff auf den gleichen Datenbestand zu gewähren.
Einige Windows-Applikationen bieten von ihrer Architektur her nicht die Möglichkeit, eine Client-Anwendung auf einer Arbeitsstation zu installieren, die dann mit einer Server-Anwendung und Datenbank kommuniziert (z.B. Microsoft ProjectWise, SAP GUI, Remedy).  Sie bieten auch kein Webfrontend an, wodurch man mittels des Browser zusammen an einem Datenbestand arbeiten könnte. Oftmals handelt es sich um hoch spezielle Anwendungen aus dem Baugewerbe und Finanzsektor, deren Portierung  zu einer Weblösung eine komplexe und kostenintensive Neuentwicklung bedeuten würde.
Neben der Projektsteuerung und der Konzeption einer hinreichend sicheren Architektur kommt uns in der Regel auch die Aufgabe zu, ein solches System umfassend zu bewerten und anschließend zu härten. In den letzten Jahren verwendeten wir zu diesem Zweck bereits häufig das Werkzeug “AppSense”, welches sich mittlerweile als wesentlicher Faktor im Sicherheitskonzept einer solchen Umgebung etabliert hat.
Wir nutzen es, um den Benutzer auf dem Windows System auf die für ihn vorgesehene Aufgabe einzuschränken und den Ausbruch aus der Umgebung zu verhindern.
Im Gegensatz zur vermeintlichen Härtung über die Windows Gruppenrichtlinien, welche für unsere Auditoren niemals eine ernst zu nehmende Hürde dargestellt hatten, werden durch AppSense mehrere Schichten der Sicherheit implementiert. Einige häufig genutzte Features sollen hier kurz beschrieben werden:

  • Trusted Ownership Modell
    Dieses Modell erlaubt es nur den Administratoren des Systems, ausführbare Anwendungen auf das System zu bringen und dort auszuführen. Vor allem, wenn Benutzer lokale Laufwerke montieren können, um z.B. Baupläne auf das Citrix System zu laden, will man dennoch nicht zulassen, dass der Benutzer einen Portscanner oder einen Passwort-Dumper auf das System kopiert und dann dort startet.
  • White- und Black-Lists
    Über Listen können Anwendungen als unerwünscht definiert werden. Das gilt auch für Anwendungen, die nach dem Trusted-Ownership-Modell von einem Administrator auf das System gebracht wurden, wie z.B. “cmd.exe”, “netstat.exe” oder “firefox.exe”. Bei einer Kontrolle über Gruppenrichtlinien konnte man in der Vergangenheit einfach die “cmd.exe” in “cmd2.exe” umbenennen und sie dann starten. Beim Kopieren, wird allerdings der Besitzer auf den kopierenden Benutzer gesetzt, sodass eine solche “cmd2.exe” unter AppSense nicht zur Ausführung gebracht werden könnte.
  • Device-Rules
    Es kann unterschieden werden, ob sich ein Benutzer aus dem internen Netz von seinem Arbeitsplatz-PC anmeldet oder ob er aus dem Internet von einem unbekannten Gerät auf das System zugreift und dementsprechend ein unterschiedliches Set an Regeln angewandt werden.
  • Network-Connection Filters
    Für Gruppen auf dem System können auch Filterungen des Netzwerkverkehrs definiert werden. So kann man beispielsweise von extern kommenden Benutzern verbieten, mit anderen Systemen im internen Netz zu kommunizieren. Oder man kann bestimmen Gruppen verbieten, die IP des firmeneigenen Proxies anzusprechen, damit sie sich von dem System aus nicht ins Internet verbinden können.
  • uvm.
Im folgenden sieht man eine typische Blacklist mit einer vollständigen Einschränkung was den Netzwerkverkehr der Gruppe angeht, wie auch einer sog. Gruppe “Evil Executables”, die von uns erstellt wurde und viele der Windows-eigenen Werkzeuge und die bekanntesten Hacktools umfasst.

Beispiel einer Blacklist

Im folgenden Screenshot sieht man den Inhalt der Gruppe “Evil Executables”.

Inhalt der Gruppe Evil Executables

Der Inhalt der Meldung bei einem Block kann personalisiert werden.

AppSense blockt Anwendung

AppSense blockt Anwendung

Man kann die Anzeige des Benachrichtigungsfensters für die einzelnen Fälle konfigurieren und auch definieren, dass sie je nach Grund des Blocks angezeigt werden oder nicht.

Einschränkung des Netzwerkverkehrs

Einschränkung des Netzwerkverkehrs

Vor allem die umfassenden Möglichkeiten der Protokollierung ermöglichen eine nahtlose Überwachung des Systems. Jede Aktion, jeder Block, jeder Autorisierung und damit jeder Ausbruchsversuch wird sichtbar gemacht.
AppSense kann in ein CSV oder XML File auf der Platte, in das lokale Windows Application Log oder ein eigenes Windows Log namens “AppSense” protokollieren. In unserem Fall ist vor allem die Protokollierung in das Application Log von Windows von Vorteil, da wir in vielen Projekten die lokalen Windows Eventlogs bereits per Syslog verschicken und zentral auswerten.

AppSense Auditing

Konfiguration der Überwachung und Protokollierung

So kann jeder Ausbruchsversuch schnell erkannt und behandelt werden.
Im Folgenden ist eine Ansicht aus Splunk zu erkennen, in der ein Benutzer versuchte, drei für ihn nicht freigegebene Programme aufzurufen, darunter auch die Kommandozeile “cmd.exe” und den MS Terminal Server Client “mstsc.exe”.

Auswertung eines Ausbruchsversuchs in Splunk

Auswertung eines Ausbruchsversuchs in Splunk

Systeme mit RDP Schwachstelle MS12-020 im Netzwerk aufspüren

Systeme mit RDP Schwachstelle MS12-020 im Netzwerk aufspüren

In einem Artikel des Security Monitoring Blogs wird beschrieben, wie man mit Hilfe eines Nmap Skriptes die RDP Schwachstelle MS12-020 an Systemen mittels eines Netzwerkscans aufspüren kann.
Wir haben für einen unserer Kunden einen Paket des Nmap Scanners erzeugt, welches bereits das nötige Skript enthält und nur entpackt werden muss, um benutzt werden zu können. Einzig ein WinPcap muss ebenso auf dem System (mit Adminrechten) installiert werden, um das Nmap Scanner Skript anwenden zu können, da Pakete erzeugt werden müssen, die jeder Norm widersprechen. Das WinPcap Installationspaket liegt dem Paket bei und befindet sich im Hauptverzeichnis als “winpcap-nmap-4.12.exe”.
Die RDP Dienste unserer Testsysteme (Windows 7 und Windows 2003) blieben durch die Tests unberührt – d.h. stürzten nicht ab.
Das Nmap Paket der Version 5.61TEST5 mit dem Skript von Aleksandar Nikolic kann hier und aus unserer Download Sektion geladen werden.
Nach dem Download und dem Entpacken kann man nmap folgendermaßen ausführen und das lokale Netz scannen lassen. (Das Zielnetz muss entsprechend angepasst werden)

nmap.exe -sC -vv -p 3389 --script ms12-020-rev 10.1.1.0/24