Phenquestions
La vulnerabilidad de truncamiento de SQL generalmente existe en bases de datos MySQL. Esta vulnerabilidad se describió por primera vez en CVE-2008-4106, que estaba relacionada con WordPress CMS.
Cómo funcionan los ataques de truncamiento de SQL
Este ataque funciona debido al truncamiento de la entrada del usuario en las bases de datos utilizando las funciones de 'selección' e 'inserción'.
- Cuando se proporciona una entrada en el campo del formulario, la función 'seleccionar' comprueba la redundancia correspondiente a las entradas en la base de datos.
- Después de verificar la redundancia, la función de 'inserción' verifica la longitud de la entrada, y la entrada del usuario se truncará si la longitud excede.
Supongamos que un desarrollador crea la tabla "usuarios" mediante la siguiente consulta:
crear usuarios de tablauser_id INT NOT NULL AUTO_INCREMENT,
nombre_usuario VARCHAR (20) NOT NULL,
contraseña VARCHAR (40) NOT NULL,
CLAVE PRIMARIA (user_id)
);
Usando este esquema, si el desarrollador crea una cuenta de administrador con lo siguiente:
user_name = 'admin'contraseña = "secret_p4ssw0ord"
Obviamente, estas credenciales no son públicas. Solo hay una cuenta de administrador en la base de datos, y si un atacante intenta registrar otra cuenta con el nombre de usuario 'admin', el atacante fallará debido a las comprobaciones de redundancia de la base de datos. El atacante aún puede omitir esa verificación de redundancia para agregar otra cuenta de administrador explotando la vulnerabilidad de truncamiento de SQL. Supongamos que el atacante registra otra cuenta con la siguiente entrada:
Nombre de usuario = 'adminxxxxxxxxxxxxxxxrandom'(x son los espacios)
Y
Contraseña = "RandomUser"
La base de datos tomará el 'nombre_usuario' (26 caracteres) y verificará si ya existe. Luego, la entrada del nombre de usuario se truncará y 'admin' ('admin' con espacio) se ingresará en la base de datos, lo que dará como resultado dos usuarios administradores duplicados.
El atacante puede crear un usuario 'administrador' con su propia contraseña. Ahora, la base de datos tiene dos entradas de administrador 'nombre_de_usuario', pero con contraseñas diferentes. El atacante puede iniciar sesión con las credenciales recién creadas para obtener un panel de administración porque los nombres de usuario "admin" y "admin" son iguales para el nivel de la base de datos. Ahora, veremos un ejemplo de ataque práctico.
Ataque de muestra
En este ejemplo, tomaremos un escenario del sitio web a través del cable.org. La comunidad de overwire proporciona CTF de juegos de guerra en los que podemos practicar nuestros conceptos de seguridad. El escenario de truncamiento de SQL ocurre en el juego natas Nivel 26-> 27. Podemos acceder al nivel utilizando lo siguiente:
URL: http: // natas27.natas.laboratorios.sobre el alambre.orgNombre de usuario: natas27
Contraseña: 55TBjpPZUUJgVP5b3BnbG6ON9uDPVzCJ
Este nivel está disponible en: https: // por cable.org / wargames / natas / natas27.html. Se le mostrará una página de inicio de sesión que es vulnerable a un ataque de truncamiento de SQL.
Al inspeccionar el código fuente, verá que la longitud del nombre de usuario es 64, como se muestra a continuación.
Ya existe un usuario llamado 'natas28'. Nuestro objetivo es crear otro usuario llamado 'natas28' usando el ataque SQL_truncation. Entonces, ingresaremos natas28, seguido de 57 espacios y un alfabeto aleatorio (en nuestro caso, a), nombre de usuario y cualquier contraseña. La letra 'a' no es visible en la captura de pantalla debido al nombre de usuario de 65 caracteres. Después de la creación de la cuenta de usuario, podrá ver el 'a.'
Si la base de datos contiene la vulnerabilidad sql_truncation, entonces la base de datos ahora debería tener dos nombres de usuario 'natas28'. Un nombre de usuario contendrá nuestra contraseña. Intentemos ingresar las credenciales en la página de inicio de sesión.
Ahora, estamos registrados como el usuario 'natas28'.
Mitigación
Para mitigar este ataque, necesitaremos considerar múltiples factores.
- No debemos permitir la duplicación de identidades críticas como el nombre de usuario. Debemos hacer que estas identidades sean claves primarias.
- La función truncar debe implementarse para todos los campos de los formularios frontend, así como el código backend, para que las bases de datos reciban entradas truncadas.
- El modo estricto debe habilitarse en el nivel de la base de datos. Sin el modo estricto habilitado, las bases de datos solo dan advertencias en el backend, pero aún guardan los datos duplicados. Con el modo estricto, las bases de datos dan errores en caso de duplicación y evitan guardar datos.
Por ejemplo, verifiquemos el modo estricto usando la siguiente consulta:
mysql> seleccione @@ sql_mode
Crearemos una base de datos y los usuarios de la tabla.'
mysql> prueba CREAR BASE DE DATOSConsulta OK, 1 fila afectada (0.02 segundos)
mysql> Prueba de uso
Base de datos cambiada
mysql> CREAR TABLA de usuarios (nombre de usuario VARCHAR (10), contraseña VARCHAR (10));
Consulta OK, 0 filas afectadas (0.05 segundos)
A continuación, crearemos un usuario administrador con credenciales utilizando la consulta INSERT.
mysql> INSERT INTO users VALUES ('admin', 'password1');Consulta OK, 1 fila afectada (0.01 seg)
Podemos ver la información de la tabla de 'usuarios' usando la opción 'seleccionar * de usuarios'.
La longitud del nombre de usuario es de 10 caracteres. Ahora, probaremos el ataque de truncamiento de SQL.
Cuando intentamos ingresar lo siguiente:
Nombre de usuario = 'adminxxxxxa'(x son los espacios)
Y
Contraseña = 'pass2'
Obtendremos un error, lo que significa que el modo estricto es totalmente efectivo.
mysql> INSERT INTO los valores de los usuarios ('admin a', 'pass2')ERROR 1406 (22001): Datos demasiado largos para la columna 'nombre de usuario' en la fila 1
Sin el modo estricto habilitado, la base de datos generará advertencias, pero aún insertará los datos en la tabla.
Conclusión
Los atacantes pueden obtener acceso a cuentas con altos privilegios si existe la vulnerabilidad sql_trunction en su aplicación. El atacante puede obtener fácilmente información sobre un nombre de usuario y la longitud de su base de datos utilizando los campos críticos, luego crear el mismo nombre de usuario, seguido de espacios y un alfabeto aleatorio después de la longitud mínima, lo que da como resultado la creación de varias cuentas con altos privilegios. Esta vulnerabilidad es crítica, pero se puede evitar si toma algunas precauciones de seguridad, como activar el modo estricto para las entradas del usuario y hacer que el campo sensible sea la clave principal en la base de datos.
