Encontrar un fallo de seguridad en una aplicación o servicio conocido puede llegar a ser lucrativo...o meterte en graves problemas legales. Vamos a dar un repaso al arte de reportar vulnerabilidades.

Sabes que está ahí, lo puedes sentir, es ese olor ocre y salino de la sustancia que emana de la presa herida. El cazador lo percibe, agudiza sus sentidos y acecha en silencio; esperando pacientemente al momento adecuado. Un segundo más, abres el editor de texto (Vim, naturalmente) y cambias dos lineas de tu script. Zas!: ejecución remota de código arbitrario conseguida. Premio. ¿Ahora qué hacemos con el trofeo?



Hace poco, leía en una viñeta de esas que aparecen, brillan y se extinguen en un par de milésimas de red social, que los Ingenieros Mecánicos y Aeronáuticos confían plenamente en aquello que diseñan y construyen. Es decir, es seguro y transmiten esa seguridad. Soluciones contrastadas, experimentadas. No dejan espacio al error, lo arrinconan, le temen, lo respetan, pero lo desafían y controlan hasta reducirlo a probabilidades muy reducidas. Ahora pregunta lo mismo a un Ingeniero Informático...

En el software las probabilidades son las mismas, pero en sentido contrario. Es decir, es ridículamente improbable que encuentres un programa que esté libre de errores. Irónicamente...no falla. Hay algo en el proceso de construcción de nuestros ingenios que impide que estén libres de errores. Esto no es nuevo, ya lo dijo el grandísimo Fred Brooks: No hay balas de plata. El software es complejo, mucho y está lejos de ser perfecto.


No hay dos errores iguales

Bien, creo que lo hemos dejado claro o al menos lo hemos intentado. El software está lleno de errores. El problema añadido es que los errores no son idénticos, poseen una jerarquía, gravedad y especializaciones propias. De entre ellos podemos destacar los errores de seguridad, que al fin y al cabo son los que nos interesan. Estos son especialmente graves de por sí, puesto que conllevan un impacto asociado a una necesidad humana: la de sentirnos seguros. 

No es lo mismo un error funcional, por ejemplo: Cuando pulso esta opción de menú aparece una molesta ventana de error, pero el proceso sigue su curso, que uno de seguridad: Cuando pulso sobre esta opción de menú, aparece una molesta ventana de error, le doy al cuadro de ayuda, mostrar propiedades, abrir consola, pum, eres administrador. Evidentemente, las consecuencias no son las mismas.

Además -para mejorar la cosa- está el primo hermano del error: el contexto. Puedes tener un error, poco grave a primera vista y que, por ejemplo, solo afecta al redondeo de unos pocos decimales. ¿Nada grave, verdad? Escala eso a millones de entradas en un software científico y tendrás un error de magnitudes incalculables. La diferencia suficiente entre hallar la vacuna del ébola a encontrar un nuevo colorante industrial para la gaseosa. Uy, por cuatro péptidos de nada.


Economía de mercado

Vale, ya sabemos que el software es un saco de bichos, que estos pueden ser más o menos graves y que las consecuencias de un fallo de seguridad pueden ser desastrosas según el contexto. ¡Anda!, ¿Y qué pasaría si descubres un error por el cual un tercero le podría sacar una rentabilidad económica o mediática? Pues que acabas de encontrar un billete de lotería premiado. Descubres algo, lo trasladas a un interesado a cambio de unos doblones y este usa esa información para su propio beneficio. Eso, amigos, nos lleva a construir una auténtica economía de mercado (con su equivalente paralelo mercado negro) basada en los errores de seguridad.

Servicios de inteligencia, contrainteligencia, brokers de exploits, productores de software de control remoto, unidades militares que participan en operaciones de ciberguerra, robo de propiedad intelectual, etc. Hay intereses de todo tipo y ejemplos que vemos casi a diario de demanda de nuevos zero-days para mantener el frente abierto. Una vez sale el parche, se acabaron las nuevas operaciones...hasta que el siguiente exploit devuelva la pelota al campo. 

Y aun no hemos mencionado las botnets, el cryptojacking y el ransomware. Muchas de ellas se apoyan en la mera ingeniería social e ir probando suerte con campañas de phishing para ir infectando equipos. Sin embargo, esta técnica suele tener un porcentaje sorprendentemente bajo de éxito. No obstante, cuando estas campañas van acompañadas de un exploit fresco, la rentabilidad en los primeros días se dispara exponencialmente. 

Que nadie crea que vender un exploit es algo exclusivo del mercado negro. Existen compañías dispuestas a pagar una suma importante de dineros a cambio de esa secuencia única de ceros y unos. 


Bug hunting, cuando la necesidad crea el producto

Hastiadas por ver como sus productos se convertían en un continuo mercadeo que afecta a sus usuarios, las empresas comenzaron a dar un paso en un peculiar sentido: No lo vendas a ellos, compártelo con nosotros. Ahora son las propias empresas, afectadas por los errores de seguridad en sus productos, las que compran los fallos de seguridad a sus descubridores.

Uno de los primeros programas de este tipo es el de Google. Allá por el 2013 anunció que pagaría por los errores de seguridad en sus productos; ahora incluso por ciertos proyectos de fuente abierta, cuyas librerías son usadas por ellos. Este paso llevó a otras compañías a anunciar el emprendimiento de programas de este tipo con pequeñas variaciones en cuanto a reglas y premios.

Tras ellos, otros con buen olfato vieron claro que aquí había negocio. ¿Por qué no abrir el negocio del reporte de fallos de seguridad? Estaba claro que había una necesidad y, por otro lado, un batallón de personas interesadas en investigar y descubrir fallos. Así que si hay una demanda y por otro una oferta...unámoslos con el pegamento universal que todo el mundo entiende y usa: el dinero.

Este tipo de esquema asume que la gente va a seguir investigando, sean cuales sean sus motivaciones y que los servicios y productos desarrollados por empresas son demasiado grandes como para ser controlados por un departamento. Win-win. Todos ganan, todos contentos.

En algunos casos, el investigador ni tan siquiera es premiado económicamente. Existen programas de recompensas que solo premian con una mención o con merchandising, dependiendo de la gravedad del hallazgo. Esperad, esperad, no os riáis. Una mención puede parecer ridícula, pero en el curriculum de un investigador puede ser la diferencia con el resto de candidatos. Por otro lado, las vulnerabilidades especialmente graves pueden llegar a reportar beneficios de cientos de miles de dólares. Como vemos el abanico de premios es surtido.



¿Cómo reportar una vulnerabilidad que no posee un programa de recompensas?

Es complicado. Muchas empresas no se toman bien este tipo de acciones. Quizás porque derivan a departamentos legales donde no saben maniobrar de otra forma que no sea abriendo fuego contra el supuesto enemigo o porque se toman como una ofensa el que alguien haya estado husmeando en sus servidores. Sea como fuere, si una empresa no indica explícitamente la manera de reportar fallos de seguridad, no se los reportes directamente.

Desde luego no reportar no implica que no des conocimiento. Existen muchísimas posibilidades de hacerlo sin meterte en un lío legal. Por un lado has descubierto algo, sabes que es ético que dicho fallo se conozca y sea reparado, pero por otro tienes miedo de que tu buena intención acabe trayéndote quebraderos de cabeza y arrastres tu alma y tus ahorros por los juzgados del país durante unos cuantos años. 

En España puedes probar con el CERTSI, donde te ofrecen anonimato y si en un plazo de tiempo prudencial no se ha encontrado solución por parte del fabricante, se publicarían los detalles de tu hallazgo con tu nombre si lo deseas.

Francamente, si te gusta encontrar fallos y ganarte un dinero y renombre, las opciones anteriores, del tipo Bugcrowd o Hackerone poseen un buen equilibrio. Busca un programa de recompensas que te interese, léete las condiciones y a cazar!