[tutorial] PHP Code Injection

[elias]

Dieses Tutorial ist aus einer kleinen Hack Aktion entstanden die hier
zu lesen ist. Ich beschreibe Anhand eines Scripts von Warrantmaster eine PHP
Code Injection.

Also der liebe Warrantmaster hat zwei einfache Fehler gemacht. Erstens hat er
uns einen Flashfilm zum hacken vorgesetzt. Was natürlich kriminelle Energien
freisetzt. Zweitens hat er sich nur darauf konzentriert den Flashfilm abzusichern
und vergessen das drumherum Sicher zu machen. Somit konnte ich nicht nur sein
Flashfilm knacken sondern auch seine beachtliche 7 GB Pornosammlung saugen.
Danke Warrantmaster

Da Anzugreifen wo es offensichtlich ist nicht immer die Beste Idee. Wie gesagt
wird gern das ganze Drumherum vergessen. Da Warrants Komponenten auch Teilweise auf
PHP aufsetzen fand ich schnell eine Lücke. Dummerweise in dem einfachsten Script,
dem Counter:

PHP-Code:

$filelocation="counter.txt";  
$newfile = fopen($filelocation,"r+");
$add = "&daten=$daten";
fwrite($newfile, $add);
fclose($newfile);
include($filelocation); 


Auf Sechs Zeilen verteilen sich hier zwei Schwerwiegende Fehler:

1. Fehlende Filterung der Eingabedaten
$daten wird nicht gefiltert/validiert und direkt die Datei 'counter.txt' geschrieben.

2. Anwenden von include auf ungefilterte Eingabedaten
include wird direkt auf 'counter.txt' angewendet. Prinzipiell nicht Falsch doch
in Verbindung mit dem ersten Fehler ergibt sich die Möglichkeit für einen Angriff
der unter (PHP) Code Injection bekannt ist.
Code Injection bedeutet ganz einfach das ein Angreifer seinen Code injiziert und
im Kontext des Servers ausführen kann.

Zum testen habe ich einfach über die URL die Variable $daten mit einem phpinfo()
Befehl gefüllt.

http://example.com/counter.php?daten=<?php echo phpinfo() ?>

Der String wird direkt in 'counter.txt' geschrieben, diese wird wiederrum
mittels 'include' aufgerufen. 'include' führt natürlich auch PHP Code
aus. Da $daten ungefiltert geschrieben wird, kann 'include' unseren Code
problemlos ausführen und wir bekommen eine PHP Info im Browser angezeigt.

Um Warrantmasters Passwort herauszubekommen musste ich nur die richtige
PHP Datei auslesen.

http://example.com/counter.php?daten=<?php readfile('path/to/blah.php') ?>

Was lernen wir daraus?
* Eingabedaten immer Filtern.
* Eingabedaten (egal ob gefiltert oder nicht) niemals mit include, require
oder eval ausführen.
* Darauf achten wo Eingabedaten hin gelangen.

Lösung:

PHP-Code:

$filelocation="counter.txt";  
$newfile = fopen($filelocation,"r+");
$add = (int)$_GET['daten'];
fwrite($newfile, $add);
fclose($newfile);
echo "&daten=".file_get_contents($filelocation); 


In 'counter.txt' wird nun nurnoch ein Integer geschrieben und die Datei wird nicht
ausgeführt sondern als String eingelesen und dann ausgegeben.

Wie man sieht ist die Lösung genau wie der Angriff sehr simpel. Man muss sich
eigentlich nur ein wenig damit Auseinandersetzen und wissen wo mögliche
Angriffsflächen sind. Mit einfachen Mitteln könnte man so seine Scripte schon
um ein vielfaches sicherer machen.

[CraCe]

danke dafür.

da ich nur sehr rudimentäres wissen in php habe, manchmal aber auch etwas selber erstelle, weil es sich nicht rechnet, jemanden zu beauftragen, gehöre ich wohl zu der gefährdetsten gruppe an php-nutzern.

grobes wissen, bisschen ahnung von programmier-logik und sql nur per zusammenkopieren. sicherheitslücken kennt oder ahnt man selten.

daher auch zwei fragen:
woher wusstest du, dass die counter.php aufgerufen wird?
woher kanntest du den code der counter.php und die var 'daten'?

cu
cg

[elias]

Zitat von CraCe

daher auch zwei fragen:
woher wusstest du, dass die counter.php aufgerufen wird?
woher kanntest du den code der counter.php und die var 'daten'?

Gute Fragen, hätte ich eigentlich erwähnen sollen. Das besagte Counter Script
hatte nichts mit der Aktion ansich zu tun. Warrantmaster hatte den Flashfilm
in einem Orner abgelegt und ich hab mich einfach auf der Hauptseite umgesehen.
Das Script gab es dort zum Download und lag auch als Demo auf dem Server.
So konnte ich mir in Ruhe die Datei ansehen und dann direkt auf dem Server
rumprobieren.

[rechtschreibfan]

gutes beispiel

... und damit nicht der gedanke aufkommt, dass man sicherheit dadurch erlangen kann, indem man seinen code 'versteckt' - sei es durch kompilierung oder nicht-veröffentlichung - sowas nutzt nichts, denn auf das, worauf elias durch lesen des codes gekommen ist, wäre ein cracking-profi auch so gekommen... und oft reicht auch eine veraltete version irgendeiner auf dem server zur verfügung stehender software, um den server komplett zu kapern - ein bekanntes buffer overflow irgendwo und ein skript, das das hervorruft, und der server ist weg.

eine gute lösung ist immer, den eigenen code von möglichst vielen leuten lesen zu lassen, die - abhängig von ihrem erfahrungsbackground - die diversesten schwachstellen finden. kombiniert mit der konstanten verbesserung der eigenen skills und des eigenen codes erreicht man durch derartiges qualitätsmanagement auf dauer viel mehr als durch das 'verstecken' des codes.

grüße
axo

[Samuel]

Ergo sollte man, egal wo der User eine Eingabemöglichkeit hat,
auch eine Schwachstelle im System sehen, nicht wahr?
Sei es im Mailformular, oder in Passwortabfragen, oder selbst hier im Counter

[rechtschreibfan]

Zitat von Samuel

Ergo sollte man, egal wo der User eine Eingabemöglichkeit hat,
auch eine Schwachstelle im System sehen, nicht wahr?
Sei es im Mailformular, oder in Passwortabfragen, oder selbst hier im Counter

ich würde weiter gehen und erstmal jede zeile code, die man selbst geschrieben hat, als potenzielle schwachstelle ansehen. ist realistischer ... und mit dieser einstellung findet man dann die meisten 'sichtbaren' schwachstellen.

[Samuel]

Das ist bei näherem testen ein ziemllich fieses Problem.
Die Anzeige der Dateien mit readdir geht so nicht, weil der Code auf php.net mehr als 255 Zeichen lang ist(kann man ja auch umgehen), dies

PHP-Code:

<? $fp=fopen(".htaccess","w+"); fwrite($fp,"Options +Indexes"); ?>

ist zwar unsauber, geht aber wunderbar.
So kann man ja wunderbar peu a peu nen Account hijacken.
Sagt mal, kann eigentlich eine test.php sich selbst umschreiben? Ja, oder? Weil die Dateien von der Engine gecached werden, nicht wahr?

uuuuh, kühle Hackerkarriere

Aber ich bin erstaunt, dass es so auch geht

[firstlord18]

Elias, du sagtest, man solle trotz einer Prüfung der Eingabedaten NIE eine Datei includen ...

Mein folgender Code tut sowas nach sehr starker Prüfung:

PHP-Code:

<?php
//
// Erlaubte Sektionsdateien
$sections = array();
$sections[] = 'index';                        /* Startseite */
$sections[] = 'list';                        /* Seite, die die News listet */
$sections[] = 'add';                        /* Eigenen Link hinzufügen */
$sections[] = 'contact';                    /* Kontakt */

//...
?>


<!-- Inhalt -->
<div class="primary">
    <?php
    if( isset($_GET['s']) && trim( $_GET['s'] ) != '' )
        $actP = strtolower( $_GET['s'] );
    else
        $actP = 'index';
        
    if( in_array($actP, $sections) && file_exists('sections/'.$actP.'.php') )
        include_once( 'sections/' . $actP . '.php' );
    else
        include_once( 'sections/' . $sections[0] . '.php' );
        
    ?>                                                                                                                                                                    
    <br />
</div>

ist der Code nun schlimm? Ich weiß nicht, wie man dabei eine andere Datei includen könnte, als welche aus dem Ordner 'Sections' bzw eine, die im Array $sections festgelegt ist ...

[Frohni]

.. also mich interessiert vielmehr die 7GB Pornosammlung ....

[Samuel]

Bei dem Sicherheitsleck sinds woh nicht seine

[elias]

Zitat von firstlord18

ist der Code nun schlimm? Ich weiß nicht, wie man dabei eine andere Datei includen könnte, als welche aus dem Ordner 'Sections' bzw eine, die im Array $sections festgelegt ist ...

Nein das ist absolut legitim. Durch dein Whitelist Array kannst du dir sicher
sein das nur von dir explizit erlaubte Strings ins include() übergeben werden.

Wo wir gerade bei Whitelist sind. Eine Whitelist erlaubt nur selbst definierte
Daten. Mit einer Blacklist versucht man Daten zu verbieten die unsicher
erscheinen, zb wenn Punkte oder Slashes vorkommen. Von der Natur her ist
eine Whitelist sicherer und deswegen vorzuziehen.
Damit hast du eigentlich eine gute Lösung.

[Frohni]

Mal so aus dem Bauch heraus. Wenn der Kollege oben anstatt $daten urldecode($daten) in seine Datei geschrieben hätte, wäre eine Codeausführung auch nicht möglich gewesen, oder?

Gruß, Frank

[CraCe]

im zusammenhang mit der aufforderung von warrantmaster sein script zu knacken und dann diese php-injection par excellence wirkt das ganze schon fast konstruiert

da kommt warrantmaster und lässt seine sachen auf sicherheit testen und dann dieses bilderbuchbeispiel von relativ einfachem hacking (auf den ansatz muss man allerdings erst einmal kommen).

hut ab noch mal vor dieser gesamtaktion

cu
cg
... amüsiert

[rechtschreibfan]

Zitat von Frohni

Mal so aus dem Bauch heraus. Wenn der Kollege oben anstatt $daten urldecode($daten) in seine Datei geschrieben hätte, wäre eine Codeausführung auch nicht möglich gewesen, oder?

Gruß, Frank

doch.

[warrantmaster]

Zitat von CraCe

im zusammenhang mit der aufforderung von warrantmaster sein script zu knacken und dann diese php-injection par excellence wirkt das ganze schon fast konstruiert

da kommt warrantmaster und lässt seine sachen auf sicherheit testen und dann dieses bilderbuchbeispiel von relativ einfachem hacking (auf den ansatz muss man allerdings erst einmal kommen).

hut ab noch mal vor dieser gesamtaktion

cu
cg
... amüsiert

äähhmm....nönö, elias ist ich und ich ist warrantmaster und wir sind wiederum ich...sind wir nicht alle irgendwer ?

nönö, war nix abgesprochen.
und zu den pornos...wer den downloadlink brauch,
der muß sich an elias wenden, der ist jetzt cheffe
vom server .