Dieser Artikel wurde auf der Grundlage eines sehr erfolgreichen Pentests geschrieben, den die Spezialisten der Group-IB vor einigen Jahren durchgeführt haben: Dabei ereignete sich eine Geschichte, die für einen Film in Bollywood adaptiert werden könnte. Jetzt wird die Reaktion des Lesers wahrscheinlich folgende sein: „Oh, schon wieder ein PR-Artikel, die werden wieder dargestellt, wie gut sie sind, vergessen Sie nicht, einen Pentest zu kaufen.“ Nun ja, einerseits ist es so. Es gibt jedoch noch eine Reihe anderer Gründe, warum dieser Artikel erschien. Ich wollte zeigen, was Pentester genau machen, wie interessant und nicht trivial diese Arbeit sein kann, welche lustigen Umstände in Projekten auftreten können und vor allem Live-Material mit realen Beispielen zeigen.
Um das Gleichgewicht der Bescheidenheit in der Welt wiederherzustellen, werden wir nach einer Weile über einen Pentest schreiben, der nicht gut gelaufen ist. Wir zeigen, wie gut gestaltete Prozesse in einem Unternehmen vor einer ganzen Reihe von Angriffen schützen können, auch wenn sie gut vorbereitet sind, einfach weil diese Prozesse existieren und tatsächlich funktionieren.
Für den Kunden in diesem Artikel war im Großen und Ganzen auch alles ausgezeichnet, nach unserem Empfinden zumindest besser als 95 % des Marktes in der Russischen Föderation, aber es gab eine Reihe kleiner Nuancen, die eine lange Kette von Ereignissen bildeten, die zunächst einmal führte zu einem langen Bericht über die Arbeit und dann zu diesem Artikel.
Also, füllen wir uns mit Popcorn und willkommen in der Detektivgeschichte. Wort - Pavel Suprunjuk, technischer Leiter der Abteilung „Audit und Consulting“ der Group-IB.
Teil 1. Pochkin-Arzt
2018 Es gibt einen Kunden – ein High-Tech-IT-Unternehmen, das selbst viele Kunden bedient. Möchten Sie eine Antwort auf die Frage erhalten: Ist es möglich, ohne Vorkenntnisse und Zugang über das Internet Active Directory-Domänenadministratorrechte zu erhalten? Ich bin nicht an Social Engineering interessiert (), haben sie nicht die Absicht, die Arbeit absichtlich zu stören, aber sie können versehentlich – zum Beispiel einen seltsam funktionierenden Server neu laden. Ein weiteres Ziel besteht darin, möglichst viele weitere Angriffsvektoren gegen den äußeren Perimeter zu identifizieren. Das Unternehmen führt solche Tests regelmäßig durch, nun ist die Frist für einen neuen Test gekommen. Die Bedingungen sind nahezu typisch, ausreichend, verständlich. Lass uns anfangen.
Es gibt einen Namen des Kunden – sei es „Firma“ mit der Hauptwebsite . Natürlich wird der Kunde anders genannt, aber in diesem Artikel wird alles unpersönlich sein.
Ich führe Netzwerkaufklärung durch – finde heraus, welche Adressen und Domains beim Kunden registriert sind, zeichne ein Netzwerkdiagramm, wie Dienste an diese Adressen verteilt werden. Ich erhalte das Ergebnis: mehr als 4000 Live-IP-Adressen. Ich schaue mir die Domänen in diesen Netzwerken an: Glücklicherweise handelt es sich bei der überwiegenden Mehrheit um Netzwerke, die für die Kunden des Kunden bestimmt sind, und wir haben kein formelles Interesse an ihnen. Der Kunde denkt das Gleiche.
Es bleibt ein Netzwerk mit 256 Adressen übrig, für das zu diesem Zeitpunkt bereits ein Verständnis der Verteilung von Domains und Subdomains nach IP-Adressen besteht, es gibt Informationen zu den gescannten Ports, sodass Sie die Dienste nach interessanten durchsuchen können. Parallel dazu werden alle Arten von Scannern auf verfügbaren IP-Adressen und separat auf Websites gestartet.
Es gibt viele Dienstleistungen. Normalerweise ist dies eine Freude für den Pentester und die Erwartung eines schnellen Sieges, denn je mehr Dienste es gibt, desto größer ist das Angriffsfeld und desto einfacher ist es, ein Artefakt zu finden. Ein kurzer Blick auf die Websites zeigte, dass es sich bei den meisten um Weboberflächen bekannter Produkte großer Weltkonzerne handelt, die einem auf den ersten Blick vermitteln, dass sie nicht willkommen sind. Sie fragen nach einem Benutzernamen und einem Passwort, schütteln das Feld zur Eingabe des zweiten Faktors aus, fragen nach einem TLS-Client-Zertifikat oder senden es an Microsoft ADFS. Auf einige kann über das Internet einfach nicht zugegriffen werden. Für einige müssen Sie natürlich einen speziellen bezahlten Kunden für drei Gehälter haben oder die genaue URL kennen, die Sie eingeben müssen. Lassen Sie uns eine weitere Woche allmählicher Verzweiflung überspringen, während wir versuchen, Softwareversionen nach bekannten Schwachstellen zu „durchbrechen“, nach versteckten Inhalten in Webpfaden und durchgesickerten Konten von Drittanbieterdiensten wie LinkedIn zu suchen und auch zu versuchen, damit Passwörter zu erraten B. das Ausgraben von Schwachstellen in selbst geschriebenen Websites – laut Statistik ist dies übrigens heute der vielversprechendste Vektor für externe Angriffe. Ich werde sofort die Filmpistole bemerken, die anschließend abgefeuert wurde.
Also haben wir zwei Websites gefunden, die sich von Hunderten von Diensten abheben. Eines hatten diese Websites gemeinsam: Wenn Sie das Netzwerk nicht akribisch nach Domänen auskundschaften, sondern direkt nach offenen Ports suchen oder einen Schwachstellenscanner mit einem bekannten IP-Bereich ins Visier nehmen, werden diese Websites dem Scan entgehen und dies einfach nicht tun sichtbar, ohne den DNS-Namen zu kennen. Vielleicht wurden sie zumindest früher übersehen und unsere automatischen Tools stellten keine Probleme damit fest, selbst wenn sie direkt an die Ressource gesendet wurden.
Übrigens, darüber, was zuvor eingeführte Scanner im Allgemeinen gefunden haben. Ich möchte Sie daran erinnern: Für manche Menschen ist „Pentest“ gleichbedeutend mit „automatischer Scan“. Aber die Scanner dieses Projekts sagten nichts. Nun, das Maximum zeigten mittlere Schwachstellen (3 von 5 in Bezug auf den Schweregrad): bei einigen Diensten ein schlechtes TLS-Zertifikat oder veraltete Verschlüsselungsalgorithmen und bei den meisten Websites Clickjacking. Aber das wird Sie nicht an Ihr Ziel bringen. Vielleicht wären hier Scanner nützlicher, aber ich möchte Sie daran erinnern: Der Kunde selbst hat die Möglichkeit, solche Programme zu kaufen und sie damit zu testen, und er hat es, den düsteren Ergebnissen nach zu urteilen, bereits überprüft.
Kehren wir zu den „anomalen“ Seiten zurück. Das erste ist so etwas wie ein lokales Wiki unter einer nicht standardmäßigen Adresse, aber in diesem Artikel sei es wiki.company[.]ru. Sie fragte auch sofort nach einem Login und einem Passwort, allerdings über NTLM im Browser. Für den Benutzer sieht dies wie ein asketisches Fenster aus, in dem er zur Eingabe eines Benutzernamens und eines Passworts aufgefordert wird. Und das ist eine schlechte Praxis.
Eine kleine Anmerkung. NTLM in Perimeter-Websites ist aus mehreren Gründen schlecht. Der erste Grund besteht darin, dass der Active Directory-Domänenname offengelegt wird. In unserem Beispiel stellte sich heraus, dass es sich ebenso um „company.ru“ handelte, genau wie der „externe“ DNS-Name. Wenn Sie dies wissen, können Sie einen Schädling sorgfältig vorbereiten, sodass er nur auf dem Domänencomputer der Organisation und nicht in einer Sandbox ausgeführt wird. Zweitens erfolgt die Authentifizierung direkt über NTLM über den Domänencontroller (Überraschung, oder?), mit allen Funktionen der „internen“ Netzwerkrichtlinien, einschließlich der Sperrung von Konten, damit die Anzahl der Passworteingabeversuche nicht überschritten wird. Wenn ein Angreifer die Logins herausfindet, versucht er es mit Passwörtern dafür. Wenn Sie so konfiguriert sind, dass Konten die Eingabe falscher Passwörter verhindern, funktioniert dies und das Konto wird gesperrt. Drittens ist es unmöglich, einer solchen Authentifizierung einen zweiten Faktor hinzuzufügen. Wenn einer der Leser noch weiß, wie es geht, lassen Sie es mich bitte wissen, es ist wirklich interessant. Viertens: Anfälligkeit für Pass-the-Hash-Angriffe. ADFS wurde unter anderem zum Schutz vor all dem erfunden.
Es gibt eine schlechte Eigenschaft von Microsoft-Produkten: Selbst wenn Sie ein solches NTLM nicht ausdrücklich veröffentlicht haben, wird es zumindest in OWA und Lync standardmäßig installiert.
Der Autor dieses Artikels hat übrigens einmal aus Versehen mit der gleichen Methode in nur einer Stunde rund 1000 Konten von Mitarbeitern einer Großbank gesperrt und sah dann etwas blass aus. Die IT-Dienste der Bank waren ebenfalls blass, aber alles endete gut und angemessen. Wir wurden sogar dafür gelobt, dass wir die ersten waren, die dieses Problem fanden und eine schnelle und entscheidende Lösung herbeiführten.
Die zweite Seite hatte die Adresse „offensichtlich eine Art Nachname.company.ru“. Habe es über Google gefunden, etwa so auf Seite 10. Das Design stammte aus den frühen bis mittleren XNUMXer-Jahren und eine angesehene Person betrachtete es von der Hauptseite aus, etwa so:
Hier habe ich ein Standbild aus „Heart of a Dog“ gemacht, aber glauben Sie mir, es war vage ähnlich, sogar die Farbgestaltung war in ähnlichen Tönen gehalten. Lassen Sie die Site aufrufen preobrazhensky.company.ru.
Es war eine persönliche Website... für einen Urologen. Ich fragte mich, was die Website eines Urologen auf der Subdomain eines High-Tech-Unternehmens machte. Ein kurzer Blick auf Google ergab, dass dieser Arzt Mitbegründer einer juristischen Person unseres Kunden war und sogar etwa 1000 Rubel in das genehmigte Kapital einbrachte. Die Site wurde wahrscheinlich vor vielen Jahren erstellt und die Serverressourcen des Kunden wurden als Hosting genutzt. Die Seite hat längst ihre Relevanz verloren, aber aus irgendeinem Grund blieb sie lange Zeit funktionsfähig.
Hinsichtlich der Schwachstellen war die Website selbst sicher. Mit Blick auf die Zukunft werde ich sagen, dass es sich um eine Reihe statischer Informationen handelte – einfache HTML-Seiten mit eingefügten Abbildungen in Form von Nieren und Blasen. Es ist sinnlos, eine solche Site zu „zerstören“.
Aber der Webserver darunter war interessanter. Dem HTTP-Server-Header nach zu urteilen, war IIS 6.0 installiert, was bedeutet, dass Windows 2003 als Betriebssystem verwendet wurde. Der Scanner hatte zuvor festgestellt, dass diese spezielle Urologen-Website im Gegensatz zu anderen virtuellen Hosts auf demselben Webserver auf den PROPFIND-Befehl reagierte, was bedeutete, dass sie WebDAV ausführte. Der Scanner hat diese Information übrigens mit der Markierung Info zurückgegeben (in der Sprache der Scannerberichte ist dies die geringste Gefahr) – solche Dinge werden meist einfach übersprungen. In Kombination ergab dies einen interessanten Effekt, der erst nach einer weiteren Suche bei Google enthüllt wurde: eine seltene Pufferüberlauf-Schwachstelle im Zusammenhang mit dem Shadow Brokers-Set, nämlich CVE-2017-7269, für die es bereits einen fertigen Exploit gab. Mit anderen Worten: Wenn Sie Windows 2003 verwenden und WebDAV auf IIS ausgeführt wird, treten Probleme auf. Obwohl die Ausführung von Windows 2003 in der Produktion im Jahr 2018 an sich schon ein Problem darstellt.
Der Exploit landete in Metasploit und wurde sofort mit einer Last getestet, die eine DNS-Anfrage an einen kontrollierten Dienst sendete – Burp Collaborator wird traditionell zum Abfangen von DNS-Anfragen verwendet. Zu meiner Überraschung funktionierte es beim ersten Mal: Es wurde ein DNS-Knockout empfangen. Als nächstes wurde versucht, über Port 80 einen Backconnect herzustellen (also eine Netzwerkverbindung vom Server zum Angreifer mit Zugriff auf cmd.exe auf dem Host des Opfers), doch dann kam es zu einem Fiasko. Die Verbindung kam nicht zustande und nach dem dritten Versuch, die Seite mit all den interessanten Bildern zu nutzen, verschwand sie für immer.
Normalerweise folgt darauf ein Brief im Stil von „Kunde, wach auf, wir haben alles fallen lassen.“ Uns wurde jedoch gesagt, dass die Site nichts mit Geschäftsprozessen zu tun hat und dort wie der gesamte Server völlig grundlos funktioniert und dass wir diese Ressource nach Belieben nutzen können.
Ungefähr einen Tag später begann die Site plötzlich selbstständig zu arbeiten. Nachdem ich eine Bank aus WebDAV auf IIS 6.0 erstellt hatte, stellte ich fest, dass die Standardeinstellung darin besteht, IIS-Arbeitsprozesse alle 30 Stunden neu zu starten. Das heißt, als die Steuerung den Shellcode verließ, wurde der IIS-Arbeitsprozess beendet, dann startete er sich selbst ein paar Mal neu und ging dann für 30 Stunden in den Ruhezustand.
Da die Rückverbindung zu TCP beim ersten Mal fehlschlug, habe ich dieses Problem auf einen geschlossenen Port zurückgeführt. Das heißt, er ging davon aus, dass eine Art Firewall vorhanden war, die den Durchgang ausgehender Verbindungen nach draußen verhinderte. Ich habe angefangen, Shellcodes auszuführen, die viele TCP- und UDP-Ports durchsucht haben, es gab keine Wirkung. Das Laden umgekehrter Verbindungen über http(s) von Metasploit funktionierte nicht – meterpreter/reverse_http(s). Plötzlich wurde eine Verbindung zum selben Port 80 aufgebaut, die jedoch sofort abgebrochen wurde. Ich führte dies auf die Wirkung des noch imaginären IPS zurück, dem der Meterpreter-Verkehr nicht gefiel. Angesichts der Tatsache, dass eine reine TCP-Verbindung zu Port 80 nicht zustande kam, eine http-Verbindung jedoch schon, kam ich zu dem Schluss, dass im System irgendwie ein http-Proxy konfiguriert war.
Ich habe Meterpreter sogar über DNS ausprobiert (danke). (Danke für Ihre Bemühungen, viele Projekte gerettet) und erinnern an den allerersten Erfolg, aber es funktionierte nicht einmal am Stand – der Shellcode war zu umfangreich für diese Schwachstelle.
In Wirklichkeit sah es so aus: 3-4 Angriffsversuche innerhalb von 5 Minuten, dann 30 Stunden warten. Und so weiter, drei Wochen hintereinander. Ich habe sogar eine Erinnerung eingerichtet, um keine Zeit zu verschwenden. Darüber hinaus gab es einen Unterschied im Verhalten der Test- und Produktionsumgebungen: Für diese Schwachstelle gab es zwei ähnliche Exploits, einen von Metasploit, den zweiten aus dem Internet, konvertiert aus der Shadow Brokers-Version. Daher wurde nur Metasploit im Kampf getestet und nur der zweite wurde auf der Bank getestet, was das Debuggen noch schwieriger machte und den Kopf zermürbte.
Am Ende erwies sich ein Shellcode als effektiv, der eine exe-Datei von einem bestimmten Server über http herunterlud und auf dem Zielsystem startete. Der Shellcode war klein genug, um hineinzupassen, aber zumindest funktionierte er. Da der Server den TCP-Verkehr überhaupt nicht mochte und http(s) auf das Vorhandensein von meterpreter überprüft wurde, entschied ich, dass der schnellste Weg darin bestand, über diesen Shellcode eine Exe-Datei herunterzuladen, die DNS-meterpreter enthielt.
Auch hier trat ein Problem auf: Beim Herunterladen einer exe-Datei und, wie Versuche zeigten, egal welcher, brach der Download ab. Wieder einmal mochte eine Sicherheitsvorrichtung zwischen meinem Server und dem Urologen keinen HTTP-Verkehr mit einer darin enthaltenen Exe-Datei. Die „schnelle“ Lösung schien darin zu bestehen, den Shellcode so zu ändern, dass er den HTTP-Verkehr im laufenden Betrieb verschleiert, sodass abstrakte Binärdaten anstelle von Exe-Daten übertragen werden. Schließlich war der Angriff erfolgreich, die Kontrolle erfolgte über den Thin-DNS-Kanal:
Es wurde sofort klar, dass ich über die grundlegendsten IIS-Workflow-Rechte verfüge, die es mir ermöglichen, nichts zu tun. So sah es auf der Metasploit-Konsole aus:
Alle Pentest-Methoden deuten stark darauf hin, dass Sie die Zugriffsrechte erhöhen müssen. Normalerweise mache ich das nicht lokal, da der allererste Zugriff einfach als Netzwerkeintrittspunkt angesehen wird und die Kompromittierung eines anderen Computers im selben Netzwerk normalerweise einfacher und schneller ist als die Erweiterung der Berechtigungen auf einem vorhandenen Host. Dies ist hier jedoch nicht der Fall, da der DNS-Kanal sehr eng ist und keine Freigabe des Datenverkehrs möglich ist.
Unter der Annahme, dass dieser Windows 2003-Server nicht wegen der berühmten MS17-010-Schwachstelle repariert wurde, tunnele ich den Datenverkehr zu Port 445/TCP durch den Meterpreter-DNS-Tunnel auf Localhost (ja, das ist auch möglich) und versuche, die zuvor heruntergeladene Exe-Datei darüber auszuführen die Verletzlichkeit. Der Angriff funktioniert, ich erhalte eine zweite Verbindung, allerdings mit SYSTEM-Rechten.
Interessant ist, dass sie trotzdem versuchten, den Server vor MS17-010 zu schützen – auf der externen Schnittstelle waren anfällige Netzwerkdienste deaktiviert. Dies schützt zwar vor Angriffen über das Netzwerk, aber der Angriff von innen auf localhost hat funktioniert, da man SMB auf localhost nicht einfach schnell deaktivieren kann.
Als nächstes werden neue interessante Details enthüllt:
- Mit SYSTEM-Rechten können Sie problemlos eine Rückverbindung über TCP herstellen. Offensichtlich ist die Deaktivierung von direktem TCP ausschließlich für den eingeschränkten IIS-Benutzer ein Problem. Spoiler: Der IIS-Benutzerverkehr wurde irgendwie in beide Richtungen in den lokalen ISA-Proxy eingebunden. Wie genau es funktioniert, habe ich nicht nachvollzogen.
- Ich befinde mich in einer bestimmten „DMZ“ (und das ist keine Active Directory-Domäne, sondern eine ARBEITSGRUPPE) – das klingt logisch. Aber statt der erwarteten privaten („grauen“) IP-Adresse habe ich eine völlig „weiße“ IP-Adresse, genau dieselbe wie die, die ich zuvor angegriffen habe. Das bedeutet, dass das Unternehmen in der Welt der IPv4-Adressierung so alt ist, dass es es sich leisten kann, eine DMZ-Zone für 128 „weiße“ Adressen ohne NAT nach dem Schema zu unterhalten, wie es in Cisco-Handbüchern aus dem Jahr 2005 dargestellt ist.
Da der Server alt ist, funktioniert Mimikatz garantiert direkt aus dem Speicher:
Ich erhalte das lokale Administratorkennwort, tunnele den RDP-Verkehr über TCP und melde mich bei einem gemütlichen Desktop an. Da ich mit dem Server machen konnte, was ich wollte, entfernte ich das Antivirenprogramm und stellte fest, dass der Server vom Internet aus nur über die TCP-Ports 80 und 443 erreichbar war und 443 nicht belegt war. Ich richte einen OpenVPN-Server auf 443 ein, füge NAT-Funktionen für meinen VPN-Verkehr hinzu und erhalte über mein OpenVPN direkten Zugriff auf das DMZ-Netzwerk in unbegrenzter Form. Es ist bemerkenswert, dass ISA mit einigen nicht deaktivierten IPS-Funktionen meinen Datenverkehr durch Port-Scanning blockierte, weshalb es durch ein einfacheres und kompatibleres RRAS ersetzt werden musste. Daher müssen Pentester manchmal noch alles Mögliche verwalten.
Ein aufmerksamer Leser wird fragen: „Was ist mit der zweiten Site – einem Wiki mit NTLM-Authentifizierung, über das so viel geschrieben wurde?“ Mehr dazu später.
Teil 2. Immer noch nicht verschlüsselt? Dann kommen wir schon hier zu Ihnen
Es besteht also Zugriff auf das DMZ-Netzwerksegment. Sie müssen zum Domänenadministrator gehen. Das erste, was mir in den Sinn kommt, ist die automatische Überprüfung der Sicherheit von Diensten im DMZ-Segment, zumal viele davon mittlerweile für die Forschung offen sind. Ein typisches Bild bei einem Penetrationstest: Der externe Perimeter ist besser geschützt als interne Dienste, und wenn man sich Zugang innerhalb einer großen Infrastruktur verschafft, ist es viel einfacher, erweiterte Rechte in einer Domäne zu erhalten, nur weil diese Domäne beginnt zugänglich für Tools, und zweitens wird es in einer Infrastruktur mit mehreren tausend Hosts immer ein paar kritische Probleme geben.
Ich lade die Scanner per DMZ über einen OpenVPN-Tunnel auf und warte. Ich öffne den Bericht – wieder nichts Ernstes, offenbar hat jemand vor mir die gleiche Methode durchgeführt. Der nächste Schritt besteht darin, zu untersuchen, wie Hosts innerhalb des DMZ-Netzwerks kommunizieren. Starten Sie dazu zunächst das übliche Wireshark und warten Sie auf Broadcast-Anfragen, hauptsächlich ARP. Den ganzen Tag über wurden ARP-Pakete gesammelt. Es zeigt sich, dass in diesem Segment mehrere Gateways zum Einsatz kommen. Das wird sich später als nützlich erweisen. Durch die Kombination von Daten zu ARP-Anfragen und -Antworten sowie Port-Scan-Daten konnte ich zusätzlich zu den zuvor bekannten Diensten wie Web und E-Mail auch die Austrittspunkte des Benutzerverkehrs aus dem lokalen Netzwerk ermitteln.
Da ich im Moment keinen Zugriff auf andere Systeme hatte und kein einziges Konto für Unternehmensdienste hatte, wurde beschlossen, mithilfe von ARP-Spoofing zumindest einen Teil des Kontos aus dem Datenverkehr herauszufischen.
Cain&Abel wurde auf dem Server des Urologen gestartet. Unter Berücksichtigung der identifizierten Verkehrsströme wurden die vielversprechendsten Paare für den Man-in-the-Middle-Angriff ausgewählt und dann wurde durch kurzfristigen Start für 5–10 Minuten etwas Netzwerkverkehr empfangen, mit einem Timer zum Neustarten des Servers bei Frost. Wie im Witz gab es zwei Neuigkeiten:
- Gut: Es wurden viele Anmeldedaten gesammelt und der Angriff insgesamt funktionierte.
- Das Schlechte: Alle Anmeldeinformationen stammten von den eigenen Kunden des Kunden. Bei der Bereitstellung von Supportdiensten stellten Kundenspezialisten eine Verbindung zu den Diensten von Kunden her, bei denen die Verkehrsverschlüsselung nicht immer konfiguriert war.
Dadurch erlangte ich viele Anmeldeinformationen, die im Kontext des Projekts zwar nutzlos, aber durchaus interessant als Demonstration der Gefährlichkeit des Angriffs waren. Grenzrouter großer Unternehmen mit Telnet, weitergeleitete Debug-HTTP-Ports an internes CRM mit allen Daten, direkter Zugriff auf RDP von Windows XP im lokalen Netzwerk und andere Obskurantismus. Es ist so gekommen .
Ich habe auch eine lustige Gelegenheit gefunden, Briefe aus dem Verkehr zu sammeln, so etwas in der Art. Dies ist ein Beispiel für einen vorgefertigten Brief, der von unserem Kunden wiederum unverschlüsselt an den SMTP-Port seines Kunden gesendet wurde. Ein gewisser Andrey bittet seinen Namensvetter, die Dokumentation erneut zu senden, und sie wird mit einem Login, einem Passwort und einem Link in einem Antwortbrief auf eine Cloud-Festplatte hochgeladen:
Dies ist eine weitere Erinnerung daran, alle Dienste zu verschlüsseln. Es ist nicht bekannt, wer und wann konkret Ihre Daten liest und nutzt – der Anbieter, der Systemadministrator eines anderen Unternehmens oder ein solcher Pentester. Ich schweige darüber, dass viele Menschen den unverschlüsselten Datenverkehr einfach abfangen können.
Trotz des scheinbaren Erfolgs brachte uns dies dem Ziel nicht näher. Es war natürlich möglich, lange zu sitzen und wertvolle Informationen herauszufischen, aber es ist keine Tatsache, dass sie dort auftauchen würden, und der Angriff selbst ist im Hinblick auf die Integrität des Netzwerks sehr riskant.
Nach einem weiteren Blick auf die Dienste kam mir eine interessante Idee. Es gibt ein solches Dienstprogramm namens Responder (es ist leicht, Anwendungsbeispiele unter diesem Namen zu finden), das durch „Vergiftung“ von Broadcast-Anfragen Verbindungen über verschiedene Protokolle wie SMB, HTTP, LDAP usw. provoziert. auf unterschiedliche Weise, fordert dann jeden, der eine Verbindung herstellt, zur Authentifizierung auf und richtet es so ein, dass die Authentifizierung über NTLM und in einem für das Opfer transparenten Modus erfolgt. Am häufigsten sammelt ein Angreifer auf diese Weise NetNTLMv2-Handshakes und stellt mithilfe eines Wörterbuchs schnell die Passwörter der Benutzerdomäne wieder her. Hier wollte ich etwas Ähnliches, aber die Benutzer saßen „hinter einer Wand“, oder besser gesagt, sie waren durch eine Firewall getrennt und griffen über den Blue Coat-Proxy-Cluster auf das WEB zu.
Denken Sie daran, dass ich angegeben habe, dass der Active Directory-Domänenname mit der „externen“ Domäne übereinstimmt, das heißt, es war „company.ru“? Daher ermöglicht Windows, genauer gesagt Internet Explorer (sowie Edge und Chrome), dem Benutzer die transparente Authentifizierung in HTTP über NTLM, wenn er davon ausgeht, dass sich die Site in einer „Intranetzone“ befindet. Ein Zeichen für ein „Intranet“ ist der Zugriff auf eine „graue“ IP-Adresse oder einen kurzen DNS-Namen, also ohne Punkte. Da sie einen Server mit einem „weißen“ IP- und DNS-Namen preobrazhensky.company.ru hatten und Domänenmaschinen zur vereinfachten Namenseingabe normalerweise das Active Directory-Domänensuffix über DHCP erhalten, mussten sie nur die URL in die Adressleiste schreiben , damit sie den richtigen Weg zum kompromittierten Server des Urologen finden, nicht zu vergessen, dass dieser jetzt „Intranet“ heißt. Das heißt, ich gebe mir gleichzeitig ohne sein Wissen den NTLM-Handschlag des Benutzers. Es bleibt nur noch, Client-Browser dazu zu zwingen, über die dringende Notwendigkeit nachzudenken, diesen Server zu kontaktieren.
Das wunderbare Dienstprogramm Intercepter-NG kam zur Rettung (danke). ). Damit konnten Sie den Datenverkehr im Handumdrehen ändern und funktionierten hervorragend unter Windows 2003. Es verfügte sogar über eine separate Funktionalität, um nur JavaScript-Dateien im Datenverkehrsfluss zu ändern. Geplant war eine Art massives Cross-Site-Scripting.
Blue Coat-Proxys, über die Benutzer auf das globale WEB zugegriffen haben, haben regelmäßig statische Inhalte zwischengespeichert. Durch das Abfangen des Datenverkehrs war klar, dass sie rund um die Uhr arbeiteten und endlos häufig verwendete statische Signale anforderten, um die Anzeige von Inhalten während der Spitzenzeiten zu beschleunigen. Darüber hinaus verfügte BlueCoat über einen spezifischen User-Agent, der es deutlich von einem echten Benutzer unterschied.
Es wurde Javascript vorbereitet, das mit Intercepter-NG für jede Antwort eine Stunde lang nachts mit JS-Dateien für Blue Coat implementiert wurde. Das Skript hat Folgendes getan:
- Ermittelt den aktuellen Browser durch User-Agent. Wenn es Internet Explorer, Edge oder Chrome war, funktionierte es weiterhin.
- Ich habe gewartet, bis das DOM der Seite gebildet wurde.
- Ein unsichtbares Bild mit einem src-Attribut des Formulars in das DOM eingefügt :8080/NNNNNNN.png, wobei NNN beliebige Zahlen sind, sodass BlueCoat sie nicht zwischenspeichert.
- Legen Sie eine globale Flag-Variable fest, um anzuzeigen, dass die Injektion abgeschlossen wurde und keine Notwendigkeit mehr besteht, Bilder einzufügen.
Der Browser hat versucht, dieses Bild zu laden. Auf Port 8080 des kompromittierten Servers wartete ein TCP-Tunnel zu meinem Laptop, auf dem derselbe Responder lief, sodass sich der Browser über NTLM anmelden musste.
Den Responder-Protokollen zufolge kamen die Leute morgens zur Arbeit, schalteten ihre Workstations ein und begannen dann massenhaft und unbemerkt, den Server des Urologen zu besuchen, nicht zu vergessen, NTLM-Handshakes „abzulassen“. Den ganzen Tag über regnete es Händeschütteln und es sammelte sich offensichtlich Material für einen offensichtlich erfolgreichen Angriff zur Wiederherstellung von Passwörtern. So sahen die Responder-Protokolle aus:
Massenhafte geheime Besuche von Benutzern auf dem Server des Urologen
Sie haben wahrscheinlich schon bemerkt, dass diese ganze Geschichte auf dem Prinzip basiert: „Alles war gut, aber dann gab es einen Mist, dann gab es eine Überwindung, und dann wurde alles zum Erfolg.“ Hier gab es also einen Mist. Von den fünfzig einzigartigen Handschlägen wurde kein einziger enthüllt. Dabei wird berücksichtigt, dass selbst auf einem Laptop mit einem toten Prozessor diese NTLMv2-Handshakes mit einer Geschwindigkeit von mehreren hundert Millionen Versuchen pro Sekunde verarbeitet werden.
Ich musste mich mit Passwort-Mutationstechniken, einer Grafikkarte und einem dickeren Wörterbuch ausrüsten und warten. Nach langer Zeit wurden mehrere Konten mit Passwörtern der Form „Q11111111....1111111q“ aufgedeckt, was darauf hindeutet, dass alle Benutzer einst gezwungen waren, sich ein sehr langes Passwort mit unterschiedlicher Groß- und Kleinschreibung auszudenken, was auch vorgesehen war komplex sein. Aber einen erfahrenen Benutzer kann man nicht täuschen, und so hat er es sich leichter gemacht, sich daran zu erinnern. Insgesamt wurden etwa fünf Konten kompromittiert, und nur eines davon verfügte über wertvolle Rechte an den Diensten.
Teil 3. Roskomnadzor schlägt zurück
So wurden die ersten Domänenkonten empfangen. Wenn Sie nach langer Lektüre zu diesem Zeitpunkt noch nicht eingeschlafen sind, erinnern Sie sich wahrscheinlich daran, dass ich einen Dienst erwähnt habe, der keinen zweiten Authentifizierungsfaktor erforderte: Es handelt sich um ein Wiki mit NTLM-Authentifizierung. Als erstes musste man natürlich dort eintreten. Ein Blick in die interne Wissensdatenbank brachte schnell Ergebnisse:
- Das Unternehmen verfügt über ein WLAN-Netzwerk mit Authentifizierung über Domänenkonten mit Zugriff auf das lokale Netzwerk. Mit dem aktuellen Datensatz ist dies bereits ein funktionierender Angriffsvektor, aber Sie müssen mit Ihren Füßen zum Büro gehen und sich irgendwo auf dem Territorium des Kundenbüros befinden.
- Ich habe eine Anleitung gefunden, nach der es einen Dienst gab, der es ermöglichte, selbstständig ein „Zweitfaktor“-Authentifizierungsgerät zu registrieren, wenn sich der Benutzer in einem lokalen Netzwerk befindet und sich sicher an seinen Domänen-Login und sein Passwort erinnert. In diesem Fall wurden „innen“ und „außen“ durch die Zugänglichkeit des Ports dieses Dienstes für den Benutzer bestimmt. Der Port war nicht über das Internet erreichbar, aber über die DMZ durchaus erreichbar.
Natürlich wurde dem kompromittierten Konto sofort ein „zweiter Faktor“ in Form einer Anwendung auf meinem Telefon hinzugefügt. Es gab ein Programm, das entweder lautstark eine Push-Anfrage mit den Schaltflächen „Genehmigen“/„Ablehnen“ für die Aktion an das Telefon senden oder den OTP-Code stillschweigend auf dem Bildschirm anzeigen konnte, um eine weitere unabhängige Eingabe zu ermöglichen. Darüber hinaus wurde in der Anleitung angenommen, dass die erste Methode die einzig richtige sei, aber sie funktionierte im Gegensatz zur OTP-Methode nicht.
Nachdem der „zweite Faktor“ defekt war, konnte ich auf Outlook Web Access-Mails und den Fernzugriff in Citrix Netscaler Gateway zugreifen. In der Mail in Outlook gab es eine Überraschung:
In dieser seltenen Aufnahme können Sie sehen, wie Roskomnadzor Pentestern hilft
Dies waren die ersten Monate nach der berühmten „Fan“-Blockierung von Telegram, als ganze Netzwerke mit Tausenden von Adressen unaufhaltsam aus dem Zugriff verschwanden. Es wurde klar, warum der Push nicht sofort funktionierte und warum mein „Opfer“ keinen Alarm schlug, weil es begann, sein Konto während der Öffnungszeiten zu nutzen.
Jeder, der mit Citrix Netscaler vertraut ist, stellt sich vor, dass es normalerweise so implementiert ist, dass dem Benutzer nur eine Bildoberfläche vermittelt werden kann, wobei versucht wird, ihm nicht die Tools zum Starten von Anwendungen von Drittanbietern und zum Übertragen von Daten zur Verfügung zu stellen, was die Aktionen auf jede erdenkliche Weise einschränkt über Standard-Kontrollschalen. Mein „Opfer“ bekam berufsbedingt nur 1C:
Nachdem ich ein wenig durch die 1C-Schnittstelle gelaufen war, stellte ich fest, dass dort externe Verarbeitungsmodule vorhanden sind. Sie können über die Schnittstelle geladen werden und werden je nach Rechten und Einstellungen auf dem Client oder Server ausgeführt.
Ich habe meine 1C-Programmiererfreunde gebeten, eine Verarbeitung zu erstellen, die eine Zeichenfolge akzeptiert und ausführt. In der 1C-Sprache sieht das Starten eines Prozesses etwa so aus (aus dem Internet entnommen). Stimmen Sie zu, dass die Syntax der 1C-Sprache die russischsprachigen Menschen mit ihrer Spontaneität in Erstaunen versetzt?
Die Verarbeitung wurde perfekt ausgeführt; es stellte sich heraus, dass es sich um das handelte, was Pentester eine „Shell“ nennen – über sie wurde der Internet Explorer gestartet.
Zuvor wurde in der Post die Adresse eines Systems gefunden, mit dem man Pässe für das Gebiet bestellen kann. Ich habe einen Pass bestellt, für den Fall, dass ich einen WLAN-Angriffsvektor verwenden musste.
Im Internet ist die Rede davon, dass es beim Kunden noch leckeres Gratis-Catering gab, aber ich habe den Angriff trotzdem lieber aus der Ferne entwickelt, das ist ruhiger.
AppLocker wurde auf dem Anwendungsserver mit Citrix aktiviert, aber umgangen. Derselbe Meterpreter wurde über DNS geladen und gestartet, da die http(s)-Versionen keine Verbindung herstellen wollten und ich zu diesem Zeitpunkt die interne Proxy-Adresse nicht kannte. Übrigens hat sich der externe Pentest von diesem Moment an im Wesentlichen vollständig in einen internen verwandelt.
Teil 4. Admin-Rechte für Benutzer sind schlecht, okay?
Die erste Aufgabe eines Pentesters, wenn er die Kontrolle über eine Domänenbenutzersitzung erlangt, besteht darin, alle Informationen über Rechte in der Domäne zu sammeln. Es gibt ein BloodHound-Dienstprogramm, mit dem Sie automatisch Informationen über Benutzer, Computer und Sicherheitsgruppen über das LDAP-Protokoll von einem Domänencontroller und über SMB herunterladen können – Informationen darüber, welcher Benutzer sich zuletzt wo angemeldet hat und wer der lokale Administrator ist.
Eine typische Technik zum Ergreifen von Domänenadministratorrechten sieht vereinfacht als ein Zyklus monotoner Aktionen aus:
- Wir gehen zu Domänencomputern, auf denen lokale Administratorrechte vorhanden sind, basierend auf bereits erfassten Domänenkonten.
- Wir starten Mimikatz und erhalten zwischengespeicherte Passwörter, Kerberos-Tickets und NTLM-Hashes von Domänenkonten, die sich kürzlich bei diesem System angemeldet haben. Oder wir entfernen das Speicherabbild des Prozesses lsass.exe und machen auf unserer Seite dasselbe. Dies funktioniert gut mit Windows jünger als 2012R2/Windows 8.1 mit Standardeinstellungen.
- Wir ermitteln, wo die kompromittierten Konten über lokale Administratorrechte verfügen. Wir wiederholen den ersten Punkt. Irgendwann erhalten wir Administratorrechte für die gesamte Domain.
„Ende des Zyklus“, wie 1C-Programmierer hier schreiben würden.
Es stellte sich also heraus, dass unser Benutzer ein lokaler Administrator auf nur einem Host mit Windows 7 war, dessen Name das Wort „VDI“ oder „Virtual Desktop Infrastructure“, also persönliche virtuelle Maschinen, enthielt. Wahrscheinlich meinte der Designer des VDI-Dienstes, dass, da VDI das persönliche Betriebssystem des Benutzers ist, der Host auch dann „neu geladen“ werden kann, wenn der Benutzer die Softwareumgebung nach Belieben ändert. Ich fand die Idee im Großen und Ganzen auch gut, bin zu diesem persönlichen VDI-Host gegangen und habe dort ein Nest gebaut:
- Ich habe dort einen OpenVPN-Client installiert, der einen Tunnel durch das Internet zu meinem Server aufgebaut hat. Der Client musste gezwungen werden, den gleichen Blue Coat mit der Domänenauthentifizierung zu durchlaufen, aber OpenVPN erledigte dies, wie sie sagen, „out of the box“.
- OpenSSH auf VDI installiert. Was wäre eigentlich Windows 7 ohne SSH?
So sah es live aus. Ich möchte Sie daran erinnern, dass dies alles über Citrix und 1C erfolgen muss:
Eine Technik zur Förderung des Zugriffs auf benachbarte Computer besteht darin, die Passwörter lokaler Administratoren auf Übereinstimmung zu überprüfen. Hier wartete sofort Glück: Der NTLM-Hash des lokalen Standardadministrators (der plötzlich Administrator hieß) wurde durch einen Pass-the-Hash-Angriff auf benachbarte VDI-Hosts, von denen es mehrere Hundert gab, angegriffen. Natürlich traf der Angriff sie sofort.
Hier haben sich VDI-Administratoren gleich zweimal selbst ins Bein geschossen:
- Beim ersten Mal wurden VDI-Maschinen nicht unter LAPS gestellt und im Wesentlichen das gleiche lokale Administratorkennwort aus dem Image beibehalten, das massiv auf VDI bereitgestellt wurde.
- Der Standardadministrator ist das einzige lokale Konto, das anfällig für Pass-the-Hash-Angriffe ist. Selbst mit demselben Passwort wäre es möglich, eine Massenkompromittierung zu vermeiden, indem man ein zweites lokales Administratorkonto mit einem komplexen Zufallspasswort erstellt und das Standardpasswort blockiert.
Warum gibt es unter diesem Windows einen SSH-Dienst? Ganz einfach: Jetzt stellte der OpenSSH-Server nicht nur eine praktische interaktive Befehlsshell bereit, ohne die Arbeit des Benutzers zu beeinträchtigen, sondern auch einen SOCKS5-Proxy auf VDI. Über diese Socken habe ich eine Verbindung über SMB hergestellt und zwischengespeicherte Konten von all diesen Hunderten von VDI-Maschinen gesammelt und dann nach dem Pfad zum Domänenadministrator gesucht, der sie in den BloodHound-Diagrammen verwendet. Da mir Hunderte von Gastgebern zur Verfügung standen, habe ich diesen Weg recht schnell gefunden. Domänenadministratorrechte wurden erworben.
Hier ist ein Bild aus dem Internet, das eine ähnliche Suche zeigt. Verbindungen zeigen, wer sich wo der Administrator befindet und wer wo angemeldet ist.
Denken Sie übrigens an die Bedingung vom Anfang des Projekts: „Verwenden Sie kein Social Engineering.“ Daher schlage ich vor, darüber nachzudenken, wie sehr all dieses Bollywood mit Spezialeffekten abgeschnitten würde, wenn banales Phishing noch möglich wäre. Aber für mich persönlich war es sehr interessant, das alles zu machen. Ich hoffe, es hat Ihnen Spaß gemacht, dies zu lesen. Natürlich sieht nicht jedes Projekt so spannend aus, aber die Arbeit insgesamt ist sehr anspruchsvoll und lässt keinen Stillstand zu.
Wahrscheinlich wird jemand eine Frage haben: Wie kann man sich schützen? Sogar dieser Artikel beschreibt viele Techniken, von denen viele Windows-Administratoren nicht einmal wissen. Ich schlage jedoch vor, sie aus der Perspektive abgedroschener Prinzipien und Informationssicherheitsmaßnahmen zu betrachten:
- Verwenden Sie keine veraltete Software (erinnern Sie sich an Windows 2003 am Anfang?)
- Lassen Sie keine unnötigen Systeme eingeschaltet (warum gab es die Website eines Urologen?)
- Überprüfen Sie die Benutzerpasswörter selbst auf Stärke (sonst werden Soldaten ... Pentester dies tun)
- nicht die gleichen Passwörter für verschiedene Konten haben (VDI-Kompromittierung)
- usw
Natürlich ist dies sehr schwierig umzusetzen, aber im nächsten Artikel werden wir in der Praxis zeigen, dass es durchaus möglich ist.
Source: habr.com