Presentamos Missions: la siguiente fase de la formación en seguridad centrada en el desarrollador

Desde 2015, hemos involucrado a desarrolladores de todo el mundo con un enfoque proactivo y positivo hacia la seguridad, ayudándoles a adquirir las habilidades necesarias para proteger su código, reducir el trabajo de corrección y, con suerte, lograr que el equipo de seguridad deje de ser visto como el "policía de la diversión".

Seguimos comprometidos a trabajar codo a codo con los desarrolladores mientras protegen su código por toda la galaxia, pero ha llegado el momento de cambiar las cosas y llevar a nuestros desarrolladores, curtidos en mil batallas y conscientes de la seguridad, al siguiente nivel.

Nos complace anunciar el lanzamiento de una nueva funcionalidad en la plataforma Secure Code Warrior: Missions. Esta categoría de desafíos totalmente nueva representa la siguiente fase en la formación en seguridad orientada a desarrolladores, permitiendo a los usuarios pasar de la simple memorización de conceptos de seguridad a su aplicación en un entorno de simulación del mundo real. Este enfoque de microaprendizaje estructurado desarrolla habilidades sólidas de codificación segura que son relevantes para el trabajo y mucho más entretenidas que ver interminables vídeos de formación de fondo durante la jornada laboral.

Nuestra primera misión pública y jugable es una simulación de la brecha de Unicode en GitHub. Puede parecer engañosamente simple, pero es una vulnerabilidad realmente ingeniosa que resulta divertido analizar. El investigador de seguridad 0xsha realizó un estudio de caso exhaustivo sobre cómo este mismo error puede utilizarse para explotar Django mediante transformaciones de mayúsculas y minúsculas, revelando además cómo el comportamiento de la vulnerabilidad puede cambiar entre diferentes lenguajes de programación. Hay mucho más por descubrir sobre este problema de seguridad, y nuestra misión es un excelente punto de partida.

Colisión frontal (mapeo de mayúsculas/minúsculas) de GitHub

En una publicación 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. Explicaron cómo pudieron utilizar una colisión de mapeo de mayúsculas/minúsculas en Unicode para provocar el envío de un correo electrónico de restablecimiento de contraseña a la dirección incorrecta (o, si pensamos como un atacante, a una dirección de correo electrónico elegida por el actor de amenazas).

Aunque una vulnerabilidad de seguridad nunca es una buena noticia, los investigadores de seguridad que actúan con ética (whitehat) ofrecen cierta ayuda —por no 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 resulta interesante aprender sobre una nueva vulnerabilidad y cómo funciona.

Para alcanzar el siguiente nivel de destreza en codificación segura, es sumamente útil no solo encontrar vulnerabilidades comunes (especialmente las nuevas y llamativas; todos sabemos que los actores malintencionados buscarán terreno fértil para extraer datos con estas nuevas técnicas), sino también contar con un entorno seguro y práctico para entender cómo explotarlas.

Así que hagamos precisamente eso. Sigue leyendo para descubrir cómo se puede explotar una colisión de mapeo de mayúsculas/minúsculas en Unicode, cómo se ve en tiempo real y cómo puedes adoptar la mentalidad de un investigador de seguridad para probarlo tú mismo.

¿Listo para enfrentarte a una colisión de mapeo de mayúsculas/minúsculas ahora mismo? Adelante:

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

"Unicode" puede no estar en el vocabulario de la persona promedio, pero es muy probable que la mayoría lo utilice de alguna forma todos los días. Si has usado un navegador web, cualquier software de Microsoft o enviado un emoji, has estado en contacto directo con Unicode. Es un estándar para la codificación y el manejo coherente de texto de la mayoría de los sistemas de escritura del mundo, asegurando que todos puedan expresarse (digitalmente) utilizando un único conjunto de caracteres. Actualmente, existen más de 143.000 caracteres, así que estás cubierto tanto si usas islandés, como la "i" sin punto turca, o cualquier otra cosa.

Debido al enorme volumen de caracteres que tiene Unicode, en muchos casos es necesario convertir caracteres a otro "equivalente". Por ejemplo, parece lógico que si conviertes una cadena Unicode con una "i" sin punto a ASCII, debería convertirse simplemente en una "i", ¿verdad?

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

Una colisión de mapeo de mayúsculas/minúsculas en Unicode es un fallo de lógica de negocio y, en esencia, puede llevar a la toma de control de cuentas que no están protegidas por autenticación de dos factores (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 email = req.body.email;
  db.get(SELECT rowid AS id, email FROM users WHERE email = ?, [email.toUpperCase()],
      (err, user) => {
          if (err) {
              console.error(err.message);
              res.status(400).send();
          } else {
              generateTemporaryPassword((tempPassword) => {
                  accountRepository.resetPassword(user.id, tempPassword, () => {
                      messenger.sendPasswordResetEmail(email, tempPassword);
                      res.status(204).send();
                  });
              });
          }
      });
});

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

1. Acepta la dirección de correo electrónico proporcionada por el usuario y la convierte a mayúsculas para mantener la coherencia.
2. Comprueba si la dirección de correo electrónico ya existe en la base de datos.
3. Si existe, establece una nueva contraseña temporal (por cierto, esto no es una buena práctica; en su lugar, utiliza un enlace con un token que permita restablecer la contraseña).
4. Luego envía un correo electrónico a la dirección obtenida en el paso 1, que contiene la contraseña temporal (esto es una práctica muy deficiente por muchas razones. ¡Qué horror!).

Veamos qué sucede con el ejemplo proporcionado en la publicación original del blog, donde un usuario solicita un restablecimiento de contraseña para el correo John@GıtHub.com (nótese la i turca sin punto):

1. La lógica convierte John@Gıthub.com a JOHN@GITHUB.COM
2. Busca esto 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 la dirección incorrecta. ¡Vaya!

Cómo expulsar a este demonio Unicode

El aspecto interesante de esta vulnerabilidad específica es que existen múltiples 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 a utilizar, es decir, la dirección proporcionada por el usuario en lugar de la que ya existe en la base de datos.

En teoría, puede solucionar este problema específico de dos maneras, tal como se identifica en la publicación del blog de Wisdom:

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

Cuando se trata de fortalecer el software, es una gran idea no dejar nada al azar, empleando tantas capas de defensa como sea posible. Por lo que sabemos, puede haber otras formas de explotar esta codificación; simplemente aún no las conocemos. Todo lo que pueda hacer para reducir el riesgo y cerrar las puertas que puedan quedar abiertas para un atacante es valioso.

¿Listo para probarlo usted mismo?

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

Es hora de llevar sus habilidades de codificación segura y concienciación al siguiente nivel. Experimente esta vulnerabilidad de GitHub en una simulación inmersiva y segura, donde podrá ver el impacto del código defectuoso tanto en el frontend como en el backend. Los atacantes tienen ventaja, así que igualemos el campo de juego y apliquemos habilidades reales con un contraataque de sombrero blanco.