En el mundo de las bases de datos y las aplicaciones web, hackear las PYME se ha convertido en una amenaza creciente, donde la seguridad es una prioridad crítica. Sin embargo, las vulnerabilidades como la inyección SQL continúan siendo un desafío recurrente, exponiendo organizaciones a riesgos significativos.
En este artículo, exploraremos un caso real donde una aplicación web vulnerable permitió la exfiltración de información sensible y la ejecución de comandos arbitrarios, comprometiendo la infraestructura completa de una organización.
A través de este análisis, no solo entenderás cómo se llevó a cabo este ataque, sino también cómo prevenirlo mediante prácticas de seguridad sólidas, como el uso de consultas parametrizadas, ORM, y la correcta configuración de permisos en las bases de datos.
La amenaza de la inyección SQL en las bases de datos
La instancia de SQL Server es una instalación independiente del software de SQL Server que se ejecuta en una computadora física o virtual. Cada instancia de SQL Server se puede utilizar para administrar una o más bases de datos. Como también, permitir una mayor personalización y configuración. Cada instancia puede tener diferentes configuraciones de recursos, permisos de usuario y seguridad, lo que puede ser muy útil en entornos de bases de datos complejos y en la gestión de múltiples aplicaciones y servicios.
El entorno del que se parte es una aplicación web hecha en PHP para el registro de clientes, que utiliza como motor de base de datos el servicio de Microsoft SQL Server. La vulnerabilidad se logra localizar rápidamente ya que, al interceptar la solicitud del registro, se identifica en el parámetro “sql” una sentencia utilizada para extraer información de los locaciones para el registro de los usuarios. Asimismo, es posible interactuar con el servicio, se introduce la consulta “select @@version”, lo que efectivamente provoca al servidor de base de datos SQL Server retornar la versión del servidor, incluyendo: el número de versión y la edición del servidor.
Si bien, lo más común es que el usuario de la aplicación no tenga permisos para ejecutar el procedimiento “xp_cmdshell” (por defecto desactivado), se ha visto en varias ocasiones que, debido a una mala configuración, sí tenga permisos para activarlo. En ese caso, se utilizarían las siguientes consultas:
EXEC sp_configure ‘show advanced options’, 1; RECONFIGURE;
EXEC sp_configure ‘xp_cmdshell’, 1; RECONFIGURE;
Llegados a este punto, se ejecuta la consulta “xp_cmdshell ‘whoami'”, utilizando el procedimiento almacenado “xp_cmdshell” para ejecutar el comando “whoami” en el servidor.
Tras recibir la respuesta de la solicitud enviada
visualizamos que el resultado de la consulta es el nombre del usuario actual en la sesión del sistema operativo, exponiendo en la respuesta al usuario “nt service\\mssqlserver”.
Continuando con la enumeración, se procede a listar los recursos de la ubicación “C:\Users” utilizando la consulta “xp_cmdshell ‘dir C:\users'”. Aunque, debido a los privilegios del usuario mssqlserver, no es posible acceder a ningún recurso del administrador.
En este punto, existe la posibilidad de concretar el compromiso del activo, lo que implicaría profundizar en una enumeración interna para identificar información sensible que nos permita comprometer a un usuario o llevar a cabo la evasión del antivirus en caso de querer escalar privilegios explotando deficiencias a nivel de sistema.
En este caso se utilizó otro vector de ataque aprovechando el servicio de MSSQL.
Procedemos a realizar la siguiente consulta para obtener información de los servidores vinculados en la instancia actual:
select srvname from master..sysservers
La tabla “sysservers” contiene información sobre todos los servidores vinculados en la instancia de SQL Server actual. Por lo que, busca el nombre del servidor (“srvname”) de cada servidor vinculado y lo retorna como resultado.
Como podemos observar, es posible identificar en la respuesta obtenida por el servidor, que existe la instancia 10.114.205.17.
En este caso, para confirmar la interacción con el activo identificado, se utiliza la funcion “openquery()” para realizar una consulta remota a otra instancia de SQL Server. La sintaxis de la función “openquery()” sería la siguiente:
openquery ( linked_server ,’query’ )
En el ejemplo, “linked_server” es el nombre del servidor vinculado que se está utilizando para acceder a la instancia remota de SQL Server y “query” es la consulta que se va a ejecutar en ese servidor remoto.
En nuestro caso, el “linked_server” es la dirección IP “10.114.205.17”. La consulta remota que se ejecuta en ese servidor es “select @@version as version”, que retorna la versión de SQL Server que se está ejecutando en esa instancia remota. Finalmente, se utilizaría la siguiente consulta:
select version from openquery (“10.114.205.17”, ‘select @@version as version’);
Una vez realizada la solicitud, es posible obtener la versión del servidor remoto vinculado a la instancia, que para nuestra sorpresa es un servidor SQL aún más antiguo: Microsoft SQL server 2014.
Llegados a este punto, haremos una pausa y expondremos la situación actual con el siguiente grafico:
Antes de continuar con el proceso, se creó un usuario que nos permitirá conectarnos al primer servidor SQL comprometido utilizando el cliente SQSH y de esta manera ejecutar las consultas de una manera más cómoda hacia la instancia 10.114.205.17.
Una vez autenticados, se procedió a habilitar el procedimiento “xp_cmdshell” en la instancia 10.114.205.17. Para ello se emplea la función “EXEC AT” utilizando las siguientes consultas:
EXEC (‘sp_configure ”show advanced options”, 1; reconfigure;’) AT “10.114.205.17”
EXEC (‘sp_configure ”xp_cmdshell”, 1; reconfigure;’) AT “10.114.205.17”
Nota: Las comillas simples se usan para delimitar una cadena de caracteres. Si una cadena de caracteres contiene comillas simples, debemos duplicarlas para indicar que no se trata del final de la cadena.
Proseguimos ejecutando la siguiente consulta EXEC (‘xp_cmdshell ”whoami” ‘) AT “10.114.205.17”, la cual utiliza el procedimiento almacenado “xp_cmdshell” para obtener la salida del comando “whoami” en el servidor 10.114.205.17. Asimismo, como podemos observar en la respuesta de la consulta, el nombre del usuario con el que estamos ejecutando comandos en el contexto del servidor en la instancia 10.114.205.17, es un usuario de dominio llamado “domain\usrsqlsrv”.
Lo que prosigue, es indagar un poco más en el servidor para enumerar los potenciales vectores de ataque en esta nueva instancia de SQL server con la finalidad de provocar un mayor impacto en la infraestructura. Para ello, podemos comenzar por corroborar qué usuarios pertenecen al grupo de administradores locales en la instancia de SQL Server. El usuario con el que estamos ejecutando comandos en el contexto del servidor, tiene los privilegios de un administrador local.
Hasta este momento, realizando este movimiento lateral sobre las instancias de SQL server, logramos comprometer un nuevo activo con un usuario que posee privilegios de administrador local. Lo que nos permite crear un nuevo usuario para asignarlo al grupo de administradores que vamos a utilizar para autenticarnos con servicio de Remote Desktop Protocol (RDP).
Como se ilustra a continuación, se realiza un volcado de memoria del proceso “lsass.exe”, ya que en Windows el proceso “lsass” (Local Security Authority Subsystem Service) es el responsable de: gestionar la autenticación de usuarios, cambios de contraseñas, creación de tokens de acceso y aplicación de políticas de seguridad. Esto significa que el proceso almacena múltiples formas de contraseñas cifradas y en algunos casos incluso almacena las contraseñas de usuario en texto plano.
imagen-15
Posteriormente, tras volcar la memoria del proceso utilizando PyPyKatz, es posible extraer las credenciales almacenadas en memoria del fichero “lsass.dmp” y obtener las credenciales del administrador de dominio “domain\Administrator”.
Finalmente, empleando secretsdump, es posible volcar los hashes de administradores de dominio y junto con contraseñas en texto plano, comprometiendo todos los usuarios del directorio activo de la organización.
Como resultado, pudimos comprometer el controlador de dominio (DC) y la infraestructura completa de la organización.
¿Cómo prevenir la Inyección SQL?
1. Consultas parametrizadas
Las consultas parametrizadas no concatenan las variables a la consulta SQL, sino que usan una sintaxis específica para pasar un conjunto de parámetros predeterminados a la consulta SQL. Veámoslo en un ejemplo con las siguientes variables:
$nombre = “Jhon”
$clave = “123”
Con la consulta SQL convencional se vería así:
String consulta = “select nombre from Usuarios where nombre =
$nombre and clave = $clave;”
En este caso, las variables se concatenan a la consulta sin ningún tipo de control y un atacante podría inyectar código SQL malicioso con mucha facilidad.
Con la consulta SQL con parámetros, en cambio, se vería así:
String consulta = “select nombre from Usuarios where nombre =? and clave =?”;
sentencia = conexion.prepareStatement(consulta);
sentencia.setString(1, $nombre);
sentencia.setString(2, $clave);¿En este último caso, se construye de otra forma utilizando el carácter de interrogación ?
Luego, con el código sentencia.setString (1, $nombre) se pasan los valores a la consulta.
El parámetro 1 refiere a la posición que tendrá en la consulta, en este caso al nombre. Si el valor fuera 2, se referiría a la clave. El parámetro $nombre refiere a la variable con el dato a pasar.
2. ORM (Object Relational Mapping)
El ORM es un modelo de programación que transforma las tablas de una base de datos en entidades para simplificar en gran medida la tarea del programador y acelerar el desarrollo de aplicaciones. Gracias al mapeo automático se puede cambiar de motor de base de datos fácilmente y cuando sea requerido.
Las acciones Insertar, Leer, Actualizar y Borrar a ejecutar sobre la base de datos se realizan de forma indirecta por medio del ORM.
Los ORM tienen el objetivo de liberarnos de la escritura o generación manual de código SQL necesario para realizar las consultas. Algunos ejemplos de estos son:
- Java
- Hibernate
- iBatis
- Ebean
- .NET
- nHibernate
- Entity Framework
- PHP
- Doctrine
- Propel
Buenas prácticas para proteger tu PYME contra ciberataques
Gestionar de que los enlaces de bases de datos bajo el principio de menor privilegio. Para una mayor seguridad, se recomienda crear cuentas dedicadas exclusivamente para estos enlaces, otorgándoles solo los permisos estrictamente necesarios para acceder a las bases de datos y tablas requeridas.
Desactivar la opción de RPC Out para evitar que los atacantes ejecuten procedimientos almacenados a través de enlaces de bases de datos, lo que podría permitirles realizar acciones no autorizadas.
Restringa el acceso al servidor de base de datos, asegurándose de que solo las cuentas con necesidades legítimas de negocio tengan acceso. Evite otorgar acceso a grandes grupos de usuarios en Active Directory, como BUILTIN\Users, ya que esto podría abrir la puerta a un acceso no autorizado.
Si no está utilizando enlaces de bases de datos, elimínelos para prevenir vectores de ataque en caso de que un usuario logre obtener acceso no autorizado. Esto reduce la superficie de ataque de manera significativa.
Conclusión: proteger tu PYME comienza con la prevención
El lenguaje de consultas SQL es conveniente para administrar las bases de datos relacionales y poder utilizarlas para aplicaciones y plataformas web. Pero lamentablemente estas están desprotegidas debido a las inyecciones SQL, a partir de las cuales se puede extraer información privada, insertar registros, modificar o eliminar datos, autorizar accesos, etc.
Este caso demuestra cómo una vulnerabilidad aparentemente pequeña puede tener un impacto devastador en la seguridad de una organización. La protección contra amenazas como la inyección SQL requiere una combinación de buenas prácticas de desarrollo, auditorías constantes y simulaciones de ataque realistas.
En Hackmetrix, ofrecemos servicios de ethical hacking y pentesting que te permiten identificar y mitigar estas vulnerabilidades antes de que sean explotadas por actores malintencionados. Contáctanos y fortalece la seguridad de tus aplicaciones y datos con expertos en ciberseguridad.
Escrito por: Gustavo Contreras
Pentester en Hackmetrix
Otras vulnerabilidades que te gustaría conocer y prevenir: