El día que encontré dos SQLi y un Bypass Authentication (CVE)

Hola a todos! Bienvenidos a mi primer artículo dentro de este proyecto personal que he decidido llamar Bugs&Coffee. En este blog hablaré sobre distintos tipos de vulnerabilidades, exploits, malwares y demás.

Sin más que agregar, espero que este primer artículo te sea de interés.

Contexto

Hace unas semanas estaba revisando la seguridad de un sitio web en específico, el cual llamaremos gametech.com para evitar exponer información sensitiva del mismo. Lo primero que hice fue listar los subdominios y ASN relacionados con el sitio.

¿Para qué necesito los subdominios y las ASN?

Cuando estás buscando vulnerabilidades dentro de un sitio web necesitas tener a la vista la mayor superficie de ataque que puedas, es decir, entender dónde están sus activos y cuáles son estos activos críticos. Las ASN o Autonomous System Number te pueden ayudar a descubrir cómo está estructurada su infraestructura externa.

Ejemplo:

Arriba te estoy mostrando las ASN’s relacionadas al dominio shein.com.

¿Qué podemos sacar de esta información? Que Shein utiliza AWS para desplegar su infraestructura y quizás tengas la posibilidad de encontrarte alguna API Key o un S3 mal configurado.

Infraestructura

Regresando a gametech.com. Al listar sus ASN y subdominios pude tener una imagen clara de dónde estaban alojados ciertos subdominios. Algunos estaban alojados en dos proveedores de nube diferente, pero la gran mayoría estaba en una IP en específico, dentro de un ASN perteneciente a un proveedor de servicio local.

Olfateando las vulnerabilidades

Después de un rato viendo varios subdominios, uno me llamó la atención.

En este subdominio que llamaremos “charts.gametech.com” mostraban gráficos con distintos tipos de información, y lo primero que se me vino a la mente fue… “jummm ¿Serán estos gráficos estáticos o los estará alimentando alguna base de datos? ¿Y Cómo?”

Comencé a capturar las peticiones mediante Burpsuite y me di cuenta de una petición muy, muy curiosa.

Como se puede ver arriba tenemos información útil donde miremos. Primero parece que estamos tratando contra un servidor Openresty, que no es más ni menos que Nginx, posiblemente un proxy. Pero lo que más llama la atención es aquél parámetro llamado “fields”.

#URL Encoded
fields=ROW_NUMBER()%20OVER%20(order%20by%20rank)AS%20n,country,%20code,%20year,%20type,%20score,%20rank

#URL Decoded
fields=ROW_NUMBER() OVER (order by rank)AS n,country, code, year, type, score, rank

Bueno, bueno, que vemos aquí; parece ser que me encontré con una sentencia SQL … ¿Ya lo vemos venir, cierto?

Para no hacer la historia tan larga, comencé a probar payloads. Primero un simple ” ‘ “ y para mi, no tan, sorpresa recibí un error de la base de datos.

Al final, con la ayuda de varias herramientas de automatización (sqlmap) pude crear el payload perfecto para extraer toda la información que quisiese de esa base de datos.

La imagen de abajo muestra información de una de las tablas de la base de datos, la cual era una Postgresql.

Además, me di cuenta que el usuario con el que estaba extrayendo toda la información era un usuario privilegiado, pudiendo así comprometer la integridad de los datos que expone este sitio web.

Después de haber obtenido esta información traté de replicar esto mismo en otros subdominios similares, y … lo logré. Era el mismo error, la misma vulnerabilidad. Por lo tanto descubrí dos SQL Injection. 🥳🥳🥳

Entrando “como perro por su casa”

Este fue un poco más sencillo ya que se trata de un servicio expuesto, el cuál era vulnerable a CVE-2023–27524: Authentication Bypass in Apache Superset.

¿Qué es Superset?

Es prácticamente una plataforma para crear dashboards y gráficos interactivos.

Con una pequeña búsqueda sobre la versión con la cual me estaba enfrentando pude notar que tenía un CVE relacionado a la misma, y oh vaya que para mi fortuna era uno crítico.

La vulnerabilidad consistía en crear un nuevo token JWT para entrar a la aplicación como un usuario administrador predeterminado. ¿Cómo se puede lograr esto? Debido a que la llave que firma el token JWT por default es “secret” y que haya habilitado un usuario administrador por defecto.

Aprovechándome de esto, forjé un JWT nuevo y !para adentro!

Aquí arriba puedes ver la lista de los usuarios existentes en la plataforma, y de tercero el usuario administrador por default.

Recomendaciones

Estas son algunas de las recomendaciones que debes tener en cuenta para evitar este tipo de vulnerabilidad: SQLi, como también servicios vulnerables.

• Verifica que todas las entradas hacia tu sitio web estén bien “sanitizadas”.
• Si tu sitio web utiliza datos de una base de datos, crea un usuario con privilegios específicos para las acciones necesarias.
• Si puedes, no expongas toda la sentencia de SQL en un solo parámetro.
• Actualiza tus servicios.
• No dejes las configuraciones por defecto, ya que en el caso de la vulnerabilidad de superset se hubiese evitado si en la configuración inicial se hubiese cambiado la llave secreta que utiliza la aplicación para forjar los token JWT.

Si llegaste hasta aquí gracias por leer y espero que te haya gustado.