Blog gratis
Reportar
Editar
¡Crea tu blog!
Compartir
¡Sorpréndeme!
Blog de la Escuela de Educación Secundaria Técnica N 8 de Quilmes
Administrador Prof. Claudio Enrique Alonso Alvite
img
28 de Noviembre, 2014    General

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
http://www.devconsole.info

Fuente http://www.securitybydefault.com/2014/11/como-reportar-una-vulnerabilidad-y-no.html?utm_source=feedburner&utm_medium=email&utm_campaign=Feed%3A+SecurityByDefault+%28Security+By+Default%29
Palabras claves , , ,
publicado por alonsoclaudio a las 16:56 · Sin comentarios  ·  Recomendar
 
Más sobre este tema ·  Participar
Comentarios (0) ·  Enviar comentario
Enviar comentario

Nombre:

E-Mail (no será publicado):

Sitio Web (opcional):

Recordar mis datos.
Escriba el código que visualiza en la imagen Escriba el código [Regenerar]:
Formato de texto permitido: <b>Negrita</b>, <i>Cursiva</i>, <u>Subrayado</u>,
<li>· Lista</li>
CALENDARIO
Ver mes anterior Septiembre 2017 Ver mes siguiente
DOLUMAMIJUVISA
12
3456789
10111213141516
17181920212223
24252627282930
BUSCADOR
Blog   Web
TÓPICOS
» General (2606)
NUBE DE TAGS  [?]
SECCIONES
» Inicio
ENLACES
MÁS LEÍDOS
» Cómo espiar WhatsApp
» Cómo usar Metashield protector for Client y por qué utilizarlo
» Ejecución remota de código arbitrario en OpenSSH
» Ganar dinero con 1.200 Millones de identidades robadas
» Hardware y sus 4 Funcionamientos Basicos y Principales en una Computadora
» #Phishing masivo a #BancoFrances, #PagoMisCuentas y #Movistar (110 afectados en 4 horas)
» Redes de la Deep Web: CJDNS y la Red Hyperboria
» Unidad Central de Procesamiento CPU
» Vulnerabilidad en Youtube permitió borrar cualquier video
» Wassap, la aplicación que permite usar WhatsApp desde la PC
SE COMENTA...
» Cómo espiar WhatsApp
19 Comentarios: NEGREDO, NEGREDO, wordhackers, [...] ...
» Curso en línea "Fundamentos de Administración de Sistemas Linux"
1 Comentario: ruchiroshni
» SoftPerfect WiFi Guard permite saber quién esta conectado a mi WiFi
1 Comentario: carlos lopez
» Analizando el LiveBox 2.1 de Orange
2 Comentarios: Nadie, brahim
» Antenas WiFi de gran potencia. Enlaces a 1.000 Km.
2 Comentarios: julio enoy, julio enoy
SOBRE MÍ
FOTO

Prof. Claudio Enrique Alonso Alvite



» Ver perfil

AL MARGEN
Escuela de Educacion Secundaria Tecnica N 8 de Quilmes
(Técnicos en Informática Personal y Profesional)
FULLServices Network | Blogger | Privacidad