Malware en Linux

news and informations automotive,business,crime,health,life,politics,science,technology,travelautomotive,business,crime,health,life,politics,science,technology,travel

Por algún motivo, muchos administradores de sistemas siguen teniendo la percepción de que Linux es un sistema operativo que no se ve afectado por el malware, o que es muy difícil que vea infectado por troyanos, virus, …

Si tenemos en cuenta que más de dos tercios de los servidores web que actualmente ofrecen contenido en Internet son variantes de Linux, Unix y BSD (W3 Techs, 2017), ¿cuál es el motivo que nos hace pensar que Linux no es un objetivo interesante para los atacantes?

Esta semana se ha puesto en contacto conmigo una empresa porque uno de sus servidores respondía con mucha lentitud a las peticiones de los clientes. En estas situaciones se pueden plantear varias posibilidades, y una de ellas es que el sistema haya sido atacado e infectado con algún tipo de malware. Desgraciadamente esta posibilidad suele ser bastante frecuente.

Lo primero es conocer las características del servidor. En este caso es una máquina CentOS 7 en Amazon EC2 en la que se instaló un JBoss versión 4.2.3:

Aquí ya tenemos el primer factor de riesgo, un servidor de aplicaciones con una versión de hace casi 9 años y que tiene muchas vulnerabilidades conocidas.

Por supuesto, si el servidor va lento tenemos que ver cuál es la causa. Con un simple comando top podemos ver algo extraño:

Un proceso kauditd que está consumiendo prácticamente el 100% de CPU. Podemos ver si se lanzó este proceso con algún argumento con un comando “ps -aux | grep -i kauditd”:

kauditd es un proceso conocido de auditoría de eventos del kernel de Linux y cuando lo ejecuta el kernel aparece en el resultado de ps entre corchetes, sin embargo, en este caso vemos que también aparece un comando regular (no está entre corchetes) que tiene el mismo nombre y que utiliza un archivo de configuración con un nombre extraño para ejecutarse. Este último es el que realmente está consumiendo toda la CPU.

Queremos encontrar ese archivo kauditd, así que hacemos una simple búsqueda con find y resulta encontrarse en /tmp:

Donde también está el extraño archivo de configuración que se ha utilizado para ejecutar el comando.  No parece que se hayan tomado muchas molestias en ocultar el rastro del ataque, lo que hace pensar que ha sido automatizado y lanzado de forma masiva contra cientos o miles de máquinas en Internet.  Si le echamos un vistazo al archivo de configuración wqbtraqbpv.conf vemos lo siguiente:

Aquí ya podemos ver que el objetivo del ataque, o al menos uno de ellos, es utilizar este servidor para minería de criptomonedas. Tenemos los servidores a los que se conecta e incluso el identificador del monedero que utiliza el atacante. Con las IPs que utiliza podemos identificar fácilmente que es una Mining Pool de Monero y lo confirmamos con un nslookup:

Los atacantes están infectando miles de máquinas como esta para ganar dinero mediante la minería de las criptomonedas.  Monero es relativamente reciente y los analistas afirman que es la que más futuro tiene. Bitcoin es la más conocida, pero la dificultad es muy alta y se requieren ASICs altamente especializados para que la minería de Bitcoin sea rentable.

Además, en el directorio /tmp hemos visto otros archivos sospechosos que tenemos que analizar. Quizás el que más llame la atención por su tamaño sea el ejecutable “yam”:

Será un binario, pero podemos extraer sus strings para ver si nos aclaran algo. Como han utilizado un miner en este servidor, probablemente esté relacionado:

Lo que no hace más que confirmar lo que ya sabíamos.

Otros dos archivos en el directorio temporal son gates.lod y moni.lod. Si vemos su contenido:

podrían ser identificadores de procesos. Vamos a ver si es así:

Estos dos procesos que se están ejecutando no corresponden a comandos legítimos de Linux, lo que nos hace sospechar que el ataque ha consistido en algo más que poner la máquina a minar criptomonedas. Vamos a ver si hay algún otro archivo más en /usr/bin que haya sido modificado en los últimos dos días:

Vemos que sí que hay varios y /usr/bin no es un directorio cuyos archivos cambien con mucha frecuencia, por lo que parece que han modificado comandos legítimos de Linux como ps o netstat. Si vemos los detalles de alguno de estos archivos:

Curiosamente todos tienen el mismo tamaño y todos han sido modificados al mismo tiempo. La fecha coincide con el momento en el que el cliente afirma haber empezado a notar lentitud en la respuesta del servidor.

Sospechamos que el servidor ha sido infectado con algún payload que se ha inyectado en estos archivos. Es muy posible que se haya convertido en parte de una botnet de los atacantes. Volvemos a hacer una búsqueda de los strings en estos archivos, por ejemplo, buscando el patrón “attack” y vemos lo siguiente:

Las sospechas se confirman y parece bastante claro que estamos viendo los strings que corresponden a las órdenes que esta máquina infectada recibe de servidores C&C (Command and Control), que controlan la botnet a la que ahora pertenece este servidor.

Podemos buscar las direcciones IP de esos servidores C&C:

Y vemos una larga lista de direcciones IP.  En cualquier página de geolocalización podemos ver dónde se encuentran estas IPs:

Tampoco nos extraña que las direcciones IP estén localizadas en China.

Aún podemos buscar algo más de información que nos pueda aclarar el malware que se ha utilizado:

Donde vemos los user-agents que ha utilizado el malware y nos lleva a una familia de malware que suele utilizarlos llamada MrBlack:

Por supuesto, el análisis podría ser mucho más detallado, como por ejemplo hacer un análisis dinámico del malware, pero creo que con esto ha quedado demostrado que esa percepción de seguridad que tienen algunos administradores de sistemas, que utilizan Linux como su sistema operativo principal, es sólo una percepción y no hay ningún sistema que esté libre de ataques.

Como siempre, las recomendaciones son las mismas:

  • Mantener actualizado el sistema y todas las aplicaciones y servicios que se ejecuten sobre él
  • Uso de mínimos privilegios
  • Bloquear todas las conexiones, tanto entrantes como salientes, que no sean estrictamente necesarias. Habitualmente prestamos mucha atención a las conexiones entrantes y somos muy permisivos con las salientes.
  • Utilizar técnicas de refuerzo de sistemas operativos y herramientas de control de red