Hallo allerseits,
vor einigen Wochen wurde relativ zeitgleich der Webspace zweier Leute, für die ich Seiten gebastelt hatte, gehackt . An meinem Rechner (also z.B. durch Ausspionieren der FTP-Passwörter) lag's nach gründlichem Check durch Trojaner-Board nicht. An einen Zufall glaubte ich trotzdem nicht; eine Sicherheitslücke in der PHP- Programmierung schien mir nicht unwahrscheinlich zu sein. Ich verfüge zwar über das absolute Basis-Sicherheits-Wissen (Superglobals usw.), aber das reicht augenscheinlich nicht: Habe jetzt einiges im Netz über die Sicherheitslücke 'Include-Dateien' gelesen, aber bislang überwiegend Bahnhof verstanden. Wer kann mir auf die Sprünge helfen?
Gruß
sandero

Welche PHP-Version wird denn eingesetzt?

Der Anbieter (:in beiden Fällen Strato) verwendet aktuell die Version 5.2.17.
Gruß,
sandero

kannst du den hack in den logs nachvollziehen, wie? ist allow_url_fopen auf on? (risiko) ist das php als cgi oder als modul?
es gibt auch löcher im ftp server, hab ich vor jahren auf meinem gehabt. dann den bereich aus dem die attacke kam , eh "nur" russland, in den iptables gesperrt.

Sagte mir zwar beides erstmal nichts, konnte ich mir aber 'ergooglen' :-).
Also:
-allow_url_fopen ist in der Tat auf 'on'. (Kann ich da was dran machen?)
-php läuft als Modul.
(Bezüglich des Anbieters habe ich übrigens Mist geschrieben: Beides Hosteurope, aber das nur am Rande.)
Aber ist das denn die gleiche Baustelle wie die 'Include- Sicherheitslücke'? Kann mir dazu jemand etwas schreiben?

Klar kann man includes als Lücken benutzen, in Kombination mit allow_url_fopen auf on sogar externe skripte von anderen servern includen lassen.
Ohne Sichtung des Quellcodes kann ich aber nicht viel zu sagen.
Sicher das es so passiert ist und nicht über ftp?

Nee, ganz und gar nicht sicher. In die Log- Dateien konnte ich noch nicht reinschauen. Habe nicht allzu viel Expertenwissen zu PHP, habe aber nochmal zum Thema 'Include' recherchiert: Da ich hierüber gar keine Variable eingebunden habe, sondern immer nur eine konkrete Datei (zur Einwahl), kann dies eigentlich nicht das Einfalltor sein, oder?
(Wenn's aber stattdessen über FTP passiert ist, müsste bei beiden Betroffenen fast zeitgleich der Tastatur- Befehl abgegriffen worden sein: Natürlich möglich, aber irgenwie glaub' ich's nicht.)
Ich häng mal die Include- Datei an sowie zwei php-Passagen aus der Datei, in welche die Include- Datei eingebunden (und die zwischenzeitkich manipuliert) wurde. Es geht hier lediglich darum, die Links zu Fotos aus einer DB zu holen, die Fotos als Thumbnail- Galerie darzustellen und die Bilder auf Klick vergrößert darzustellen. Aus Datenschutzgründen (:nicht meine Website) hab ich hier und da ** eingefügt.
Hoffe, man kann trotzdem schon etwas daraus ablesen.
Gruß,
sandero

Datei grossesbild.txt, Zeile

PHP-Code:

$wahlSorte=$_GET["so"]; 


und

PHP-Code:

 $resGr= mysql_query("select * from grossebilder where sorte=\"$wahlSorte\""); 


gaanz grober Schnitzer - du verwendest ungeprüft eine Variable aus GET in einem SQL Befehl. Du bist klassisches Opfer einer SQL Injection geworden.

Es gibt eine goldene Regel: traue NIEMALS den Eingaben eines Nutzers. _GET oder _POST sind klassische Einfallstore für Skriptkiddies.

mindestens

PHP-Code:

$wahlSorte=addslashes($_GET["so"]); 


wäre angebracht gewesen, mache dich mal schlau wie es noch besser geht. Noch besser ist es mysql_real_escape_string() zu verwenden, denn addslashes kann man über UTF auch durchdringen:
hxxp://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string

P.S. was ftp angeht, es gibt ältere ftp daemons die verwundbar waren. Man musste nur einen Stack Overflow provozieren und konnte dann ohne Passwort mit root Rechten auf den ftp zugreifen. Dazu gibt es sogar Würmer, mit einem davon musste ich mich vor ein paar Jahren auf mehreren Firmenserver herumplagen.

Ookay, den Programmierschnitzer hab ich vom Prinzip, glaube ich, verstanden.
Aber diese _GET-Variable bestimmt ja 'nur', aus welchem Teil der DB das Foto geladen wird. Könnte denn, wenn dieser Befehl korrumpiert wird, auch externer Code eingeschleust werden, oder könnte schlimmstenfalls falsches Material aus meiner Datenbank geladen werden?

Zitat von sandero

Könnte denn, wenn dieser Befehl korrumpiert wird, auch externer Code eingeschleust werden, oder könnte schlimmstenfalls falsches Material aus meiner Datenbank geladen werden?

Da könnte so ziemlich alles mit gemacht werden, vom simplen Löschen der gesamten Datenbank bis hin zum Setzen anderer Passwörter.
Wenn Du das Skript z.b. mit

PHP-Code:

hxxp://link-zum-programm/grossesbild.php?so=0; update users set passwort=md5('1234') where username like 'admin'; 


aufrufst erzeugt es folgendes SQL statement:

PHP-Code:

"select * from grossebilder where sorte=0; update users set passwort=md5('1234') where username like 'admin';" 


das sind dann 2 SQL Befehle. leuchtet es ein?
es gibt noch viel mehr Möglichkeiten, bis hin zu Code Injection. Eine ungeprüfte _GET Variable ist eine offene Einladung zum Hacken.

Ja, so leuchtet's mir allerdings ein. Öha! Mal gut, dass ich nachgefragt habe; danke für das 'Mini- Tutorial'.
Gruß
sandero

Doch noch eine Frage in selber Sache: Zwar ist mir die Brisanz der (inzwischen behobenen) Sicherheitslücke klar geworden, aber:
Um (wie ebenfalls geschehen) schadhaften Code auch in .htm- Dateien einzufügen, muss doch in irgendeiner Weise das FTP- Passwort gehackt worden sein, nicht wahr? Und das zumindest- so hoffe ich!- dürfte eigentlich nicht im Zusammenhang mit der SQL-Injection stehen können- oder doch ???

Zitat von deraddi

P.S. was ftp angeht, es gibt ältere ftp daemons die verwundbar waren. Man musste nur einen Stack Overflow provozieren und konnte dann ohne Passwort mit root Rechten auf den ftp zugreifen. Dazu gibt es sogar Würmer, mit einem davon musste ich mich vor ein paar Jahren auf mehreren Firmenserver herumplagen.

Die Antwort hatte ich schon gegeben.