Skip to content

Gibt es eine 0-Day-Schwachstelle in vBulletin oder nicht?

Angeblich wurden Server von vBulletin.com und MacRumors vom "Inj3ct0r Team" über eine 0-Day-Schwachstelle in vBulletin kompromittiert. vBulletin glaubt nicht, dass es eine 0-Day-Schwachstelle in vBulletin gibt, bei vBulletin wurde ein unsicheres Testsystem kompromittiert. Es ist schön, wenn die vBulletin-Entwickler das glauben, im Bereich der Sicherheit interessieren aber nur Fakten. Also werfen wir mal einen Blick auf die bekannten Fakten.

14.11: Die Hacker melden sich zuerst

Los geht es mit der Ankündigung vom "Inj3ct0r Team" vom 14. November:

"Inj3ct0r Team hacked vBulletin.com and Macrumors.com

Inj3ct0r Team hacked the big CMS vendor vBulletin.com

We got shell , database and root server. We wanted to prove that nothing in this world is not safe.

We found a critical vulnerability in vBulletin all versions 4.x.x and 5.?.x

We've got upload shell in vBulletin server, download database and got root.

[...]

Macrumors.com was based on vBulletin CMS. We use 0day exploit on vBulletin, got password moderator. 860000 hacked too.

The network security is a myth"

Diese Aussagen werfen zumindest eine Frage auf: Die haben einen vBulletin-Exploit verwendet und damit root-Rechte erhalten? Ich hoffe, dass ist eine Verkürzung der tatsächlichen Tatsachen, denn das würde ja bedeuten, dass vBulletin mit root-Rechten lief. Und das ist ja wohl hoffentlich nicht der Fall. Webanwendungen müssen bekanntlich mit möglichst niedrigen Benutzerrechten laufen. Vermutlich wurden die root-Rechte nach dem Hochladen einer Shell über eine lokale Privilegieneskalation erlangt, oder es gibt sie gar nicht. Aber machen wir weiter mit den bekannten Fakten:

15.11: vBulletin meldet einen Angriff

Am 15. November hat vBulletin die Benutzer aufgefordert, ihre Passwörter zu ändern, da ein Angreifer Zugriff auf Benutzer-IDs und verschlüsselten Passwörtern hatte:

"[...] Very recently, our security team discovered sophisticated attacks on our network, involving the illegal access of forum user information, possibly including your password. Our investigation currently indicates that the attackers accessed customer IDs and encrypted passwords on our systems. [...]"

Dazu erst mal eine Feststellung: Wenn die Passwörter wirklich verschlüsselt waren, war das bodenloser Leichtsinn. Passwörter müssen immer als gesalzener Hashwert gespeichert werden, am besten mit einer speziell dafür entworfenen Hashfunktion. Eine Verschlüsselung kann umgekehrt werden, danach hat der Angreifer sofort das Klartextpasswort. Adobe hatte auch den Fehler gemacht, die Passwörter nur zu verschlüsseln, und das inzwischen vermutlich bitter bereut. Einfach gehashte Passwörter und sogar gesalzen gehashte Passwörter lassen sich zwar mit mehr oder weniger Aufwand ebenfalls ermitteln, aber genau deswegen wurden ja spezielle Funktionen zum Hashen von Passwörtern entwickelt, bei denen das Berechnen der Passwörter nicht in brauchbaren Zeiträumen möglich ist. Aber kommen wir zurück zum Angriff auf vBulletin.

Als nächstes drängt sich mir die Frage auf, wieso die Angreifer nach der Kompromittierung des Testsystems Zugriff auf die Benutzerdatenbank hatten. Testsysteme sind zum Testen da und damit immer potentiell unsicher. Und von so einem System kann auf die Benutzerdatenbank zugegriffen werden? Das ist dann in der Tat ein unsicheres System.

17.11.: The Hacker News zeigen Screenshots

Aber machen wir mit den bekannten Fakten weiter. Am 17. November berichtete Mohit Kumar auf The Hacker News über den Angriff auf vBulletin.com und das Forum von MacRumors, der mit einigen Beweis-Screenshots vom "Inj3ct0r Team" illustriert ist. Gehen wir mal davon aus, dass die echt sind, immerhin hat vBulletin selbst zugegeben, Opfer eines Angriffs geworden zu sein. Zu sehen sind eine Datenbank-Übersicht, Listen mit (teilweise ausgeblendeten) Zugangsdaten sowie eine der üblichen PHP-Shells. Also dass, was bei einer Kompromittierung einer Webanwendung quasi üblich ist. Die Frage, ob es die behauptete 0-Day-Schwachstelle in der vBulletin-Software gibt, wird damit aber nicht beantwortet.

19.11.: vBulletin glaubt nicht an einen 0-Day-Exploit

Dazu schreibt Wayne Luke am 19.11. folgendes:

"Given our analysis of the evidence provided by the Inject0r team, we do not believe that they have uncovered a 0-day vulnerability in vBulletin."

Wie oben schon geschrieben: Glauben können die viel, wichtig ist, wie es mit den Fakten aussieht. Und die sind sie schuldig geblieben. Gibt es die Schwachstelle, oder gibt es sie nicht? Glaube bedeutet, dass es sie vielleicht gibt, vielleicht aber auch nicht. Mit so einer Aussage ist niemanden geholfen, ganz im Gegenteil: Wenn es um Sicherheit geht, muss man immer vom schlimmsten ausgehen, und das bedeutet in diesem Fall, dass bis zum Beweis das Gegenteils von der Existenz der 0-Day-Schwachstelle ausgegangen werden muss. Deshalb wurde zum Beispiel das Forum der DefCon-Sicherheitskonferenz bis zur Lösung des Problems stillgelegt:

DefCon-Forum außer Betrieb
Abb. 1: Das DefCon-Forum wurde vorübergehende still gelegt (Klick für großes Bild)

Ein Zwischenfazit

Es steht bisher also Aussage gegen Aussage:

"Inj3ct0r Team": "Wir haben vBulletin und MacRumors über eine 0-Day-Schwachstelle in vBulletin 4.x und 5.x angegriffen"
vBulletin: "Es gibt keine 0-Day-Schwachstelle, nur einen unsicheren Testserver"

MacRumors Angriff hilft weiter

MacRumors hat selbst noch vor dem "Inj3ct0r Team" gemeldet, dass das Forum kompromittiert wurde. Die Passwörter waren als Hashwert gespeichert, der verwendete MD5-Algorithmus ist aber für Passwörter nicht besonders sicher. Vielleicht hilft der Angriff auf MacRumors ja bei der Suche nach dem 0-Day-Exploit - wie wurde MacRumors angegriffen?

Dazu gibt es zwei Aussagen: Laut einem Eintrag im ISC Diary war die Ursache ein "shared password", gegenüber Brian Krebs hat MacRumors-Eigentümer Arnold Kim ausgesagt, dass der Angriff über eine XSS-Schwachstelle in der veralteten Version 3.x von vBulletin erfolgte. Irgendwie gelangten die Angreifer an das Passwort eines Moderators. Damit konnten sie JavaScript-Code in eine Ankündigung einfügen, und nachdem ein Administrator diese Seite aufrief installierte dieser Code eine PHP-Hintertür. Der MacRumors-Hacker hat sich im MacRumors-Forum selbst zu Wort gemeldet und klar gestellt, dass die Schuld allein bei einem Moderator lag. Der Hacker hat sich durch die Angabe eines Teils des Passwort-Hashes und des Salts des MacRumors-Autors "Arn" identifiziert. Da Arn den Angaben nicht widersprochen hat, dürften sie richtig sein und es sich wirklich um den oder zumindest einen der Angreifer auf das MacRumors-Forum handeln.

Fazit

Damit kommen zu den obigen Aussagen zwei weitere hinzu:

"Inj3ct0r Team": "Wir haben vBulletin und MacRumors über eine 0-Day-Schwachstelle in vBulletin 4.x und 5.x angegriffen"
vBulletin: "Es gibt keine 0-Day-Schwachstelle, nur einen unsicheren Testserver"
MacRumors-Hacker: "Ich habe MacRumors über ein Moderatoren-Passwort gehackt."
MacRumors: "Wir verwenden vBulletin 3.x"

Tja, und damit haben wir einige Widersprüche:

  • Da MacRumors vBulletin 3.x verwendet, kann es nicht über eine Schwachstelle in Version 4.x und 5.x angegriffen worden sein.
  • Außerdem sagt der MacRumors-Hacker, dass ein Moderator Schuld hat und keine Schwachstelle ausgenutzt wurde, um in das Forum einzudringen.

Glauben und hoffen statt wissen

Insgesamt sieht das für mich eher so aus, als gäbe es die 0-Day-Schwachstelle nicht. Sicher überprüft werden kann das aber erst, wenn der Exploit oder eine Beschreibung der angeblichen Schwachstelle veröffentlicht wurde. Und in der gleichen Situation dürften sich die vBulletin-Entwickler befinden: Wenn deren Server nicht über die angebliche 0-Day-Schwachstelle angegriffen wurde, wissen sie nicht, wo sie danach suchen müssen. Daher glauben sie, dass es die Schwachstelle nicht gibt, wissen es aber nicht wirklich. Was den betoffenen Benutzer wenig weiter hilft. Eigentlich müsste man also sicherheitshalber davon ausgehen, dass es die Schwachstelle gibt. Was die Entwickler der betroffenen Software natürlich nur ungern tun werden.

Carsten Eilers

Trackbacks