Por qué debemos apoyar, y no castigar, a las mentes curiosas de la seguridad

Las recientes noticias sobre el joven investigador de seguridad Bill Demirkapi, quien expuso vulnerabilidades importantes en el software utilizado por su escuela, sin duda me trajeron recuerdos. Recuerdo ser ese niño curioso que levantaba el capó del software para echar un vistazo y ver cómo funcionaba todo y, lo que es más importante, si era capaz de romperlo. Durante décadas, los ingenieros de software han buscado la mejora continua y el fortalecimiento de sus productos, y la comunidad de seguridad (aunque a veces con un enfoque un tanto atrevido) desempeña un papel importante en el descubrimiento de fallos y posibles desastres, con suerte antes de que un delincuente haga lo mismo.

Sin embargo, el problema aquí es que, como respuesta a sus descubrimientos, recibió una suspensión menor por parte de la escuela. Y eso solo ocurrió después de que agotara todas las vías para contactar a la empresa (Follett Corporation) de forma privada, optando finalmente por una denuncia bastante pública para identificarse y demostrar su capacidad para vulnerar su sistema. Sus repetidos intentos de advertir éticamente a Follett Corporation no obtuvieron respuesta, mientras que el software seguía siendo vulnerable y montañas de datos de estudiantes quedaban expuestas con bastante facilidad, ya que gran parte no estaba cifrada.

También buscó errores en el software de otra empresa: Blackboard. Aunque los datos de Blackboard al menos estaban cifrados, los posibles atacantes podrían haber accedido y robado millones de registros más. Tanto este software como el producto de Follett eran utilizados por su escuela.

La narrativa del "hacker malvado" es problemática.

Demirkapi presentó sus hallazgos en la DEF CON de este año, y los detalles más traviesos de sus travesuras fueron aplaudidos por el público. Y con razón: aunque al principio fue visto con malos ojos y se enfrentó a muchos obstáculos para que sus descubrimientos fueran reconocidos, al parecer Follett Corporation agradeció sus esfuerzos y actuó según sus consejos, logrando finalmente que su software fuera más seguro y evitando la crisis de convertirse en otra estadística de filtración de datos. Además, asistirá al Instituto de Tecnología de Rochester después de terminar la escuela secundaria, por lo que está claro que va por el camino correcto para convertirse en un especialista en seguridad muy solicitado.

Como alguien que trabaja en seguridad, me resulta difícil no cuestionar cómo se manejó esta situación. Aunque bien está lo que bien acaba, al principio fue tratado como un molesto "script kiddie" que metía las narices donde no debía. Una búsqueda en Google sobre el incidente muestra artículos que se refieren a él como un "hacker" (en la mente del profano en seguridad, esto lo posiciona como el villano en muchos sentidos), cuando en realidad su enfoque (y el de muchos otros) es lo que ayuda a mantener nuestros datos seguros.

Necesitamos personas curiosas, inteligentes y centradas en la seguridad que miren bajo el capó, y necesitamos que esto ocurra con mucha más frecuencia. Hasta julio, más de cuatro mil millones de registros han quedado expuestos en filtraciones de datos maliciosas solo este año. Es posible añadir otros cincuenta millones a esa cifra, gracias a la brecha de agosto en la marca de moda y estilo de vida Poshmark.

Estamos cometiendo los mismos errores y, lo que es más preocupante, a menudo se trata de vulnerabilidades simples que nos siguen haciendo tropezar.

El cross-site scripting y la inyección SQL no han desaparecido.

Como informó WIRED, Demirkapi descubrió que el software de participación comunitaria de Blackboard y el sistema de información estudiantil de Follett contenían errores de seguridad comunes como el cross-site scripting (XSS) y la inyección SQL, ambos presentes en el sector desde la década de 1990. Hemos soportado su existencia durante muchísimo tiempo y, al igual que las camisetas Hypercolor y los disquetes, ya deberían ser un recuerdo lejano.

Pero no lo son, y está claro que no hay suficientes desarrolladores que demuestren una conciencia de seguridad adecuada para evitar su introducción en el código. Las herramientas de escaneo y las revisiones manuales de código solo pueden hacer hasta cierto punto, y existen problemas de seguridad mucho más complejos que el XSS y la inyección SQL, donde estas medidas costosas y lentas podrían aprovecharse mejor.

Personas como Bill Demirkapi deberían inspirar a los desarrolladores a crear un estándar de código más alto; con solo 17 años, vulneró dos sistemas de alto tráfico mediante vectores de amenaza que deberían haber sido detectados y corregidos antes incluso de que el código fuera implementado.

Gamificación: ¿La clave para el compromiso?

He escrito mucho sobre por qué los desarrolladores siguen estando en gran medida desvinculados de la seguridad, y la respuesta corta es que no se está haciendo mucho, ni a nivel organizativo ni educativo, para fomentar desarrolladores conscientes de la seguridad. Cuando las empresas se toman el tiempo de construir una cultura de seguridad que recompensa y reconoce el compromiso, incluyendo la implementación de una formación que hable el lenguaje de los desarrolladores y los motive a seguir intentándolo, estas molestas reliquias de vulnerabilidad comienzan a desaparecer del software que utilizamos.

Demirkapi obviamente tiene un interés extracurricular en la seguridad y se ha tomado el tiempo de aprender a realizar ingeniería inversa en malware, detectar fallos y, bueno, romper cosas que no parecen rotas desde fuera. Sin embargo, al hablar con VICE (y a través de sus diapositivas de la DEF CON), hizo una declaración interesante sobre su autoaprendizaje... lo gamificó:

"Con el objetivo de encontrar algo en el software de mi escuela, fue una forma divertida y 'gamificada' de enseñarme una cantidad significativa de pruebas de penetración. Aunque comencé mi investigación con la intención de aprender más, terminé descubriendo que las cosas estaban mucho peor de lo que esperaba", dijo.

Aunque no todos los desarrolladores querrán especializarse en seguridad, a todos se les debería dar la oportunidad de ser conscientes de ella, con los conceptos básicos sirviendo casi como una "licencia para programar" dentro de una organización, especialmente para aquellos que controlan grandes cantidades de nuestros datos confidenciales. Si todos los desarrolladores pudieran parchear los agujeros de seguridad más simples antes de que se escriban, estaríamos en una posición mucho más segura frente a aquellos que buscan causar estragos.

¿Tienes curiosidad por la formación gamificada? Echa un vistazo a nuestra serie Coders Conquer Security sobre XSS y inyección SQL.