Se ha cargado el script de malware: la CPU se ha agotado al máximo

Si usa FTP para acceder a los archivos de su sitio web, debe tener mucho cuidado.

Si almacena los nombres de usuario y las contraseñas de su FTP en su computadora local utilizando un software como FileZilla, su sitio web puede verse comprometido si se instala un software malicioso o un troyano en su computadora.

Nunca almacene credenciales en su computadora local.

Además, debe usar SFTP (FTP seguro) o SSH (Shell seguro) que usa cifrado, en lugar de FTP: FTP transfiere credenciales e información en texto sin formato. Esto significa que cualquier persona o programa que esté "escuchando" la transmisión de credenciales al servidor FTP, puede hacerlo con relativa facilidad y luego robar estas credenciales.

Las credenciales, como el nombre de usuario y las contraseñas de FTP, pueden verse comprometidas por troyanos y virus instalados en las computadoras de los usuarios confiados "sniff" las credenciales que se transfieren a través de Internet al servidor web.

SSH (Secure Shell) o SFTP (Secure FTP) evitará el riesgo de credenciales de los ataques "sniffing".

  

Ahora he eliminado la carpeta y todos los archivos que contenía. Yo tambien   mató a todos los procesos.

¿Hiciste copias de los archivos o simplemente los borraste? Porque sin ellos realmente no hay manera de decirte algo definitivo sobre ellos.

No debes asumir que hayas limpiado todo o bloqueado todo el acceso al atacante. Su mejor opción es hacer una copia de seguridad de sus datos y borrar el servidor. Si no está preparado para hacerlo, al menos siga los pasos como los que se enumeran aquí .

  

¿Has visto algo similar?

Google tiene . Simplemente siguiendo esos resultados, el vector de ataque probablemente fue Shellshock . ¿Está parcheado contra esto ?

  

Además de sobrecargar el servidor, ¿puede entender la intención anterior de la información anterior? ¿Qué puede hacer con nuestro servidor?

No, deberíamos ver los contenidos de /home/user/.lesshts/kthread para poder responder a esa pregunta. Si tuviera que adivinar , probablemente estaba escaneando e intentando infectar a otras personas vulnerables a Shellshock, pero eso es solo una suposición descabellada. Una vez más, eliminó el signo obvio de compromiso. ¿Cuántas puertas traseras no obvias dejaron atrás?

Actualizado: Basándose en el binario que cargó (vea los comentarios a continuación), el programa kthread se parece al Tsunami IRC / bot . Aquí hay un buen análisis técnico . Su sistema probablemente estaba bloqueado porque estaba participando en un ataque DDoS .

  

Lo más importante: ¿Tiene alguna idea de cómo puedo evitar que el malware se cargue de nuevo en el servidor?

Una vez más, hay una buena respuesta en que aqui . Mi consejo, sin embargo, es:

• Cree, aplique parches y asegure un sistema de reemplazo
• Migre los datos importantes y necesarios solo del sistema antiguo al nuevo
• Borrar el sistema antiguo

Cuando migre datos, obviamente, no inicie sesión desde el sistema comprometido al sistema limpio; copie desde el sistema comprometido que, en su lugar, tiene credenciales potencialmente comprometidas.

Veo 3 banderas rojas de inmediato:

• el primero es que usas WHM, lo cual es una mala idea (al igual que su pequeño amigo cPanel y sus colegas Plesk, Kloxo, etc.) - No me sorprendería si hay vulnerabilidades extremas en estas pilas de basura que permitiría el acceso de nivel de raíz al servidor sin comprometer las cuentas de usuario.

• el segundo es que usas FTP ... en 2015. Además de ser un protocolo horrible y roto desde el principio, también es completamente inseguro y cualquier atacante que escuche el tráfico de cualquier cliente puede obtener su contraseña. Debería usar SFTP integrado en OpenSSH, para que ya lo tenga.

• finalmente, a pesar de este compromiso, aún estás tratando de arreglar esta pesadilla, aunque lo único correcto es atacar desde la órbita, reinstalar una buena distribución sin ningún tipo de panel web.

Ahora, para obtener una respuesta adecuada a lo que hace este código, después de decirle algo muy bueno y amigable, intenta eliminar cualquier versión que ya se esté ejecutando, se inicia con el nombre "ktnread", con la esperanza de engañar a cualquier administradores sin experiencia en confundirlo con el hilo real y legítimo del núcleo "kthreadd".

En realidad, podría ver cuál es su propio hilo, estoy bastante seguro de que es una historia de horror de Perl robada de años de antigüedad, diseñada para conectarse a un servidor IRC y esperar órdenes de objetivos a DoS para que los niños que operan estos Puede sentirse importante y poderoso, lo más probable es que compense lo que realmente son en la vida real.

Para responder a tu pregunta final, desafortunadamente es imposible evitar completamente que esto suceda, pero al menos puedes limitar el daño:

• bloquee las conexiones salientes de los servidores / contenedores / procesos de PHP y permítales caso por caso si la aplicación realmente lo necesita; puede usar IPtables para eso. Incluso en el caso de un compromiso, evitará que su malware ataque a otros hosts desde su servidor o envíe spam. El script kiddies incluso se rendirá completamente porque su malware (robado) no se puede conectar a su servidor IRC y no son lo suficientemente inteligentes como para modificarlo para tomar pedidos del servidor HTTP que ya se está ejecutando (al monitorear las solicitudes entrantes en el acceso log).

• bloquee los procesos PHP en su propio chroot o contenedor LXC con solo el mínimo que necesitan ejecutar; para Lowlife será mucho más difícil implementar su malware robado basado en Perl si no hay /bin/perl . No es a prueba de balas, ya que solo podrían cargar su propio binario Perl, pero aún así ayudaría un poco y al menos desalentaría a algunos de ellos.

• mantenga las aplicaciones web y sus complementos actualizados, ya que son el principal punto de entrada para los atacantes. A menudo encuentran una vulnerabilidad de carga de archivos que les permite cargar toda su carga útil y, finalmente, un script PHP que contiene exec("./payload") en el que pueden ejecutarse con solo ingresar a su URL.

• ejecuta scripts PHP basados en una lista blanca, en lugar de ejecutar ciegamente cualquier cosa que termine con .php . Incluso si hay vulnerabilidades de carga de archivos, eso no significará un compromiso instantáneo del servidor porque no pueden ejecutar su carga útil porque su ruta no está en la lista blanca (y la mayoría de las vulnerabilidades de carga de archivos no le dan el lujo de) también especificando la ruta de destino, para anular un archivo en la lista blanca).

• evita que el proceso de PHP escriba donde no se supone que debe hacerlo, también bloquea o al menos ralentiza a los atacantes porque la vulnerabilidad de carga del archivo que encontraron solo les permite subir a un directorio no estándar donde el usuario de PHP puede No escribas.

• finalmente, dependiendo de lo que seas (host web, compañía estándar, etc.), deberías preguntarte si puedes confiar en tus usuarios. Si eres una empresa, la respuesta es probablemente sí, solo asegúrate de tener buenas políticas de contraseña (usa las claves siempre que sea posible, por ejemplo, las claves SSH para SFTP) y, finalmente, limita los inicios de sesión solo a la red de tu empresa. Si es un proveedor de alojamiento web, la respuesta es definitivamente no y debe pensar en hacer cumplir la verificación manual para nuevos clientes (la verificación de antecedentes básica de la información que proporcionaron, ya sea si la dirección postal o el teléfono es real o solicitar una identificación) ser un buen elemento disuasorio para las actividades maliciosas.

La conclusión es que nunca puede estar 100% seguro, especialmente en un entorno de alojamiento compartido. Pronto o más tarde, a pesar de todas estas recomendaciones de seguridad, su servidor se verá comprometido con la raíz y tendrá que detenerlo y reinstalarlo, y dependiendo de sus leyes / los datos alojados en ellos, deberá informar. Sus clientes sus datos fueron violados. Si los datos son algo más valioso que los blogs básicos, le sugiero que use máquinas virtuales separadas o servidores de código abierto para ejecutar el código real (PHP, etc.).

Vimos este problema exacto en uno de nuestros servidores hoy.

Verifique los archivos cron en su sistema para ver si han sido manipulados por este malware: en nuestro caso particular, el malware se configuró para ejecutarse a través del cron del usuario apache . Compruebe si se ha agregado algo a alguno de sus archivos cron:

grep 'run.sh' /var/spool/cron/*

Si se encuentran resultados, coméntelos o elimínelos.

Con la entrada cron como se mencionó anteriormente, incluso si eliminamos todos los procesos de malware y el daemon kthread malicioso, se reiniciará solo después de un reinicio o a las 23:59 diariamente.

Al deshabilitar el trabajo cron no autorizado, al menos evitará que el daemon se reinicie de nuevo, pero aún debe intentar y evitar que los usuarios puedan infiltrarse en su sistema con estos archivos. Por ejemplo, intente aislar cada dominio / cuenta para que se ejecute como su propia cuenta de usuario (no apache ).

Si está ejecutando un entorno de alojamiento compartido, podría considerar usar algo como CloudLinux o BetterLinux para proporcionar aislamiento y una mejor seguridad.