No es ningún secreto que en Secure Code Warrior creemos firmemente en el poder de la gamificación para comprometer a los desarrolladores a codificar de forma segura. Es lo que hacemos, y los resultados han sido sorprendentes hasta ahora. Pero, ¿qué pasa con el uso de un videojuego real para evaluar posibles nuevas contrataciones? ¿Se está yendo demasiado lejos, o podría ser una práctica eficaz?

Eso es lo que hace la startup Scoutible, y tengo que decir que me intriga su enfoque. Scoutible evalúa a los posibles contratados mediante un videojuego -no evaluaciones gamificadas, sino una experiencia real de videojuego- y comprueba cómo se comporta la persona en determinadas situaciones. El juego captura "millones de puntos de datos utilizados para medir los diversos atributos de un candidato" durante sólo 20 minutos de juego, y utiliza esos puntos de datos para calificar cómo lo haría el candidato para el trabajo en cuestión.

Hay mucho que gustar aquí, y mucho de lo que aprender también. El producto es flexible para satisfacer las necesidades de sus clientes, y aborda un problema que muchos responsables de la contratación conocen desde hace tiempo. Los autoinformes assessment, como el de Myers-Briggs, no son fiables. Permiten "jugar" con el sistema, o al menos intentarlo, al no ser del todo honestos. En un juego, tienes un objetivo y debes adaptarte y resolver problemas para cumplirlo. Es bastante sencillo, e ingenioso si funciona como afirma Scoutible. Estoy impaciente por saber más al respecto.

Juego frente a gamificación

El enfoque de Scoutible tiene sentido para su público objetivo y su caso de uso. En un momento del viaje de Secure Code Warrior, consideramos el valor de una plataforma de juegos completa, o de mini juegos incorporados a la formación, pero al final ese ángulo no añadía suficiente valor para nuestros propósitos. Los usuarios finales que reciben nuestra formación en seguridad saben que se supone que están aprendiendo.

Dentro de nuestra plataforma Secure Code Warrior , medimos las habilidades de codificación segura de un desarrollador de software mientras utilizamos elementos basados en el juego para mantenerlos comprometidos. Esto significa tener en cuenta estas preguntas:

• ¿Conocen los puntos débiles más comunes de la seguridad del software?
• ¿Pueden arreglar los errores de seguridad más comunes utilizando funciones de seguridad específicas del marco?
• ¿Confían en sus conocimientos de seguridad del software?
• ¿Cuáles son sus puntos fuertes y sus carencias en materia de código seguro?

Cuidado por diseño

Hay otra razón por la que me identifico mucho con el producto de Scoutible. No sólo es un beneficio para la empresa contratante, sino también para el candidato. No todos los candidatos fuertes que se encuentran son buenos en las entrevistas. Para algunos, simplemente no está en su personalidad. Para otros, es posible que nunca se les haya enseñado el fino arte de las entrevistas, o tal vez son nuevos en la fuerza de trabajo y esta es su primera entrevista.

Aquí es donde veo una similitud con los desarrolladores de software. Lamentablemente, en muchos programas universitarios no se presta atención a la seguridad. A los aspirantes a desarrolladores se les dice "lo aprenderás en el trabajo". Salen de la escuela sabiendo cómo hacer que su código funcione, pero perpetúan sin saberlo todas las mismas vulnerabilidades contra las que hemos estado luchando durante 20 o más años.

Cuando los desarrolladores consiguen ese trabajo y piden aprender sobre seguridad, tienen incluso menos tiempo que cuando estaban en la escuela. Se les paga para que produzcan software funcional y eficaz, y muchos de los cursos de seguridad para desarrolladores courses ... bueno, son aburridos. Seamos sinceros.

¿Qué pasaría si pudiera hacer que sus desarrolladores, nuevos y antiguos, se preocuparan por la seguridad sin pensar realmente en ella? ¿Cómo hacer que la formación sea interesante, atractiva e incluso divertida, sin dejar de ser eficaz?

Ese es nuestro reto, y al igual que el de Scoutible, es muy real. Que el problema sea increíblemente grave no significa que la solución tenga que ser mundana y aburrida. Ya lo hemos intentado. Preferimos inyectar un poco de diversión, emoción, competencia y compromiso en nuestra solución. Hasta ahora, ha funcionado muy, muy bien.

Pensé que si podíamos construir una herramienta que se sintiera como un juego, e incorporar pruebas para los atributos cognitivos y de personalidad apropiados, podríamos abordar muchos de los problemas que había estado estudiando.

https://www.inc.com/kevin-j-ryan/scoutible-video-game-reinventing-the-hiring-process.html

Al desarrollar para móviles, las aplicaciones suelen tener que solicitar algunos permisos al sistema. Pueden necesitar acceso a los contactos del usuario, a la conexión Bluetooth o la capacidad de enviar mensajes SMS. Todos los permisos mencionados anteriormente son permisos de plataforma, definidos por el framework de Android.

Pero hay casos en los que estos no son suficientes y la aplicación necesita definir su propio permiso personalizado. Utilizaré nuestra propia empresa como ejemplo. Secure Code Warrior puede crear una aplicación que guarde algunos datos privados como parte de un perfil, incluyendo el rendimiento del usuario en la plataforma SCW. Y nos gustaría permitir que otra aplicación de formación en seguridad, digamos DevTrainer, utilice estos datos si el usuario le da permiso para hacerlo. Se trata de datos sensibles, el usuario ciertamente no querría que cualquiera los conociera, pero la SCWApp no debería ocultarlos y protegerlos completamente, ya que podrían ser útiles. Por lo tanto, deseamos que el usuario tenga control sobre ella. Aquí es donde entran los permisos personalizados.

La SCWApp crea un permiso personalizado, DevTrainer solicita este permiso y el usuario puede decidir si quiere permitirlo o no. Esta es una práctica común y una buena manera de restringir el acceso a las aplicaciones de la lista blanca.

Lamentablemente, hay algunos comportamientos poco intuitivos en torno a los permisos personalizados que los hacen arriesgados desde el punto de vista de la seguridad. Concretamente, los permisos personalizados pueden ser definidos por cualquier app en cualquier momento, y "el primero gana", y esta estrategia viene con algunas consecuencias.

Para el siguiente escenario, definimos dos perfiles de aplicaciones que hemos introducido anteriormente (todas estas aplicaciones son ficticias a efectos demostrativos):

1. SCWApp: la aplicación que define un permiso personalizado y defiende un componente utilizando este permiso.

2. DevTrainer: esta aplicación define el mismo permiso que SCWApp y declara al usuario que desea tener este permiso.

Este es un escenario común acuñado como el caso de las Peer Apps. Si la aplicación DevTrainer fuera sólo un plugin para la SCWApp no tendría que definir el permiso personalizado. La suposición, en este caso, es que SCWApp se instalaría antes que DevTrainer y no se produciría ningún comportamiento inesperado. Si de alguna manera el usuario instala primero DevTrainer, no se le informa de la solicitud del permiso. Si el usuario instala más tarde SCWApp, no se concede el permiso a DevTrainer de forma retroactiva, por lo que los intentos de la aplicación DevTrainer de utilizar el componente seguro fallarán.

Aquí es donde entra en juego el caso de la aplicación Peers. En algunos casos, no se puede esperar que una aplicación se instale antes que la otra. Digamos que si Facebook y Twitter quieren utilizar los componentes del otro, tienen que definir los permisos personalizados del otro.

Sin embargo, aquí es donde la cosa se complica. Si la aplicación DevTrainer se instala primero, el usuario no es informado de su solicitud de permiso personalizado. En este punto, aunque el usuario no haya sido informado, DevTrainer tiene el permiso personalizado y puede acceder al componente protegido.

La cosa se complica aún más. La aplicación DevTrainer puede cambiar el nivel de protección de los permisos. Android no utiliza el nivel de protección del defensor, sino el nivel de protección que se define primero, lo que significa que la aplicación que se instaló primero puede definirlo. Esto significa que si DevTrainer cambia el nivel de permiso a normal, entonces cualquier aplicación futura que solicite este permiso no tendrá que ser confirmada por el usuario, sino que se le concederá automáticamente el acceso.

Este escenario está inspirado en la explicación de este problema que se encuentra en el github de cwac-security.

La estrategia "el primero gana" tiene algunas consecuencias peligrosas y el desconocimiento de su comportamiento puede llevar al desarrollador a tomar decisiones de seguridad basadas en entradas no fiables y permitir que aplicaciones no deseadas accedan a datos sensibles o servicios protegidos. Para obtener más información sobre cómo evitar las decisiones de seguridad a través de entradas no fiables, visite nuestra plataforma. Este comportamiento se modificó a partir de Android 5.0 (Lollipop). Pero como actualmente, más del 22% de los dispositivos Android siguen ejecutando una versión inferior de Android es importante mitigar los riesgos del comportamiento original en tu aplicación. Comprueba si el permiso ya se ha definido en la primera ejecución de tu app y toma las medidas adecuadas si es el caso para resolver cualquier riesgo de seguridad.

Buena suerte con la codificación y hasta la semana que viene.

Al definir los permisos personalizados, una aplicación puede compartir sus recursos y capacidades con otras aplicaciones.

https://developer.android.com/guide/topics/permissions/defining.html

Un ataque de canal lateral es cuando un hacker puede obtener información de la implementación física de un sistema de software en lugar de una debilidad teórica en el algoritmo o un error en el código del software.

Un ejemplo que me gusta utilizar para dejar esto más claro es una forma de hacer la enumeración de nombres de usuario. Si quieres saber qué es la enumeración de nombres de usuario o por qué es mala, visita nuestra página web para ver un vídeo explicativo o juega a un reto para ver si puedes identificarlo en el código.

Ahora, para entender cómo se puede hacer la enumeración de nombres de usuario a través de un ataque de canal lateral, es necesario tener un poco de conocimiento de cómo se manejan las contraseñas (o al menos deberían manejarse) en las aplicaciones web modernas. Una buena aplicación web no conoce tu contraseña, no guarda o almacena tu contraseña en ningún sitio. Entonces, ¿cómo sabe que lo que has escrito es correcto y que es tu contraseña? Bueno, tu contraseña está cifrada.

Una función hash es una operación matemática que es fácil de realizar en un sentido (aunque algo costosa desde el punto de vista computacional) pero muy difícil de revertir y, en el caso de los buenos algoritmos hash, la salida es única dependiendo de la entrada. Cuando te registras en un sitio web, ese hash se almacena de forma segura, no tu contraseña en sí. Esto significa que cada vez que te registras, la aplicación web realiza el hash de tu entrada y compara el resultado con el hash almacenado. Si quieres saber más sobre el almacenamiento seguro de contraseñas, puedes hacerlo en nuestra plataforma.

El hash de la entrada lleva algún tiempo en un ordenador y los desarrolladores siempre intentan optimizar todo lo que escriben para que los usuarios tengan una experiencia fluida. Una cosa que acelera el programa es omitir el hash cuando no es necesario. Por ejemplo, cuando el nombre de usuario no existe (y por tanto no hay que comprobar la contraseña) pueden responder al usuario inmediatamente. De esta manera, se puede omitir el lento cálculo de la contraseña. Si el nombre de usuario es correcto, se hará un hash de la contraseña introducida y se comparará con el hash almacenado.

Llegados a este punto, ya habrás adivinado dónde pueden ir mal las cosas. Aunque en realidad el hashing tarda sólo unos milisegundos, un hacker puede utilizar este retraso añadido para averiguar si el nombre de usuario que ha introducido es correcto o no, ya que un nombre de usuario incorrecto tendrá una respuesta ligeramente más rápida porque no se ha realizado el hashing. Este tipo de ataque de canal lateral se llama ataque de tiempo y es un buen ejemplo de cómo diferentes requisitos no funcionales pueden contrarrestarse entre sí. A veces el código no puede ser rápido y seguro al mismo tiempo.

Así que aunque las contraseñas se manejen perfectamente, y el mensaje que se muestra sea genérico y no avise de si la contraseña o el nombre de usuario eran incorrectos, el sistema sigue siendo vulnerable. La solución es fácil, siempre hash la contraseña o retrasar el envío de la respuesta el tiempo que tardaría en hash.

La información obtenida puede ser utilizada por un atacante para obtener una lista de usuarios en el sistema. Esta información puede ser utilizada para atacar la aplicación web, por ejemplo, a través de un ataque de fuerza bruta o de nombre de usuario/contraseña por defecto.

https://www.owasp.org/index.php/Testing_for_User_Enumeration_and_Guessable_User_Account_(OWASP-AT-002)

Borrar archivos en un sistema informático es complicado. Todo el mundo, incluso tu madre, ha borrado alguna vez un archivo de más y se ha alegrado de encontrarlo todavía en la papelera y poder recuperarlo.

Los datos en los sistemas informáticos se representan mediante una secuencia de bits. Eso significa que el sistema necesita llevar una contabilidad dentro del sistema de archivos para saber qué bits representan cada archivo. Entre esta información se encuentra el tamaño del archivo, la hora de la última modificación, su propietario, los permisos de acceso, etc. Estos datos de contabilidad se almacenan por separado del contenido del archivo.

Normalmente, cuando se elimina un archivo no ocurre nada con los bits que lo representan, pero los datos de contabilidad se modifican para que el sistema sepa que esta parte del almacenamiento ya no tiene sentido y puede volver a utilizarse. Hasta que se guarde otro archivo en esta ubicación y se sobrescriban los bits de la misma, a menudo se pueden recuperar los datos que se guardaron. Esto no sólo mejora la velocidad de borrado de archivos, sino que a menudo es una función útil para deshacer el borrado.

Sin embargo, este enfoque tiene sus inconvenientes. Cuando una aplicación en un sistema informático maneja información sensible, guardará estos datos en algún lugar del sistema de archivos. En algún momento, cuando la información ya no es necesaria, estos datos pueden ser borrados. Si no se toman precauciones adicionales, estos datos pueden seguir siendo recuperables aunque la intención del desarrollador haya sido la de eliminar todos los datos.

La forma más fácil de borrar completamente esos datos es reescribir el contenido del archivo con datos aleatorios (a veces incluso varias veces). Existen varios métodos de eliminación segura de archivos y varían según los tipos de almacenamiento y los sistemas de archivos, como el método Gutmann. Sin embargo, para el uso diario de las aplicaciones, estos métodos son un poco exagerados y puedes sobrescribir los datos tú mismo.

Sin embargo, ¡tenga cuidado! No utilice todos los ceros u otros datos de baja entropía. Muchos sistemas de archivos pueden optimizar la escritura de tales archivos dispersos y dejar parte del contenido original. Se recomienda generar datos aleatorios seguros para sobrescribir todo el contenido del archivo antes de borrarlo.

La remanencia de datos es la representación física residual de los datos que han sido borrados de alguna manera. Una vez borrados los medios de almacenamiento, puede haber algunas características físicas que permitan reconstruir los datos.

https://fas.org/irp/nsa/rainbow/tg025-2.htm

BSIMM 8 ha salido! Fantástico. El único estudio a gran escala sobre las prácticas de seguridad que aplican las grandes organizaciones para producir software seguro.

El estudio lo llevan a cabo profesionales de la seguridad de las aplicaciones bajo la supervisión de Gary McGraw, asegurándose de que los datos recogidos son coherentes, precisos y dan una idea de lo que hacen 300.000 desarrolladores en su día a día.En mi última presentación, hago referencia a las cifras de la BSIMM donde menciono que, de media, hay 2 profesionales de la seguridad de las aplicaciones por cada 100 desarrolladores.

Sin embargo, este no ha sido el caso desde BSIMM4. El BSIMM8 informa de que esta cifra es aún menor, ahora de 1,6 por cada 100 desarrolladores. Contratar a más profesionales de la seguridad de las aplicaciones simplemente no funcionará, ya que hay escasez de talento. Más que nunca, tenemos que dar a los desarrolladores las herramientas y la formación para escribir código seguro que sea práctico, fácilmente disponible y escalable para las organizaciones.

El informe también muestra que la actividad más común en la práctica de la formación es proporcionar una formación de concienciación a todos los empleados, con un 67%. Empecé a trazar un mapa de lo que hacemos en Secure Code Warrior (SCW) en la práctica de la formación y me di cuenta de que nuestra solución puede marcar las 12 actividades de la práctica de la formación que van desde el nivel 1 (la mayoría de las empresas lo hacen) hasta el nivel 3 (muy pocas empresas lo hacen).

De las 12 prácticas de formación, las más interesantes para la solución Secure Code Warrior son:

• Nivel 1: Impartir formación de sensibilización
• Nivel 1: Impartir formación individual a la carta
• Nivel 2: Mejorar el satélite a través de la formación (métrica SCW)
• Nivel 3: Recompensar la progresión a través del plan de estudios (insignias SCW)
• Nivel 3: Impartir formación a los proveedores o a los trabajadores subcontratados (evaluaciones del SCW)
• Nivel 3: Eventos de seguridad del software externo del host (modo SCW Tournament )
• Nivel 3: Identificar el satélite a través de la formación (métrica SCW)

¿Está seguro de que su solución actual aborda estas prácticas?

¿Por qué un programa de formación en seguridad de aplicaciones para desarrolladores produce mejores resultados que otro?

A lo largo de mis más de 10 años como formador de SANS y los últimos tres años fundando y construyendo Secure Code Warrior (SCW), he visto el valor de invertir tiempo y recursos en hacer que los programas de formación produzcan los mejores resultados.

En nuestro primer año de ventas, nuestra empresa consiguió que más de 10.000 desarrolladores recibieran formación sobre código seguro, y observé una serie de tendencias entre los que tuvieron la implantación más eficaz. Sus resultados son alentadores: gran compromiso, aumento de la concienciación sobre la seguridad y fuerte retorno de la inversión del programa al detectar antes los puntos débiles de seguridad, antes de que salgan caros.

Odio admitirlo, pero también ha habido algunos que han adoptado el enfoque de "poco esfuerzo" y han intentado desplegar un programa enviando un correo electrónico con un enlace a la formación. No es de extrañar que no les vaya tan bien y que tengamos que corregir estos despliegues.

A continuación, comparto lo que creo que son cinco lecciones importantes que mejorarán significativamente los niveles de compromiso, el impacto y el éxito de cualquier programa de formación en seguridad para desarrolladores, incluido el nuestro.

1. Poner algo de diversión en el arranque si quieres que tu programa tenga impacto

Organizar un evento especial el día de la inauguración, o dar a su programa un tema de película/juego/geeky puede marcar una gran diferencia en el nivel de entusiasmo y participación desde el principio. Uno de nuestros grandes clientes ha creado todo un programa de fantasía en torno a una popular serie de televisión, con camisetas, insignias y pegatinas, convirtiendo todo el programa de formación en una experiencia que ningún promotor querría perderse. Otro organizó su evento en torno a la Guerra de las Galaxias, celebrado convenientemente el 4 de mayo. Un poco de diversión ayuda mucho a que los empleados se incorporen, haciendo que las breves sesiones de formación en habilidades de código seguro para desarrolladores se sientan como una pausa en el trabajo, en lugar de otra tarea que hay que hacer. Hito nº 1 conseguido, hemos captado su atención y conocen el programa.

2. Encuentre al campeón de la formación en seguridad para desarrolladores (pista: ¡necesitan habilidades de comunicación más que de seguridad!)

Ser capaz de encontrar a los campeones de seguridad adecuados en cada equipo de scrum es fundamental para el éxito continuo del programa, especialmente en las organizaciones más grandes. Según mi experiencia, no todos los expertos en seguridad o desarrolladores altamente cualificados tienen habilidades de comunicación o humanas muy desarrolladas. Los mejores defensores de la seguridad, los que darán a su programa un impacto positivo continuo, son las personas que se apasionan por la seguridad y que tienen fuertes habilidades de comunicación, influencia y comunicación con las personas. Elige bien y ten en cuenta la personalidad y las habilidades de comunicación.

3. Tener recompensas geniales que reconozcan las habilidades

En general, a todos los frikis de la informática -incluidos los desarrolladores- les gusta que se reconozca su inteligencia y sus habilidades. Cuando se les recompensa con pegatinas de estatus específico, gadgets geek, insignias especiales o camisetas impresas personalizadas que reconocen sus habilidades, las llevarán o mostrarán con orgullo. Si alguien consigue algo importante en el programa de formación, es importante pensar en formas de darle reconocimiento y exposición. Vi una gran iniciativa con un cliente que tomaba regularmente fotos de sus campeones de Secure Code Warrior y las publicaba junto con una foto y un mensaje del CISO de la empresa en el boletín de los empleados.

4. No intente convertir a sus desarrolladores en expertos en seguridad

Si bien usted quiere que sus desarrolladores sean la "primera línea de defensa" de su programa de seguridad, ayudándoles a codificar de forma segura, eso no significa que tengan que ser los expertos en seguridad más profundos de su empresa; o que usted tenga que presentarles continuamente nuevas vulnerabilidades de seguridad y ejemplos de violaciones de datos. Aunque la seguridad es importante, su objetivo principal suele ser crear un gran producto o servicio y seguir el ritmo de la empresa. Si se sobrecarga a alguien con demasiada seguridad, se corre el riesgo de que se desentienda. Lecciones clave aprendidas, necesitan entender la higiene básica de la seguridad y apoyarles con herramientas para codificar de forma segura, pero no necesitan ser el experto en seguridad de la empresa.

5. No midas la formación, mide el impacto

No mida cuántas horas de formación reciben sus desarrolladores o cuántos vídeos ven, mida el número de debilidades que se detectan en el ciclo de vida del desarrollo a través del análisis de código, los bug-bounties o las clásicas pruebas de vulnerabilidad antes de iniciar el programa en cada equipo. Si su programa de formación está funcionando, el número de vulnerabilidades que se identifican disminuirá. Lo segundo que hay que medir es el tiempo que se tarda en solucionar una vulnerabilidad. Si un desarrollador tarda un mes en arreglarla, esto muestra claramente que no entiende cómo hacerlo, pero si puede arreglarla en una hora, sabes que domina las habilidades. Estas son las dos métricas que las empresas inteligentes están empleando para medir el impacto de su formación en codificación segura para desarrolladores.

5 lecciones importantes sobre cómo desplegar una formación eficaz en materia de seguridad para los desarrolladores:

1. Poner algo de diversión en el arranque si quieres que tu programa tenga impacto
2. Encontrar al campeón de la formación en seguridad para desarrolladores (pista: ¡necesitan habilidades de comunicación más que de seguridad!)
3. Tener recompensas geniales que reconozcan las habilidades
4. No intente convertir a sus desarrolladores en expertos en seguridad
5. No midas la formación, mide el impacto

Investigadores de VirginiaTech publicaron un documento tras analizar cientos de mensajes en el foro de desarrolladores más popular (Stack Overflow). Examinaron el tipo de preguntas formuladas en torno a la seguridad, las respuestas más populares dadas por la comunidad y el efecto que tiene en los ingenieros de software de código.

No es una verdadera sorpresa para las personas que han estado en la ciberseguridad durante un tiempo, pero se necesita más conciencia en torno a este problema desde la perspectiva de los desarrolladores:

• Las características de seguridad proporcionadas por los marcos de codificación (por ejemplo, JAVA Spring) son demasiado complicadas y están mal documentadas
• Un número considerable de desarrolladores no parece entender las implicaciones de seguridad de las opciones de codificación, lo que demuestra una falta de formación en ciberseguridad
• Muchas de las sugerencias y "arreglos" en estos foros no son seguros pero estaban recibiendo votos positivos y por lo tanto más altos en las calificaciones

El informe sugiere las siguientes soluciones:

• Recalificación de la mano de obra
• Detección y corrección semiautomática de errores de seguridad

Tenemos que facilitar la seguridad a los desarrolladores e incorporarla desde el principio para mantener la velocidad con la que operan las empresas hoy en día.

"La importancia de este trabajo es que aportamos pruebas empíricas de un número significativo de problemas alarmantes de codificación segura, de los que no se había informado anteriormente", dice el documento. "Estos problemas se deben a una serie de razones, como la necesidad cada vez mayor de aplicaciones de seguridad en las empresas, la falta de formación en materia de seguridad de los trabajadores que desarrollan el software y las bibliotecas de seguridad mal diseñadas".

https://www.theregister.com/2017/09/29/java_security_plagued_stack_overflow/

A principios de este mes, el cazarrecompensas belga Inti De Ceukelaire desveló un creativo hackeo que afecta a cientos de empresas. El truco consiste en explotar una lógica lógica empresarial en los populares helpdesk y issue trackers para obtener acceso a intranets, cuentas de redes sociales o, más a menudo, equipos de Yammer y Slack. Puedes leer los detalles en la entrada del blog de Inti. Me impresionó la creatividad necesaria para idear esta hazaña y sentí curiosidad por el proceso implicado, así que decidí hacerle algunas preguntas a Inti, y comparto sus respuestas con vosotros.

Hola Inti, ¿puedes presentarte brevemente a nuestros lectores?

Soy Inti, cazarrecompensas en Intigriti y Hackerone. Vivo en Aalst (Bélgica) y me paso el día rompiendo cosas.

La semana pasada leí la entrada de tu blog sobre lo que desde entonces has llamado "Truco del billete" y me impresionó tu creatividad para encontrar esta hazaña. Cómo se te ocurrió la idea de probar este truco?

Participo en programas de bug bounty, lo que significa que ciertos sitios web ofrecen dinero a los investigadores de seguridad responsables que descubren vulnerabilidades únicas. Como hay mucha competencia, hay que seguir buscando cosas que otros no hayan encontrado ya. Pensé que Slack era un vector de ataque interesante porque a menudo contiene información sensible y a veces sólo requiere un correo electrónico válido de la empresa. Así que cogí una cerveza, me tumbé en el sofá y empecé a pensar en todos los posibles vectores de ataque. De repente se me ocurrió una idea descabellada, y resultó que funcionó. Por lo general, pruebo todo lo que se me ocurre. Aunque sólo funcione unas pocas veces, da sus frutos. ;-)

Como alguien que suele trabajar en el lado opuesto, tratando de asegurar el código, a menudo me pregunto cómo es una sesión de pentesting. ¿Dónde trabajas? ¿Es algo que también haces en tu tiempo libre desde el sofá? ¿O te sientas en una oficina?

Durante el día trabajo como codificador creativo digital en una emisora de radio llamada Studio Brussel. Se trata de algo de programación y algo de redes sociales, pero no de seguridad. Intento no mezclar mi afición con mi trabajo profesional. Tengo miedo de perder mi creatividad si lo hago. No pirateo tan a menudo: máximo unas horas a la semana. Puede ser en la mesa, en el sofá o en mi cama: lo que sea cómodo en ese momento.

¿Cómo se empieza? ¿Tiene una hoja de trucos? ¿Tienes algunas entradas para probar si hay suficiente validación de entrada o escape de salida?

Soy muy caótico, así que no tengo una lista de comprobación, sólo utilizo mi instinto. La mayor parte de las veces empiezo con algo llamado reconocimiento: hacer una lista de toda la información interesante del objetivo, subdominios, direcciones IP, todo lo que pueda encontrar. Intento ver el panorama general y entender la lógica del negocio antes de empezar a hackear. Si sólo buscas las vulnerabilidades estándar, de libro de texto, te perderás muchos de los fallos más inteligentes y complejos. Cuando se trata de la entrada, intento cubrir el mayor número posible de vulnerabilidades en una carga útil. Siempre que descubro algo interesante, juego con él durante un tiempo y le meto un montón de tonterías, sólo para ver cómo reacciona el sistema. Los mejores bugs suelen encontrarse en las partes más remotas de una aplicación web, así que intento indagar todo lo posible.

¿Qué crees que hace a un buen pentester? ¿Tienes algún truco en la manga que puedas compartir con nosotros?

No soy un pentester, así que no puedo hablar por los pentesters en general, pero creo que la motivación y la persistencia son los activos más importantes. La mayoría de la gente ni siquiera considera buscar vulnerabilidades de seguridad en Google porque tienen los mejores ingenieros del mundo, sin embargo, pagan millones de recompensas por errores cada año. Llevo más de dos años trabajando en un objetivo y ahora estoy empezando a llegar a los bugs realmente interesantes. Lleva un tiempo. El problema con el pentesting normal es que los probadores son recompensados con una cantidad determinada, tanto si encuentran vulnerabilidades críticas como si no. Creo que aún quedan muchos bugs en Facebook, sólo hace falta alguien que esté dispuesto a profundizar lo suficiente.

Cuando se dio cuenta de la magnitud del Ticket Trick, ¿qué fue lo primero que pensó?

Tenía sentimientos encontrados. Me sentí asombrado e inmediatamente pensé en las recompensas por errores que podría cobrar con ello, pero por otro lado me sorprendió que esto fuera posible. Cuando encuentras algo así, de repente posees un montón de información valiosa en la que estarían muy interesadas las partes maliciosas. El proceso de divulgación es duro: hay que informar al mayor número posible de empresas afectadas, pero, por otro lado, hay que asegurarse de que la información no se filtre ni se utilice de forma abusiva.

¿Por qué ha decidido publicar la información antes de cobrar más recompensas?

Hacer lo correcto es más importante que cobrar recompensas. Creo que he tenido mi parte justa y ahora quiero devolverla a la comunidad. Además, he estado informando a las empresas sobre este asunto durante meses, para que cada vez más gente lo supiera. No quería que se filtrara o que alguien con malas intenciones abusara de ello.

¿Qué le parecieron las respuestas de las empresas afectadas?

La mayoría de las respuestas fueron satisfactorias. A algunas empresas no les importó mucho, pero al fin y al cabo, ellas se lo pierden. Ser rechazado como investigador de seguridad es parte del juego. Al menos, no recibí ninguna demanda. Hace 10 años, probablemente habría sido así.

Una última pregunta, en reddit he leído que habéis reclamado 8.000 dólares en recompensas por bugs, ¿tenéis algún plan chulo para gastar este dinero?

En total, obtuve más de 20.000 dólares de este bicho. Más de la mitad se destina a impuestos. El resto lo gasto en cosas normales como viajes, salir a cenar, ... nada descabellado. :-)

Muchas gracias por su tiempo y buena suerte en la caza en el futuro.

El fallo sigue ahí. No es algo que se pueda arreglar de inmediato. En los últimos meses, me he puesto en contacto con docenas de empresas y proveedores afectados como parte de sus programas de recompensas por errores para conseguir que se arregle su configuración.

https://medium.freecodecamp.org/how-i-hacked-hundreds-of-companies-through-their-helpdesk-b7680ddc2d4c

Si observamos cualquier organización, pública o comercial, hay dos cosas que podemos garantizar. En primer lugar, sus productos y servicios son cada vez más digitales, lo que significa que implican a desarrolladores de software que crean líneas de código. En segundo lugar, estos negocios digitales están bajo la presión de competidores tradicionales y no tradicionales, que operan en un mundo más dinámico y global.

En este entorno, los CIO se han convertido en los nuevos innovadores y ocupan posiciones de poder e influencia. Sin embargo, la fuerte presión para acelerar la salida al mercado, mejorar la calidad y aumentar la flexibilidad ha dado lugar a equipos de desarrollo complejos y distribuidos, centrados en el desarrollo rápido de características y funciones sin tener en cuenta las vulnerabilidades que podrían estar creando.

Ahora más que nunca, se necesita una nueva forma de trabajar. Sólo hay que ver el daño nuclear de Equifax tras su reciente brecha, que fue el resultado de una codificación insegura. Los CIOs y CISOs deben pensar cuidadosamente si sus equipos de desarrollo son la primera línea de riesgo, o son los campeones de seguridad de la empresa, la verdadera "primera línea de defensa" de su empresa.

He creado esta lista de comprobación de la codificación segura para ayudar a los CIO y CISO a considerar si han configurado sus equipos de desarrollo para que sean campeones de la codificación segura que puedan ayudarle a innovar con un código más rápido, mejor y más seguro.

1. ¿Reconoce su ejecutivo de nivel superior que la seguridad tradicional de la red no es suficiente?

Proteger la capa de red con las medidas de seguridad tradicionales ya no es suficiente y, de todos modos, rara vez tenía éxito, incluso contra los hackers semiprofesionales. Entre muchos informes coincidentes, el informe de Verizon sobre investigaciones de fugas de datos de 2017 sitúa que el 35% de las fugas de datos actuales están causadas por vulnerabilidades de las aplicaciones web. La seguridad de las aplicaciones web es tan importante como la seguridad de la red.

2. ¿Está pensando en la seguridad desde el principio?

Las herramientas actuales de seguridad de las aplicaciones se centran en ir de derecha a izquierda en el ciclo de vida del desarrollo del software (SDLC). Este enfoque favorece la detección y la reacción, lo que significa que los equipos de seguridad detectan las vulnerabilidades en el código escrito y reaccionan para solucionarlas. Según el Instituto Nacional de Estándares y Tecnología (NIST), es 30 veces más caro detectar y corregir las vulnerabilidades en el código comprometido que prevenirlas al escribir el código en el IDE. Por no hablar de los retrasos en los que se incurre para remediar el problema. Los campeones del código seguro comienzan en el extremo izquierdo del SDLC, centrándose en la formación continua de sus desarrolladores en la codificación segura, para que puedan ser la primera línea de defensa de su organización, evitando las vulnerabilidades en primer lugar.

3. ¿Realmente construye habilidades de seguridad en lugar de sólo alimentar el conocimiento?

La mayoría de las soluciones de formación (en línea y en el aula) se centran en la creación de conocimientos en lugar de en la creación de habilidades. Para que los desarrolladores escriban código seguro, necesitan tener acceso regular a un aprendizaje práctico que les haga participar activamente en el aprendizaje y la creación de sus habilidades de codificación segura. Necesitan aprender sobre las vulnerabilidades identificadas recientemente, en código real y en sus propios lenguajes/marcos. Esta experiencia de aprendizaje debe ayudarles a comprender cómo localizar, identificar y corregir las vulnerabilidades conocidas en el código.

4. ¿Mide sus habilidades de codificación segura con métricas en tiempo real?

Es importante crear pruebas que demuestren al desarrollador y a su organización que las habilidades de codificación segura de un desarrollador están mejorando. No se puede mejorar lo que no se puede medir. Sus evaluaciones deben ayudar a identificar el progreso de sus equipos de desarrollo en tiempo real, así como a comparar sus puntos fuertes y débiles en materia de codificación segura.

5. ¿Está seguro de que sus proveedores subcontratados aplican técnicas de codificación seguras?

Muchas organizaciones deciden contratar trabajos de desarrollo a grandes empresas de desarrollo onshore o offshore. En el mejor de los casos, la única forma de garantizar la seguridad que pide una organización es una declaración en el contrato que exige que el producto final sea "seguro". Pocos verifican realmente las habilidades de estas empresas de desarrollo por adelantado y terminan con un software que no sigue las buenas prácticas de codificación segura. En el peor de los casos, no las conocen y ponen en marcha la aplicación. El escenario más común es que los especialistas dedicados a ello (por los que usted paga) los detecten y usted se enfrente a retrasos en la puesta en marcha y a discusiones contractuales sobre quién tiene que pagar por la corrección de estas debilidades de seguridad. Sea inteligente por adelantado, y evalúe las habilidades de seguridad de la aplicación de los desarrolladores que van a construir su próxima aplicación.

6. ¿Sus desarrolladores conocen los puntos débiles de seguridad más comunes?

El 85,5% de las vulnerabilidades de las aplicaciones web explotadas se atribuyen a sólo 10 vulnerabilidades conocidas " el Top 10 de OWASP. Su formación en seguridad de aplicaciones debe cubrir como mínimo éstas y muchos más tipos de vulnerabilidades. Los retos que sus desarrolladores completan deben ser continuamente revisados y actualizados con nuevos retos para nuevos marcos de codificación o nuevos tipos de vulnerabilidad.

7. ¿Dispone de campeones de seguridad internos?

Todas las organizaciones con muchos desarrolladores deberían invertir en alguien que defienda la seguridad dentro de sus equipos de desarrollo. Su propósito es ser un punto de contacto de apoyo para cualquier persona que tenga preguntas sobre la seguridad, pero también defender las prácticas de codificación y arquitectura seguras dentro de un equipo.

8. ¿Ha invertido en herramientas para que sus desarrolladores faciliten la codificación segura?

En un entorno con muchos cambios en las aplicaciones o en el que se practica un desarrollo ágil, la automatización de partes de la seguridad es esencial para mantener el ritmo y el volumen. Hay herramientas disponibles en cada etapa del ciclo de vida del desarrollo que servirán como asesores, puertas de calidad o herramientas de detección. Hay plugins del IDE que se centran en determinados tipos de errores de seguridad y actúan como correctores ortográficos mientras el desarrollador escribe su código. También hay herramientas que se integran con el proceso de construcción que detectan ciertos tipos de debilidades cuando el código se está enviando a un repositorio de código. También hay herramientas que ejecutan pruebas automatizadas sobre el código, simulando técnicas de hacking una vez que el software está en producción. Todas tienen sus propias ventajas y dificultades, y ninguna puede garantizar al 100% que no haya problemas de seguridad. La regla de oro es que cuanto antes se detecte el punto débil, más rápido y barato será remediarlo con el menor impacto en la empresa.

A medida que los CIOs construyen agresivamente sus capacidades de agilidad empresarial, las habilidades de codificación segura serán un arma de innovación y no tenerlas será un instrumento de destrucción. Piénselo dos veces antes de omitir esta capacidad crítica.

¿Cómo se ha enfrentado su organización a esta lista de control?

A medida que los CIOs construyen agresivamente sus capacidades de agilidad empresarial, las habilidades de codificación segura serán un arma de innovación y no tenerlas será un instrumento de destrucción. Piénselo dos veces antes de omitir esta capacidad crítica.