Nachdem OP Protokolle hinzugefügt hatte, wurde klar, dass das Problem im Remote Code Execution Exploit für Struts 2 (CVE-2017-5638) liegt.
Einige zusätzliche Links:
- Neuer Struts2-Remote-Code-Execution-Exploit in freier Wildbahn entdeckt.
- CVE-2017-5638 – Apache Struts2 S2-045.
Die Lösung besteht darin, Struts auf Version 2.3.32 oder 2.5.10.1 zu aktualisieren.
Ich hatte ähnliche Probleme, als ich Systemadministrator war. Ich denke, Sie müssen unterscheiden, ob es sich um Ihren Tomcat-Server oder Ihre Java-App handelt.
Wenn Sie Tomcat ohne die "infizierte Java-App" starten, wird der Cron aktiviert? (Ich meine, Ihre Anwendung aus Tomcat löschen und starten) Wenn dies der Fall ist, haben Sie ein größeres Problem. Sie müssen die Startskripts und alle auf dem Tomcat-Server bereitgestellten Anwendungen überprüfen.
Andernfalls sind wir sicher, dass Ihre App das Problem ist.
Wenn dies der Fall ist, gehen Sie zu:
$CATALINA_BASE/webapps/your_app
Überprüfen Sie die Integrität Ihrer Anwendung. Gibt es zusätzliche Dateien, die Sie nicht erkennen?
Wechseln Sie nun in das webapps-Verzeichnis Ihrer Tomcat-Installation:
$CATALINA_BASE/webapps/
Führen Sie in diesem Verzeichnis Folgendes aus:
grep -R '91.230.47.40' *
Um die mögliche Datei/Codezeile zu finden, die die Infektion verursacht, könnte es sich um eine Datei Ihrer App oder um eine neue handeln.
Haben Sie Ihren Code in einem CSV-System?
Erstellen Sie die Kriegsdatei außerhalb des infizierten Servers aus Ihrem CSV-Repo und tun Sie Folgendes:
md5sum your_app.war
Entfernen Sie Ihre Anwendung vom Tomcat-Server und stellen Sie sie erneut bereit, vergewissern Sie sich, dass Sie den richtigen Krieg über md5 hochladen, und prüfen Sie dann, ob crontab aufgerufen wird.
Wenn Sie Feedback zu diesen Schritten geben, helfe ich Ihnen gerne weiter.
Wir mussten diese Art von Angriff auf einem Server einfach abwehren, er startete immer wieder neu und überschrieb crontab für unseren Tomcat-Benutzer, wie oben beschrieben. Die IP-Adresse war identisch. Grep des gesamten Webapps-Verzeichnisses für die IP-Adresse ergab keinen Schuldigen.
In unserem Fall verwenden wir keine Struts, aber wir hatten die Apps „host-manager“ und „manager“ in Webapps und wir hatten JMX aktiviert/Port geöffnet. Ein Neustart ohne diese scheint gelöst zu sein, also ist meine Vermutung, dass die Schwachstelle in einer davon liegen könnte. Insbesondere wurde in 7.0.73 eine JMX-Schwachstelle behoben, die unser Schuldiger sein könnte (https://tomcat.apache.org/security-7.html#Fixed_in_Apache_Tomcat_7.0.73).
Eine weitere Vorsichtsmaßnahme, die wir jetzt ergreifen, besteht darin, den Zugriff auf wget und chmod nur auf root zu beschränken (führen Sie einfach chmod 770 für diese Binärdateien aus).