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

11 comments :

JuanQ dijo...

Hola, creo que quizá la próxima vez deberíais probar contactar con entidades como FIRST primero, donde la gente es muy colaborativa y tiene contactos directos con los equipos de seguridad en la mayoria de organizaciones. Un saludo.

Ignacio Agulló dijo...

Enhorabuena por la investigación. Os topáis con un dilema ético. Entiendo que la vulnerabilidad solamente permite ataques de denegación de servicio que no ponen en peligro los datos de los usuarios. Así que ante la expectativa de que Drupal informe de la vulnerabilidad al publicar el parche, y a cualquier otro investigador se le ocurra estudiar esa misma vulnerabilidad en Wordpress, caben dos temores:
a) Que mentes malintencionadas utilicen esa vulnerabilidad para realizar ataques de denegación de servicio a instalaciones de Wordpress.
b) Que otro investigador publique la vulnerabilidad antes que vosotros y se lleve el mérito.

Para mí la línea roja está en que si no peligran datos personales no se justifica la Revelación Completa y por tanto yo no la consideraría. Si los desarrolladores de Wordpress están avisados y les da igual que les lluevan ataques de denegación de servicio, problema de ellos. Para el investigador que ha hecho un trabajo y quiere asegurarse de que se le atribuye el mérito, siempre hay formas. ¿No existe un eGarante global donde depositar la prueba de concepto, cifrada bajo una contraseña que se revela más tarde?

Hernán Möller dijo...

Hasta cuando tratamos de colaborar con entes que no quieren que colaboremos?


No more Free Bugs!

David dijo...

Deduzco de lo que habeis contado que vuestros objetivos no se han cumplido, o por lo menos no en su mayor parte. Por lo que veo, de dinero ni un duro y de reconocimiento más bien poco. Por lo que parece el único reconocimiento público ha sido publicar este post aquí, que tiene un buen número de visitas (para público hispano sólo) pero no parece mucha recompensa, ya que en un día pocos se acordarán de quién los descubrió... corregidme si me equivoco en las afirmaciones anteriores, por favor.



Por eso tengo unas preguntas para vosotros, si sois tan amables, y os agradeceré enormemente las respuestas.


¿Ha merecido el esfuerzo el resultado obtenido? ¿Lo volveríais a hacer? ¿Por qué SbD y no por ejemplo Chema Alonso, que también tiene un número muy grande de visitas? Diría que Chema más visitas y más ahora que está en la radio, la tele, revistas...y que seguramente también aceptaría.
¿Habeis notada incremento de visitas a vuestros blogs? ¿Cuánto? ¿Alguna oferta de trabajo a raíz de esto? ¿Alguna forma de monetizar el bug? Si lo hubiérais vendido, ¿cuánto os habrían pagado? ¿Pensasteis en esa posibilidad? ¿Posibilidad de gira por conferencias? ¿Citas con modelos muy gupas y noches de desenfreno? ;)





Tengo más pero no quiero hacerme muy pesado, así que muchas gracias por compartir vuestra experiencia con nosotros.


Saludos.

random dijo...

Eso es trabajo de programadores pagados. Si quieren parches gratis que liberen el código fuente.
Full Disclosure contra el software propietario.

marcos dijo...

Leyendo la descripción de la vulnerabilidad encontrada y los datos que aportais. Es muy facil hacer un POC sabiendo un poco de programación.

https://api.drupal.org/api/drupal/includes!password.inc/function/user_hash_password/7
https://api.drupal.org/api/drupal/scripts!password-hash.sh/7

gpl dijo...

El wordpress y drupal son privativas?

c0r3dump3d dijo...

Gracias por tus comentarios. En ningún momento nuestras motivaciones fueron el dinero, el reconocimiento, ni el de salir de gira, ni el de ligarnos a tías buenas, como hemos explicado en el post, nos movió la simple curiosidad.


Ahora es cierto que una vez encontramos el fallo nuestra idea, lógica, fue intentar sacar el mayor rédito posible, ya sea económico o de reconocimiento. El económico ha sido imposible, y por el reconocimiento se ha cumplido a la perfección. Así es que estamos muy contentos y satisfechos.

Javier Nieto dijo...

Aquí tienes la PoC ;)

http://www.behindthefirewalls.com/2014/12/cve-2014-9016-and-cve-2014-9034-PoC.html

Kayla Marrie dijo...

Yo estoy aquí para dar testimonio de la buena labor del Dr. Olokum. Hace 4 años, mi esposo se fue de casa, él nunca volvió, nada de llamadas, ni cartas, ni correos electrónicos, ni rastro de él en cualquier lugar. mi hija se enfermó con la esclerosis múltiple, las cosas eran tan duro para mí. Yo había perdido la esperanza, hace 2 años, conocí a un psíquico, me dijo que me ayudaría, he pagado más de 500 y todavía no pasó nada, perdí la esperanza. por completo, mi situación hijas empeoró cada mes day.last, vi un anuncio relativo a las good.works de todo los profesionales, les di una oportunidad? pedí los tres hechizos (Traiga Lover. atrás, Healing hechizo y hechizos de Carrera). En cuestión de semanas, mi esposo me llamó y me dijo que era. lo siento y que quiere volver a mí y que iba a explicar todo cuando regrese, tres días después, recibí un nuevo trabajo con una compañía de préstamos y las finanzas, en este momento, la condición de mi hija ?? s is.getting mejor cada día y confío en que estaría bien en cuestión de days.I quiero agradecer, LAVENDERLOVESPELL@YAHOO.COM por sus esfuerzos y por traer a mi vida vuelva a la normalidad y tan cerca.

Kayla Marrie dijo...

Quiero agradecer al Dr. Olokum para llevar alegría y felicidad a mi relación y mi familia. Perdí a mi novio, y yo requería ayuda hasta que me encontré con el Dr. Olokum el verdadero hechicero, Y él me aseguró que voy a tener mi novio de vuelta en dos días después de que el hechizo se ha fundido. dos días después, mi teléfono sonó, y así sorprendentemente, era mi novio, que no me ha llamado por mucho tiempo, e hizo una apología de la rotura del corazón, y me dijo que él está dispuesto a dedicar el resto de su vida conmigo. ola princetess lo soltó hasta saber lo mucho que me amaba y quería que él .. en este momento yo y mi novio es vivir una vida feliz y nuestro amor es ahora más fuerte que la forma en que eran incluso antes de nuestro descanso up..All agradecimiento a DR Olokum por el excesivo trabajo que ha hecho por mí. A continuación se muestra que la dirección de correo electrónico en la situación en la que está siendo sometido a una rotura del corazón, y te aseguro que a medida que la mina ha hecho por mí, ella definitivamente le ayudará también. Email: LAVENDERLOVESPELL@YAHOO.COM