gobysec/weblogicWebLogic-Schwachstellenanalyse vom Anfänger bis zum Experten.
Zusammenfassung: In den letzten Jahren wurden Weblogic-Deserialisierungsschwachstellen entdeckt, wobei der Fokus auf dem Auslösepunkt der Deserialisierung lag. Es gibt jedoch viele Punkte, die Deserialisierung beinhalten, aber nicht in Echtzeit ausgenutzt werden können, was bei der regulären Schwachstellenforschung leicht übersehen wird. In der Branche gab es weitere Diskussionen über „Post-Deserialisierungs“-Schwachstellen, bei denen scheinbar nicht ausnutzbare Schwachstellen tatsächlich durch nachfolgende Techniken ausgenutzt werden können. Wenn die Schwachstelle beispielsweise nach einer bind()- oder rebind()-Operation nicht ausgelöst wird, kann man andere Methoden wie lookup() oder ausprobieren, um die Schwachstelle auszulösen.
Mit diesem Ansatz haben wir zwei Weblogic-Post-Deserialisierungs-Schwachstellen (CVE-2023-21931, CVE-2023-21839) entdeckt, die von Oracle offiziell bestätigt wurden. In diesem Artikel verwenden wir diese beiden Weblogic-Schwachstellen als Beispiele, um den Denkprozess hinter der Ausnutzung von Post-Deserialisierungs-Schwachstellen zu teilen. Wir glauben, dass es in Zukunft viele ähnliche Schwachstellen geben wird, die nach und nach entdeckt werden, und wir hoffen, dass dieser Artikel Forschern einige Anregungen bieten kann.
lookupLink()Zusammenfassung: Die Weblogic-Serialisierungsschwachstelle hängt hauptsächlich von den T3- und IIOP-Protokollen ab, die viele Probleme in der Kommunikationsinteraktion aufweisen, wie z. B. sprachübergreifende Kommunikation und Netzwerkübertragung, was viele Unannehmlichkeiten für die Erkennung und Ausnutzung von Schwachstellen mit sich bringen kann. In der Philosophie von WhiteHat Labs ist die Erkennung und Ausnutzung von Schwachstellen eine kreative Arbeit, die auf möglichst prägnante und effiziente Weise umgesetzt werden sollte, um die Plattformunabhängigkeit und Praktikabilität der Schwachstelle zu gewährleisten. Daher haben wir eine sprachübergreifende IIOP-Protokoll-Kommunikationslösung implementiert, um das Problem der Serialisierungsschwachstelle zu lösen.
Zusammenfassung: Dieser Artikel behandelt die folgenden Schwachstellen: CVE-2021-2135, CVE-2021-2394, CVE-2020-2555, CVE-2020-2883, CVE-2020-14645, CVE-2020-14825, CVE-2020-14841, CVE-2020-14756. In den letzten Jahren wurden häufig Deserialisierungsschwachstellen in der WebLogic-Coherence-Komponente gemeldet. Es gibt jedoch keine öffentliche Zusammenfassung historischer Deserialisierungsschwachstellen in der WebLogic-Coherence-Komponente, was es für diejenigen schwierig macht, die Deserialisierungsschwachstellen in der WebLogic-Coherence-Komponente erlernen oder verstehen möchten. Daher bietet dieser Artikel eine Zusammenfassung und Analyse historischer Deserialisierungsschwachstellen in der WebLogic-Coherence-Komponente.
Zusammenfassung: Am 21. Juli 2021 veröffentlichte Oracle eine Reihe von Sicherheitsupdates, die 342 Schwachstellen in seinen Produkten betrafen, darunter Weblogic Server, Database Server, Java SE, MySQL usw. Darunter befindet sich eine hochriskante Schwachstelle im Oracle WebLogic Server-Produkt mit der Schwachstellennummer CVE-2021-2394 und einem CVSS-Score von 9.8. Sie betrifft mehrere WebLogic-Versionen und kann über die T3- und IIOP-Protokolle mit geringem Aufwand remote ausgenutzt werden.
Zusammenfassung: Die kürzlich offengelegte Deserialisierungs-RCE-Sicherheitslücke CVE-2020-14645 in Weblogic ist ein Bypass des Patches für CVE-2020-2883. CVE-2020-2883 rief im Wesentlichen beliebige Methoden über ReflectionExtractor auf, die dann über die exec-Methode des Runtime-Objekts beliebige Befehle ausführten. Der Patch setzte ReflectionExtractor auf die Blacklist, sodass mithilfe von UniversalExtractor eine neue Exploit-Kette konstruiert werden konnte. UniversalExtractor kann die Methoden get und is beliebig aufrufen, was zur Ausnutzung des entfernten dynamischen Klassenladens von JDNI führt. UniversalExtractor ist nur in Weblogic-Version 12.2.1.4.0 vorhanden, und dieser Artikel analysiert es auf der Grundlage dieser Version.
Zusammenfassung: Am 15. Juli 2020 veröffentlichte Oracle eine große Anzahl von Sicherheitspatches, unter denen die Sicherheitslücke CVE-2020-14644 mit einem Schweregrad von 9.8 bewertet wurde und die Versionen 12.2.1.3.0, 12.2.1.4.0 und 14.1.1.0.0 betrifft. Dieser Artikel basiert auf öffentlich verfügbarem Proof-of-Concept-Code (POC) aus dem Internet zur Reproduktion und Analyse. Schließlich erreichten wir uneingeschränktes defineClass + Instanziierung, was zu Remote-Code-Ausführung (RCE) führte.
Wenn Sie ein Problem mit einer funktionalen Art haben, können Sie ein Issue auf GitHub oder in der untenstehenden Diskussionsgruppe erstellen: