Inyecciones en inyecciones SQL

[MichBukana]

La entrada que traigo hoy, trata de como llevar un paso más haya las Union Based SQL Injection, por ejemplo si en algún caso nos vemos frente a una inyección SQL de este tipo, que no contiene datos aprovechables, como pueden ser subir una webshell u obtener las credenciales para acceder al login del gestor de la web que se esté auditando, etc. Se ha de tener en cuenta que un ataque como el Union Based SQL Injection se puede aprovechar de otras formas, y una de estas formas es la que hoy expondré.

Se trata ni más ni menos que aprovechar los campos imprimibles de la consulta SQL que por debajo está realizando la página web al cambiar los parámetros que se envían por la url. Aprovechándonos de dicha forma lograr inyectar además de la inyección SQL, código javascript, HTML o por qué no realizar un SSI, de este modo podríamos desde ejecutar comandos en una Shell devuelta por el sistema que se muestra en la página (SSI), incluir un iframe para cargar un exploit (HTMLi), leer las cookies, suplantar un formulario como vimos en uno de los anteriores post de este blog http://code-disaster.blogspot.com.es/2013/08/ataques-xss-avanzados-aplicaciones-webs.html; o cualquier otro que se nos ocurra, y es que de esta forma se lograría explotar otro tipo ataque que tal vez por estar bien protegida la web no se podría dar y con ello otra forma de ownear la web.

A continuación se puede ver un ejemplo de una inyección XSS sobre una inyección SQL ya que no se logró explotar de otra forma un XSS en lo demás de la web, siendo irrelevantes los datos obtenidos en la base de datos.

Imagen 1: XSS con SQLi en Google Chrome.

Otro punto a favor de realizar una inyección XSS de esta manera, es que se consigue Bypassear tanto los filtros Anti-XSS de navegadores como Google Chrome (Versión 29.0.1547.76 m) como los de IExplorer (10.0.9200.16660).

Imagen 2: XSS con SQLi en IExplorer.

Para realizar este ataque se debe primero preparar la inyección SQL de modo que quede así.
http://www.localhost.com/test.php?Op=2-1+union+select+1,2,3,4,5,6

Imagen 3: Búsqueda del campo imprimible.

Como se puede apreciar el campo imprimible es el que cae en el 5, entonces será cuestión de sustituirlo en este caso por la inyección XSS cifrada en Hexadecimal con cualquier conversor de Ascii a Hex.

Ascii: <script>alert("code-disaster.blogspot.com")</script>
Hex: 3c7363726970743e616c6572742822636f64652d64697361737465722e626c6f6773706f742e636f6d22293c2f7363726970743e

y por ultimo concatenar a la inyección SQL junto con dos paréntesis de apertura al principio, más 0x (que sirve para identificar el cifrado en el gestor de base de datos y que luego va a servir para devolverla impresa en la web en texto plano), más la cadena en Hex y dos cierre de paréntesis al final.

((0x3c7363726970743e616c6572742822636f64652d64697361737465722e626c6f6773706f742e636f6d22293c2f7363726970743e))

Quedando así.
http://www.local.com/test.php?Op=2-1+union+select+1,2,3,4,((0x3c7363726970743e616c6572742822636f64652d64697361737465722e626c6f6773706f742e636f6d22293c2f7363726970743e)),6


Fuente: http://code-disaster.blogspot.com/

[Stakewinner00]

Pues mi anti-XSS de firefox si que detecta el
((0x3c7363726970743e616c6572742822636f64652d64697361737465722e626c6f6773706f742e636f6d22293c2f7363726970743e))