SSH extraño, seguridad del servidor, podría haber sido pirateado

30

No estoy seguro de si he sido pirateado o no.

Traté de iniciar sesión a través de SSH y no aceptó mi contraseña. El inicio de sesión raíz está deshabilitado, así que fui a rescatar y activé el inicio de sesión raíz y pude iniciar sesión como root. Como root, intenté cambiar la contraseña de la cuenta afectada con la misma contraseña con la que había intentado iniciar sesión antes, passwdrespondí con "contraseña sin cambios". Luego cambié la contraseña a otra y pude iniciar sesión, luego cambié la contraseña a la contraseña original y pude volver a iniciar sesión.

Revisé los auth.logcambios de contraseña pero no encontré nada útil.

También escaneé en busca de virus y rootkits y el servidor devolvió esto:

ClamAV:

"/bin/busybox Unix.Trojan.Mirai-5607459-1 FOUND"

RKHunter:

"/usr/bin/lwp-request Warning: The command '/usr/bin/lwp-request' has been replaced by a script: /usr/bin/lwp-request: a /usr/bin/perl -w script, ASCII text executable

Warning: Suspicious file types found in /dev:"

Cabe señalar que mi servidor no es ampliamente conocido. También cambié el puerto SSH y habilité la verificación en dos pasos.

Me preocupa que me hayan pirateado y alguien esté tratando de engañarme, "todo está bien, no te preocupes por eso".

PhysiOS
fuente
10
De acuerdo con Michael. Parece que Mirai usa la adivinación de contraseña de fuerza bruta para comprometer los hosts de Linux: incapsula.com/blog/malware-analysis-mirai-ddos-botnet.html . Usar la autenticación de clave pública sería mejor que cambiar el puerto SSH por motivos de seguridad en mi humilde opinión.
Josh Morel
3
@JoshMorel Iría más lejos y diría que cambiar el puerto SSH es perjudicial para la seguridad. No ayuda a proteger nada, pero las personas que lo hacen erróneamente se sienten más seguras. Entonces, al sentirse más seguros sin estar realmente más seguros, están peor que antes. Además, diría que la autenticación de pubkey no es simplemente mejor, sino imprescindible.
marcelm
10
"... no aceptaba mi contraseña ... respondía" contraseña sin cambios "... después de cambiar la contraseña a otra cosa que pude iniciar sesión, cambié la contraseña a lo que era y todavía podía iniciar sesión." - Todo eso podría explicarse haciendo errores tipográficos en su contraseña (o bloqueando las mayúsculas) antes de dirigirse al usuario de rescate.
marcelm
2
La detección de troyanos busybox por clamav también me ocurrió a mí esta mañana por primera vez en ~ 100 sistemas; Estoy votando falso positivo. Supongo que clamav actualizó su base de datos de sig para que este falso positivo comience a aparecer de la noche a la mañana por la noche
JDS
2
Por cierto, el hashsum sha256 de mi busybox en estos sistemas es 7fa3a176871de12832ca8a78b646bc6be92f7f528ee81d1c35bf12aa99292b1c. Estos son sistemas ubuntu 14.04, y el mtime en el busybox bin es 2013-11-14
JDS

Respuestas:

30

Al igual que J Rock, creo que esto es un falso positivo. Tuve la misma experiencia.

Recibí una alarma de 6 servidores diferentes, dispares, separados geográficamente en un corto período de tiempo. 4 de estos servidores solo existían en una red privada. Lo único que tenían en común era una actualización reciente de daily.cld.

Entonces, después de verificar algunas de las heurísticas típicas de este troyano sin éxito, encendí una caja vagabunda con mi línea base limpia conocida y ejecuté freshclam. Esto agarró

"daily.cld está actualizado (versión: 22950, ​​sigs: 1465879, nivel f: 63, generador: neo)"

Un posterior clamav /bin/busyboxdevolvió la misma alerta "/ bin / busybox Unix.Trojan.Mirai-5607459-1 FOUND" en los servidores originales.

Por último, por si acaso, también hice una caja de vagabundo oficial de Ubuntu cuadro y también tengo el mismo "/ bin / busybox Unix.Trojan.Mirai-5607459-1 hallado" (Nota, que tuvo que la memoria en este cuadro de vagabundo desde su defecto 512MB o clamscan falló con 'matado')

Salida completa de la nueva caja vagabunda Ubuntu 14.04.5.

root@vagrant-ubuntu-trusty-64:~# freshclam
ClamAV update process started at Fri Jan 27 03:28:30 2017
main.cvd is up to date (version: 57, sigs: 4218790, f-level: 60, builder: amishhammer)
daily.cvd is up to date (version: 22950, sigs: 1465879, f-level: 63, builder: neo)
bytecode.cvd is up to date (version: 290, sigs: 55, f-level: 63, builder: neo)
root@vagrant-ubuntu-trusty-64:~# clamscan /bin/busybox
/bin/busybox: Unix.Trojan.Mirai-5607459-1 FOUND

----------- SCAN SUMMARY -----------
Known viruses: 5679215
Engine version: 0.99.2
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 1.84 MB
Data read: 1.83 MB (ratio 1.01:1)
Time: 7.556 sec (0 m 7 s)
root@vagrant-ubuntu-trusty-64:~#

Entonces, también creo que es probable que esto sea un falso positivo.

Diré que rkhunter no me dio la referencia: "/ usr / bin / lwp-request Advertencia", por lo que quizás PhysiOS Quantum tenga más de un problema.

EDITAR: acabo de notar que nunca dije explícitamente que todos estos servidores son Ubuntu 14.04. Otras versiones pueden variar?

cayleaf
fuente
1
Voy a cambiar mi autenticación SSH por una clave pública e intentaré monitorear las conexiones de red, pero honestamente es realmente extraño porque incluso copié y pegué la contraseña y aún así la rechazó. ¿Qué debo hacer con / usr / bin / lwp-request?
PhysiOS
1
También recibí esta notificación esta mañana en un servidor Ubuntu 14.04. Comparé ( sha1sum) el /bin/busyboxarchivo de mi servidor con el mismo archivo en una VM local creada a partir de una imagen de Ubuntu y son idénticos. Así que también voto falso positivo.
Agregoire
3
@PhysiOSQuantum Nada. Eso también es un falso positivo: lwp-request es una herramienta relacionada con un módulo Perl ( metacpan.org/pod/LWP ), por lo que es perfectamente normal que sea un script.
duskwuff
45

La firma ClamAV para Unix.Trojan.Mirai-5607459-1 es definitivamente demasiado amplia, por lo que es probable que sea un falso positivo, como lo señalan J Rock y cayleaf.

Por ejemplo, cualquier archivo que tenga todas las siguientes propiedades coincidirá con la firma:

  • es un archivo ELF;
  • contiene la cadena "watchdog" exactamente dos veces;
  • contiene la cadena "/ proc / self" al menos una vez;
  • contiene la cadena "busybox" al menos una vez.

(Toda la firma es un poco más complicada, pero las condiciones anteriores son suficientes para una coincidencia).

Por ejemplo, puede crear dicho archivo con:

$ echo 'main() {printf("watchdog watchdog /proc/self busybox");}' > innocent.c
$ gcc -o innocent innocent.c
$ clamscan --no-summary innocent
innocent: Unix.Trojan.Mirai-5607459-1 FOUND

Cualquier construcción busybox (en Linux) generalmente coincidirá con las cuatro propiedades que enumeré anteriormente. Obviamente es un archivo ELF y definitivamente contendrá la cadena "busybox" muchas veces. Se ejecuta "/ proc / self / exe" para ejecutar determinados applets. Finalmente, "watchdog" aparece dos veces: una como nombre de applet y otra dentro de la cadena "/var/run/watchdog.pid".

tipo nómada
fuente
20
¿Dónde puedo leer esa firma y otras de ClamAV por curiosidad?
Délisson Junio
2
Sabía que alguien más inteligente que yo podría explicar por qué era un falso positivo. ¡Gracias!
cayleaf
3
@ Délisson Junio: cree un directorio vacío, cd en él y ejecútelo sigtool --unpack-current dailypara descomprimir daily.cvd (o sigtool --unpack-current maindescomprimir main.cvd). Si selecciona los archivos resultantes para "Unix.Trojan.Mirai-5607459-1", debe encontrar la firma, que está en daily.ldb. El formato de la firma se explica en signatures.pdf (viene con el paquete clamav-docs en Ubuntu).
nomadictype
6

Esto también apareció hoy para mí también en mi búsqueda de ClamAV para / bin / busybox. Me pregunto si la base de datos actualizada tiene un error.

J rock
fuente
2
Escanee / bin / busybox en cualquier Ubuntu 14.04 LTS con la última base de datos ClamAV. Vuelve infectado. Este es un falso positivo, OMI.
J Rock
2
Envié un informe falso positivo a ClamAV. También descubrí que los binarios del reproductor vmware aparecen infectados con el mismo troyano. Es probable que hayan incluido el código de busybox.
J Rock
4

Traté de iniciar sesión a través de SSH y no aceptó mi contraseña. El inicio de sesión raíz está deshabilitado, así que fui a rescatar y activé el inicio de sesión raíz y pude iniciar sesión como root. Como root, intenté cambiar la contraseña de la cuenta afectada con la misma contraseña con la que había intentado iniciar sesión antes, passwd respondió con "contraseña sin cambios". Luego cambié la contraseña a otra y pude iniciar sesión, luego cambié la contraseña a la contraseña original y pude volver a iniciar sesión.

Esto suena como una contraseña caducada. Establecer la contraseña (con éxito) por root restablece el reloj de caducidad de la contraseña. Usted podría comprobar / var / log / secure (o lo que es el equivalente de Ubuntu) y averiguar qué se rechazó su contraseña.

Xalorous
fuente