ACHTUNG, erneut schweres Sicherheitsloch in phpnuke/VKP-Maxi

Begonnen von Andi, 30 März 2004, 20:25:58

⏪ vorheriges - nächstes ⏩

0 Mitglieder und 1 Gast betrachten dieses Thema.

Andi

Wieder mal ein ernstes Sicherheitsloch in phpNuke.
In verschiedenen Modulen, die bbCode verwenden, ist es möglich, fast alle Funktionen des Adminbereichs indirekt auszuführen.

Mehr dazu:
http://www.securityfocus.com/archive/1/358326
http://www.nukeboards.de/index.php?showtopic=21907

Das bei securityfocus beschriebene Problem, betrifft nicht das vkpMx2.x. Allerdings ist das nicht das einzige Problem dieser Art.
Zur Sicherheit empfehlen wir, auch im vkpMx2.x, folgende Codezeilen in die mainfile.php einzufügen:

foreach ($_REQUEST as $value) {
  if (preg_match("#\[img\].*?(admin\.php).*?\[/img\]#si", $value)) die('fukk you');
  }

Die Zeile ist im Prinzip egal, am besten gleich irgendwo vor die Zeile
define("mxMainFileLoaded","1");
Das Ganze funktioniert allerdings erst mit php-Versionen ab 4.1

[Editiert am 30.3.2004 von Tora]
schön´s Grüssle, Andi

_Gerry_

Also meine Meinung dazu:

 Will man Hackern erleichtern das Leben,
soll man PhpNuke auf seinem Server geben!
Schwerr in der Installation, aber leicht zu hacken!

 
CMS-Version: pragmaMx 0.1.11, 1.33.2.12.2.9/2009-05-10   
PHP-Version: 5.2.0-8+etch5~pu1
MySQL-Version: 5.0.32-Debian_7etch1
Server-Version: Apache/2.2.3 (Debian) mod_ssl/2.2.3 OpenSSL/0.9.8c

Andi

GRÖÖÖÖÖÖÖÖÖÖHHHHHHHHHHLLLLLLLLL

Das Bild und das Gedicht sind geil  :schout:   :D  
schön´s Grüssle, Andi

_Gerry_

Is mir so auf die schnelle eingefallen!
Und eben noch schnell ein Bildchen bearbeitet und *fertich*
 :BD:
CMS-Version: pragmaMx 0.1.11, 1.33.2.12.2.9/2009-05-10   
PHP-Version: 5.2.0-8+etch5~pu1
MySQL-Version: 5.0.32-Debian_7etch1
Server-Version: Apache/2.2.3 (Debian) mod_ssl/2.2.3 OpenSSL/0.9.8c

Andi

Kleine Verbesserung, die auch die normalen imagetags, iframes und objects mit einschliesst:

 
foreach ($_REQUEST as $value) {
if (is_string($value) && !is_int($value)) {
$pattern = '#(<(img|iframe|object)[^>]+src=[^>]+admin\.php\?[^>]+\>)|(\[img\].+?(admin\.php\?).+?\[/img\])#i';
if (preg_match($pattern, $value)) {
Header("Location: index.php");
exit;
}
}
}
unset($pattern); unset($value);
 

das Ganze, ohne    ziemlich oben in der mainfile.php einfügen
schön´s Grüssle, Andi

jubilee

Grrrrr ...................
Ich hab langsam vom Patchen die Nase voll.
Entweder es sind Fehler in phpNuke oder es ist irendwas aufm Server was gepatcht, compiliert, ausgetauscht werden muss .....
Haben die Kiddies heutzutage denn nix anderes mehr zu tun ???
BTW: Tora kannst du mir mal per PM kurz
die anderen Ecken mitteilen wo es noch kriselt (vkpMaxi, das setzt ein Kumpel von mich ein und der will nicht up´graden).
Hab zwar schon jeden Menge in Reviews-, Links-, Downloads-, Search- Modul gepatcht aber kA ob ich alles gefunden hab.
MfG
jubilee

Andi

es geht weiter....

habe jetzt mal verschiedene Module in Nuke durchgesehen und etliches rumpropiert.
Der Exploit betrifft also nicht nur  den imagetag über bbCode, sondern in bestimmten Modulen auch normale HTML-Tags.
In einigen Modulen wird die Usereingabe in keiner Weise auf unerlaubte HTML-tags überprüft. Selbst wenn, gibt es auch noch "geeignete" HTML-Tags, die durch die Überprüfung durchrutschen.
In den meisten Fällen muss ein Admin zwar die Usereingabe erst freischalten, aber durch "geschicktes Verstecken" sind die Dinger leicht zu übersehen.

Während dem rumtesten habe ich meine nuke6.5 Testseite mit Adminnachrichten von oben bis unten zugemüllt....
(auch das ist möglich)

Leider ist in geringen Teilen auch das vkpMx betroffen. Deshalb auch hier, zur Sicherheit, die folgenden Zeilen in die mainfile.php einfügen.

Nachfolgend der etwas überarbeitete Fix, der auch die anderen "gefährlichen" HTML-Tags berücksichtigt.
Ausserdem hatte ich die Tatsache nicht berücksichtigt, dass auch arrays per POST übergeben werden können (Stichwort Umfragen)


foreach ($_REQUEST as $value) {
if (is_string($value) && !is_int($value)) {
  $pattern = '#(\<(img|i?frame|object|i?layer|script|link|embed)[^\>]+([[:space:]]{0,})(src|rel)([[:space:]]{0,})?=([^\>]+)?admin\.php\?[^\>]+\>)|(\[img\](.+)?(admin\.php\?).+?\[/img\])#si';
  if (preg_match($pattern, $value)) {
  Header("Location: index.php");
  exit;
  }
  }
}
unset($pattern); unset($value);


ACHTUNG:
der Teil, $pattern = '#(\<(img|i?frame|obje....php\?).+?\[/img\])#si'; ist EINE  Zeile, durch den Zeilenumbruch entstehen zusätzliche Leerzeichen, die müssen unbedingt raus!!

Wirkliche Sicherheit gibt es bei diesem Exploit nur über ein konsequentes Umschreiben des gesamten Adminbereichs. Dass sich irgendetwas in die Datenbank einschleichen kann, wird sich nie ganz verhindern lassen. Aber dass Adminfunktionen über einfache Get-parameter ausgeführt werden können, das lässt sich verhindern.

@ Jubilee
Das müsste alle bisher bekannten und auch die meisten zukünftigen Löcher zustopfen. Etliches was hier berücksichtigt wird ist noch garnicht bekannt.

[Editiert am 31.3.2004 von Tora]
schön´s Grüssle, Andi