- Ustedes son geniales! ¡Así que nadie nos ha decepcionado todavía!
- Lo intentamos.Sí, la vida de los cazadores de vulnerabilidades está llena de cumplidos específicos de clientes y situaciones no menos específicas. Durante el año pasado, hemos completado más de cincuenta pruebas de penetración en diferentes compañías y, hay que decirlo, lo hemos visto todo. Una contraseña para todas las cuentas y sistemas, almacenamiento abierto de contraseñas en la base de datos, los restos de la funcionalidad de depuración en un entorno de combate ... Por lo tanto, cuando nuestros colegas de JSOC CERT
contaron varias historias sobre investigaciones de incidentes cibernéticos, en el departamento de Pentest decidimos mantenernos al día y mostrar el otro lado de la "barricada" »: La infraestructura del cliente a través de los ojos de un hacker. Hoy le contaremos sobre los pentests externos más interesantes de los últimos tiempos, cuando tuvimos que penetrar en el perímetro interno del cliente, teniendo solo una lista de sus direcciones IP externas y nombres de dominio.
Odyn
Lunes:
- Chicos, comiencen más rápido con un pentest: solo tienen 3 semanas para hackearnos. Pero tenga en cuenta que sus posibilidades son mínimas: nos revisan todos los años y no encuentran pistas.
Después de 4 horas:
"Ya estamos adentro".
- vamos? ¡No puede ser así! Ahora revisemos los registros ...
Viernes:
- Maldición, de verdad. ¿Cómo es eso? Pero como el tiempo no funcionó, ¿quizás buscarás otra cosa?
- Si, no hay duda.
Y comenzamos a buscar. Al escanear el perímetro de la organización, nos encontramos con un host en el que giraban 4 aplicaciones web, un servidor FTP y el panel de administración phpMyAdmin se colgó. El análisis de las aplicaciones web no reveló vulnerabilidades críticas allí (por ejemplo, inyecciones SQL, XXE, RCE, etc.) que nos permitirían acceder al servidor. En algún momento cambiaron a FTP, y aquí ya era más interesante: se abrió el acceso anónimo en el servidor, pero solo para leer.
Durante varios días, examinamos el contenido del servidor y encontramos algunas líneas extrañas en los registros, algunas contraseñas ingresadas incorrectamente para uno de los administradores de la aplicación web.
Con base en las opciones incorrectas, supusimos cómo debería ser la contraseña, y surgió. Decidimos probarlo para phpMyAdmin y, oh, un milagro, también surgió. Luego, era un asunto pequeño: cargar el shell, obtener acceso a la red interna, establecerse allí y desarrollarse ya dentro.
Así es como la pereza ordinaria (¿y de qué otra manera explicar la renuencia a ingresar contraseñas diferentes para cada panel de administración?) Allana el camino para los piratas informáticos a la red interna de la organización.
¿Por qué depurar en un entorno de combate?
La mayoría de nuestros avances se producen a través de aplicaciones web y, a menudo, nos encontramos con curiosos "restos" de tiempos de desarrollo y pruebas. A menudo encontramos registros, algunas piezas de modos de depuración, pero no siempre con su ayuda logramos llevar a cabo RCE (ejecución remota de código).
Durante uno de nuestros clientes, descubrimos un sistema CRM, en el que decidimos dedicar un poco más de tiempo (y, debo decir, que luego valió la pena). Al realizar el análisis de la aplicación, encontramos los restos de las pruebas, que, aparentemente, se utilizaron en la etapa de desarrollo. La autenticación se produjo en ellos de una manera muy milagrosa: solo se verificó el nombre de usuario y el hecho de pasar un parámetro que contenía alguna contraseña. Cinco minutos de búsqueda y lectura de documentación estándar, y tenemos en nuestras manos el nombre de la cuenta de superusuario incorporada. Llenar el caparazón ya era una cuestión de tecnología.
Otro ejemplo. Al comienzo del proyecto, lanzamos una fuerza bruta recursiva de subdominios y la dejamos. Después de algún tiempo, para nuestra sorpresa, apareció un subdominio de quinto nivel llamado test.debug.application.client.ru, en el que encontramos una aplicación web con Adminer instalado allí. Esta es una aplicación de administración de base de datos liviana, en versiones anteriores de las cuales, si está configurada incorrectamente, puede interactuar con una base de datos SQLite sin una contraseña.
El hecho de que no hubiera datos en esta base de datos no era importante: después de todo, en SQLite puede crear una base de datos en una ruta arbitraria con un simple shell web dentro, obteniendo así la capacidad de administrar convenientemente el servidor y ejecutar comandos desde una página web.
Todo lo que quedaba era averiguar la dirección completa de la aplicación web en el servidor. Aquí fuimos ayudados por todos los "amados" CMS 1C-Bitrix, que, en un mensaje de error, compartieron con gusto dónde está ubicado. Entonces solo quedaba llenar el caparazón y terminar el proyecto.
El trabajo con SQLite DB se puede ver
aquí .
¿Registros encontrados? Contraseñas como regalo!
Un cliente nos pidió que realicemos una pentest de una aplicación web. Durante los tres años anteriores, realizó pentests con otro equipo y probablemente logró parchear algunos de los agujeros en el perímetro, por lo que no esperábamos un éxito rápido.
Durante el borrado de la aplicación web, encontramos una página en la que se registraba la autorización del usuario. El tiempo y el inicio de sesión del usuario que inició sesión en la aplicación se mostró en el registro. Escribimos un script que una vez que un par de minutos sondeó esta página, analizó la respuesta y anotó los inicios de sesión encontrados en un archivo. Después de unos días, logramos recolectar alrededor de cien inicios de sesión. Decidimos comenzar la selección de contraseñas: para 5 inicios de sesión se encontraron en la lista de
las peores contraseñas TOP-500 .
Una vez que obtuvimos acceso a la aplicación, continuamos analizándola y encontramos otro archivo interesante: en él se mostraban todas las consultas de la base de datos en tiempo real. Con una herramienta de depuración tan conveniente, la búsqueda de vulnerabilidades y la explotación de la
inyección SQL basada en el tiempo booleano encontrada se
ha convertido en una tarea trivial.
A pesar de que ya es 2019, la gente todavía cree que almacenar contraseñas en una base de datos en forma abierta es una buena idea. Usamos esto y encontramos la inyección SQL y obtenemos una cuenta de administrador con la que completar el shell web y abrir el acceso a la red interna de la organización no fue un gran problema.
Marcas de corte
En primer lugar, realice pruebas de penetración periódicas: lo ayudarán a encontrar puntos delgados que podría haberse perdido en la etapa de desarrollo o al cambiar de entornos de prueba a combates.
En segundo lugar, considere siempre el factor humano: las personas son demasiado flojas para cambiar las contraseñas, e incluso pueden usar una contraseña en varios sitios. Sí, los administradores también pecan esto.
Tercero, elimine los modos de depuración en entornos de combate.
PS
En general, la vida cotidiana del departamento de Pentest está llena de todo tipo de "entretenimientos" y, por supuesto, las pruebas externas no son las únicas. El cliente puede desear verificar las vulnerabilidades del perímetro interno (pentest interno), o analizar la seguridad de las aplicaciones web y móviles, así como las redes WiFi, o hacer arreglos para que los empleados verifiquen utilizando métodos de ingeniería social.
En nuestro tiempo libre de proyectos,
comprendemos Zen, buscamos nuevas vulnerabilidades, mejoramos nuestras herramientas y técnicas. Y estamos comprometidos en un bugbounty (donde sin él).
Aprenderá sobre la diversidad de nuestras "aventuras" en las siguientes publicaciones.