Seite 5 von 6
Verfasst: 15.05.2006 19:41
von thompson
also ich hab auch erst mal die datei umbenannt.
den upload an sich will ich nicht verbieten. was kann ich noch tun ?
Verfasst: 06.06.2006 12:59
von stw
TK hat geschrieben:Verlinkte Avatare sind das gefährlichste überhaupt: Wenn z.B. jemand ohne Cookies im Forum surft, dann wird bei ihm immer die SID in der URL angehängt. Wenn jetzt ein fremdes Bild von einem anderen Server als Avatar in den Foren-Seiten "eingebettet" geladen wird, dann erscheint in den Server-Logs des fremden Servers die URL, von der das Bild angefordert wurde. Also die URL mit SID.
Gibt es da einen Unterschied zwischen Bildern und Avataren?
In meinen logs steht keine URL, sondern lediglich die IP des anfordernden Rechners. Wieso sollte das board die URL rausschmeissen? Macht doch gar keinen Sinn. Das Bild wird doch nur auf der Betrachterseite in einer entsprechend generierten page eingebaut.
Oder stehe ich hier auf dem Schlauch?
Verfasst: 08.06.2006 19:41
von kellanved
Underhill hat geschrieben:Hi,
wie gesagt - Ich bin nicht der Crack in diesen Dingen - aber schau dir doch mal das z.B. Video "(WBB Portal) Cross-Site Scripting Using Unsanitized jpg File" unter milw0rm an... dann wird dir sicher auch ganz anders
Die unzureichende Bilderreinigung ist beim WBB bekannt - das Problem ist seit Jahren ungepatcht. Beim phpBB wurde es aber vor einigen Versionen behoben; auch vB und IPB hatten das Problem. (ist eigentlich ein IE Bug)
Verfasst: 08.06.2006 21:25
von felixx
Hi,
ist der Fehler nun mit dem Update auf 2.0.21 behoben?
Oxpus sagt
nein und Anommander Rake sagt
ja.
Was ist denn nun richtig?
Verfasst: 08.06.2006 21:54
von kellanved
Der Fehler beruhte - unter Anderem - auf der unzureichenden Behandlung der Konfigurationseinstellung default_lang. Die Updateanleitung zeigt:
Code: Alles auswählen
#
#-----[ FIND ]---------------------------------------------
# Line 314
$board_config['default_lang'] = $userdata['user_lang'];
#
#-----[ REPLACE WITH ]---------------------------------------------
#
$default_lang = phpbb_ltrim(basename(phpbb_rtrim($userdata['user_lang'])), "'");
#
#-----[ FIND ]---------------------------------------------
# Line 327
if ( !file_exists(@phpbb_realpath($phpbb_root_path . 'language/lang_' . $board_config['default_lang'] . '/lang_main.'.$phpEx)) )
{
$board_config['default_lang'] = 'english';
}
#
#-----[ REPLACE WITH ]---------------------------------------------
#
else
...
Was umgebogene Verweise in den Sprachordner ziemlich sicher abtöten sollte.
suntzu giving you the pain
Verfasst: 08.06.2006 22:35
von Underhill
Hi,
sorry, aber der "phpBB <= 2.0.20 (Admin/Restore DB/default_lang) Remote Exploit" von milw0rm ist
NICHT behoben.
Ich habe es gerade an einem Vanilla phpBB 2.0.21 getestet...
Wenn einer an die akuelle AdminsessionID kommt kann er ueber diesen Exploit einen Adminuser anlegen
Edit:
Gegentest: Bei einem zweiten Test ohne die "admin_db_utilities.php" war der Exploit nicht erfolgreich...
Gruss
Underhill
Verfasst: 08.06.2006 22:43
von felixx
Hi Underhill,
Danke Dir für den Test und die Info!

Verfasst: 08.06.2006 22:50
von Underhill
Hi,
Nachtrag:
Leider funktioniert seit der Umstellung der Sessiontabellen mit phpBB2.0.21 auch
unser Hotfix nicht mehr...
Ergo: Wer
ganz sicher gehen will sollte erstmal die "admin_db_utilities.php" weglassen...
Gruss
Underhill
Verfasst: 08.06.2006 22:59
von IPB_Flüchtling
Auch von mir danke für den Test, Underhill!
Man sollte
vor der admin_db_utilities.php sowieso warnen: Gibt viel zu viele Kollegen, die damit ihre Backups > 2 mb anfertigen und sich dann wundern, weshalb sie nicht funktionieren.
Habe die Datei (und die zugehörige .tpl-Datei) vollständig gelöscht. Überdies ist der Admin-Ordner bei mir per .htaccess passwortgeschützt.
LG, IPB_Flüchtling
EDIT: Vielleicht solltest Du den Titel dieses Threads in "Remote Exploit unter 2.0.21?" ändern?
Verfasst: 08.06.2006 23:13
von kellanved
In dem Fall muss ich mich entschuldigen.
Nur die zweite Hälfte des Exploits (Ausführung des PHP Codes im Avatar) funktioniert nicht mehr.
Der Teil in eine Admin-Session zu springen, um damit Eine SQL-Anfrage abzusetzen wird noch gehen. Allerdings ist es relativ schwierig in eine Admin-Session zu springen. Geht nur bei IP-Adressen aus dem gleichen Subnetz und bekannten Session-IDs -> in freier Wildbahn nur sehr selten ausnutzbar.