“Para ir por donde no se sabe, has de ir por
donde no se sabe”
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.
Consultor de Seguridad IT
Analista de Sistemas
http://www.devconsole.infoFuente 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
