30 abril 2011

Sniffer para windows RawCap

RawCap es un sniffer que tan solo ocupa 17kB y que además no require de ningún driver instalado, como ocurre con otras herramientas y la necesidad de la popular librería WinPcap.

Su uso es tan sencillo como copiar el binario y ejecutarlo, ya que tampoco requiere instalación y es portable. Ideal para llevar en el clásico kit de herramientas de gestión de incidentes o tests de intrusión.

Solo soporta dos argumentos, la dirección IP del interfaz y el fichero destino. Una de las características más importantes es que permite sniffar loopback, conexiones PPP o Wireless.

Como desventaja, y es que no hay software perfecto, es la falta de compatibilidad con Windows Vista y Windows 7, ya que el método para sniffar raw sockets en estos sistemas es distinto y tan solo deja almacenar los paquetes que se reciben (Windows 7) o los que se envían (Windows Vista)

Mediante el argumento --help muestra todas las posibilidades para que se haga una selección:


Una vez identificadas todas las interfaces, se introducen los argumentos:



Rawcap se puede descargar desde: http://www.netresec.com/?page=RawCap
Leer más...

29 abril 2011

Monitorizando nuestra reputación

Cuando hablamos del día a día de la gestión de la seguridad de la información en una entidad, empresa o grupo, estamos haciendo referencia entre otros al ejercicio de la ejecución y seguimiento de determinadas tareas. Cuando desarrollamos un plan de seguridad para una entidad, no pueden faltar por ejemplo la definición de la gestión de actualizaciones de seguridad en sistemas operativos y antivirus, backups de la configuraciones y datos, gestión de los registros de seguridad (logs), etc.

Este tipo de tareas son muy comunes, y como digo su presencia es crucial, deben estar claramente definidas en el calendario del equipo de profesionales encargado de gestionar la seguridad de la información en una empresa concreta.

Durante la última década con la llegada de nuevas tecnologías, el uso de Internet como medio donde hacer negocios, y consecuencia de esto, el nacimiento de un “crimen organizado” que intenta aprovechar la más mínima posibilidad de comprometer un recurso para ponerlo al servicio de sus propósitos, ha nacido la necesidad de integrar otro elemento dentro de las tareas habituales que dibujan la hoja de ruta del seguimiento del estado de la seguridad. Este elemento a integrar es el habitualmente conocido como “monitorización de la reputación”.

Entendiendo a nuestros nombres de dominios y direcciones IP publicas cómo lo que son, activos al servicio de nuestro negocio, es importante llevar a cabo una constante monitorización de la información con la cual éstos están relacionados. La presencia de nuestros nombres de dominios y direcciones IP publicas en una blacklist pública, malograría muchísimo nuestra imagen corporativa, y esto ya sabemos que finalmente puede materializarse en una pérdida de la oportunidad de negocio, y por ende de potenciales beneficios.

En un intento de establecer dichos controles, es muy común por parte de los administradores la suscripción al servicio de alertas de google, añadiendo sus nombres de dominio e IPs con ánimo de obtener la información relativa cualquier nueva publicación que contenga dicha información.

Otro elemento de uso común es la web http://multirbl.valli.org/lookup donde se puede ejecutar una consulta buscando entre más de 100 blacklists.



De entre las blacklist destacan las especializadas en la presencia de Malware en nuestros sitios web. A modo de ejemplo podemos encontrar información especifica en algunas de las siguientes direcciones:

En relación con todo esto he desarrollado una pequeña aplicación a modo de ejemplo de lo que podría ser un control de este tipo. La aplicación ejecuta los siguientes pasos:

1. Ejecuta una petición http al sitio www.malwaredomainlist.com para consultar la presencia de una IP concreta.
2. Discrimina en un función del tamaño en bytes de la respuesta.
3. Escribe un log en la salida de la consola que ejecuta la aplicación.
4. Se ejecuta continuamente, lanzando la petición y el análisis posterior cada 2 minutos.

El código está escrito en Python y el siguiente:

#!/usr/bin/env python
#-*- coding: UTF-8 -*-
# Se conecta a mdl y comprueba si nuestra ip esta en la lista negra 

import urllib2
import time

# funcion que comprueba de tamaño de la respuesta en bytes
def comprobar():
link = urllib2.urlopen("http://www.malwaredomainlist.com/mdl.php?search=80.24.165.210")
html = link.read()
if (len(html) == 6285):
print "Fecha comprobacion:" + str(time.strftime('%X %x %Z'))
print "Estado: OK"
print "tamaño en bytes:" + str(len(html))
else:
print "Fecha comprobación:" + str(time.strftime('%X %x %Z'))
print "enviar el mail"
print "tamaño en bytes:" + str(len(html))
time.sleep(20)

# ejecución constante 
while (1):
comprobar()




Como podéis comprobar el código ejecuta una consulta relacionada con la IP 80.24.165.210. Sí, sé que podría parsear la respuesta en lugar de comprobar su tamaño en bytes, sería mucho más fiable, podría enviar un correo cuando se produzca un positivo, añadirlo al Cron en lugar ejecutar un while 1 y hacer el sleep o lanzarlo en background y escribir en un fichero en lugar de en la salida de la consola. Además de que es mejor lanzar la consulta por ejemplo una vez al día en lugar de cada 2 minutos, entre otros para evitar que nos baneen, pero el script es solo una pequeña prueba de concepto para ilustrar la idea de lo que podría ser un control de la reputación de una IP concreta.

Finalmente comentar la existencia en el mercado de productos y servicios que nos dan este tipo de cosas hechas, obteniendo las alertas a través de la recepción de correos o mensajes SMS. Pero por otro lado esta claro que desarrollar y mantener una aplicación que monitorice la reputación de nuestros recursos, tampoco es una tarea imposible, y esto significa un interesante ahorro a la hora de establecer controles.

-----------

Contribución gracias a Sergi Roselló León
Leer más...

28 abril 2011

Binarios para desayunar

Como ya sabéis desde hace tiempo llevamos organizando los 'wargames' de Campus Party e incluso lanzamos nuestro primer Wargame internacional hace relativamente poco.

Llevamos tiempo prometiendo que liberaríamos algunas de las pruebas para aquellos que en su momento no pudieron participar y hoy ha llegado ese día.

Las pruebas que vamos a liberar son de tipo 'binarios' y la dificultad va in crescendo, la primera es bastante sencilla, la segunda tiene mas dificultad y la tercera es mas dura .

Problemas de tiempo

Esta prueba formó parte del reto Campus Party 2009 y la lógica es la siguiente: Tenemos un binario compilado que debe liberar un token, el problema es que solo liberará dicho token en una fecha determinada (y posterior a la actual). 

Para asegurarnos que el binario se ejecutaba en el host donde debía ejecutarse (y no fuera tan fácil como descargarlo y ejecutar en una maquina cambiando la hora ...) debes crear el fichero /tmp/matrixhasyou para simular el entorno confiable donde debe ejecutarse.

El código fuente de la prueba se puede descargar aquí

Compilación: gcc -static timetoken.c -o timetoken

Crackme 'old school'

Este es el típico crackme donde se debe 'reversear' el binario en busca del token, lo suyo es compilarlo con -static para meter mayor cantidad de ruido y hacer que el comando strings emita muchos datos.

El fuente de esta prueba aquí.

Compilación: gcc -Wall -O2 --static -pthread passCP.c -o passCP

Crypto al revés

Esta prueba, del Wargame I, generó infinidad de correos electrónicos preguntando 'si estaba bien' porque el planteamiento es un poco diferente a lo normal. En este caso, del binario debes ser capaz de obtener un string cifrado y convertido en base64 y la clave para descifrar dicho string. ¿Donde está el problema? En que no se especifica en ningún lado con qué algoritmo de cifrado se ha realizado el proceso. 

El binario se ofrecía 'roto' ya que faltaba una librería llamada libSbD.so.1 que era la que contenía la información sobre los algoritmos empleados. Se pedía como solución que se entregase una librería que hiciera funcionar el binario

Mucha gente resolvió el problema haciendo fuerza bruta ... de algoritmos para descubrir cual se estaba usando.

Para jugar esta prueba, compila todo el fuente (binario y librerías) y luego 'borra' libSbD.so.1 para tener el binario exactamente a como se entregaba a los participantes

El fuente de la prueba se puede descargar aquí

Compilación: 

(la librería compartida)

gcc -c -fPIC libSbD.c -o libSbD.o

gcc -shared -Wl,-soname,libSbD.so.1 -o libSbD.so  libSbD.o

(El binario en si )

gcc bin02.c -o bin02 -L. -lSbD -lssl -lcrypto -pthread
ln libSbD.so libSbD.so.1

(Para ejecutarlo)

export LD_LIBRARY_PATH=`pwd`

./bin02

Esperamos que este material resulte didáctico, tanto para los valientes que compilen y jueguen como para aquellos que simplemente tengan interés en ver el código
Leer más...

27 abril 2011

Trasteando con una alarma de Securitas

Tal y como le prometí a Chema Alonso en la entrevista que me hizo en El Lado del Mal, tenía otra frikada domótica Mcgyveriana pendiente por hacer. En los tiempos en los que estuve analizando cómo iba a acceder a encender la Roomba me vino a la cabeza la solución a un anterior reto inacabado que tenía meses atrás: Poder encender y apagar de forma remota la alarma de mi casa.

Intenté buscando en foros de alarmas y redes P2P, manuales de instalador de Securitas, en busca de algún punto de acceso remoto que me permitiese manipular la centralita. Esta búsqueda terminó sin éxito. Incluso llamé al instalador de mi alarma porque recordaba que se había conectado vía Bluetooth para activar "noseque". Efectivamente, me contó que hacía ciertas comunicaciones, pero previamente hay que abrir la centralita de la alarma y activar el bluetooth poniéndola en modo test, por lo que tampoco me valía. Por más que busqué por bluetooth, no encontré ningún identificador de forma normal.

Sin embargo, mientras le explicaba a mi atónita madre (hola mamá!) cómo iba a acceder a la Roomba inicialmente simulando ser un mando a distancia por infrarrojos, se me encendió la luz respecto a la alarma: El mando a distancia que me dieron con la misma.


Historia de un hack domótico
Dicho mando funciona con una pila (en concreto una CR2450 de 3 Voltios) y permite mediante 4 botones: activar la alarma completamente, desactivarla, activarla parcialmente (para cuando estás dentro de casa) y saber el estado en el que está. Lo primero fue quitarle los tornillos al mando y entender cómo funciona. Me dí cuenta que, si mantienes apretado uno de los botones y le metes la pila, el mando envía la señal del botón correspondiente a la alarma inmediatamente una sola vez. En mi caso, la idea era poder al menos encender la alarma cuando mi casa detecte que no estoy (en base a no encontrar el bluetooth de mi móvil por ejemplo). Es increible la cantidad de cosas que se pueden hacer gracias a los 3,3V que es capaz de sacar el puerto paralelo mediante 8 líneas diferentes de salida controlables.
Hace muchos años, me animé a hacer un reloj binario controlado mediante el puerto paralelo del PC. Así que lo primero que se me ocurrió fue un sencillo circuito que, manteniendo presionado el botón de encender alarma, atención "con una pinza de la ropa!", conectando el cable del pin 0 del puerto paralelo al contacto positivo de la toma de corriente de la pila del mando a distancia y el cable del pin 25 (Tierra) al negativo. Y, no os lo vais a creer, pero al mandar un 1 por el bit 0 del puerto paralelo, la mayoría de las veces: funcionaba!!!!  El circuito era una chapuza y era inestable como él solo, pero era capaz de activar la maldita alarma con un solo bit del puerto paralelo.

Sin embargo, me interesaba lograr el poder encender y apagar remotamente la alarma (nunca se sabe cuando puede llegar a activarse sola estando en el salón y si salgo al pasillo, directamente sonaría!) así que el circuito tendría que ser más complicado, involucrando un par de relés (uno para cada botón: encender y apagar) y un par de líneas más desde el puerto paralelo para usar a modo de señales de control que permitan hacer que los relés se exciten o no. Dado que el voltaje del puerto paralelo es de 3,3 Voltios, necesitaba unos relés especiales que funcionasen a 3V. Por haceros la historia corta, gracias a la colaboración de mi buen amigo Pablo y su experiencia soldando circuitos, llegamos a la conclusión que la intensidad del puerto paralelo no era suficiente para alimentar por un bit el circuito y por otros dos hacer que los relés llegasen siquiera a inmutarse.

Mi gozo una vez más en un pozo!!!! Así pues, exponiéndole el problema a un tío mío, ingeniero electrónico, se ofreció a diseñarme el circuito definitivo que me garantizaría el correcto funcionamiento. En este caso, sería necesario, además del puerto paralelo para las señales de control, la utilización de un cable USB que proveería de un voltaje de 5V, suficientes para hacer que todo funcione como corresponde.

Así pues, y como la electrónica avanzada no es mi fuerte, os expongo el esquema del circuito que me envió mi tío, así como la lista de materiales necesarios.





Lista de materiales

  • Placa perforada -> 4 euros 
  • 2 Optoacopladores darlington 4N30 -> Regalados por mi amigo Koldo
  • 2 resistencias de 2,2 KOhms 1/4W -> 0,02 euros
  • 2 resistencias de 10 KOhms 1/4W -> 0,02 euros
  • 2 resistencias de 100 KOhms 1/4W -> 0,02 euros
  • 2 transistores MPSA13 -> 0,4 euros
  • 3 diodos 1N4007-> 0,6 euros
  • 2 relés OMRON G5V1 3DC -> 5,1 euros
Los relés OMRON, los conseguí en ASDS y el resto de las piezas, excepto los optoacopladores, en Actron y en Electrónica Cíes

Y el circuito soldado queda algo así: 


    Lo siguiente es buscar una cajita o un contenedor que permita encajar toda la maraña de cables y chips, así como dar una consistencia más sólida al circuito y sus cables, que son bastante frágiles ante cualquier tirón.



    ¿Quién no tiene por casa un viejo router ADSL Zyxel de esos monopuerto de Telefónica? Pues os diré que si vaciáis uno y quitáis un par de patillas de plástico internas, encaja a la perfección. Me doy cuenta ahora que, entre el cable USB con la manzanita reciclado de mi viejo iPhone 2G y la caja blanca del router, parece un accesorio más de Apple: ¿habremos creado la "iAlarma"?

     

    Para enviar las señales necesarias desde el puerto paralelo, utilizaremos un par de scripts en Perl:

    Script activar_alarma.pl


    [root@Carmen ~]# more /usr/local/bin/activar_alarma.pl 
    #!/usr/bin/perl
    
    use Device::ParallelPort;
    use Device::ParallelPort::drv::linux;      
    
    my $port = Device::ParallelPort->new('linux');
    
    $port->set_bit(1,0);#Inicializo a 0
    $port->set_bit(2,0);#Inicializo a 0
    sleep (1);
    
    $port->set_bit(1,1); #Pongo a 1 el bit 1 para que se "presione" el botón
    print "Activando…\n";
    sleep 5; #Espero 5 segundos con el botón "presionado"
    
    $port->set_bit(1,0); #Suelto el botón
        
    

    Script desactivar_alarma.pl


    [root@Carmen ~]# more /usr/local/bin/desactivar_alarma.pl 
    #!/usr/bin/perl
    
    use Device::ParallelPort;
    use Device::ParallelPort::drv::linux;      
    
    my $port = Device::ParallelPort->new('linux');
    
    
    $port->set_bit(1,0); #Inicializo a 0
    $port->set_bit(2,0); #Inicializo a 0
    sleep (1);
    
    $port->set_bit(2,1); #Pongo a 1 el bit 2 para que se "presione" el botón
    print "Desactivando..\n";
    sleep 5;#Espero 5 segundos con el botón "presionado"
    
    $port->set_bit(2,0);#Suelto el botón
    


    Aquí podéis ver un video de ambos scripts funcionando:









    Conclusiones
    • La forma de controlar si estoy/estamos en casa es mediante el bluetooth del teléfono móvil, por lo que en cuanto el servidor de casa no encuentra el móvil, vía bluetooth, activará la alarma. De manera que al llegar a casa y apagar la alarma manualmente con su correspondiente código de desbloqueo, en la siguiente barrida encontraría el bluetooth del móvil y no se activaría de nuevo la alarma. Podría hacerlo automáticamente también, invocando a desactivar_alarma.pl, pero si alguien lograra spoofear la BD Address bluetooth de mi móvil y su nombre, se desactivaría la alarma. Otro problema más, ¿qué sucede si llego a casa sin batería en el móvil? La puedo apagar manualmente sí, pero según llegue al salón, al siguiente minuto, se volvería a activar y estaría acorralado en el salón de casa! Así pues me interesa tener a mano la posibilidad de desactivar manualmente la alarma con desactivar_alarma.pl y quitar del cron el que monitorice si hay dispositivos bluetooth autorizados cerca mientras arranco el móvil y hasta que el bluetooth sea detectable. He estado buscando dispositivos bluetooth que poder comprar, que no hagan NADA pero que simplemente me sirvan para hacer el control de presencia, ¿quizá algo que se cuelgue en el llavero?
    • Sí, ya sé que Securitas ofrece un módulo GSM que mediante SMSs, permite hacer esto mismo, pero el modulito cuesta 120 euros más todos los SMSs que quieras enviar diariamente. también podría haber comprado un scanner de frecuencias e intentar capturar las señales enviadas por el mando a distancia al presionar ambos botones y replicarlas con un emisor de frecuencias. Desconozco cuanto costaría el equipo necesario para hacer eso. Sin embargo, la solución casera vale unos 10 euros. ¿Estamos en crisis no?
    • No he querido titular el post Hacking Securitas aunque realmente crea que así es, pero no faltarán las críticas a que eso no es hacking, así que… dejémoslo en trasteando o curioseando y así todos contentos: los trolls y yo ;D
    • Este invento ha sido el último a añadir al sistema de monitorización de presencia que tengo en casa, que activa/desactiva Motion, la posibilidad de que la Roomba se líe a limpiar, un contestador automático hecho con un modem externo y ahora la activación de la alarma, de manera que no tenga que presionar ningún botón y que todo se active y, excepto la alarma, se desactive por sí solo. Prometo exponer todo este frikismo en un post de aquí a un tiempo.
    • Cuando ví que no había manera de hacer que este invento funcionase con el puerto paralelo, pensé incluso en adquirir un Arduino o incluso recuperar mis recuerdos universitarios en programar un micropic 16F84.

    Créditos y agradecimientos


    Muchísimas gracias a mi amigo Pablo por sus manos expertas con el soldador, a mi amigo Koldo Valle por conseguirme y enviarme los optoacopladores que necesitaba para este invento, y por supuesto a mi tío Ricardo por las horas invertidas de una persona tan ocupada, dedicados a contentar las locuras de su sobrino. A los tres, gracias además por vuestra paciencia y un fuerte abrazo!
    Leer más...

    26 abril 2011

    Android+Skype – All your data are belong to us


    El pasado viernes la conocida empresa Skype confirmaba en su blog los rumores sobre la posibilidad de tener acceso a los datos de carácter privado almacenados por la aplicación en dispositivos Android.

    El problema aún se agrava más si tenemos en cuenta que estos datos no están cifrados, por lo que cualquier podría utilizarlos sin mayor problema para fines delictivos.

    Nuevamente volvemos a encontrarnos ante el problema de infectar aplicaciones de terceros en las que incluir el código malicioso para robar los datos.

    Introducción

    El objetivo de esta entrada es analizar cómo está desarrollado el exploit para vulnerar la privacidad de los usuarios y hacer un pequeño repaso al tema de análisis forenses a dispositivos android para dejar entrever algunas de sus deficiencias.

    Como requisitos previos será necesario disponer de acceso root al teléfono, para ello podemos guiarnos de la aplicación SuperOneClick y tener instalado el SDK para hacer uso del Android Debug Bridge (ADB).

    Skypwned

    Cuando instalamos Skype y establecemos conexión por primera vez con nuestra cuenta, en la jerarquía de carpetas de la instalación se crea una nueva con nuestro nombre de usuario, y se almacenan ahí todos los ficheros como contactos, perfil, logs de las conversaciones mantenidas y bases de datos sqlite3

    El problema viene con la forma de otorgar los permisos, donde hacen posible la lectura y escritura de todos los ficheros para cualquier usuario. De esta forma es relativamente sencillo conseguir acceso remoto a través de cualquier aplicación a las carpetas deseadas, hacer una copia y enviarlas a otro lugar donde tratar la información más detenidamente.

    # ls -l /data/data/com.skype.raider/files/arriba_laesteban
    -rw-rw-rw- app_62  app_62    331776 2011-04-16 00:08 main.db
    -rw-rw-rw- app_62  app_62    119528 2011-04-16 00:08 main.db-journal
    -rw-rw-rw- app_62  app_62     40960 2011-04-14 14:05 keyval.db
    -rw-rw-rw- app_62  app_62      3522 2011-04-15 23:39 config.xml
    drwxrwxrwx app_62  app_62           2011-04-14 14:05 voicemail
    -rw-rw-rw- app_62  app_62         0 2011-04-14 14:05 config.lck
    -rw-rw-rw- app_62  app_62     61440 2011-04-15 00:08 bistats.db
    drwxrwxrwx app_62  app_62           2011-04-14 21:49 chatsync
    -rw-rw-rw- app_62  app_62     12824 2011-04-14 14:05 keyval.db-journal
    -rw-rw-rw- app_62  app_62     33344 2011-04-14 00:08 bistats.db-journal
    

    Para demostrar el impacto, AndroidPolice desarrolló un pequeño POC llamado Skypwned. El APK (e788c146fbeaf4152d57c12711c4bdbd ) presenta la siguiente estructura una vez desempacado y pasado dex2jar y JAD:

    sebas@Helios:~/Android/research/Source_Code_JAD$ tree .
    .
    |-- a.jad
    |-- b.jad
    |-- c.jad
    |-- d.jad
    |-- e.jad
    |-- f.jad
    `-- Main.jad
    
    0 directories, 7 files
    

    El trozo de código qué aprovecha este fallo podéis verlo aquí. Básicamente busca ficheros específicos y reserva memoria para varios strings donde se forman las consultas para lanzarlas a la base de datos y sacar así los datos que nos interesan : información de los contactos, perfiles, logs, y demás. El fallo, está presente en varias compilaciones de la aplicación también, aquí si las cosas se hacen mal, que sean desde el principio...

    El problema viene ante la posibilidad de un vector de ataque en el que se utilicen aplicaciones de terceros para inyectar ese trozo de código, empacar el APK de nuevo y lanzarlo al market. Provocando así una infección masiva que revele los datos privados de cientos de usuarios. Incluido el número de la tarjeta de crédito en caso de que se tenga asociada a la cuenta de Skype así como los logs de las conversaciones.

    Supongamos que por un casual fuese Google el que tiene este fallo, y es su aplicación de Google Talk la que tiene este problema y deja expuestos los de sus usuarios, números de teléfono y agenda de contactos. Sería un desastre ¿verdad?.

    El POC en funcionamiento podéis verlo en este vídeo realizado por AndroidPolice:







    ¿Dónde está el problema?

    Analizando más detenidamente el núcleo del error, nos damos cuenta de que se han producido tres fallos esenciales de cierto calibre:
    • No se han aplicado correctamente las políticas de los permisos, dejando datos de importancia a la vista de los más curiosos. La solución a esto es bastante clara, otorgar las restricciones pertinentes.
    • Los datos son almacenados sin aplicarse ningún esquema de cifrado, de forma que el usuario que tenga acceso a ellos se lleva el premio gordo. Esto sigue siendo uno de los principales problemas desde mi punto de vista, se hace necesaria una capa de protección que cifre el contenido importante del teléfono.
    • Toda aplicación antes de ser lanzada, ha de pasar por unos mínimos de calidad. Estos problemas se hubieran evitado si se hubiera realizado un análisis exhaustivo de la misma antes de hacerla pública. Un mal ejemplo que deja en evidencia una empresa importante como Skype.

    Evidentemente todo esto podría haberse evitado, ¿pero es un error que sólo comete Skype?

    A mí las cosas me gustan claras

    Podríamos pensar que esto es un hecho aislado y que está todo bajo control, pero si nos aventuramos a realizar un forense al teléfono podemos llevarnos más de una sorpresa. ¿Están nuestros datos protegidos?.

    Para llevar a cabo nuestro análisis vamos a utilizar el SDK de Android que trae consigo la herramienta ADB. Otra opción es también montar un servidor SSH en el teléfono con la aplicación QuickSSHd y conectarnos en remoto desde un equipo, pero las transferencias al realizar movimientos de ficheros son más lentas.

    Para ver los dispositivos conectados utilizamos:

    sebas@Helios:~/Android/sdk/platform-tools$ ./adb devices
    List of devices attached
    emulator-5554 device 
    HT07DP800223 device
    

    En este caso estoy corriendo un Nexus One con id HT07DP800223 y un emulador para las pruebas. Vamos a centrarnos en el primero.

    Estructura interna

    Cuando levantamos una shell a nuestro teléfono y solicitamos un listado del directorio raíz observamos:

    sebas@Helios:~/Android/sdk/platform-tools$ ./adb -s HT07DP800223 shell
    $ ls
    config
    cache
    sdcard
    acct
    mnt
    d
    etc
    system
    sys
    sbin
    proc
    init.rc
    init.mahimahi.rc
    init.goldfish.rc
    init
    default.prop
    data
    root
    dev
    

    Si echamos un vistazo a cómo está montado el sistema de ficheros:

    $ mount
    rootfs / rootfs ro,relatime 0 0
    tmpfs /dev tmpfs rw,relatime,mode=755 0 0
    devpts /dev/pts devpts rw,relatime,mode=600 0 0
    proc /proc proc rw,relatime 0 0
    sysfs /sys sysfs rw,relatime 0 0
    none /acct cgroup rw,relatime,cpuacct 0 0
    tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
    none /dev/cpuctl cgroup rw,relatime,cpu 0 0
    /dev/block/mtdblock3 /system yaffs2 ro,relatime 0 0
    /dev/block/mtdblock5 /data yaffs2 rw,nosuid,nodev,relatime 0 0
    /dev/block/mtdblock4 /cache yaffs2 rw,nosuid,nodev,relatime 0 0
    /sys/kernel/debug /sys/kernel/debug debugfs rw,relatime 0 0
    /dev/block/vold/179:1 /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
    /dev/block/vold/179:1 /mnt/secure/asec vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
    

    Podemos observar que existen varios puntos de montaje en distintos mtdblocks para cada directorio importante en nuestro teléfono. Así tenemos:
    • /system en /dev/block/mtdblock3
    • /cache en /dev/block/mtdblock4
    • /data en /dev/block/mtdblock5
    En caso de tener una tarjeta SD externa vemos como esta es montada en /sdcard.

    Este subsistema de ficheros es conocido como Memory Technology Devices (MTD) y se caracteriza por embeber y dividir el sistema en un medio flash a diferencia de dispositivos de bloque tradicionales como podemos encontrar en cualquier equipo corriente. Llegados a este punto observamos que la nomenclatura utilizada es muy tradicional a los discos IDE o SATA, siendo en este caso utilizada /dev/mtd*

    Si queremos obtener más información podemos consultar el /dev y obtenemos:

    $ ls /dev/mtd*
    mtd5ro
    mtd5
    mtd4ro
    mtd4
    mtd3ro
    mtd3
    mtd2ro
    mtd2
    mtd1ro
    mtd1
    mtd0ro
    mtd0
    

    Podemos distinguir para cada dispositivo que tiene asociado un ro (Read Only) Por lo que si deseamos hacer una correlación y traernos al equipo el punto de montaje a analizar tendrá que ser aquel que no sea de lectura sólo, para ello utilizaremos el comando dd:

    # dd if=/dev/mtd/mtd5 of=/sdcard/data/mtd5.img bs=2048
    100480+0 records in 
    100480+0 records out
    205783040 bytes transferred in 108.504 secs (1896547 bytes/sec)
    


    Nos traemos el fichero a nuestro entorno de trabajo con el comando pull:

    sebas@Helios:~/Android/sdk/platform-tools$ sudo ./adb pull /sdcard/data/mtd5.img /home/sebas/Android/research/mtd5.img
    1799 KB/s (205783040 bytes in 111.650s)
    

    Ahora podemos comenzar la investigación buscando strings que nos revelen información como claves, base de datos o nombres de usuarios:

    sebas@Helios:~/Android/research$ strings -a ./mtd5.img | grep databases | more
    
    ...
    /data/data/com.android.providers.contacts/databases/contacts2.db-journal
    /data/data/com.google.android.gsf/databases/talk.db-journal
    /data/data/com.google.android.gsf/databases/talk.db-mj157DA2E7
    ...
    

    Sabemos que en el directorio /data/data vamos a tener todas aplicaciones instaladas con sus respectivas bases de datos. Será más fácil para trabajar traernos todo el directorio al completo a local.



    Facebook, Tuenti, Youtube, Google Apps, MMS, contactos, Tweetdeck. Toda la información de acceso se encuentra en sus respectivas bases de datos, aunque algunas están vacías porque nunca he acabado usando la aplicación. ¿Qué pasaría si perdiésemos nuestro teléfono?

    Por ejemplo Tuenti:


    A pesar de que nuestro password está cifrado utilizando MD5, sería relativamente cuestión de tiempo y GPU realizar un ataque de fuerza bruta o combinado con diccionarios para romper la clave.

    Más ejemplos así podemos encontrarlos en Facebook:



    Otras veces no es ni necesario consultar a la base de datos, podemos encontrar en shared_prefs un fichero XML en el que se incluye información interesante.

    Por ejemplo este caso de la aplicación Delicious:


    Si piensas que únicamente sucede con las aplicaciones, miremos los SMS a ver cómo se muestran:



    Conclusiones

    Cada vez es más habitual que los usuarios de smartphones lleven su vida digital sincronizada a su teléfono con el considerable volumen de información que ello conlleva.

    Emails, redes sociales, agendas, contactos, calendarios, son expuestos automáticamente en caso de perder el dispositivo. Alguien con bajos conocimientos puede perfectamente extraer todos los datos que le interesen y utilizarlos como mejor le convenga.

    El problema no viene evidentemente del usuario, sino de los propios desarrolladores que permiten utilizar sus aplicaciones sin forzar el uso de cifrado y contraseñas.

    Diversos motivos son los que mantienen enfrentados a detractores y defensores, ¿Es necesario realmente proteger nuestros datos?, ¿A qué coste?, ¿Cifrado completo o parcial de los datos?, ¿Compensa tener más cercana nuestra vida digital sabiendo el peligro que corremos?

    De soluciones se ha hablado mucho, utilizar sqlitecrypt, cifrar los datos que se almacenan en la BD y utilizar una clave maestra para descifrarlos cuando se sirvan a terceros, lvm-crypt. Pero nunca se llega a un acuerdo entre eficiencia y rendimiento.

    En lo personal, creo que a día de hoy, nuestros teléfonos son los sustitutivos de nuestros equipos personales cuando no nos encontramos en casa, el trabajo o dónde sea. Y cada vez el flujo de datos e información que es manejado es mayor, aumentando así la responsabilidad en la protección y cuidado de los mismos. Un claro ejemplo podemos citarlo con Blackberry cuyas comunicaciones van cifradas. ¿Cuánto tiempo pasará hasta que se sucedan los típicos leaks?


    ---------
    Contribución por Sebastián Guerrero
    Leer más...

    25 abril 2011

    Vulnerabilidad en eyeOS 1.x

    eyeOS es, para el que no lo conozca, un escritorio virtual accesible desde navegadores web basado en la nube en el cual podemos realizar infinidad de tareas, entre las que se encuentran almacenamiento de ficheros, ejecución de aplicaciones, gestión de usuarios y permisos y un largo etcétera. Al ser software libre podemos descargarlo para instalar nuestro propio servidor independiente.

    Actualmente existen dos ramas, la 1.x, que ha sido la rama estable durante bastante tiempo, y la nueva rama 2.x donde se centra el desarrollo principal en este momento.

    En este artículo vamos a ver un fallo de seguridad que afectaba a toda la rama 1.x de eyeOS, la rama 2.x no es vulnerable. Después de ponernos en contacto con el equipo de desarrolladores, la vulnerabilidad ya está solucionada en la última versión, lanzada hace sólo unas horas. Destacada la seriedad, entrega y rápida respuesta por parte del equipo, especialmente de Lars Knickrehm, de nota.

    Aquí podéis encontrar el advisory que fue enviado.

    Los ficheros y sus extensiones, no todo es lo que parece

    Cuando un usuario sube un fichero a eyeOS, el tipo de fichero únicamente es determinado por la extensión que éste posea. Es decir, un fichero .jpg será una foto, y un .doc un documento con formato. Esto es, en cierto modo, un problema, ya que el fichero será abierto con las aplicaciones para su formato según la extensión, aunque no sea realmente la aplicación adecuada. Posteriormente las aplicaciones podrán tener su propio filtrado.

    Por ejemplo, podemos subir una foto renombrando su extensión a .doc, y cuando la abramos en eyeOS, intentará ser abierta con el visor de documentos en lugar del visor de imágenes.

    El visor de imágenes

    Para visualizar imágenes en eyeOS utilizaremos el visor que tiene integrado. Cuando abrimos una imagen se crea un nuevo frame HTML que contiene el fichero de imagen puro, y nuestro navegador se encarga de mostrarla.


    Explotación

    Entonces, ¿que pasaría si subimos un fichero HTML con extensión de fotografía y lo abrimos? La lógica nos dice que será abierto con el visor de imágenes en un nuevo frame, por lo que el navegador lo interpretará. Vamos a subir el fichero xss.png que contiene lo siguiente:

    <!doctype html>
    <script>alert("XSS done");</script>

    Lo abrimos en eyeOS y ...


    Es una vulnerabilidad de tipo XSS persistente, hemos inyectado código que queda almacenado en el sistema por medio del fichero de imagen, y que al ser abierto se ejecuta.

    Un usuario malintencionado lo podría utilizar para, por ejemplo, programar un malware que se propague por el sistema mediante ficheros compartidos y mensajes internos entre los usuarios, o para incrustar exploits de navegadores que intenten comprometer los equipos del resto de usuarios.

    Se pueden tomar medidas para mitigar los efectos, como deshabilitar los directorios compartidos, o descargar en el equipo los ficheros de imagen para verlos, en lugar de abrirlos directamente. Aunque por supuesto la opción más eficaz es, siempre que se pueda, actualizar a la última versión.
    Leer más...

    24 abril 2011

    Enlaces de la SECmana - 68


    Leer más...

    22 abril 2011

    ETHERNET EXPOSED: Encuentra tomas de red al descubierto

    Os vamos a proponer una especie de juego, en el que esperamos recibir muchas contribuciones por vuestra parte, ahora que resulta tan sencillo el realizar fotografías de gran calidad con dispositivos que tenemos en el bolsillo en cualquier lugar.

    No es extraño que, al visitar sitios en los que vamos a estar más de 10 minutos, saquemos nuestro smartphone preferido y nos pongamos a buscar redes wireless. Esperamos que haya alguna abierta, con ESSID "default" o "WIRELESS" y demás, o directamente por curiosidad, por saber qué routers nos rodean.

    ¿Qué os proponemos? En vez de buscar redes wifi en el exterior o en cualquier local...busquemos tomas ethernet, ¡que también tienen su derecho! En vez de buscar routers Wi-Fi colgados como si fueran cuadros  o colocados detrás de botellas de alcohol en algunas bares, miremos al suelo buscando cajetines con su correspondiente toma ethernet.

    ¿Os creéis que ya no se lleva? ¿Que nadie podría dejar estas tomas al descubierto? A continuación os dejo una imagen, de un conocido restaurante en el que sirven unas bacon-cheese-fries de escándalo, de un cajetín al lado de la caja registradora:


    En la siguiente, unos grandes almacenes de ropa deportiva, que riman con triathlon:


    Estas tomas pueden encontrarse por ejemplo, en zonas dónde se hayan colocados kioskos virtuales, puestos informativos, servicios online de la propia tienda, cajeros...Yo os pregunto...¿qué creéis que ocurriría si os diese por coger un netbook y conectaros a la red con un cable de red a dichas tomas? ¿Habrá DHCP? ¿Qué mundo nos encontraríamos? Si recibimos muchas aportaciones por vuestra parte, quizás podamos introducirnos en el mundo de la seguridad en redes locales, 802.1X...

    ¡Mandadnos fotos o incluso videos que muestren casos de "Ethernet Exposed"! Ya sabéis nuestra dirección de correo electrónico:

    Leer más...

    20 abril 2011

    Nuevo Rootkit ataca el sector de arranque (Rookit.Win32.Fisp.a)

    Desde hace unos días podemos leer en determinados blogs, artículos que advierten de que un rootkit de origen chino está siendo diseminado por la red. Los laboratorios Kaspersky lo identifican como Rookit.Win32.Fisp.a.

    Esta vez la propagación se da a través de un vídeo colgado en una falsa web de porno china. Según lo publicado, una vez ejecutado el malware sustituye el sector de arranque por una versión modificada. Cuando se reinicia el dispositivo, el proceso troyano toma control del dispositivo y finalmente vuelve a escribir la versión original del MBR, del cual previamente ha hecho un backup.

    Otra de las técnicas que incorpora es una búsqueda de procesos relativos a antivirus, para ello dispone de una lista de cadenas que emplea para dicha búsqueda. Si detecta la presencia de algún proceso relacionado intenta detenerlo. 

    La lista de cadena que incorpora es la siguiente:

    Beike, Beijing Rising Information Technology, AVG Technologies, Trend Micro, BITDEFENDER LLC, Symantec Corporation, Kaspersky Lab, ESET, spol, Beijing Jiangmin, Kingsoft Software, 360.cn, Keniu Network Technology (Beijing) Co, Qizhi Software (beijing) Co.

    Hasta donde hemos podido conocer, se utiliza la típica técnica de recopilación de información del ordenador, y posterior envío de dicha información mediante una petición HTTP con la siguiente estructura:

    http://ab.*****.com:8081/tj.aspx?a=Windows XP Service Pack 2&b=192.168.0.16&c=00-00-00-00-00-00&f=none&g=none&k=a&h=62&i=2&j=0321-01

    Donde podemos ver que se están enviando al servidor de la botnet datos como pueden ser la versión del Sistema Operativo, la dirección IP en la red interna, etc. 

    Determinadas fuentes relacionan el rootkit con el robo de credenciales de juegos online, si bien en los informes que hasta la fecha se han publicado no se presentan evidencias de que el troyano intercepte peticiones para robar credenciales, haga búsquedas en ficheros o cualquier otro tipo de actividad dañina para los usuarios infectados.

    Una limitación a la hora de remover el troyano del sistema es el hecho de que éste controla el sistema operativo antes de cargar el motor antivirus en memoria, lo cual dificulta las tareas de detección y eliminación.

    [+] Referencias
    The Chinese bootkit (Securelist.com)

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

    Contribución gracias a Sergi Roselló León
    sergirosello.com
    Leer más...

    19 abril 2011

    Mitos de HTTPS y la navegación segura

    Las siglas HTTPS (Hypertext Transfer Protocol Secure) han generado siempre confusión, ya que bajo el paraguas de la "S" de seguro siempre se han escondido mitos sobre lo que realmente significa e implica.

    Con la entrada de hoy, a modo "Cazadores de Mitos", espero aclarar algunas de estas confusiones y que poquito a poco, todos  naveguemos mejor informados.

    Las páginas bajo HTTPS no se almacenan en la caché del ordenador.

    Es común asociar HTTPS a información sensible, son siempre las páginas más delicadas y en las que más capas de seguridad se aplica las que contienen datos confidenciales, como datos de carácter personal,  o bancarios.

    En teoría todo lo que se transmita por HTTPS y sea sensible el propio servidor debería identificar que no se cacheé, de esta forma se optimizaría las peticiones al igual que ocurre con HTTP.

    Imaginemos que me conecto a un banco y este no especifica que la información no ha de cachearse localmente, si visito este banco desde un ordenador público, otro usuario podría consultar la cache del navegador y conocer mis movimientos u otros datos confidenciales. Esto es considerado una vulnerabilidad, pero aún hay miles de webs en las que se produce esta problemática

    Está por lo tanto en manos del navegador definir qué hacer con el contenido pedido bajo HTTPS. Internet Explorer, salvo lo indique el servidor, por defecto usará la caché, aunque tiene una opción para deshabilitarlo y que nunca almacena datos, tal y como se comenta en el siguiente artículo: HTTPS Caching and Internet Explorer.

    Para configurarla, tan solo hay que ir a "Herramientas"->"Opciones de Internet" y en la pestaña "Avanzado", seleccionar "No guardar las páginas cifradas en el disco"


    En Firefox, depende de la versión del navegador tiene un funcionamiento u otro, hasta el 2010 han tenido abierto un bug donde han discutido este funcionamiento. Actualmente las páginas son cacheadas si el servidor no dice lo contrario, al igual que hace Internet Explorer. Se puede controlar este comportamiento mediante la directiva: cache.disk_cache_ssl

    La siguiente imagen muestra un elemento cacheado que se sirvió por SSL.



    En el caso de Opera, las páginas cacheadas de HTTPS son eliminadas al cerrar el navegador. Definido en la opción: Cache HTTPS After Sessions

    Chrome cachea las páginas como el resto y no permite modificar este comportamiento, salvo se use una extensión, como ya comentamos anteriormente en: Extensiones para navegar más seguro con Chrome

    Si hay HTTPS puedo mandar cualquier cosa en las Cookies o en la petición (URL)

    Todos los datos confidenciales deben ser enviados utilizando el método POST, ya que si existe información confidencial en la propia URL, está quedará almacenada en múltiples sitios, como el historial del navegador, los registros del proxy, o los registros del propio servidor donde llegan las peticiones, como ocurre con HTTP.

    Aunque la conexión se establezca utilizando SSL, las sesiones han de ser configuradas para que no puedan ser enviadas utilizando otros canales. Tal y como comentamos en "Sesiones seguras: es gratis", se ha de establecer el parámetro "secure".



    Hace falta un certificado SSL para cada dirección IP, domonio o subdominio.


    Existen muchas opciones y alternativas que permiten versatilidad con los certificados SSL y su instalación y configuración.

    Un único certificado SSL que soporte wildcards, podrá ser instalado en todos los subdominios que queramos.

    Server Name Indication extiende el protocolo de SSL y TLS permitiendo que el "CN" sea solicitado en la negociación TLS, dejando al servidor presentar el certificado correcto en base a la consulta que reciba.

    Mediante Unified Communications Certificate (UCC), es posible incluir varios dominios distintos en un único certificado. En caso de que compartamos IP con otras aplicaciones y otros clientes.


    Los certificados SSL son muy caros y dificiles de conseguir

    Algunas compañías no usan SSL porque piensan que adquirir uno tiene un precio muy elevado. Esto no es así. Hay certificados incluso gratuitos como los que ofrece StartSSLComodo.o CACert.

    Se pueden adquirir otros productos, con garantía o que permiten wildcards, desde 10$ anuales. Un precio asumible para cualquier compañía que tenga presencia y venta de productos online.




    HTTPS es muy lento.


    Sobre este mito hay aún debates abiertos. Uno de ellos es el que mantiene Adam Langley de ImperioViolet con el fabricante de aceleradores SSL F5. El primero ofrece argumentos  por lo que la negociación SSL hoy por hoy se puede asumir económicamente. F5 (entre otras cosas, vendedor de aceleradores SSL) responde con unas tablas de pruebas y explicando que las pruebas de Adam son con certificados 1024-bit y no con los 2048-bit. Finalmente Adam opina que las pruebas de F5 no son reales, ya que están hechas con portátiles y no con servidores.

    Lo único que hay que transmitir vía HTTPS es la información sensible, como el usuario y contraseña.

    Si algo hemos aprendido todos con FireSheep es que no es necesario tener las credenciales de un portal para acceder con la cuenta de otro usuario. Basta con robarle la sesión y asignarla a nuestro navegador.

    Por ese motivo, si una web requiere autenticación y trata datos confidenciales, todas las páginas que se sirvan  han de ser única y exclusivamente vía HTTPS.


    El usuario debería elegir si quiere utilizar o no HTTPS.


    Volvemos a lo de siempre: Seguridad Por Defecto (SbD). Me gustaría no tener que explicarle a nadie porque debe usar HTTPS y no HTTP. La seguridad ha de ser impuesta, evitará problemas.

    Si a un usuario únicamente le dejas acceder al servicio mediante el protocolo seguro, con certeza jamás hará una transacción por otra vía. No debe ser una opción y mucho menos una opción deshabilitada por defecto.


    Me puedo fiar de la web si hay un candado en mi navegador.

    El candado que se muestra en el navegador solo indica que el certificado SSL es válido, no que la entidad que dice estar detrás es la auténtica. Generalmente informa que la los datos serán transmitidos de forma cifrada. Pero insisto nuevamente: no garantiza la autenticidad de la compañía en la que está alojado.

    Yo puedo crear un certificado SSL válido para "paipal.com" y hacerme pasar por Paypal, y el navegador mostraría el candado correctamente. Yago escribió sobre esto y lo demostró en un magnifico artículo: Fraude online con firma digital y SSL. Comprobar que la dirección y el dominio son correctos, es tarea que ha de hacer el usuario manualmente.




    Las páginas que tienen HTTPS no tienen problemas de seguridad.

    Fuera de este mundo, para el usuario final y no experto posiblemente el mayor mito es que las páginas que se alojan en un servicio que contiene HTTPS ya son seguras en todos sus aspectos. Ignorando que la seguridad que proporciona HTTPS no afecta a la calidad del código de las páginas web, solo al canal por el que son transmitidas. Un banco, una red social, el correo electrónico o cualquier otro servicio web no está libre de fallos por el mero hecho de publicarse mediante el protocolo seguro de HTTP.

    Leer más...

    18 abril 2011

    Anti Rootkits para Windows

    Hace un tiempo hablábamos sobre herramientas anti-keyloggers analizando unas cuantas, hoy le toca el turno a un par de herramientas anti rootkits: NoVirusThanks Anti Rootkit y GMER.

    Lo primero que hay que decir sobre estas herramientas es que no son, en absoluto, para un público de 'propósito general'. Tal vez la herramienta de NoVirusThanks sea mas intuitiva pero aun así se requiere background para comprender la información que ofrecen.

    El funcionamiento de ambas herramientas consiste en radiografiar ciertas partes del sistema, por lo que luego hay que interpretar y discernir que es una amenaza y que no

    Aunque ambas herramientas permiten identificar múltiples tipos de amenazas, la funcionalidad mas interesante es poder identificar si un sistema está comprometido bien por rootkits a nivel Ring-3 (generalmente usando API-Hooking) o por sistemas mas sofisticados en Ring-0 (cargando drivers en el sistema)

    La herramienta de NoVirusThanks es bastante fácil de utilizar:


    Permite seleccionar el tipo de scan a realizar y una vez realizado el scaneo, la información se presenta bastante bien categorizada.

    Como se puede ver en esta captura, en el sistema donde se ha realizado el análisis se encuentra instalado Messenger-Plus que establece una serie de hooks para funcionar:


    Como decía al principio, es necesario interpretar los resultados, en este caso viendo las funciones 'hookeadas' y quien hace los hooks podemos inferir que no representan amenazas.

    La herramienta de NVT también identifica los BHO (Browser Helper Objects) que son DLLs que se añaden a InternetExplorer para dotarle de mas funcionalidad (y que en su vertiente maliciosa pueden servir para capturar la navegación o modificar formularios)


    En el caso de GMER hay menos funcionalidades y la presentación es claramente inferior. El único aspecto que supone un avance frente a la herramienta de NVT es que no requiere instalación y cuando se hace el download, genera un nombre aleatorio para el ejecutable, lo que en teoría permite que un proceso malicioso no pueda localizar y eliminar a GMER. En la práctica, hay muchos mas vectores que podrían ser usados por un proceso malware para hacer el fingerprinting de GMER.

    En esta captura GMER muestra los hooks de Messenger-Plus. Como se puede apreciar la información es menos intuitiva que la ofrecida por NVT

    Leer más...

    17 abril 2011

    Enlaces de la SECmana - 67


    Leer más...

    16 abril 2011

    Wargame II - Campus Party Valencia 2011

    Campus Party celebra su décimo quinto aniversario de una forma especial. Todas las áreas tendrán grandes novedades y apuestas muy interesantes que harán que este año no sea uno más.

    En el área de seguridad ya está cerrada la agenda de ponentes y actividades. Lo más destacable por nuestra parte es la posibilidad de participar en el reto de hacking desde Internet. Algo que en otras ediciones se ha solicitado siempre. Sin olvidar que tendremos una ponencia del inolvidable Kevin Mitnick.

    Para rematar, Yago y Lorenzo harán una presentación de los Hackeos Memorables más destacados, algunos de los tratados en este blog y otros de los que aún no hemos hablado. 

    Además, a diferencia de la I edición del wargame que organizamos a principios de año, hemos decidido  llegar a mucha más gente y que todos los participantes puedan terminar el concurso. Por lo que las pruebas estarán enfocadas a un público más general que esté iniciándose en este mundo.

    Por si fuera poco, los premios serán muy atractivos, con 1.000€ y hardware valorado en 2.000€ para el primer puesto, 600€ para el segundo y 400€ para el tercero.

    El concurso comenzará y terminará dentro de las fechas de la Campus. Es decir del 11 al 17 de Julio, pero ya podéis inscribiros en la página web del reto: http://www.campus-labs.com/webapp/reto/ver/seg_war#

    Para finalizar, agradecerle a Campus Party que haya vuelto a confiar por cuarta vez en nosotros para esta tarea y como no, a ESET, patrocinador del área de seguridad.
    El hashtag oficial del wargame será #wgsbd2
    Leer más...