Malware en servidor linux

Hola al foro después de... no sé, muchísimos años: no sé si quedará alguien de mi quinta por aquí. En fin, a lo que voy: a ver si alguno que esté puesto me puede arrojar un poco de luz en este caso, porque yo no me lo explicó (y, desgraciadamente, tampoco tengo mucho sobre lo que estudiar).

Sigo medio administrando en la distancia (porque ya no trabajo allí) un pequeño servidor que monté en debian (wheezy) con bastantes servicios: hora, dhcp, dns, http (nginx que ejecuta php), ssh, vpn, ftp (vsftpd), pxe, y correo (smtp+imap). De todo ellos, son accesibles desde internet http, ftp, smtp, imap, ftp y dns (se gestiona un subdominio gratuito de .tk).

Pues bien, me ha pasado lo siguiente: de vez en cuando me paso por el servidor a actualizarlo (las actualizaciones de seguridad de la debian estable) y comprobar como sigue funcionando, porque mis compañeros tienen menos conocimientos que yo y, además, no fueron quienes montaron el bicho. Pues bien, hace semana y media, me metí en auth.log para curiosear los accesos y vi que un usuario "javier" (correspondiente a una persona física, no a un servicio) ejecutaba una tarea de cron cada minuto. Como me pareció raro, miré su cron y vi que el 22 de octubre se había editado el crontab de este usuario para incluir una línea que ejecutaba un programa llamado

/tmp/.UNIX/update

y, claro, me saltaron todas las alarmas. Desgraciadamente, el ejecutable se había borrado el 11 de noviembre, porque ese día apagaron el servidor para quitar un disco que no era necesario; así que no tengo más que el nombre. Miré en internet y vi alguna infección con ese nombre o con el mismo modus operandi, pero en que la infección se había producido a través del usuario www-data, lo cual tiene sentido si se usa php con algún agujero de seguridad.

Lo que no me explico de todo esto es que:

* La infección se produjo a través de un usuario real (quiero decir, de una persona real), no de www-data, que sería lo esperable.
* El usuario real sólo usa el servidor para subir material por ftp y ver contenido por http.
* He comprobado que, aunque puede conectarse por ssh, jamás lo ha hecho: su perfil está como cuando se copia de /etc/skel y no hay rastro de .bash_history.

¿Alguien se explica cómo se puede producir en estas circunstancias una infección? ¿Usando un cliente de ftp se puede llegar a estos extremos? Entiendo que con el protocolo ftp se suben y se bajan ficheros y nada más (salvo bug/backdoor de vsftpd, pero no me ha parecido leer que tuviese ninguno en este final de 2013).

Notas:

1. Hablar con el usuario es como hablar con una mesa camilla así que no se le puede sacar más y, además, no lo puedo hacer yo directamente.
2. He pasado rkhunter al servidor y no parece que el malware fuera capaz de instalar ningún rootkit ni similar.
Yo si te recuerdo de algo XD.

El tema...
https://community.rackspace.com/general/f/34/t/75
Aqui (que supongo que habras mirado) se muestran muchas opciones para revisar logs y cambios en el sistema que puedan ayudarte a diagnosticar todo.


Pueden acceder al sistema de mil maneras, si como comentas tienes un dominio con mil servicios accesibles desde el exterior entre los que se encuentra el acceso remoto... puede haber mil opciones. Pero ese usuario si accede al sistema, también tiene mil opciones, un ftp permite subir archivos, archivos que podrían tal vez visualizarse o incluso ejecutarse (no especificas si el ftp es de su /home cerrada o por ej permite también a la parte de acceso web para visualizar lo que sube).

Ademas, debes tener en cuenta que si una amenaza prospera mucho tiempo y no se tienen ciertas medidas de seguridad para evitar ataques de fuerza bruta te acabaran colando algo tarde o temprano.

Otras vulnerabilidades típicas pueden ser de java, pdf o flash... aunque si es un server no creo que ejecuten pdf o flash... pero al ser un server PXE, si este sirve clientes todo es posible pues al fin y al cabo significa que todos esos usuarios están trabajando en el servidor.

Recordemos por ultimo que cualquier tecnología web puede tener algún bug explotable que te permita acceder al sistema pero cualquier puerta cerrada puede provocar que aunque algo llegue a entrar solo realice algunas tareas limitadas sin llegar a su objetivo final.
blackgem escribió:Yo si te recuerdo de algo XD.


Jo, pues yo no... [mamaaaaa] pero es que eso fue hace muchos años. Creo que dejé de ser usuario activo allá por el 2005. En fin...

blackgem escribió:El tema...
https://community.rackspace.com/general/f/34/t/75
Aqui (que supongo que habras mirado) se muestran muchas opciones para revisar logs y cambios en el sistema que puedan ayudarte a diagnosticar todo.


He intentado revisar sí, pero no soy muy ducho en seguridad. Le echaré un vistazo a ver si sugieren algo que yo no haya hecho. En cualquier caso, el problema es que del 22 de octubre, ya no se guardan prácticamente logs de nada. Date cuenta de que esto pasó el 22 de octubre (al menos esa era la fecha de última modificación del archivo de crontab del usuario en cuestión) y yo vine a curiosear prácticamente dos meses después. auth.log, por ejemplo, que es al primero que uno echa mano no guardaba información de tanto tiempo. Tampoco hay registros ya del acceso a vsftpd. En realidad, saber qué pasó es ya imposible con la información que hay disponible: el problema es que no me explico ningún medio para el ataque, suponiendo que se realizase a través de ftp (que es lo único que veo posible).

blackgem escribió:Pueden acceder al sistema de mil maneras, si como comentas tienes un dominio con mil servicios accesibles desde el exterior entre los que se encuentra el acceso remoto... puede haber mil opciones. Pero ese usuario si accede al sistema, también tiene mil opciones, un ftp permite subir archivos, archivos que podrían tal vez visualizarse o incluso ejecutarse (no especificas si el ftp es de su /home cerrada o por ej permite también a la parte de acceso web para visualizar lo que sube).


Sí, hay varios modos de acceder: ssh, correo (smtp e imap), http, dns y ftp. http, smtp, imap y dns no ejecutan (o eso creo) ningún proceso a nombre del usuario que accede a ellos. Por ejemplo, si el contagio hubiera procedido de http, el descosido lo hubiera hecho www-data (hay bastante php funcionando:mediawiki, joomla, moodle, wordpress y unos cuantos scripts propios). Además, este usuario no usa el correo. Quedan ssh y ftp a mi juicio. ssh no lo ha usado: él lo ha dicho y, además, me metí en su perfil y comprobé que efectivamente no quedaba rastro de que hubiera accedido alguna vez.

En cuanto al ftp (sftp creo que tampoco lo usa), tiene todas las papeletas, porque este sí lo usa. El usuario NO esta enjaulado: hay un tipo de usuarios (alumnos) que sí, pero otros (los profesores), no.

Y ahora que me lo dices sí que se me ocurre un medio posible de que haya llegado ese fichero ahí sin necesidad de ejecutar nada: que fuera subido por ftp: no hay que ejecutar nada, sólo subirlo al lugar adecuado. Sin embargo, si reviso el directorio /var/spool/cron/crontab (en otra máquina linux, porque ahora mismo no tengo acceso al servidor de marras) veo que tiene permisos:

drwx-wx--T root crontab

O sea que no, si en el servidor los permisos son los mismos (cosa que imagino) el usuario no tiene permisos para crear nada en ese directorio y, por tanto, no podrá haber subido el fichero a ese sitio.

De hecho cada usuario puede editar su crontab porque crontab tiene habilitado el bit setuid:

$ ls -l `which crontab`
-rwxr-sr-x 1 root crontab 35880 jul  3  2012 /usr/bin/crontab


blackgem escribió:Ademas, debes tener en cuenta que si una amenaza prospera mucho tiempo y no se tienen ciertas medidas de seguridad para evitar ataques de fuerza bruta te acabaran colando algo tarde o temprano.


Quizás esta no prosperase, porque rkhunter no me ha cantado nada.

blackgem escribió:Otras vulnerabilidades típicas pueden ser de java, pdf o flash... aunque si es un server no creo que ejecuten pdf o flash...


No hay instalado entorno gráfico.

blackgem escribió:pero al ser un server PXE, si este sirve clientes todo es posible pues al fin y al cabo significa que todos esos usuarios están trabajando en el servidor.


No es un servidor de terminales tontas, es simplemente un servidor pxe: sirve sistemas operativos en red que se ejecutan en el cliente: por ejemplo, gparted o clonezilla (pero una versión que modifiqué, porque el clonezilla server está pensado para que sólo se ejecute él).

En fin, no tengo ni idea. Creo que la única puerta de entrada posible es FTP, pero no me explico cómo puede llegar a escvribirse la tarea en el crontab del usuario.
ese usuario es accesible por ssh? es posible que hubiesen conectado a fuerza bruta.

El .bash_history olvidate de el, la mayoría se lo cepilla cuando infectan la máquina ...

A mi me da la sensación que se han colado en el user, sftp/scp para subir el backdoor y lo han metido en el crontab como han podido. Tampoco ha sido tan grave, podrían entrar como root y hacerte una bastante mas gorda y ahora no lo sabrías [+furioso]

Revisa auth.log aun que me comentas que ya no tiene la info mira a ver si tienes muchas peticiones ssh

Me preocuparía el tema de que el usuario tenga un virus parecido a los keyloggers que te pillan poniendo la cuenta de twitter y lo usan para spam

Si tienes un servidor de mail, como comentas, no sé hasta que punto se pueden revisar los correos salientes, por si han enviado spam desde la máquina.

Dices usar wheezy, lo cual me imagino que está actualizada, revisa que las versión de ssh server, nginx y demás estén libres de exploits

No se me ocurre nada mas :(
KiAn escribió:ese usuario es accesible por ssh? es posible que hubiesen conectado a fuerza bruta.


Sí.

KiAn escribió:El .bash_history olvidate de el, la mayoría se lo cepilla cuando infectan la máquina ...


Por curiosidad, ¿cómo se puede cepillar y que después no aparezca? Yo puedo cepillarme el .bash_history, pero cuando cierre la sesión y la vuelva a abrir me encontraré con un .bash_history que contiene el comando ce borrado...

¡Ah! Ya lo he visto:

unset HISTFILE


De todos modos hay una forma de saber si pasó eso, supongo: mirar la fecha de modificación de $HOME. Sin embargo, como nunca antes había entrado no se había creado .bash_history, así que nunca tuvo que borrarse,,,

Bueno, es una posibilidad esta. Lo raro es que hace cosa de tres años pasó exactamente lo mismo con este usuario en un antiguo servidor (en este lapso de tres años no ha estado). Y me escama que le averigëen dos veces la contraseña. Y si el ataque es externo, también hay que averiguar el nombre de usuario. Es demasiado.

KiAn escribió:A mi me da la sensación que se han colado en el user, sftp/scp para subir el backdoor y lo han metido en el crontab como han podido. Tampoco ha sido tan grave, podrían entrar como root y hacerte una bastante mas gorda y ahora no lo sabrías


La única forma de escribirlo en el crontab es ejecutar crontab (o ser root, claro)

KiAn escribió:Revisa auth.log aun que me comentas que ya no tiene la info mira a ver si tienes muchas peticiones ssh


Siempre. Casi todos los días hay algún pesando que intenta acceder al servidor por ssh (hay demasiados aburridos por el mundo): el acceso siempre consiste en usar cuentas más o menos conocidad (principalmente root) he intentar varias veces averiguar la contraseña correcta.

KiAn escribió:Me preocuparía el tema de que el usuario tenga un virus parecido a los keyloggers que te pillan poniendo la cuenta de twitter y lo usan para spam

Si tienes un servidor de mail, como comentas, no sé hasta que punto se pueden revisar los correos salientes, por si han enviado spam desde la máquina.


Sí se puede revisar eso, y no he caído. Lo miraré.

KiAn escribió:Dices usar wheezy, lo cual me imagino que está actualizada, revisa que las versión de ssh server, nginx y demás estén libres de exploits


Sí, está todo actualizado. De vez en cuando me suelo meter en el servidor a instalar las actualizaciones de seguridad: no creo que se els cuele un paquete con exploits a los de debian en esas actualizaciones.

KiAn escribió:No se me ocurre nada mas :(


Bueno, muchas gracias. Ha sido bastante lo que has dicho.
Hace un mes o así me encontré con el mismo script y fui incapaz de averiguar de donde salió.

Aparentemente no hacia nada (Solo escribia una linea en el syslog cada minuto) por lo que lo borre y no me ha vuelto a salir.
5 respuestas