30 enero 2014

Integración de Process Explorer v16 con Virus Total



Lo venía anunciando el propio creador de la suite de SysInternals Mark Russinovich en un tweet hace semanas, sobre que estaba trabajando en incluir el análisis de los procesos en ejecución del sistema contra el servicio de Virus Total, para poder detectar malware en ejecución en nuestro sistema sin realizar el análisis manual a través de su servicio online.





Tweet de Mark Russinovich: "Trabajando en la integración de Process Explorer con Virus Total"
El día ya ha llegado después de este anuncio anterior al día de reyes: ya está disponible la versión 16.0 de Process Explorer que incluye la integración con Virus Total para análisis de procesos en ejecución.

La descripción completa de esta nueva versión es la siguiente:

Process Explorer v16.0: Gracias a la colaboración con el equipo de Virus Total, esta actualización de Process Explorer introduce la integración con VirusTotal.com, un servicio de análisis online de antivirus. Cuando se encuentre habilitado, Process Explorer envía los hashes de las imágenes y ficheros mostrados en el proceso y las vistas DLL a VirusTotal y si hubieran sido previamente analizadas, informaría cuantos motores de antivirus lo identificarían como supuestamente maliciosas. El resultado (que incluye enlace) nos dirigiría al informe en la propia VirusTotal.com e incluso se podría enviar ficheros para su análisis.

Tras descargar esta nueva versión de la aplicación, podremos observar una nueva columna en la aplicación dedicada a recoger los resultados de VirusTotal una vez analizado el proceso:

Nueva columna en Process Explorer para resultados de Virus Total

Al hacer clic con el botón derecho del ratón en cualquier proceso, veremos una nueva opción denominada "Check VirusTotal" que, al ser pulsada, comenzará con el envío del hash de la imagen del proceso. Una vez finalizado el análisis, veremos el resultado en base a los motores de antivirus disponibles en este servicio online:

Opción por proceso para comprobar hash en VirusTotal

El búsqueda del hash del proceso jusched.exe sobre VirusTotal reporta 0 detecciones por parte de 50 motores
La aplicación no funciona bajo demanda únicamente, y también es posible que la propia herramienta realice el análisis de todos los procesos de forma paralela, obteniendo los resultados en la interfaz cuando hubiesen finalizado. Para ello, es necesario activar dicha opción desde el menú de Opciones -> VirusTotal.com -> Check VirusTotal.com


Tras finalizar el análisis, cualquier de los binarios que resultasen desconocidos para VirusTotal, serían marcados como tal en Process Explorer, permitiendo su subida de forma automática para realizar su primer análisis.

Sin duda, esta nueva funcionalidad nos ahorrará muchísimo tiempo en análisis propios del sistema en caso de que notemos que alguno de los procesos realiza un comportamiento anómalo o si su nombre pudiese ser sospechoso. En caso de tener alguna duda, es posible realizar la subida del binario directamente desde la interfaz de Process Explorer. 

Leer más...

29 enero 2014

Ingeniería inversa del juego Pixel Dungeon para Android

He desempolvado uno de mis juegos favoritos de Android, el rogue like Pixel Dungeon.



La propuesta del juego es sencilla: elige una clase de personaje y profundiza a lo largo de múltiples niveles de mazmorras enfrentándote a trampas, enemigos y jefes de mazmorra cada vez más complicados mientras que por el camino recolectas armas, armaduras, pociones, pergaminos y todo tipo de objetos que intentarán servirte en tu ayuda, pero que sólo dilatarán una muerte que llegará tarde o temprano (más temprano que tarde, por cierto).
Y después de esta introducción vamos a lo que nos ocupa, una de sus últimas actualizaciones, la clase cazadora:


Como podéis leer en la descripción del personaje, el juego nos reta indicándonos que únicamente podremos jugar con esta clase una vez que hayamos superado al jefe de mazmorra del nivel 3, jefe al que no he tenido el gusto de conocer porque lo normal es una muerte prematura varios niveles antes de llegar a él..., así que intentamos resolver este problema con otro acercamiento: la ingeniería inversa.

Notas de partida

  • Si no habéis jugado previamente, además de descargarlo es necesario que juguéis y desbloqueéis algún logro para que se genere un fichero que necesitaremos. Los logros más sencillos se obtienen al matar 10 enemigos o recolectar 100 monedas. Se puede confirmar si has desbloqueado logros desde la opción "Badges" del menú principal.
  • El dispositivo Android tiene que estar rooteado ya que accederemos a ubicaciones del sistema de ficheros a los que de otro modo no tendremos acceso
  • El dispositivo Android tiene que encontrarse en modo depuración y con su driver correctamente configurado para que ADB sea capaz de identificarlo:


Paso a paso

1. Cerrar el proceso del juego en el dispositivo Android en caso de que se encuentre en ejecución.

2. Lo primero que tendremos que hacer es obtener el nombre del APK del juego, utilizaremos ADB para esto:


3. Obtenemos la ruta de instalación del APK utilizando el paquete que nos ha indicado la salida el anterior comando:


4. Descargamos el APK desde la ruta que hemos obtenido:


5. El siguiente paso es convertir el fichero APK en JAR, para ello utilizaremos la herramienta dex2jar:


6. En el JAR tenemos los ficheros .class, para decompilarlos podemos utilizar la herramienta gráfica jd-gui. Es suficiente con abrirla y arrastrar sobre ella el fichero .JAR:



7. Ahora que tenemos el código en nuestro poder vamos a buscar parte de la cadena de texto que nos muestra el juego y en la que nos indica que la cazadora está bloqueada, para ello hacemos lo siguiente: Menú Search > Search > Seleccionamos todas las opciones y escribimos "unlock":



8. El resultado de esta búsqueda nos muestra la clase StartScene, donde revisando las variables encontramos "TXT_UNLOCK", donde está la cadena que leemos en el juego;  y "private boolean huntressUnlocked", que suena bastante prometedor ¿verdad?:



9. Al ser "huntressUnlocked" una variable privada, buscamos sus asignaciones dentro de la clase y encontramos el siguiente código en el metodo create():


10. Como vemos, se invoca el método isUnlocked(...) de la clase Badge. Si le damos un vistazo a la clase  Badge encontramos en una de las variables el fichero de logros:



11. Descargamos el fichero de logros de la ubicación por defecto para los ficheros creados por una aplicación Android ( /data/data/<app>/files/ ), en nuestro caso "/data/data/com.watabou.pixeldungeon/files/":


12. ¡Perfecto!, abrimos el fichero en un bloc de notas y nos encontramos el siguiente formato:


13. Como vimos en el paso 9, se realizaba una comprobación de si se disponía del logro "Badges.Badge.BOSS_SLAIN_3", asi que volvemos a jd-gui y buscamos en la clase Badges el enumerado "public static enum Badge":


14. En el recuadro en rojo tenemos el logro que espera el juego para activar el booleano de "huntressUnlocked", así que añadimos el valor a la colección de logros del fichero "badges.dat" que hemos descargado y lo guardamos:


15. Hacemos push del fichero modificado al sistema de ficheros del dispositivo:


16. Iniciamos el juego y nos vamos al menú de personajes y... ¡habremos desbloqueado a la cazadora!


Happy hunting ;)


Artículo cortesía de Miguel Ángel García
Leer más...

28 enero 2014

Entrevista a Alberto Ortega, analista de malware

Alberto, en su lucha diaria con
los zombies
Hoy tengo el inmenso placer de poder entrevistar a Alberto Ortega, amigo personal y una de las personas más sorprendentes con las que he tenido el placer de colaborar.

Conocí a Alberto hace unos cuantos años en un evento de Panda, se acercó y con un toque de humildad y timidez se puso a hablarme de PenTBox, una suite de herramientas ofensivas escritas en Ruby. Tras esa charla, Alberto entró directamente al radar como persona a seguir.

Posteriormente logramos convencerlo para que fuese colaborador de Security By Default, donde nos brindó unos post con mucho nivel, también fue uno de los referentes del grupo 'aw3a' y estuvieron compitiendo con mucha soltura en varios CTFs.

Hoy día es analista de malware en AlienVault y una de las personas que siempre viene a mi cabeza cuando pienso en análisis de malware.

1- Mucha gente ya te conoce, pero para aquella minoría que aun no te conozca, cuéntanos quién eres y qué haces

Me llamo Alberto, vivo en Madrid, y desde que empecé a estudiar me he centrado en la informática. Ya le dedicaba mucho tiempo antes, pero cuando se empieza con los estudios y especialmente a trabajar de ello, la cosa cambia bastante, o al menos lo hizo para mí.

Siempre me ha apasionado que sea un campo en el que muchísima gente aporta diariamente contenidos para el público, y muchas veces sin intenciones de conseguir nada a cambio. Buen ejemplo de ello es la cantidad de software libre e investigaciones publicadas que tenemos disponibles, y su calidad.

Cuando tengo tiempo y surge, también juego algún que otro CTF, o toqueteo algún cacharro.

A parte de esto, me gustan los videojuegos, el cine, viajar, ... lo típico supongo :)

2- Ahora mismo estás muy focalizado en el 'mundo malware', ¿Cual es tu opinión sobre el 'estado del arte' en este campo?

Por un lado, tenemos una industria de desarrollo y venta de malware 100% profesionalizada, y que se desarrolla íntegramente en Internet. La mayoría de las veces el comercio se lleva a cabo sin que las partes se conozcan (más que por referencias y un nick), y se cuidan bien de guardar el anonimato. Aún con todo esto, y el hecho de que gran parte sea ilegal, es un negocio que funciona muy bien, y hay muchísima gente dentro que no ha tenido ni tendrá nunca problemas con la ley.

Por el otro lado, tenemos todo el panorama de la "ciberguerra", el espionaje y demás, que ahora está muy de moda. Para los países es una herramienta, pero también hay empresas que están aprovechando el pelotazo. Ejemplos visibles de ello son VUPEN o Hacking Team. Aquí una presentación interesante del 30c3 sobre el tema, To Protect And Infect.

3- Las casas de Antivirus siempre se descuelgan con notas de prensa hablando de cientos de miles de programas malware que salen 'a diario' ¿Es realmente tan cuantiosa la amenaza?

¿Hablamos de desarrollos nuevos? :)

Si es así, no creo que las cifras sean tan escandalosas. Ahora bien, si contamos todas las pequeñas modificaciones, nuevas formas de empaquetar o distribuir el malware, ventas o intercambios que se producen cada día, contabilizamos cada carga maliciosa de un esquema típico de infección, etc, entonces seguramente se superen esas cifras con facilidad.

Personalmente creo que es una métrica muy "sonada" y muy poco concreta a la vez. Contabilizar el número de infecciones y el software que usaban las víctimas en el momento de la infección es mucho más real.

4- Una de las cosas más 'divertidas' a la hora de analizar malware es la forma en la que el creador trata de hacer la vida imposible al analista ¿cual ha sido el método que más te ha impresionado?

Recuerdo un truco que utilizaba una muestra dirigida que estuvimos analizando en su momento.

A los objetivos les llegaba un .doc que tenía un exploit para MS Office. Si se ejecutaba correctamente, se extraía un binario de Nvidia firmado digitalmente, una DLL de Nvidia también, y un fichero boot.ldr con datos binarios.

La situación era curiosa porque el binario y la DLL parecían totalmente legítimos. El truco estaba en el boot.ldr, que era interpretado por los dos anteriores y conseguía ejecutar la carga maliciosa, que resultó ser PlugX.

No es una técnica para hacer la vida complicada a un analista que tenga todo el esquema de la infección, ya que algo que ha salido de un exploit encontrado "in the wild" no puede ser bueno, pero sí causa que una vez infectado sea complicado darse cuenta de que un binario de Nvidia es lo que está ejecutando el malware.


5- Hace no mucho liberaste pafish, una prueba de concepto con muchas rutinas para detectar la presencia de máquinas virtuales y entornos de debug. Sin duda fue una apuesta valiente, pero ¿has recibido alguna crítica por hacer la vida más fácil a los creadores de malware?

En ese sentido no, creo que el objetivo del proyecto se ha entenido bastante bien en general. Es verdad que inicialmente levantó algunas ampollas en varios desarrolladores de software para hacer sandboxing de malware.

Pero estoy contento, porque aunque al principio no les gustara, luego les ha forzado a tener en mente éstas técnicas, que es la razón de ser del proyecto.

¿Respecto a malware que esté usando el código? Tengo a algunos fichados, pero es lo bueno, cómo es código propio es muy facil de detectar en los feeds que tenemos :)

Además he distribuido alguna firma para detectarlo, ya que entiendo que es algo potencialmente no deseado, y no todo el mundo quiere tenerlo en su $HOME_NET.

6- Ahora mismo estás en AlienVault, una de esas empresas con origen Español de la que estamos muy orgullosos, ¿Puedes contarnos interioridades de la empresa?

Te puedo contar que he conocido a gente muy buena dentro de la empresa, y que el porcentaje de gente brillante que está (y ha estado) allí es inusualmente alto.

Aunque de primeras no te impresione alguien, tarde o temprano te puede dejar alucinado, creo que es lo que más me gusta.

7- Si tratas de mirar en perspectiva de aquí a 5 años ¿Donde te ves? ¿Te planteas 'fugarte' al extranjero?

Difícil pregunta, de aquí a 5 años me veo todavía en seguridad (espero), y no sé si en el mismo área pero me gustaría que estuviera relacionada o fuera cercana a la que estoy ahora.

¿Extranjero? Bueno, creo que en seguridad aún con la que tenemos encima hay trabajo, lo que no quita que me apetezca salir de aquí :)

8- Con tu visión de persona relacionada con el malware, ¿Puedes darnos una previsión a corto plazo sobre como va a evolucionar?

Si tuviera que apostar por algo, diría que el mundo del crimeware no va a sufrir grandes cambios en su modelo, aunque sí en las técnicas, cómo ha venido haciendo constantemente desde hace tiempo, que no paran de evolucionar y mejorarse.

Y en la parte de malware de los gobiernos, creo que empezarán a exigir mucha más delicadeza a sus desarrolladores, en el sentido de que las piezas tarden mucho más en salir a la luz. Es algo que ya está pasando, pero seguro que mejorarán aún más.

9- Finalmente la pregunta más típica: Si alguno de nuestros lectores quiere ser como tú ¿De que forma tendría que empezar y cómo debería formarse?

Que se ponga a pulsar teclas, que al final es lo que vale. Y que colabore y publique, hay un montón de proyectos interesantes de todos los colores en Internet que puedes usar, modificar, mejorar, e incluso aportar a ellos, ésto es mucho más facil ahora que antes.

Muchas gracias Alberto, ha sido un placer el haber podido entrevistarte.

Podéis seguir a Alberto en twitter
Leer más...

27 enero 2014

Suplantación de identidad sobre el aire en redes GSM

Un poco de historia

Corría el año 2000 y el Canal Satélite Digital y VíA Digital estaban en pleno auge, igual que las tarjetas smartcard con un microcontralador PIC 16F8xx como las SilverCard y GoldWafer para "hackear" estos servicios. Todos teníamos un programador TE20 para poder escribir los datos en los microcontraladores y el TE21 o Phoenix para leer las tarjetas originales smartcard ISO 7816.

Entonces apareció él, se llamaba SIM EMU y era un programa que podíamos cargar en el PIC 16F84 para emular una tarjeta SIM. Para que la tarjeta fuese funcional 100% era necesario leer dos parámetros de la tarjeta SIM original; el IMSI y el número secreto Ki de 128 bit (wikipedia.org, apartado "Authentication key Ki"). Esto se podía hacer con el lector TE21 utilizando cualquiera de los programas disponibles: cardinal68, sim scan, etc (creo que todos ellos ya no están soportados por sus desarrolladores, pero se pueden encontrar gracias a Don Google). 

Fue cuando aprendimos el proceso "RUN GSM ALGORITHM" (el proceso encargado de generar la respuesta SRES (algoritmo A3) y la clave de cifrado Kc (algoritmo A8) al recibir un número aleatorio RAND de la red GSM, ver documento Specification of the Subscriber Identity Module - Mobile Equipment SIM - ME interface GSM 11.11) y que había dos tipos de tarjetas SIM; las que tenían implementada la versión 1 del algoritmo, llamado COMP128v1 y las nuevas con la versión 2; COMP128v2. Sólo podemos someter al ataque de fuerza bruta a aquellas tarjetas que tengan implementado el algoritmo COMP128v1, puesto que es el único que se consiguió romper.

Entonces se necesitaba acceso físico a la tarjeta SIM para poder suplantar la identidad de un usuario de la red GSM.


¿Qué ha pasado desde entonces hasta ahora?

Gracias a las nuevas herramientas para monitorizar el tráfico GSM (OsmocomBB, SDR, USRP...), podemos ver en nuestro wireshark cómo la red GSM y el terminal realizan el proceso de autenticación pero no desde el punto de vista de la tarjeta SIM, sino la señalización entre el equipo (ME) y la red GSM. Teóricamente cada vez que encendemos el teléfono y en determinadas circunstancias, como por ejemplo: hand-over entre celdas (nos desplazamos en coche y cambiamos de antena GSM), al activar servicios de la red GSM (realizar o recibir llamadas o mensajes) la red GSM nos debe solicitar autenticarnos en la red, enviando a nuestra SIM la petición "RUN GSM ALGORITHM".

¿Porqué no hacer un par de pruebas con cada operador para analizar el comportamiento de la red? ¿Cada cuánto tiempo solicita la red a mi móvil/SIM que se autentique? …¡¡ Manos a la obra !!

La herramienta seleccionada fue OsmocomBB corriendo en un portátil con Ubuntu (Layer 2 y 3) y en un Motorola C118 (Layer 1), de tal modo que puedo ver las trazas en el wireshark mientras me muevo y realizo llamadas. Cuando todo está listo, una vuelta por la M40 haciendo llamadas y enviando SMS.

osmocom lanza el firmware Layer1 en el móvil
motorola C118 corriendo firmware Layer1

aplicación "mobile", capa 2y3, solicita el PIN

wireshark recibiendo la señalización de nuestro móvil
Al analizar las trazas, la gran sorpresa es que no todas las redes (operadoras) tienen el mismo nivel de seguridad/rigurosidad con la autenticación. No voy a dar nombres, pero encuentro que en una red GSM, tras encender el móvil y realizar 3 llamadas, en ningún momento la red me ha solicitado autenticarme. Este caso más sangrante me lleva a seguir con una nueva prueba, un ataque de suplantación de identidad sobre el aire. Los TMSI circulan tranquilamente (sin cifrar) por el aire en mi celda … ¿Qué pasaría si programo una tarjeta SIM sólo con un TMSI y clave Kc de cifrado válidos?

Si un hipotético atacante quisiera conocer cuales son el TMSI , el Kc y la localización (celda) de una víctima a partir de su número de teléfono, es perfectamente posible y ya ha sido tratado en varias sesiones del Chaos Computer Club (27C3, 28C3 y 30C3).


En esta prueba no voy a utilizar un IMSI válido, lo que vamos a hacer es inventarnos un IMSI que la red reconozca como suyo (ojo al MNC) y que el resto de dígitos serán aleatorios, ídem para la clave Ki; aleatoria. Para llevar a cabo todo este proceso he utilizado un lector/programador de smartcards SCM SCR3310 con una tarjeta SIM programable sysmoSIM y el software cyberflex.



Debemos tener en cuenta todos los ficheros (EF) que residen en la SIM dentro del directorio (DF) GSM 7F20, y en particular el LOCI "6F 7E", es aquí donde vamos a poner nuestro TMSI objetivo, puesto que el fichero LOCI contiene concatenados el TMSI seguido del "Location Area Information", nuestra última posición conocida por la SIM. El LAI a su vez se compone de: MCC + MNC + LAC (Location Area Code). Para España el MCC es 214 y el MNC depende de la red (ver en Don Google). Os dejo algunos comando útiles para movernos por la SIM (para ver el listado completo ver la referencia anterior GSM 11.11):
STATUS: a0f2000002 (debemos comenzar la sesión siempre con status)
a0a40000023f00    (selecciona el MF)
a0a40000022fe2    (selecciona el EF ICC ID)
a0b000000a        (muestra el contenido)
a0a40000027f20    (selecciona el DF GSM)
a0a40000026f07    (selecciona el EF IMSI)
a0b0000009        (muestra el contenido)
a0a40000026f7e    (selecciona el EF LOCI)
a0b000000b
a0a40000026f20    (selecciona el EF Kc)
a0b0000009
a0a40000026f30    (selecciona el EF PLMN sel)
a0b0000096
El resultado: tras grabar los resultados a la tarjeta SIM programable, un primer intento falla: recibo LOCATION UPDATE REJECT. Vuelto a intentar y … Sorpresa !! Veo el nombre del operador en la pantalla del teléfono, me doy a prisa en llamar a mi amigo Ramón y … funciona, llamada con éxito, me he suplantado a mi mismo.


Conclusión

El resultado de esta prueba/ataque depende de muchos factores a tener en cuenta;

- Celda y Location Area: cada celda y cada LA tienen parámetros distintos, que funcione en una "zona" no quiere decir que vaya a funcionar en toda España (y viceversa)

- Configuración de la red: el tiempo de "refresco" de nuestra clave de cifrado Kc y del TMSI depende de cada red, es posible que durante nuestros ensayos la red solicite a la tarjeta SIM que se autentifique, pero al no tener un Ki válido, lógicamente será automáticamente rechazada la SIM y la clave Kc puesta a "FFFFF…."

- Para evitar estos ataques, no podemos hacer nada. Son el resultado de faltas graves de seguridad en la red GSM. Si un atacante no pudiese conocer mi TMSI u obtener la clave Kc a partir de una captura, la suplantación nunca podría funcionar. Si aún así, dichas claves se refrescasen en cada petición de servicio a la red GSM, la suplantación sería mucho más costosa, prácticamente imposible.

La conclusión más evidente es la falta de seguridad, a día de hoy, en las redes GSM. Si quereis ver cómo son de seguras las redes GSM, visitad la web GSMmap.

Artículo cortesía de Pedro Cabrera
Leer más...

26 enero 2014

Enlaces de la SECmana - 211


Leer más...

25 enero 2014

Primeros ponentes y acciones formativas de Rooted CON 2014


Dentro de un mes y una semana aproximadamente dará comienzo la quinta edición de Rooted CON 2014,  que tendrá lugar los días 6, 7 y 8 de Marzo en el Centro de Congresos Principe Felipe del Hotel Auditorium de Madrid.

Este año como novedad habrá dos tipos de acciones formativas. En primer lugar, los RootedLabs, que se celebran como cada año los tres días antes del congreso en diferentes localizaciones de Madrid, y de los que su registro comenzó esta misma semana:



Y como novedad, el día 5 y 6 de Marzo tendrá lugar la Corelan Bootcamp, un training intensivo de más de 12 horas cada día en el que Peter Van Eeckhoutte (corelanc0d3r) dará una clase magistral de explotación en Win32 que ha definido como "hardcore". Las plazas son muy limitadas y se agotaron muy rápidamente.


En cuanto al congreso, se acaban de anunciar ya los primeros ponentes y ponencias confirmadas para esta edición:

  • César Lorenzana y Javier Rodríguez – Por qué lo llaman APT´s, cuando lo que quieren decir es dinero
  • Jaime Sánchez y Pablo San Emeterio – WhatsApp, mentiras y cintas de video
  • Andrés Tarasco – Ataques dirigidos con APTs Wi-Fi
  • Youcef Bajaja y Juan Antonio Rivera – GiroAirHack:capturando radiofrecuencias con HackRF
  • Juan Vazquez y Julián Vilas – Tú a Boston Barcelona y yo a California Tejas, A patadas con mi SCADA!
  • José Luis Verdeguer y Víctor Seva – Secure Communications System
  • Borja Berástegui – Handware hacking – Si hay un ‘input’, hay peligro
  • Manu Quintans y Frank Ruiz – 50 shades of crimeware
  • Pau Oliva – Bypassing wifi pay-walls with Android
  • Aladdin Gurbanov – Magnetic Road
  • Jeremy Brown – Microsoft Vulnerability Research: How to be a finder as a vendor
  • Raul Siles – iOS: Regreso al futuro

Leer más...

23 enero 2014

Como cada año (ya desde hace 10), se celebran en la UPM las llamadas TASSI, siglas correspondientes con "Temas Avanzados en Seguridad y Sociedad de la Información", una asignatura de carácter optativa que se imparte en el Campus Sur de la Universidad Politécnica de Madrid, en la Escuela Técnica Superior de Ingeniería de Sistemas Informáticos y en la Escuela Técnica Superior de Ingeniería y Sistemas de Telecomunicación.


No es una asignatura típica, ya que corresponde con sesiones de entre 1 hora y 1 hora y media en las que se dan a conocer los últimos avances en materia de seguridad informática y protección de la información desde diversos puntos de vista: redes, datos, gestión, legislación, estándares. Y lo mejor y más destacable, es el elenco de profesores con los que se cuenta para cada una de las sesiones. Por allí han pasado Carlos Sánchez Almeida, José Parada, Antonio Ramos, nuestro compañero Alejandro Ramos que nos contó su experiencia el año pasado en este post, Román Ramirez, David Barroso, Chema Alonso, Sergio de los Santos y muchos más.

Lo mejor de todo es que, aún siendo una asignatura, la entrada es completamente libre y gratuita tanto para alumnos como para el público en general, así que si tienes oportunidad, no dejes escaparla.

El programa para el X Ciclo de Conferencias UPM TASSI (que se impartirán en la Sala de Grados 3005 de la ETSIST, con un aforo para 90 personas) es el siguiente:

Jueves 20 de febrero de 2014
Latch. Protección de identidades digitales - D. Antonio Guzmán (ElevenPaths)

Jueves 6 de marzo de 2014
Posibilidades del voto telemático en la democracia digital - D. Justo Carracedo (UPM)

Jueves 20 de marzo de 2014
Bitcoin: moneda y mercados - D. Jonás Andradas (GMV)

Jueves 3 de abril de 2014
Protección de comunicaciones en dispositivos móviles - D. Raúl Siles (DinoSec)

Jueves 24 de abril de 2014
Ethical hacking: afrontando una auditoría interna - D. Pablo González (ElevenPaths)

Jueves 8 de mayo de 2014
Técnicas de ocultación de información: esteganografía y canales encubiertos - D. Alfonso Muñoz (UC3M)

Jueves 22 de mayo de 2014
La amenaza del cibercrimen - D. Juan Salom (Guardia Civil)

Desde 2008, todas las sesiones han sido grabadas en video, y podéis consultarlas en este enlace




Leer más...

22 enero 2014

Análisis de AutomateIT (3 de 3)

En los posts anteriores (parte 1 y parte 2) hemos estudiado y replicado en una prueba de concepto el comportamiento de los servicios Web esperados por la aplicación durante el proceso de desbloqueo de las características que no se incluyen por defecto, pero continuando con el análisis veremos que este no es el único problema que presenta.

Descarga de reglas

La aplicación dispone de un mercado de reglas donde los usuarios pueden publicar sus creaciones y otros usuarios pueden descargarlas a un coste de 5 de sus puntos:



Si capturamos la petición de la búsqueda de reglas y alteramos el parámetro de la petición RowCount para que nos devuelva un único resultado veremos lo siguiente:



Entre los parámetros recibidos en la estructura JSON podemos destacar el campo GlobalRuleId, que es el identificador de la regla en el sistema; y RuleConfig, que contiene la configuración de la regla.

Si desde la aplicación instalamos esta regla capturaremos la siguiente petición:



A la que el servidor nos devolverá la siguiente respuesta:



Si comparamos el contenido de la respuesta al instalar la regla con el resultado de la búsqueda veremos como no existe ninguna diferencia:



Visto este comportamiento se concluye:
  1. En la misma respuesta a una búsqueda de reglas se incluye la configuración de la regla.
  2. Conocida la estructura de petición y respuesta se podría simular la inclusión de la regla programando el servicio Web análogo al demostrado en el desbloqueo de características.

Fugas de información

Otro comportamiento curioso es realizar una consulta introduciendo como criterio de búsqueda la cadena "@gmail.com". Obtendremos como resultado las reglas publicadas por usuarios cuyo nombre de usuario contiene dicha cadena:


Y como ya vimos en la primera parte del análisis, existe un servicio Web que devuelve información del usuario en base a la dirección de correo electrónico:


De este modo se podría obtener información del usuario en el sistema, en este caso su configuración nos indicaría:
  • Ha configurado el sexo como hombre (Gender 0)
  • Su fecha de nacimiento es el 7/8/1962
  • Reside en España (CountryCode ES)
  • Ha comprado la la versión completa de la aplicación en Google Play (IsPro 1).
Por último, si nos dirigimos al apartado de configuración del perfil del usuario, realizamos algunos cambios y los guardamos, capturaremos el siguiente intercambio de información con el servidor:



Como vemos en los parámetros incluidos en la petición, no se observa ningún campo que apunte a la sesión del usuario, de modo que se puede deducir que si se reenvía la misma petición, modificando el UserEmail (en las cabeceras HTTP y en el cuerpo de la petición) con el de alguno de los localizados en la búsqueda por email... ¿se podrían alterar los datos de dicho usuario?

Conclusiones finales

A la vista de los resultados del análisis y de forma resumida, podemos concluir que se han encontrado las siguientes vulnerabilidades:

- Configuración de seguridad incorrecta. Hay que evitar el uso de funciones de hashing sobre cadenas de texto predecibles, en este caso permitirán a un usuario mal intencionado superar las barreras establecidas en la aplicación para el desbloqueo de nuevas características.

- Referencia directa insegura a objetos. En toda solicitud que suponga un cambio en el sistema se tienen que incluir parámetros que permitan autorizar la operación por usuario o sesión.

- Exposición de datos sensibles. Al no impedir a los usuarios que configuren sus alias con su cuenta de correo, esta información puede filtrarse a través de búsquedas en el sistema.


Artículo cortesía de Miguel Ángel Garcia.
Leer más...

21 enero 2014

WPA/2 Enterprise - Cracking de EAP-MD5

Recientemente me he encontrado con un punto de acceso con configuración WPA2 Enterprise y autenticación EAP-MD5. Seguramente uno de los últimos que quedan, ya que está configuración es insegura, incluso más que WEP. Pero para mi sorpresa, la contraseña era bastante robusta. 

Antes de entrar al tajo, permitidme que haga una pequeña introducción.

Tanto WPA como WPA2 soportan dos métodos de autenticación distintos:
1.- Contraseña compartida o PSK de sus siglas Pre Shared Key, tan simple como que ambas partes, punto de acceso y todos los clientes, conocen la contraseña. Siempre la misma.
2.- "Enterprise" ó 802.1x, donde mediante un segundo servicio de autenticación denominado radius se valida cada uno de los distintos usuarios y sus contraseñas usando alguna de las extensiones disponibles en EAP (Extensible Authentication Protocol). Una de estas extensiones es MD5.

En el caso de EAP-MD5, la comprobación de estas credenciales se hace mediante un desafío y su respuesta de la siguiente forma:
  1. Hasta que se ha realizado la validación el punto de acceso tan solo transmite desde el radius hasta el cliente sin intervenir en el proceso.
  2. El primer paso es la identificación del cliente que trata de conectar con el nombre de usuario "Identity" hasta el radius.
  3. El radius contesta con un paquete que contiene el identificador de la petición, por ejemplo la "1", y un desafío que es hash md5 obtenido al azar, por ejemplo: 6119212b50e2c9eba01fd618288f316c
  4. El cliente obtiene ambos valores y junto a la contraseña, por ejemplo "test", genera un nuevo hash de la siguiente forma: md5(requestid + contraseña + desafío), lo que se traduce como: md5(\x01test\x61\x19\x21\x2b\x50\xe2\xc9\xeb\xa0\x1f\xd6\x18\x28\x8f\x31\6c) y lo manda nuevamente al radius. En el ejemplo anterior: a4f3d177f37cff946daa45b8327e80c8
  5. El radius hará el mismo md5 con la contraseña que él conoce para ese usuario y si obtiene el mismo hash que le mandó el cliente como respuesta (a4f3d177f37cff946daa45b8327e80c8), es que la contraseña es válida.

Esquema de 802.1x (imagen de http://www.juansa.net/)
Todo este tráfico se manda en texto claro, por lo que una captura de como conecta un cliente permite generar fácilmente un ataque de diccionario sobre la contraseña, generando tantos md5 como sean necesarios hasta que se obtenga el mismo que el cliente mandó en el último paso.

Con este concepto hay un par de scripts: eapmd5crack y eapmd5pass que hacen la labor. Pero por desgracia estas utilidades no están optimizadas para probar un elevado número de contraseñas en poco tiempo.

Para intentar optimizar el proceso he modificado eapmd5crack. Ahora en vez de tratar de obtener la contraseña directamente, creara la configuración necesaria para ejecutar posteriormente hashcat (en caso de CPU) o oclhashcat si disponemos de GPU mostrando el comando a ejecutar. 

El script está disponible en el repositorio de SbD.

epamd5hcgen.py

Respondiendo a un comentario añado esta información explicando los  parámetros de hashcat:
  • -m 10: que identifican que es un MD5 del tipo hash:salt
  • --quiet: para que no muestre la salida completa y solo el resultado.
  • --hex-salt: para indicarle que el salt (challange enviado por el radius) es binario y no un string en hexadecimal
  • --outfile-format 7: para que muestre la salida con el resultado también en hexadecimal
  • ToPwn: es el fichero que contiene el hash:salt
  • /usr/share/wordlists/rockyou.txt: el diccionario
  • -r eap.rule: se utiliza para añadir el ID del paquete al inicio de cada palabra probada.Necesario como se vio en la explicación de como se compone el MD5.
  • awk...sed, simplemente es para eliminar de la contraseña el ID del paquete.
Leer más...

20 enero 2014

Análisis de AutomateIT (2 de 3)

En el post anterior realizamos un análisis de la aplicación AutomateIT que nos permitió identificar todos los aspectos necesarios para simular los servicios Web utilizados en el proceso de desbloqueo de nuevas características.

Para confirmar el conocimiento reunido durante el análisis vamos a crear un escenario donde explotarlo a modo de prueba de concepto.

Escenario

Para la ejecución de la prueba de concepto se partirá de la siguiente configuración:

- Router con IP 192.168.0.1
- Dispositivo Android con IP 192.168.0.100. En este dispositivo se encontrará instalada la aplicación AutomateIT
- Equipo Kali Linux con IP 192.168.0.109. En esta máquina se crearán los servicios Web de desbloqueo de características y se utilizarán técnicas de spoofing contra el dispositivo Android para redirigir las peticiones de AutomateIT de modo que sea Kali quien responda en lugar del servidor de la aplicación.

Pasos

1. Antes de empezar con la explotación comprobamos los puntos que tenemos en la aplicación:


 2. Iniciamos el servidor Apache:



3. Se crea el fichero /var/www/ws/AutomateItRulesMarket/getUserDetails.php . Se configura para que nos devuelva 3000 puntos (nos servirá para validar el escenario de ataque):

<?php

echo '{"UserEmail":"'.$_GET["UserEmail"].'","IsUserRegistered":true,"UserId":"666666","IsPro":"0","Nickname":"Dr0pALL","CountryCode":"ES","PromoCode":"appoftheday","Score":"3000","Gender":"0","DateOfBirth":null}';

?>

4. Se crea el fichero /var/www/ws/UnlockFeatures/getFeaturesCost.php :

{"FeaturesCost":[{"FeatureName":"CalendarTrigger","Cost":"5"},{"FeatureName":"CompositeOrTrigger","Cost":"5"},{"FeatureName":"CompositeAndTrigger","Cost":"5"},{"FeatureName":"SensorTrigger","Cost":"5"},{"FeatureName":"RecurringEventTrigger","Cost":"5"},{"FeatureName":"CompositeAction","Cost":"5"},{"FeatureName":"EnableDisableScreenLockAction","Cost":"5"},{"FeatureName":"CopyRule","Cost":"5"},{"FeatureName":"RuleActivePeriod","Cost":"5"},{"FeatureName":"CancelDelayedExecutionByTrigger","Cost":"5"},{"FeatureName":"CellIdTriggerUnlimitedLocations","Cost":"5"}]}

5. Se crea el fichero /var/www/ws/UnlockFeatures/unlockFeature.php :

<?php

$contenido = file_get_contents('php://input');
$json = json_decode($contenido);
$claro  = $json->UserEmail . $json->FeatureName;
echo '{"Result":0,"UnlockCode":"'.sha1( $claro ).'","Score":3000}';

?>

6. Desde la máquina Kali se realizará un ataque MITM contra el dispositivo Android con arpspoof:
6.1. En un terminal activamos el forwarding de paquetes IPv4 y mantenemos el ARP spoof en sentido router:



6.2. Abrimos otro terminal y mantenemos el ARP spoof en sentido dispostivo Android:



7. Desde la máquina Kali realizamos DNS spoof para redirigir las peticiones del dominio automateitapp.com al servidor Apache que hemos levantado:



8. En el dispositivo Android:
8.1. Reiniciamos la caché DNS. Para esto lo que mejor suele funcionar es un hard reboot (apagar el dispositivo y extraer la batería durante 30 segundos).
8.2. En la aplicación nos dirigimos a "Más > Desbloquear características". Si todo ha funcionado correctamente veremos los 3000 puntos:


8.3. Una vez se ha confirmado la puntuación, sólo hay que desbloquear característica por característica:



8.4. Veremos además como nuestra puntuación no baja porque en el servicio Web " unlockFeature.php " siempre devolvemos un Score de 3000.


Artículo cortesía de Miguel Ángel García.
Leer más...