Hallo zusammen,
keine Ahnung, wie ich das nun zusammenfassen soll, was ich seit dem 18. Februar auf dem System meines Kollegen erlebe, aber versuchen wir es mal.
Heute (18.02.2019) schreibt mich mein Kollege an, dass sein Email-Postfach durchdreht, im Sekundentakt kommen Email-Nachrichten rein, ich solle mir das bitte mal ansehen. Stellte dann fest, dass von seinem Server unzählige Nachrichten versendet werden, adressiert an chinesische Empfänger und die Gegenstellen entsprechend kontern. Bei der ursprünglichen Nachricht handelte es sich um eine Produktempfehlung, die initial aus seinem Shop gesendet wurde.
Nun gut, habe ich also mal die Server-Konfiguration und die Mail-Logs unter die Lupe genommen, wo ich schon im Sekundentakt die Zugriffe sah. Um dem Ganzen in einem ersten Workaround entgegen zu wirken installierte ich fail2ban, setzte den Ban von 10 Minuten auf permanent, modifizierte die Konfiguration so, dass auch nach einem Neustart von fail2ban die bereits persistent geblockten IPs wieder gebannt werden. Fazit: Nichts ändert sich.
Irgendwann habe ich dann den Shop in den Maintenance-Modus umgestellt - vermeintlich war erst mal Ruhe. Okay, das ist natürlich keine Dauerlösung, somit nach einer Stunde den Shop wieder in Betrieb genommen - das Spiel begann von vorne.
Also im OXID-Forum nach ‘Deaktivieren der Artikel empfehlen-Funktion’ gesucht, keine schnelle Lösung auf Anhieb gefunden und im Grundsatz ging es mir auch eher darum heraus zu finden, wie der Angriff denn gerade abläuft.
Der Server dann ergebnislos nach Rootkits und Malware durchsucht, die Postfix-Konfiguration geprüft, keine Auffälligkeiten festgestellt… viel Rumgestochere im Nebel.
Nun habe ich dann vor einer Stunde - auf solche Ideen kommt man immer erst zuletzt (oder vielleicht auch nur ich) - mal eine der Emails genauer unter die Lupe genommen.
Im Header fand ich das:
Received by ..de (Postfix, from userid 33) id 1499042488; Mon, 18 Feb 2019 17:31:46 +0100 (CET) To FriendName [email protected] Subject 111 X-PHP-Originating-Script 1000:class.phpmailer.php Date Mon, 18 Feb 2019 17:31:46 +0100 From info@. Reply-To MyName [email protected]
Kurzer Check bez. der userid 33:
…
www-data:33
…
Prüfen der userid 1000 (-> X-PHP-Originating-Script |1000:class.phpmailer.php):
…
:1000
Hmm, okay, der Webserver schickt also mittels class.phpmailer.php konsequent weiter Emails raus.
Bei der Überprüfung von class.phpmailer.php ergab sich als Besitzer/Gruppe mein Kollege und die Berechtigungen sind auf ‘644’ gesetzt - was ja an sich in Ordnung ist, da sich aus dem Header aber ergab, dass der Benutzer 1000 die class.phpmailer.php missbraucht scheint hier der Wurm begraben zu sein.
Temporär mal den Dateinamen in _class.phpmailer.php geändert - nun war wieder Ruhe. Prüfen der Queue:
Mail queue is empty
Okay, ändern wir die Bezeichnung der PHP-Datei wieder auf den Ursprung zurück. Und schon geht der “Spaß” von vorne los:
root@…:/var/customers/webs/…/shop/vendor/phpmailer/phpmailer# mailq
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
38E454252C* 45706 Mon Feb 18 18:02:09 info@…de
[email protected]– 44 Kbytes in 1 Request.
Vorläufige Schlussfolgerung: Benutzerkonto des Kollegen ist kompromittiert, ändern wir erst einmal das zugehörige Passwort. Vermeintlich sollte nun Ruhe einkehren… aber die Queue sagt etwas anderes:
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
5034842563* 45694 Mon Feb 18 18:07:44 info@…de
[email protected]A967542560* 45696 Mon Feb 18 18:07:32 info@…de
[email protected]– 89 Kbytes in 2 Requests.
Nun gut - ändern wir also noch einmal den Dateinamen des PHP-Skripts und kontrollieren nach:
Mail queue is empty
Das ist jedoch keine zielführende Lösung, eher ein dirty Workaround. Also sehen wir noch mal in den Logs nach, um den Status quo zu ermitteln.
Feb 18 18:31:59 … postfix/smtpd[20505]: connect from unknown[94.102.56.215]
Feb 18 18:32:01 … postfix/smtpd[20505]: warning: unknown[94.102.56.215]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
Feb 18 18:32:01 … postfix/smtpd[20505]: disconnect from unknown[94.102.56.215]
Feb 18 18:32:52 … postfix/smtpd[20505]: connect from unknown[185.234.217.187]
Feb 18 18:32:54 … postfix/smtpd[20505]: warning: unknown[185.234.217.187]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
Feb 18 18:32:54 … postfix/smtpd[20505]: lost connection after AUTH from unknown[185.234.217.187]
Feb 18 18:32:54 … postfix/smtpd[20505]: disconnect from unknown[185.234.217.187]
Feb 18 18:36:14 … postfix/anvil[20507]: statistics: max connection rate 1/60s for (smtp:79.142.126.225) at Feb 18 18:31:21
Feb 18 18:36:14 … postfix/anvil[20507]: statistics: max connection count 1 for (smtp:79.142.126.225) at Feb 18 18:31:21
Feb 18 18:36:14 … postfix/anvil[20507]: statistics: max cache size 3 at Feb 18 18:31:59
Ergebnis nach einer Woche: class.phpmailer.php blieb umbenannt für einige Zeit, fail2ban war fleissig und fügte ca. 2000 IP-Adressen der persistenten Bannliste hinzu. Vorgestern bekam das class.phpmailer.php-Skript seine Originalbezeichnung zurück, einen Tag lang blieb es ruhig, seit heute morgen rasselte es wieder.
Ich bin mit meinem Latein am Ende, da ich mich intensiv mit der Absicherung des Servers von Anfang an beschäftigt hatte und nun nur kleine Ergänzungen zur Betriebssicherheit vornahm. Da ich aber bis dato keine ähnlich gelagerten Fälle im Forum entdeckte kann ich auch nicht von einem Bug ausgehen…
Für jegliche Tipps, Hinweise oder sonstigen Denkanstöße bin ich sehr dankbar.
Beste Grüße,
Ralf
