Por qué debemos apoyar a los agentes de seguridad curiosos y no castigarlos

Informes actuales del joven investigador en seguridad Bill Demirkapi El descubrimiento de graves fallos de seguridad en el software utilizado en su colegio seguramente le habrá traído algunos recuerdos. Recuerdo que era un niño curioso que quitaba la cubierta del software para echar un vistazo entre bastidores y ver cómo funcionaba todo y, lo que es más importante, si podía estropearlo. Durante décadas, los ingenieros de software se han esforzado por mejorar y reforzar continuamente sus productos, y la comunidad de seguridad (aunque a veces sea un poco descarada en su enfoque) desempeña un papel importante en el descubrimiento de errores y posibles catástrofes, con la esperanza de que lo haga antes que un malhechor.

Sin embargo, el problema es que, como reacción a sus descubrimientos, recibió una leve suspensión escolar. Y eso ocurrió solo después de que agotara todas las posibilidades de ponerse en contacto con la empresa (Follett Corporation) de forma privada y finalmente decidiera hacer una denuncia bastante pública para identificarse a sí mismo y su capacidad para burlar su sistema. Sus repetidos intentos de advertir éticamente a Follett Corporation no obtuvieron respuesta, mientras que el software seguía siendo vulnerable y se podía acceder con relativa facilidad a montones de datos de estudiantes, ya que la mayor parte de ellos no estaban encriptados.

También se dedicó a buscar errores en el software de otra empresa: Blackboard. Aunque los datos de Blackboard estaban al menos encriptados, los posibles atacantes podrían haber accedido a ellos y haberse llevado 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 resultados en la edición de este año de AUF JEDEN FALL, donde los detalles más pícaros de sus travesuras cosecharon el aplauso del público. Y con razón, realmente. Aunque al principio estaba en mala posición y tuvo que superar muchos obstáculos para que se reconocieran sus descubrimientos, según los informes, Follett Corporation le agradeció sus esfuerzos y siguió sus consejos para, finalmente, hacer que su software fuera más seguro y evitar la crisis que se habría convertido en otra estadística más de violaciones de la privacidad. Después de terminar el bachillerato, también asistirá al Instituto Tecnológico de Rochester. Así que está claro que va por buen camino para convertirse en un especialista en seguridad muy solicitado.

Como yo mismo soy agente de seguridad, me resulta difícil no tener reservas sobre cómo se gestionó esta situación. Aunque en este caso todo salió bien, al principio se le trató como a un molesto guionista novato que mete las narices donde no le incumbe. Una búsqueda en Google sobre el incidente contiene artículos en los que se le denomina «hacker» (a los ojos de los profanos en materia de seguridad, esto le posiciona en muchos sentidos como un villano), aunque su enfoque (y el de muchos otros) contribuye en realidad a proteger nuestros datos.

Necesitamos personas curiosas, inteligentes y preocupadas por la seguridad que se atrevan a mirar bajo el capó, y necesitamos que eso ocurra mucho más a menudo. En julio, más de cuatro mil millones de registros se vieron expuestos solo este año por violaciones maliciosas de la privacidad. Esa cifra podría aumentar en otros cincuenta millones gracias a la violación de la marca de moda y estilo de vida Poshmark en agosto.

Cometemos los mismos errores y, lo que es aún más preocupante, a menudo se trata de simples fallos de seguridad que nos hacen tropezar una y otra vez.

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

Según informa VERKABELT, Demirkapi descubrió que el software de participación comunitaria Blackboards y el sistema de información para estudiantes Folletts contenían vulnerabilidades de seguridad frecuentes, como Cross-Site Scripting (XSS) e inyección SQL, que son una espina clavada para los especialistas en seguridad desde la década de 1990. Hemos soportado su existencia durante mucho tiempo, realmente mucho tiempo, y al igual que las camisetas Hypercolor y los disquetes, ya deberían ser un recuerdo lejano.

Pero no es así, y está claro que no hay suficientes desarrolladores con la concienciación necesaria en materia de seguridad como para impedir su introducción en su código. Las herramientas de análisis y las revisiones manuales del código tienen un efecto limitado, y hay problemas de seguridad mucho más complejos que el XSS y la inyección SQL, en los que estas costosas y laboriosas medidas 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, rompió dos sistemas muy usados a través de vectores de amenaza que deberían haberse detectado y corregido antes de que se publicara el código.

Gamificación: ¿la clave para el compromiso?

He escrito mucho sobre por qué los desarrolladores siguen distanciándose en gran medida del tema de la seguridad, y la respuesta breve es que no se está haciendo mucho, ni a nivel organizativo ni educativo, para fomentar la concienciación sobre la seguridad entre los desarrolladores. Si las empresas se toman el tiempo necesario para crear una cultura de seguridad que recompense y reconozca el compromiso, incluyendo la implementación de cursos de formación que hablen el idioma de los desarrolladores y los motiven a seguir intentándolo, estas molestas reliquias de las brechas de seguridad desaparecerán gradualmente del software que utilizamos.

Demirkapi tiene un interés evidente por la seguridad fuera del ámbito escolar y se ha tomado el tiempo necesario para aprender a revertir el desarrollo de malware, detectar errores y, bueno, romper cosas que desde fuera parecen irrompibles. Pero en una conversación con LASTER (y en sus diapositivas de DEF CON), hizo una interesante declaración sobre su autoformación... la ha convertido en un juego:

«Con el objetivo de encontrar algo en el software de mi escuela, fue una forma divertida y lúdica de aprender por mí mismo muchas pruebas de penetración. Aunque empecé mi investigación con la intención de aprender más, descubrí que las cosas eran mucho peores de lo que esperaba», dijo.

Aunque no todos los desarrolladores querrán especializarse en seguridad, todos ellos deberían tener la oportunidad de adquirir conocimientos sobre seguridad, ya que los fundamentos sirven prácticamente como «licencia para programar» dentro de una organización, especialmente para aquellos que controlan la gran cantidad de datos confidenciales que manejamos. Si todos los desarrolladores pueden corregir las vulnerabilidades de seguridad más simples antes incluso de que se escriban, estaremos en una posición mucho más segura frente a aquellos que quieren causar estragos.

¿Le interesa el entrenamiento gamificado? Eche un vistazo a nuestra serie Coders Conquer Security. XSS y inyección SQL.