nickstadb/pocRepository für Proof-of-Concept-Exploits und Tools.
Repo für Proof-of-Concept-Exploits und Tools.
Exploit für nicht authentifizierte Remote-Codeausführung gegen den RSCD-Agenten von BMC Server Automation. Der Exploit funktioniert gegen Server, die von CVE-2016-1542 betroffen sind (von Nessus erkannt).
Dies ist jetzt ein Metasploit-Modul, siehe exploits/multi/misc/bmc_server_automation_rscd_nsh_rce
Der Exploit wurde erstellt, indem Nessus ein Python-Skript gescannt hat, das Pakete aufzeichnete und sie/Müll an Nessus zurückschickte. Mit den erfassten Paketen war das Datenformat trivial zu "reverse-engineeren", um einen halbwegs funktionierenden Exploit zu erstellen. Später bekam ich Zugriff auf die betroffene Agentsoftware und konnte mit einem Debugger und etwas Fuzzing die Macken ausbügeln und dies in einen soliden RCE-Exploit verwandeln.
Schau dir meine Blogbeiträge an, wie ich den Exploit gebaut habe, für weitere Details:
Exploit für nicht authentifizierte Remote-Codeausführung für HP Device Manager Versionen 5.0.0 bis 5.0.3 (CVE-2020-6926, CVE-2020-6927).
Der Exploit nutzt einen nicht authentifizierten Java-RMI-Dienst aus, der eine Schwachstelle zur Hibernate-Query-Language-Injection aufweist. ORM-Injection wird verwendet, um ein Postgres-SQL-Injection-Payload einzuschleusen, um die Datei pg_hba.conf auf dem HP-Device-Manager-Server zu überschreiben und so den Fernzugriff auf die mit HPDM gebündelte Postgres-Datenbank zu ermöglichen. Sobald dies aktiviert ist, wird ein Hintertür-Superuser-Konto verwendet, um sich an der Postgres-Datenbank zu authentifizieren und beliebige Betriebssystembefehle auszuführen.
Schau dir meinen Blogbeitrag an, wie ich diese Schwachstellen entdeckt habe, für weitere Details:
Während dieser Exploit nur gegen HPDM 5.x funktioniert, ist der nicht authentifizierte Java-RMI-Dienst in allen Versionen von HPDM vor 5.0.4 und 4.7 Service Pack 13 vorhanden. Die Auswirkungen der Ausnutzung dieses Dienstes können geringer sein, aber es gibt weiterhin eine HQLi/SQLi-Schwachstelle, zusammen mit der Möglichkeit, Konfigurationen zu extrahieren (einschließlich möglicherweise Passwörter für andere Dienste) sowie alle HPDM-Benutzernamen und die zugehörigen MD5-Passwort-Hashes.
Exploit für nicht authentifizierte Remote-Codeausführung gegen unsicher konfigurierte JNBridge-Java-Dienstendpunkte. Basierend auf der Arbeit von Moritz Bechler (CVE-2019-7839).
Das von JNBridge implementierte Netzwerkprotokoll ist ausschließlich dazu gedacht, Remote-Codeausführung für die Interoperabilität zwischen Java- und .NET-Anwendungen zu ermöglichen. Daher ist dies technisch gesehen kein Exploit, sondern nur ein praktisches kleines Python-Skript, um beliebige Befehle gegen einen JNBridge-Java-Endpunkt auszuführen.
Schau dir meinen Blogbeitrag an, für einen Walkthrough meines Weges von der Sicherheitsmeldung bis zum vollständigen Exploit:
Dieser Exploit zielt auf unsichere automatische Update-Funktionalität in WordPress ab, um eine PHP-Shell auf dem zugrunde liegenden Server abzulegen. Der Exploit wurde erfolgreich bis WordPress 4.9.8 getestet, das zum Zeitpunkt der Veröffentlichung die neueste Version ist.
Wenn WordPress nach Updates sucht, versucht es eine sichere HTTPS-Verbindung zu api.wordpress.org herzustellen. Wenn diese Verbindung fehlschlägt, zum Beispiel weil ein nicht vertrauenswürdiges Zertifikat präsentiert wird, fällt WordPress auf eine unsichere HTTP-Verbindung zurück.
Das zweite Problem ist, dass WordPress Übersetzungs-Updates vertraut. Es aktualisiert Plugins, Themes oder größere Kernversionen nicht automatisch, vermutlich wegen der Risiken, neuen Code auf dem Server zu installieren. Es aktualisiert jedoch automatisch Übersetzungen. Leider validiert WordPress Übersetzungsarchive nicht ordnungsgemäß, sodass WordPress, solange die Übersetzungs-ZIP-Datei mindestens eine Datei mit der Erweiterung .po und eine Datei mit der Erweiterung .mo enthält, den Inhalt auf dem zugrunde liegenden Server extrahiert (einschließlich der Shell, die vom MitM dort eingefügt wurde).
Ich bin zufällig über diese Probleme gestolpert, aber als ich sie meldete (November 2017), sagte das WordPress-Team im Grunde WONTFIX wegen Abwärtskompatibilität. Wenn jemand WordPress auf einem Server betreibt, der keine ausgehende SSL/TLS-Verbindung aufbauen kann, dann sollte er WordPress aus Sicherheitsgründen trotzdem automatisch aktualisieren können, sagen sie.
¯\_(ツ)_/¯
Schau dir meinen Blogbeitrag für weitere Details an:
Einige JS-Snippets zur Ausnutzung von WordPress-XSS-Schwachstellen.
