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

Desde 2015, hemos estado involucrando a los desarrolladores de todo el mundo con un enfoque proactivo y positivo hacia la seguridad, ayudándoles a construir las habilidades para asegurar su código, reducir el retrabajo y la remediación, y con suerte ver el equipo de seguridad como algo más que la policía de la diversión.

Seguimos comprometidos a estar al lado de los desarrolladores para que aseguren el código en toda la galaxia, pero es hora de cambiar las cosas y llevar a nuestros desarrolladores, curtidos en la batalla y conscientes de la seguridad, al siguiente nivel.

Estamos encantados de anunciar una nueva función en la plataforma Secure Code Warrior : Missions. Esta nueva categoría de retos es la siguiente fase de la formación en seguridad adaptada a los desarrolladores, que hace que los usuarios pasen de recordar los conocimientos de seguridad a aplicarlos en un entorno de simulación del mundo real. Este enfoque de microaprendizaje basado en el andamiaje crea potentes habilidades de codificación segura que son relevantes para el trabajo, y mucho más entretenidas que (verticalmente) ver interminables vídeos de formación en el fondo de un día de trabajo.

Nuestra primera misión jugable y pública es una simulación de la violación de GitHub Unicode. Puede parecer engañosamente simple, pero es una vulnerabilidad realmente inteligente que es divertida de diseccionar. El investigador de seguridad 0xsha hizo un estudio exhaustivo sobre cómo este mismo fallo puede utilizarse para explotar Django mediante transformaciones de casos, al tiempo que revela cómo el comportamiento de la vulnerabilidad puede cambiar entre lenguajes de programación. Hay mucho más que descubrir sobre este problema de seguridad, y nuestra misión es un gran lugar para empezar.

Colisión frontal de GitHub (mapeo de casos)

En una publicación del 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 pudieron utilizar una colisión de mapeo de casos en Unicode para desencadenar el envío de un correo electrónico de restablecimiento de contraseña a una dirección de correo electrónico incorrecta (o, si pensamos como un atacante, a una dirección de correo electrónico elegida por el actor de la amenaza).

Aunque una vulnerabilidad de seguridad nunca es una buena noticia, los investigadores de seguridad que se dedican al sombrero blanco proporcionan algo de piedad -por no mencionar la oportunidad de evitar un desastre- si descubren errores potencialmente explotables en una base de código. Sus blogs e informes a menudo son una gran lectura, y es genial aprender sobre una nueva vulnerabilidad y cómo funciona.

Para pasar al siguiente nivel de destreza en la codificación segura, es inmensamente poderoso no sólo encontrar las vulnerabilidades comunes (especialmente las nuevas y geniales - todos sabemos que los actores de amenazas maliciosas estarán buscando terreno fértil para desenterrar algunos datos con estas nuevas técnicas) sino también tener un entorno seguro y práctico para entender cómo explotarlas.

Así que vamos a hacer precisamente eso. Sigue leyendo para descubrir cómo se puede explotar una colisión de mapeo 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.

¿Preparado para enfrentarte a una colisión de mapas de casos ahora mismo? Acércate:

Unicode: Complejo, infinitamente personalizable y más que emojis

Puede que "Unicode" no esté en el léxico de la persona media, pero es muy probable que la mayoría de la gente lo utilice de alguna forma cada día. Si has utilizado un navegador web, cualquier programa de Microsoft o has enviado un emoji, entonces has estado cerca de Unicode. Se trata de un estándar para la codificación y el manejo coherente del texto de la mayoría de los sistemas de escritura del mundo, que garantiza que todo el mundo pueda expresarse (digitalmente) utilizando un único conjunto de caracteres. En la actualidad, hay más de 143.000 caracteres, así que estás cubierto tanto si utilizas el islandés como el turco sin puntos, o cualquier otro.

Debido al enorme volumen de caracteres que tiene Unicode en su conjunto, en muchos casos se necesita una forma de convertir los caracteres a otro carácter "equivalente". Por ejemplo, parece sensato que si se convierte una cadena Unicode con un punto sin a ASCII, que 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 un fallo de lógica de negocio, y en su esencia, puede llevar a una toma de posesión de cuentas no protegidas por 2FA. Para ilustrar la vulnerabilidad en cuestión, veamos un ejemplo de este fallo 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 es algo así:

1. Acepta la dirección de correo electrónico proporcionada por el usuario, y la pone en mayúsculas por coherencia
2. Comprueba si la dirección de correo electrónico ya existe en la base de datos
3. Si lo hace, entonces establecerá una nueva contraseña temporal (esto no es la mejor práctica, por cierto. En su lugar, utiliza 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, con la contraseña temporal (esto es una práctica muy mala, por muchas razones.)

Veamos qué ocurre con el ejemplo proporcionado en la entrada original del blog, en el que un usuario solicita un restablecimiento de la contraseña para el correo electrónico John@GıtHub.com (nótese la i turca sin puntos):

1. La lógica convierte John@Gıthub.com en JOHN@GITHUB.COM
2. Lo busca en la base de datos y encuentra el 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 sensible a la dirección de correo electrónico equivocada. Uy!

Cómo expulsar a este demonio de Unicode

Lo interesante de esta vulnerabilidad específica es que hay múltiples factores que la hacen vulnerable:

1. El comportamiento real de la fundición de Unicode
2. La lógica que determina la dirección de correo electrónico 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, se puede solucionar este problema específico de dos maneras, como se indica en la entrada del blog de Wisdom:

1. Convertir el correo electrónico a ASCII con la 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 endurecer 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, sólo que aún no las conocemos. Todo lo que pueda hacer para disminuir el riesgo y cerrar las ventanas que puedan quedar abiertas para un atacante es valioso.

¿Listo para probarlo por ti mismo?

La mayoría de los desarrolladores son conscientes de 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, brechas y problemas de ciberseguridad.

Es hora de llevar tus habilidades de codificación segura y de concienciación al siguiente nivel. Experimenta esta vulnerabilidad de GitHub en una simulación inmersiva y segura, en la que podrás ver el impacto de un mal código en contextos tanto de frontend como de backend. Los atacantes tienen ventaja, así que vamos a igualar el campo de juego y aplicar las habilidades reales con un contragolpe de sombrero blanco.