USB con unidad de sólo lectura: caso práctico INTECO

Hola a todos, acostumbrado a escribir sobre cosas más tecnicas hoy publico este post que es algo a modo de curiosidad, pienso que puede ser interesante el método a seguir para esta clase de cosas.

El otro día me dejaron un pendrive USB de estos con propaganda (como los típicos corporativos) que al enchufarlo me di cuenta que no era normal ya que tenía una unidad que detectaba como unidad de CD-ROM (de sólo lectura) y otra unidad normal donde almacenar los datos:

La unidad de CD-ROM contiene información relativa al Observatorio de la Seguridad de la Información del Instituto Nacional de las Tecnologias de la información (INTECO).

Nada más ver esto me entró curiosidad por ver como funcionaba esto y hasta donde podia llegar, al final pude hacerle cosillas al USB y voy a contar paso por paso lo que fui haciendo:

1. Antes de abrir el usb para obtener información y cargármelo suelo obtener toda la información que pueda del hardware en cuestión (sobre todo cuando el hardware no es mío), así que lo enchufo y lo primero que obtengo de Windows es la siguiente información: CBM Flash Disk USB Device, esta información tan básica la podeis ver al intentar quitar el hardware con seguridad.
   
   
2. Para ampliar información lo ideal es buscar software que nos de más información del hardware en esta caso he probado varios que dan información sobre USB, los que más me han gustado USBDeview (http://www.nirsoft.net/utils/usb_devices_view.html) y ChipGenius (http://www.mydigit.cn/chipgenius.htm) está en chino así que mejor usar gooogle translate. Las herramientas nos dan algunos datos interesantes como el Serial Number, la versión del Firmware etc.
   
   
   
   
3. Como podéis ver en las capturas los dos software dan una información similar sobre el USB, pero Chipgenius nos ahorra trabajo, ya que nos dá directamente el nombre del Vendor etc.
   
   
4. Después de googlear un poco podemos encontrar páginas en la que con los datos obtenidos saber que herramientas necesitamos para eliminar la partición, etc, una muy útil es una página rusa: http://flashboot.ru/iflash.html solo tenemos que meter el VID y el PID, en este caso 0204 y 6025 respectivamente (información obtenida con las herramientas anteriores).
   
   
5. Una de las herramientas que nos dan para nuestro chip es CBM209X UMP-Tool. Yo estoy usando la versión: CBM209XUmptoolV1.8.3.2_1122 . 
   
   
6. Abrimos el ejecutable umptool2090 de Chipsbank (si lo ejecutais con usuario limitado no funciona). Solo hay que hacer click en Start para que empiece a formatear:
   
   
   
7. Una vez hecho desaparecerá la molesta unidad de CD-ROM y tendremos un pendrive USB listo para usar. Es importante que la configuración del software esté correcta, os dejo unas capturas de como tiene que estar:
   
   
   

Y esto es todo, ¿vosotros como haceis esta clase de cosas?

PD: No soy un experto y no tengo ni idea de estos temas, si hay algo mal poned un comentario, muchas gracias.

------------------------

Contribución por David Reguera García aka Dreg - http://www.fr33project.org/ - http://twitter.com/fr33project

Leer más...

Montar nuestro honeypot con Netcat

Uno de los muchos usos que se le pueden dar a Netcat es, dentro de sus posibilidades, montar un honeypot. Al ser una herramienta tan versátil podemos adaptarla a múltiples servicios, en este caso vamos a ver como podemos configurar un simple honeypot FTP.

Para darle un poco de originalidad, vamos a buscar algún servidor FTP que haya sufrido alguna vulnerabilidad, cuanto más fácil de explotar mejor.

Una de las primeras que nos viene a la cabeza es la versión backdoorizada de ProFTPD 1.3.3c que fue detectada a finales del año pasado. Para saber como es el banner del servicio podemos, por ejemplo, buscar en Shodan servidores con versiones cercanas.

Con estos datos, nos queda hacer que Netcat escriba el banner en cada conexión y guarde un log con las conexiones. Podemos hacerlo con el siguiente script:

#!/bin/bash

buff="220 ProFTPD 1.3.3c Server (ProFTPD)\r\n"

while [ 1 ]; do
    echo $buff | netcat -v -l -p 21 >> /var/log/honeylog.log 2>> /var/log/honeylog.log
done

Usamos un bucle porque netcat terminará de escuchar cuando finalice la conexión, posiblemente con otras versiones de netcat podríamos mejorarlo.

Si escaneamos con Nmap el servicio nos detecta la versión de FTP vulnerable:

$ nmap -sT -sV -p 21 192.168.1.2

Starting Nmap 5.21 ( http://nmap.org )

Nmap scan report for 192.168.1.2

Host is up (0.0051s latency).

PORT   STATE SERVICE VERSION

21/tcp open  ftp     ProFTPD 1.3.3c

Service Info: OS: Unix

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .

Nmap done: 1 IP address (1 host up) scanned in 0.57 seconds

Y si miramos el log del honeypot:

$ cat honeylog.log

listening on [any] 21 ...

connect to [192.168.1.2] from desktop.local [192.168.1.3] 33303

listening on [any] 21 ...

Por supuesto, también podemos conectarnos, aunque la funcionalidad es mínima:

$ ftp localhost

Connected to localhost.

220 ProFTPD 1.3.3c Server (ProFTPD)\r\n

Name (localhost:asd):

Leer más...

Crear y montar imágenes raw (2ª parte)

Continuando el post que inició Alejandro Ramos sobre imágenes raw, voy a ampliar alguno de los puntos que se tocaron.

En el post se comentan comandos que derivan del original dd para realizar un clonado de discos. En caso de encontrarnos un disco con sectores defectuosos, el trabajo con ellos se puede convertir una auténtica pesadilla si no utilizamos las herramientas correctas. Si realizamos un clonado de disco con dd, si existe algún error en el disco origen el comando intenta una y otra vez leer el sector defectuoso, quedando atascado el proceso. Para evitarlo se puede realizar el clonado de la siguiente forma:

# dd if=/dev/sda of=/dev/sdb conv=noerror,sync

entonces no se detendrá ante sectores defectuosos y escribirá ceros, de forma que se mantiene el mismo tamaño en el disco destino que en el origen.

Para clonar discos con errores es mejor utilizar ddrescue del paquete gddrescue en Debian/Ubuntu.

La diferencia entre dd y ddrescue es que el primero con las opciones conv=noerror,sync se escriben ceros al encontrarse con un bloque con sectores dañados. Es decir, se escriben tantos ceros como tamaño de bloque se haya indicado con la opción bs. ddrescue en cambio opera a nivel de sector cuando trabaja con bloques dañados, por lo tanto recupera la máxima información posible.

Tal y como se comenta en el manual de ddrescue, la diferencia respecto a otros software como dd_rescue de Garloff, estriba en que este software trabaja de forma intensiva cuando se encuentra errores. En cambio ddrescue se preocupa primero por recuperar la máxima cantidad de datos posible, volviendo después a los bloques que contienen sectores erróneos para recuperar tanto como sea posible. En resumen dd_rescue de primeras trabaja con las zonas erróneas que se va encontrando, pudiendo repercutir esto de forma negativa en el disco. ddrescue en cambio salva todo lo posible antes, y luego se centra en las zonas dañadas.

Para trabajar con discos defectuosos es conveniente seguir los siguientes pasos:

1. Desmontar los sistemas de ficheros que contengan las particiones/discos que se vayan a copiar. Sino se podrían escribir datos mientras se realiza el clonado, de forma que la copia contenga un sistema de ficheros corrupto (por ejemplo, una parte de un fichero es la original y otra contiene datos modificados).
2. Ejecutar ddrescue en dos pasadas, de forma que la primera sólo recupera los bloques que no contenga sectores defectuosos y el segundo se centre en recuperar el máximo de los defectuosos. Esto permite que cuando acabe el primer comando (primera pasada) tengamos buena parte de los datos recuperados. En el primer comando se reliza copia de gran cantidad de datos, pero el segundo resulta también costoso al trabajar con sectores dañados:
   

# ddrescue -v -n /dev/sda /dev/sdb log_ddrescue.txt

NOTA: con -b se puede indicar el tamaño de bloque para acelerar el clonado de datos. Según www.cgsecurity.org es adecuado trabajar con bloques de 256k-500k:

# ddrescue -v -r2 -d /dev/sda /dev/sdb log_ddrescue.txt

NOTA: en este comando no tendría sentido indicar un tamaño de bloque, ya que ddrescue cuando trabaja con bloques que contienen sectores dañados lo hace sector a sector.
3. Finalmente se intentan solventar incoherencias en los sistemas de ficheros recuperados mediante fsck

Las herramientas anteriormente comentadas son útiles, pero poco eficientes antes discos de gran tamaño como los actuales. Para realizar un clonado eficiente de particiones (no de discos enteros), disponemos de varias herramientas:

1. partimage: hace una copia a nivel de bloque, y por tanto no es capaz de reestablecer un sistema de fichero a una partición de menor tamaño. No tiene soporte para ext4/btrfs, y con ntfs trabaja en caso de no estar muy fragmentado y no hacer uso de compresión.
2. partclone: trabaja a nivel de bloque. Tiene soporte para ext4/btrfs/ntfs.
3. ntfsclone: trabaja a nivel de bloque con el sistema de ficheros NTFS.
IMPORTANTE: partimage/partclone/ntfsclone copian una partición a otra del mismo tamaño; nunca a una de menor tamaño. Y en caso de ser mayor, hay que redimensionar el sistema de ficheros a mano.
4. fsarchiver: a diferencia de partimage, trabaja a nivel de fichero.
   Tiene soporte para ext4/btrfs/ntfs y también otras características como checksum, compresión multihilo, cifrado y flexibilidad en el tamaño de la partición. Se puede restaurar una copia a una partición de menor o mayor tamaño, sin tener que redimensionar el sistema de ficheros de forma manual.

Por último es importante tener en cuenta que no existe una única tabla de particiones en caso de que una de las particiones primarias sea extendida. Tendremos tantas tablas como particiones lógicas existan más la del MBR. Cada una de estas tablas se almacena en el primer sector de cada partición lógica formando una lista enlazada; de forma que la entrada de la partición extendida del MBR apunta a la tabla de la primera partición lógica, ésta a la segunda, y así hasta llegar a la última.

-----------------------------------

Artículo cortesía de David Montero http://damontero.wordpress.com

Leer más...

Geolocalizando con precisión de cirujano!

Actualmente, y mayormente gracias a los GPSs incorporados en los dispositivos móviles, la geolocalización se encuentra de lo más extendido y natural. Incluso hay redes sociales como Foursquare o el "Yo estuve aquí" de Facebook, que reconozco haber utilizado aprovechando el GPS de mi teléfono móvil, permiten compartir todo el mundo dónde te encuentras en un momento determinado.

A nivel IP, muchas veces hemos hablado sobre las diferentes formas de explotar la rica variedad de funcionalidades y usos que nos puede dar el conocer la localización geográfica de una IP determinada. Desde poder obtener estadísticas en las que aparece una banderita con el país origen o destino; ser capaces de ofrecer un contenido en el idioma adecuado, o proveer publicidad específica para una determinada ciudad o código postal (al menos en USA). Incluso Yago desarrolló su GeoIPS para algo que me parece más que interesante desde el punto de vista de la seguridad: "Si yo vendo flores en España,  ¿en qué me puede beneficiar las visitas desde China?" Evidentemente desde el punto de vista del SEO, puede ser interesante tener enlaces desde muchos sitios y visitas desde diferentes orígenes, pero si lo que me interesa es evitar un gran porcentaje de ataques automatizados, ¿para qué permitir visitas no deseadas?

Existe varias bases de datos (como por ejemplo la de Maxmind) y servicios mejor o peor actualizados, que permiten mediante una API, consultar una IP determinada, dónde se encontraba en el momento que se registró. Aquí se cuentan direcciones IP de utilización dinámica, que muchas veces van cambiando de ciudad en ciudad, no siendo tan tan eficaz, pero que para un uso normal es más que suficiente.

Sin embargo, cuando ya parecía que estaba todo inventado al respecto, me llamó muchísimo la atención un artículo que leí en Newscientist.com en el que se explicaba magnífico trabajo realizado por Yong Wang, un ingeniero informático chino y su equipo de la Universidad de Evanston en Illinois.

La novedad es que ha diseñado un mecanismo para geolocalizar, con un error bastante bajo dentro de márgenes más que aceptables, dónde se encuentra una IP concreta.

Fundamentalmente, Wang se basa en que conoce previamente las coordenadas GPS y dirección física de más de 76000 entidades, entre Universidades y empresas, que cuentan con al menos una dirección IP fija . Así pues, crearon una base de datos con toda esta información (en el artículo denominan a cada entrada en esta base de datos "landmarks" o referencias/marcas terrestres).

Para saber a qué distancia está una IP, se suele acotar en tres fases diferentes:

1. Se envía una serie de paquetes hacia la IP, y en base a lo que tarda en contestar se transforma en una distancia (más o menos esto vale para acotar a unos 200 kms)
2. Después se envían paquetes a los servidores referencias de los puntos conocidos de Google Maps (imagino que sólo será a los "más cercanos" a la IP acotada anteriormente) para saber por qué routers pasan. Cuando una IP conocida y la que se pretende geolocalizar atraviesan el mismo router, se compara cuánto tardan en llegar los paquetes desde cada máquina a ese router. Así se va acotando la distancia, hasta poder acercarse a saber dónde está realmente la IP.
3. Se repite el paso anterior pero sobre un área mucho más pequeña hasta determinar cuál de todos los servidores conocidos está más cerca del destino. Se han llegado a geolocalizar direcciones IP con una precisión de 690 metros!

Ante la evidencia científica yo expongo ciertas dudas:

• Aunque lo dicen en el artículo, utilizando un proxy puedes evadir el sistema explicado, de manera que si sales a través de un proxy que está en otro país, engañaríamos a la mayoría de los sistemas de geolocalización. Al menos el de Google falla cuando voy a Francia y con el mismo PC en español, salgo a Internet a través de la red de mi empresa o atravesando una VPN hasta mi casa. Qué poco me gusta que Google.com me redirija a Google.fr pudiéndome llevar a Google.es a través de la VPN. Wang indica que son capaces de detectar si una máquina es un proxy o no, y mostrar un resultado nulo en vez de un falso positivo. En mi caso concreto, estoy seguro que daría un falso positivo, esté en mi oficina de París o en el salón de mi casa, puesto que el mecanismo de salida es siempre a través del mismo Squid y a través de una VPN con OpenVPN hasta la misma máquina, ya sea por red cableada en Francia como por red wireless en el salón.

• Sigo sin tener claro, a no ser por el rigor de la prueba científica claro está, cómo es posible identificar una dirección IP con tanta precisión, en base al tiempo que demoran ciertos paquetes en llegar a un destino, siendo que la latencia dependerá del tráfico de la red, la carga de servidores, routers y balanceadores intermedios, que no siempre es la misma, máxime cuando se está hablando de direcciones IP en cualquier lugar del Mundo. De esta manera, cierto es que aunque una dirección IP sea dinámica, puede geolocalizarse igualmente sin tener que buscar en una base de datos que puede estar desactualizada, sino que la búsqueda se efectúa dinámicamente

• Si este mecanismo de geolocalización se empezara a utilizar de forma masiva a nivel mundial, los dispositivos con IP fija que se utilizan como referencia, registrarían un incremento de tráfico de red para el que incluso puede que no estén preparados y el mecanismo, precisamente por los cambios en los tiempos de respuesta, dejarían de ser válidos.

• Estoy completamente de acuerdo con el post de David Rubia de ALT1040 en el que se concluía que la geolocalización es algo que ha llegado a nuestras vidas para quedarse y que no es algo que simplemente pasará de moda llegado unos años dada la utilidad potencial que esto tiene.

• Si pudiera hacerle una sugerencia al equipo de Wang, añadiría a su algoritmo de búsqueda un paso previo, que es geolocalizarlo según lo registrado en una base de datos, para hacer hincapié en servidores referencia de la zona "cercana" a lo que diga la base de datos. Dado el número de direcciones IP existentes y dado que nadie suele apagar el router en los tiempos que se corre, la probabilidad de que una dirección IP no haya cambiado de usuario, es bastante alta y puede valer como un elemento más a tener en cuenta en la ecuación para la geolocalización  

Leer más...

Cookies si pero credenciales mejor

En este post voy a hablar de un vector de ataque de XSS que podemos explotar para obtener los credenciales de acceso a cualquier servicio del dominio vulnerable, esté el usuario autenticado o no en el mismo.

Como sabemos, la opción de los navegadores de autocompletar formularios de autenticación es muy cómoda y utilizada. Aprovecho para destacar que sólamente Mozilla Firefox tiene implementada la opción de contraseña maestra (aunque no venga activada por defecto) por lo que si usamos Internet Explorer, Google Chrome o Safari (los navegadores que utilizaré para realizar el ataque), nuestras contraseñas estarán almacenadas en texto plano.

Volviendo al tema del ataque, podréis intuir que podemos aprovecharnos de esta funcionalidad para inyectar en la página un formulario de autenticación oculto y obtener los credenciales que el navegador autocompleta.

Aun más interesante es la forma en que los navegadores guardan los credenciales, atendiendo únicamente al host (excepto Internet Explorer que lo hace correctamente), por lo que si hay un XSS en cualquier path podremos explotarlo para obtener los credenciales almacenados en el navegador del usuario de cualquiera de los servicios de ese mismo dominio.

Un ejemplo podría ser el siguiente dominio con los servicios de correo e intranet:

http://pagina.es/correo/login.php
http://pagina.es/intranet/access.php
http://pagina.es/index.php

Si existiera un XSS como http://pagina.es/index.php?msg=XSS podríamos utilizarlo para obtener los credenciales de ambos servicios (correo e intranet).

¿Qué ocurre si los usuarios son distintos?

Si el usuario no es el mismo para ambos servicios tenemos dos casos. Si el usuario está utilizando Firefox o Chrome el formulario no se autocompletará hasta que no especifiquemos con qué usuario nos vamos a autenticar y si, en cambio, está utilizando Safari nos autocompletará con el primero de ellos.

Para obtener los credenciales en el primer caso, o los restantes en el segundo, podríamos cargar la página oculta con AJAX y mediante un script irla recargando modificando el valor del parámetro 'value' del usuario en el formulario (por fuerza bruta o diccionario). En el momento en el que fuera correcto se obtendría la contraseña y se pasaría al siguiente caso.

En el caso de que el usuario estuviera autenticado todo se simplificaría porque bastaría con obtener el nombre de usuario/email (o lo correspondiente) y especificarlo en el parámetro 'value' del usuario en el formulario.

Podéis ver un ejemplo en el siguiente video:

Por lo tanto queda claro que almacenar los credenciales es cómodo pero puede suponer un serio problema, ya no sólo en aquellos navegadores que no ofrecen la opción de configurar una contraseña maestra, sino además si la página es vulnerable a un XSS, pues ya no sólo obtienen nuestro sessionID sino algo más importante, nuestros credenciales.

Aprovecho para hacer referencia a los programas IEPassView, ChromePass y PasswordFox de Nirsoft (en el caso de que no se haya configurado la contraseña maestra) que permiten obtener los credenciales almacenados en dichos navegadores.

---------------------

Contribución por Luis Delgado J.

Leer más...

Enlaces de la SECmana - 66

• Abierto el proceso de solicitud de ponencias (Call for papers) para la HITB (Hack In The Box) 2011 en Malasia. Finaliza el 15 de Junio de 2011.
• Microsoft publica la segunda edición de su guía Microsoft Security Update Guide, guía sobre actualizaciones de seguridad de Microsoft, la cual incluye en esta ocasión cómo prueba Microsoft sus actualizaciones de seguridad, estudio de la mejor estrategia para actualizaciones según el entorno corporativo, información sobre el programa de validación de actualizaciones de seguridad, mayor repaso a los indices de explotabilidad y métricas, etc.
• Listado de compañías afectadas por la fuga de direcciones de correo de la empresa de marketing online Epsilon.
• En Shell-Storm, tenemos disponible un repositorio con las pruebas de las pasadas prequals de la Nuit Du Hack 2011
• Primer episodio en español de uno de los mejores podcast de tecnología y seguridad Pauldotcom, semanales. Como primer invitado en este nuevo proyecto, Julio Canto de VirusTotal. Aquí [MP3] podréis escucharlo.
• Videos del seminario de Wikileaks que se celebró en el Campus Sur de la UPM el 30 de Marzo.
• Importante actualización de seguridad, Wordpress 3.1.1 disponible
• Recopilación de las presentaciones de charlas de la pasada Troopers 2011
• Tercer episodio de 'Mundo Hacker TV' con mención especial a SecurityByDefault :)
  

Leer más...

Crear y montar imágenes raw

Existen muchas opciones para obtener una imagen de un disco duro en un análisis forense. Una de las más económicas y utilizadas son las herramientas opensource que se proveen en distribuciones LiveCD de Linux enfocadas a este mismo propósito.

Estas distribuciones integran la utilidad "dd" y múltiples alternativas que facilitan y mejoran las funciones de la original, como son:

• dc3dd: creada por Jesse Kornblum,  para el DoD Cyber Crime Center, junto a otras utilidades conocidas como foremost o md5deep. Esta aplicación es un parche para el comando "dd" al que añade nuevas características, como: 
• Creación de hashes "en el vuelo", para no tener que ejecutar posteriormente otra herramienta para sacar los hashes de cada imagen.
• Verificación de la correcta lectura y escritura de datos.
• Barra de progreso.
• Posibilidad de dividir de las imágenes resultantes entre varios ficheros.
• Combinación de errores en los logs, para no generar cientos de líneas en fallos de lectura.
• Posibilidad de ser utilizado para "wipear" datos.
• dcfldd: creado por el U.S. Department of Defense Computer Forensics Lab, es muy similar al dc3dd en cuanto a sus características, pero a diferencia del anterior, no es un parche a aplicar al propio dd. Dcfldd es un fork que se mantiene independientemente. Una de las mejoras más destacables es la posibilidad de almacenar los datos en múltiples destinos, de tal forma que se pueda hacer más de una imagen a la vez de un mismo bloque de datos.
• dd_rescue: orientada a la realización de copias de seguridad para la recuperación en caso de desastre. Entre sus principales ventajas y diferencias ofrece la posibilidad de configurar el tratamiento en caso de errores de lectura y la posibilidad de lectura inversa: comenzando por el final del archivo.
• ddrescue: pese a la similitud en el nombre con el anterior, es una herramienta distinta con el mismo propósito. Esta aplicación ofrece la opción de resumir y continuar copias canceladas.

Por cierto, un truquito para conocer cuantos datos ha copiado el clásico dd es enviarle la señal USR1:

#
# dd if=/dev/zero of=/dev/null& pid=$!
# kill -USR1 $pid; sleep 1; kill $pid
24601995+0 records out
12596221440 bytes (13 GB) copied, 13.0529 s, 965 MB/s

Una vez hecha la imagen, que incluirá la tabla de particiones, la forma más sencilla de ir montando cada una de las particiones en otro equipo del laboratorio es con la herramienta kpartx. Sus   parámetros son muy sencillos:

# kpartx -l image.img
loop1p1 : 0 512020 /dev/loop1 61
loop1p2 : 0 512000 /dev/loop1 412062
loop1p3 : 0 44056010 /dev/loop1 924060

# kpartx -a -v image.img
add map loop1p1 (253:6): 0 512020 linear /dev/loop1 61
add map loop1p2 (253:7): 0 512000 linear /dev/loop1 412062
add map loop1p3 (253:8): 0 44056010 linear /dev/loop1 924060

# ls -l /dev/mapper
total 0
crw-rw---- 1 root root  10, 62 2010-06-15 17:40 control
brw-rw-r-- 1 aramosf aramosf 253,  6 2019-08-16 00:28 loop1p1
brw-rw-r-- 1 aramosf aramosf 253,  7 2011-04-01 00:28 loop1p2
brw-rw-r-- 1 aramosf aramosf 253,  8 2011-04-01 00:28 loop1p3

# mount /dev/mapper/loop1p1 /mnt -o ro

# umount /mnt

# kpartx -d image.img
loop deleted : /dev/loop1

Leer más...