Presentamos Missions: la siguiente fase de la formación en seguridad centrada en los desarrolladores

Desde 2015, hemos estado involucrando a desarrolladores de todo el mundo con un enfoque proactivo y positivo de la seguridad, ayudándoles a desarrollar las habilidades necesarias para proteger su código, reducir las modificaciones y, con suerte, ver al equipo de seguridad como algo más que una policía divertida.

Seguimos comprometidos a trabajar codo a codo con los desarrolladores para proteger el código de toda la galaxia, pero es hora de cambiar las cosas y llevar a nuestros desarrolladores empedernidos y preocupados por la seguridad al siguiente nivel.

Nos complace anunciar el lanzamiento de una nueva función en la plataforma Secure Code Warrior: Missions. Esta nueva categoría de desafíos es la siguiente fase de la formación en seguridad para desarrolladores, ya que permite a los usuarios dejar de recordar los conocimientos de seguridad para aplicarlos en un entorno de simulación real. Este enfoque de microaprendizaje escalonado desarrolla habilidades de programación potentes y seguras que son relevantes para el trabajo y son mucho más entretenidas que ver (verticalmente) un sinfín de vídeos de formación al fondo de una jornada laboral.

Nuestra primera misión pública y jugable es una simulación de la violación de Unicode en GitHub. Puede parecer engañosamente simple, pero es una vulnerabilidad muy inteligente que es divertido analizar. El investigador de seguridad 0xsha hizo un estudio de caso completo sobre cómo se puede usar este mismo error para explotar Django mediante transformaciones de casos, al tiempo que revela cómo el comportamiento de la vulnerabilidad puede cambiar entre los lenguajes de programación. Hay mucho más por descubrir sobre este problema de seguridad, y nuestra misión es un buen punto de partida.

La colisión frontal de GitHub (mapeo de casos)

En un entrada de blog del 28 de noviembre de 2019, el grupo de investigación de seguridad Wisdom informó sobre un error de seguridad que descubrieron en GitHub. Describieron cómo podían utilizar una colisión de casos en Unicode para provocar que un correo electrónico para restablecer la contraseña se enviara a una dirección de correo electrónico equivocada (o, si pensábamos como la de un atacante, a una dirección de correo electrónico elegida por el autor de la amenaza).

Si bien una vulnerabilidad de seguridad nunca es una buena noticia, los investigadores de seguridad que usan un sombrero blanco sí brindan cierta clemencia (sin mencionar la oportunidad de evitar un desastre) si descubren errores potencialmente explotables en una base de código. Sus blogs e informes suelen ser una lectura excelente, y es genial aprender sobre una nueva vulnerabilidad y su funcionamiento.

Para pasar al siguiente nivel de destreza en la codificación segura, resulta inmensamente poderoso no solo encontrar las vulnerabilidades comunes (especialmente las nuevas e interesantes; todos sabemos que los actores de amenazas malintencionadas buscarán un terreno fértil para desenterrar algunos datos con estas nuevas técnicas), sino también disponer de un entorno seguro y práctico en el que entender cómo explotarlas.

Así que, hagamos precisamente eso. Sigue leyendo para descubrir cómo se puede aprovechar una colisión cartográfica de casos en Unicode, cómo se ve en tiempo real y cómo puedes adoptar la mentalidad de un investigador de seguridad y probarlo por ti mismo.

¿Estás listo para enfrentarte a Case Mapping Collision ahora mismo? Da un paso adelante:

Unicode: complejo, infinitamente personalizable y más que solo emojis

Es posible que «Unicode» no esté en el léxico de la persona promedio, pero es muy probable que la mayoría de las personas lo usen de alguna forma todos los días. Si has utilizado un navegador web, algún software de Microsoft o has enviado un emoji, significa que has estado familiarizado con Unicode de cerca. Es un estándar para la codificación y el manejo consistentes del texto de la mayoría de los sistemas de escritura del mundo, lo que garantiza que todos puedan expresarse (digitalmente) utilizando un único conjunto de caracteres. Tal como están las cosas, hay más de 143 000 caracteres, por lo que no importa si utilizas el islandés, el turco sin puntos o cualquier otro método intermedio.

Debido al gran volumen de caracteres que Unicode tiene en su conjunto, en muchos casos se necesita una forma de convertir los caracteres en otro carácter «equivalente». Por ejemplo, parece sensato que si conviertes una cadena Unicode sin puntos a ASCII, simplemente se convierta en una «i», ¿verdad?

Un gran volumen de codificación de caracteres conlleva un gran potencial de desastre.

Una colisión de mapeo de casos en Unicode es una lógica empresarial un defecto y, en esencia, puede llevar a la apropiación de cuentas que no estén protegidas por la 2FA. Para ilustrar la vulnerabilidad en cuestión, veamos un ejemplo de este error en un fragmento de código real:

app.post (/api/ResetPassword, function (req, res) {
var correo electrónico = req.body.email;
db.get (SELECCIONE ID de fila como identificador, correo electrónico DE los usuarios DONDE correo electrónico =? , [email.toUppercase ()],
(err, usuario) => {
si (err) {
console.error (err.message);
res.status (400) .send ();
} otra cosa {
Generar contraseña temporal (tempPassword) => {
AccountRepository.resetPassword (user.id, tempPassword, () => {
Messenger.SendPasswordResetEmail (correo electrónico, contraseña temporal);
res.status (204) .send ();
});
});
}
});
});

La lógica es más o menos así:

1. Acepta la dirección de correo electrónico proporcionada por el usuario y la pone en mayúscula para mantener la coherencia
2. Comprueba si la dirección de correo electrónico ya existe en la base de datos
3. Si lo hace, establecerá una nueva contraseña temporal (por cierto, esta no es la mejor práctica). En su lugar, usa un enlace con un token que permita restablecer la contraseña)
4. A continuación, envía un correo electrónico a la dirección obtenida en el paso 1, que contiene la contraseña temporal (esta es una práctica muy mala, por muchas razones). ¡Ay!)

Veamos qué ocurre con el ejemplo que se muestra en el publicación de blog original, donde un usuario solicita el restablecimiento de la contraseña del correo electrónico John@GıtHub.com (observe la i sin puntos en turco):

1. La lógica convierte John@Gıthub.com en JOHN@GITHUB.COM
2. Lo busca en la base de datos y encuentra al usuario JOHN@GITHUB.COM
3. Genera una nueva contraseña y la envía a John@Gıthub.com

Tenga en cuenta que este proceso termina enviando el correo electrónico altamente confidencial a una dirección de correo electrónico incorrecta. ¡Uy!

Cómo expulsar a este demonio de Unicode

El aspecto interesante de esta vulnerabilidad específica es que hay varios factores que la hacen vulnerable:

1. El comportamiento real de conversión de Unicode
2. La lógica que determina la dirección de correo electrónico que se va a utilizar, es decir, la dirección de correo electrónico proporcionada por el usuario, en lugar de la que ya existe en la base de datos.

En teoría, puedes solucionar este problema específico de dos maneras, como se identifica en la entrada del blog de Wisdom:

1. Convierte el correo electrónico a ASCII con Conversión de Punycode
2. Utilice la dirección de correo electrónico de la base de datos, en lugar de la proporcionada por el usuario

Cuando se trata de reforzar el software, es una buena idea no dejar nada al azar y emplear tantos niveles de defensa como sea posible. Por lo que sabemos, es posible que haya otras formas de aprovechar esta codificación, pero aún no las conocemos. Todo lo que puedas hacer para reducir el riesgo y cerrar las ventanas que podrían quedar abiertas para un atacante es valioso.

¿Estás listo para probar esto por ti mismo?

La mayoría de los desarrolladores saben que los datos comprometidos son perjudiciales para las empresas. Sin embargo, los ingenieros conscientes de la seguridad son un poderoso antídoto contra las crecientes vulnerabilidades, infracciones y problemas de ciberseguridad.

Es hora de llevar tus habilidades de codificación segura y concientización al siguiente nivel. Experimenta esta vulnerabilidad de GitHub en una simulación segura e inmersiva, en la que podrás ver el impacto del código incorrecto tanto en el contexto del frontend como del backend. Los atacantes tienen una ventaja, así que igualemos el terreno de juego y apliquemos las habilidades reales con un contragolpe de sombrero blanco.