(Español) Banner + CPE = Vulnerabilidades offline

# De qué va este post?

En este post hablaremos de la identificación de plataformas informáticas y su correlación con CPE (Common Platform Enumeration).

# Identificación: Porqué es importante?

En cualquier auditoría de seguridad que se precie, la identificación del sistema a auditar es el primero de los pasos a llevar a cabo.

Los resultados obtenidos durante ese proceso, condicionarán en gran medida el trabajo que hagamos a posteriori.

# Cómo solemos identificar un sistema?

Existen muchas formas de enumerar e identificar la plataforma de un sistema (cuando hablamos de un sistema, nos referimos a uno al que no tenemos acceso local).

El método más común y sencillo de identificar un sistema, suele por el banner que podemos obtener de éste. En la imagen podemos ver el banner de un servidor web:

banner

Aunque es muy fácil de falsear el banner que devuelve un servicio o sistema (eso es harina de otro costal, de lo se podría escribir un libro entero), para este post asumiremos que el resultado obtenido es el real.

# ¿Para qué podemos usar este banner?

Una vez identificado el sistema, ya podemos encauzar nuestros ataques de una forma más afinada: No es lo mismo atacar un Apache, que un nginx o un IIS.

# La ‘IP’ de las plataformas

Hasta aquí, nada nuevo. Vamos a ver, qué otras cosas útiles podríamos hacer con este banner:

Al igual que la identificación de un host en una red se hace por su IP (abstenerse los puretas, se que hay más métodos de identificación :-P ), las plataformas de un sistema informático se pueden definir de forma única mediante su CPE.

# Qué es el CPE?

El CPE (http://cpe.mitre.org) es el método para identificar de forma inequívoca una plataforma. La base de datos es con todas las plataformas es gratuita y se puede descargar de: http://nvd.nist.gov/cpe.cfm

Si nos descargamos el XML de la última version (2.3) y echamos un vistazo, podemos ver algo como:

cpe:/a:igor_sysoev:nginx:1.4.2

Esta cadena conformaría el CPE para el banner de la imagen expuesta más arriba.

# Quien usa CPE?

Actualmente existen varias bases de datos de vulnerabilidades públicas, pero tal vez la más conocida sea la del NIST: http://nvd.nist.gov/download.cfm

Si descargamos y abrimos el fichero XML, podemos ver cómo a cada vulnerabilidad se el asocia un CPE. Esto es así porque es la manera más estándar de identificar un sistema de forma única.

# Porqué es útil el CPE?

Con lo expuesto arriba, podemos sacar una conclusion rápida: Si tenemos el CPE de un sistema, podemos obtener sus vulnerabilidades publicadas, de una forma muy rápida. Tan rápida como buscar en el XML.

# Problemática

Cual es el principal problema para hacer esto: Que hay que hacerlo de forma manual.

Los banners prácticamente nunca suelen coincidir con su texto descriptivo del CPE. Esto es así porque, normalmente, se suele añadir en el propio banner la plataforma, módulos de compilación, etc.

Debido a esto, no es nada trivial automatizar la búsqueda de vulnerabilidades a partir de un banner. O si….?

# Conversión: Banner -> CPE

## ¿Qué pasaría si pudiéramos obtener un CPE, a partir de un banner?

Fácil, que podríamos automatizar la búsqueda de vulnerabilidades de una plataforma y hacerlo en offline, con un porcentaje de error bastante bueno.

## ¿Cómo lo hacemos?

Como dice un colega: “cuando el diablo se aburre…”. Pues eso, que nos da por maquinar :)

Precisamente por lo explicado en este post, publiqué una librería llamada “info2cpe” que trata de hacer la conversión entre un banner y su CPEhttps://github.com/cr0hn/info2cpe

Aunque la librería todavía está en beta, funciona bastante bien para banners de servidores web.

Como se puede ver en la ayuda, podemos usar “info2cpe” como librería o por linea de comandos.

## Ejemplo: Convirtiendo un banner en CPE

Tras descargar la librería y obtener un banner de “por ahí”, tratamos de identificar un “”Microsoft IIS httpd 7.5″:

found

No está mal del todo, no? :-P

## Automatización

¿No sería genial, que hubiera una herramienta que “automágicamente” buscara vulnerabilidades en sistemas remotos usando este método?

No se a vosotros, pero a mi me vendría de perlas :)

Como buenos “juaquers” amantes de la automatización, por su puesto trataremos de hacer todo esto de forma automático. ¿Cómo y donde? Como no podía ser de otra forma, dentro de muy poco lo integraremos en nuestro querido GoLismero :)

Versión testing: https://github.com/cr0hn/golismero

Versión estable: https://github.com/cr0hn/golismero

## Por hacer

Soy consciente de que la librería está verde todavía y requiere mucho trabajo todavía. Estoy en ello, con la ayuda de todo aquel que se anime a echar un mano con cualquier idea y/o sugerencia.

# Sobre mi

Bueno, aquí un poco de spam mío :-P

Twitter: https://twitter.com/ggdaniel

Portfolio genérico: http://www.cr0hn.com/

 

Share via email
Share on Facebook+1Share on Twitter

III Conferencias de seguridad Navaja Negra

Sorry, this entry is only available in Español.

Share via email
Share on Facebook+1Share on Twitter

TOPERA – Ataques IPv6 invisibles a Snort

¿Qué es TOPERA?

Topera es una herramienta que realiza ataques IPv6 que no son detectados por Snort o sistemas basados en Snort.

¿Qué hace diferente a TOPERA?

En muchos foros, blogs, reddit e, incluso, la propia lista de correo de Sourcefire (empresa fundada por el creador de Snort) se ha cuestionado los ataques que lleva a cabo TOPERA y como estos podrían detectarse ajustando las reglas de detección de Snort.

TOPERA aprovecha un fallo de diseño de Snort en el tratamiento de ciertos paquetes de IPv6. Esto significa que no importa lo buenas que sean las reglas que se tengan configuradas, Snort no será capaz de detectar los ataques que se aprovechen de este fallo de diseño.

TOPERA no ha reinventado la rueda, en lo que ataques se refiere, pero les ha otorgado la capacidad de ser indetectables por Snort.

¿Qué hay de nuevo en la versión 2?

TOPERA se encuentra en su versión 2, que fue presentada en el XI foro de seguridad en RedIris, mejorando el anterior ataque e incorporando uno nuevo: slow HTTP.

TOPERA fue la primera en incorporar este ataque bajo IPv6 (que días más tarde fue añadido al proyecto slowloris) y, además, dotarlo invisibilidad ante Snort:

¿Qué consecuencias tiene TOPERA?

Si eres administrador de sistemas, probablemente ya te habrás echado a templar leyendo el nuevo ataque. Si no eres sysadmin o todavía no le ves el peligro real (más allá del propio ataque) esto tal vez te haga hacerte una idea:

Usando TOPERA puede inutilizar (durante todo el tiempo que se esté ejecutando el ataque) un servidor web vulnerable a slow HTTP attaks, como Apache. Al no ser detectado por el IDS (basado en Snort) no podrás tomar contramedidas para poder protegerte o tratar de mitigar el ataque. Por lo tanto: el sistema de seguridad en que delegas para proteger tu infraestructura será inútil y no podrás hacer nada, ya que todavía no hay forma de solucionarlo.

No está mal, ¿verdad? Creo que ahora ya todo el mundo entiende el porqué los sysadmin se echaron a templar :-P

Uso y disfrute

Usar TOPERA es muy sencillo. Está hecho en python y es multiplataforma (aunque en Windows os irá muy lento si usáis el intérprete oficial de python: CPython).

Tenéis toda la documentación y ejemplos del estilo “copy&paste” (lo que más nos gustan, ¿verdad? :-P ) en la web del proyecto que tenemos publicada en github: http://toperaproject.github.io/topera/

Por si sois algo perezosos, no tenéis ningún sistema con IPv6 a mano o, sencillamente, no os apetece bajar la herramienta para verla en acción, aquí os dejamos el video oficial que hicimos de demo:

Y, como pone un poco más arriba, a usarlo y disfrutarlo. Eso si! Con moderación y no la lieis demasiado :)

—–
Autores:
Rafael Sánchez – @R_a_ff_a_e_ll_o
Daniel García A.K.A. cr0hn – @ggdaniel

Share via email
Share on Facebook+1Share on Twitter

Reparando un disco duro Seagate inutilizado

El firmware de algunas series de discos Seagate (especialmente la serie Barracuda 7200.11 y algunas series de Momentus para portátiles) vienen con un defecto que provoca que el disco se congele y deje de ser detectado por el PC. Para hacer frente a este problema hay diversas guías publicadas en la red, pero generalmente carecen de precisión en algunos conceptos y, en general, les falta claridad, así que he decidido redactar esta guía explicando el proceso de forma más fácil e inteligible.

El problema

Realmente, existen diversos casos distintos en los que el disco deja de funcionar. Entre ellos, los más comunes son:

  • Error LBA 0: En este caso la BIOS detecta el disco pero indica que su capacidad es de 0 bytes.
  • Error BSY: La BIOS no detecta el disco duro en absoluto, porque éste indica que está “ocupado” (BuSY)
  • Bloqueo del motor u otras averías físicas. En estos casos la solución no resolverá el problema, pero el proceso siguiente servirá para diagnosticarlo.

La causa

Un disco duro, además del espacio reservado a datos del usuario, contiene una partición especial dedicada a información de autodiagnóstico (SMART) que en situaciones normales se utiliza para marcar los sectores defectuosos y otros problemas encontrados. Esto sirve para evitar en lo posible fallos catastróficos, siendo el propio disco duro lo suficientemente inteligente como para evitar perder datos y/o avisar cuando está a punto de sufrir un problema grave. Pues bien, el firmware que viene con estos modelos de disco tiene un error que provoca que la partición de SMART se corrompa, dejando el disco inutilizable. Seagate publicó en su momento una actualización del firmware para estos discos que evitaba el error. La mala noticia es que esta actualización evita que el problema aparezca, pero una vez que el problema aparece es imposible actualizar el firmware. Por tanto, a no ser que seas un poco paranoico o que ya conocieras el problema con anterioridad, es muy poco probable que hayas actualizado el firmware sin encontrarte antes tu disco duro convertido en un bonito pisapapeles. Por supuesto, cuando el problema aparece los datos no se han perdido, ni muchísimo menos.

La solución

Dado que el origen del problema está en los datos de la partición SMART, la forma de solucionar el fallo una vez ha aparecido va a consistir en devolver esta partición a su estado de fábrica. Como el disco no es accesible, dado que la BIOS no lo reconoce, vamos a utilizar un puerto serie que incorporan estos modelos, que está ahí precisamente para tareas de diagnóstico y reparación de este tipo. Las conexiones del disco duro tienen más o menos esta apariencia: conexiones del disco: VCC-GND-TX-RX - SATA-Data - SATA-Power

Material necesario

Para realizar esta operación necesitaremos:

  • Un puerto USB libre en un PC
  • Un conversor de USB a UART, como éste: USB-UART
    • También nos sirve un módulo Arduino, del que usaremos los pines GND, TX y RX con el mismo cometido Arduino
  • Tres cables de cobre, con terminales que nos permitan conectar el UART al disco. En nuestro caso hemos usado puntas de prueba (test hooks) como estas: cables
  • Destornillador torx T3 de precisión. Sólo es necesario para los discos de 3,5″.
  • Una fuente de alimentación con un cable libre de alimentación SATA. También nos sirve una caja de disco externa del tipo adecuado y un cable de alimentación SATA. SATA-Power

Procedimiento

  • 1. (Sólo si el disco es de 3,5″) Desatornillamos la placa PCB del disco para desconectarla por completo de éste.
    Si nos saltamos este paso y el disco tiene el error de BSY, no podremos acceder a la consola de diagnóstico en el paso 7.
  • 2. Conectamos el adaptador UART al puerto serie del disco.Puedes basarte en el código de colores de las imágenes:
    • PC-TX ==> HDD-RX
    • PC-RX ==> HDD-TX
    • PC-GND ==> HDD-GND
    • NO es necesario conectar el pin de VCC.
  • 3. Conectamos el adaptador UART al puerto USB.
  • 4. Conectamos la alimentación SATA al puerto SATA-Power del disco duro.
  • 5. Abrimos putty (también puedes usar hyperterminal u otro programa de terminal, siempre que uses los parámetros adecuados) y nos conectamos al puerto serie correspondiente al adaptador UART, usando la siguiente configuración:
    • Velocidad (Speed): 38400 baudios
    • Bits de datos (Data bits): 8
    • Bits de parada (Stop bits): 1
    • Bits de Paridad (Parity): Ninguno/None
    • Control de flujo (Flow control): Ninguno/None
  • 6. Accedemos a la consola de diagnóstico del disco duro, pulsando Control + Z (en putty). Aparecerá un prompt en la consola:
    F3 T> 
  • 7. Accedemos al nivel de operación 2, escribiendo /2↵. El prompt cambiará.
    F3 T> /2
    F3 2>
     
  • 8. Esperamos unos segundos, y detenemos el motor del disco (o le hacemos saber a la PCB que está detenido, si la tenemos desconectada del disco), enviándole la orden Z↵.
    F3 2> Z 

    Aquí el disco tardará un momento y devolverá un resultado. Si devuelve un error, es posible que hayamos ido demasiado deprisa. Vuelve a emprezar y espera más tiempo antes de enviar la orden de parada del motor. 

  • 9. (Sólo si hemos desconectado la PCB en el paso 1) Con cuidado de que no se desconecte ningún cable, volvemos a conectar la placa PCB al disco duro. Para ello, la colocamos en su sitio y la atornillamos al mismo, apretando bien todos los tornillos.
  • 10. Esperamos unos segundos, y arrancamos el motor del disco, enviándole la orden U.
    F3 2> U

    Aquí el disco tardará un momento y devolverá un resultado. El motor del disco debería girar (debería notarse vibración). Si devuelve un error, es posible que la PCB no esté bien conectada al disco (revisa los tornillos), o que el motor del disco esté bloqueado y no pueda girar. Esto son malas noticias (ver más abajo).

  • 11. Accedemos al nivel de operación 1, escribiendo  /1↵. El prompt cambiará de nuevo.
  • F3 2> /1
    F3 1>
     
  • 12. Reiniciamos los datos de SMART, enviando la orden N1↵
    F3 1> N1

    El disco tardará un momento y devolverá un resultado. 
  • 13. Volver al modo de operación T, mediante T↵
    F3 1> /T
    F3 T>
     
  • 14. Reiniciar la lista de defectos detectados en el disco, usando el comando i4,1,22↵. Este paso no siempre es necesario.
    F3 T> i4,1,22 

    Aquí el disco tardará un momento y devolverá un resultado. 

  • 15. Detenemos el motor del disco (para apagarlo con seguridad) y lo apagamos. Para ello:
    • Accedemos al nivel de operación 2, escribiendo /2↵
    • Detenemos el motor del disco, enviándole la orden Z↵.
    • Cuando el motor se haya detenido, desconectamos el cable de alimentación SATA.
  • 16. Esperamos unos 10 segundos.
  • 17. Volvemos a conectar la alimentación SATA
  • 18. Volvemos a acceder a la consola de diagnóstico del disco duro, pulsando Control + Z
    F3 T>
     
  • 19. Regeneramos la partición de SMART, con el comando m0,2,2,,,,,22↵
    F3 T> m0,2,2,,,,,22 

    Aquí el disco tardará un buen rato antes de darnos un resultado. Esperamos a comprobar que el resultado es correcto. 

  • 20. Detenemos el motor del disco (para apagarlo con seguridad) y lo apagamos. Para ello:
    • Accedemos al nivel de operación 2, escribiendo /2↵
    • Detenemos el motor del disco, enviándole la orden Z↵.
    • Cuando el motor se haya detenido, desconectamos el cable de alimentación SATA.

Y después…

En este punto, ya hemos terminado de reiniciar los datos problemáticos. Si todo ha ido bien, el disco ya será detectado normalmente por la BIOS y podrá usarse sin problemas. Lo único que queda pendiente, a modo preventivo, es actualizar el firmware del disco duro para que el problema no vuelva a aparecer.

Qué hacer si el motor no gira

Si el motor de nuestro disco no gira (siempre responde con un error a la orden U en el punto 10 del procedimiento anterior), una de las causas más probables es que se encuentre bloqueado. Esto ocurre generalmente debido a un golpe o shock, o, con menos frecuencia, debido a un apagado brusco de la corriente. Llegados a este punto, si los datos contenidos en el disco son importantes, deberíamos enviar el disco al servicio técnico o a una empresa especializada de recuperación de datos. Sólo si esto no es posible y si los datos no son realmente importantes podríamos aventurarnos a desbloquear el motor nosotros mismos. Abrir un disco duro en un área no preparada específicamente para ello (debería hacerse siempre en una cámara de vacío) supone la muerte del mismo, por lo que, si estamos decididos a ello, debemos actuar rápido y con decisión y tener en cuenta que, una vez lo hayamos abierto, contaremos con poco tiempo para recuperar los datos antes de que éstos empiecen a degradarse. El bloqueo en este caso es físico, por lo que la operación consistiría en:

  1. Equiparnos adecuadamente (mascarilla, gorro o redecilla para el pelo, guantes de latex o “finger cots”) para evitar dejar partículas de cualquier tipo en la superficie de los platos del disco.
  2. Abrir el disco con los destornilladores torx apropiados.
  3. Mover el brazo (34) a su posición de inicio (50), de forma que las cabezas de lectura/escritura (32) queden fuera de la superficie de los platos (10)
  4. Obligar al rotor del disco (20) a girar, asegurándonos de que gira libremente y de que no tocamos ningún otro punto del disco.
  5. Cerrar el disco inmediatamente

hard disk internal structure

Share via email
Share on Facebook+1Share on Twitter

(Español) Técnicas de evasión de bloqueo y rooteo en dispositivos Android

A la hora de afrontar un análisis forense de dispositivos Android, una de las dificultades a las que nos enfrentamos es a que dicho dispositivo se encuentre bloqueado. En el siguiente artículo repasaremos las estratégias más utilizadas para evadir dicho bloqueo, incluyendo los tipos de elevación de privilegios, necesarios en muchas ocasiones.

Para comenzar, habría que repasar los 4 tipos de bloqueo del dispositivo que Android nos proporciona:

Slide (none). Es el modo más básico, simplemente realizando el gesto del desplazamiento el dispositivo quedará desbloqueado.

Pattern lock. En este modo se proporciona un patrón sobre los puntos marcados que debe seguirse para conseguir el desbloqueo del dispositivo. El único requisito sobre dicho patrón es que contenga al menos el paso por 4 puntos.

PIN. En este modo el usuario debe introducir un código numérico para desbloquear el dispositivo.  El único requisito sobre el PIN es que conste de al menos 4 digitos.

Password. En este modo el usuario debe introducir con código alfanumérico para desbloquear el dispositivo.  El único requisito sobre la contraseña es que conste de al menos 4 caracteres.

Los modos de bloqueo pueden configurarse desde las opciones generales, en el apartado de seguridad, en la opción “Screen lock”, como podemos ver a continuación: 1_tipos_bloqueo

Una vez clasificados los tipos, vamos a enumerar las diferentes aproximaciones para evadir estas protecciones: Smudge Attacks. En esencia se trata de ver las marcas físicas sobre la pantalla del dispositivo. Aunque a priori parezca un tanto cojido con los pelos, el hecho de tomar una fotografía de la pantalla y jugar con los cambios de colores, brillos, ponerla en negativo y demás pueden tener resultados muy satisfactorios. En el siguiente papper detallan esta aproximación desde una manera formal: http://static.usenix.org/event/woot10/tech/full_papers/Aviv.pdf Pattern Lock Crack Evadir esta protección es muy sencilla solo si se tiene acceso al modo debug del dispositivo rooteado. En patrón se almacena en el dispositivo en forma de hash en el fichero /data/system/gesture.key, como podemos ver a continuación:

2_gesturekey

Si tenemos acceso ADB de root, podemos eliminar el fichero y crear uno nuevo vacío:  

rm gesture.key touch gesture.key

A partir de ese momento, cualquier gesto desbloqueará el dispositivo. Si no tenemos acceso al modo debug, es posible a través de la interfaz JTAG, el proceso está descrito en el siguiente enlace: http://forensics.spreitzenbarth.de/2012/02/28/cracking-the-pattern-lock-on-android/ Password Crack && PIN Crack Evadir estas protecciones es muy sencillo solo si se tiene acceso al modo debug del dispositivo rooteado. La contraseña y/o PIN se almacena en el dispositivo en forma de hash en el fichero /data/system/password.key, como podemos ver a continuación:

3_passwordkey

Si tenemos acceso ADB de root, podemos eliminar el fichero y crear uno nuevo vacío:

rm password.key touch password.key

A partir de ese momento, cualquier contraseña y/o PIN desbloqueará el dispositivo. La gracia visto lo visto es tener el dispositivo rooteado, pero rootear un dispositivo en el transcurso de un análisis forense entraña dificultades en el proceso, ya que el principio fundamental es que las modificaciones de la envidencia tiendan a cero. Vamos a repasar el proceso. Lo primero al acceder a un dispositivo es saber si somos root en el mismo, tal vez el usuario lo tiene rooteado. ¿Cómo saberlo manipulando lo menos posible el dispositivo? Lo más sencillo es conectar al mismo mediante ADB y ejecutar la siguiente sentencia:

adb shell su

Si como respuesta entramos a la shell, somos root, si obtenemos un “Permision denied” nos lo tenemos que ganar. Antes que nada, no pensemos que ser o no root es algo abosluto, en entornos Android tenemos diferentes tipos de rooteo, y no todos tienen las mismas implicaciones desde el punto de vista forense, por lo que debemos evaluar en cada caso cuál necesitamos y actuar en consecuencia.

Root permanente. Es el más habitual. Entramos al dispositivo y somos root, ¿porqué? Normalmente es así porque se ha habilitado alguna ROM personalizada o se le han proporcionado al dispositivo binarios ARM para comandos como “su“. La referencia es XDA Developers.

Root temporal. Se elevan privilegios solo hasta el renicio, normalmente tras aprovechar una vulnerabilidad en ejecución. Esta forma es ideal desde el punto de vista práctico, si bien entraña riesgos porque se va a modificar en dinámico, puede causar inestabilidad y aprovechar vulnerabilidades para elevar privilegios puede ser muy discutido desde el punto de vista del proceso.

A continuación indico un par de aplicaciones para conseguir este objetivo:

psneuter. Aplicación que gana acceso a root utilizando una vulnerabilidad en Android. https://github.com/tmzt/g2root-kmod/tree/master/scotty2/psneuter

SuperOneClick. Aplicación que reune múltiples exploits para rootear el dispositivo. http://shortfuse.org/?page_id=2

Mercury. Este framework de análisis dinámico incorpora exploits para rootear el dispositivo. http://labs.mwrinfosecurity.com/tools/2012/03/16/mercury/

Root recovery. En este modo se habilita una particion de recuperación en el dispositivo que permite el acceso privilegiado solo cuando se carga dicha partición. Este tipo de rooteo es el más indicado para procedimientos forenses. La problemática es que cada fabricante maneja las particiones de recuperación de una manera diferente y en algunos casos no será trivial. A continuación dejo, por cortesía de @hidark, a modo de ejemplo el proceso para el modelo ASUS Transformer TF101: Arrancamos el dispositivo presionando los botones “power” y “subir volumen“, no ves nada en la pantalla, pero si la tienes conectada al PC puedes apreciar con un “dmesg” desde el PC que el dispositivo entró en modo APX:

5_apx_transformer

Después ya se puede cargar un bootloader específico mediante wheelie (http://androidroot.mobi/2012/05/27/introducing-wheelie-nvflash-for-asus-transformer-tf101-b70/) y extraer las particiones mediante nvflash (http://forum.xda-developers.com/showthread.php?t=1676845). Es importante tener en cuenta que este método ha de ser probado previamente en entorno de laboratorio para que la ejecución sobre la evidencia sea lo más limpia posible.

Daniel Medianero

Share via email
Share on Facebook+1Share on Twitter
Page 1 of 1412345»10...Last »