Microsoft SCCM ist eines jener Produkte, für das ich eine ausgeprägte „Hassliebe“ pflege. Vollautomatisierte Betriebssysteminstallation, Patchmanagement mit hohem Informationsgehalt, standardisierte Softwareverteilung… seit über 10 Jahren hilft SCCM mir in vielen Bereichen, sehr viel Zeit zu sparen und „ordentliche IT“ zu betreiben. Selbst für unser kleines Office könnte ich mir Systemmanagement ohne SCCM nicht vorstellen.
Doch manchmal macht mich das Produkt schlichtweg Wahnsinnig – Logfiles sind ein Kapitel für sich, alleine das Wissen wo man welche Infos findet, ist eine 2-tägige Schulung wert. Mangelnde Transparenz – warum passiert gerade was wo auf welchem Gerät und warum vielleicht auch nicht – verleiten häufig dazu, dem Monitor frustriert eine saftige Abreibung zu verpassen. Und ein mittelkomplexes Netzwerk mit SCCM zu betreuen erfordert definitiv Expertenwissen beim Einrichten oder das Projekt geht den Bach hinunter.

Trotzdem: ohne SCCM geht’s bei mir einfach nicht, und besonders wenn man auf IT-Sicherheit schauen will ist ein zentrales Systemmanagement unumgänglich. Umso positiver Empfinde ich die Entwicklung, die das Produkt in den letzten Jahren gemacht hat. Es gab dann doch einige spürbare Verbesserungen (zb: Self-Update) in letzter Zeit, und vor kurzem kam ein ganz spannendes neues Feature hinzu: 3rd-Party-Patching über den integrierten Softwarekatalog!

Das heisst, SCCM ist nun endlich(!) in der Lage, auch non-Microsoft-Produkte über das integrierte Patch-Management auf Stand zu halten – vorher war dazu die Installation von Zusatzprodukten nötig. Die Patch-Daten müssen natürlich von irgendwoher kommen, so bieten Hersteller wie HP oder DELL beispielsweise entsprechende Kataloge an, für den folgenden Feature-test reicht das Trial-Angebot von „PatchMyPC“, den wir kurzerhand einrichten:

 

Ein kurzer Sync später, Zertifikat verifizieren („Subscribe“), und wir können den Katalog abrufen:

 

im Logfile finden wir den Vorgang bestätigt:

Im Software Update Point das 3rdParty-Feature aktivieren, den interne-WSUS-DB-Sync abwarten, die neuen Kategorien aktivieren, und nochmal syncen. Wie war das mit der Hassliebe?!

 

Das Ergebnis ist für einen SCCM Admin höchst erfreulich – die Produktpatches erscheinen im zentralen Katalog, von wo der Standardworkflow erfolgen kann (manuelles Deployment oder Auto-Rule….).

Happy Patching!

 

 

Hack the Hash

Eines unserer Workshop-Themen ist „Password Security“, hier erklären wir unter anderem, wie wichtig es ist auf die Länge des Passwortes zu achten. Je mehr Zeichen ein Password hat, desto schwieriger kann es „errechnet“ werden. Ein Real-World-Example bekamen wir nun selbst bei einem Pentest zu spüren, den wir für einen Kunden durchgeführt haben.

Konkret: David ist bereits via Trojaner am Kundenrechner und scannt SPNs in der Domain. Er löst mit den „Kerberoast“ Tools ein Service Ticket, und extrahiert den darin enthaltenen Hashwert des Passwortes (wie genau das funktioniert, lernt ihr in unserem Advanced Hacking Workshop). Was machen wir nun mit dem Hash? Zurückrechnen geht ja nicht – aber man kann alle möglichen Passwortkombinationen durchprobieren, mit dem Hash vergleichen, und schauen ob man das Service-Passwort „errät“.

Los gehts!

Hashcat für Arme

Wir speisen den erbeuteten Hashwert ins Profi-Crack-Tool „HASHCAT“ und geben einige Rahmenbedingungen vor (zb Zeichenanzahl, Muster, etc..).

Am Lab-Notebook schaut der Versuch allerdings etwas….. traurig aus. Für ein 6-stelliges Passwort rechnet man noch gute 2 Stunden herum, aber bei 8 Stellen steigt die Zeit auf 40 Jahre an. Womit bewiesen wäre, dass diese 8 Stellen mehr als ausreichend sind, um ein „sicheres“ Passwort zu verwenden.

Doch damit geben wir uns nicht zufrieden! Ganz klar, ab zum nächsten Media Markt, einen Pack High-End GPUs einkaufen und eine Hashcrack-Workstation aufbauen.

Das Problem: Kostenpunkt über 10.000 €. Und was tut man dann mit diesem Monster, ausser wertvolle Zeit mit 3D-Games verbraten? (Wer jetzt „Bitcoin Mining“ sagt, verlässt bitte umgehend den Blog…. 🙂)

 

Hashcat für Profis

Viel einfacher und vor allem kosteneffizienter ist es, sich so eine Power-Workstation einfach zu mieten – und zwar in der AWS Cloud. Dort gibt es quasi auf Knopfdruck eine fertig vorinstallierte Kali Linux VM mit wahlweise 1, 8 oder 16 NvidiaK80 GPUs (P2-Tier) oder 1, 4 oder 8 Nvidia V100 GPUS (P3-Tier). Der Kostenpunkt hierbei dreht sich um Stundenweise gerade mal einen € bis hin zu 24€ für die High-End-Variante.

Die Hashcat-Zeiten sehen dann auf einmal sogar richtig brauchbar aus:

Hier ein paar Vergleichswerte:

P2.x (1x Nvidia k80) – $1/h
8 Stellen – 1 Jahr 67 Tage
7 Stellen – 5 Tage 22 Stunden
6 Stellen – 1 Stunde 50 Minuten

P3.2x (1x Nvidia V100) – $3/h
8 Stellen – 19 Tage
7 Stellen – 6 Stunden
6 Stellen – 5 Minuten

P3.8x (4x Nvidia V100) – $12.3/h
8 Stellen – 5 Tage 10 Stunden
7 Stellen – 1 Stunde 45 Minuten
6 Stellen – 1 Minute

(Die P3.18x Variante mit 8x Nvidia V100 haben wir nicht mehr getestet. Bei 8 Stellen schätze ich die Rechenzeit aber grob auf 2.5 Tage.)

Um den Bogen zum Eingangs erwähnten Password-Security Workshop zu spannen: es ist für ganz normale Consumer mittlerweile möglich, 8-Stellige Passwörter in 2-3 Tagen zu errechnen – für etwas weniger als 200€. Wer in der Verantwortung steht, sollte sich daher überlegen, eine Mindestlänge von mehr als 8 Zeichen in der Passwortrichtlinie zu setzen. Bei Service-Accounts ist die Verwendung von MSA / Group-MSA empfehlenswert oder der Einsatz eines Remote-Password-Changer Tools. Weitere Tipps und Tricks gibts in unseren Workshops!

In diesem Sinne: Hack on!

 

PS: Der hier im Artikel zu errechnende Hash war vom Typ „Kerberos 5 TGS-REP etype 23“. Andere Hashtypen, wie zb NTLM sind unter Umständen noch wesentlich schneller berechenbar. Es soll hier konkret gezeigt werden, wie „einfach“ es bereits geworden ist, tiefgehende Systemvorgänge (Kerberos Ticket Exchange) zu knacken.


 

 

Ein kleines Update zu unseren Workshop-Inhalten:

Seit Version 6.7.0 unterstüzt ESX nun endlich „Virtualization Based Security“, eine der Grundvoraussetzungen für den Einsatz von Credential Guard. Bisher war man hierzu zwingend auf Hyper-V am Host angewiesen.

https://blogs.vmware.com/vsphere/2018/05/introducing-support-virtualization-based-security-credential-guard-vsphere-6-7.html

 

Wer sich jetzt schon freut – wie ich – Credential Guard auf seinen Servern aktivieren zu können, der wird enttäuscht werden.

 

 

Eine weitere Voraussetzung für Credential Guard ist nämlich das vorhanden sein eines TPM-Chips. Eine VM hat so etwas natürlich nicht, also muss man mit einem virtuellen TPM-Chip nachhelfen. Doch blöderweise ist das bei VMWare nur möglich, wenn man einen VSphere Key Management Server betreibt und seine VMs encrypted….. was in unserer Lab-Umgebung leider aus Ressourcengründen (noch) nicht eingerichtet wurde.

Schade!

 

PS: Ohne es im Detail geprüft zu haben, hier gibt es Möglicherweise eine kostenfreie VSphere-KMS Lösung

Attack! … or not?

Bei einem kürzlich durchgeführten Pentest für einen Kunden geschah das Unerwartete: Wir konnten trotz allen Anstrengungen keine C2-Verbindung zum Opfer herstellen.

Am Phishing-Mail dürfte es nicht liegen, denn die ersten User klickten bereits unseren Link an („Bitte installieren sie das verlinkte Plugin um ihren PC auf DSGVO-Kompatibilität zu prüfen“ ist zwar gemein, funktioniert aber). Der Kundenseitige Mailfilter war also nicht Schuld. Am Webserver sahen wir Zugriffslogs auf den ersten Stage der Schadsoftware. Kurz darauf, Nachladen der zweiten Stage. Doch dann – nichts! Es fand keine C2-Kommunikation statt.

Hat der Kunde einen besonders guten Virenscanner? Oder eine neuartige Firewall-Lösung, von der wir nichts wussten? War ein Security-Admin vor Ort, der sein Handwerk versteht und uns zum Narren hält? Ist eine moderne EDR-Lösung im Einsatz? Ganz klar, wir mussten der Sache auf den Grund gehen.

 

Debugging

Im Testlab installierten wir ein der Kundensituation ähnliches Systemumfeld, und fanden dabei (eher durch Zufall) folgende Situation vor:

Ein Powershell-Befehl unseres Staging-Scripts konnte nicht ausgeführt werden – genauer gesagt: System.Text.Encoding soll angeblich nicht existieren?  Diese Klasse ist aber Bestandteil der Standard-Assemblies, und existiert auf jedem System. Und bei unseren Tests vor dem eigentlichen Angriff trat der Fehler auch nicht auf (ja, selbstverständlich testen wir unsere eigenen Hacks 😉 )

Der Fehler lag im „Nichts“: wer genau hinsieht, wird zwischen Encoding und ] ein Leerzeichen erkennen. Diese Technik benutzen wir (unter anderem) gerne für Obfuskierungen von Malicious Code, was erschreckenderweise in vielen Fällen ausreicht, um AV und IDS Systeme zu umgehen. In diesem Fall scheint das Leerzeichen aber dazu zu führen, dass der Parser die PS-Syntax nicht mehr akzeptiert. Doch wieso funktioniert auf unseren Testsystemen alles?

 

Patch me up, Scotty

Auf Windows 10 (beliebige Versionen) wird das Leerzeichen ignoriert:

 

Auf einem Windows 7 SP1 jedoch nicht:

 

Die Moral der Geschichte: Liebe Kunden, bitte updated eure Systeme, sonst funktionieren manche obfuskierte Pentest-Scripts nicht 🙂

 

Beim Einrichten von DNS-Blocklisten auf unserem Proofpoint-Lab-System erscheint folgende Fehlermeldung:

Ein Packet Capture auf der Firewall zeigt uns eine DNS Abfrage auf 2.0.0.127.zen.spamhaus.org, welche manuell mit nslookup nachgestellt eine „Non-existent domain“ Response erzeugt. Das Hinzufügen anderer DNS-Blocklisten, wie b.barracudacentral.org, liefert korrekte DNS-Responses. Warum das?

Nach etwas Recherche finden wir zwei hilfreiche Beiträge [1] [2] und stellen den gefundenen Fakt kurzerhand nach:

Interessant… das Google DNS Service erzeugt hier NXDOMAIN, während andere DNS Dienste wie Cloudflare oder OpenDNS korrekte DNS-Responses liefern.

Abhilfe schaffen wir kurzerhand auf der Palo Firewall, und zwar mit einer DNS Proxy Rule:

Problem solved:

Microsoft hat in den aktuellsten Windows 10 Versionen 1709 und 1803 einige Sicherheitsfeatures in Windows Defender integriert, welche das Risiko einer Malware-Infektion stark reduzieren sollen. Uns Pentester treffen diese Mitigations potentiell recht schmerzhaft, da sie das derzeitige Schadsoftware-Einfallstor #1 direkt absichern (sollen): Email und Office-Applikationen. Windows 10 und ein aktuell gehaltener Windows Defender sind bereits im Default-Zustand recht effektiv – Grund genug, zu testen ob die zusätzlichen Features die Latte noch höher legen können!

Allgemeine Infos über die Attack Surface Reduction findet man in der Microsoft Dokumentation.

Wir starten mit einem generellen Funktionstest: Mit Kali Linux und Unicorn erstellen wir eine Fileless Malware und verstecken diese in einem Word-2003-Macro, welches beim Öffnen des Dokuments automatisch ausgeführt wird. Dabei wird eine Meterpreter Session zum Angreifer erzeugt.

Wir testen ausserdem die Tools Mimikatz und Kekeo, einerseits um Credentials, andererseits um Kerberos Ticket auszulesen:

Nun konfigurieren wir Defender, idealerweise über Group Policies, denn wir sind Enterprisey 😉 Die offizielle Anleitung ist hier zu finden.
An dieser Stelle auch noch der Hinweis auf ein Beispiel-Ruleset im sehr hilfreichen Blog von Gunnar Haslinger.

Nach gpupdate /force am Testclient führen wir das Malware-verseuchte Word-File neu aus. Wie auf den folgenden Screenshots zu sehen, wird der Angriff erfolgreich blockiert.

 

Unsere Angriffe mit Mimikatz und Kekeo zeigen sich jedoch vom neuen Schutzmechanismus recht unbeeindruckt. Wir können weiterhin Kerberos-Tickets exportieren und Passwörter auslesen.

Dafür bekommen wir nun auf unseren Lab-Notebooks alle paar Sekunden eine Warnmeldung von Defender, die nach näherer Betrachtung im Eventlog von VmWare Workstation auszugehen scheint. Ohne dem näher nachzugehen – das wäre im Produktivbetrieb so nicht brauchbar.

Auf der Microsoft ASR Demo Page  findet sich leider kein Testcase zum Feature lsass Protection / 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 – wir haben mal nachgefragt, was Sache ist. Sollte eine brauchbare Antwort eintreffen, werden wir den Blogpost updaten!

 

Das Unsigned-Executable-From-USB-Stick-Feature haben wir auch kurz probiert:

Dies funktioniert wie erwartet. Es stellt sich aber die Frage, ob dies in der Praxis einen relevanten Schutz darstellt. Selbst das oben genannte Tool Mimikatz ist vom Programmierer digital signiert und wird daher nicht blockiert (um genau zu sein: Defender blockiert das File erfolgreich, aber aufgrund der AV-Signatur, nicht aufgrund der ASR-Settings). Eine Whitelisting, Application Control oder USB-Management Lösung ersetzt das Feature daher nicht.

 

Fazit:
Auf den ersten Blick stellen einige (wenige) der verfügbaren Protection Settings tatsächlich eine größere Hürde für Angreifer dar, zumindest wenn man default-Scriptkiddie-Attacken aus Google-Anleitungen betrachtet.  Inwieweit dieser Schutzmechanismus doch noch umgangen werden kann, wird sich noch zeigen – Child-Prozesse aus Office-Anwendungen heraus nicht mehr erzeugen zu können, dürfte aber schon mal sehr effektiv sein – sofern nicht durch irgendeinen Business-Case nicht im Unternehmen implementierbar.

Windows Defender ist unserer Praxiserfahrung nach daher zu einem ziemlich bissigen Antimalware-Tool geworden und dem ein oder anderen namhaften Konkurrenten duchaus überlegen. Wer Defender im Unternehmen einsetzt, sollte die neuen Mitigations daher unbedingt austesten!

 

Security-Roundtable Innsbruck am 14.06.2018

Der Security-Roundtable ist gedacht für den lockeren Austausch zwischen den Teilnehmern und Hacker-Profis. In unserem Hacking-Lab wird ein von unseren Kunden favorisiertes Thema präsentiert und workshop-artig besprochen – dies soll einen technischen Erfahrungsaustausch untereinander initiieren. Im locker gesetzten Rahmenprogramm moderieren wir diesmal folgendes Szenario:

Wir planen gemeinsam einen gezielten Cyberangriff anhand der Cyber-Kill Chain:
Unsere live erstelle Schadsoftware wird aktuelle AV-Lösungen umgehen und uns als Türöffner für eine persistente C2-Verbindung in ein Unternehmen dienen. Nach dem Download sensibler Firmen-Dokumente (GDPR) finden wir das schwächste Glied im Server-Netz und bewegen uns lateral durch pass-the-hash/ticket Richtung Domain-Admin-Rechte. Parallel dazu betrachten wir, welche Spuren Angreifer hinterlassen (Indicators of attack/compromise) und zeigen die Ansätze von EDR Lösungen am Markt auf.

Nerd specs: Wir stellen Angriffe der Hackergruppe APT3 nach, nehmen Bezug auf das MITRE Attack Framework und zeigen so technisch wichtige Details  für Angriff wie auch Verteidigung auf.

Datum: 14.06.2018 16:30-20:00 Uhr
Ort: SoHo2 Grabenweg 68 – Konferenzraum im Penthouse (OG4, nach Lift links)
Parken: Tiefgarage vorhanden
Kosten: kostenlos

Anmeldung: kurzes Mail an workshops@strong-it.at erleichtert passende Bestuhlung und Getränke-Sizing.