Ataque de truncamiento SQL

Ataque de truncamiento SQL
La vulnerabilidad de truncamiento SQL ocurre cuando una base de datos trunca la entrada del usuario debido a una restricción en la longitud. Los atacantes pueden recopilar información sobre la duración de un campo crítico (como un nombre de usuario) y explotar esta información para obtener acceso no autorizado. Los atacantes pueden iniciar sesión como otro usuario, como un administrador, con su propia contraseña registrada.

La vulnerabilidad de truncamiento SQL generalmente existe en las 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 SQL

Este ataque funciona debido al truncamiento de la entrada del usuario en bases de datos utilizando las funciones de 'selección' e 'inserción'.

  • Cuando se da la entrada en el campo Formulario, la función 'Seleccionar' verifica 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" a través de la siguiente consulta:

crear usuarios de tabla (
user_id int no null auto_incement,
user_name varchar (20) no nulo,
contraseña varchar (40) no nula,
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 verificaciones de redundancia de la base de datos. El atacante aún puede evitar esa verificación de redundancia para agregar otra cuenta de administrador explotando la vulnerabilidad de truncamiento SQL. Supongamos que el atacante registra otra cuenta con la siguiente entrada:

User_name = 'adminxxxxxxxxxxxxxxxrandom'
(x son los espacios)
Y
Contraseña = "randomuser"

La base de datos tomará el 'user_name' (26 caracteres) y verificará si esto ya existe. Luego, la entrada user_name se truncará, y 'admin' ('admin' con espacio) se ingresará en la base de datos, lo que dará como resultado dos usuarios de administración duplicados.

El atacante puede crear un usuario de 'administrador' con su propia contraseña. Ahora, la base de datos tiene dos entradas de administrador 'user_name', pero con diferentes contraseñas. El atacante puede iniciar sesión con las credenciales recientemente creadas para obtener un panel de administración porque tanto el "administrador" de user_names y el "administrador" son iguales para el nivel de la base de datos. Ahora, veremos un ataque práctico de muestra.

Ataque de muestra

En este ejemplo, tomaremos un escenario del sitio web Overthewire.organizar. La comunidad de Overthewire proporciona CTF de juego de guerra en los que podemos practicar nuestros conceptos de seguridad. El escenario del truncamiento SQL ocurre en el nivel de juego de Natas 26-> 27. Podemos acceder al nivel usando el siguiente:

URL: http: // natas27.natas.laboratorios.Overthewire.organizar
Nombre de usuario: Natas27
Contraseña: 55TBJPPZUUJGVP5B3BNBG6ON9UDPVZCJ

Este nivel está disponible en: https: // overthewire.org/wargames/natas/natas27.html. Se le mostrará una página de inicio de sesión que es vulnerable a un ataque de truncamiento 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' utilizando 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 la longitud de 65 caracteres. Después de la creación de la cuenta de usuario, podrá ver el 'a.'

Si la base de datos contiene vulnerabilidad sql_truncation, entonces la base de datos ahora debe 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 conectados como el usuario 'Natas28'.

Mitigación

Para mitigar este ataque, tendremos que considerar múltiples factores.

  • No debemos permitir la duplicación de identidades críticas como el nombre de usuario. Deberíamos hacer estas identidades claves primarias.
  • La función truncada debe implementarse para todos los campos de los formularios frontend, así como el código de backend, de modo que las bases de datos reciban entradas truncadas.
  • El modo estricto debe habilitarse a nivel de base de datos. Sin habilitado el modo estricto, las bases de datos solo dan advertencias en el backend, pero aún así guarde 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> Crear prueba de base de datos
Consulta bien, 1 fila afectada (0.02 seg)
mysql> usar prueba
Base de datos cambiada
MySQL> Crear usuarios de tabla (UserName varchar (10), contraseña varchar (10));
Consulta bien, 0 filas afectadas (0.05 segundos)

A continuación, crearemos un usuario administrador con credenciales utilizando la consulta de insertos.

mySql> insertar en los valores de los usuarios ('admin', 'contraseña1');
Consulta bien, 1 fila afectada (0.01 seg)

Podemos ver la información de la tabla de 'usuarios' utilizando la opción 'Seleccionar * de los usuarios'.

La longitud del nombre de usuario es de 10 caracteres. Ahora, probaremos el ataque de truncamiento SQL.

Cuando intentamos ingresar lo siguiente:

UserName = 'Adminxxxxxa'
(x son los espacios)
Y
Contraseña = 'pass2'

Recibiremos un error, lo que significa que el modo estricto es totalmente efectivo.

MySQL> Insertar en los valores de los usuarios ('Admin A', 'Pass2')
Error 1406 (22001): datos demasiado largos para el 'nombre de usuario' de la columna en la fila 1

Sin habilitado el modo estricto, la base de datos generará advertencias, pero aún insertará los datos en la tabla.

Conclusión

Los atacantes pueden obtener acceso a cuentas de alto privilegio si existe la vulnerabilidad SQL_TRONCTION 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 alfabeto aleatorio después de la longitud mínima, lo que resulta en la creación de múltiples cuentas de alto privilegio. Esta vulnerabilidad es crítica, pero se puede evitar si toma algunas precauciones de seguridad, como activar el modo estricto para las entradas de los usuarios y hacer del campo confidencial la clave principal en la base de datos.