GNU/Linux >> Tutoriales Linux >  >> Linux

Ataque de script de Shell en el servidor Apache, a través de un cron de origen desconocido

Después de que OP agregó registros, quedó claro que el problema está en el exploit de ejecución remota de código para Struts 2 (CVE-2017-5638).

Algunos enlaces adicionales:

  1. Nuevo exploit de ejecución remota de código de Struts2 atrapado en la naturaleza.
  2. CVE-2017-5638:Apache Struts2 S2-045.

La solución es actualizar Struts a la versión 2.3.32 o 2.5.10.1.


He enfrentado problemas similares antes cuando era administrador de sistemas. Creo que debe distinguir si es su servidor Tomcat o su aplicación Java.

Cuando inicia Tomcat sin la "aplicación Java infectada", ¿se habilita el cron? (Me refiero a eliminar su aplicación de Tomcat e iniciarla) Si es así, entonces tiene un problema mayor, deberá verificar los scripts de inicio y cada aplicación implementada en el servidor tomcat.

De lo contrario, estamos seguros de que su aplicación es el problema.

Si ese es el caso, vaya a:

$CATALINA_BASE/webapps/your_app 

Verifica la integridad de tu aplicación, ¿hay archivos adicionales que no reconozcas?

Ahora vaya al directorio webapps de su instalación de Tomcat:

$CATALINA_BASE/webapps/

En ese directorio realice:

grep -R '91.230.47.40' *

Para encontrar el posible archivo/línea de código que causa la infección, podría ser un archivo de su aplicación o uno nuevo.

¿Tienes tu código en un sistema CSV?

Cree el archivo war fuera del servidor infectado desde su repositorio CSV y haga lo siguiente:

md5sum your_app.war

Elimine su aplicación del servidor tomcat y vuelva a implementarla, verifique que esté cargando la guerra correcta a través de md5, luego verifique si se está invocando el crontab.

Si proporciona comentarios sobre estos pasos, estaré encantado de ayudarle.


Solo tuvimos que luchar contra este tipo de ataque en un servidor, se reiniciaba sobrescribiendo crontab para nuestro usuario de tomcat como se describe anteriormente. La dirección IP era idéntica. Grep de todo el directorio de aplicaciones web para la dirección IP no reveló un culpable.

En nuestro caso, no usamos struts, pero teníamos las aplicaciones "host-manager" y "manager" en aplicaciones web, y teníamos JMX habilitado/puerto abierto. Reiniciar sin esos parece haberse resuelto, por lo que mi corazonada es que la vulnerabilidad podría estar en uno de esos. Específicamente, se corrigió una vulnerabilidad de JMX en 7.0.73 que podría ser nuestro culpable (https://tomcat.apache.org/security-7.html#Fixed_in_Apache_Tomcat_7.0.73).

Otra precaución que estamos tomando ahora es restringir el acceso a wget y chmod solo a root (solo haz chmod 770 en esos binarios).


Linux
  1. Uso de una secuencia de comandos contenedora de Cron

  2. ¿El significado de $? ¿En un guión de Shell?

  3. Shell script directorio actual?

  4. Servidor Apache/Linux, ataque DoS desde IP propia

  5. ¿Captura de pantalla de la aplicación de terminal a través de un script de shell?

Instale el servidor Apache Tomcat 9 en Ubuntu 20.04

Cómo vincular Apache Tomcat a IPv4 en CentOS/Redhat

Cómo ejecutar comandos de Shell a través del servidor HTTP

Cómo instalar el servidor Apache Tomcat en Ubuntu 22.04

Cómo configurar Nginx como equilibrador de carga para Apache o Tomcat para HTTP/HTTPS

Automatice mysql_secure_installation con el comando echo a través de un script de shell