Empleando técnicas Rookit para ocultar VirtualBox

septiembre 20, 2013 § Deja un comentario

‘Hand of the Thief’ es un troyano “comercial” que se ha estado moviendo por foros rusos. Este troyano está dirigido a sistemas Linux y su función principal es el robo de credenciales bancarias, aunque no se limita a este tipo de webs. Dicha función permite al troyano captar las credenciales a través de form grabbing. Curiosamente, a pesar de ser un troyano orientado a sistemas Linux, posee un sistema de manipulación de registros DNS en memoria. Es decir, el troyano no toca los archivos para modificar la resolución de nombres local.

El troyano ha sido probado con éxito en diversas distribuciones: Fedora, Arch Linux, Gentoo, Debian entre otras.

Una de las técnicas tradicionales para evitar su análisis por parte de las compañías antivirus es la detección de máquinas virtuales, esto es, cuando el troyano se está ejecutando en un entorno virtualizado su comportamiento pasa a ser inocuo o directamente finaliza su ejecución de manera prematura. ‘Hand of the Thief’ detecta máquinas virtuales VirtualBox, VMware, Power VM, IBM/S390, QEMU y Xen.

No vamos a describir aquí el comportamiento de este troyano, ya que esto daría para otro post y además existe un excelente análisis aquí. Lo que vamos a ver son técnicas concretas que podemos usar para esconder el entorno de virtualización, en concreto VirtualBox. Primero introduciremos los términos que vamos a usar y posteriormente veremos como el troyano intenta detectar la virtualización y como podemos evadir dicha funcionalidad.

Definiciones

Las técnicas rootkit permiten ocultar la presencia de un malware, explotar vulnerabilidades y escalar privilegios en un sistema (cuanto más altos, mayor control sobre el sistema). Un rootkit puede cargarse tanto en espacio de usuario como en el espacio del kernel (donde siempre tendrá más control).

Una llamada al sistema o system call, es una función que se efectúa en el espacio de usuario para transferir momentaneamente el control al kernel a través de una interrupción. Podemos ver una lista de las llamadas al sistema realizadas por un proceso a través del programa strace. El funcionamiento de una llamada al sistema es sencillo: Un proceso en espacio de usuario necesita ejecutar una llamada al sistema, mete en la pila su índice, parámetros y ejecuta una interrupción a través del código ensamblador INT 0x80. En ese momento el kernel recoge dicha petición, busca en el índice la función correspondiente, la ejecuta con los parámetros provistos por el usuario y retorna el resultado y el control de ejecución al proceso del usuario.

Un driver es un módulo del kernel. Un programa inyectado en el espacio del kernel teniendo acceso tanto a dicho espacio como al espacio del usuario. Dispone de una variedad de instrucciones más amplia que un proceso de usuario debido a los privilegios que dispone. Un módulo se carga en el kernel con el comando insmod o modprobe y se desinstala con rmmod.

Evitando la detección

Para detectar la máquina virtual VirtualBox, el troyano prueba la presencia de la cadena “VBOX” dentro del archivo “/proc/scsi/scsi” que lista los discos SCSI usados (disco duro, disco de DVD, etc.). Si lo encuentra, el troyano termina su ejecución. Como dijo P. Kalni, podemos evitar esta prueba quitando el modo lectura de este archivo para que el troyano no pueda leerlo. Sin embargo, este método es limitado y no puede generalizarse a otro troyano ya que éste podría probar si el archivo esta en modo lectura. Nuestra solución implica el uso de un rootkit para modificar el contenido del archivo leído. Es decir, que cuando el troyano lea el archivo, el rootkit va a buscar la cadena VBOX y la reemplazará por otra cadena. De esta manera, modificamos el contenido leído al vuelo y no el archivo. En este ejemplo, modificamos la cadena VBOX por “____”.

Cuando un programa lee un archivo, llama a la system call “read” de la biblioteca libc que ejecuta la función del kernel “sys_read” a través de la interrupción 0x80. En otras palabras, para modificar el contenido al vuelo de un archivo leído se necesita hookear la función del espacio de usuario “read” o del espacio del kernel “sys_read”. Hemos elegido hookear la función del kernel porque el programa podría escapar del hook de la función “read” llamando a la función “sys_read” directamente. Además, hookear la función “read” supone que el malware use la biblioteca libc para leer un archivo.

Hookear la función “sys_read” significa cambiar el modo lectura de la tabla de llamadas al sistema para poder escribir y cambiar el index en dicha tabla de la función “sys_read” para redireccionarla a nuestra función “new_sys_read”. Hemos creado un driver para hookear la función “sys_read” y crear la nueva función “sys_new_read”. Cuando la función “new_sys_read” sea llamada, ella va a (1) llamar a la función original “sys_read” para recoger una parte del archivo o la totalidad del archivo en un búfer, (2) reemplazará cada cadena VBOX por “____” del búfer y (4) devolverá el búfer modificado.

Sin embargo, necesitamos conocer la dirección de la función “sys_read” para llamarla desde “new_sys_read”, conocer la dirección de la tabla de llamadas al sistema para modificar la entrada “sys_read”, y también la dirección de la función “lookup_address” que nos permite obtener la página correspondiente a la tabla de llamadas al sistema para cambiarla del modo lectura y escritura. Estas direcciones variarán de un sistema a otro. Se pueden encontrar en el archivo /boot/System.map.

Esto es solo una de las múltiples técnicas que podemos emplear para evadir este tipo de detecciones. Por supuesto, ni es la única técnica que emplean los troyanos para evadir la ejecución sobre una plataforma virtualizada, ni es la única contramedida de las que disponemos.

Fuente: Hispasec

Anuncios

RDFU: framework para la detección de bootkits en las "nuevas BIOS" (EFI)

agosto 14, 2013 § Deja un comentario

Según reza la Wiki “La Interfaz Extensible del Firmware, Extensible Firmware Interface (EFI), es una especificación desarrollada por Intel dirigida a reemplazar la antigua interfaz del estándar IBM PC BIOS, que interactúa como puente entre el sistema operativo y el firmware base.”

En 2005 se creó la fundación UEFI (Unified Extensible Firmware Interface) cuya labor consistía en desarrollar y promocionar esta plataforma EFI y hoy en día la mayoría de los sistemas operativos sobretodo de 64 bits lo soportan, de hecho se prevé que Windows 8 sustituya completamente la BIOS por EFI.

Evidentemente esta “modernización” del arranque de los PCs no ha pasado inadvertida para los desarrolladores de malware que han fijado UEFI como uno de sus grandes objetivos, más aún cuando la detección y/o erradicación de rootkits o bootkits es muy difícil.

Para combatir esta nueva amenaza Reversing Labs ha desarrollado Rootkit Detection Framework para UEFI (“RDFU”) que incorpora un conjunto de herramientas y drivers que tratan este problema a lo largo de un gran número de implementaciones UEFI:

  • enumera todos los drivers EFI cargados en memoria
  • comprueba rangos de memoria en busca de ejecutables
  • monitoriza nuevos drivers cargados hasta que se inicia el sistema operativo
  • lista EFI BOOT SERVICES y EFI RUNTIME SERVICE en busca de modicaciones en punteros de función
  • supervisa continuamente EFI BOOT SERVICES y EFI RUNTIME SERVICE mientras que se carga el sistema operativo
  • muestra el mapa de memoria y vuelca tosas las regiones adecuadas
  • lista y monitoriza rellamadas de eventos que pueden ser utilizadas por rootkits/malware
  • trabaja en modo standalone sin el shell EFI

Descargas: White Paper | Blackhat 2013 Presentation | Source Code

Fuente: HackPlayers

AVATAR: un rootkit que promete grandes novedades y con precio de oferta

mayo 4, 2013 § Deja un comentario

Aparece en el mercado (negro) un nuevo rootkit que según sus creadores “no es detectado por los antivirus ni por los famosos antirootkit GMER o RKU”.

En la carta de presentacion, los creadores aclaran que el rootkit no está a la venta, solo en alquiler y a un precio promocional de lanzamiento y aclaran que todavía no funciona correctamente en sistemas x64, sólo en los sistemas basados en i386.

El tamaño del ejecutable es de 120 Kb sin empaquetar y sus 327.416 líneas de codigo fueron escritas en C++ y ASM.

Tiene varias novedades para los “chicos malos”, por ejemplo trae un SDK para desarrollo llamado ASDK (Avatar Software Development Kit) y una biblioteca ARTL (Avatar Runtime Library) y una WinAPI, es decir, todo el paquete necesario para el desarrollador. El malware basa su supervivencia mediante el uso de exploits basados en Metasploit y 0-Days y no se guarda en disco sino que se carga directamente desde la memoria, lo que le permite saltear UAC y la lista blanca de software firmado de Windows.

Después de cargar correctamente el controlador del rootkit, Avatar ejecuta un algoritmo para infectar a los controladores del sistema con el fin de sobrevivir al reinicio del sistema. Con el fin de realizar su infección, Avatar elige al azar un driver y comprueba su nombre en una lista negra que varía para cada versión de Windows.

También en la presentacion en sociedad de AVATAR recuerdan los “viejos tiempos” donde uno podía mantener una botnet muchísimo tiempo sin ser descubierto y donde las botnets crecian rápidamente al igual que la monetizacion de las mismas. El negocio actual esta muy complicado y los tiempos son difíciles y, en muchos casos estan al borde del rojo financiero. Melancólicamente recuerdan el cierre de botnets de gran alcance como Waledac, Coreflood, Kelihos, Rustock y Conficker… por lo que proponen un metodo novedoso de C&C mediante conexiones cifradas con RSA de 1024 bits lo que hace más difícil la detección. Como novedad, para método de control AVATAR no utiliza los clasicos C&C sino que utiliza un híbrido entre un c&C y Grupos de Yahoo!.

Aclaran que el bajo precio es por la falta de soporte para x64 y por su debut en el mercado y que luego irán acomodando los precios para garantizar que sólo los “profesionales” tengan acceso.

La buena noticia para nosotros, los chicos buenos, es que los antivirus ya comienzan a analizarlo en profundidad y a detectarlo y pronto el todos los antivirus lo harán.

Adolfo de la Redaccion de Segu-Info (@adolfofioranell)

Detectar Rootkits en Linux

marzo 4, 2013 § 1 comentario

Una de las primeras acciones que lleva a cabo un intruso, una vez ingresa a un sistema, es instalar un rootkit, el cual facilita el control de la máquina desde ese momento en adelante. Dichas herramientas presentan un gran riesgo para los administradores y, por tanto, es de vital importancia conocer sus alcances, funcionamiento y los mecanismos que existen para detectarlos.

Los Rootkits fueron descubiertos a mediados de los ’90. En aquella época, los administradores de sistema del sistema operativo Unix de SUN comenzaron a ver un comportamiento extraño en el servidor, la falta de espacio de disco, ciclos extra en la CPU y las conexiones de red que no se mostraba con el comando netstat.

1. ¿Qué son exactamente?
Los Rootkits son herramientas que permiten esconder actividades intrusas dentro de un sistema, después de que un intruso ha logrado penetrar en él. Además, proveen al atacante de vías de acceso ocultas para utilizar nuevamente el sistema en futuras oportunidades. El nombre Rootkit se origina a partir de la idea de que quien lo utiliza puede acceder fácilmente al nivel de root, o de administrador del sistema, una vez la herramienta ha sido instalada.

2. ¿Qué tipos hay?

De acuerdo a la teconología empleada, existen tres clases principales de Rootkits disponibles hoy:

  • Kits binarios: alcanzan su meta substituyendo ciertos ficheros del sistema por sus contrapartes Troyaneadas.
  • Kits del núcleo: utilizan los componentes del núcleo (también llamados módulos) que son reemplazados por troyanos.
  • Kits de librerías: emplean librerías del sistema para contener Troyanos.

3. ¿En qué se basan?
El principio operativo de los rootkits es el de reemplazar archivos de programa del sistema con versiones modificadas, para que se ejecuten determinadas operaciones. A estas versiones modificadas se les conoce con el nombre de troyanos. Un rootkit es, en esencia, una colección de programas troyanos.

4. Objetivos
El objetivo de los troyanos es imitar exactamente el comportamiento de las aplicaciones originales, pero escondiendo los archivos, acciones y evidencias del intruso. En otras palabras, una vez instalado el rootkit, en principio, el intruso podrá utilizar el sistema sin ser detectado por el administrador. Sin embargo, actualmente existen métodos para detectar la presencia de rootkits dentro de un sistema.

5. Qué ficheros suelen los intrusos troyanizar

Algunos son:  login, su, telnet, netstat, ifconfig, ls, find, du, df, libc, sync
Así como los binarios listados en /etc/inetd.conf.

6. Algunos Rootkits
Solaris rootkit, FreeBSD rootkit, lrk3, lrk4, lrk5, lrk6, t0rn (and t0rn v8), some lrk variants, Ambient’s Rootkit for Linux (ARK), Ramen Worm, rh[67]-shaper, RSHA, Romanian rootkit, RK17, Lion Worm, Adore Worm, LPD Worm, kenny-rk, Adore LKM, ShitC Worm, Omega Worm, Wormkit Worm, dsc-rootkit.

Detectar Rootkits

Existen maneras de diferenciar los ejecutables legítimos de los troyanos mediante el uso de algoritmos de chequeo de suma. Dichos algoritmos, como el MD5 checksum, garantizan que la única forma de que el resultado de la suma sea igual para dos archivos, es que los dos archivos sean perfectamente idénticos. De esta forma, un administrador precavido debe almacenar los checksum de su sistema en dispositivos externos, tales como CD’s, para poder, más adelante, identificar rootkits comparando dichos números con los generados por un programa de chequeo en un momento determinado.

A. Una herramienta diseñada para este fin es Tripwire, el cual mantiene control de integridad sobre los archivos del sistema.

B. Otra manera para detectar la posible existencia de rootkits es realizar escaneos de puertos desde otros equipos, con el fin de detectar puertas traseras que estén escuchando en puertos que normalmente no se utilizan. También existen demonios especializados, como rkdet para detectar cualquier intento de instalación de un rootkit y, de ser posible, impedirlo y avisar al administrador del hecho.

C. Otra herramienta es Chkrootkit que es un shell script que busca en nuestro sistema binarios modificados por rootkits.

Entre otras tareas Chkrootkit revisa localmente rastros de rootkits incluyendo detección de:

  • rootkits LKM
  • ifpromisc.c: para revisar y ver si la interface de red está en modo promiscuo
  • chklastlog.c: para revisar lastlogs por las tachaduras
  • chkkwtmp.c: para revisar wtmp por las tachaduras

Algunas herramientas antirootkits recomendadas para su instalación:

Estas son algunas de la herramientas que recomendamos su instalación para evitar los accesos indeseados, como programar su ejecución, ya se lo dejamos al administrador:

Y así, es como podrá instalarlos directamente desde sus propios repositorios (que además es lo recomendado). Para buscar paquetes relacionados se puede usar yum search rootkit o apt-cache search rootkit

Fuente: Linux Party

Vulnerabilidad en microprocesador, aprovechada por rootkits en Linux

diciembre 8, 2012 § Deja un comentario

Una vulnerabilidad en los procesadores Intel x86_64 debida a un incorrecto manejo de los punteros de retorno de excepciones de protección está siendo aprovechada por rootkits en Linux para obtener escalado de privilegios y/o bloqueos de las máquinas afectadas. El problema afecta tanto al SO principal de la máquina como a versiones paravirtualizadas en Xen, ya sea Linux, Windows en cualquiera de sus versiones o alguna variante de BSD Unix. El rootkit fue diseñado para el Kernel 2.6.32-5-amd64 posteriormente crea una botnet.

Si bien los principales fabricantes y distribuciones ya han publicado versiones corregidas, todavía parece haber multitud de equipos vulnerables, por lo que se recomienda proceder a su actualización y parcheado lo antes posible.

Fuente: Kriptopolis

#Crisis/Morcut: primer malware para máquinas virtuales

agosto 25, 2012 § Deja un comentario

Crisis, también conocido como Morcut, es un rootkit descubierto el pasado julio, que infecta tanto ordenadores con Windows como Mac OS X. Se camufla a través de un falso aviso de instalación del reproductor Flash de Adobe, y una vez instalado crea una “puerta trasera” por donde puede grabar conversaciones de Skype y mensajería instantánea, o grabar el tráfico visitado desde Firefox y Safari.

No pasaría de ser una muestra más de las muchas que abundan entre el malware de no ser porque ha dado el salto a un nuevo entorno, que hasta ahora parecía a salvo de este tipo de amenazas: las máquinas virtuales.

Según la compañía de seguridad Symantec, Crisis puede replicarse de tres formas: creando copias de sí mismo a través de un archivo autorun.inf en un disco extraíble; en smartphones que funcionan con Windows Mobile y en las máquinas virtuales de VMware.

Symantec explica que una vez que ha infectado un ordenador, el malware busca imágenes de máquinas virtuales VMware, y si las encuentra se replica a sí mismo utilizando la herramienta VMware Player.

En realidad, no se trata de ningún fallo de seguridad del software de VMware, sino que el malware se aprovecha de una característica de las máquinas virtuales: dado que éstas consisten en archivos alojados en una máquina, dichos archivos pueden ser manipulados, incluso cuando la máquina virtual no está funcionando.

Finalmente, Symantec explica que las amenazas que conlleva este malware se frenan cuando se encuentran con una aplicación de monitorización en la máquina virtual que las analiza… Lo cual puede suponer el próximo desafío para los creadores de malware.

Fuente: Baquia

Presentan virus que infecta firmware de PC #BlackHat

julio 30, 2012 § Deja un comentario

Muchos estábamos en cierto modo preocupados por los virus convencionales, aquellos que se cuelan en nuestro ordenador e infectan nuestro sistema operativo. Puede que eso dentro de no mucho quede obsoleto y los virus acaben infectando el firmware de los dispositivos que forman parte de nuestro PC. Así lo ha demostrado Jonathan Brossard, investigador de seguridad, durante las conferencias Black Hat y Defcon.

Rakshasa [PDF con la investigación], que así se llama el invento, infectaría la BIOS del ordenador. No es el primero que hace esto; no obstante el ingenio viene en el modo en el que permanecería persistente en el sistema. Además de infectar la BIOS infectaría el firmware de los dispositivos conectados al sistema, como unidades de CD/DVD, tarjetas PCI, e incluso adaptadores de red (que recibirían un software adicional, luego explico para qué).

La cuestión es que para limpiar esta infección no sólo sería necesario reflashear la BIOS de la placa base: habría que reflashear todos y cada uno de los componentes del sistema, y en algunos casos son necesarias herramientas software/hardware específicas. De no hacer así, el malware de la unidad de CD (por poner el caso) podría reflashear la BIOS. Y para reflashear la BIOS del sistema puede no ser necesario acceso físico a la máquina: todos conocemos herramientas software que se encargan de ello.

Otro detalle interesante es que el software insertado en el firmware de la tarjeta de red tiene capacidad de realizar un arranque desde software obtenido vía red local: la versión modificada de iPXE sería capaz de cargar un bootkit (malware que arranca antes que el sistema operativo y, por tanto, antes que la mayoría de productos de seguridad). En lugar de insertar el malware en el MBR se descargaría cada vez que se encendiera el ordenador, dificultando su detección limpieza. Y no se toca un sólo byte del sistema de archivos.

Y lo más interesante de todo: una vez el bootkit realiza su función puede borrarse de la memoria RAM del sistema, de manera que un análisis en caliente tampoco serviría para detectarlo. Lo más interesante de esta clase de malware, realmente, es que es extremadamente complicado detectarlo: los productos convencionales no están diseñados (y por tanto no son efectivos) para este tipo de amenazas. Quizá las empresas de seguridad deban plantearse construir nuevos métodos para proteger nuestros sistemas.

Este malware ha sido construido en su totalidad mediante herramientas libremente disponibles en la red, open source, y por suerte no ha sido hecho público y viene a complementar el Rootkit para Mac que se presentó ayer.

Fuente: Genbeta

¿Dónde estoy?

Actualmente estás explorando la categoría rootkit en Seguridad Informática.