Este siempre es uno de los temas que más polémicas levantan cuando te encuentras en una reunión de profesionales de la seguridad informática. ¿Hacer público un fallo o avisar al fabricante y esperar a que lo arregle aplicando un principio de Responsible Disclosure?
La verdad es que yo soy de los de descubrimiento responsable… (casi siempre) y abogo por avisar siempre al fabricante. Así, cuando nos topamos con el fallo del componente de Joomla (que al final parcheamos nosotros), los productos afectados por las técnicas de Connection String Parameter Pollution o el caso del "no-bug" de Google Chrome, por poner algunos ejemplos que han salido por aquí, siempre hemos avisado primero al fabricante de software.
En el tema de los fallos en las páginas web, yo hace tiempo que opté por no avisar a ninguna directamente y hacerlo siempre por medio de los cuerpos de seguridad del estado. Así, fallos que hemos sacado en organizaciones grandes han pasado por nuestros cuerpos de seguridad españoles para que estos les mandaran un aviso oficial.
Sin embargo, cuando estuve en la Troopers 2010 [vídeos disponibles!], Marsh Ray, uno de los descubridores del bug de SSL-Renegotiating, discutí sobre este tema. El argumento de Marsh es:
“OK, yo soy responsable porque aviso del fallo, pero… ¿Cuánto tiempo debe tomarse el fabricante para corregirlo? ¿Cuál es el tiempo “responsable” que debe tomarse un fabricante para corregir un bug? ¿Y si dice que no lo va arreglar? En caso de que un fabricante se tome más tiempo del que debe o en el caso de que diga que no lo va a corregir, entonces lo responsable es publicarlo para que la gente conozca el riesgo. Nunca tienes la seguridad de ser el único que conoce ese fallo”.
La verdad es que Marsh es único argumentando, y discutir con él durante toda la Troopers fue de lo mejor. Ellos publicaron la información sobre el fallo de SSL sin esperar que fuera corregido por todos. Lo cierto es que en su caso muchos dijeron que era un ataque "teórico" que no podría ser explotado o que sería muy dificil. Tiempo después se utilizó para atacar a Twitter o los firewalls CISCO, como hará Ben Feinstein en la próxima BlackHAT USA 2010 bajo el título "The Emperor Has No Clothes: Insecurities in Security Infrastructure". Estos acontecimientos han hecho que todo el mundo se ponga a corregir el "fallo-teórico".
Sin embargo, yo no tengo claro cuándo es “demasiado tiempo”. Hasta el momento, cuando nosotros hemos avisado, la respuesta ha sido “lo vamos a corregir” y se ha corregido en un tiempo “prudencial” o, como en el caso de Google Chrome… “esto funciona así y no lo vamos a corregir hasta futuras versiones” lo que nos llevó a publicarlo en full-disclosure porque pensamos que era una característica insegura.
A día de hoy seguimos creyendo en un descubrimiento responsable de los fallos como la mejor opción, pero… ¿cuál ha sido tu experiencia?
Saludos Malignos!
La verdad es que yo soy de los de descubrimiento responsable… (casi siempre) y abogo por avisar siempre al fabricante. Así, cuando nos topamos con el fallo del componente de Joomla (que al final parcheamos nosotros), los productos afectados por las técnicas de Connection String Parameter Pollution o el caso del "no-bug" de Google Chrome, por poner algunos ejemplos que han salido por aquí, siempre hemos avisado primero al fabricante de software.
En el tema de los fallos en las páginas web, yo hace tiempo que opté por no avisar a ninguna directamente y hacerlo siempre por medio de los cuerpos de seguridad del estado. Así, fallos que hemos sacado en organizaciones grandes han pasado por nuestros cuerpos de seguridad españoles para que estos les mandaran un aviso oficial.
Sin embargo, cuando estuve en la Troopers 2010 [vídeos disponibles!], Marsh Ray, uno de los descubridores del bug de SSL-Renegotiating, discutí sobre este tema. El argumento de Marsh es:
“OK, yo soy responsable porque aviso del fallo, pero… ¿Cuánto tiempo debe tomarse el fabricante para corregirlo? ¿Cuál es el tiempo “responsable” que debe tomarse un fabricante para corregir un bug? ¿Y si dice que no lo va arreglar? En caso de que un fabricante se tome más tiempo del que debe o en el caso de que diga que no lo va a corregir, entonces lo responsable es publicarlo para que la gente conozca el riesgo. Nunca tienes la seguridad de ser el único que conoce ese fallo”.
La verdad es que Marsh es único argumentando, y discutir con él durante toda la Troopers fue de lo mejor. Ellos publicaron la información sobre el fallo de SSL sin esperar que fuera corregido por todos. Lo cierto es que en su caso muchos dijeron que era un ataque "teórico" que no podría ser explotado o que sería muy dificil. Tiempo después se utilizó para atacar a Twitter o los firewalls CISCO, como hará Ben Feinstein en la próxima BlackHAT USA 2010 bajo el título "The Emperor Has No Clothes: Insecurities in Security Infrastructure". Estos acontecimientos han hecho que todo el mundo se ponga a corregir el "fallo-teórico".
Sin embargo, yo no tengo claro cuándo es “demasiado tiempo”. Hasta el momento, cuando nosotros hemos avisado, la respuesta ha sido “lo vamos a corregir” y se ha corregido en un tiempo “prudencial” o, como en el caso de Google Chrome… “esto funciona así y no lo vamos a corregir hasta futuras versiones” lo que nos llevó a publicarlo en full-disclosure porque pensamos que era una característica insegura.
A día de hoy seguimos creyendo en un descubrimiento responsable de los fallos como la mejor opción, pero… ¿cuál ha sido tu experiencia?
Saludos Malignos!
La única vez que he encontrado un fallo de segurida "xungo" lo hablé con mi jefe, me hecho una bronca del copón, luego a escondidas reportó él el fallo y se llevo el reconocimiento...
ResponderEliminarPor suerte ya no trabajo ahí...
lol, vaya un cabrón está hecho tu ex-jefe...
ResponderEliminarHe aquí la cuestión...reportar o no una vulnerabilidad??
ResponderEliminarEstoy en mi casa navegando por una web y descubro ciertos fallos en la web gracias a mi constante curiosidad. Les aviso mediante un mail que aportan desde la web sobre el fallo? Qué beneficios puedo sacar ayudándoles a nivel particular? Avisarlo mediante los cuerpos de seguridad... qué procedimiento lleva?
Buenas, pues yo comentare mi experiencia pero es parecida a la de Scan.
ResponderEliminarYo actualmente no me dedico a la seguridad si no al desarrollo, pero como muchos de nosotros, soy un vicioso de la seguridad y siempre ando a ver que rompo. La cosa es que en un proyecto para el gobierno de Aragon, encontre un fallo muy importante en Crystal Reports XI, curiosamente ese mismo fallo valia para el resto de versiones (r2, 2008...), resumiendo te hacias con la cuenta de administrador del servidor, y de eso pues elevación de privilegios, robo de información.... Se lo comente a mi jefe de proyecto y las implicaciones que podia tener eso para todos los datos de nuestra aplicación, me dijo que seguridad era cosa de los de sistemas, los de sistemas que no sabian ni que era Crystal Repors pero que tampoco les importaba, le mando un mail al comercial de SAP asignado a mi empresa, que a el le venia dando igual pero que oye, felicidades por descubrirlo, que hable con la gente de desarrollo sap.....les mande un correo tambien a ellos y los reyes magos por si colaba...
Conclusión, a dia de hoy sigue siendo un fallo que esta funcionando. Lo mas curioso es que gracias a la foca saque un monton de servidores de crystal reports y reporte un monton fallos de seguridad de empresas, entre ellas el gobierno argentino que incluso me pidio consejo para securizar el servidor!!
Aun asi coincido totalmente que reportar fallos a webs es perder el rato, yo a menos que sea un fallico muy cantoso no en plan 1=1 ni me molesto...y ni aun asi....pero vamos que en cuanto ves el minimo fallo yo soy de los que enciendo el portatil con las 400 distribuciones y aplicaciones malignas y me pongo a juguetear antes de reportar....por documentarme ehhh! jaja
Saludos!
@Scan
ResponderEliminarSeguro que no has sido el único. Alertas de un fallo y el que recibe el mail se tira el pisto no solo con el hallazgo sino con la solución.
Y mientras te comes los mocos...
Lo de las web puede ser hasta peligroso...Sobre todo ahora con el nuevo código penal, con sus artículos 137 y 264, ¿no puedes buscarte un lío serio si informas al propietario de una web vulnerable y se lo toma a mal?
ResponderEliminarEn cuanto a informar primero al fabricante antes de hacerlo público, me parece lo correcto...Claro que si trabajas en Google y descubres una vulnerabilidad en el HSC a lo mejor no te mueve lo correcto sino otra cosa...No sé por qué se me ha venido esto a la mente ahora.
Saludos
full-disclosure FTW! Porque tendrías que trabajar gratis para las empresas de software? Si descubres un fallo en una aplicación, tu eres libre de hacer lo que quieras... otra cosa seria que lo usaras para hacer cosas ilegales, pero hacerla publica es una solución tan valida como avisar al vendor.
ResponderEliminarAlgunos lo llaman "Amor al arte" :-)
ResponderEliminarEso de programar gratis está fatal, GPL y perroflautas... hay que gastarse la pasta en empresas que SI saben qué hacen.
ResponderEliminarY cobran porque después ya ves que te encuentras con los programas de perroflautas.
Eso sí, ser un free beta-tester mola.