31 diciembre 2012

Un repaso a nuestros tweets y posts más destacados del año 2012

Este pasado 20 de Diciembre conseguíamos superar la barrera de los 10.000 followers de nuestra cuenta de Security By Default en twitter: @secbydefault


Ha sido un año repleto de noticias interesantes referentes al mundo de la seguridad informática: grandes hacks, memorables algunos entre ellos, nuevas iniciativas de interés, proyectos, herramientas, actualizaciones, etc, y hemos intentado hacerlas llegar a nuestros seguidores mediante la cuenta de Twitter, posts y SECmanas.

A través de diferentes herramientas online, hemos confeccionado la lista de los tweets realizados desde nuestra cuenta que han contado con un mayor número de retweets/RT durante este 2012. Son los siguientes:










Y para finalizar los posts más vistos, en los que predomina el contenido relacionado con WhatsApp, la herramienta de moda tanto para lo bueno, como para lo malo...

1) Descifrando el fichero msgstore.db.crypt de WhatsApp








3) Cómo ganar siempre al Apalabrados




4) Autenticación de doble factor Google: Casi perfecta










Queremos daros las gracias a TODOS por el apoyo que nos seguís brindando día a día, esperamos que el año que entra en ya menos de 24 horas sea tan interesante o más como este que hemos pasado.

Desde Security By Default ¡Feliz salida y entrada de año!
Leer más...

30 diciembre 2012

Enlaces de la SECmana - 155


Leer más...

28 diciembre 2012

Todos conocemos el 'reality' Gran Hermano, amado por muchos, odiado por otros. En cualquier caso los participantes de dicho reality están ahí porque han querido, lo han elegido y son conscientes de que la gente les está observando.

Pero, ¿Qué pasaría si un fabricante de cámaras de vigilancia fuese tan negligente como para dejar expuestos a sus clientes a miradas indiscretas? 

Trendnet, fabricante de dispositivos de red cuyo lema es 'Networks People Trust' ha hecho exactamente eso: Convertir a sus clientes en involuntarios concursantes de Gran Hermano.

Según leo aquí, las cámaras de vigilancia de dicho fabricante adolecen de una seria vulnerabilidad que permite a cualquier atacante remoto acceder a la grabación de la cámara.

El fallo es bastante negligente y denota bastante torpeza, ya que no requiere hacer nada más que apuntar el navegador a una URL para acceder a la cámara. Nada de Kun Fu ni artes Ninjas

A modo de concienciación, se ha creado una cuenta en twitter llamada TRENDnetExposed en la que periódicamente se van publicando enlaces de cámaras IP de clientes que confiaron en TRENDnet. Todo un Gran Hermano al alcance de 'un follow'

Entre otros, podemos ver a la concursante 'oficinista':




A los chicos, sin duda, conspirando para nominar a las chicas:


Y como todo buen Gran Hermano que se precie: El establo con los animales




En la cuenta twitter de TRENDnetExposed podemos conocer al resto de participantes:


Leer más...

27 diciembre 2012

Google Play, ocultación de malware y ExynosAbuse > Pwned!

Hace algo más de mes y medio tuve la oportunidad de acudir a la No cON Name 2012 con la ponencia Being smarter than G00gle! en la que presentaba una técnica para inyectar código malicioso en aplicaciones Android que a priori son inofensivas.

Este verano Nicholas J. Percoco y Sean Schulte presentaron en BlackHat USA 2012 una ponencia titulada "Adventures in Bouncerland" (podéis encontrar el whitepaper aquí) en la que explicaron cómo se podía convertir una aplicación inofensiva en maliciosa a través de JSBridge. Simplemente comentar que esta técnica se aprovecha de los puentes que se crean entre código Javascript (de ahora en adelante JS), que interpreta la aplicación a través del componente WebView, y métodos de código nativo de la aplicación. De esta forma, es posible acceder a métodos de la aplicación (como enviar un SMS) a través de JS; como hacían aplicaciones como Facebook (versión HTML5).

A continuación se muestra un ejemplo sencillo que ilustra esta técnica:


Si bien es una técnica muy interesante que permite modificar dinámicamente el comportamiento de la aplicación (a partir del código HTML/JS de las páginas que se abren con el componente WebView), el código nativo que ejecuta siempre está presente en la aplicación y éste no puede modificarse salvo que se actualice la aplicación.

Visto el inconveniente que supone el uso de JSBridge, se me ocurrió que podía ser interesante hacer uso de las posibilidades que nos ofrece Java en cuanto a la carga dinámica de clases en memoria, para crear malware modular que permita mantener una aplicación inofensiva (sin código sospechoso ni comportamiento malicioso) a la que se le agreguen las distintas capacidades en función de lo que requiera en cada momento (y dependiendo del dispositivo, firmware y demás características en las que se esté ejecutando).

Además, haciendo uso de este tipo de técnicas, podemos evitar los mecanismos de seguridad implementados en Google Play (la tienda de aplicaciones oficial de Android) y más recientemente a nivel del dispositivo (las versiones 4.2+ comprueban si las aplicaciones instaladas desde fuentes desconocidas contienen malware) puesto que un análisis automático de la aplicación no es capaz de encontrar ningún código ni comportamiento malicioso porque a priori no existe en la aplicación (ni siquiera parte del código como ocurría con la técnica de JSBridge).

Para ver más en detalle el funcionamiento de esta técnica utilizaremos de ejemplo una aplicación que simula ser una galería con las últimas siete fotografías utilizadas en el buscador Bing.



La aplicación BingImages ha estado publicada en Google Play desde el 6 de septiembre de 2012 (la acabo de retirar) para demostrar que el uso de estas técnicas es totalmente factible. También es importante destacar que este tipo de situaciones (uso de librerías) es normal y por ello, puesto que no se ejecuta ningún tipo de código malicioso durante el análisis que realiza Bouncer, su detección es complicada. Además se podría hacer uso de técnicas de 'fingerprinting' para detectar si estamos siendo analizados por Bouncer y, en ese caso, camuflarnos aun más si cabe (se puede leer más acerca de FP de Bouncer en el whitepaper 'Dissecting de Android Bouncer' de Charlie Miller y Jon Oberheide).

El código de las aplicaciones (tanto BingImages como BingUpdater -actualizador que incluye el payload malicioso-) puede ser descargado desde mi página.

Con respecto al código que se utiliza en BingImages para contactar con el servidor de comando y control que le indicará si tiene que descargarse algún payload y cómo ejecutarlo, y posteriormente su carga en memoria:


Simplemente comentar que, si el servidor de comando y control indica que existen actualizaciones, descarga el APK indicado en el JSON, lo carga en memoria haciendo uso del cargador DexClassLoader (se le indica una ruta temporal donde creará el DEX y que posteriormente eliminaremos -método cleanTemporalyFiles()-) y ejecuta el método inicial (indicado también en el JSON). De esta forma, el payload puede tener la estructura que nosotros queramos, sin tener que "atarnos" a una fija que pueda limitarnos en un futuro.

La ocultación se realiza a nivel aplicación (indicamos al DexClassLoader la ruta en la que tiene que crear los archivos DEX temporales) haciendo que el código malicioso esté disponible sólo en memoria y únicamente durante su ejecución puesto que posteriormente el recolector de basura de Java se encarga de eliminarlo sin necesidad de tener que liberar espacio en memoria de forma manual o reiniciar el dispositivo. Si bien siempre quedan evidencias (p.e la caché Dalvik en la que se almacenan los DEX optimizados para evitar su creación en cada ejecución -y que no podríamos eliminar salvo con un exploit o si el dispositivo está 'rooteado'-), esta técnica complica un nivel más el estudio del especímen de malware y/o el análisis forense del dispositivo infectado (a priori se encontrarían con un dispositivo que ha sido infectado sin tener claro qué aplicación es la culpable).

Un ejemplo de un payload sencillo podría ser un módulo que envíe al servidor de comando y control todos los ficheros que se estén almacenando en la carpeta Whatsapp de la SDCard (sólo necesitaríamos permisos de internet, la lectura de la SDCard no tienen ningún tipo de restricción -este permiso tendría que estar declarado en la aplicación 'padre'-). Y como ya comentó Alex hace un tiempo, el cifrado no sería un problema.


Siempre que hablo sobre este tema comento que uno de los usos de esta técnica podría ser el crear una aplicación 'padre' que únicamente tenga el permiso internet (es muy fácil justificarlo) y que los módulos se aprovechen de vulnerabilidades que permitan la escalada de privilegios (vulnerabilidades en aplicaciones stock, vulnerabilidades en Android, debugging...) o 'bypass' de los permisos, etc.

Hace más de una semana que se está hablando de la famosa vulnerabilidad descubierta en los teléfonos Samsung con procesadores Exynos 4210 y 4412 (podeis acceder a una buena explicación del tema en el artículo de Una al día). Básicamente la vulnerabilidad se encuentra en la asignación de los permisos del fichero /dev/exynos-mem que permite el acceso a toda la memoria RAM del dispositivos a cualquier usuario del dispositivo. Podéis acceder al exploit en este post del foro de XDA-Developers.

¿Y si el módulo que descarga nuestro malware comprueba si se encuentra entre los modelos afectados -comprobar la existencia de dicho fichero y sus permisos- y descarga el exploit? ¡Tendríamos una aplicación en la tienda de aplicaciones de Android que es capaz de ejecutar permisos como root sin que el dispositivo tenga que estar rooteado ni notificar al usuario en ningún momento!

En el código publicado de BingUpdater se presentan dos ejemplos, uno en el que se copia la base de datos 'fb.db' de la aplicación de Facebook a la SDCard (contiene, entre otra mucha información, los tokens de autenticación) y el segundo que hace 'root' al dispositivo.

A continuación se muestra un video de todo el proceso (descarga de una aplicación del Google Play que acaba siendo un malware con acceso completo al dispositivo):


Podéis acceder al código de las aplicaciones y demás material en:

Artículo cortesía de Luis Delgado 
Leer más...

26 diciembre 2012

Hacker Épico: Mi crítica #hackerepico


Disclaimer: Aunque Alejandro Ramos, uno de los autores de este libro, sea editor de Security By Default, y pese a que pueda parecer lo contrario, las opiniones vertidas en la siguiente crítica se han realizado de forma totalmente independiente y subjetiva por Lorenzo Martínez.

Después de llevar una semana siguiendo por twitter el hashtag #hackerepico, y con los dientes largos con todo el mundo hablando maravillas de este libro, por fin el viernes por la tarde-noche me llegó mi copia. Tendría que haber llegado antes, pero un error de un número en la dirección de envío, hizo que cayera en mis manos antes de un fin de semana.

Menos de 24 horas me ha durado desde que abrí la portada en busca de la dedicatoria de los autores, hasta que felicité a Alex por el gran trabajo realizado por él y por Rodrigo.


No es mi intención "spoilear" nada en este post, así que haré lo posible, aunque haya alguna frase mítica que perdonaréis que se me escape.

La trama de la novela, editada por Informática64, combina los ingredientes necesarios para lograr un escenario de continua tensión, aderezada con varios casos de hacking y forense real. El protagonista de la historia es Ángel Ríos (cualquier parecido con la realidad en las iniciales, tiene pinta de ser pura coincidencia :D), un integrante del Tiger Team de una empresa consultora/auditora de "alto nivel", genio en un montón de aspectos del hacking: wireless, web, redes, sistemas operativos, scripting, cracking, dispositivos móviles, ingeniería social,… paranoico, concienzudo, metódico… pero con un punto débil: sus sentimientos hacia la que fue el amor platónico que nunca llegó a conseguir en vidas pasadas.

Gran apasionado por el cine y las series, Ángel hace numerosas comparativas con el mundo fílmico y del cómic a lo largo del libro, quedando retratadas, a través de los protagonistas, cuáles son las preferencias cinéfilas de los autores.

Según iba devorando las hojas, empezaba a pensar en un ingrediente extra para que la historia fuese completa… Ya puestos, que apareciera algún político a relucir, sería genial. No preocuparse, se cumple TODO!

Si tuviera que elegir una frase de todo el libro (y sin spoilear demasiado), sin duda sería esta: "Cuando tienes un iphone como yo, no necesitas una blackberry". Quizá fuera de contexto no os impacte demasiado, pero cuando lo leáis en el capítulo correspondiente, veréis que es como para decir: Amén!  

Por compararlo con otras novelas con temática informática que he bebido de forma intensiva, en tiempos récord en vidas pasadas, podría decir que los sentimientos que evocan su lectura son comparables a los que tuve con "La Estancia Azul". Fundamentalmente, por los tintes de novela negra, pero con un contenido técnico muy superior, explicando en cada caso, hasta el último de los detalles (incluso los flags de las herramientas y recursos utilizados por el protagonista), muy al estilo de dos libros técnicos que suelo recomendar en charlas y cursos  "Hackers, 20 desafíos prácticos" y "Hackers: 19 desafíos prácticos más".

Para no tener que estar pendiente del boli y el papel para tomar notas respecto a las diferentes herramientas, han tenido el detalle de recopilar al final de la obra todos los recursos utilizados separados por cada uno de los capítulos, de manera que sea mucho más sencillo profundizar en cada una de las herramientas yendo a tiro fijo.

No me cabe duda que este libro será el primero de una saga en la que no habrá ni vampiros ni lobos pastelosos, sino acción y hacking avanzado. Como sugerencia aconsejo que pases por el baño una vez que te sientes a leer, puesto que la constante tensión y las ganas de saber qué pasará en la siguiente página, harán que no te despegues del sillón, con las consecuencias para la vejiga que eso puede tener.

¿Es entonces un libro recomendable? No, es simplemente imprescindible! De hecho, si Tarantino fuese español y supiese de informática, alguien tendría que asegurarse que este libro cayese en sus manos!
Leer más...

25 diciembre 2012

29th Chaos Communication Congress - Not My Department

Llega como cada año el congreso más longevo en cuanto a seguridad informática y hacktivismo se refiere: el Chaos Communication Congress. Este año, estamos ante la vigésimonovena edición, cuyo "slogan" es "Not my department".

Son fechas complicadas para su celebración, ya que justo cae entre Navidad y Fin de Año (27, 28, 29 y 30 de diciembre) pero para los que tienen citas familiares ineludibles, tranquilos, que habrá streaming de todas las charlas que se dan en el evento, como se viene haciendo en anteriores ediciones, y posteriormente, está disponible el archivo para poder descargarlas y verlas.

Si algo caracteriza al CCC es su enfoque, no solo por la temática de sus charlas y sus categorías de tracks disponibles, si no por sus iniciativas, talleres, aceptación de donaciones (no monetarias, si no de hardware, comida, etc), proyectos que nacen o se desarrollan, etc. El voluntariado es una característica principal, ya que acude muchísima gente (miles y miles) y con tantos temas y localizaciones que se desarrollan en paralelo, se hace dificil su gestión. En la sección de Assemblies también podréis ver un listado de todos los grupos y asociaciones que se reunen durante el evento, y si darán charlas, talleres...



Nuevos tipos de Lightning Talks

La agenda o Fharplan del evento está disponible en este enlace, y aquí en su versión descargable, dónde además se indica el lenguaje que se utilizará (inglés o alemán). Este año, las famosas charlas rápidas o lightning talks tienen novedades tal y como se explica en este post de su blog: habrá hueco para charlas de tipo Pecha Kucha (20 segundos x 20 imágenes) en el día 3, así como del estilo del congreso FOSDEM, con charlas alrededor de 15 minutos.

El precio de la entrada se establece entre 80, 100 y 120 euros, dependiendo del apoyo que se quiera dar al evento. Las entradas de 100 y 120 las llaman de "supporter", no tienen privilegios especiales, pero si que permitirían aportar un poco más al evento en caso de que sea posible. Toda ayuda es bienvenida.

Enlaces de interés

Leer más...

24 diciembre 2012

Seguridad en IOS: Análisis del fichero binario Manifest.mbdb

Cada vez que se hace una copia de seguridad de iTunes, ya sea con contraseña o sin ella, se genera una base de datos sin cifrar en un archivo dentro del directorio del backup llamado Manifest.mbdb, este fichero tiene un listado del resto de archivos y sus propiedades.

También hay otros ficheros como Info.plist dónde se almacena el IMEI, las aplicaciones instaladas, la fecha de la copia o el número de serie del terminal. Al igual que en el caso anterior, estos datos están siempre disponibles, ya que la información no se cifra, pese a que se establezca una contraseña en las opciones de iTunes. ¿Tiene sentido que sea así? No importa, no es el motivo de esta entrada.

Del Manifest.mbdb la estructura de los registros que lo componen es bien conocida y en se resumen en el siguiente esquema:

Esta información no es únicamente relevante en el contexto de un análisis forense, también es útil para  llevar a cabo una auditoría y conocer el tipo de clase de protección del dato que usa cada fichero de una aplicación.

Desde IOS4 se permite especificar el nivel de seguridad de cada nuevo fichero que se crea mediante atributos de la siguiente forma:



Esto es importante, ya que por ejemplo un fichero PDF que se entrega como adjunto de un correo electrónico tendrá el máximo nivel de protección, en cambio, si es enviado a otra aplicación de lectura de PDFs, dependerá de la aplicación el cómo lo almacene, perdiendo sus propiedades de seguridad.

Los distintos tipos de atributos son:


Con el objetivo de analizar el fichero Manifest.mbdb y todo su contenido, donde como se ha visto hay bastante información, he creado el script:  listManifest.py que genera un CSV con toda la información. Realmente he pillado varias funciones de distintas aplicaciones/foros y hecho un mix en este código.

El CSV tiene los siguientes campos: permisos, inodo, uid, guid, tamaño, clase, fecha de modificación, fecha de acceso, fecha de creación, hash sha1, dominio, nombre de la aplicación, nombre del fichero y propiedades.

Abierto con una hoja de calculo, tiene este aspecto.




Leer más...

23 diciembre 2012

Enlaces de la SECmana - 154


Leer más...

22 diciembre 2012

Predicciones de seguridad 2013





Como siempre por estas fechas, y como hemos hecho otros años, es momento de recopilar las predicciones que diferentes fabricantes de seguridad estiman que será donde pongan sus apuestas a la hora de trabajar en 2013.

Esta vez hemos tenido en cuenta las siguientes fuentes:
Fundamentalmente,  los evaluados coinciden en los siguientes puntos como trending topics para el año 2013:
  • Expansión de ataques APT (Advanced Persistent Threats), incluso llegando a afectar a usuarios "normales". Doy por sentado que esto combinado a nuestra, cada vez mayor presencia en más y más redes sociales y servicios interactivos, así como nuestra tendencia a contarlo todo en las mismas, será de gran ayuda a quien quiera prepararnos alguna jugarreta.
  • Aumento de amenazas en dispositivos móviles Está claro que disponer de herramientas tecnológicas que conectan nuestras vidas a Internet, con información tan personal como nuestro teléfono o tablet, nos expone a amenazas con las que nuestros padres no contaban. Pero claro, no se puede vivir siempre con el típico Nokia 3210 que lo más avanzado que tenía era que se podía jugar al Nibbles. Esto es renovarse o morir, aunque implique nuevos vectores de ataque. Así que tiene pinta que se saturará aún más el mercado con soluciones de protección de dispositivos móviles. Especial hincapié hay que hacer en las aplicaciones que instalamos en nuestros dispositivos móviles, que incluso descargados de sitios oficiales pueden venir con un regalito incorporado.
  • Servicios ofrecidos desde el Cloud: Dado el funcionamiento de los estrategas especialistas en nuevas técnicas de fraude, al analizar el mercado, y detectar que los usuarios y empresas cada vez confiamos más almacenar nuestra información en entornos Cloud, deciden poner a trabajar a sus equipos de I+D en explotar vulnerabilidades de estos entornos que puedan resultar "rentables". Y lo peor de todo, es que ante las vulnerabilidades que afecten a los proveedores de servicios cloud, no podemos hacer nada, puesto que no depende de nosotros. En este caso, dependerá de la elección de proveedor que hagamos desde un primer momento, basándonos en la confianza que éste nos inspire en cuanto a la conciencia y medidas de seguridad aportadas. 
  • Malware multiplataforma: Respecto a los sistemas operativos de usuario, una de dos, o los malos se han dado cuenta que el Windows 8 no le va a gustar tanto a los usuarios, o simplemente se han dado cuenta que, aunque estadísticamente el sistema operativo de las ventanas gana por goleada, ha dejado espacio para otros jugadores (fundamentalmente Apple). Los malos están empezando a aumentar sus miras para diseñar malware que permita ejecutarse en varios sistemas operativos. Si eres de los que pueden hacerlo todo con Linux, de una forma personalizada y controlando absolutamente los servicios activos, conexiones, perfiles de usuario, cifrado de disco, etc… la recomendación es que sigas usándolo vigilando aquello que se ejecuta bajo Java, porque salvo esta parte, estadísticamente seguirás estando más seguro, no sólo por el nivel de personalización que he mencionado antes, sino porque aun siendo el malware multiplataforma, Linux (del Top 3 de sistemas operativos más comunes) es el objetivo con menor índice de utilización, por lo que primero se centrarán en Mac OS X .

Es decir, que el año promete ser movidito en cuanto a seguridad se refiere, aunque ninguna de las fuentes mencionadas diga nada sobre la fecha del fin del mundo.
Leer más...

21 diciembre 2012

Venta de exploits: ¿Mejora o empeora la seguridad?


Hace algún tiempo leí en un medio anglosajón una reflexión sobre si el floreciente mercado de exploits había ayudado o no a mejorar el panorama de la seguridad informática. Lamentablemente no he sido capaz de encontrar el enlace (si alguien también leyó ese post y lo comparte en comentarios, se lo agradecería)

Muy atrás queda el año 2002 cuando Idefense (ahora en manos de Verisign) lanzó su programa de compra de exploits que revolucionó las reglas del juego. Posteriormente le siguieron otras empresas como TippingPoint que también ofrecieron dinero x exploits / vulnerabilidades.

Tal vez haya sido VUPEN quien mejor haya sabido elegir su modelo de negocio, ya que su volumen de facturación alcanza cifras escandalosas y han llegado a un grado de profesionalización increíble.

Hoy día casi cualquier empresa de cierto nivel tiene un programa de recompensas o bug bounty: Facebook, Mozilla o Google son ejemplos directos.

Por lo que he podido leer hay dos corrientes de opinión al respecto: de un lado quién dice que incentivar la búsqueda de vulnerabilidades fomenta la inseguridad. Del otro lado, quienes dicen que gracias a ese tipo de programas ha aflorado de una forma controlada un mercado que ya existía y que ha permitido avanzar positivamente.

En este punto, retomo el título del post y lanzo la pregunta: Venta de exploits: ¿Mejora o empeora la seguridad?

Podéis votar en la encuesta:


Venta de exploits: ¿Mejora o empeora la seguridad?

Leer más...

19 diciembre 2012

Evadiendo Snort en IPv6: Topera

Logo_topera
Recientemente se celebró en Albacete las II Conferencias de seguridad “Navaja Negra”. Entre las muchas charlas que se presentaron (podéis ver una crónica en: Día 1, Día 2) estaba la de Rafa Sánchez y mía (cr0hn), que llevaba por nombre: “IPv6 vs IDS. Hagan sus apuestas…”. En ella presentábamos un fallo de Snort, no reportado ni corregido, resultado de una investigación, así como “Topera”, un PoC capaz de explotar dicho fallo.

"Topera" es una nueva herramienta de hacking capaz de ejecutar ataques de red que pasan inadvertidos para Snort. Snort es el IDS/IPS más conocido y más utilizado como motor de detección de ataques de red. Muchas de las herramientas comerciales actuales de protección contra ataques de de red basan su potencial en este conocido IDS.

IPv6 es un protocolo complejo y con mucho potencial, y como tal, su uso conlleva riesgos de seguridad que deben ser analizados con detenimiento. Desde Iniqua, llevamos algún tiempo investigando sobre este protocolo y sus implicaciones de seguridad.

Recientemente hemos detectado lo que parece ser una nueva vulnerabilidad crítica en el manejo que el motor de detección de Snort realiza sobre determinados tipos de paquetes IPv6. Concretamente, sobre paquetes con un elevado número de Extension Headers.

"Topera" es una herramienta de auditoría de red todavía en fase Beta, y quisiéramos invitar a la comunidad a colaborar testando su comportamiento en distintos entornos. En estos momentos nos encontramos en pleno desarrollo de esta herramienta, tratando de analizar el potencial real que pudiera tener.

Quisiéramos recordar que, actualmente, la industria confía, en un alto grado, en las capacidades de detección motor de Snort en multitud de entornos, algunos de ellos críticos. "Topera" está orientado principalmente a administradores de Seguridad, administradores de red o CSOs, que estén interesados en evaluar el riesgo al que están expuestos sus sistemas de información al tener IPv6 activado por defecto (como por ejemplo, los sistemas basados en Linux y Windows). 

A continuación mostraremos un ejemplo del uso de topera. En primer lugar, describimos el escenario, que intenta simular un entorno real:

Para todos aquellos que queráis reproducir el ataque, tendréis que editar el fichero de configuración de Snort, normalmente en "/etc/snort/snort.conf", y añadir la siguiente linea (tener cuidado con no descomenarla solamente, hay que añadir más parámetros):



Una vez configurado nuestro Snort, nos aseguramos que hay conectividad entre la máquina con la Backtrack y la máquina Windows. Para ello lanzamos un escaneo con nmap en IPv6. Como muestra la siguiente figura, la máquina está activa y tiene abierto el puerto 139, activo por defecto en todos los sistemas Windows:


Una vez hecho esto, vamos a simular un escaneo de puertos con scapy. Scapy es, para los que no lo conozcáis, un generador de paquetes de red muy potente, intuitivo y sencillo de usar. 

El motivo de usar scapy, en lugar de nmap, es que Topera los usa para generar los paquetes IPv6 personalizados. De este modo, quedará patente que snort es capaz de detectar el scaneo hecho con scapy y que no hay "trampa ni cartón" cuando usemos Topera.

Para simular es escaneo debemos enviar muchos paquetes a la máquina remota, pero a puertos distintos. Por este motivo el puerto de destino lo ponemos aleatorio. Enviamos 200 paquetes, menos incluso que un escaneo por defecto en el nmap. Como podemos observar en la siguiente imagen, es detectado sin problemas por snort:


Ahora vamos a ver como, con topera, podemos hacer un escaneo de verdad sin ser detectados. Su uso es muy sencillo. En su ejecución básica sólo tendremos que indicar el sistema a escanear. También podemos indicar un rango de puertos, interfaz de salida o un archivo donde guardar los resultados. En la siguiente imagen se puede apreciar una ejecución de Topera y como pasa desapercibido a Snort:


Para los que no os apetezca montar todo el entorno o queráis verlo en funcionamiento sin esperas, podéis verlo en el siguiente video:


En estos momentos, Topera se encuentra en la versión 0.0.2, y solamente realiza escaneos de red TCP. Aviso al betatester: no esperes encontrar un rendimiento óptimo parecido al de nmap, ni una fiabilidad a prueba de bombas…

Invitamos a cualquier interesado en seguridad informática a probar esta herramienta para que, entre todos, podamos analizar el impacto real que esta nueva vulnerabilidad pudiera tener sobre los sistemas de detección de intrusos actuales.

Hemos decidido publicar esta vulnerabilidad porque, al igual que ha sido detectado por un par colegas en sus ratos libres, es posible que otros, con peores intenciones, lo hayan descubierto antes que nosotros y puedan estar explotando esta vulnerabilidad de forma activa. Por eso, queremos caracterizar este fallo cuanto antes, para que IPv6 siga siendo un protocolo potente en el que todos podamos apoyarnos para desarrollar nuevos servicios del Internet del futuro… y sin riesgos de seguridad innecesarios.

Podéis encontrar más información en la sección “labs” de iniqua y en la web del proyecto en google code

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

Artículo cortesía de:

- Daniel García a.k.a. cr0hn (@ggdaniel) - Auditor de seguridad e investigador en Buguroo Offensive Security y miembro de Iniqua.
- Rafa Sánchez (@r_a_ff_a_e_ll_o) – Auditor de seguridad e investigador miembro de Iniqua
Leer más...

18 diciembre 2012

Interceptando tráfico SSL en Android con Mallory proxy

Hace poco, y terminando ya un día de trabajo, me di cuenta de que la batería de mi smartphone Android se había drenado en cosa de 8-9 horas, del más absoluto de los idle's, hasta llegar al 0% y morir tras un agónico final sin cargador. Se trata de un Samsung Galaxy S III, que por aquella tenía embebida una versión del popular sistema operativo para smartphones y tablets de google número 4.0.4, también conocida como Ice Cream Sandwich. Tras este agónico final en tan poco tiempo me decidí a echar un ojo al tráfico que genera el terminal, a ver si se veía algo extraño ya que se ha visto por el market apliaciones fraudulentas que poco más que hacían que dar dinero a sus creadores generando tráfico basura desde nuestro Android a diferentes servicios que pagan por "click". 
En este punto, @aramosf me comentó sobre un proxy transparente presentado en la Black Hat de 2010 utilizado precisamente para estos menesteres. Así que me puse a ello.

Mi infraestructura iba a constar de:
  •  Un ordenador de sobremesa
  •  Mi maltrecho móvil
  •  Un router wifi
Ni más ni menos. Si además contamos con un portátil y un par de interfaces wi-fi podemos crear un AP falso para pasearlo por distintas ubicaciones públicas ;) Pero eso será objecto de otra entrada, ya que de momento mi portátil se encuentra fuera de combate.

Yo me decidí a realizar el MITM mediante una VPN, bastante fácil de configurar en Linux y ensucia menos la red que un arpspoof. Si elegimos el segundo método después tendremos que crearnos nuestras propias reglas en iptables, para enrutar el tráfico y que pase por mallory. Pero ese es otro tema, puesto que mallory junto con una VPN nos facilita enormemente la labor en este sentido.

Existe una máquina virtual con mallory pre-instalada, para descargar de su web oficial, yo me decidí a instalarlo directamente en el backtrack que tengo configurado sobre una máquina virtual.

La interfaz de red de mi máquina virtual la tengo configurada como "adaptador puente" o "bridge interface". De esta manera el DHCP del router es capaz de asignarle una dirección tal y como si fuera una interfaz física más dentro de la red.

Vamos a descargar y ejecutar la aplicación pptpd que será la encargada de crear nuestra VPN, y endpoint de nuestro terminal móvil.

root@bt:~/Desktop/mallory/mallory/scripts# apt-get install pptpd

Ahora vamos a configurarlo. Para ello editamos el archivo /etc/pptpd.conf y localizamos las líneas donde se definen la ip local del servidor VPN y las ips remotas que van a ser asignadas a nuestros clientes VPN.


  1. root@bt:~/Desktop/mallory/mallory/scripts# vi /etc/pptpd.conf
  2. ###############################################################################
  3. # $Id: pptpd.conf 4255 2004-10-03 18:44:00Z rene $
  4. #
  5. # Sample Poptop configuration file /etc/pptpd.conf
  6. #
  7. # Changes are effective when pptpd is restarted.
  8. ###############################################################################
  9. localip 192.168.1.22
  10. remoteip 192.168.1.230-240


Si estas dos líneas están comentadas (#) las descomentamos y en localip definimos la ip local del servidor VPN y en remoteip el rango de direcciones ips que queremos que se asignen a los clientes que se van a conectar. El siguiente paso es configurar un par usuario/contraseña para conectarnos. Debemos editar el archivo chap-secrets que se encuentra en /etc/ppp/


  1. root@bt:~/Desktop/mallory/mallory/scripts# vi /etc/ppp/chap-secrets
  2. # Secrets for authentication using CHAP
  3. # client        server  secret                  IP addresses
  4. user pptpd password *


Este archivo contiene las parejas usuario/contraseña válidas para acceder a nuestra red privada virtual. El primer campo será el usuario, el segundo la aplicación que se alimentará de estas credenciales, el tercero la contraseña y el último el rango de direcciones ips autorizadas a acceder a ese recurso.
Guardamos y reiniciamos el servicio pptpd:

root@bt:~/Desktop/mallory/mallory/scripts# /etc/init.d/pptpd restart

Y ya deberíamos ser capaces de conectarnos a través de nuestra recién configurada VPN. En android el proceso es muy sencillo. Aplicaciones -> Ajustes -> En conexiones inalámbrica buscamos Más ajustes -> VPN

Añadimos una red VPN con el usuario y contraseña que acabamos de definir en chap-secrets y con la dirección ip donde se encuentra la máquina servidor. Si todo ha ido bien deberíamos estar conectados ya.


Ahora procederemos a la instalación de mallory.

  1. sudo apt-get install mercurial;
  2. sudo apt-get install python-pyasn1;
  3. sudo apt-get install python-netfilter;
  4. sudo apt-get install libnetfilter-conntrack-dev;
  5. sudo apt-get install python2.6-dev;
  6. sudo apt-get install python-setuptools;
  7. sudo easy_install pynetfilter_conntrack;
  8. sudo apt-get install netfilter-extensions-source;
  9. sudo apt-get install libnetfilter-conntrack3-dbg;
  10. sudo apt-get install python-paramiko;
  11. sudo apt-get install python-imaging;

  12. #If you are installing Mallory on a 32 bit machine
  13. wget http://ubuntu.cs.utah.edu/ubuntu/pool/universe/libn/libnetfilter-conntrack/libnetfilter-conntrack1_0.0.99-1_i386.deb
  14. sudo dpkg -i libnetfilter-conntrack1_0.0.99-1_i386.deb
  15. #endif
  16. #if you are installing Mallory on a 64 bit machine
  17. wget http://ubuntu.cs.utah.edu/ubuntu/pool/universe/libn/libnetfilter-conntrack/libnetfilter-conntrack1_0.0.99-1_amd64.deb
  18. sudo dpkg -i libnetfilter-conntrack1_0.0.99-1_amd64.deb
  19. #endif

Instalamos todas las librerías y dependencias que son necesarias y dependiendo de si nos encontramos en un sistema operativo de 32 ó 64 bits instalaremos el primer o el segundo .deb

Dentro de la ruta de instalación de mallory podemos encontrar tres directorios principales:
  • mallory/db Que contienen las bases de datos sqlite en las que se insertan todos los streams que pasan por mallory
  • mallory/scripts Scripts para la configuración de iptables para realizar el MITM, además de uno para bloquear el spam que entraba hace años por netbios (:?) y por el servicio de windows messenger service. Nosotros no vamos a necesitar estos scripts puesto que vamos a lanzar la interfaz gráfica de mallory, que lo hará por nosotros. Pero para que se sepa deberíamos modificar config_router.sh y config_mallory.sh con las interfaces de entrada y salida.
  • mallory/src Donde se encuentra el core de programa. Los dos ejecutables que necesitamos (mallory.py y launchgui.py) además de un directorio con el certificado y demás ejecutables.
Abrimos un par de terminales y en una ejecutamos el proxy en sí.

  1. root@bt:~/Desktop/mallory/mallory/src# python mallory.py
  2. /root/Desktop/mallory/mallory/src/config_proto.py:3: DeprecationWarning: the sets module is deprecated
  3.   import sets
  4. MALLLLORYYY!!!!!!!!!!
  5. [*] [2012-12-09 19:50:39,404] INFO:Logging setup complete
  6. [*] [2012-12-09 19:50:39,406] INFO:[*] SSHProtocol: Initializing
  7. [*] [2012-12-09 19:50:39,409] INFO:HTTP protocol handler initialized
  8. [*] [2012-12-09 19:50:39,409] DEBUG:SSLProtocol: Initializing
  9. [*] [2012-12-09 19:50:39,410] DEBUG:SSLProtocol: Initializing
  10. [*] [2012-12-09 19:50:39,411] INFO:ConfigRules.init: LOADING RULES.
  11. [*] [2012-12-09 19:50:39,413] INFO:ConfigRules.load_config: Rule Action String is:Debug
  12. [*] [2012-12-09 19:50:39,417] DEBUG:NetfilterTool: Instantiating object.
  13. [*] [2012-12-09 19:50:39,418] INFO:RPCServer: add_remote_obj - adding remote object
  14. [...]
  15. [*] [2012-12-09 19:50:39,445] DEBUG:NetfilterTool: Instantiating object.
  16. [*] [2012-12-09 19:50:39,446] DEBUG:UDPProtocol[m]: Waiting for data

Ahora deberemos arrancar la interfaz gráfica que se conecta a través de un servidor xmlrpc a mallory.

root@bt:~/Desktop/mallory/mallory/src# python launchgui.py 

Y la interfaz gráfica arrancará. Si os da un warning acerca de una librería no instalada instaladla si vais a utilizar la interfaz del programa sobre la base de datos. Luego veremos cómo.

Ahora lo primero es realizar el MITM. Lo primero que se nos abre es la pestaña de interfaces en la que vamos a escoger la interfaz por la que "entra" el tráfico que queremos analizar y la interfaz por la que "sale" hacia internet. Y es tan sencillo cómo seleccionarlas mediante botones:


En mi caso he seleccionado la interfaz ppp0 (la del único cliente que tengo conectado a la VPN, recordemos que con cada cliente conectado el demonio crea un nuevo adaptador virtual punto a punto) como interfaz de "entrada" o donde mallory lo etiqueta como Perform MITM y eth0 como interfaz de "salida", o etiquetado tal cual está en mallory Outbound interface. Una vez hecho esto sólo tenemos que hacer click en Apply Configuration y la aplicación solita se encarga de agregar las reglas a iptables que son necesarias como podremos ver si ponemos en primer plano la terminal de la que cuelga la interfaz gráfica de mallory.


Lo que hacen estas reglas básicamente es redirigir todo el tráfico tanto tcp como udp que llega por ppp0 hacia el puerto de escucha de mallory, el 20755. Además añade un MASQUERADE en la interfaz de salida y activa el ip_forwarding.

Ahora nos vamos a la pestaña protocols, dónde podemos ver los protocolos y puertos que queremos interceptar.


Tan sólo tenemos que quitar los comentarios (;) del principio de línea de la definición de protocolos y puertos y clickear en Apply para activar la intercepción de estos protocolos y puertos. Por el momento tenemos disponibles tres, que son ssh, ssl y http.
Podemos añadir fácilmente tráfico en otro puerto, por ejemplo:

miproto:sslproto.SSLProtocol:5222

La pestaña rules es un potente modificador de tráfico, que nos permitirá automatizar el proceso de modificación de tráfico mediante patrones y reglas, aunque también podemos hacer modificaciones manualmente en "tiempo real".

La pestaña rules contiene la salsa de la aplicación, dónde en tiempo real, se muestra todo el tráfico que la aplicación está capturando, en base a los protocolos que hemos definido en la pestaña protocols. Debemos activar el botón de Intercept para que la aplicación muestre el tráfico y lo guarde en la base de datos y Auto-send si de momento sólo queremos mirar y no modificar nada. Casi inmediatamente y si tenemos nuestro terminal conectado a la vpn deberíamos empezar a ver trazas yendo y viniendo de aquí para allá, puesto que nuestros smartphones sabéis que están constantemente sincronizando y enviando otro tipo de datos a diferentes servicios. Por ejemplo, yo me di cuenta de que al abrir Chrome en mi android está casi continuamente mandando información contra un servidor de google para sincronizar las pestañas abiertas en los diferentes dispositivos que tenemos enlazados con nuestra cuenta de google.
¿Pero y qué ocurre si intentamos acceder a una web mediante https? Esto:


Chrome además de avisarnos de que el certificado no es válido, ni siquiera nos permite proseguir aceptando los riesgos. ¿Cómo se comportan este tipo de proxies cuando accedemos a un recurso mediante SSL? Tienen una ca interna que genera certificados autofirmados para cada web que visitemos. Además de todo esto, las aplicaciones que utilizan SSL para comunicarse con sus servidores ni siquiera funcionarán. Así que para solucionar este entuerto instalaremos el .cer en el terminal que nos permitirá salvar esta situación.

En algún sitio había leído que era un lío instalar un certificado en android, así que busqué y encontré un método en el que necesitábamos root en el teléfono y una shell en éste mediante el SDK de Android. Android posee un contenedor de certificados en /system/etc/security/cacerts/ donde se almacenan todos los instalados en el télefono. El nombre de los certificados es un hash del subject del certificado, seguido de un .0 ó .1, .2... si existen colisiones. Así que el directorio nos queda tal que así:


  1. shell@android:/system/etc/security/cacerts # ls -l
  2. ls -l
  3. -rw-r--r-- root     root         4767 2012-09-28 14:15 00673b5b.0
  4. [...]
  5. -rw-r--r-- root     root         5106 2012-09-28 14:15 ff783690.0



Después tan sólo hacíamos el mencionado hash con openssl x509 -noout hash -in .../mallory/src/ca/cer.key, renombrábamos el certificado a ese hash (más un .0) y lo metíamos mediante un adb push al directorio contenedor de certificados. Pero a mí particularmente no me funcionó. Por lo que puse en marcha la solución sencilla. Montar un apache, meter ahí el certificado de mallory y acceder desde el móvil para descargarlo. Dicho y hecho.


Pinchando en él se descarga a la SD, por lo que el siguiente paso en el móvil es ir a Ajustes -> Seguridad -> Instalar desde almac dispositivo -> seleccionar el certificado que acabamos de descargar. Si ahora vamos a Credenciales de confianza -> pestaña Usuario, debería aparecer el certificado que acbamos de instalar.


Ahora intentamos acceder a una web con https y...


Ya confía en nosotros :) Ahora podremos ver el tráfico en claro desde mallory:


Además de que otras aplicaciones que transmiten sobre SSL también funcionarán :)


Mallory además tiene una interfaz contra la base de datos que podemos utilizar para consultarla sobre los streams almacenados. En la pestaña advanced podemos pulsar sobre create flow query y nos generará una consulta con los campos más importantes para poder ver un flujo de tráfico. 


Además podemos abrirla directamente con sqlite3 y hacer consultas desde la línea de comandos. Para ver el schema de la base de datos:

  1. root@bt:~/Desktop/mallory/mallory/db# sqlite3 trafficdb
  2. SQLite version 3.7.11 2012-03-20 11:35:50
  3. Enter ".help" for instructions
  4. Enter SQL statements terminated with a ";"
  5. sqlite> .schema
  6. CREATE TABLE connections(
  7.                 connCount INTEGER,
  8.                 serverIp TEXT,
  9.                 serverPort INTEGER,
  10.                 clientIp TEXT,
  11.                 clientPort INTEGER
  12.             );
  13. [...]  
  14.          
  15. sqlite>


Y con .help podemos ver todos los comandos disponibles en sqlite3. Por ejemplo, .tables nos mostrará el nombre de todas las tablas de esa base de datos.

Con todo esto en marcha, no sería muy difícil crear un punto de acceso falso, conseguir clientes que se conectarían pensando que es un AP legítimo, colocarles una especie de portal cautivo dónde se les pidiera la instalación del certificado y a continuación dejarles navegar con normalidad.
Para otra entrada queda cómo crear un punto de acceso falso con hostapd.


Artículo por @jorch_garcia
Leer más...