Symbiote es un rootkit de Linux particularmente desagradable, y tenemos el caso interesante de dos análisis separados que se lanzarán esta semana. arriba primero es [CyberMasterV] desmontando una muestra muy temprana del malware. El propósito principal de Symbiote parece ser capturar los inicios de sesión SSH, y esta versión lo hace conectando el sistema de Módulos de autenticación conectables (PAM) para capturar a los usuarios que inician sesión en la máquina en la que reside. También busca binarios SSH y SCP, y huele la terminal utilizada por esos binarios, capturando así las credenciales salientes.
Todos estos datos se empaquetan como consultas de DNS y se transfieren al servidor de comando y control. “Fácil”, le escucho decir, “simplemente bloquee el tráfico de DNS a todas partes excepto a un proveedor de DNS de confianza”. Es más inteligente que eso. Los datos están en forma de subdominios DNS válidos. En su totalidad, es una solicitud de DNS para PacketNumber.MachineID.Data.px32.nss.atendimento-estilo[.]com
, todos debidamente codificados para ser válidos. Cada solicitud será para un nombre de host único, por lo que cada solicitud se reenvía al controlador de C&C, que cumple una doble función como el solucionador de DNS autorizado para ese dominio. Es posible que obtenga algún beneficio del bloqueo (o al menos del registro) de consultas de DNS muy largas.
Symbiote también reemplaza los archivos y dispositivos típicos que buscaría para encontrar un problema potencial. Por ejemplo, /proc/net/tcp
es donde el núcleo informa de las conexiones TCP abiertas. En una máquina infectada, el malware mantiene una copia de este archivo, convenientemente omitiendo las conexiones resultantes de las infecciones. Simbionte tiene un gancho en fopen
, por lo que cada vez que un proceso intenta leer esta ubicación, la lectura se redirige a la versión cocinada, lo que oculta perfectamente el rootkit. Aparentemente, esta función de sigilo también se usa para ocultar otro malware de los mismos atacantes que pueden estar en la misma máquina.
Ahora veamos el segundo análisis, un esfuerzo conjunto de BlackBerry e Intezer. Esto es de una muestra posterior de Symbiote, y ha habido una evolución interesante. Lo más notable es que utiliza el filtro de paquetes de Berkeley (BPF) para ocultar su tráfico de las capturas de paquetes. Dado que los filtros BPF se ejecutan directamente en el kernel, esta es una técnica sigilosa muy poderosa. Symbiote incluso detecta una serie de ldd
, que lo enumeraría como una biblioteca en ejecución. Esto también se desinfecta, lo que hace que Symbiote sea muy difícil de detectar. Debería ser posible utilizar las funciones de rootkit de Symbiote en su contra, para la detección. Por ejemplo, uno de los nombres de archivo que está oculto es apache2start
. Debería ser posible touch
este nombre de archivo, y luego ejecute ls
en el directorio que debería contenerlo. Si el nuevo archivo aparece en la lista, probablemente esté bien. Si falta, es muy probable que tenga el rootkit ejecutándose. Nos hemos puesto en contacto con los investigadores para que nos ayuden a confirmar esta sencilla técnica de detección, así que manténgase atento a una posible actualización.
Cerraduras “inteligentes”
Una vez más, cuando se trata de IoT, la S significa seguridad. La diversión comienza con un error clásico, en realidad no hacer la verificación SSL. Entonces, el firmware se comunica con un servidor HTTPS para operar, pero aceptará cualquier certificado para esa conexión. Man-in-the-Middle es mucho más fácil en ese caso. Y esa postura de MitM se combina bien con el siguiente problema que encontraron los investigadores de NCC Group, un desbordamiento de búfer en el análisis de JSON. Ponga estos dos juntos, y sentarse en la misma red que el candado hace que el código se ejecute en él.
Para la mayoría de nosotros, un atacante en la red interna, o incluso en una red dedicada de IoT, ya es un desastre. Hay otra cadena de ataque que fue descubierta. La forma en que generalmente se instala esta cerradura es con un “giro de llave” instalado en una puerta, se desbloquea físicamente hasta que la puerta se desbloquea y se abre. La segunda mitad es el “teclado”, la pieza de cara al público donde se ingresa el código. En teoría, el hardware del manipulador de llaves no debe confiar en ese teclado, y solo debe pasar las pulsaciones de teclas a través del enlace BLE. En la práctica, el teclado puede enviar una solicitud de desbloqueo sin el código y desbloquear la puerta.
Esto lleva al elemento final, puertos JTAG accesibles en el teclado. JTAG es una interfaz de depuración para dispositivos integrados, extremadamente útil para actualizar el firmware a dispositivos que de otro modo estarían bloqueados, así como para realizar la depuración en tiempo real. Es ese último el que hace el trabajo aquí. Conéctese al puerto JTAG del teclado y tome los datos de autenticación de la memoria. Luego use un dispositivo diferente y los datos de autenticación para falsificar el teclado y enviar comandos arbitrarios a través del enlace BLE. Pídele cortésmente al manipulador de llaves que desbloquee, y lo hará. Con un equipo dedicado y un poco de práctica, es probable que todo el proceso se reduzca a unos pocos segundos. ¡Uf!
El lado positivo es que Nuki, el fabricante de esta cerradura, hizo un trabajo estelar al manejar el informe de vulnerabilidad. Los parches salieron menos de dos meses después de que se informaran los problemas. Se enviaron avisos a los clientes activos y luego, después de un período de tiempo adecuado, se divulgaron públicamente las vulnerabilidades.
Su servidor está comprometido
Recibe una llamada o un correo electrónico de su empresa de alojamiento, Linode en este caso, que su servidor alojado está participando en un ataque DoS. Es probable que estés pwned.
¿Que sigue? Los investigadores de Trunc tienen algunos consejos. En primer lugar, es útil tener algo como
sysstat
en ejecución, un demonio de recopilación de estadísticas del sistema. El siguiente paso es SSHing a la máquina y ejecutar algunas herramientas. last
muestra el historial de inicio de sesión de la máquina, top
enumera el uso de CPU y memoria ordenado por proceso, df
muestra espacio libre en disco, ps
enumera los procesos en ejecución, y lsof
muestra la lista de archivos abiertos. A menos que esté lidiando con un rootkit realmente desagradable, como Symbiote discutido anteriormente, estas herramientas deberían mostrar algo inusual. Si sysstat se ha estado ejecutando, sar -n DEV
proporciona algunos datos sobre el uso de la red a lo largo del tiempo. Si esta máquina está enviando mucho tráfico, debería aparecer aquí, dándote una buena idea de cuándo comenzaron las cosas.
El sistema en cuestión mostró un gran pico de tráfico, y el apache
binary estaba ejecutando un uso de CPU muy alto. Eso parecía extraño. Los registros tenían algunas entradas que indicaban una llamada a POST //xmlrpc.php HTTP/1.1
. Si bien se puede abusar de este punto final para la reflexión de DDoS, no había suficientes entradas de registro para sugerir ese problema. Entonces, lo siguiente es buscar archivos modificados. Hay opciones para esto, como OSSEC
, pero deben ejecutarse en la máquina en un estado bueno conocido. Entonces, ¿cómo verifica si hay archivos manipulados si no tiene eso en su lugar? Si está ejecutando WordPress, simplemente puede descargar y descomprimir una copia nueva del tarball de instalación que coincida con su versión instalada. Descomprímalo y utilícelo diff
para encontrar alguna diferencia. Una de esas diferencias puede ser un webshell inyectado en uno de los archivos PHP de WordPress.
REstringer desofusca Javascript
Como hacker, uno de los problemas más irritantes es el código ofuscado. Javascript es inherentemente abierto, pero las técnicas de ofuscación hacen que la fuente sea totalmente ilegible. [Ben Baryo] está trabajando en una solución, un desofuscador al que llama REstringer. Intenta coincidir con el tipo de ofuscación que se está utilizando y luego pasa por métodos seguros de desofuscación. Hay una advertencia importante allí. Puede ser muy difícil desofuscar el código sin ejecutar accidentalmente partes de ese código. Todavía es un trabajo en progreso activo, así que revise el código o pruebe la demostración en vivo.
Rootkits UEFI
Hay una especie de Boogeyman en la seguridad informática, el malware mítico que se incrusta en el firmware de una computadora, lo que hace que la eliminación sea imposible. Si bien es teóricamente posible que el firmware de una placa base pueda ser manipulado de esta manera, seguramente eso es solo un mito, y tal vez los actores estatales lo utilicen para sus objetivos más importantes.
Esa teoría ha recibido un golpe, ya que un rootkit que usa exactamente esta técnica ha aparecido en la naturaleza. Los investigadores de Kaspersky lo han denominado CosmicStrand y señalan que se encontraron infecciones en China, Vietnam, Irán y Rusia. Algunas pistas en el código sugieren un origen chino y una posible conexión con otro malware que también se origina en esa región.
Técnicamente, usar firmware malicioso para iniciar una reinfección es toda una proeza. Primero, tenga en cuenta que este código se ejecuta mientras la máquina se inicializa, mucho antes de que el sistema operativo Windows comience a ejecutarse. ¿Cómo se las arregla el código del rootkit para realizar una infección sofisticada cuando su propia ejecución finaliza mucho antes de que el kernel de Windows comience a ejecutarse?
Implanta código en el administrador de arranque de Windows, que a su vez conecta el cargador del sistema operativo Windows. Este cargador es parte del proceso de arranque de Windows y permite que se dirija más manipulación contra el propio kernel de Windows. Y finalmente, una vez que se inicia el kernel, esta carga útil implementa el shellcode real. La sofisticación de este malware es bastante sorprendente.