La seguridad con ejemplos de la vida real siempre es m谩s interesante.Una vez que un cliente lleg贸 con una solicitud de pruebas de penetraci贸n. Ten铆a bastantes motivos de preocupaci贸n, entre otros, se escuch贸 uno: 鈥淗ace unos meses, un nuevo desarrollador vino a nosotros, obtuvo acceso al c贸digo fuente, documentaci贸n, un servidor de prueba, desapareci贸 dos d铆as despu茅s y a煤n no responde. 驴C贸mo puede amenazarme esto? No se le dio acceso al sistema en vivo ".
No hablaremos de los errores de los desarrolladores, que pueden convertirse en agujeros serios en el sistema en vivo. Todo es mucho m谩s simple: el c贸digo fuente en s铆 puede contener instrucciones y accesos directos.
De los diversos proyectos que probamos para la seguridad, dar茅 ejemplos reales cuando, con solo el c贸digo fuente, podamos penetrar en el sistema mismo. Se han solucionado todas estas 谩reas problem谩ticas y se oculta cualquier informaci贸n adicional en las capturas de pantalla.
Sistema 1.El c贸digo clonado de gita no solo es la 煤ltima versi贸n, sino tambi茅n el historial de todos los cambios. Usualmente ejecutamos el c贸digo fuente de informaci贸n confidencial usando
gittyleaks .
En este proyecto, encontramos una clave de cifrado privada que una vez se elimin贸 del c贸digo, pero a煤n se usaba en el sistema en vivo. Esta clave se utiliz贸 para la autenticaci贸n, y conociendo el mecanismo, podr铆amos generar cualquier cookie de autenticaci贸n para cualquier usuario, incluido el administrador.
Imagen 1. Salida: gittyleaks --find-anything
Sistema 2.Puede usar la
utilidad git y pedirle que muestre todos los archivos eliminados. En este sistema, encontramos un archivo deployer.pem que sol铆a estar en la ra铆z del proyecto y se utiliz贸 para implementar autom谩ticamente el proyecto en los servidores a trav茅s del canal SSH. El puerto SSH en el sistema en vivo se ha abierto. 驴Por qu茅 est谩 abierto? Los desarrolladores respondieron que su m谩quina de compilaci贸n estaba detr谩s de una direcci贸n IP din谩mica, y decidieron no cerrar el puerto: "de todos modos, nadie recoger谩 la clave SSH". Gee-gee ...
Imagen 2. Salida: git log --diff-filter = D --summarySistema 3.Con este sistema, todo fue a煤n m谩s f谩cil. Puede valer la pena entrar en los scripts de la base de datos y ver c贸mo se crean los usuarios de forma predeterminada. Por lo general, el primer usuario en crear un administrador con los permisos m谩s altos. En los scripts, encontramos un c贸digo que generaba un hash a partir de contrase帽as reales y lo escrib铆a en la base de datos. Sorprendentemente, se crearon 5 usuarios, pero la contrase帽a del administrador m谩s importante, para nuestro asombro, pas贸 por el sistema en vivo. Y este c贸digo no es el primer a帽o, por cierto, y ninguna persona ha trabajado con 茅l.
Imagen 3. C贸mo encontrar contrase帽as reales en los scripts de la base de datosLa promesa
1. Si su proyecto est谩 en un gita, 谩bralo y ejecute un par de comandos desde la carpeta ra铆z:
pip install gittyleaks
gittyleaks --encontrar cualquier cosa
git log --diff-filter = D --summary2. Una regla de oro. Un sistema en vivo siempre debe tener claves 煤nicas, contrase帽as de usuario 煤nicas y todo lo que contiene debe estar cerrado al m谩ximo.
La informaci贸n anterior se proporciona solo con fines educativos y educativos, no es necesario c贸mo hacer sus sistemas.
Denis Koloshko