Remote Exploit unter 2.0.20 und .21?

[thompson]

also ich hab auch erst mal die datei umbenannt.

den upload an sich will ich nicht verbieten. was kann ich noch tun ?

[stw]

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?

[kellanved]

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)

[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?

[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.

[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

[felixx]

Hi Underhill,

Danke Dir für den Test und die Info!

[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

[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?

[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.