Nicht authentifizierte Remote-Code-Ausführung in vBulletin durch Missbrauch der Reflection API bei der Anzeigenverwaltung

Eine schwerwiegende Sicherheitslücke wurde in der Forensoftware vBulletin (Versionen 5.0.0 bis 5.7.5 sowie 6.0.0 bis 6.0.3) entdeckt. Diese Schwachstelle ermöglicht es Angreifern ohne Foren-Account, schädlichen Code auf dem Server auszuführen, der das Forum hostet. Dies kann zur vollständigen Übernahme des Servers führen, mit potenzieller Offenlegung sensibler Daten, Website-Defacement oder der Nutzung des Servers für weitere Angriffe. Das Problem ist besonders relevant für Foren, die aktuelle PHP-Versionen (ab 8.1) verwenden, und wird Berichten zufolge bereits aktiv ausgenutzt.

ProduktvBulletin
Datum02.06.2025 16:14:45
Informationen
  • Fix verfügbar
  • Aktive Ausnutzung

Technische Zusammenfassung

Die vBulletin-Versionen 5.0.0 bis 5.7.5 und 6.0.0 bis 6.0.3 sind anfällig für eine Remote Code Execution (RCE)-Schwachstelle ohne Authentifizierung. Die Hauptursache liegt in einer unzureichenden Berechtigungsprüfung in Kombination mit der unsachgemäßen Verwendung der PHP Reflection API, was insbesondere den Endpunkt ajax/api/ad/replaceAdTemplate betrifft.

Die als CVE-2025-48827 identifizierte Schwachstelle ermöglicht es nicht authentifizierten Benutzern, geschützte API-Controllermethoden aufzurufen, wenn die Software unter PHP 8.1 oder höher ausgeführt wird. Dies liegt daran, dass sich das Verhalten der Reflection ab PHP 8.1 geändert hat, was es unter bestimmten Bedingungen potenziell ermöglicht, die vorgesehenen Zugriffskontrollen zu umgehen.

Angreifer können diese Schwachstelle ausnutzen, indem sie eine entsprechend präparierte POST-Anfrage an den Pfad / senden, wobei der Parameter routestring auf ajax/api/ad/replaceAdTemplate gesetzt ist. In dieser Anfrage ist es möglich, in den Parameter template ein bösartiges vBulletin-Template-Tag einzuschleusen, wie z. B. <vb:if condition='" ... "'>, das beliebigen PHP-Code enthalten kann, beispielsweise passthru($_POST['cmd']) oder, wie im bereitgestellten Nuclei-Template zu sehen, var_dump("some_random_string") als Proof-of-Concept.

Eine zweite POST-Anfrage, ebenfalls an / mit dem routestring auf ajax/render/ad_<location> (wobei <location> dem in der ersten Anfrage verwendeten Wert entspricht), löst das Rendering des injizierten Templates aus und führt somit den PHP-Code mit den Privilegien des Webserver-Benutzers aus.

Der Exploit nutzt somit einen zweistufigen Prozess: Zuerst wird der bösartige Template-Code über replaceAdTemplate injiziert und anschließend über ajax/render/ad_<location> gerendert und ausgeführt. Dies ermöglicht es einem nicht authentifizierten Angreifer, eine Remote Code Execution zu erreichen.

Zudem wird die Schwachstelle CVE-2025-48828 erwähnt, die sich wahrscheinlich auf einen eng damit verbundenen Aspekt dieser Schwachstellenkette oder auf das allgemeinere Problem des Aufrufs geschützter Methoden bezieht.

Empfehlungen

  1. Sofortiges Update: Aktualisieren Sie vBulletin auf Version 6.0.4 oder höher. Wenn Sie vBulletin 5.x verwenden, wenden Sie alle verfügbaren Sicherheitspatches an, insbesondere solche, die den Aufruf geschützter Controllermethoden und die Absicherung der Werbeersatz-Funktion betreffen.
  2. Web Application Firewall (WAF): Implementieren Sie WAF-Regeln, um Anfragen zu blockieren, die versuchen, diese Schwachstelle auszunutzen. Diese Regeln könnten:
    • Den Parameter routestring auf verdächtige Werte wie ajax/api/ad/replaceAdTemplate oder ajax/render/ad_ untersuchen.
    • vBulletin-Template-Tags (<vb:if> usw.) erkennen, die PHP-Ausführungsfunktionen (z. B. passthru, shell_exec, system, eval, exec, var_dump) innerhalb des template-Parameters des replaceAdTemplate-Aufrufs enthalten.
    • Den direkten Aufruf geschützter API-Methoden blockieren, sofern die WAF in der Lage ist, solche Muster zu identifizieren.
  3. Überlegungen zur PHP-Version: Obwohl die Möglichkeit zur Ausnutzung der Schwachstelle unter PHP 8.1+ größer ist, können die zugrunde liegenden logischen Fehler auch in älteren PHP-Versionen existieren. Verlassen Sie sich nicht auf die Verwendung einer älteren PHP-Version als vollständige Schadensbegrenzung.
  4. Analyse der Server-Logs: Überwachen Sie die Zugriffsprotokolle des Webservers und die Anwendungsprotokolle auf Anfragen, die dem Exploit-Muster entsprechen (POST-Anfragen an / mit routestring=ajax/api/ad/replaceAdTemplate oder routestring=ajax/render/ad_), um mögliche Kompromittierungsversuche zu erkennen.

[Callforaction-THREAT-Footer]

Leave a Reply

Your email address will not be published. Required fields are marked *