Dopo che OP ha aggiunto i log, è diventato chiaro che il problema è nell'exploit Remote Code Execution per Struts 2 (CVE-2017-5638).
Alcuni collegamenti aggiuntivi:
- Nuovo exploit Struts2 Remote Code Execution catturato allo stato brado.
- CVE-2017-5638 - Apache Struts2 S2-045.
La soluzione è aggiornare Struts alla versione 2.3.32 o 2.5.10.1.
Ho già affrontato problemi simili quando ero amministratore di sistema. Penso che tu debba distinguere se è il tuo server Tomcat o la tua app Java.
Quando avvii Tomcat senza l '"app Java infetta", il cron viene abilitato? (intendo, eliminare la tua applicazione da Tomcat e avviarla) In tal caso, hai un problema più grande, dovrai verificare gli script di avvio e ogni applicazione distribuita nel server Tomcat.
Altrimenti siamo sicuri che il problema sia la tua app.
In tal caso, vai a:
$CATALINA_BASE/webapps/your_app
Verifica l'integrità della tua applicazione, ci sono altri file che non riconosci?
Ora vai alla directory webapps della tua installazione di Tomcat:
$CATALINA_BASE/webapps/
In quella directory eseguire:
grep -R '91.230.47.40' *
Per trovare il possibile file/riga di codice che causa l'infezione, potrebbe essere un file della tua app o uno nuovo.
Hai il tuo codice in un sistema CSV?
Crea il file war fuori dal server infetto dal tuo repository CSV ed esegui:
md5sum your_app.war
Rimuovi la tua applicazione dal server Tomcat e ridistribuiscila, verifica di caricare il war corretto tramite md5, quindi controlla se il crontab viene richiamato.
Se fornisci un feedback su questa procedura, sarò lieto di aiutarti.
Dovevamo solo combattere questo tipo di attacco su un server, continuava a riavviarsi sovrascrivendo crontab per il nostro utente Tomcat come descritto sopra. L'indirizzo IP era identico. Il grep dell'intera directory webapps per l'indirizzo IP non ha rivelato un colpevole.
Nel nostro caso non usiamo i montanti, ma avevamo le app "host-manager" e "manager" nelle webapp e avevamo JMX abilitato/porta aperta. Il riavvio senza quelli sembra aver risolto, quindi la mia impressione è che la vulnerabilità potrebbe essere in uno di quelli. In particolare, nella versione 7.0.73 è stata risolta una vulnerabilità JMX che potrebbe essere la nostra colpevole (https://tomcat.apache.org/security-7.html#Fixed_in_Apache_Tomcat_7.0.73).
Un'altra precauzione che stiamo prendendo è limitare l'accesso a wget e chmod solo a root (basta eseguire chmod 770 su quei binari).