Skip to main content

Propósito de Año Nuevo: no mostrar mis tokens de seguridad al hackear mi aplicación de demostración en el escenario

Escrito por

12 de enero de 2022

0 minutos de lectura

Tradicionalmente, empezamos el año nuevo con propósitos. Queremos hacer más cosas buenas, como trabajar, y dejar de hacer otras. En cuanto a esto último, mi propósito para 2022 es dejar de exponer accidentalmente información confidencial mientras hackeo mi aplicación durante demostraciones en el escenario o situaciones similares。

Sí, este propósito de Año Nuevo suena muy específico, y tiene detrás una excelente historia de terror sobre seguridad.

Hackeando mi aplicación de demostración en J-Fall 2021

El 4 de noviembre de 2021 se celebró J-Fall, la conferencia de Java más grande de los Países Bajos. Es un evento anual de Netherlands Java User Group (NLJUG) y, como miembro de la junta, me alegró que volviéramos a tener un evento presencial por primera vez desde el inicio de la pandemia. También fui seleccionado para dar una charla en esta conferencia sobre un tema relacionado con la seguridad de Java: problemas de seguridad de deserialización en Java.

Como parte de esta presentación, hackeé mi aplicación mediante una cadena de gadgets de deserialización. Usé la conocida cadena de ataque de la biblioteca Commons Collections 3.1, creada para mostrar cómo hackear mi aplicación mediante la ejecución arbitraria de código (ACE). Preparar todo fue fácil: usé ysoserial para configurar la cadena de gadgets y la aplicación de demostración que estaba a punto de hackear incluía la biblioteca. Hasta ahí, todo bien; pero ahora venía la parte difícil…

Exponer tokens secretos de API en el escenario

La ACE que iba a realizar consistía en ejecutar el comando env en mi máquina y mostrar el resultado en la consola. Para quienes no conocen este comando, muestra las variables de entorno de la máquina host. A menudo uso un usuario específico en mi laptop de demostración cuando hago demostraciones de cómo hackear aplicaciones. A veces uso un contenedor de Docker, pero esta vez no lo hice.

Esta vez, hice el hackeo en mi entorno principal, el que también uso para el desarrollo habitual en mi laptop. Por eso, mis variables de entorno también incluían algunos tokens de API, como mi token de GitHub. Todo esto apareció en la pantalla gigante de la gran sala de cine. ???

Al principio, no me di cuenta y estaba totalmente concentrado en dar mi presentación y hacer las demostraciones en el escenario. Sin embargo, después, uno de los asistentes, Nils Breunese (@breun), se acercó y me dijo: «Oye, espero que sepas apreciar esto como experto en seguridad», y me mostró la siguiente foto en su teléfono.

Captura de pantalla de una página web móvil que destaca el titular «BrianVermeer.nl hackeado en J-Fall», sobre una foto de Brian Vermeer con una laptop.

Al principio, no entendí del todo lo que podía hacer. Sin embargo, me explicó la situación y usó mi token de acceso de GitHub para confirmar código en mi sitio web. Cuando me di cuenta de lo que había pasado, sentí vergüenza y alivio al mismo tiempo. Esto pudo haber sido mucho peor que la simple broma que me hizo. Invalidé de inmediato todos los tokens declarados en mis variables de entorno y corregí mi sitio web. Decidí no revertir el commit de Nils, sino corregirlo en un nuevo commit, así que todavía está visible como recordatorio de mi J-Fail.

Dos hombres posan en el escenario junto a un podio de J-FALL 2021: uno levanta el pulgar y el otro hace un gesto de silencio.

El momento en que Nils me contó lo que había pasado, justo después de terminar mi charla en J-Fall 2021.

No te hackees a ti mismo; hackea solo tu aplicación de demostración

Por suerte, todo terminó siendo una buena historia que puedo contarles a otras personas. Quiero agradecerle a Nils por ser una buena persona y tener sentido del humor. Para mí, esto es un recordatorio de que debo practicar lo que predico. Es increíblemente doloroso hablar de seguridad en el escenario y hackear aplicaciones, y que te vulneren en el proceso. Por eso, quiero concluir que debemos tener cuidado con lo que hacemos y con lo que los demás pueden ver. Aunque las herramientas para proteger tu aplicación, como las que ofrece Snyk, son útiles, no te protegen de los errores tontos. Hasta los profesionales de seguridad cometemos este tipo de errores. Solo procura estar consciente de esto y revisar lo que aparece en pantalla antes de publicar tu aplicación en producción o hacer una demostración en el escenario.

Así que mi propósito de Año Nuevo para 2022 es: ¡no exponer información confidencial mientras hackeo mis aplicaciones durante demostraciones o presentaciones! Agradezco mucho que Nils haya sido tan amable de recordármelo. ¡Feliz 2022 a todos!

Leer más

Blog

Los modelos de frontera encontraron las vulnerabilidades. Solo el atacante encontró las cadenas.

El análisis estático encontró las fallas, pero solo las pruebas de ataque en vivo demostraron cómo podían encadenarse para provocar brechas. Una comparación de Evo COS, Claude Security y Claude Code Security.

feature insights context
Blog

Los ataques autónomos ya están aquí. La defensa debe estar a su altura.

Los atacantes autónomos están reduciendo el tiempo disponible para defenderse. Descubre cómo el descubrimiento, la corrección, la validación y la prevención continuos pueden ayudar a los equipos de seguridad a seguirles el ritmo.

Blog

Por qué los agentes de programación con IA siguen generando fallas de control de acceso

Los agentes de programación con IA pueden generar lógica de autorización que compila y supera la revisión, pero expone los datos de un inquilino a otro. Descubre por qué es difícil detectar el control de acceso roto y cómo prevenirlo.