Trivial zu findende Cross-Site-Scripting-Lücke

Wenn man als Benutzername im vBulletin-Testscript HTML-Code eingibt, führt das zu einer Fehlermeldung des MySQL-Servers. Diese Fehlermeldung wird ohne Escaping in der Seite ausgegeben und enthält den Benutzernamen. Damit lässt sich dort auch Javascript-Code einfügen, der im Browser ausgeführt wird.

Relevant ist ein solcher XSS-Angriff dann, wenn das Skript auf einer Seite liegt, auf der auch andere Webanwendungen vorhanden sind. Dann kann die Lücke genutzt werden, um beispielsweise die Accounts zu übernehmen.

An der XSS-Lücke ist vor allem bemerkenswert, wie einfach sie sich finden lässt. Entsprechende XSS-Angriffsvektoren in ein Formular einzugeben, ist üblicherweise das allererste, was man beim Testen einer Webanwendung auf Sicherheitslücken tut.

vBulletin reagiert schleppend auf Fehlerbericht

Wir haben beide Sicherheitslücken an die Entwickler von vBulletin gemeldet. Auf unseren Fehlerbericht hin wurde uns zunächst mitgeteilt, dass man das Problem an das Entwicklerteam weitergeleitet habe. Danach erhielten wir für längere Zeit keine Antwort.

Erst nach Rückfrage teilte man uns mit, dass ein Fix in Arbeit sei und gerade getestet werde. Details darüber oder einen Patch erhielten wir aber nicht. Anfang Juli fragten wir erneut nach. Daraufhin wurde uns mitgeteilt, dass der Fix bereits veröffentlicht worden sei. Das war allerdings nicht korrekt. Das Skript auf der vBulletin-Seite war identisch mit der Version, in der wir die beiden Sicherheitslücken gefunden hatten.

vBulletin liefert einen Fix, der nicht funktioniert

Nachdem wir das dem Support von vBulletin mitgeteilt hatten, wurde am Tag darauf eine neue Version bereitgestellt. Die Cross-Site-Scripting-Lücke war darin geschlossen. Bei der viel gravierenderen MySQL-Lücke sah es anders aus. Zwar hat man wohl versucht, diese zu schließen, der Fix funktionierte aber nicht.

vBulletin hat versucht, die Einstellung für das Laden lokaler Dateien über die entsprechende INI-Einstellung abzuschalten. Was dabei jedoch nicht bedacht wurde: PHP-Skripte können nicht alle INI-Einstellungen in PHP ändern. Die entsprechende Option (mysqli.allow_local_infile) kann nur systemweit geändert werden.

Damit es korrekt funktioniert, muss die Option für die jeweilige Verbindung geändert werden. Wir haben das vBulletin mitgeteilt und einen Patch mitgeschickt, der das Problem tatsächlich behebt. Zum Zeitpunkt dieses Artikels war das Skript auf der vBulletin-Webseite weiterhin verwundbar, wenn man eine ältere PHP-Version nutzt.

Unabhängig vom Status der Sicherheitslücken ist es empfehlenswert, das Skript nach Benutzung nicht auf dem Webserver zu belassen. Wer in der Vergangenheit das vb_test.php-Skript genutzt hat sollte prüfen, ob es weiterhin im Webroot liegt, und es gegebenenfalls entfernen. Da das Skript nur für einen kurzen Test genutzt werden sollte, gibt es keinen Grund dafür, dass es dauerhaft im Web erreichbar ist. Ein Test, mit dem man Server auf das Vorhandensein des Skripts checken kann, steht im Tool Snallygaster zur Verfügung, das vom Autor dieses Artikels entwickelt wurde.