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.

Plesk 0-day Workaround

Ein kürzlich bekannt gewordener 0-day Exploit für Plesk bedroht zahlreiche Server-Installationen. Betroffen sind vorasussichtlich alle Versionen vor Plesk 11. Die Lücke soll bereits genutzt worden sein, um tausende Installationen zu unterwandern. Über das ausgenutzte Plesk lassen sich weitreichende Rechte auf dem System erlangen.
Da bisher kein offizieller Patch bereit steht, empfehlen wir, den Plesk Zugriff per Firewall Regel zu unterbinden.

Plesk in aktivierter Plesk-Firewall deaktivieren – von der Kommandozeile

Die Plesk Firewall konfigurieren

vi /usr/local/psa/var/modules/firewall/firewall-active.sh

Darin die Zeilen für den Zugriff auf Plesk auskommentieren – z.B.:

#/sbin/iptables -A INPUT -p tcp --dport 8443 -j ACCEPT
#/sbin/iptables -A INPUT -p tcp --dport 8880 -j ACCEPT

Dann Plesk-Firewall neu starten:

/etc/init.d/psa-firewall restart

Plesk per iptables Regel unzugänglich machen

Zuerst sollte man prüfen, welche Regeln aktiv sind:

iptables -L -vn --line-numbers

Dort Ausschau halten nach Zeilen mit Zielport 8443 und 8880.
Wenn kaum Zeilen zu sehen sind, dann ist die Firewall nicht konfiguriert und man sollte beispielsweise eine Werkzeug wie “lokkit” verwenden, um Basisregeln auf einfache Weise auf das System zu bringen.
Wenn zahlreiche Firewall-Regeln konfiguriert sind, lohnt es sich herauszufinden, von welchem Werkzeug die Regeln auf dem System erzeugt wurden. Manchmal lässt sich das an den “Chain”-Namen ableiten.
Für schnelle Hilfe bis zu einem Restart, geht man folgendermaßen vor, wenn man ACCEPT-Zeilen für die Plesk Dienste gefunden hat.

iptables -D Chain-Name Nummer-der-Regel

also z.B.

ipatbles -D INPUT 5

Wenn man keine Firewall definiert hat oder keine Regel findet, die Plesk explizit verbietet, gibt man folgendes ein:

iptables -I INPUT 1 -p tcp --dport 8443 -j DROP
iptables -I INPUT 2 -p tcp --dport 8880 -j DROP

Das fügt ganz oben in den INPUT Chain die Regeln ein, dass niemand auf Plesk Zugriff bekommt.
Man kann die Regeln immer wieder löschen und beispielsweise nur der eigenen IP Zugriff auf Plesk geben.
Löschen

iptables -D INPUT 1
iptables -D INPUT 2

Nur eigener Zugriff (eigene IP hier als “87.12.34.56” definiert)

iptables -I INPUT 1 -p tcp -s 87.12.34.56 --dport 8443 -j ACCEPT
iptables -I INPUT 2 -p tcp -s 87.12.34.56 --dport 8880 -j ACCEPT
iptables -I INPUT 3 -p tcp --dport 8443 -j DROP
iptables -I INPUT 4 -p tcp --dport 8880 -j DROP

Die Änderungen an der Firewall sollten immer auch getestet werden, indem man versucht, die Seite aufzurufen.

Microsoft XML Core Services Schwachstelle Workaround 2719615

Laut einer Meldung des US-CERT wird derzeit die bisher ungepatchte Schwachstelle an den Microsoft Core Services aus dem Advisory 2719615 massiv ausgenutzt. Die Schwachstelle an den XML Core Services führt dazu, dass Software, die diesen Service nutzt, implizit auch Schwachstellen aufweist. Es sind alle Plattformen betroffen, auch die Serversysteme 2008 Server und Windows 7.
Die betroffene Software, die direkt per Drive-By Download zur Ausführung von Code gebracht werden kann ist:

  • Internet Explorer (alle Versionen)
  • Microsoft Office 2003
  • Microsoft Office 2007

Microsoft stellt ein Fixit in Form eines MSI Paketes bereit, mit dessen Hilfe man das Problem beheben kann. Das Advisory von Microsoft findet sich hier.
Aber auch beim Surfen mit Google Chrome und Firefox bestehen Risiken, denn diese führen häufig ein Microsoft Office Plugin mit sich, dass man sicherheitshalber deaktivieren sollte. Clients, die mit diesen Plugins Webseiten ansurfen, können mit schadhaftem Code versehene Office-Dokumente direkt im Browser aufrufen, ohne erforderliche Benutzerinteraktion. Die schadhaften Office-Dokumente werden einfach in die Website eingebettet.

Google Chrome

Die aktiven und inaktiven Plugins findet man in Chrome über die Eingabe von “about:plugins” in der URL Leiste. Das Plugin “Microsoft Office” ist zu deaktivieren.

Mozilla Firefox

In Firefox wählt man am Besten den Weg über “Firefox > Add-ons > Plugins”. Hier deaktiviert man das “Microsoft Office Live Plugin for Firefox …”.

Java Schwachstelle

Java Schwachstelle

Das im Browser als Plugin hinterlegte Java Runtime Environment weißt wieder einmal eine schwerwiegende Schwachstelle auf, die Angreifer derzeit gezielt ausnutzen. Nach Angaben von heise Security wurde eine Exploit, welches diese Lücke adressiert, in das BlackHole Exploit-Kit aufgenommen.
Sie sollten so bald wie möglich auf allen Arbeitsstationen mit Internetzugang eine aktuelle Version installieren oder Java gegebenenfalls deaktivieren, falls es betrieblich nicht zwingend erforderlich ist.
Unter diesem Link können Sie die aktuell in Ihrem Browser verwendete Java Version bestimmen lassen.
Java kontrollieren und ggfs. deaktivieren für den verschiedenen Browser:
Internet Explorer 8
Unter Extras > Add-ons verwalten

Mozilla Firefox
Unter Extras (bzw. Firefox Button) > Add-ons > Plugins

Google Chrome
In der URL-Leiste (Omibar) eingeben: about:plugins
Plesk Sicherheitsproblem mit Microupdates lösen

Plesk Sicherheitsproblem mit Microupdates lösen

Ein Sicherheitsproblem im Server-Management-Werkzeug Plesk bedroht viele über dieses System gemanagte Serversysteme. In einem heute veröffentlichten heise-Alert wird das Problem beschrieben und auch auf die Workarounds für ältere Systeme verlinkt. Die Lücke wird nach Angaben heises bereits aktiv ausgenutzt.
Alte Plesk Versionen können mit Hilfe des “Autoinstallers” für Micro-Updates mit dem Fix versorgt werden.
Konkret empfiehlt sich folgendes Vorgehen:
1. Plesk Home Directory finden bzw. Version feststellen

dpkg -l | grep plesk 

bzw.

find / -name "autoinstaller*"

2. In das “sbin” Verzeichnis wechseln
z.B.

cd /opt/psa/admin/sbin/

3. dann folgenden Befehl ausführen

autoinstaller --select-product-id plesk --select-release-current --reinstall-patch --install-component base

Auf diese Weise können Sie Ihre Plesk Installation schnell fixen.

GDPR Cookie Consent with Real Cookie Banner