Ich bin noch nicht so lange in der IT, aber vor kurzem hat mich das Thema Cybersicherheit mitgerissen. Besonders interessant ist der Beruf eines Pentesters. Beim Surfen sah ich einen coolen Artikel von Security Shenanigans "Wie eine schlecht konfigurierte Datenbank es uns ermöglichte, eine ganze Cloud mit über 25.000 Hosts zu besitzen" . Übersetzung beider Teile und machen Sie darauf aufmerksam.
Einführung
In diesem Artikel erfahren Sie, wie wir es geschafft haben, mithilfe von BMC / IPMI eine direkte SQLMap-Verbindung zur Datenbank herzustellen, um einen großen Client zu gefährden.
Hintergrund
Vor einigen Jahren erhielt unser Team die Aufgabe, einen Infrastruktur-Penetrationstest im Openstack-Netzwerk durchzuführen. Es bestand aus etwa 2.000 physischen Servern, auf denen über 25.000 virtuelle Maschinen gehostet wurden. Wir haben unsere Arbeit an einem kleinen Subnetz begonnen, in dem die Menge des ausgehenden Datenverkehrs begrenzt war. Nach einem kurzen Scan konnte Nmap keine offensichtlichen Sicherheitslücken finden, die ausgenutzt werden konnten. Aus diesem Grund haben wir begonnen, die uns zur Verfügung stehenden Dienstleistungen zu untersuchen. Unter ihnen fanden wir einen wehrlosen PostgreSQL-Server, der auf einem Entwicklungsserver gehostet wird. Nachdem wir eine benutzerdefinierte Wortliste mit mehreren Ableitungen des Firmennamens erstellt hatten, konnten wir uns mit relativ einfachen Daten aus dem Konto in das System einschleichen. Der Benutzername war Postgres und das Passwort war "admin".
Als nächstes entschieden wir uns zu verwendensqlmap . Dieses Tool wurde für die Verwendung von SQL Injection entwickelt, bietet Ihnen jedoch auch verschiedene Optionen beim Herstellen einer direkten Datenbankverbindung (wenn Sie über Ihre Anmeldeinformationen verfügen). Eine dieser Optionen besteht darin, eine Befehlsshell für die Datenbank in der Produktion zu starten.
Nach dem Testen der Shell haben wir beschlossen, eine benutzerdefinierte Nutzlast (Payload) zu erstellen, um eine umgekehrte Verbindung zu erhalten. Dies würde es ermöglichen, bequemer zu arbeiten.
Wir haben die Nutzdaten mit msfvenom erstellt. Die Nutzlast war in diesem Fall eine Reverse-TCP-Shell für einen Linux x64-Computer. Im vorherigen Bild sehen Sie, dass wir die Datenbankarchitektur auswählen mussten.
Sammeln der Nutzdaten mit msfvenom
Der Vorteil dieser Nutzlast besteht darin, dass sie verwendet werden kann, um mit einfachem Netcat eine Verbindung herzustellen. Die meisten anderen Nutzdaten erfordern für dieselben Aufgaben etwas wie Metasploit (wählen Sie Exploit / Multi / Handler).
Nachdem wir die Nutzdaten mit dem sqlmap-Wrapper ausgeführt haben, haben wir unsere Verbindung zum Server hergestellt.
Starten von Payload Herstellen der Verbindung
und Testen des Zugriffs
Verwenden von BMC-Geräten
Wenn Sie einen Infrastruktur-Penetrationstest ausführen und einen Computer in einem neuen Netzwerksegment kompromittieren, sollten Sie den Scan erneut ausführen, um festzustellen, ob etwas Neues angezeigt wird. Mit dieser Datenbank konnten wir eine Verbindung zum Cloud-Netzwerk des Unternehmens herstellen, einschließlich der meisten virtuellen Maschinen und Hosts. Wir waren sehr zufrieden mit den Ergebnissen des neuen Scans, da wir mehrere BMC-Geräte gefunden haben.
Eines von drei BMC-Geräten
Der BMC (Baseboard Management Controller, Serviceprozessor) ist ein bevorzugtes eingebettetes Gerät, das mit dem Hauptserver verbunden ist und eine Out-of-Band-Überwachung und -Steuerung bietet. Es funktioniert unabhängig von CPU, BIOS und Betriebssystem. Fehler, die in einem dieser Elemente auftreten, können den Betrieb nicht beeinträchtigen. Der Mikrocontroller verfügt über einen eigenen Prozessor, einen eigenen Speicher und eine eigene Netzwerkschnittstelle. Daher ist er auch dann verfügbar, wenn der Server selbst ausgeschaltet ist. Alle großen Ausrüstungslieferanten haben spezifische BMCs für ihre Produkte:
- Dell DRAC
- IBM IMM
- HP iLO
- Supermicro IPMI
Ein weiterer Begriff, mit dem Sie sich vertraut machen müssen, IPMI (Intelligent Platform Management Interface), ist im Grunde das Protokoll, das Sie für die Kommunikation mit diesen Geräten verwenden. Der Zweck besteht darin, die Serverhardware unabhängig vom Betriebssystem zu überwachen und zu verwalten, selbst wenn der Server ausgeschaltet, aber an eine Stromquelle angeschlossen ist.
Sagen wir einfach, IPMI ist bei weitem eines der unsichersten Protokolle, die Sie finden können. Um Ihnen eine Vorstellung zu geben, ist IPMI 2.0 so konzipiert, dass Sie während des Authentifizierungsschritts direkt einen benutzerdefinierten Hash vom Server anfordern können. Eine weitere Sicherheitsanfälligkeit besteht, wenn Sie im Modus "Verschlüsselung 0" eine Autorisierung anfordern, mit der Sie sich mit einem beliebigen Kennwort anmelden können. BMC-Geräte mit
IPMI-
Blockarchitektur, die Sie möglicherweise finden, sind normalerweise schlecht geschützt, da es sich um einen Gerätetyp handelt, der während der Montagephase des Rechenzentrums einmal konfiguriert und dann nur verwendet wird, wenn der Server mit herkömmlichen Mitteln nicht verfügbar ist.
Auf einigen Geräten mit aktivierter Verschlüsselung 0 konnten wir uns problemlos authentifizieren .
Hier können Sie sehen, wie wir mit einem zufälligen Passwort angemeldet sind. Achten Sie auf den Teil "-C 0".
Erfolgreich mit einem zufälligen Kennwort am Gerät angemeldet
Netzwerkinformationen für das Gerät
Auch wenn auf einigen Geräten die Verschlüsselung 0 nicht aktiviert ist, haben Sie noch andere Möglichkeiten, sich anzumelden. Die beiden bekanntesten verwenden entweder Standardanmeldeinformationen (die Sysadmins normalerweise nicht zu ändern versuchen) oder nutzen eine Sicherheitsanfälligkeit bezüglich der Offenlegung von Hashs aus (und brechen dann die Hashes). Letzteres musste für die meisten Geräte durchgeführt werden.
Banale Standard-Benutzername / Passwort-Paare für die meisten Benutzer
Eine Liste von Wörtern, die Hashes von Benutzern enthalten, die wir vom Server anfordern
Erweitern von benutzerdefinierten Hashes mithilfe von Metasploit
Sofort erhalten wir Daten zu typischen Hashes.
Nachdem wir alle Hashes durchgearbeitet hatten, begannen wir, sie zu knacken.
Die ersten Hashes hacken
In wenigen Minuten haben wir Zugriff auf ca. 600 BMC.
609 Hashes erfolgreich geknackt
Es gab einige HP ILO-Geräte, die wir nicht knacken konnten. Zum Glück verfügt HP iLO 4 1.00 bis 2.50 auch über einen Authentifizierungsbypass. Auf diese Weise können Sie ein Administratorkonto über einen Pufferüberlauf im vom Webserver verarbeiteten HTTP-Verbindungsheader erstellen. Der Exploit verwendet dies, um privilegierten Zugriff auf den Rest der API zu erhalten, wodurch Sie die Berechtigung zum Erstellen von Konten erhalten.
Verwenden von CVE-2017-12542
Nach diesen Schritten haben wir die volle Kontrolle über 90% der BMC-Geräte des Unternehmens. Wenn Sie über BMC-Geräte gelesen haben, wissen Sie jetzt, dass Sie damit:
- Monitor
- Starten Sie neu
- Neu installieren
- KVM (virtualisieren)
verbundene Geräte. Das ist großartig und alles, aber sie simulieren nur den physischen Zugriff auf den Server. Sie müssen immer noch hinein. Ja, Sie können herumalbern, indem Sie die Geräte ausschalten, aber wir dachten, es sei nicht genug, also gruben wir weiter.
Eine der häufigsten Möglichkeiten, Hardware mit einer physischen Adresse zu hacken, besteht darin, sie neu zu starten und die automatische Ausführung der Root-Shell zu steuern. Sie können dies unter Unix, Mac und Windows tun.
Die Schwierigkeit bei diesem Ansatz besteht darin, dass jeder Server normalerweise etwa 2000 virtuelle Hosts hostet. Wir mussten also einen nicht verwendeten Server finden. Der Plan war, es auszuschalten (oder einfach zu starten, wenn es bereits ausgeschaltet war) und den Autorun zu bearbeiten, um uns Root-Zugriff zu gewähren. Danach wollten wir uns die Konfiguration ansehen, um Fehler / Nutzdaten zu finden, die es uns ermöglichen würden, auch andere Server zu gefährden.
Mit Openstack können Sie die lokale Infrastruktur abfragen und bestimmte Parameter abfragen. Eine davon ist der Status der virtuellen Maschine, der im Fall dieses lokalen Unternehmens als Verfügbarkeit der VM (weiße / schwarze Liste für den Empfang von Datenverkehr) + Betriebsstatus (gestartet / deaktiviert) definiert wurde.
Wir mussten einen Server auf der schwarzen Liste finden (der Arbeitsstatus spielte keine Rolle) und wir fanden einen, der aufgrund von Festplattenproblemen nicht funktionierte. Glücklicherweise konnten wir booten, aber einige Teile des Dateisystems waren schreibgeschützt.
Openstack-Anforderung für einen geeigneten Hacking-Server
Sobald wir ihn gefunden haben, haben wir uns mit den zuvor gefundenen Anmeldeinformationen angemeldet.
Verwenden der zuvor erhaltenen Zugriffe
Zugriff auf die KVM-Schnittstelle Die KVM-
Schnittstelle simuliert eine direkte Verbindung zum Server über den BMC. Beim Booten müssen Sie das automatische Laden von Grub bearbeiten und
ro init = / bin / bashzur entsprechenden Zeile hinzufügen , um die Root-Shell zu booten... Normalerweise wird das Lese- / Schreibflag (rw) verwendet, aber wir mussten das Nur-Lese-Flag (ro) verwenden, um Probleme mit der ausgefallenen Festplatte zu vermeiden.
Bearbeiten des Grub-Menüs
Nach dem Anmelden haben wir die Netzwerkschnittstellen untersucht, um die Konnektivität zum Server zu testen. Wie Sie sehen können, zeigt ifconfig mehr als 10 aktive Schnittstellen.
Nachdem wir uns einige Zeit genommen hatten, um die Struktur des Netzwerks zu analysieren und zu verstehen, wo wir uns befinden, begannen wir, den Server zu untersuchen.
In ein paar Minuten fanden wir einen Mittelweg mit bash_history (eine der besten Quellen für wertvolle Informationen, die Sie auf einem Linux-Computer finden können)
novadb-Anmeldeinformationen in bash_history
Für diejenigen, die mit der Openstack-Architektur nicht vertraut sind, ist Nova eine Verwaltungsdatenbank, in der Verwaltungsinformationen für die gesamte Cloud gespeichert werden, z. B. Zertifikate, Kontingente, Instanznamen, Metadaten und viele wichtigere Informationen .
Anmeldeinformationen
überprüfen Nach dem Anmelden haben wir den Administratorzugriff mit grant_MySQL überprüft.
Nachdem wir dies getan haben, können wir die interne Struktur von NovaDB sehen.
Tabellen in der Novadb-Datenbank Bei
Betrachtung der Informationen zur VM konnten wir ungefähr 34.000 Geräte sehen. Etwa ein Drittel von ihnen war jedoch nicht verfügbar / funktionierte nicht. Der genaue Betrag ist im Zeileneintrag float_ips zu sehen.
Lassen Sie mich erklären, warum diese Daten aus der Datenbank so wichtig sind.
Wenn Sie das gesamte Unternehmen herunterfahren möchten, können Sie jeden virtuellen Server über die BMC-Schnittstelle herunterfahren. Sie werden nicht funktionieren, bis die Systemadministratoren die Dinge wieder einschalten.
Sie können Ihre eigene Malware schreiben, um alle Server zu infizieren, aber die Massenbereitstellung über BMC-Kanäle ist nicht einfach (denken Sie daran, dass wir einen nicht verwendeten Server starten mussten, um den Grub-Autorun zu bearbeiten, bevor wir darauf zugreifen konnten).
Mit dem Zugriff auf NovaDB können Sie jedoch einfach die Datenbank beschädigen, und die gesamte Cloud-Umgebung funktioniert nicht mehr. Selbst wenn der Systemadministrator intelligent genug ist, um einen kurzen Blick auf die Datenbank zu werfen, ist es viel schwieriger, eine beschädigte Datenbank zu beheben als eine fehlende.
Außerdem kann der Systemadministrator herausfinden, dass etwas nicht stimmt, und einfach alles mit der neuesten Sicherung überschreiben, oder? Wir haben auch darüber nachgedacht. Aus diesem Grund haben wir die Backups kompromittiert.
Zuerst haben wir versucht, die Hauptdatenbank mit so etwas abzufragen
SELECT * FROM information_schema.PROCESSLIST AS p WHERE p.COMMAND = 'Binlog Dump'; , aber das Unternehmen verwendete eine eigene Sicherungslösung, die unregelmäßig lief und kein Master / Slave-Schema verwendete. Also haben wir die benachbarten Subnetze weiter gescannt, um die Sicherungsdatenbanken zu finden, die auf demselben Port wie der Hauptport ausgeführt werden.
Wie wir es geschafft haben, die Backups zu finden
Wir haben die Möglichkeit geprüft, die vorhandenen Anmeldeinformationen zu verwenden, und natürlich sind sie aufgetaucht.
Überprüfen des Zugriffs auf ein Backup
Mit unseren eigenen Backups konnten wir den vollständigen Kompromiss der Virtualisierungsinfrastruktur nachweisen und den Vorgang in wenigen Minuten abschließen.
Ich beende immer gerne eine Überprüfung / einen Bericht mit möglichen Korrekturen für gefundene Probleme. Darüber hinaus gab es viele von ihnen, zum Beispiel:
- Anmeldeinformationen wiederverwenden
- Es gibt keine Netzwerksegmentierung
- Banale Passwörter
- Unsichere Sicherungsstruktur
- Veraltete Firmware
Ein kritisches Problem, das nicht einfach zu beheben war, waren die Fehler im IPMI-Protokoll.
Die erfolgreichste Lösung wäre, die BMC-fähigen Server in einem anderen Netzwerksegment mit einer begrenzten und kontrollierten Liste von IP-Adressen zu platzieren. Dies ist, was diese Firma am Ende getan hat.
Ich hoffe dir hat unsere Geschichte gefallen. So viel Spaß wir hatten, dieses Thema zu lernen.