Remote File Inclusion in geschütztem Verzeichnis

C

cohilion

New Member
Hallo und guten Abend.
Nach langer Zeit des Mitlesens habe ich mich hier nun auch mal angemeldet, der Anlass dafür ist leider kein freudiger.

Durch eine Lücke in einem PHP-Script bekam ich eine Shell untergejubelt.

Diesbezüglich hätte ich an euch Experten nun mal eine Verständnisfrage.

Die Lücke befand sich in einer PHP-Datei welche in einem per .htaccess geschützten Verzeichnis liegt.
Die Datei wurde lt. log mit "POST /pfad/upload_image.php?name=namedershell.php aufgerufen. (Zum Verständis: in der upload_image.php war die Lücke!)
Daraufhin gab der Server den Statuscode 200 zurück und die shell war damit hochgeladen.

Als der Angreifer dann einige stunden später die namedershell.php aufrufen wollte - bekam er eine 401er Statusmeldung zurück. Sprich er lief gegen den htaccess-Schutz.

Danach gab es keine weiteren Aufrufe die auf die Shell zeigten, und auch die verwendeten IPs tauchten in den Logs nicht mehr auf.

Als er die shell also aufrufen wollte - gelang ihm dies offensichtlich nicht, weil er keinen Zugriff darauf bekam - da per .htaccess gesperrt!

Ich verstehe aber nicht, wie er überhaupt die Shell in den geschützten Bereich schmuggeln konnte? Beim Aufruf der upload_image.php mit ?name=namedershell.php hätte er doch normalerweise auch schon in den htaccess-Schutz laufen müssen?


P.S. Sorry, falls die Frage zu trivial ist - im Moment ist mein Kopf aufgrund des Schreckens wohl noch nicht frei genug um selber intensiv darüber nachzudenken.
 
Ja, du hast Recht.

<limit GET>
require User Mein_Benutzername
</limit>

Da die Logs zeigen, dass nach dem gescheiterten Login-Versuch in die shell keine weiteren Versuche mehr folgten:
Darf ich davon ausgehen, dass ich nochmal Glück im Unglück hatte?

Und damit ich bei der Sache auch was lerne:
Hat/Hätte es für den Angreifer eine Möglichkeit gegeben sich in die Shell einzuloggen?
 
Last edited by a moderator:
Hallo Joe User,
zunächst vielen Dank für deine Antwort.

Könntest du mir bitte kurz erläutern, wie der Angreifer sich in die Shell hätte einloggen können?
 
Wunschantwort: Ja.
Ehrliche Antwort: Nein.
Click to expand...
Da keine weiteren Log-Eintraege ausser einem spaeteren 403 zustande kamen - eher nein.
Ein Server sollte PHP-Skripte unter einem anderen Benutzer als dem Webserver ausfuehren und mit openbasedir auf ihr eigenes Verzeichnis begrenzen - somit sollte die Logfile der Realitaet entsprechen und nicht modifiziert worden sien.
 
Roger Wilco said:
Mit beliebigen POST Requests an das hochgeladene PHP-Skript.
Click to expand...

Verstehe, aber dann müsste das Skript auch in der Lage sein, solche Requests entsprechend zu interpretieren bzw. der Angreifer müsste wissen welche konkreten POST Requests er an das Script schicken muss, oder?

somit sollte die Logfile der Realitaet entsprechen und nicht modifiziert worden sien.
Click to expand...
Die Logfiles liegen in einem vom Web aus nicht zugänglichen Bereich. Darüberhinaus bräuchte man Root-Zugriff um selbige zu ändern. Da ich keinen root-Zugriff habe, sondern nur der Provider halte ich es daher für eher unwahrscheinlich, dass die Logs manipuliert wurden.
 
d4f said:
Da keine weiteren Log-Eintraege ausser einem spaeteren 403 zustande kamen - eher nein.
Ein Server sollte PHP-Skripte unter einem anderen Benutzer als dem Webserver ausfuehren und mit openbasedir auf ihr eigenes Verzeichnis begrenzen - somit sollte die Logfile der Realitaet entsprechen und nicht modifiziert worden sien.
Click to expand...
Wir haben doch schon mehrfach gelernt, dass man lokalen Logfiles nicht trauen darf. Und dedizierte User helfen einem bei Remoteshells in Kombination mit Local-Root-Exploits herzlich wenig. Von Letzteren gibt es genug ungepatchte und Erstere ist/war offen zugänglich. Was nun?
 
You must log in or register to reply here.
Back
Top