Mostrando entradas con la etiqueta vulnerabilidad. Mostrar todas las entradas
Mostrando entradas con la etiqueta vulnerabilidad. Mostrar todas las entradas

16 septiembre 2015

El investigador de seguridad Mark Dowd ha descubierto una vulnerabilidad MUY grave en una librería presente en iOS y OSX, y fácilmente explotable a través de la aplicación AirDrop (propia de dispositivos Apple para intercambio de archivos) que permitiría la escritura de ficheros de forma ajena sobre sistemas iOS y OSX.

El video que incluimos a continuación, grabado por el propio investigador, demuestra dicha vulnerabilidad. Se puede ver el exploit para iOS 8.4.1:



Justo hoy se ha hecho pública la actualización de iOS 9, y esta vulnerabilidad obliga a todos sus usuarios la actualización de forma urgente. Dicha actualización no soluciona la vulnerabilidad por completo, pero si que ofrece una mitigación
Leer más...

29 julio 2015

Nominados a los Pwnie Awards 2015

Un año más, los premios a los mejores FAILs en seguridad informática (a este paso habrá que hacer varias convocatorias) Pwnie Awards serán entregados durante la Black Hat USA que se celebrará en Las Vegas entre el 1 y el 6 de Agosto.


Desde ayer, ya tenemos la lista de nominados para cada una de las categorías propuestas. En negrita, he marcado mis preferencias para ser los ganadores.

Pwnie for Best Server-Side Bug

  • SAP LZC LZH Compression Multiple Vulnerabilities (CVE-2015-2278, CVE-2015-2282)
  • Clobberin' Time (CVE-2014-9293, CVE-2014-9295)
  • Magento(CVE-2015-1397)

Pwnie for Best Client-Side Bug

  • Will it BLEND? (CVE-2015-0093, CVE-2015-3052)
  • Sandworm (CVE-2014-4114)
  • It's ESET Up!
  • W3TotalFail

Pwnie for Best Privilege Escalation Bug

  • Rowhammer
  • PingPongRoot (CVE-2015-3636)
  • UEFI SMM Privilege Escalation
  • Wild TTF Overflow
  • Will it BLEND? (CVE-2015-0093, CVE-2015-3052)

Pwnie for Most Innovative Research

  • ret2dir
  • Modern Platform-Supported Rootkits
  • Threatbutt Advanced Enterprise Platform
  • Abusing Silent Mitigations
  • Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice

Pwnie for Lamest Vendor Response

  • "A Peek Under The Blue Coat"
  • Seagate NAS RCE
  • Samsung Swift Keyboard MITM RCE

Pwnie for Most Overhyped Bug

  • Shellshock (CVE-2014-6271)
  • iOS CoreText DoS (CVE-2015-1157)
  • VENOM (CVE-2015-3456)

Pwnie for Best Song

  • "Try Harder!" - Offensive Security
  • "Integer Overflow" - NYAN
  • "Clean Slate" - YTCracker
  • "Spierdalaj Kurwa" - Acid Flux, Dariush Gee

Pwnie for Most Epic FAIL

  • Oh, Please... Man! (OPM)
  • We're Not Quite Sure (Bank in Poland)
  • Peepin' on the Creepin' (Ashley Madison)
  • ManageEngine
  • Aviator (WhiteHat Security)

Lifetime Achievement Award

  • Ivan Arce
  • Gera Richarte
  • Wu Shi
  • Halvar Flake
  • Rolf Rolles

Pwnie for Epic 0wnage

  • Kaspersky Lab (Duqu 2)
  • Hacking Team
  • U.S. Office of Personnel Management
  • The World (always China)
  • Samsung Swiftkey Keyboard Bugdoor
Queda muy poco para saber los verdaderos ganadores, actualizaremos este post con los resultados, pero por el momento, podéis dejar vuestras apuestas en los comentarios. ¡Que gane el "peor"!

Leer más...

02 abril 2015

Vulnerabilidad en Youtube permitió borrar cualquier video




El investigador de seguridad Kamil Hismatullin descubrió una vulnerabilidad (grave) en la plataforma de vídeos online Youtube mediante la cual, aprovechando un problema en la lógica de una de las funcionalidades, podría borrar cualquier vídeo subido de cualquier usuario.

El script en cuestión se encuentra en la siguiente URL:
  • https://www.youtube.com/live_events_edit_status_ajax?action_delete_live_event=1
El cual acepta, mediante método HTTP POST, dos parámetros:
  • event_id: identificador del video a eliminar
  • session_token: token de sesión válido de cualquier usuario diferente al del propietario del vídeo a eliminar
Esta funcionalidad se utiliza dentro de la aplicación YouTube Creator Studio, la aplicación de edición de videos para usuarios de Youtube tanto para iOS como para Android, en la que entre otras funciones, también permite la gestión de los videos.

A continuación enlazamos el video que demuestra la vulnerabilidad y su explotación:


Como veréis, una vulnerabilidad grave, con una explotabilidad muy sencilla. Si bien Kamil no ha recibido una gran cantidad de dinero por esta vulnerabilidad en base a su impacto (5.000$), por apenas 5/6 horas de investigación no está mal.

Imaginad por un momento haber elegido otros videos más importantes para ser eliminados...

Leer más...

04 marzo 2015

FREAK: La última amenaza contra SSL/TLS






Ya tenemos entre nosotros la publicación de una nueva vulnerabilidad de impacto alto, en algunas implementaciones del protocolo SSL/TLS.

Según leo en ArsTechnica, investigadores del Microsoft Research y del French National Institute for Research in Computer Science and Control, han descubierto una vulnerabilidad que afectaría entre otros a los dispositivos cliente basados en IOS y Android, entre otros. 

Para la explotación de dicha vulnerabilidad, el atacante necesita estar en una posición que le permita situarse en medio de la comunicación entre cliente y servidor.

Para ello el atacante intercepta el handshake inicial entre cliente y servidor, e inyecta cierta información que fuerza al servidor (si es que este lo permite) a hacer un downgrade de la seguridad de la comunicación, utilizando una clave de sesión RSA de 512 bits de longitud. El contenido de la comunicación, al poder ser interceptada, podrá ser descifrada offline, crackeando la clave en unas 7 horas y media con el hardware adecuado. 

Esta vulnerabilidad se ha llamado FREAK por las siglas de "Factoring Attack on RSA- Export Keys” y acompañan a otras tantas vulnerabilidades, como Heartbleed o Poodle, que han desmitificado las comunicaciones cifradas por uno de los protocolos más utilizados en Internet.  Se ha asignado el identificador CVE-2015-0204

¿Por qué es posible hacer este downgrade para usar longitud de claves consideradas débiles?

En los 90, la administración Clinton, decidió regular la robustez del cifrado utilizado para software y hardware exportados fuera de Estados Unidos, para que se utilizasen longitudes de clave más débiles. 

En el inicio de la comunicación cifrada entre cliente y servidor, se establece un intercambio de algoritmos a utilizar en la misma, dependiendo de las capacidades y configuración de ambas partes. Normalmente, se suele utilizar (si así está configurado) el algoritmo más seguro soportado por ambas partes, pero por compatibilidad con sistemas más antiguos (tanto de cliente como de servidor) queda la puerta abierta a utilizar el cifrado que exija menor rendimiento (muchas veces, como en este caso, la necesidad no es técnica, sino legal!) 




Básicamente, si el servidor soporta el algoritmo TLS_RSA_EXPORT_WITH_DES40_CBC_SHA, el servicio es vulnerable. 
  
¿Quién es vulnerable?

Por las estadísticas que se han obtenido, y aunque van disminuyendo el número de servidores afectados por la misma, en el momento de redacción de este post, hay un 10% de servidores afectados del Top 1 Millón de dominios de Alexa (según la web https://freakattack.com/), aunque ha disminuido del 12,2% anterior. 

Desde el punto de vista del cliente, Android, IOS y Chrome sobre cualquier plataforma, lo es. Puedes comprobar si tu navegador es vulnerable a este fallo en: https://freakattack.com/clienttest.html

Como se puede ver la última versión de Google Chrome, sobre Mac OS X, es vulnerable


Ojo, recordamos que esta situación sólo aplica en entornos donde sea posible MiTM, y en los que el servidor y cliente sean vulnerables, por lo que aunque tendrá su quota de explotación, es algo a tener en cuenta. Desde mi punto de vista, los dispositivos servidores más afectados, serán aquellos que no permitan actualización sencilla y que implementen SSL/TLS como OpenSSL. Me refiero a dispositivos con servidor web embebido como sistemas de gestión de alarmas, cámaras, etc,...

Como siempre, no fiarse de redes inalámbricas, tener grabada a fuego la correspondencia entre las direcciones MAC e IP de vuestro gateway en el PC y utilizar conexiones 3G (para sólo desconfiar del ISP), son medidas más que interesantes.

Desde el punto de vista del servidor, en aquellos que se pueda, recomendamos la utilización de algoritmos de cifrado fuertes, como hicimos Yago y yo en el Curso de "Attack & Hardening de GNU/Linux”,  cuando hablábamos de securización de servidores Apache.
Leer más...

27 noviembre 2014

Como reportar una vulnerabilidad y no morir en el intento

Para ir por donde no se sabe, has de ir por donde no se sabe” 
San Juan de La Cruz

Esta es una pequeña historia que confirma que con algo de curiosidad, trabajo duro e insistencia se llega casi siempre a buen puerto. Es el relato sincero de una humilde batalla, de cómo descubrimos la vulnerabilidad que afectaba a Drupal (CVE-2014-9016) y a Wordpress (CVE-2014-9034), de cómo un día Drupal decidió corregirla y de cómo tuvimos que esperar un día más para ver la actualización de Wordpress, de las vicisitudes y dudas que tuvimos al reportarla, y de cómo conseguimos sortearlas... Tan solo es un ejemplo más, para todos aquellos que se adentren como novatos, en estas aguas turbulentas de los CERT y el Responsible Disclosure. 

“Alicia se levantó de un salto, porque comprendió de golpe que ella nunca había visto un conejo con chaleco, ni con reloj que sacarse de él, y, ardiendo de curiosidad, se puso a correr tras el conejo por la pradera, y llegó justo a tiempo para ver cómo se precipitaba en una madriguera que se abría al pie del seto. 
Un momento más tarde, Alicia se metía también en la madriguera, sin pararse a considerar cómo se las arreglaría después para salir."
Alicia en el País de las Maravillas - Lewis Carrol

Igual que Alicia, de la misma manera nosotros descubrimos una madriguera, la curiosidad, la chispa que conduce a todo conocimiento, surge al leer acerca de una vulnerabilidad en OpenSSH que permite enumerar usuarios simplemente mandando contraseñas enormes y viendo el tiempo de respuesta del sistema, lo que se conoce como Timing Attacks. Para mentes inquietas que mejor que una respuesta inesperada, esas son la madrigueras que todos estamos buscando.

No dudando en adentrarnos más profundo, pues deseamos comprender, nos preguntamos por el proceso de autenticación en OpenSSH, y descubrimos, ¡¡Oh sorpresa!! que las funciones que habitualmente se utilizan, tienen una curiosa particularidad, a saber, que el tiempo que tardan en realizar el cálculo depende de la longitud del “chorizo” que le metas. Aquí, la aparentemente banal madriguera, por la que nos metimos, se vuelve realmente interesante, porque la siguiente cuestión es “¿En qué otros lugares se utilizan estos artefactos?”. La respuesta era PHP y sus hijos los CMS.

Así es que empezamos a buscar esa respuesta inesperada en algunos de los CMS más famosos, y ¡¡Oh sorpresa!! uno de lo más laureados y utilizados, Wordpress, usa estas funciones y no controla, y he aquí el verdadero problema de seguridad, la longitud del input. La imaginación más retorcida vuela, y se pregunta, ¿qué pasaría si en vez de meter un “chorizo” metemos varios “chorizos” a la vez?

Este es el final de la madriguera, en ese momento te despiertas, la mente se vuelve práctica y escribes un script...

Muchas emociones y preguntas, como novatos que somos, se te ocurren cuando ves que tu script funciona y que eres capaz de tirar tu entorno de pruebas con un 100% de éxito, te sientes con poder. Y lo primero que se te viene a la mente es… bien, ¿cómo puedo sacar el mayor beneficio de esto a la vez que se arregla este fallo? ¿Puedo monetizarlo y a la vez tener reconocimiento?

Zero Day Initiative es una buena oportunidad, pagan por fallos de seguridad a la vez que te dan un reconocimiento cuando el parche es publicado. ¡¡Perfecto!! ¡¡Justamente lo que buscamos!! Así es como le hacemos llegar todos los detalles, nuestro script “wp-exploit.py” y una prueba de concepto. Desgraciadamente la vida es dura, y recibimos una contestación descorazonadora:
“We are not interested in vulnerabilities affecting this product.”
Conscientes de la “poderosa” herramienta que habíamos desarrollado decidimos ponernos en contacto con el CERT de todos los CERT, buscando ayuda y ya solo el reconocimiento y arreglo de dicho fallo. Confiados les escribimos, y horas después desestiman nuestros deseos con buenas e incomprensibles palabras:
“Any web application is vulnerable to this denial of service attack without some sort of protection”
Y nos exhortan a ponernos directamente en contacto con Wordpress. Lógicamente, y sin perder un segundo, nos ponemos en contacto con Wordpress en sus diferentes puntos de contacto, direcciones de correo tales como (security@wordpress.com) y a través de la plataforma Hackerone. Entusiasmados y esperando una rápida respuesta, los días fueron pasando a la vez que las semanas, tan solo recibiendo una lánguida respuesta que decía: 
“Hi, Thanks for your report. We see you also submitted this to security@wordpress.org. The WordPress Core Security Team is currently evaluating your report and we will get back to you as soon as we can.”
El tórrido y cálido verano acechaba ya sobre nuestras cabezas, y ninguna contestación más recibimos de la gente de Wordpress, nuestro entusiasmo inicial se diluía como azucarillo en agua, y las vacaciones impusieron su silencio.

Como los buenos potajes, que se cuecen a fuego lento, a la vuelta de vacaciones, decidimos darle un nuevo calentón al asunto. La madriguera de nuevo aparecía abierta y nos metimos de cabeza, descubriendo que otro CMS muy muy conocido, a la sazón Drupal en su versión 7, adolecía del mismo problema. Esta vez fuimos al grano y escribimos directamente a Drupal. Con gran alegría y alborozo celebramos que reconocían el fallo, y en menos de dos horas ya tenían el parche preparado, junto con un Security Advisory que sacarían en las semanas próximas.

Aun así, nuestra preocupación y ansiedad creció al pensar en Wordpress, nada sabíamos de ellos, y en cuanto sacaran los de Drupal su Advisory muchos pensarían inmediatamente ¿Y en Wordpress? Nos pusimos de nuevo en contacto con Wordpress, advirtiéndoles de que otro conocido CMS sacaría el mismo fallo a la luz. Su respuesta fue la misma, el vacío del silencio.

Los días pasaban, y nuestro nerviosismo crecía, por nuestra mente rondó incluso el Full Disclosure. Pero no, las repercusiones podrían ser grandes, así es que decidimos ponernos en contacto de nuevo con el CERT. Una vez más vez con la intención de que simplemente mediaran entre Wordpress y nosotros. Después de varios correos con el CERT, después de poner todos nuestros ESFUERZOS en hacer entender nuestra visión de los acontecimientos y poniendo en precedentes que otro CMS lo iba a arreglar y el perjuicio de los administradores y usuarios de Wordpress, decidieron por fin contactar con ellos…

En este mundillo, no hay nada mejor que ir de la mano de un gran CERT y como muestra un botón. En horas Wordpress responde pidiendo disculpas por el “traspapeleo” de este caso. Reconocen el fallo y nos avanzan que será solucionado en breve. Mientras tanto, Drupal saca el parche de seguridad el Miércoles día 19 de Noviembre y tenemos que esperar un día más, el Jueves 20 de Noviembre para ver como Wordpress saca su actualización de seguridad.

Durante este tiempo, hemos reflexionado sobre un eterno problema, el Full Disclosure y su contrapartida en el Responsible Disclosure tal como ocurrió en esta entrada de SbD. En nuestro caso nos decidimos por este último, publicaríamos todos los detalles sobre el fallo dando la oportunidad a quien esté realmente interesado en conocer el alcance del fallo a la vez de facilitarle el camino para llegar al mismo punto al que llegamos nosotros. Ahora bien, decidimos no publicar la PoC para de esta manera, dar tiempo suficiente a los administradores de actualizar sus sistemas al mismo tiempo que no ofrecíamos un arma cargada a personas con pocos conocimientos y escrúpulos. La PoC será publicada más adelante, cuando todos los sistemas deberían haber sido actualizados.

Javier Nieto @behindfirewalls
Consultor de Seguridad IT

Andrés Rojas @cor3dump3d
Analista de Sistemas

Leer más...

07 agosto 2014

Pwnie Awards 2014

Ayer 6 de Agosto, se celebró la entrega de premios de los Pwnie Awards 2014, como todos los años, durante el congreso de seguridad Black Hat USA en Las Vegas. Si no conocías estos premios anteriormente, puedes acceder a otras menciones de este evento en nuestro blog, del que nos hemos hecho eco desde casi el 2009. Como resumen, se entregan los premios a los mejores FAILs en seguridad informática.


Esta claro que este año, reina en casi todas las categorías en las que aplique, la vulnerabilidad de OpenSSL Heartbleed, que hizo las delicias de todos al poder comprobar su facilidad en la explotación y como consiguió romper el propósito del servicio.

Las categorías de premios para este año son:

  • Best Server-Side Bug - Mejor vulnerabilidad del lado del servidor
  • Best Client-Side Bug - Mejor vulnerabilidad del lado del cliente
  • Best Privilege Escalation Bug - Mejor vulnerabilidad que permita escalada de privilegios
  • Most Innovative Research - Mejor trabajo de investigación
  • Lamest Vendor Response - Respuesta más absurda por parte de un fabricante
  • Best Song - Mejor canción
  • Most Epic FAIL - El FAIL más épico
  • Epic Ownage - El compromiso/incidente/brecha de seguridad más épico

Si bien todavía no tenemos los resultados de los ganadores, por el momento enumeramos a continuación, para cada una de las categorías, los candidatos a llevarse esta peculiar estatuilla:
  • Best Server-Side Bug - Mejor vulnerabilidad del lado del servidor
    • Abusing JSONP with Rosetta Flash (CVE-2014-4671) - Michele Spagnuolo
    • Heartbleed (CVE-2014-0160) - Neel Mehta and Codenomicon - GANADOR
    • IPMI: Sold Down the River - Dan Farmer
    • Embedded Device Hacking - Craig Heffner
  • Best Client-Side Bug - Mejor vulnerabilidad del lado del cliente
    • Google Chrome Arbitrary Memory Read Write Vulnerability (CVE-2014-1705) - Geohot - GANADOR
    • Heartbleed (CVE-2014-0160) - Neel Mehta and Codenomicon
    • Pwn4Fun Safari vulnerability (CVE-2014-1300) - Ian Beer
    • Goto Fail (CVE-2014-1266) - Anonymous
  • Best Privilege Escalation Bug - Mejor vulnerabilidad que permita escalada de privilegios
    • AFD.sys Dangling Pointer Vulnerability (CVE-2014-1767) - Sebastian Apelt - GANADOR
    • VirtualBox VM Breakout using 3D Acceleration (CVE-2014-0981) - Francisco Falcon
    • Linux Futex Bug (CVE-2014-3153) - Comex and Geohot
    • evasi0n iOS 7.0 jailbreak - evad3rs
    • Pangu iOS 7.1 Jailbreak - Pangu, Stefan Esser y otros
  • Most Innovative Research - Mejor trabajo de investigación
    • Hardware-assisted Memory Corruptions - Ralf-Philipp Weinmann
    • Bypassing Windows 8.1 Mitigations using Unsafe COM Objects - James Forshaw
    • RSA Key Extraction via Low-Bandwidth Acoustic Cryptanalysis - Daniel Genkin, Adi Shamir, Eran Tromer - GANADOR
    • Windows 8 UEFI Secure Boot Bypasses Yuriy Bulygin, Andrew Furtak, Oleksandr Bazhaniuk, John Loucaides from Intel Security, Corey Kallenberg, Xeno Kovah, John Butterworth, Sam Cornwell
    • Hacking Blind - Andrea Bittau, Adam Belay, Ali Mashtizadeh, David Mazieres, Dan Boneh
  • Lamest Vendor Response - Respuesta más absurda por parte de un fabricante
    • OpenCart PHP Object Injection Vulnerability - Daniel de OpenCart
    • Fired, I? - FireEye
    • AVG Remote Administration Insecure "By Design" - AVG - GANADOR
    • Faulty Ignition Switch - General Motors
  • Best Song - Mejor canción
    • "I'm a C I Double S P" - Host Unknown
    • "Memory Corruption" - NYAN
    • "Expect Us (We Are Anonymous)" - Z0ph0kl3z
    • "Security Kate" - Dale Chase
    • "The SSL Smiley Song" - 0xabad1dea - GANADOR
  • Most Epic FAIL - El FAIL más épico
    • Goto Fail - Apple - GANADOR
    • Heartbleed - Open Source Community
    • Target Breach - Target
    • ISC2 Optional Membership Fee - ISC2
  • Epic Ownage - El compromiso/incidente/brecha de seguridad más épico
    • Heartbleed (CVE-2014-0160) - Neel Mehta and Codenomicon
    • Target Breach - Anonymous
    • Inputs.io - Anonymous
    • Mt. Gox - Mark Karpelès - GANADOR
Leer más...

10 julio 2014

¿Límite de espacio? No en Dropbox….

Los servicios de almacenamiento están a la orden del día. Los usamos para hacer backup de nuestros datos, para compartir grandes volúmenes de información etc…

La mayoría de estos servicios te dejan un espacio gratuito y te cobran por querer almacenar mas datos. También suelen incluir limitaciones como limitar la velocidad en las descargas.

Uno de los servicios mas usados es Dropbox, tienes una cuenta gratuita si quieres, es multiplataforma e incluso puedes instalarla en tu Smartphone o Tablet.

Con NaxoneZ, se nos ocurrió echarle un vistazo a Dropbox a ver si podíamos encontrar alguna vulnerabilidad en su plataforma para optar al Bug Bounty.

Después de buscar y buscar a NaxoneZ se le ocurrió una manera curiosa de saltarse una de las restricciones que aplica Dropbox, el espacio con la cuenta gratuita.

¿Cómo se explota la vulnerabilidad?

Antes de entrar en detalle, vamos a ver cuanto cuesta el servicio Premium y que características ofrece:


Además de pagar Dropbox ofrece descuentos si eres Universitario si comprabas algún Smartphone de la marca HTC, si invitabas a otros usuarios a formar parte del servicio etc… Es decir, ofrece facilidades para el aumento de espacio.

Pero no contentos con eso, decidimos echarle un vistazo para ver si podíamos hacer Bypass de la restricción. Para ello, no hizo falta nada mas que:

· Alguien que te comparta una carpeta con un tamaño superior al permitido en la cuenta free
· Un navegador
· Cuenta en Dropbox (Obviamente xD)
· Firebug

Lo primero que haremos será compartir una carpeta con un tamaño por ejemplo de 35 GB. Cuando se comparte una carpeta, Dropbox manda una solicitud al usuario al que le has compartido la carpeta.

Cuando el usuario que recibe la invitación quiere aceptar la carpeta, si no dispone de espacio suficiente por el tipo de cuenta que tiene, podrá ver el botón de “Aceptar” deshabilitado y un “bonito” mensaje que pone:

“You need more space to accept this folder".

Yo no quería compartirle la carpeta a NaxoneZ y le dije que pagara la cuenta Premium, “que eran 4 chavos” y que no podría compartirle la carpeta porque no era usuario Premium. Ante eso, solo pudo tomar una posición:
Si le pegamos un vistazo al código fuente, vemos:


Esto lo cambiaremos por:


Una de las líneas importantes a tener en cuenta es:


Deberemos de cambiar ese valor, por el de la carpeta a la que queremos obtener acceso.
Para obtener dicho valor, deberemos de mirar el código fuente del botón donde pone Deny.


Finalmente se consigue tener acceso a la carpeta, saltando la restricción del espacio.
Es gracioso que incluso en el estado de nuestra cuenta aparece que hemos sobrepasado el espacio.


Alguno puede pensar que es un fallo de seguridad tal y como creemos NaxoneZ y yo, pero en cambio Dropbox contestó lo siguiente:

No contentos con la respuesta preguntamos el motivo de no aceptación del fallo.
La respuesta fue:


Obviamente no estamos de acuerdo, ya que si se hiciera de forma masiva, Dropbox podría encontrarse en un grave problema. ¿Vosotros que opináis?

Por otro lado, la camiseta prometida por el “fallo” nunca ha llegado, pero si el aumento de espacio. Pero… Lo del espacio ya lo teníamos, ¿Qué  hemos ganado? xD

Este es uno de los ejemplos en los cuales se ve claramente como no es aceptado un fallo usando la opción de Bug Bounty que ofrecen algunas empresas.

Para no tener problemas con la publicación, avisamos de que lo haríamos público (ahí pensamos que se tirarían para atrás), pero nuestra sorpresa fue recibir esto

Así que nada, si no es importante a nadie le importará que lo hagamos público

Artículo cortesía de @NaxoneZ y @Seifreed
Leer más...

08 abril 2014

Desangrando el corazón de OpenSSL (CVE-2014-0160)

Estamos ante una de las vulnerabilidades más graves (opinión personal) de los últimos años. Y no sólo vulnerabilidad, la explotación tiene efectos que sinceramente, tras verlos, asustan.

Ayer 7 de Abril se publicó una vulnerabilidad en OpenSSL 1.0.1 que permitiría a un atacante obtener 64Kb de memoria. Pueden parecer pocos, pero os aseguro que en dicha sección de memoria se pueden encontrar credenciales, cookies de sesión, claves privadas, etc, de los clientes y servidores conectados al servidor vulnerable. El aluvión de tweets referentes a este tema fue masivo, han sido unas navidades anticipadas con un regalo en forma de vulnerabilidad que permite ser explotada en cualquier servicio vulnerable expuesto sin apenas ser detectado.

Esta vulnerabilidad ha sido descubierta por Neel Mehta del equipo de Google Security, y el CVE reservado (CVE-2014-0160) fue creado el 3 de Diciembre de 2013:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160

Impacto tras explotación

La información que se podría obtener sería la siguiente:

  1. Claves privadas
  2. Usuarios y contraseñas utilizadas en servicios vulnerables
  3. Información sensible utilizada por servicios vulnerables
  4. Direcciones de memoria y su contenido que podría permitir evadir mecanismos de mitigación ante exploits.

¿Mi servidor es vulnerable?

Rápidamente, comenzaron a publicarse herramientas que permitían tanto comprobar si un servidor es vulnerable como obtener la información tras su explotación.

Servicio online en http://filippo.io/Heartbleed para comprobar si un servicio web es vulnerable
El caso más sonado fue el de Yahoo.com, cuya página de autenticación de usuarios login.yahoo.com ha sido vulnerable durante un día entero, corriendo imágenes de su explotación como la pólvora en redes sociales, mostrándose usuarios y contraseñas (en caso de encontrarse conectados en el momento del análisis).


Cómo corregir esta vulnerabilidad

Lo primero y más importante, actualizar la librería OpenSSL a una versión no vulnerable, a partir de la 1.0.1g. También se recomienda encarecidamente regenerar toda aquella información afectada, claves de usuarios, claves privadas... Esta tarea puede ser ardua y suponer un esfuerzo considerable, pero nadie nos asegura si, durante el período hasta la actualización de nuestros servicios vulnerables, pudiera haberse explotado este fallo para obtener de manera masiva información sensible.

Otro método para su corrección consiste en deshabilitar el soporte de Heartbeat en OpenSSL, recompilándolo con la opción -DOPENSSL_NO_HEARTBEATS

En este enlace del GIT de openssl se pueden ver las modificaciones realizadas sobre los ficheros d1_both.c y t1_lib.c que solventarían esta grave vulnerabilidad.

¿Qué páginas se encuentran afectadas?

Unas cuantas...

Se ha puesto a disposición de todos un listado del TOP 1000 portales web según el ranking de ALEXA, mostrando si son vulnerables o no. El listado corresponde con el estado de dichas webs durante el 8 de abril siendo confeccionada tras la ejecución de la herramienta de comprobación de manera masiva.


Muchas páginas de proyectos importantes, como Cloudflare que lo indica en un post dentro de su blog, tuvieron constancia de la vulnerabilidad una semana antes de su publicación, teniendo tiempo para corregir la vulnerabilidad en sus servidores. Otros muchos, parece que han hecho caso omiso aún habiendo tenido el privilegio de haber sido informados (ya que todo ha seguido las normas del responsible disclosure).

Existe una página considerada "oficial" de Heartbleed dedicada a intentar responder todas las preguntas referentes a esta vulnerabilidad: http://heartbleed.com

En el siguiente listado disponible dentro del advisory en kb.cert.org se encuentran todos los fabricantes afectados hasta el momento.

Leer más...

19 junio 2013


En la actualidad, es cada vez más frecuente la instalación de cámaras de vídeo tanto en recintos privados como en la vía pública, con la finalidad de garantizar la seguridad de una instalación, la seguridad de las personas o el correcto desempeño de cualquier tarea en diversos ámbitos. 

De hecho, los sistemas de videovigilancia se publicitan como la solución para la seguridad debido en mayor medida a su gran facilidad de uso, ya que solo es necesario un dispositivo capaz de conectarse a la red para poder ver por ejemplo el tráfico en la m-30, nuestro negocio o incluso a nuestros hijos jugando en casa.

Sin embargo, ¿nos hemos planteado si estos sistemas son realmente fiables? ¿quién nos asegura que sólo estamos mirando nosotros? estas y otras cuestiones son las que hemos tratado de responder en el siguiente estudio: Cámaras IP de Videovigilancia: Seguridad y Protección, o Inseguridad y Exposición

Somos un grupo de estudiantes del 
 Máster Universitario en Seguridad de las TIC  que ofrece la UEM realizando el Proyecto Fin de Máster a cargo de Alejandro Ramos como Director de Proyecto, en el que elaboramos un análisis del estado actual en los sistemas de video.

Recopilación de información, modelos y cámaras.


Para comenzar la investigación se construyó un inventario de las principales marcas y modelos de cámaras y nos centramos en tres líneas de investigación básica: Firmware, Web, ActiveX-Applet.
Se intentó buscar los antecedentes de las vulnerabilidades para estas líneas de investigación y creamos una metodologías a aplicar para cada una de ellas.
Por otro lado se estudió de manera casi individual las cámaras, a través de la información que los propios fabricantes facilitan en sus páginas web, tales como manuales de usuario o datasheet.

Por último se comprobó la existencia en la web de las cámaras relacionadas con la investigación para ver el grado de productos expuestos y vulnerables en la red.

La siguiente imagen muestra una recopilación de simples búsquedas sobre algunas de las cámaras elegidas:

Búsquedas en Shodan



Desarrollo de Metodologías

Metodología firmware

En esta parte se analiza el firmware de las cámaras IP. Para ello, hay que obtener el firmware de las cámaras,  que generalmente se encuentra en la página web del fabricante y suele estar compuesto por:
1.Firmware header , 2.Bootloader, 3.Kernel, 4. Filesystem
Se utiliza la herramienta binwalk para identificar y separar las partes que lo componen.
Se intenta buscar algún archivo oculto, información sobre la versión Linux, o sobre el Kernel. Gracias a comandos como “strings” se pueden buscar cadenas que puedan ser útiles. Por último se trata de extraer y montar el filesystem, con comandos como “mount”, para ver cómo está compuesto y ver si presenta alguna vulnerabilidad o nos puede ayudar con otras.


Metodología Web

Estas cámaras suelen usar un servicio web con HTTP sobre TCP en el puerto 80 para proveer a sus usuarios. Adicionalmente suelen usan protocolos como TELNET, FTP, RTSP, SMTP para los mismos fines u otros como pueden ser la gestión y configuración del dispositivo, un servidor ftp o de correo, transmitir audio o vídeo, etc y que también se deben chequear.

Para identificar y localizar las vulnerabilidades se ha utilizado metodología
OWASP, adaptándola a este tipo de dispositivos para tratar de adecuar las pruebas lo máximo posible.

Metodología ActiveX-Applet

Todas estas cámaras utilizan siempre algún componente cliente (ActiveX o Applet) para mostrar y reproducir las imágenes.
En estos componentes se pueden detectar vulnerabilidades de todo tipo: corrupción de memoria, acceso a información sensible, modificación, escritura o eliminación de ficheros, accesos sin credenciales…
Para ello, durante la fase de análisis, se han buscado vulnerabilidades similares a éstas mediante pruebas manuales o por medio de diversas aplicaciones.  En un artículo previo de SBD se explica de manera detallada cómo hacerlo.

Detección y recopilación de vulnerabilidades

Se han detectado un total de 14 vulnerabilidades en 7 modelos distintos de cámaras IP de los 9 totales analizados, la siguiente tabla muestra un resumen de las mismas:    

Resumen de Vulnerabilidades Encontradas
Resumen de Vulnerabilidades Encontradas
Para más información, las vulnerabilidades fueron reportadas en fulldisclosure en este enlace.
A continuación, se va a dar un repaso a las más importantes de todas las encontradas, para mostrar la peligrosidad de las vulnerabilidades.

CVE-2013-3542, GrandStream GXV Series. TELNET backdoor.
Se ha encontrado una puerta trasera en el protocolo TELNET, que permite acceder remotamente a estos dispositivos con credenciales de superadministrador para gestionar o configurar la cámara mediante línea de comandos. Únicamente hay que conectar con el dispositivo mediante TELNET e introducir la cadena mágica "!#/" como usuario y contraseña.
Esto implica que, usando esta vulnerabilidad, se pueda acceder a todos los modelos citados en el reporte y hacernos con el control de estas cámaras.


El vídeo se divide en dos partes: en la primera, se muestra los usuarios que hay creados en una de estas cámaras mediante la interfaz web, después se conecta con la misma mediante TELNET y se accede usando la puerta trasera. En la segunda, se simula como se accedería remotamente a una cámara de la que se desconocen las credenciales mediante TELNET, para restaurar la configuración de fábrica y finalmente acceder a la cámara usando el interfaz web para confirmar que se ha logrado.

CVE-2013-3541, Airlive WL2600CAM. Relative Path Traversal.
Este tipo de vulnerabilidad permite leer información sensible perteneciente al sistema de ficheros del dispositivo vulnerable.

Debido a este tipo de vulnerabilidad somos capaces de leer cualquier fichero que esté dentro del directorio “/etc/” . Previamente se analizó el firmware para obtener el sistema de ficheros y ver hasta dónde se tenía acceso.

En el vídeo se observa cómo se accede a los ficheros "passwd" y "device.conf" usando las siguientes URLs:
Estos ficheros contienen entre otras cosas, las contraseñas de todos los usuarios del sistema de ficheros, todo el archivo de configuración del sistema, direcciones IPs, DNS por defecto, privilegios de usuarios, modos de lectura/escritura, servicios activos, etc.

En la siguiente imagen se muestra algunas como ejemplo:

Archivo "../etc/device.conf"
Archivo "../etc/device.conf"
CVE-2013-3691, Airlive. Denegación de Servicio (DoS).
Es posible crear una denegación de servicio sobre el servicio web que corre en este tipo de dispositivos. Este DoS será causado lanzando una petición sobre la ruta “/” que contenga una gran número de caracteres.
CVE-2013-3688, TP-LINK. Execute Remote Command bypassing authentication.
Se ha encontrado que es posible la ejecución remota de comandos por HTTP, sin necesidad de estar autenticado.

El vector de ataque que se muestra en el vídeo es:
Mediante este ataque se consigue restaurar la configuración de fábrica de la cámara y obtener el control del dispositivo haciendo uso de las credenciales por defecto.

CVE-2013-3689, Brickcom. Authentication Bypass & Clear Text Storage of Sensitive Information
Esta vulnerabilidad permite descargar todo el archivo de configuración del dispositivo mediante la copia de seguridad o backup, sin tener ninguna credencial ni estar autenticado, permitiendo obtener toda la información sensible del dispositivo.

En el vídeo se muestra cómo se obtendría este archivo, siguiendo la siguiente URL.
En el vídeo y en la siguiente imagen, se puede ver cómo se localizan los usuarios y contraseñas, entre otros datos sensibles, al instante:

Archivo "configfile.dump"
Archivo "configfile.dump"

CVE-2013-3690, Brickcom. Cross Site Request Forgery (CSRF) + Privilege Escalation.
Este  ataque permite manipular los parámetros que usa la interfaz web, pudiendo crear, modificar o eliminar usuarios con credenciales de administrador, reiniciar la cámara o restaurarla a su configuración de fábrica original, etc.

En el vídeo se muestra cómo a través de esta vulnerabilidad, se consigue una escalada de privilegios de un usuario “observador” a uno “administrador”, insertando un vector de ataque en un documento .HTML específicamente creado para ello.

El siguiente vídeo muestra los detalles sobre los últimos 5 CVE's de los que se han hablado:


CVE-2013-3543, Axis.  File Corruption.
La vulnerabilidad afecta a la última versión de “AXIS Media Control“ (6.2.10.11, publicada el 19 de Octubre de 2012), software recomendado por el fabricante para ver imágenes de video en Internet Explorer. Ésta herramienta incluye una serie de métodos ActiveX inseguros dentro de la librería "AxisMediaControlEmb.dll": "StartRecord()", "SaveCurrentImage()" y "StartRecordMedia()".

Con esto, un usuario malintencionado puede explotar esta vulnerabilidad para dejar en un estado inconsistente el sistema de la victima, sobrescribiendo cualquier fichero o generando archivos aleatorios con contenido basura.

A continuación se incluye un video a modo de ejemplo en el que se detalla como explotar la vulnerabilidad mediante el uso de uno de los métodos ActiveX vulnerables:
 


Herramienta de búsqueda de vulnerabilidades

Como complemento al proyecto, hemos generado un script en Python que analiza un total de 9 pruebas de concepto relativas a los protocolos RTSP y HTTP empleados por todas las cámaras.
RTSP es un protocolo de nivel de aplicación no orientado a conexión similar a HTTP. Sin embargo, se diferencian en los siguientes aspectos:
  • RTSP introduce nuevos métodos y tiene un identificador de protocolo diferente.
  • Un servidor RTSP necesita mantener el estado de la conexión.
  • Tanto el servidor como el cliente pueden hacer solicitudes.
  • Los datos son transportados por un protocolo diferente.
El código, junto con un manual de usuario, están disponibles en el siguiente enlace:

Resultados de la Herramienta
Resultados de la Herramienta

Conclusiones

La finalidad de este estudio es evaluar el estado actual de seguridad de las cámaras de videovigilancia. Para ello, hemos analizado un total de 9 marcas distintas: Airlive, Axis, Brickcom, Grandstream, Samsung, Sony, TP-Link, AV-Tech y Geovision. El resultado ha sido bastante clarificador: 14 vulnerabilidades en 7 de las 9 marcas auditadas.

Todas estas vulnerabilidades comprometen gravemente la seguridad y privacidad de la información además del correcto funcionamiento del servicio.
El 90% de las cámaras encontradas en Internet tienen credenciales por defecto.
Además, hemos reportado todas y cada una de las vulnerabilidades a los fabricantes. Únicamente 2 de los 7 fabricantes (Grandstream y TP-Link) nos han comunicado que han desarrollado un parche tras nuestro reporte, solucionando alguna de las vulnerabilidades detectadas.

En conclusión, podemos afirmar que la gran mayoría de las Cámaras de Videovigilancia IP no están preparadas para conectarse en una red abierta, debido a la gran cantidad de fallos de seguridad que poseen. Esto obviamente choca completamente con su función y nos hace preguntarnos cómo es posible que un dispositivo destinado a la seguridad acabe resultando un foco de exposición.

Autores:
  • Eliezer Varadé Lopez
  • Javier Repiso Sánchez
  • Jonás Ropero Castillo


Leer más...

12 junio 2012

Vulnerabilidad grave en MySQL/MariaDB - CVE-2012-2122

No es el día de los Santos Inocentes, ni de aquí (28 de Diciembre) ni internacional (April's Fool). El sábado 9 de Junio  Sergei Golubchik, coordinador de seguridad de MariaDB publicaba un post en la lista OSS-SEC sobre una grave vulnerabilidad que afectaba a diferentes versiones de MySQL y MariaDB.

Se evidencia la posibilidad de autenticarse como usuario con máximos privilegios (root) únicamente realizando conexiones simultáneas, con CUALQUIER contraseña introducida como parámetro y contra un servidor vulnerable. Al cabo de un número indeterminado de intentos fallidos, el servidor aceptará la conexión y se realizará la autenticación de forma satisfactoria. Sin más. Sin shellcodes raras, sin casuísticas extrañas: únicamente tenemos que tener delante un servidor vulnerable, que cumpla con las siguientes versiones:

  • Son vulnerables todas las versiones de MariaDB y MySQL hasta la 5.1.61, 5.2.11, 5.3.5 y 5.5.22
  • NO SON vulnerables las versiones de MySQL 5.1.63, 5.5.24 y 5.6.6
  • NO SON vulnerables las versiones de MariaDB 5.1.62, 5.2.12, 5.3.6 y 5.5.23
Con la siguiente línea en shell script, teniendo instalada una base de datos vulnerable en el sistema local, y contando con el cliente 'mysql', se podría realizar una autenticación como usuario root sin conocer la contraseña:

for i in `seq 1 1000`; do mysql -u root --password=blablabla -h 127.0.0.1 2>/dev/null; done

Básicamente, se ejecutará la sentencia de autenticación mediante cliente por consola (comando mysql) como usuario root (-u root) y cualquier contraseña (--password=blablabla) contra el servidor vulnerable  presente en el mismo sistema donde se ejecuta este script (-h 127.0.0.1), sin mostrar ningún mensaje de error por pantalla (2>/dev/null).

Vamos a ver el ejemplo real. Las siguientes pruebas se han realizado sobre una Fedora Core 16, con MySQL versión 5.5.21:


En primer lugar, y para este ejemplo, cambiaremos la contraseña original de MySQL para el usuario root, que antes la teníamos establecida a 'password', para que ahora sea 'SuperPassWordDeLaMuerte':


Seguidamente, salimos de la sesión de root, y nos quedamos como usuario sin privilegios, y ejecutamos la secuencia anterior, que realizará conexiones como usuario root y cualquier contraseña, programando un total de 1000 intentos. A continuación se ejecutará la consola de mysql satisfactoriamente:



Comprobamos el usuario con el que estamos autenticados mediante la sentencia select current_user(), obteniendo como resultado 'root@localhost'


Obviamente, este "ataque" ya se encuentra integrado como exploit de Metasploit Framework, permitiendo además el volcado de hashes de todos los usuarios, todo ello con el módulo mysql_authbypass_hashdump:



Enhorabuena desde SecurityByDefault a los descubridores de este bug, verlo para creerlo...De momento, ¡una de las vulnerabilidades descubiertas favoritas para este año 2012!



Leer más...

08 abril 2012

Flashback botnet: ¿Vulnerabilidad de Java? No, de Mac OS X


He de confesar que mi motivación para escribir este post en la tarde de un domingo, es expresar mi visión ante el artículo que escribió Eduardo Arcos en el archiconocido blog de Tecnología ALT1040 "Flashback botnet: ¿Vulnerabildad de Mac OS X? No, de Java".

En él, el popular blogger ecuatoriano, culpaba a Oracle (propietario de Sun, y por ende de la tecnología JAVA) del fallo de moda que ha causado que más de 600.000 equipos con sistema operativo Mac OS X, hayan sido infectados por el troyano Flashback, exculpando a Apple del tema. Asimismo en dicho artículo, el autor afirmaba categóricamente: "Pero Mac OS X al ser basado en UNIX es sumamente seguro y por lo tanto mucho menos vulnerable".

Con estas premisas, me gustaría dar mi punto de vista sobre lo que, a mis ojos (y parece ser que ante los de los lectores de ALT1040 que dejaron sus comentarios al controvertido artículo también), es una opinión equivocada. Para empezar, y por desmitificar el título del artículo: La culpa de esta vulnerabilidad, es de Apple! ¿Por qué? pues principalmente, porque el motor Java incluido en el sistema operativo Mac OS X lo implementa Apple y no ORACLE. Es por eso que la organización encargada de publicar los parches necesarios para corregir las vulnerabilidades que surjan para este módulo es Apple, y no ORACLE.    

Apple, gracias al boom de sus equipos informáticos (portátiles, sobremesa, ipads, iphones, etc,…) ha ido ganando cada vez más cuota de mercado. Evidentemente, y por qué no decirlo, desgraciadamente, el porcentaje de mercado para los dispositivos con sistema operativo Mac OS X, es irrisoria comparada con el todopoderoso parque de PCs con Windows, distribuidos por el Mundo. Sin embargo, dada la gran aceptación de este sistema operativo por parte de un público, harto de pantallazos azules, que busca funcionalidad de serie y estabilidad en un sistema operativo de escritorio, ha levantado la bandera para que los desarrolladores de malware pongan en su punto de mira la explotación de vulnerabilidades de Mac OS X. 

Hasta hace unos años, los early adopters usuarios de Apple, vivían felices, viendo como los usuarios de Windows eran constantemente atacados por malware específico para explotar sus vulnerabilidades. ¿Se podía decir que Mac era seguro? Categóricamente NO. Lo que se podía decir es que no había virus, o la proporción era muy baja, o simplemente que sentarse a buscar vulnerabilidades para un público tan reducido no era rentable para los desarrolladores de malware. Sin embargo, y debido a esta explosión de márketing hacia Apple, los "gusanos para las manzanas" se han multiplicado y, el mejor ejemplo de que las amenazas están ahí, es que prácticamente todas las casas de software antivirus han publicado una versión específica para Mac OS X.
 
Ante este panorama, a Apple no le ha quedado más remedio que empezar a ponerse las pilas con la seguridad de sus soluciones, materia en la que no eran precisamente expertos. Cuando Windows ya implementaba tecnologías como DEP Data Execution Prevention en el Service Pack 2 de Windows XP en 2004 o ASLR Address Space Layout Randomization en aquella decepción consumidora de recursos que era Windows Vista (en Enero de 2007), Apple introducía DEP en 2006 y una implementación decente en Mac OS X Lion (en 2011). Es decir que en este sentido, Windows ha tenido una conciencia de seguridad mucho mayor que Apple a la hora de implementar tecnologías más seguras en cuanto a la ejecución de aplicaciones.

Como se puede observar con este último ejemplo en el troyano Flashback, la celeridad en el publicación de parches no es precisamente algo de lo que Apple, ni sus usuarios, podamos vanagloriarnos, habiendo sido publicado el parche para esta vulnerabilidad de JRE, por parte ORACLE, en Febrero de 2012. En este caso, hasta mes y medio después, no ha existido solución por parte de Apple. Incluso el primero de los parches, presumiblemente no debió ser todo lo acertado/fino posible por lo que Apple tuvo que re-publicar un parche para esta vulnerabilidad, al día siguiente.

Asimismo, los usuarios de Tiger y Leopard, actualmente se encuentran indefensos ante esta y otras futuras  vulnerabilidades, al haberse detenido el desarrollo de parches para dichas versiones de OS X.

Así pues, queda demostrado que la afirmación de que "Mac OS X, al ser basado en UNIX, es sumamente seguro y mucho menos vulnerable" es completamente incierta, fruto de la impulsividad de un fanboy, incondicional a una marca que, efectivamente hace dispositivos y sistemas operativos muy atractivos, muy usables, muy estables y muy funcionales,… pero cuyo nivel de seguridad es cuanto menos mejorable, al igual que el de TODOS los demás sistemas operativos, y los módulos involucrados en los mismos.

Quiero indicar que, en mi situación personal, usé Windows como sistema operativo de escritorio hasta el 2003. A partir de ahí, empecé a utilizar KDE sobre Linux, y a mediados de 2008 relegué Linux a mi uso diario en mi servidor, pasando a usar Mac OS X como herramienta de trabajo diario hasta el día de hoy, estando además muy satisfecho con sus niveles de rendimiento y usabilidad.

La seguridad es un proceso, y como tal, debe evolucionar a la vez que lo hace la propia innovación de los productos de la marca. Estoy seguro que Apple, como el gigante innovador que es, tendrá esta experiencia en cuenta y se pondrá las pilas, como hizo Microsoft en su día, para disponer de niveles de seguridad acordes con la calidad estética y funcional de sus productos.
Leer más...