Spamversand über OXIDs phpmailer

#1

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 [email protected].
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:

[email protected]…:/var/customers/webs/…/shop/vendor/phpmailer/phpmailer# mailq
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
38E454252C* 45706 Mon Feb 18 18:02:09 [email protected]…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 [email protected]…de
[email protected]

A967542560* 45696 Mon Feb 18 18:07:32 [email protected]…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

#2

Shopversion? Alle Sicherheitslücken geschlossen?
Vorab: Lade den Shop komplett runter und vergleiche alle Dateien mit dem Original-Shop-Download der aktuellen Version mit Tools wie “Beyond Compare etc.”
So wirst schnell fündig, ob eine Datei verändert oder hinzugefügt wurde. Das gleiche gilt für die Datenbank.

#3

Handelt sich um die aktuellste CE, Version 6.1.2, aktualisiert mittels Composer. System ist auf dem aktuellsten Stand, alle Patches eingespielt und alle potentiellen Lücken überprüft - nichts gefunden.

Den Vergleich starte ich gleich mal parallel.

#4

Ho!

Was steht denn in der Mail?

Hast du irgendein Honeypot oder Catcha installiert?

Kannst du die Access-Logs prüfen welche IP zu der Zeit so rumspamt und welche Seiten / Controller / Endpunkte ggf. aufgerufen wurden?

Gibt es Fehlermeldungen in der PHP Error Log Datei, nach dem Umbenennen der Datei?

LG

#5

Einladungen sind deaktiviert? (Stammdaten, Grundeinstellungen, Einstellungen, Einladungen)

#6

Einladungen sind und waren deaktiviert.

#7

Die E-Mail sieht für mich 100%ig nach der Tell-a-friend-Funktion aus. Nochmal, um ganz sicher zu gehen: Stammdaten -> Grundeinstellungen -> Einstellungen -> Artikel. Ist der Punkt “Empfehlen von Artikeln erlauben” aktiviert?

1 Like
#8

Ah stimmt genau das war eigentlich das was ich meinte Marco.

1 Like
#9

Dies habe ich nun deaktiviert. Erschliesst sich zwar immer noch nicht, wieso daraus so ein extremer Bounce an Mails entstand, aber warten wir es nun mal ab.

#10

Wasserstandsmeldung: Ich kann es noch immer nicht nachvollziehen, was das nun genau los war. Grundsätzlich kann ich soviel sagen: Ich weiss nicht, was los war :wink:

Zwischenzeitlich ist Ruhe eingekehrt… vielleicht ist es nicht verkehrt den Thread offen zu lassen - ich werde neue Erkenntnisse nachliefern, so bald ich wieder etwas Zeit habe mich dem Thema intensiver zu widmen.

Dankeschön auf alle Fälle für alle Hinweise!

Grüße,
Ralf

1 Like