Wake On Lan como canal de control para Botnets

A finales del año pasado, hubo un ransomware que provocó dolores de cabeza a muchas personas en nuestra península. “Ryuk”, que así se llama ese malware, afectó a grandes empresas, a pequeñas y a particulares. Antes de empezar la beca en Telefónica dentro del equipo de Ideas Locas de Chema Alonso, me documenté sobre este ransomware en concreto,  para saber un poco mas acerca de él, de la manera por la cuál se propagaba tan rápido a través de la red, que parecía pura “magia”. 

Figura 1: Wake On Lan como canal de control para Botnets

Después de ver cuál era esa “magia” que estaba utilizando, un compañero y yo nos centramos en configurar los equipos de la empresa, para minimizar los riesgos por ese vector de propagación tanto para evitar a este bicho, sino para evitar que al siguiente que le copie el truco.

La “Magia” del vector de propagación en Ryuk

Los más veteranos seguro que se lo conocen, y si has leído las aventuras de Wardog - nuestro querido BOFH - te habrás reído hasta llorar con el uso que le dan a la función de Wake On Lan (WOL), que proporcionan la gran mayoría de tarjetas de red en conjunción con la placa base de los equipos y la BIOS.

Figura 2: El libro de "Wardog y el mundo", nuestro querido BOFH
(Bastard Operator From Hell) escrito por el propio Wardog

Esta característica permite al equipo que, aun apagado, pueda recibir un “magic packet” que provoca el arranque del equipo. Esto es lo que permite a los protagonistas de Wardog hacer muchas "cosas malas" a los compañeros de aventuras. 

Cómo funciona Wake On Lan (WOL)

Para entender cómo funciona el servicio Wake On Lan, vamos a ver en primer cómo es y cómo funciona este "Magic Packet", del que debes saber que es un paquete que funciona a Nivel de Trama o Enlace de Datos, es decir, en la Capa 2 del modelo OSI y por lo tanto no es enrutable fuera de la LAN (Local Area Network). Es decir, solo se puede enviar por la red local.

Figura 3: Modelo OSI en Wikipedia

Lo que se envía en este "Magic Packet" de WOL es un paquete broadcast, por toda la red, que lleva con contenido - como dato - una dirección MAC. El paquete mágico comienza la trama con la dirección física FF-FF-FF-FF-FF-FF, seguida de 16 veces la dirección MAC del equipo que se quiere encender. En este punto es donde entra la Tabla ARP (Address Resolution Protocol), donde cada equipo tiene una tabla donde se almacena de manera temporal las direcciones IP de las cuales conoce su MAC. Si has leído el libro de Ataques en Redes de Datos IPv4&IPv6 3ª Edición de 0xWord, la conocerás bien porque es fundamental en los ataques de Man in the Middle IPv4.

IP	MAC
192.168.1.1	d1:31:54:68:1a:db
192.168.1.3	00:31:64:68:ca:dc

Como resumen de su funcionamiento, supongamos que tenemos dos equipos en nuestra red. Uno es el equipo A y otro es el equipo B. El equipo A quiere mandar una trama al equipo B. Para ello, mirará su Tabla ARP con el fin de poner en la trama la dirección MAC del equipo B. De esta manera, los equipos a los que les llegue esa trama sabrán rápidamente si es para ellos o no, o si deben dejar pasar esa trama y no procesarla.

Figura 4: Libro de Ataques en redes de datos IPv4 & IPv6 3ª Edición

Configuración del servicio Wake On Lan

Para que ese "Magic Packet" de WOL funcione y se pueda llevar a cabo el encendido remoto del equipo se tiene que comprobar unas configuraciones, ya que en función de la BIOS viene habilitado/ deshabilitado por defecto. En mi caso para la prueba de concepto, tenemos que cambiar varias configuraciones de la placa, así que debes mirar cuál es el software de la tuya buscar estas opciones.

Figura 5: Activación de servicio Wake On Lan en BIOS

También es posible, que se tenga una contraseña en la BIOS, antes del arranque del sistema operativo, en mi caso está deshabilitado, pero es importante este apartado, ya que influye en el encendido vía WOL en los sistemas. Como os podéis imaginar, por mucho que el servicio WOL procese el Magic Packet, esta contraseña implicará la interacción manual con el usuario. 

Figura 6: Configuración de arranque con password

En otras placas también es necesario configurar las opciones de Advanced Configuration and Power Interface (ACPI) en modo S1 o S3, que dejan el equipo en modo “Stand by” mientras que la memoria será alimentada con bajo consumo. Esto suele dejar algún led encendido visible en la placa.

Una vez configurada la BIOS tenemos que comprobar las propiedades de la tarjeta de red. Desde la opción del Panel de Control de Windows/ Sistema y Seguridad / Herramientas administrativas / Administración de equipos / Administrador de dispositivos, seleccionamos el adaptador de red.

Figura 7: Opciones de Configuración de Tarjeta de Red

Una vez allí, dentro de las opciones de administración de energía del adaptador de red seleccionado encontraremos algo similar a lo siguiente:

Figura 8: Opciones de Magic Packet en Ahorro de Energía

Es conveniente para hacer uso del WOL desmarcar la casilla de que el equipo apague este dispositivo, en mi caso no es necesario, ya que eso lo controla la propia BIOS.  Por otro lado también es necesario dentro de las propiedades del controlador, habilitar las siguientes opciones:

Figura 9: Opciones del Magic Packet

La primera es para que quede a al espera del Paquete Mágico WOL. La segunda es para lo mismo, pero atendiendo a unos patrones que se especifican en ese equipo, entre ellos el paquete mágico, TCPv4 SYNC, TCPv6 SYNC y el nombre de la NetBIOS. 

Probando Wake On Lan

Una vez tenemos preparada la configuración del equipo que queremos “despertar” desde otra máquina en local, en mi caso un Ubuntu, podemos utilizar el siguiente comando para arrancar el equipo de manera remota con el servicio Wake On Lan.

etherwake -i “nombre_Interfaz_red” -p “192.168.1.0/24” “MAC_Adatador_red”.

Si conocemos la dirección IP exacta podemos sustituirla por el 0/24, si no se apoyará en la Tabla ARP para encontrar dicha dirección IP asociada a ese adaptador de red. 

Esto funciona para encender equipos remotamente, dentro de una misma red, pero si lo que se pretende es encender remotamente un equipo a través de Internet usando el protocolo Wake On Wan debemos enrutar el paquete mágico desde Internet a nuestra red LAN. 

Configuración de WOL a través de Internet

Para hacerlo funcionar, es necesario configurar nuestro router para que cuando reciba el Magic Packet, normalmente como un Datagrama UDP al puerto 7 o 9, lo enrute hacia la dirección IP del dispositivo que queramos encender. Al estar el equipo apagado, cuando el router trata de reenviar el paquete mágico a la dirección IP del equipo destino, no hay nadie que le conteste diciendo “yo tengo esa dirección IP” en la resolución ARP, con lo cual, el router no sabrían cuál es la dirección MAC a donde debe reenviar el paquete.

Esto se soluciona añadiendo en la Tabla ARP del router una entrada manual y estática con la información del equipo al que se quiere habilitar WOL desde Internet. Cómo la Tabla ARP por defecto es dinámica, y se mantiene viva, únicamente almacena las asignaciones de conexiones más recientes. Esto quiere decir que aunque la introduzcamos a mano se borrará al cabo de un tiempo - salvo si la damos de alta como entrada estática -, o se borrará en el siguiente reinicio del router.

Figura 10: Enviar Magic Packet WOL vía Internet

Para solventar esto, será necesario configurar la entrada en el archivo de inicio del router, para que cada vez que se encienda, se cargue el comando con los parámetros anteriores nuevamente en la Tabla ARP. Es posible configurar entradas ARP estáticas, a través del modificador “arp –s”, no obstante, igualmente solo será válida hasta que se reinicie el router, por lo cual seguirá haciendo falta añadir esa línea en un archivo de inicio por lotes para dotar esta entrada en la Tabla ARP de persistencia en el router. 

El último problema que debemos resolver es la dirección IP de nuestro router, a la que debemos enviar el paquete mágico. Si se trata de una dirección IP fija, no hay problema, pero si nuestro proveedor de Internet, nos la cambia a menudo, se trata entonces de una dirección dinámica, que es lo habitual. 

Si esto es así, para no perder el rastro no nos queda otra que utilizar el servicio de un DNS Dinámico, como puede ser “DynDns”, que es gratuito y permite definir un dominio que apunte y mantenga constantemente la dirección IP de nuestro router, por mucho que ésta cambie. Una vez tenemos todo configurado podremos utilizar una web como depicus para despertar nuestro equipo remotamente a través de Internet. 

Notas Finales

Como conclusión esta función es muy útil en ciertos aspectos, si se necesitan encender todos los equipos de una red para hacer alguna gestión en ellos, o se necesita en un momento concreto tener disponibilidad del equipo para trabajar remotamente y no tenerlo encendido siempre. Y esto, para los responsables de grandes plantas de equipos y servidores físicos en  Data Centers puede ser de gran utilizad. Pero...

...pero si no tienes un uso claro de este servicio, ten en cuenta que es una característica que las Botnets de malware pueden utilizar para tener la persistencia que necesitan y realizar ataques a tu organización in que lo sepas. Cuando no haya nadie en la oficia y los equipos estén apagados arrancan el equipo que quieran, se arranca su malware en el equipo, y hacer las acciones maliciosas que necesiten en tus sistemas.

Figura 11: Libro de  Máxima Seguridad en Windows Gold Edition
escrito por Sergio de los Santos

Así que, como recomendación de seguridad, si no es estrictamente necesaria esta utilidad, es conveniente  dentro de las opciones de fortificar tus equipos Windows, verificar que por defecto está deshabilitado el “Magic Packet” en el adaptador de red, y así reducimos un vector de riesgo que pueda ser, o esté siendo, utilizado por un malware.

Autor: Víctor Rodríguez Boyero, Security Researcher en el equipo de Ideas Locas de Telefónica

Proteger Windows con "Máxima Seguridad en Windows"

Había pasado mucho tiempo desde que se agotó el libro de Máxima Seguridad en Windows, y como es uno de los más solicitados, desde 0xWord hemos estado trabajando para tener en el catálogo una nueva edición de este título. En él, Sergio de los Santos (@ssantosv) saca el máximo de todas las tecnologías de seguridad del sistema operativo para tener, como dice el título, Máxima Seguridad en Windows. El libro está disponible desde hoy mismo en la web de 0xWord, y además ya está también incluido dentro de la Colección Completa de 0xWord.

Figura 1: Libro Máxima Seguridad en Windows 3ª Edición

El texto de esta edición es más o menos similar al de las ediciones anteriores, y solo se han cambiado pequeñas partes del mismo, añadiendo algunas nuevas utilidades que han aparecido en los últimos tiempos, y algunas soluciones para evitar problema con malware, como el desgraciadamente popular ransomware que tanto daño ha estado haciendo en los últimos tiempos. Este es el índice detallado del libro.

Fígura 2: Máxima Seguridad en Windows: Índice

Si administras sistemas Windows en una empresa, o si tu equipo personal de trabajo de día a día es un sistema Microsoft Windows, los contenidos de este libro son sin duda fundamentales para tener lo más protegida posible tu plataforma.

Saludos Malignos!

SSDT Hooking V2

Cuando hablamos de rootkits hablamos de los internals, del kernel, hablamos de las tripas del sistema operativo (Microsoft Windows y arquitectura x86 en el caso que nos ocupa), y hablamos de la modificación de su flujo y alteración de su comportamiento sin pérdida de funcionalidad; todo ello, claro está, efectuándose de un modo oculto y silencioso.

Alterar la SSDT (System Service Descriptor Table) es uno de los métodos de hooking más empleados por rootkits comunes, sin olvidarnos de la mayoría de antivirus del mercado. Sencillamente se modifican o intercambian entradas en esta tabla indexada y así se altera el comportamiento del sistema. No obstante, dicha tabla se encuentra en una zona de la memoria con permisos read-only y se requiere habilitar el permiso de escritura antes de su modificación.

The Rootkit Arsenal detalla dos formas de realizar esta operación, y si queremos olvidarnos de la segunda (basada en Memory Descriptor List’s o MDL’s, técnica que ya habían descrito con claridad Greg Hoglund y James Butler en “Rootkits: Subverting the Windows Kernel”), estamos en todo nuestro derecho.

La primera técnica, como decíamos, se basa en deshabilitar el WP bit (Write Protection bit) del registro de procesador CR0. Intel nos dice que si este bit es igual a 0, cualquier código en el kernel (Ring 0) tiene acceso de lectura/escritura en todas las páginas de memoria. Lo curioso de esta técnica es que el registro CR0 puede modificarse mediante instrucciones assembler igual que cualquier otro registro de operación básico.

PUSH EBX
MOV EBX, CR0
AND EBX, 0XFFFEFFFF
MOV CR0, EBX
POP EBX

Analicemos por qué todo esto es necesario:

lkd> dps nt!KeServiceDescriptorTable
82daf9c0 82cb66f0 nt!KiServiceTable
82daf9c4 00000000
82daf9c8 00000191
82daf9cc 82cb6d38 nt!KiArgumentTable

KeServiceDescriptorTable es un array de cuatro estructuras que contienen 4 valores DWORD. La primera dirección apunta directamente a la SSDT, el tercer DWORD (0x191) nos indica la cantidad de funciones que contiene la SSDT. Veamos algo acerca de la página en la que se aloja la SSDT:

lkd> !pte nt!KiServiceTable
VA 82cb66f0
PDE at C06020B0 PTE at C04165B0
contains 00000000001D2063 contains 0000000002CB6121
pfn 1d2 ---DA--KWEV pfn 2cb6 -G--A--KREV

Como se puede ver en (-G--A--KREV), la página pertenece al kernel (K) y tiene permisos de sólo lectura (R).

Ahora viene lo bueno. La alternativa que yo planteo en este artículo es la de modificar la SSDT sin tener que habilitar los permisos de escritura en la memoria. ¿Cómo puede ser esto posible? Si observamos la página sobre la que se asienta KeServiceDescriptorTable obtenemos lo siguiente:

lkd> !pte nt!KeServiceDescriptorTable
VA 82daf9c0
PDE at C06020B0 PTE at C0416D78
contains 00000000001D2063 contains 0000000002DAF963
pfn 1d2 ---DA--KWEV pfn 2daf -G-DA--KWEV

Como vemos en (-G-DA--KWEV), esta zona de memoria sí tiene permisos de escritura (W). ¿Cómo podemos aprovechar esta situación? Pues la solución pasa por crear una nueva SSDT y sobrescribir la dirección de la KiServiceTable original por la nueva. Para ello, lo que hacemos en el código es ver el número de API's que contiene la SSDT original y reservar un espacio de memoria adecuado para la nueva SSDT:

newSSDT = ExAllocatePool(NonPagedPool, nCalls * sizeof(DWORD));

Imaginemos que la dirección devuelta es 0x8537b9b8, veamos los permisos de la página:

lkd> !pte 8537b9b8
VA 8537b9b8
PDE at C0602148 PTE at C0429BD8
contains 000000007F70F863 contains 000000007F37B963
pfn 7f70f ---DA--KWEV pfn 7f37b -G-DA--KWEV

Como siempre, perteneciente al kernel (K) y escribible (W). Lo siguiente es hacer una copia de todas las direcciones de las API contenidas en la SSDT original en la nueva, al tiempo que hookeamos la API elegida:

for ( i = 0; i < nCalls; i++ ) {
if ( i == idx )
newSSDT[i] = newApi;
else
newSSDT[i] = GetSSDTEntry(i);

Ahora sólo nos queda modificar el primer DWORD de KeServiceDescriptorTable con la dirección de la nueva SSDT:

oldSSDT = GetSystemCallTable();
serviceDesc = &KeServiceDescriptorTable;
serviceDesc->KiServiceTable = newSSDT;

Y ya lo tenemos hecho. El módulo o driver puede cargarse de múltiples formas, el programa OSR Loader es lo más sencillo para la etapa de pruebas (sc y métodos de inyección deben ser utilizados por rootkits funcionales). En la siguiente figura utilizamos Windbg para revelar el contenido de KeServiceDescriptorTable antes y después de la creación y sustitución de la nueva SSDT.

Figura 1: Contenido de KeServiceDescriptorTable antes y después

DebugView es la utilidad perfecta para mostrar los resultados de nuestra técnica:

Figura 2: Resultados obtenidos

¿Qué ventajas puede tener este método?

1) Por un lado guardamos la dirección de la SSDT original intacta. Para dejar el sistema como estaba no hace falta unhookear cada API una por una, sino tan sólo modificar otra vez el primer DWORD en KeServiceDescritorTable con la dirección de la SSDT original. 

 2) En ningún momento modificamos el registro CR0 y por lo tanto cualquier código inmerso en el kernel chequeando este valor de forma periódica es evadido. 

3) Imagine un código antirootkit que haya obtenido la dirección de la SSDT original, y la mantenga almacenada como un valor estático, cada vez que acceda a esta dirección de memoria y compruebe las direcciones de las API's contra una copia no alterada no descubrirá cambio alguno en la tabla.

Muestro a continuación el código completo que hace hooking sobre la API ZwSetValueKey() siguiendo la metodología descrita en esta sección.

Figura 3: Código de HookSSDT.c en la cuenta de Chema Alonso en SlideShare

Queda a tu elección qué mecanismo usar, esta es tan sólo una alternativa que me ha parecido relativamente más sencilla y que puede ofrecer alguna que otra ventaja. Aunque, al igual que el modo descrito en The Rootkit Arsenal puede ser fácilmente detectable. En este caso no habría que comprobar todas las API's sino tan sólo comparar el valor introducido en KeServiceDescriptorTable con el original previamente almacenado. Por supuesto comprobar que las entradas de la SSDT no apuntan a la memoria propia de “ntkrnl*.exe” es una técnica común.

Feliz Hacking!

by blackngel (blackngel@blackbycode.com)
Autor del libro "Linux Exploiting"

Una buena política anti-malware debe buscar en el pasado

Hace poco me preguntó uno de los alumnos del Master de Seguridad de la UEM una cuestión con la que yo me había topado hace ya tiempo en un proyecto con un cliente y que había resuelto de una forma peculiar. Como nunca había hablado de esto por aquí me he decidido a escribirlo por si a alguien le viene bien implementarlo en su empresa. El problema en cuestión es tan sencillo de exponer como "¿Cómo detectar un malware en tu sistema?".

Las soluciones habituales cuando se tienen un equipo solo pueden ser las habituales en equipos Mac OS X o en equipos Windows, pero si nos enfrentamos a un Évola Asesino, - o al español Careto -mejor tener una buena estrategia a nivel global.

El Évola Asesino vive en tu red

Supongamos un poderoso malware al que llamaremos Évola Asesino con capacidades de rootkit y que está siendo controlado remotamente por un equipo profesional de atacantes se ha colado en tu red. El malware, como hacen los bots de última generación viene preparado para defenderse no solo de los sistemas de seguridad, sino también de otros programas maliciosos que pudieran existir en el mismo equipo.

Además de esas protecciones, tiene controladas todas las llamadas a la API del sistema operativo para evitar la detección por parte de las herramientas antimalware, interceptando las llamadas que le interesan y las que no le interesan para evitar levantar sospechas.

Esto les permite que cuando se hacen listados de ficheros en carpetas, servicios, o cualquier otra llamada a la API del sistema operativo, el rootkit pueda ocultar su presencia en los resultados. También cuando detecta que se está utilizando alguna técnica de detección de rootkit que busca localizar diferencias entre los resultados devueltos por las llamadas a las API y los que se puede obtener accediendo en bruto, deciden no ocultarse y confundir más a las herramientas.

Además, este poderoso malware cuenta con una buena estructura detrás y muta continuamente para dificultar la generación de firmas por parte de los laboratorios de las casas antimalware. Para ello han creado un sistema curioso para protegerse y en un entorno similar a Virus Total analizan continuamente los bots con todos los motores antivirus. En el momento en que ven que un Antimalware detecta los bots como software sospechoso, mutan el código del malware y actualizan todos los equipos infectados con una nueva versión indetectable en tiempo record.

¿Cómo se podría detectar al Évola Asesino?

Cuando se me planteó esto hace tiempo llegué a la conclusión de que una buena política contra este tipo de ataques debería tener una estrategia de análisis de malware en el pasado. Es decir, que la base de datos de firmas actualiza de todos los motores de antivirus debería revisar no solo el entorno actual, sino también el entorno que habíamos tenido en el pasado. Las recomendaciones que hice en aquel entonces, además de aplicar todas protecciones en tiempo real en los puntos de conexión externa con el sistema, fueron:

1) Tener copias de seguridad completas del disco completo de equipos seleccionados de la red para poder hacer escaneos offline de los sistemas. Esto está pensado para conseguir evitar el que un malware con capacidades de rootkit logre eludir la detección manipulando las respuestas de la API tal y como hace cuando se encuentra con el sistema online. Así, las versiones de Évola Asesino que haya se irán con ellas.

Figura 2: Ejemplo de copias de seguridad completas datadas con su versión del Évola Asesino

2) Escanear las copias de seguridad del pasado con las nuevas firmas. Muchas veces las casas de antivirus añaden firmas de malware que ha estado circulando por Internet y las redes de las empresas durante mucho tiempo, así que puede que en el pasado lo tuvieras. Además, si el malware hubiera mutado para no ser detectado, no lo podría haber hecho en la copia de seguridad almacenada.

Figura 2: Ejemplo de actualización de firmas y detección de versiones del Évola Asesino

3) Escanear las copias de seguridad de los equipos con todos los antimalware posibles. No es recomendable por precio y por usabilidad tener varias soluciones antimalware en los equipos de trabajo, pero tener una licencia de muchos antimalware para escanear copias de seguridad del pasado, es económicamente barato para una empresa y funcionalmente cómodo. Se podría tener un servidor escaneando constantemente copias de seguridad de equipos para detectar firmas de malware en el pasado.

Figura 3: Cuando se iría descubriendo cada versión del bot

4) Escanear las copias de seguridad de equipos con distribución geográfica y temporal. Es decir, hacer el proceso con equipos significativos de cada maqueta de ellos que haya en la red de la organización y hacerlo con diferentes copias temporales.

Conclusiones

Al final, con una estrategia como esta podrás sacar mucho conocimiento de cómo hay ido evolucionando la seguridad de tu organización y descubrir posibles infecciones hechas por algún Évola Asesino u otro similar, además de que podrás encontrarte con brechas de seguridad no conocidas hasta el momento. Si por el contrario no haces esto, el malware Évola Asesino podría permanecer indetectable durante años en tus sistemas hasta que perdiera una carrera con tu software antimalware. No es lo suyo jugárselo todo a una carta.

Como dice Sergio de los Santos (@ssantosv) en su libro de Máxima Seguridad en Windows, un antimalware no es suficiente para una amenaza como la del Évola Asesino y hay que hacer más cosas en el sistema, pero una buena estrategia te puede ayudar a mejorar la ayuda que te pueden dar estas tecnologías. Si tienes esas copias de seguridad hechas, ahora podrías saber si tuviste un Careto en tu red en algún momento.

Saludos Malignos!

Android.Oldboot: Primer Bootkit para Android

Hoy la noticia que más me ha sorprendido ha sido la que parece primera aparición en escena de un bootkit para los terminales Android, lo que abre la puerta a un panorama mucho más peligroso para los terminales con este sistema operativo y el malware, ya que si no se controlan bien en las tiendas de apps, esta moda puede ser más que peligrosamente aprovechada por apps maliciosas del tipo de la linterna molona o el juego de Android que vende tus WhatsApps que quieran generar dinero en la industria del fraude online.

Tras la proliferación del malware instalado a nivel de kernel como drivers, los fabricantes de sistemas operativos decidieron prohibir la instalación de drivers a nivel de kernel que no estuvieran firmados digitalmente por una entidad autorizada.

Figura 1: Error de intento de carga de driver no firmado en un Windows

Eso hizo que los creadores de malware crearan los bootkits, un software que funciona como un sistema operativo reducido a su mínima expresión con la única misión de buscar el kernel del sistema operativo, parchearlo para anular la verificación de la firma digital del los drivers, e instalar el rootkit a nivel de kernel con tranquilidad, antes de arrancar definitivamente el sistema operativo de la víctima - ya infectado -.  Aquí os publiqué un ejemplo en el que Blackngel - autor del libro de Linux Exploiting -hacía algo algo similar con un sistema operativo, pero con el objetivo de hacer un ataque de fuerza bruta.

Para conseguir hacer todo ese proceso, los bootkits necesitan ponerse antes en el proceso de arranque, así que modifican el famoso MBR (Master Boot Record) del disco duro del sistema para conseguir el control total de la máquina de la víctima. Como contramedida a los bootkits, la industria decidió apostar por el firmado digital del Master Boot Record y la comprobación del mismo desde el firmware UEFI del equipo, lo que se llamó SecureBoot y hace que antes de instalar un nuevo sistema operativo en un hardware sea necesario tenerlo firmado digitalmente por el fabricante - como hizo Microsoft con el loader de Linux -.

Ahora Dr. Web ha anunciado que ha descubierto un malware, al que ha denominado Android.Oldboot que se distribuye mayoritariamente en China como un bootkit. Para ello se aprovecha de apps maliciosas que instalan el bootkit, y en el siguiente reinicio se carga el rootkit que toma control total del sistema.

Figura 2: Android.Oldboot publicado por Dr. Web

Esto en Android es especialmente complicado de controlar, ya que la dispersión de hardware hace que sea complicado asegurarse de que todos los terminales con Android tienen la protección contra la manipulación del proceso de arranque.  Además, el proceso de cifrado de disco completo de Android es algo que se hace antes de que el sistema arranque, así que lo que hace el bootkit es cargarse en el inicio, pero después de que se haya descifrado el disco, por lo que no le afecta para nada si el terminal está cifrado o no.

Figura 3: El SecureBoot Activado en un firmware de dispositivo

Controlar el proceso de arranque en terminales Android es algo que se persigue desde hace tiempo, pero muchos terminales vienen con el Secure Boot deshabilitado y otros muchos usuarios lo deshabilitan de forma manual para instalar determinados mods de firmware en sus dispositivos.

Una fiesta para controlar todos que puede dar mucho juego al mundo del e-crime, que podría portar sus famosos ransonwares a un secuestro total del terminal, obligando a pagar a la gente si quiere volver a recuperar el control de su dispositivo, o podría también crear troyanos para espiar Android que sean más difíciles de detectar y tengan más poder dentro de todo el terminal o evolucionar los Rogue AV de Android a sistemas mucho más peligrosos.

Saludos Malignos!

Linux/Chapro.A un módulo de malware para Apache

El mundo del malware destinado al fraude online y/o e-crime no para de adaptarse para buscar nuevas formas de infectar equipos, y hacerlo desde servidores web es algo de lo más común desde hace ya más de un lustro usando kits de explotación, como el archifamoso Black Hole. La idea es sencilla, desde un servidor web comprometido - si es popular como la web del sistema postal americano mejor - lanzar un exploit que afecte al software de un cliente que se conecta e inyectar un bot para controlar la máquina desde un panel de control. Sencillo y funcional, así que se sigue haciendo.

Figura 1: Aspecto de un panel de control de Black Hole

Una de las primeras formas de conseguir comprometer los servidores web han sido los bugs de aplicación tipo SQL Injection, RFI, o incluso XSS persistentes para lanzar el exploit a los clientes. Sin embargo no se quedaron ahí, y los bugs en gestores de contenidos populares de blogs, CMS, etcétera, pasaron a ser de los más utilizados - que se lo digan a WordPress, Joomla e incluso a los Moodle -. Con este tipo de ataques se realizaron campañas de infección masiva usando los buscadores - llegando a infectar sitios de renombre como Apple.com en operaciones como Lizamoon -.

Figura 2: La web de Apple fue infectada en un ataque SQLi masivo para distribuir malware

Sin embargo, las cosas no se quedaron ahí y han evolucionado hasta aprovechar cualquier punto de apoyo para conseguir lanzar los exploits desde los servidores web. En el caso de Linux, aparecieron cosas como Linux/Snakso.A, un rootkit a nivel de kernel que modificaba las páginas web enviadas desde servidores nginx o Apache para añadir un iframe que apuntaba al kit de exploits.

El último que ha salido a la primera plana de actualidad en el mundo del e-crime es Linux/Chapro.A, un malware en forma de módulo malicioso de Apache pensado para infectar con un iframe que apunta a un kit de exploits en todas las páginas que sirve el servidor web infectado para instalar bots de Zeus en los clientes que se infecten.

Figura 3: Esquema de Linux/Chapro.A

En este caso en concreto, el kit de exploits que se estaba utilizando era Sweet Orange que, por supuesto, tiene malware y exploits disponibles para equipos con sistemas operativos Windows, Mac OS X y Linux.

Figura 4: Kit de exploits Sweet Orange

Esta idea de utilizar un módulo malicioso de Apache no es nueva, y de hecho se usan como manera de mantener un servidor troyanizado después de una intrusión, como es el caso de mod_rootme, del que ya os hablé por aquí. Si quieres revisar los módulos cargados en tu Apache, en el artículo de Fortificar Apache tienes los comandos para revisar los módulos cargados en tu servidor web.

Saludos Malignos!

La ciberguerra del rootkit, la caricatura y los agentes secretos de Facebook

Pensar que los ejércitos y los servicios de inteligencia están dejando de lado el uso de las tecnologías de la información y el uso de técnicas hacker para sus labores “del día a día”, es como pensar que una banda terrorista no va a hacer uso de un sistema informático vulnerable para sus objetivos. Es un campo de batalla que existe y con muchas ventajas si vas por delante.

No es de extrañar lo que ha puesto de manifiesto el grupo anonym0us liberando los mails de HBGary que, de nuevo en Ars Technica, publican en un genial artículo sobre cómo el gobierno utiliza Backdoors.

Task B

Los mails obtenidos en el “pwned magistral” de anonym0us han permitido hacer un recorrido de los sistemas para controlar, espiar y atacar al enemigo que HBGary estaba ofertando al gobierno. Todo comenzó con un proyecto llamado Task B en el que se buscaba crear un troyano que permitiera controlar un equipo utilizando los puertos de un equipo (ratón, USB, etcétera) en entornos donde se pudiera tener acceso físico al equipo durante unos minutos.

La idea tras esto, era instalar un rootkit, del que hay hasta una hoja de características que se estaba ofreciendo a los cuerpos de seguridad y que también ha sido publicada.


Figura 1: Hoja de características del rootkit que se comercializaba

Proyecto 12 monkeys

Por supuesto, la cosa evolucionó a lo que todos desde hace tiempo sabemos: La compra de inteligencia con fines militares, o lo que es lo mismo la compra de exploits 0-day que pudieran ser utilizados para explotar las máquinas del enemigo e instalar troyanos, así, HBGary estaba vendiendo kits de exploits, al estilo de Black Hole o Eleonore II, pero para fines militares con los siguientes exploits.

VMware ESX and ESXi
Win2K3 Terminal Services
Win2K3 MSRPC
Solaris 10 RPC
Adobe Flash
Sun Java
Win2k Professional & Server
XRK Rootkit and Keylogger
Rootkit 2009

Recuerdo que hace unos años se habló durante un tiempo de un exploit de VMware para ejecutar código remotamente que luego desapareció...¿será este el destino que tuvo ese 0day?

Caricaturas

Otro de los servicios que estaba ofreciendo consistía en hacer guerra de información viral por medio de caricaturistas puestos a sueldo del gobierno que, al estilo de las guerras de los equipos de marketing, estaban realizando dibujos para que fueran distribuidos por Internet transmitiendo una idea de forma “graciosa” para conseguir que así se difundiera mucho más rápidamente. Es decir, sería como poner el equipo de El Jueves a sueldo del gobierno. La sola idea hace que me tiemblen las canillas.


Figura 2: Caricaturas contra IRAN
Agentes espías en Facebook

Una de las características que más me ha llamado la atención es el servicio de generación de perfiles en Facebook para controlar personas y grupos. Me imagino a un equipo de trabajo controlando a 100 “agentes secretos de Facebook” y decidiendo si empujar o alentar revoluciones en un país mediante la convocación de manifestaciones o si, simplemente, robar información a usuarios.

Está claro que la guerra entre los países ha cambiado y las operaciones de inteligencia y militares están haciendo uso de este campo de batalla. ¿Y tú, conoces a todos tus amigos de Facebook? ¿Aún crees que esto es ciencia ficción?

Saludos Malignos!

Cómo crear un "proxy" de DLLs en .NET

En este artículo se verá cómo crear un proxy de DLLs entre una aplicación y una DLL original desarrolladas en .NET. Dicho de otro modo, se introducirá un código intermedio entre una aplicación y sus librerías pudiendo interceptar y modificar tanto las llamadas que realiza la aplicación a las DDLs así como las respuestas que estas retornan a la aplicación.


Figura 1: Arquitectura de la aplicación "proxy dll"
Para llevar a cabo esta prueba de concepto, crearemos una DLL muy sencilla con dos métodos que nos devolverán el valor del atributo ‘nombre’, en este caso ‘DLL ORIGINAL’.


Figura 2: Código fuente de la DLL original
A continuación se muestra el código de la aplicación que hará uso de dicha DLL, el cual únicamente hará dos llamadas a los métodos de la DLL y los mostrará por pantalla.


Figura 3: Código fuente de la aplicación que llama a la DLL
De este modo, el resultado de la ejecución normal de la aplicación sería la siguiente:


Figura 4: Resultado tras una ejecución normal
Ahora que tenemos el objetivo a atacar compilado (Aplicación + DLL), procederemos a realizar un análisis a modo de caja negra de la DLL, ya que para introducir nuestra DLL (Proxy) entre la aplicación y la DLL original, tendremos que implementar todos los métodos y atributos que tenga la original.

Para ello utilizaremos la aplicación Reflector, el cual muestra la estructura de un ensamblado .NET. En la siguiente captura se ve marcado de color verde los métodos públicos existentes - los privados tienen un candado como icono -, los cuales son los únicos que nos interesan, puesto que son los únicos que serían accesibles por la aplicación, y sobre los cuales habría que llevar a cabo la intercepción de las llamadas.


Figura 5: Apertura de la DLL con Reflector
Una vez tenemos el objetivo fijado, deberemos modificar su ‘NameSpace’ (dlloriginal), ya que si no habría conflictos de acceso con la DLL que estableceremos como proxy, debido a que tendría el mismo ‘NameSpace’ que la original. Esta modificación podemos realizarla a través de un editor hexadecimal, remplazando la cadena ‘dllOriginal’ por ‘dllOrigina2’, y guardando el fichero como ‘dllOrigina2.dll’.


Figura 6: Modificación del namespace
De este modo, el estado actual de los ficheros serían, la aplicación junto a la DLL original, a la cual le hemos modificado el ‘NameSpace’.

Ahora es el momento de desarrollar el código de la DLL que funcionará como proxy, la cual deberá implementar los métodos que se obtuvieron mediante ‘Reflector’ y deberá tener una referencia a ‘dllOrigina2’, como se ve en la siguiente captura:


Figura 7: Métodos a implementar
Los métodos que esta debe implementar deben ser todos los que disponga la DLL original, y el código de cada uno de ellos ya depende de la funcionalidad que se le quiera dar, desde ideas beneficiosas como la mejora de determinadas funciones, como la curiosidad de conocer los datos internos de cada llamada, o hasta la inclusión de una puerta trasera que se active al recibir determinado valor a través de los atributos de una llamada a una función.


Figura 8: Código fuente de la nueva DLL
Ya solo es necesario copiar la DLL que actúa como proxy en el mismo directorio que la aplicación, y con el nombre ‘dllOriginal.dll’.


Figura 9: Ejecución con intercepción de llamadas a DLLs
Autor: Manu "The_Sur"

Asegúr@IT III : Online

Cracking & Protección de Software
Mikel Gastesi [S21Sec]

Asegúr@IT III - Técnicas de protección de Software y Cracking

View SlideShare presentation or Upload your own. (tags: seguridad cracking)

Rootkits: Memory Subverting
Iñaki Etxeberria [Panda Security]

Asegúr@IT III - Rootkits: Memory Subvertion

View SlideShare presentation or Upload your own. (tags: iñaki etxeberría)

Tempest: Mitos y Realidades
Pablo Garaitzar "Txipi" [Universidad Deusto]

Asegúr@IT III - Tempest: Mitos y Realidades

View SlideShare presentation or Upload your own. (tags: tempest security)

Network Access Protecction (NAP)
Juan Luís Rambla [Informática64]

Asegúr@IT III - Network Access Protection (NAP)

View SlideShare presentation or Upload your own. (tags: juan luís)

Ataques Masivos SQL Injection
David Carmona [Spectra]

Asegúr@IT III - Ataques SQL Injection masivos

View SlideShare presentation or Upload your own. (tags: botnets server)

Saludos Malignos!

Asegúr@IT III - La Previa

Hola seres y estares, ya llega el veranito, y antes de que os vayáis de vacaciones, os quemeís como gambas en la playa, engordéis un par de kilos más que no os quitaréis con facilidad y vengáis más cansados que lo que os fuísteis, os voy a dejar en la agenda un evento GRATUITO que hemos montado en Bilbao. Es el Asegúr@IT III en Bilbao, esta vez, bajo el paraguas de Spectra Technet, en la sede de la Universidad de Deusto, con la participación de S21Sec, de Panda Security por primera vez e Informática64.

- Los ponentes: Mikel Gastesi, Iñaki Etxeberría, Pablo Garaizar, Juan Luís Rambla y David Carmonix.

- El lugar: Bilbao, Universidad de Deusto.

- El Cuando: El día 25 de Septiembre de 2008.

La agenda

09:00 - 09:15 Registro

09:15 - 10:00 Cracking & protección de software

La disciplina de cracking software tiene mucho que ver con la protección de software. En esta sesión Mike Gastesi, de S21Sec, contará cuales son algunas de las técnicas utilizadas para la decompilación y crackeo de software y al final dará algunas recomendaciones para proteger el software contra este tipo de técnicas.

10:00 - 10:45 Rootkits in Action

La técnología rootkit llego ya hace unos años para quedarse con nosotros. En esta sesión Iñaki Etxeberría, de Panda Security, contará como funcionan hoy en día los rootkits, cuales son sus objetivos y cómo podemos protegernos de ellos.

10:45 - 11:15 Café

11:15 - 12:00 Tempest, mitos y realidades

La tecnología Tempest ha dado mucho que hablar. La posibilidad de interceptar la información generada en un equipo mediante la intercepción de las ondas radiadas por los dispositivos electrónicos ha sido utilizada en múltiples novelas y películas de ciencia ficción. No obstante, las técnicas tempest existen y funcionan con unas características. En esta sesión Pablo Garaizar, Txipi, de la Universidad de Deusto mostrará que es mito, que es realidad y hará algún ejemplo de estas técnicas.

12:00 - 12:45 Network Access Protecction

La protección de las redes en entornos en los que los trabajadores utilizan dispositivos móviles para conectarse (portátiles, pdas, teléfonos móviles) necesitan comprobar la salud de los equipos que se conectan a la red. Windows Server 2008 y Windows Vista incorporan NAP, una tecnología que permite controlar la salud de los equipos que se desean conectar a la red. Juan Luís Rambla, MVP de Spectra en Windows Security de Informática 64 realizará una demostración de como implantar esta tecnología.

12:45 - 13:30 Protección contra Botnets desplegadas por Web

Las técnicas de expansión de las redes botnets van cambiando día a día buscando nuevos métodos de infectar máquinas. Actualmente una de las disciplinas utilizadas consiste en atacar máquinas través de sitios web legítimos vulnerados mediante fallos de programación. David Carmona, Evangelista de Spectra desgranará como funcionan estas nuevas formas de despliegue y dará pautas para protegernos contra ellas.

13:30 - 14:00 Preguntas a los ponentes

Apúntate en esta URL: Asegúr@IT III en Bilbao, 25 de Septiembre de 2008

Saludos Malignos!