Si las organizaciones quieren tomarse en serio la seguridad del software, deben capacitar a sus ingenieros para que desempeñen un papel defensivo contra los ataques cibernéticos mientras elaboran su código.
El problema es que los desarrolladores no han tenido la introducción más inspiradora a la capacitación en seguridad a lo largo de los años, y cualquier cosa que se pueda hacer para que su experiencia sea más atractiva, productiva y divertida será un poderoso motivador para ayudarlos a obtener información valiosa y segura. habilidades de codificación.
Y después de dedicar un tiempo precioso a dominar nuevas habilidades que pueden ayudar a vencer a los atacantes en su propio juego, la oportunidad de probar estos nuevos poderes no se encuentra fácilmente en un entorno seguro.
Entonces, ¿qué debe hacer un ingeniero experimentado en seguridad y consciente de la seguridad?
Una nueva característica lanzada en la plataforma Secure Code Warrior, llamada ‘Misiones‘es una categoría de desafío que eleva a los usuarios desde la recuperación del conocimiento de seguridad aprendido hasta su aplicación en un entorno de simulación del mundo real.
Este enfoque de microaprendizaje basado en andamios desarrolla habilidades de codificación sólidas y seguras que son relevantes para el trabajo y mucho más entretenidas que ver (verticalmente) videos interminables de capacitación en el fondo de una jornada laboral.
La primera ‘Misión’ disponible es una simulación de la violación de GitHub Unicode. No es tan simple como podría parecer en la superficie, y es una vulnerabilidad realmente inteligente que es divertido analizar. El investigador de seguridad 0xsha realizó un estudio de caso integral sobre cómo este mismo error se puede usar para explotar Django mediante transformaciones de casos y, al mismo tiempo, mostró 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 este es un excelente lugar para comenzar.
Resumen
Colisión frontal (asignación de casos) 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. Describieron cómo pudieron utilizar una colisión de mapeo de casos en Unicode para activar una entrega de correo electrónico de restablecimiento de contraseña a la dirección de correo electrónico incorrecta (o si estaba pensando como un atacante, una dirección de correo electrónico elegida por el actor de amenazas).
Si bien una vulnerabilidad de seguridad nunca es una buena noticia, los investigadores de seguridad que tienen un sombrero blanco brindan algo de misericordia, sin 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 excelente lectura, y es genial aprender sobre una nueva vulnerabilidad y cómo funciona.
Para pasar al siguiente nivel de destreza de codificación segura, es muy poderoso no solo encontrar vulnerabilidades comunes, sino también tener un entorno seguro y práctico para comprender cómo explotarlas también.
Siga 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 puede asumir la mentalidad de un investigador de seguridad y probarlo usted mismo.
Unicode: más que simples emojis
«Unicode» puede no estar en el radar de la persona promedio, pero es muy probable que la mayoría de la gente lo use de alguna forma todos los días. Si usó un navegador web, cualquier software de Microsoft o envió un emoji, entonces ha estado en contacto directo con Unicode.
Es un estándar para la codificación y el manejo consistentes de texto de la mayoría de los sistemas de escritura del mundo, lo que garantiza que todos puedan expresarse (digitalmente) usando un solo conjunto de caracteres.
Tal como está, hay más de 143,000 caracteres, por lo que está cubierto ya sea que esté usando el islandés þ, o el turco sin punto ı, o cualquier otro.
Debido al gran volumen de caracteres que Unicode tiene en su conjunto, en muchos casos se necesita una forma de convertir caracteres en otro carácter «equivalente». Por ejemplo, parece sensato que si convierte una cadena Unicode con una «i» sin punto a ASCII, simplemente debería convertirse en una «i», ¿verdad?
Con un gran volumen de caracteres, la codificación viene muy bien responsabilidad potencial de desastre.
Una colisión de mapeo de casos en Unicode es una falla de lógica de negocios y puede conducir a una toma de control de cuentas que no están protegidas por 2FA. Vea un ejemplo de este error en un fragmento de código real:
La lógica es algo como esto:
- Acepta la dirección de correo electrónico proporcionada por el usuario y la escribe en mayúsculas para mantener la coherencia.
- Comprueba si la dirección de correo electrónico ya existe en la base de datos.
- Si lo hace, establecerá una nueva contraseña temporal (por cierto, esta no es la mejor práctica. En su lugar, use un enlace con un token que permita restablecer la contraseña)
- Luego 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).
Veamos qué sucede con el ejemplo provisto en la publicación de blog original, donde un usuario solicita un restablecimiento de contraseña para el correo electrónico John@GıtHub.com (observe la i turca sin punto):
- La lógica convierte a John@Gıthub.com en JOHN@GITHUB.COM
- Lo busca en la base de datos y encuentra al usuario JOHN@GITHUB.COM
- 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 de correo electrónico incorrecta. ¡UPS!
Cómo expulsar a este demonio Unicode
Lo interesante de esta vulnerabilidad específica es que existen múltiples factores que la hacen vulnerable:
- El comportamiento real de conversión de Unicode,
- 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, puede solucionar este problema específico de dos maneras, como se identifica en la publicación del blog de Wisdom:
- Convierta el correo electrónico a ASCII con conversión Punycode,
- 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 fortalecer el software, es una gran idea no dejar nada al azar, empleando tantas capas de defensa como sea posible. Por lo que sabe, puede haber otras formas de explotar esta codificación, pero aún no las conoce. Cualquier cosa que pueda hacer para reducir el riesgo y cerrar las ventanas que puedan quedar abiertas para un atacante es valiosa.
¿Listo para pilotar tu propia misión?
Es hora de llevar sus habilidades de conocimiento y codificación segura al siguiente nivel. Experimente esta vulnerabilidad de GitHub en una simulación inmersiva y segura, donde puede ver el impacto del código incorrecto tanto en el contexto del front-end como en el back-end. Los atacantes tienen una ventaja, así que igualemos el campo de juego y apliquemos habilidades reales con un contragolpe de sombrero blanco.
