Sicherheitslücken in "CMS"en

[Tom]

Hello,

ich sammele so nebenbei "Sicherheitslücken" in Content-Management-Systemen oder was sich dafür hält.

Wo ist da die Lücke?
Abgesehen von "register_globals = on" bin ich der Meinung, dass man mit dem Code auf dem Server spazieren gehen kann.

#if($id == null || $id == "")
       #{
       #  $file = DATAPATH . "001" . ".php";
       #  include $file;
       #}
       #else
       #{
       #  $file = DATAPATH . $id . ".php";
       #  include $file;
       #}

Auskommentiert, damit das ja keiner benutzt ;-)

Wenn Ihr auch noch ein paar nette Standart[tm]-Lücken für mich habt, postet fleißig. Ich freu mich drauf. *grins*

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[wahsaga]

hi,

Wo ist da die Lücke?

rhetorische frage?

Abgesehen von "register_globals = on" bin ich der Meinung, dass man mit dem Code auf dem Server spazieren gehen kann.

ja, das sieht mir auch so aus.

gruß,
wahsaga

[Tom]

Hello,

Wo ist da die Lücke?

rhetorische frage?

Ja und nein.

Die 'normale' Lücke ist offensichtlich. Durch einfügen von genügend '%2f" kann man beim Root-Verzeichnis anfangen, alle PHP-Files (also die mit Endung *.php) aufzurufen. Die sollten ja normalerweise dann noch geparst werden.

Ich suche aber noch...
Einige PHP-Versionen scheinen das include()-Argument an einem Leerzeichen im Filenamen abzubrechen.
Kann natürlich auch Zufall sein, das ich eine Installation gefunden habe, die das macht.

Fallen Dir noch weitere Möglichkeiten einmn, das angehängte '.php' durch den Parameter abzuspalten, aufzufressen oder sonstiges...?

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[wahsaga]

hi,

Die 'normale' Lücke ist offensichtlich. Durch einfügen von genügend '%2f" kann man beim Root-Verzeichnis anfangen, alle PHP-Files (also die mit Endung *.php) aufzurufen.

%2f? zwei punkte davor aber wohl auch noch, denn sonst kommst du von DATAPATH aus ja nicht auf höhere ebenen.

Einige PHP-Versionen scheinen das include()-Argument an einem Leerzeichen im Filenamen abzubrechen.
Kann natürlich auch Zufall sein, das ich eine Installation gefunden habe, die das macht.

ist mir bisher noch nicht bekannt. evtl. OS-abhängig?

Fallen Dir noch weitere Möglichkeiten einmn, das angehängte '.php' durch den Parameter abzuspalten, aufzufressen oder sonstiges...?

"sie haben post" ... weiteres lieber per mail, bevor sich wieder jemand aufregt, wir würden tipps zum hacken geben ;-)

gruß,
wahsaga

[Tom]

Hello,

%2f? zwei punkte davor aber wohl auch noch, denn sonst kommst du von DATAPATH aus ja nicht auf höhere ebenen.

Sooo genau wollte ich das nicht beschreiben

"sie haben post" ... weiteres lieber per mail, bevor sich wieder jemand aufregt, wir würden tipps zum hacken geben ;-)

eben drum.
Ich schau mal.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Henryk Plötz]

Moin,

ist mir bisher noch nicht bekannt. evtl. OS-abhängig?

Also Leerzeichen eher nicht. Das Standardproblem ist ein Stringabschneiden an NUL-Zeichen, aber das ist ein Bug der IIRC schon vor einem oder mehreren Jahren korrigiert wurde.

"sie haben post" ... weiteres lieber per mail, bevor sich wieder jemand aufregt, wir würden tipps zum hacken geben ;-)

Sprich dich ruhig aus. Wir sind hier schliesslich nicht in Amiland und noch darf man hier offen über allerlei Dinge reden.

[Tom]

Hello,

Also Leerzeichen eher nicht. Das Standardproblem ist ein Stringabschneiden an NUL-Zeichen, aber das ist ein Bug der IIRC schon vor einem oder mehreren Jahren korrigiert wurde.

Weder Leerzeichen noch NUL machen neueren den getesten Systemen 'wsas aus. Allerdings habe ich bei einem PHP 4.0.3 auf einem Windows 98 installiert das Verhalten bei einem Leerzeichen. Es wird im include nur bis zum Leerzeichen gelesen und dann abgebrochen, aber kein Fehler ausgelöst. Es wird also die Datei mit dem untergeschobenen Namen geholt.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Andreas Korthaus]

Hi Henryk!

Also Leerzeichen eher nicht. Das Standardproblem ist ein Stringabschneiden an NUL-Zeichen, aber das ist ein Bug der IIRC schon vor einem oder mehreren Jahren korrigiert wurde.

Mich würde mal interessieren wann genau, ich weiß dass es bei 4.1.2 noch funktioniert! Irgendwie finde ich dazu nix...

Grüße
Andreas

[Axel Richter]

Hallo,

#if($id == null || $id == "")
       #{
       #  $file = DATAPATH . "001" . ".php";
       #  include $file;
       #}
       #else
       #{
       #  $file = DATAPATH . $id . ".php";
       #  include $file;
       #}
Wo ist da die Lücke?

Das kann man aus dem Stück Code nicht ersehen. Woher kommt $id? Was wurde vorher damit gemacht? Fragen über Fragen ;-)).

Wenn in der Konstante DATAPATH z.B. "myscript" drinsteht und $id daraufhin überprüft wurde, dass nur "002", "003" oder "004" drin stehen darf, dann ist da überhaupt keine Lücke.

Abgesehen von "register_globals = on"

Das erkennst Du woran? Am Stück Code ist es nicht zu erkennen.

viele Grüße

Axel

[Tom]

Hello,

Abgesehen von "register_globals = on"
Das erkennst Du woran? Am Stück Code ist es nicht zu erkennen.

Das erkenne ich an der Servereinrichtung und das war die Information, woher $id kommen kann. ;-)

Aber wie wahsaga schon schrieb, will auch ich keine Anleitungen geben, sondern suche Tipps von Leuten, die sich mit der Thematik auch schon auseinandergesetzt haben.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Helmut Weber]

Hallo Tom,

ich kann Dir das Buch "Sicherheitsrisiko Web-Anwendung" von Sverre H. Huseby zu diesem Thema wärmstens empfehlen.

In diesem Buch wird mit anschaulichen Beispielen erläutert, wie man Web-Anwendungen gegen Session-Hijacking, SQL-Injection und Cross-Site-Scripting absichert.
Erstaunlich wie viele Möglichkeiten es gibt, eine Web-Anwendung zu knacken ;)

Schönes Wochenende noch!

Gruß
Helmut Weber

[Johannes Zeller]

Hallo Helmut,

ich kann Dir das Buch "Sicherheitsrisiko Web-Anwendung" von Sverre H. Huseby zu diesem Thema wärmstens empfehlen.

In diesem Buch wird mit anschaulichen Beispielen erläutert, wie man Web-Anwendungen gegen Session-Hijacking, SQL-Injection und Cross-Site-Scripting absichert.
Erstaunlich wie viele Möglichkeiten es gibt, eine Web-Anwendung zu knacken ;)

Zum Thema allgemein auch empfehlenswert: http://phpsec.org/

Schöne Grüße,

Johannes