Aparentemente, cada vez son más los usuarios frustrados que se quejan en los foros porque sus dispositivos integrados se sobrecargan con tareas informáticas y de red. Lo que estas quejas en particular tienen en común es el nombre del proceso que causa el problema, uno que se ejecuta desde un directorio temporal y se hace pasar como parte del marco de Java, bajo el nombre “.javaxxx“. También usa los nombres adicionales “.swap” o “kworker“. Hoy veremos de dónde vienen estos reclamos.
Hace unas semanas, analizamos los incidentes recientes de Mirai y los problemas de seguridad provocados por esta botnet en nuestro artículo “Un ejército de zombis: Cuando los dispositivos IoT están fuera de control“. Todo lo que escribimos en ese momento aún sigue vigente.
Vector de ataque
El ataque se realiza a través de intentos de inicio de sesión remoto vía SSH por fuerza bruta, y opera de manera similar a los gusanos para Linux, incluyendo Linux/Moose (que para propagarse atacó los inicios de sesión de Telnet y sigue activo), y al que ESET ha estado investigando desde el año pasado. Entre los objetivos de ataque se encuentran los dispositivos y servidores integrados que tienen un puerto SSH abierto y cuya contraseña es muy débil.
El propósito evidente de este troyano es recopilar una lista de dispositivos desprotegidos y construir una botnet de dispositivos zombis que sea de interés para los atacantes. De esta forma, les suministra una lista selecta y no demasiado extensa de objetivos: únicamente se infectarán las máquinas que representen oportunidades fáciles desde la perspectiva de seguridad.
Cabe notar que las víctimas informaron casos en los que tenían una contraseña segura, pero restauraron la configuración del dispositivo a los valores de fábrica con la contraseña predeterminada, olvidando que su dispositivo estaba online. Un par de horas de exposición online es suficiente para que una máquina restaurada a la configuración de fábrica resulte infectada.
Análisis
El malware está escrito en Go y normalmente aparece comprimido con la herramienta UPX original. Lo extraño es que los desarrolladores quitaron los nombres de las funciones en el archivo binario, pero igualmente siguen estando presentes en una sección especial.
Con la ayuda de un script creado por RedNaga Security, que vuelve a asignar los símbolos correspondientes a sus funciones en el software desensamblador IDA Pro, se simplificó todo el análisis y solo hubo que revisar las funcionalidades que sugerían los nombres de las funciones, tales como main_loadConfig, main_startLocalHttp, main_Skaro_Upgrade,main_IPTarget_checkSSH, etc. El archivo binario incluye cadenas de caracteres como “Skaro” y “dalek“. Los autores posiblemente tenían en mente el planeta ficticio de la serie televisiva de ciencia ficción Doctor Who, donde se originaron los Daleks.
Como primer paso, Linux/Rakos carga su configuración a través de una entrada estándar (stdin) en formato YAML. El archivo de configuración contiene información como listas de C&C, todas las credenciales que se prueban contra sus objetivos y los parámetros internos:
| —
version: 30 skaro: checkers: userpass: [ |
“guest:1234”, “root:1111”, “test:test”, “support:password”, “admin:1”, “test:test123”, “manager:manager”, “fax:fax”, “service:service”, “root:letmein”, “sales:sales”, “guest:guest”, “shell:sh”, “enable:system”, “user:password”, “backup:backup”, “ftpuser:ftpuser”, “admin:password123”, “monitor:monitor”, “bin:bin”, “root:ikwb”, “admin:manager”, “oracle:oracle”, “test:12345”, “bob:bob”, “user1:1234”, “root:1234”, “root:system”, PlcmSpIp:PlcmSpIp”, |
“user1:123456”, “1:1”, “root:1”, “support:123456”, “nagios:nagios”, “demo:demo”, “admin:1111”, “PlcmSpIp:PlcmSpIp”, “pos:pos”, “support:12345”, “root:baseball”, “guest:12345”, “admin:1234”, “apache:apache”, “root:123456”, “adam:adam”, “root:alpine”, “tester:retset”, “root:raspberry”, “pi:raspberry”, “administrator:1234”, “admin:abc123”, “admin:qwerty”, “root:openelec”, “admin:admin1234”, “shipping:shipping”, “ftpuser:asteriskftp”, “operator:operator”, ] |
La configuración completa de Linux/Rakos en texto sin formato está disponible en el repositorio de ESET en Github.
En segundo lugar, el malware inicia un servicio HTTP local disponible en https://127.0.0.1:61314. Hay dos razones por las que se instala: la primera es como un método ingenioso para que las versiones futuras del bot cierren las instancias en ejecución (independientemente del nombre que estas tengan) mediante una solicitud https://127.0.0.1:61314/et; la segunda es porque intenta analizar los parámetros “ip”, “u” y “p” en una consulta URL mediante una solicitud https://127.0.0.1:61314/ex. El propósito del recurso /ex de HTTP aún no está claro en el momento en que se escribe este informe, y no parece que haya referencias a él en ninguna otra parte del código.
El bot también crea un servidor web que escucha en todas las interfaces. En las primeras versiones, escuchaba en el puerto TCP 13666, pero ahora el puerto se selecciona aleatoriamente dentro del rango 20000 a 60000. Al enviar una solicitud remota al dispositivo a través de este puerto, se muestra un mensaje como este en el navegador:
| {“origin”:”192.168.18.1″} |
Allí, la dirección IP corresponde al lado del cliente. La salida está en el mismo formato que el servidor de prueba público https://httpbin.org con la solicitud /ip. En el lado que ejecuta Linux/Rakos, se puede llegar a ver la siguiente línea de registro en stdout:
| “{2016/11/21 09:02:03 INFO StartChecker.func1 ▶ 001 check: 192.168.18.1}” |
A continuación, envía una solicitud HTTP inicial que contiene información importante de la víctima a https://{cnc_server}/ping. Los datos enviados pueden ser los siguientes (algunos campos han sido alterados artificialmente):
| { “arch”: “amd64”, “config”: 30, “fork”: 0, “generation”: 0, “ip”: “192.168.18.1”, “origin”: “unknown”, “password”: “shipping”, “services:”: {“http”:{“addr”:”192.168.18.1:80″,”available”:false,”running”:false}, “dns”:{“addr”:””,”available”:false,”running”:false}, “checker”:{“addr”:”192.168.18.1:22418″,”available”:false,”running”:true}}, “stats”: { “cnt”: “load: 0 scan: 0 bless: 0 sm:0 ins: 0 mem: 2692k”, “cpu”: “1 x Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz 3591Mhz”, “facts”: “host: ubuntu pid: 10219 uid: 0 args: [/tmp/.javaxxx]”, “load”: “1.14 0.45 0.17”, “mem”: “592MB / 1983MB free (35.21% used)”},“uptime”: 514, “username”: “shipping”, “uuid”: “ab-97-b1-d5-2d-8f”, “version”: 706 } |
La funcionalidad principal de este bot es explorar el servicio SSH en diversas direcciones IP, que se obtienen del servidor de C&C al solicitar la lista ubicada en https://{cnc_server}/scan. Al parecer, esta lista se modifica con frecuencia. Las versiones anteriores del troyano también analizaban el servicio SMTP, pero los atacantes han silenciado esta funcionalidad (posiblemente la estén desarrollando para mejorarla).
El ataque principal se lleva a cabo de la siguiente manera: si la conexión con el objetivo se logra correctamente, se ejecutan dos comandos de manera remota (id, uname -m). Se hacen otras comprobaciones y se informan sus resultados. Finalmente, el binario verifica si puede cargarse al dispositivo de la nueva víctima y lo hace si la respuesta es afirmativa.
Para nuestro análisis, seleccionamos dos objetivos (127.0.0.1 y 127.0.0.100) y simulamos un ataque (originalmente, los atacantes lo intentan con 200 objetivos simultáneos cada 10 segundos). En caso de que el bot no logre conectarse al primer objetivo, lo etiquetará con la palabra “FORGET” (olvidar). Si a continuación se conecta correctamente al segundo objetivo, lo marcará con la palabra “INSTALL” (instalar) y se establece una conexión SSH con los datos de inicio de sesión correctos shipping:shipping; también es importante notar que el archivo ejecutable cargado se elimina de inmediato tras su ejecución.
Además, el backdoor es capaz de:
- actualizar el archivo de configuración (desde https://{cnc_server}/upgrade/vars.yaml)
- mejorarse a sí mismo.
No se implementa ninguna actividad maliciosa evidente de las que podríamos esperar, como ataques de DDoS o propagación de spam (al menos hasta este momento). No obstante, el hecho de que se envíen la dirección IP, el nombre de usuario y la contraseña significa que los atacantes podrán hacer lo que quieran con la máquina más tarde. Creemos que es poco probable que solo se trate de un experimento invasivo pero inocente, o de un ejercicio o una investigación académica que salió mal.
Hay varios informes online sobre las infecciones. Por ejemplo, se puede encontrar uno del 23 de agosto de 2016 en Pastebin. La siguiente tabla contiene el resultado al ejecutar “lsof –n” en el proceso culpable. Hay que recordar que los rangos de direcciones IP probados por SSH parecen aleatorios:
| CMD | PID | USER | FD | TYPE | SIZE/OFF | NODE | NAME | |
|---|---|---|---|---|---|---|---|---|
| .javaxxx | 2773 | root | txt | REG | 5822568 | /tmp/.javaxxx | (deleted) | |
| .javaxxx | 2773 | root | 5u | IPv6 | 0t0 | TCP | *:13666 | (LISTEN) |
| .javaxxx | 2773 | root | 6u | IPv4 | 0t0 | TCP | 127.0.0.1:61314 | (LISTEN) |
| .javaxxx | 2773 | root | 7u | IPv4 | 0t0 | TCP | 192.168.88.210:59958->66.209.103.211:ssh | (ESTABLISHED) |
| .javaxxx | 2773 | root | 10u | IPv4 | 0t0 | TCP | 192.168.88.210:57370->139.196.21.134:ssh | (ESTABLISHED) |
| .javaxxx | 2773 | root | 13u | IPv4 | 0t0 | TCP | 192.168.88.210:52507->148.75.167.198:ssh | (SYN_SENT) |
| .javaxxx | 2773 | root | 16u | IPv4 | 0t0 | TCP | 192.168.88.210:54746->208.9.162.70:ssh | (SYN_SENT) |
| .javaxxx | 2773 | root | 17u | IPv4 | 0t0 | TCP | 192.168.88.210:54533->148.75.167.191:ssh | (SYN_SENT) |
| .javaxxx | 2773 | root | 18u | IPv4 | 0t0 | TCP | 192.168.88.210:51856->139.196.20.79:ssh | (ESTABLISHED) |
| .javaxxx | 2773 | root | 19u | IPv4 | 0t0 | TCP | 192.168.88.210:57210->208.9.162.95:ssh | (SYN_SENT) |
| .javaxxx | 2773 | root | 24u | IPv4 | 0t0 | TCP | 192.168.88.210:45946->148.75.167.99:ssh | (SYN_SENT) |
| .javaxxx | 2773 | root | 25u | IPv4 | 0t0 | TCP | 192.168.88.210:55928->208.9.162.25:ssh | (SYN_SENT) |
| .javaxxx | 2773 | root | 27u | IPv4 | 0t0 | TCP | 192.168.88.210:50041->139.196.21.177:ssh | (ESTABLISHED) |
Mitigación y desinfección
El troyano no es capaz de mantener su persistencia tras reiniciar el sistema. Por lo tanto, los dispositivos disponibles se pueden infectar reiteradamente.
Los pasos necesarios para desinfectar son los siguientes:
- Conéctate a tu dispositivo mediante SSH/Telnet,
- Busca un proceso llamado .javaxxx,
- Ejecuta comandos como netstat o lsof con el conmutador -n para confirmar que es el responsable de establecer las conexiones no deseadas,
- (Acción voluntaria) recopila evidencia forense volcando el espacio de memoria del proceso correspondiente (por ejemplo, con gcore). También es posible recuperar la muestra borrada desde /proc con cp /proc/{pid}/exe {output_file}
- Finaliza el proceso con el parámetro -KILL.
Naturalmente, es imprescindible que las víctimas protejan sus credenciales SSH y deben recordar volver a hacerlo después de cada restablecimiento a los valores de fábrica.
También preparamos un complemento para Volatility Framework llamado vf_ioc_linux_rakos_a.py que detecta los indicadores de sistemas comprometidos si se cuenta con un volcado de memoria completo que admita este marco. Además, este complemento extrae datos del proceso malicioso como la configuración o la información enviada al servidor de C&C. Está disponible también en GitHub.
Conclusión
En esta ocasión presentamos otro ejemplo de un backdoor para Linux que se propaga a través de un canal bastante conocido. Parece que a los atacantes les conviene escribir nuevas muestras de software malicioso para aprovechar las vulnerabilidades actuales de la seguridad de la red.
Fuente:https://www.welivesecurity.com/
Entusiasta de la seguridad cibernética. Especialista en seguridad de la información, actualmente trabajando como especialista en infraestructura de riesgos e investigador.
Experiencia en procesos de riesgo y control, soporte de auditoría de seguridad, diseño y soporte de COB (continuidad del negocio), gestión de grupos de trabajo y estándares de seguridad de la información.
Envía tips de noticias a info@noticiasseguridad.com o www.instagram.com/iicsorg/.
También puedes encontrarnos en Telegram www.t.me/noticiasciberseguridad
