Test de uso de GenAI para la detección Connection String Parameter Pollution (CSPP) usando Ollama
Figura 2: Connection String Attacks en DefCON18
Aunque hay varias formas en las que se puede explotar esta vulnerabilidad, nos centraremos en el escenario de delegación de la autenticación en el motor de BD. Es decir, tenemos una aplicación que recoge las credenciales del usuario y la cadena de conexión a la BD se calcula dinámicamente con estas. Cada usuario puede tener o no permisos de conexión a la BD y permisos de lectura o no a ciertas tablas. En el siguiente código C# de una aplicación ASP.NET se puede ver la idea:
{
string cadenaConexion = $”Server=UK5FCMI;Database=WebApp;User Id={usuario};Password={contraseña};”;
using (SqlConnection con = new SqlConnection(cadenaConexion))
{
using (SqlCommand cmd = new SqlCommand(“SELECT * FROM Products”))
{
using (SqlDataAdapter sda = new SqlDataAdapter())
{
cmd.Connection = con;
sda.SelectCommand = cmd;
using (DataTable dt = new DataTable())
{
sda.Fill(dt);
GridViewProductos.DataSource = dt;
GridViewProductos.DataBind();
}
}
}
}
}
El método construye, mediante interpolación de cadenas, una cadena de conexión a una BD tipo SQL Server a partir de los parámetros de usuario y contraseña. Estos parámetros no se validan en ningún momento (ni en el llamador). Con esta cadena de conexión, se lanza una conexión contra la BD y se lee la información de la tabla Products (si el usuario de BD tiene permisos SELECT sobre dicha tabla) para mostrarla en la grid del formulario ASPX. Todos estos ataques se explican en mucho detalle en el libro “Hacking Web Technologies 2ª Edición” de 0xWord.
Una forma de explotarlo sería, por ejemplo, introducir como contraseña la cadena ;Integrated Security=True;, con cualquier usuario. Si se permite la autenticación integrada en SQL Server y el usuario del pool de IIS con que se está ejecutando la aplicación tiene permisos de conexión y consulta a la BD de la aplicación, podemos conseguir acceder a información que no nos corresponde.
Utilizando el mismo prompt que ya hemos diseñado, vamos a pedir al modelo de Llama 3.1 que evalúe la seguridad del código.
El modelo detecta un problema en la cadena de conexión, identificando que los parámetros de usuario y contraseña, que provienen de los campos de un formulario, no se han validado ni comprobado. Detecta que esto puede presentar un problema de SQL Injection, sin embargo, la propuesta de solución NO es acertada. En la cadena de conexión, elimina los parámetros de usuario y contraseña:
string cadenaConexion = $”Server=UK5FCMI;Database=WebApp;”;
using (SqlConnection con = new SqlConnection(cadenaConexion))
{
…
using (SqlCommand cmd = new SqlCommand(“SELECT * FROM Products WHERE Usuario = @Usuario AND Contraseña = @Contraseña”))
{
cmd.Parameters.AddWithValue(“@Usuario”, usuario);
cmd.Parameters.AddWithValue(“@Contraseña”, contraseña);
…
}
Parece que el modelo está intentando encajar la solución de una SQL Injection clásica a este tipo de vulnerabilidad. Una solución podría ser utilizar la clase SqlConnectionStringBuilder, de la que Chema habla en la segunda parte de su serie en el blog.
Al ser Llama un modelo general, se probó también con un par de modelos especializados en código. Por ejemplo, el modelo Code Llama de Meta (basado en Llama 2), es un modelo especializado en código y está entrenado, entre otros, con lenguajes C#. El análisis de este modelo (en su versión 13B) del código anterior fue muy similar a Llama 3.1, proponiendo como solución la consulta parametrizada que incluye los parámetros de usuario y contraseña en la SELECT de productos.
El modelo CodeGemma 7B también propuso el uso de consultas parametrizadas y además sacar la cadena de conexión a la sección ConnectionStrings del fichero Web.config. Esto tampoco soluciona la vulnerabilidad, aunque se saque la cadena a otro sitio.
Powered by WPeMatico
