20 septiembre 2012

Algo falla en seguridad

Lo siento pero hoy no quiero hablar de nada técnico, hoy me apetece lloriquear un poco

Cada día nos despertamos con una derrota nueva en las batallas contra el malware. Poco a poco la guerra parece no tener sentido. El número de muestras diarias es incalculable. Las compañías de antivirus no son capaces de analizar cada una de ellas y buscan las mejores formas de solucionar el problema. Soluciones que son insuficientes.

Analistas aplican ingeniería inversa para despiezar cada nueva familia de bichos en millones de trozos y buscar patrones que los identifiquen. Patrones que sirvan para todos ellos y que no requieran que cada mínima variación sirva para evadir su detección. Pero la técnica falla, y no una o dos veces, falla demasiadas. Incluso auto-detectandose así mismos como malware.

Dejas de leer twitter para escribir un correo electrónico y cuando vuelves la mirada, te encuentras con un 0-day en Java que son incapaces de parchear u otro para Internet Explorer que llega a salpicar hasta su más reciente y fortificada versión 9, incluso sobre en el intocable Windows 7 con ASLR.

Aplicaciones programadas por los mejores hackers para automatizar los análisis y las protecciones a todos los niveles: UEFI/BIOS, sistema operativo, aplicaciones, plugins... Nada parece funcionar. 

Ni siquiera Google y toda su fuerza tecnológica ha podido solucionar los problemas en el correo electrónico. Estamos terminando 2012 y aún seguimos recibiendo  phishings de paypal, o de cualquier otra entidad.


Pero como no recibirlo, si cualquiera puede mandar estos correos, comprando en el mercado negro kits para explotar vulnerabilidades e infectar equipos. Vulnerabilidades, que por cierto, son implantadas antes en estos frameworks de fraude que parcheadas por los fabricantes. Tal y como ha ocurrido con el último fallo de Java.

La seguridad perimetral parecen unas rodilleras para saltar desde el Empire State Building. 

Fabricantes con un increíble prestigio en seguridad como F5 son pillados en renuncios ridículos. Tecnología de seguridad que puede ser esquivada de 150 formas distintas. Consultoras especialistas, contratadas por el gobierno como compañías punteras, son penetradas con una vulnerabilidad de hace 10 años.  Empresas que deciden fumarse con papel reciclado vulnerabilidades reportadas hace 13 años.

¿Y nos sorprende lo que hace anonymous? Analizándolo fríamente, es incluso poco.

Por cada iniciativa que busca soluciones innovadoras a los problemas de forma defensiva, tal y como hacen en Bluehat Prize Contest, nacen tres empresas dispuestas a vender vulnerabilidades a un cuarto de millón de dólares o concursos que premian al hacker más rápido en hacer saltar por los aires la seguridad de un navegador. El fin podría ser el mismo, mejorar la seguridad, pero ¿lo es?

Es mi sensación o ¿el avance en materia de seguridad es demasiado lento?

Leer más...

19 septiembre 2012

Una de las cosas que siempre se ha echado a faltar en WhatsApp es la posibilidad de usarlo fuera del móvil. Existen formas de usarlo en un PC mediante el emulador de Android pero eso, aparte de ser farragoso, impide ir un poco mas allá y poder usarlo por ejemplo vía web.

WhatsApp, lejos de liberar una API pública e incentivar a los desarrolladores a crear aplicaciones basadas en su plataforma, siempre se ha mostrado muy hostil con esa clase de iniciativas. Amén de que va introduciendo cambios en su plataforma de forma improvisada y sobre la marcha, como si de Rajoy se tratase.

Pese a eso, algunas personas, mediante ingeniería inversa, han conseguido saber como funciona internamente whatsApp e incluso desvelado muchas de sus miserias, como publicábamos hace poco aquí.

En base a ese trabajo de ingeniería inversa se ha publicado una API alternativa para poder usar WhatsApp desde los lenguajes de programación PHP y Python que abre la puerta hacia aplicaciones web, clientes alternativos de escritorio, y un sin fin de posibilidades. Su nombre: WhatsAPI

¿Problema? Eso a WhatsApp no le ha hecho ninguna gracia y ha lanzado su equipo legal contra los creadores, de hecho, a día de hoy han bloqueado el acceso al código fuente de las librerías


Al final, hacer eso, es poner puertas al campo, la API ya ha sido publicada, es fácilmente replicable y esa acción no va a detener algo que ya está en marcha.

En vez de eso, bien haría WhatsApp en no ver eso como una amenaza sino como una demanda, una necesidad, y dar respuesta oficialmente lanzando su propia API, incluso fichando a los creadores de WhatsAPI y colaborando a que su negocio crezca y se use más de lo que ahora mismo se está usando, ¿O acaso ese no es el objetivo de toda empresa?

UPDATE: Cómo conseguir el código (by Mario Vilas): Si haces git clone del repo puedes acceder a los commits anteriores. No quitaron el codigo, solo hicieron un commit para borrar los archivos, así que es cuestión de clonar el repo y volver atrás el ultimo commit.  
Leer más...

18 septiembre 2012

Listado de 'Celebrities' con problemas de privacidad

El caso de Olvido Hormigos y el tristemente famoso vídeo de contenido erótico es tan solo el último caso de violación de privacidad.

Previo al 'caso Olvido' fue Karina Bolaños quien estuvo en la picota por otro vídeo sustraído en extrañas circunstancias.

Pero no son las únicas, cada cierto tiempo sale a la luz pública un caso parecido, a veces son fotos, en otros casos vídeos.

La gente de hackmageddon ha hecho un completo recopilatorio a modo de timeline con todas las 'Celebrities' que han pasado por ese trance, el tipo de 'hackeo' que sufrieron y en caso de estar identificado, su autor.


Están Christina Aguilera, Scarlett, lady Gaga y otras muchas.

El artículo original (en inglés), así como enlaces a cada caso se puede leer aquí
Leer más...

17 septiembre 2012

WhatsApp: Spam, inundación y robo de cuentas

En Marzo del 2011, en este mismo blog, Alberto Ortega explicaba como funcionaba la autenticación de los clientes de WhatsApp con sus servidores y se preguntaba cuál sería la contraseña para el acceso. Hoy y desde hace meses, ya se conoce como se genera. 

En esta entrada vamos a explicar qué riesgo implica este dato y como en otras ocasiones, esperamos ayudar a convencer a WhatsApp de sacar una nueva actualización.

En febrero se publicó el método de generación de la contraseña, cuando alguien escribió en el foro hak5 un comentario con su investigación sobre la aplicación del sistema Symbian, acompañándolo con las funciones en java que hacían esta tarea.

Generación de la contraseña MD5 en cliente de Symbian
Al final no era mucho más complicado que hacer un MD5 del IMEI del teléfono móvil invertido, al menos en este caso y en el de los teléfonos Android.

Este descubrimiento se ha hecho popular hace unas semanas (el día 5 de septiembre) a raíz de una entrada de Sam Granger, pero realmente era algo bien conocido desde febrero.

A partir de aquí decenas de usuarios empiezan a crear los primeros clientes no oficiales y es que la comunidad no tiene límites. Uno hecho en java para los móviles n900 (que además y sin que se hiciera demasiado eco funciona en PC), Yaparri  y Wazzap! para N9. Todo un lujo para los usuarios de estos móviles.

En mayo se creó una API (no oficial), tanto en php como en python, que usa este mismo sistema y permite a desarrolladores hacer sus propias aplicaciones.

Una noticia más de esta semana y que ha hecho saltar la alarma a los blogs más generalistas ha sido el reciente descubrimiento de como genera la  contraseña el cliente móvil de la plataforma IOS, que es tan sencillo como aplicar un MD5 a la MAC de la tarjeta wireless duplicada: md5(MACMAC).

Generación del hash MD5 en IOS (Fuente:  http://www.ezioamodio.it/?p=29 )
El problema de este método de generación es obvio. Tan solo hace falta conocer la MAC del móvil para suplantar su identidad y con ello mandar mensajes a su nombre y además recibirlos (aunque el móvil suplantado no los recibiría). La MAC, a diferencia del IMEI, es un dato que se puede obtener sencillamente sin acceso físico a el.

Este hallazgo explica el motivo por el que en ocasiones tanto la API como otros clientes fallaban al acceder a los servicios de WhatsAPP, ya que si te registras por primera vez con un iPhone, tu contraseña no estará creada en base al IMEI y por lo tanto fallará. Ocurre lo mismo si el proceso es inverso.

Los riesgos que implican este comportamiento son varios, entre ellos el spam, la inundación y el robo de la cuenta.

SPAM

Seguro que todos habéis usado alguna vez alguno de estos servicios: Messenger, Gtalk, Facebook o Tuenti. Y seguro que no os sorprende que para que alguien pueda interactuar con vosotros se sigue un proceso muy sencillo: primero se manda una solicitud para conectar y a continuación la otra persona  ha de aceptar. Una vez hecho, se establece un vínculo y queda vía libre para la comunicación.

Este proceso no es igual en WhatsApp. Aquí un usuario puede mandar mensajes a quien quiera (al igual que ocurre con los SMS), tan solo conociendo su teléfono. Teniendo en cuenta que el envío no tiene coste y se puede automatizar sencillamente es previsible que empecemos a sufrirlo a corto plazo.  Este mismo problema ocurre en Twitter donde tampoco se aceptan los followers salvo se configure en modo privado. ¿Alguno tiene la cuenta de twitter pública y ha recibido mensajes de mujeres increíblemente guapas que ponen direcciones de páginas web? Si, es SPAM, y entonces ya sabéis a lo que me refiero.

Tal vez alguien malo se haya leído mi anterior post donde contaba el número de móviles con whatsapp instalado y usando el mismo proceso sea capaz de generar una lista con los teléfonos dados de alta y por lo tanto "objetivo".

Solo espero que si alguien se aprovecha, acabe teniendo que dar explicaciones legales. Bueno, eso y que WhatsApp me permita configurar mi "usuario" como privado.

Ejemplo de envío masivo de publicidad de SbD vía WhatsApp

Inundación

Por lo explicado anteriormente, el mismo ataque se puede replicar mandando miles de mensajes automáticamente al mismo teléfono, dejándolo KO hasta que elimine la aplicación, desactive los datos o alguna otra medida similar.

Denegación de servicio con mensajes masivos de WhatsApp

Robo de cuenta

Lo que al final todo el mundo quiere hacer. Leer los mensajes de whatsapp de la novia de la que tanto se fían. Lo que cuento aquí no tiene ningún misterio y ya es público, pero sed responsables, ya que un gran poder conlleva una gran responsabilidad. Y acabar explicándoselo a un Juez, no debería ser una opción.

Dependiendo del móvil que se usó para registrarse la última vez, la contraseña estará basada en IMEI (Android/Symbian) o en la MAC de la Wifi (iPhone).
  • Si es IMEI la única opción es acceder físicamente al móvil y verlo al quitar la batería o en la configuración del terminal. La configuración es distinta por cada móvil, pero en muchos de ellos se muestra directamente al pulsar el código:  *#06#
  • Si es la MAC, se puede sacar de distintas formas:
    • En Ajustes->General->Información->"Dirección WIFI"
    • Si está en la misma red que tú, como por ejemplo en casa compartiendo ADSL. Dentro de la configuración del router aparecerá un apartado con los clientes conectados o un listado con la asignación DHCP, relacionando direcciones IP con MACs
    • Usando un sniffer como kismet que es capaz de localizar los dispositivos wireless (como el iphone en cuestión) cada vez que tratan de conectar a alguno de los puntos de acceso que tienen configurados, independientemente de que estén disponibles o no.
    • Por otro fallo de IOS, cuando configuras un punto de acceso este queda almacenado para siempre y si detecta otro con el mismo nombre, se conectará directamente sin preguntar.  Por lo que otra opción es crear un punto de acceso falso (fakeap), con nombres de redes conocidas y que seguramente ya estén almacenadas en el móvil. Como por ejemplo: "McDonalds", "Starbucks", "Hotel NH", etc.

Kismet mostrando clientes conectados y sus MAC (Fuente:  http://www.kismetwireless.net/screenshot.shtml)

Configuración de router Belkin mostrando clientes Wireless (Fuente:  http://www.techspot.com/guides/442-check-if-someone-uses-your-wi-fi/)

Una vez dispones de los datos necesarios, descarga PHP y WhatsAPI, Edita el código de ejemplo "whatsapp.php" añadiendo el nombre, teléfono (sin el 00 ni el +, pero si con el código de país) y luego el IMEI o MAC.


A continuación hay que modificar el php.ini para que cargue la librería de sockets y openssl, además de modificar la clase whatsprot.class.php para eliminar el timeout del socket y por último, cambiar las rutas de Unix a Windows en los require (las barras, vaya)

Para evitaros hacer esos esos cambios, he dejado en el repositorio todas las modificaciones hechas, junto a todo lo necesario, para que solo tengáis que descargar el archivo en C:\php y editar el whatsapp.php con el nickname, sender e IMEI.

Desde un cmd, se ejecuta con una sintaxis sencilla.

  • El primer comando, sin argumentos, muestra la ayuda: php whatsapp.php
  • El segundo manda un mensaje de prueba: con -s y el teléfono (country code, sin 00 ni +)
  • Con la opción -l permanece a la escucha para la recepción. Ojo que si es de otro usuario, el legítimo no los recibirá.



Actualización: 18/09/2012

Otra opción más sencilla tanto para Windows como Linux es descargar ThatsaPC, en el que desde entorno gráfico, ofrece la misma funcionalidad. Tan solo hay que añadir el código de país (34 para España), el IMEI o MAC (en mayusculas) y el número de teléfono.

Una vez se conecta, se añaden los contactos manualmente desde el menú de contactos.




Leer más...

16 septiembre 2012

Enlaces de la SECmana - 140

Leer más...

14 septiembre 2012

Android, tus horas están contadas!

Sí, ya sé que suena alarmista, sensacionalista y que se acaba el mundo, pero por lo que me he podido enterar, va a ser un bombazo. No estoy hablando que Android vaya a morir porque el nuevo Iphone 5 (sin rimas por favor), presentado esta semana por Apple, va a ser un Android-Killer, sino por un fallo que tienen todos los Android que, por lo que me han contado, los deja como un bonito pisapapeles bastante caros.

Como sabéis los que nos seguís, la semana que viene se celebra en Buenos Aires una nueva edición del popular Congreso de Seguridad Ekoparty, en el que tendré el honor y placer de participar. Esta conferencia, aparte de estar considerada como la más importante de las que se celebran en toda Latinoamérica, se caracteriza por tener una altísima repercusión mediática mundial, por increíble puesta en escena, diferentes actividades y talleres, así como por hacer público en muchas de sus charlas, "hitos" que marcan un antes y un después en mundo de la seguridad. Lo mismo hay curiosas charlas de hacking de satélites, de lockpicking, o liberan un 0-Day sobre cómo romper el protocolo HTTPS, algo imprescindible en Internet,…

Bueno pues este año, gracias a la organización de Ekoparty, tenemos el placer de anunciar, en exclusiva en SbD, que habrá una charla en la que se publicará un mecanismo para dejar inservible cualquier terminal con Android.


Y es que he tenido la oportunidad de cruzarme unos correos con Ravishankar Broagaonkar (al que espero poder tratar de "Ravi" en Argentina) en los que me ha dado un poco de información sobre su investigación. Actualmente trabaja en el departamento de seguridad telecomunicaciones de TU Berlin y siempre ha dedicado a seguridad de telecomunicaciones.

Traduzco literalmente lo que me ha autorizado para hacer público en el blog sobre el bombazo que liberará en Ekoparty:

"Una grave vulnerabilidad en todos los dispositivos Android me permite desconectar usuarios móviles de comunicación por celular, de forma remota, causando una denegación de servicio permanente. Además, vectores de ataque improvisados impactarán la disponibilidad y la integridad de dispositivos móviles basados en Android".

Como anécdota curiosa, le pregunté cuántos móviles o dispositivos Android había dejado inservibles. Me contesta: "Incialmente rompí mis 4 dispositivos,… pero ya te contaré, tomando unas cervezas en Buenos Aires, la escabechina que monté en una tienda de electrónica en Berlín con esta vulnerabilidad :D"

Sólo os puedo decir que espero ansioso conocer a Ravi y al resto de los ponentes de la Ekoparty, porque tiene pinta que va a ser impresionante este año. Nos vemos en Argentina!
Leer más...

13 septiembre 2012

Riesgos reales en VoIP

Buenas a todos, sin dejar de todo el tema de Metasploit, hoy voy a hablar un poco sobre seguridad en VoIP, que es en lo que trabajo. Es decir, si monto un servidor SIP en Internet, ¿que debería preocuparme?

Las escuchas ilegales y demás vectores de ataque originados “desde dentro”, como el cracking de contraseñas, no van a ser objeto de estudio en esta ocasión por ser mucho menos comunes y tener fácil solución. Prácticamente la totalidad de ataques del exterior van a tratar de explotar el protocolo SIP, encargado de la señalización. 

Podríamos establecer una clasificación sencilla de los mismos:
  • Enumeración de extensiones/bruteforcing de contraseñas: En este apartado agrupamos ambos vectores de ataque ya que, en muchas ocasiones, el atacante no tiene claros los pasos para comprometer un servicio SIP. Su objetivo normalmente es obtener credenciales válidas para poder realizar llamadas (caras) a diferentes destinos. En ocasiones para vender los minutos y en otras para llamar a sus propios números de tarificación especial. En este post (y este otro) explico en detalle como realizar una auditoría mínima utilizando módulos de Metasploit, aunque también se podría hacer con la suite SIPVicious. En resumen, los pasos serían los siguientes:
    • Se comienza por un escaneo SIP.
    • A continuación se enumeran las extensiones por fuerza bruta.
    • Finalmente se trata de hacer lo mismo para las contraseñas de las extensiones descubiertas en el paso anterior.
Como comentaba, los atacantes normalmente no realizan este proceso de forma correcta como veremos en los siguientes ejemplos de trazas reales:
    • En este caso estamos la imagen muestra como el atacante trata de registrarse utilizando un usuario no válido en el sistema con distintas contraseñas, lo cual nunca va a generar resultados positivos. Se observa que la víctima responde con un reto a las peticiones, a partir de 5 intentos va a bloquear esa dirección IP. Esto se debe a la configuración que establecemos en las medidas de protección de nuestros servidores SIP. De esta forma se permite algún error en el registro de usuarios legítimos pero no un ataque de fuerza bruta o DoS.


    • En el siguiente caso ahora no se responde a ninguna petición porque además implementamos una regla que bloquea todas las peticiones realizadas  por el software SIPVicious (“User-Agent: friendly-scanner”). Aunque como podríamos imaginar en ocasiones los atacantes lo cambian para tratar de pasar desapercibidos.

  • INVITE attack: No son tan comunes, pero sí se ven alguna vez. En este caso el atacante trata de llamar (paquete INVITE) sin estar registrado previamente, el objetivo final es el mismo que para el caso anterior, realizar una llamada a un número de teléfono para obtener algún beneficio. Realmente no funcionan con la configuración por defecto de la mayoría de los sistemas SIP típicos ya que, aunque se permiten INVITES (llamadas) a usuarios no registrados, previamente se les solicita una autenticación por medio de un reto. Este proceso funciona de forma análoga al caso del registro. Mi amigo Pepelux publicó hace tiempo un ejemplo, así que no me voy a repetir.
  • DoS/DDoS flood: Debido a que la mayor parte de los ataques destacan por su escasa eficiencia, tal y como se expuso, a efectos prácticos pasan a convertirse en ataques típicos de DoS. Además, solo es cuestión de tiempo que grupos hacktivistas, organizaciones y gobiernos comiencen a explotarlo, al igual que hacen con los servicios web. Este último año aparecieron iniciativas relacionadas, como Occupy Phones, que tratan de inundar los números de teléfono públicos de los objetivos. Utilizan la VoIP como herramienta para abaratar costes, o para hacerlo de forma gratuita utilizando sistemas comprometidos. Como curiosidad comentar que ya existen empresas que incluso ofrecen el “servicio” de floodear por encargo a determinados objetivos.
En comparación con la web, en mi opinión, el impacto es mucho mayor en sistemas VoIP. Ya que una pequeña variación en el ancho de banda disponible, podría afectar produciendo micro-cortes en conversaciones y bloquear nuevos registros. Por todo esto mi proyecto de fin de carrera se centró en el estudio de las posibilidades de explotación del mismo en esta tecnología. En él se expone como durante la realización de test de rendimiento de las medidas de protección anti-DoS de distintos dispositivos SIP, nos encontramos que las herramientas disponibles en la actualidad compartían una problemática común:
  • Falta de actualización y flexibilidad, por ejemplo SIPp es una herramienta muy potente pero solo permite manipular las cabeceras SIP. No ofrece la posibilidad de hacer lo mismo en cabeceras inferiores, lo cual es necesario para comprobar como se comportan las defensas ante un ataque DDoS.
  • Heterogeneidad en lenguajes de programación y estructura, lo cual complica su utilización y sencillez a la hora de realizar modificaciones en las mismas.
  • Ausencia de mecanismos de generación de informes.
La opción elegida para solventarlo fue desarrollar distintos módulos de Metasploit que nos permitiesen realizar estos tests de una forma completa. Realmente ya están publicados en mi PFC pero adjunto aquí las versiones definitivas mucho más fieles al protocolo y, por lo tanto, más eficientes. Las imágenes muestran el módulo en funcionamiento contra un FreeSWITCH y un Asterisk. Se envían paquetes INVITE, por ser los que más fácilmente saturan un servidor SIP, como se detalla también en el proyecto.


¿Como protegernos? Afortunadamente las contramedidas para los vectores descritos son las mismas, para no alargarme demasiado paso a resumir las más conocidas a día de hoy:
  • Medidas genéricas aplicables a cualquier servidor como mantenerlo actualizado, utilizar contraseñas seguras, uso de IPtables, etc.
  • Fail2ban: Es un software que trabaja de forma conjunta con Asterisk. Su funcionamiento es simple, cuando detecta un cierto número de peticiones de una misma dirección IP lanza una orden. Normalmente una regla de IPtables para bloquear dicha dirección. El problema principal es que trabaja sobre los logs, por lo que a veces cuando bloquea una dirección es demasiado tarde.
  • Modulo PIKE: Cumple la misma función que Fail2ban pero lo hace de una forma mucho más eficiente y es parte del proxy SIP Kamailio.
  • Monitorización de llamadas: Siempre es necesario un control de los picos de llamadas sospechosos para tomar medidas en caso de que sea necesario.
  • Session Border Controller (SBC): Son, en resumen, un “todo en uno” para que organizaciones con grandes infraestructuras puedan gestionar el acceso a todas sus UC (Unified Communitacions) desde un mismo dispositivo de una forma relativamente cómoda y controlada. Realmente no representan a ningún elemento de una infraestructura VoIP estándar, fue un término inventado por los fabricantes para, según ellos, satisfacer las necesidades del mercado. El precio depende principalmente de la marca y de su naturaleza hardware o software, pero en cualquier caso es muy elevado. El coste de una instalación típica (hardware) ronda las decenas de miles de euros. Normalmente, además de disponer de distintas funcionalidades que facilitan la integración de servicios VoIP, ofrecen protección específica contra DoS y DDoS (xD) tanto para el caso de inundación como ante paquetes malformados. De este tema podríamos hablar largo y tendido ya que hay detractores y fervientes defensores, así que queda para otra ocasión. De momento voy a decir que a mí, personalmente, no me gustan las soluciones propietarias y que ninguna tecnología es la panacea.
Por este motivo en breve presentaré un nuevo proyecto personal como una posible alternativa a los sistemas propietarios para la protección frente a los vectores de ataque aquí presentados. El producto final será una caja negra (no tan negra) orientada a la securización de infraestructuras de Comunicaciones Unificadas. Entre otras, utilizará tecnologías como Kamailio, Snort y Homer, pero de momento prefiero no contar más. ;)

Bueno, pues todo listo por esta vez, se trataron diferentes temas así que si alguien tiene interés en algo en especial agradeceré que deje algún comentario para la próxima.


Un saludo.


Artículo cortesía de Jesús Pérez
Leer más...