Kali Linux > Web Aplications > Database Exploitation

Kali Linux >  Web Aplications  > Database Exploitation

sqlninja

Explotacion de vulnerabilidades de inyección SQL para Microsoft SQL Server
El objetivo principal de sqlninja es conseguir acceso interactivo a nivel de sistema operativo en el servidor remoto DB y para utilizarlo como un punto de apoyo en la red de destino. Como una característica experimental, también puedes explotar las vulnerabilidades de inyección SQL en aplicaciones web que utilizan Microsoft SQL Server como back-end. En pocas palabras, esto es lo que hace:

Huella digital de control remoto de SQL Server (versión usuario que realiza las consultas, los privilegios del usuario, xp_cmdshell disponibilidad, el modo de autenticación del servidor DB)
• Bruteforce de la contraseña 'sa' (sólo SQL Server 2000)
• Escalada de privilegios a 'sa' (sólo SQL Server 2000)
• Creación de un xp_cmdshell personalizado si el original se ha desactivado
• Subir de ejecutables
• Exploración en sentido inverso con el fin de buscar un puerto que se puede utilizar para una cáscara inversa
• Shell directa e inversa, TCP y UDP
• DNS túnel pseudoshell, cuando no hay puertos disponibles para una BindShell
• ICMP túnel shell, si el DBMS de destino puede comunicarse a través de eco ICMP con la máquina atacante
• Metasploit envoltura, cuando se quiere utilizar Meterpreter o incluso desea obtener acceso GUI en el servidor remoto DB
• Escalada de privilegios del sistema operativo en el servidor DB remoto mediante secuestro ficha o mediante CVE-2010-0232
• Extracción de datos de la base de datos remota, utilizando inferencia WAITFOR basado en túneles o basadas en DNS
• Todo lo anterior se puede hacer con ofuscado el código SQL, con el fin de confundir a los sistemas IDS / IPS

Cómo usarlo

El comportamiento de sqlninja se controla a través del archivo de configuración (por defecto: sqlninja.conf ), que narra sqlninja qué atacar y cómo (host de destino, la página vulnerable, explotar cadenas, ...), y algunas opciones de línea de comandos, que cuentan sqlninja qué acción para llevar a cabo. Estas opciones de línea de comandos son los siguientes:

-M <attack <modo: especifica el modo de ataque. Básicamente, dice sqlninja qué hacer. Los valores posibles son: ◦ prueba
◦ huella dactilar
◦ fuerza bruta
◦ escalada
◦ resurrectxp
◦ subir
◦ dirshell
◦ backscan
◦ revshell
◦ dnstunnel
◦ icmpshell
◦ Metasploit
◦ sqlcmd
◦ leedato

-V: resultado detallado

-F <archive>: especifica un archivo de configuración para su uso.

-P <contraseña 'sa'>: se utiliza en el modo de escalado para añadir DB usuario actual al grupo sysadmin, y en otros modos de ejecutar la consulta como administrador, si el usuario DB no pertenece a dicho grupo. Esta opción se utiliza muy poco, ya que el modo de fuerza bruta por defecto añade el usuario DB al grupo sysadmin cuando se encuentra la contraseña 'sa'. Para obtener más información acerca de cuándo utilizar este parámetro, consulte el modo de escalada

-W <wordlist>: lista de palabras a utilizar en el modo de fuerza bruta

-G: combinado con el modo de carga, generar script de depuración y de salida

-D <debug <modo: activa la depuración, para ver lo que está pasando bajo el capó. Los valores posibles son:

◦ 1: imprime cada comando SQL que se inyecta
◦ 2: imprimir cada petición HTTP que se envía a la diana
◦ 3: imprimir cada respuesta HTTP que se recibe desde el objetivo
◦ todo: todo lo anterior

Modos de ataque

Sqlninja tiene actualmente 14 modos de ataque. El modo de utilizar se puede especificar por su nombre:

sqlninja -m upload

por su acceso directo:

sqlninja -mu

La lista con los modos disponibles y sus correspondientes accesos directos se puede recuperar mediante el lanzamiento de sqlninja sin parámetros.

Para obtener una primera comprensión de los diferentes modos de ataque, esto es una forma típica de usar sqlninja:

1. Configure el archivo de configuración y utilice el modo de prueba para comprobar que el código SQL se inyecta correctamente

2. Huella digital del servidor DB remoto, utilizando el modo de huella digital

3. Si es necesario, utilice el modo de fuerza bruta para encontrar la contraseña 'sa' y escalar privilegios (sólo SQL Server 2000)

4. Si es necesario, utilice el modo resurrectxp para volver a crear el procedimiento extendido xp_cmdshell (sólo SQL Server 2000)

5. Subir netcat, utilizando el modo de carga

6. Si es posible contactar con el servidor de base de datos en algún puerto, utilice el modo dirshell y obtener una shell directa. Alternativamente, si el puerto es TCP, utilice el modo de Metasploit para obtener acceso gráfico

7. De lo contrario, utilice el modo backscan permitido encontrar una "salida" del puerto TCP / UDP

8. Si el paso 7 tiene éxito, utilice el modo revshell para obtener una shell inversa. Alternativamente, si el puerto es TCP, utilice el modo de Metasploit para obtener acceso gráfico

9. Si el paso 8 no, subir icmpsh.exe y tratar de modo icmpshell para obtener una shell icmp tunelizado

10. Si el paso 9 no, subir dnstun.exe y empezar el modo dnstunnel para obtener un seudo-shell dns-túnel

11. Si el paso 10 no, poner encima leedato modo y empezar a extraer algunas mesas!

Prueba
Atajo: t
Parámetros: ninguno

Este modo simplemente inyecta una simple WAITFOR DELAY y comprueba si se ejecuta con éxito por el servidor remoto. Utilice este modo para comprobar si el archivo de configuración es correcta y la inyección está funcionando.

Huellas dactilares

Atajo: f
Parámetros:-p <sa contraseña> (opcional)

Con la inyección ciega WAITFOR basado, este modo las huellas dactilares con el servidor remoto. Los siguientes tipos de información se pueden obtener: • Versión de base de datos (2000/2005/2008/2012)

• Usuario que está realizando las consultas
• Ya sea que el usuario pertenece al grupo sysadmin
• Si xp_cmdshell está disponible para ese usuario
• Si el servidor remoto utiliza la autenticación mixta o sólo para Windows (lo que necesita saber esto si quieres fuerza bruta la contraseña 'sa')
• Si el control remoto de SQL Server se ejecuta como SYSTEM. Esto también se puede utilizar para comprobar si churrasco.exe se ha subido correctamente y es capaz de escalar privilegios mediante el secuestro token.
• Nombre de la base de datos actual

Si usted está atacando SQL Server 2000, el usuario actual DB no pertenece al grupo sysadmin, pero la contraseña correcta 'sa' se especifica como un parámetro, la huella digital se realiza con derechos administrativos. La técnica WAITFOR es mucho más lento en comparación con otros métodos de inferencia, pero es, con mucho, el más flexible. Sin embargo, ya que los factores externos como el tráfico de red y la carga del servidor podrían interferir con las mediciones de tiempo, es posible que desee repetir la huella digital de un par de veces, si el primer resultado no se ve bien, o jugar con el blindtime parámetro en el archivo de configuración . Tenga en cuenta que para poder utilizar la huella digital del usuario que ejecuta SQL Server lo siguiente debe estar disponible en el cuadro de mando a distancia:

xp_cmdshell (o un procedimiento equivalente)
whoami.exe . Esto está presente de forma predeterminada en Windows 2003, pero si usted sospecha que esta utilidad no está en el cuadro de mando a distancia, sólo tiene que descargar de microsoft.com y subir con él.

Fuerza bruta

Atajo: b
Parámetros:-w <wordlist> (opcional)

Este modo se debe utilizar si el usuario que realiza las consultas no pertenece al grupo sysadmin (ver modo de huella digital ). Si este es el caso, tenemos que intensificar nuestros privilegios. Dado que mediante el uso de OPENROWSET podemos hacer la base de datos objetivo conectar a sí mismo con credenciales alternativas, se puede tratar de fuerza bruta la contraseña 'sa'. Si no se encuentra la clave correcta, el usuario actual se añade automáticamente al grupo sysadmin. Para este ataque funcione, el servidor SQL Server remoto debe utilizar "autenticación mixta". Utilice el modo de huella digital para comprobar si este es el caso.

Este modo de ataque puede utilizar dos métodos diferentes: "diccionario" y "incremental". Usted es libre de utilizar el método que mejor se adapte a tus necesidades.

Diccionario

Este método se utiliza cuando no se especifica una lista de palabras, utilizando el -w opción. Con este método, las contraseñas posibles se obtienen de la lista de palabras, y cada uno es probado en una solicitud por separado. Asegúrese de que su lista de palabras contiene 'sa' y la contraseña en blanco, dos todo-tiempos favoritos para instalaciones de MS SQL Server.

Pros:

Muy eficaz si la contraseña es una palabra del diccionario
No pone una pesada carga en el servidor de base de datos

Contras:

No es efectivo contra las contraseñas que no sean diccionario base. Si la clave no está en tu lista de palabras, usted está fuera del juego
Necesita un montón de conexiones de red, por lo que el ataque es muy fácil de detectar mirando los logs del servidor web

Incremental

Este método se utiliza cuando no se especifica una lista de palabras. Sqlninja presenta un conjunto de preguntas que tratan de * todas * las combinaciones posibles de caracteres hasta una cierta longitud especificada por el usuario. El aspecto fresco de esta táctica es que, dado que las consultas se ejecutan en el servidor de base de datos, la fuerza bruta es efectuado utilizando recursos de la CPU del objetivo.

Pros:

Extremadamente eficaz en la búsqueda de contraseñas que no son diccionario basado
Necesita relativamente pocas conexiones, por lo que hay muy pocas entradas en los registros del servidor web

Contras:

Si la contraseña es larga, puede ser que tome las edades
Se podría empujar el uso de la CPU del servidor de DB hasta el 100% durante todo el tiempo, que puede ser peligroso con una aplicación en vivo. También tenga en cuenta que los servidores críticos tienen alarmas que se activan si el uso de la CPU sigue siendo muy elevada durante un tiempo determinado. Como medida de seguridad, sqlninja divide la tarea en pequeños trozos (cada trozo tratando n ^ 3 contraseñas, siendo n la longitud del mapa de caracteres utilizado). Si algo sale mal, simplemente parar sqlninja y la fuerza bruta a distancia se detendrá al final del fragmento actual
Dependiendo de la aplicación se conecta al servidor de base de datos, esta técnica no podría funcionar (por ejemplo: ODBC es conocido por crear problemas). Sqlninja intenta averiguarlo casi inmediatamente y avisa al usuario, por lo que no se pierde un tiempo precioso

Notas importantes

A partir de SQL Server 2005, OPENROWSET está desactivado por defecto para los usuarios que no son administradores. Si el modo de huella digital le dijo que se trata de SQL Server 2005/2008/2012 y que no está 'sa', entonces es probable que no están de suerte (pero todavía se puede extraer datos con el leedato modo
En SQL Server 2000, las contraseñas son sensibles a mayúsculas, lo que simplifica enormemente la tarea de craqueo.
El bit de escalada podría verse afectado si la aplicación utiliza ODBC (ver modo de escalada )

Escalada

Acceso directo: e
Parámetros:-p <sa contraseña> (requerido)

Cuando se especifica la contraseña correcta 'sa', se añade el usuario actual DB al grupo sysadmin.

En general, no es necesario este método, ya sqlninja se encarga de la escalada en el modo de fuerza bruta ya. Sin embargo, puede haber casos en los que usted necesita para llevar a cabo este bit independiente (tal vez usted encontró la contraseña con un ataque de ingeniería social).

Si quieres saber cómo funciona la escalada, o si ha encontrado la contraseña 'sa', pero la escalada parece no funcionar, siga leyendo. De lo contrario, usted puede saltar al modo resurrectxp .

La escalada se realiza combinando OPENROWSET, el derecho contraseña 'sa', y sp_addsrvrolemember, añadiendo el usuario actual DB al grupo sysadmin. Es muy poco probable que sp_addsrvrolemember se ha deshabilitado, por lo que el truco debería funcionar casi siempre. Si esto no funciona, puede haber 2 casos:

1. El servidor utiliza ODBC, y se está utilizando conexiones ODBC antiguos de la agrupación de conexiones, que siguen utilizando los viejos privilegios

2. El procedimiento sp_addsrvrolemember se ha desactivado

En el primer caso, sólo puede tener un par de pintas de espera para la antigua conexión ODBC a tiempo de espera y se redujo: de forma predeterminada, una conexión ODBC se cae después de 60 segundos de inactividad, y la posibilidad de un evento depende del número de clientes se conecta a la aplicación web y cómo este número varía con el tiempo.

En el segundo caso (o también en el primero, si usted no quiere esperar), sólo tiene que especificar el -p <sa password> parámetros en todas las etapas siguientes del atentado: que le dirá sqlninja utilizar OPENROWSET en cada conexión, se ejecuta cada comando como 'sa' y no como el usuario actual.

resurrectxp

Atajo: x
Parámetros:-p <sa contraseña> (opcional)

Este modo se utiliza cuando las condiciones siguientes son met:

-Contamos con privilegios de sysadmin o sabemos la contraseña 'sa'
-xp_cmdshell se ha desactivado

El objetivo de este modo es, por supuesto, para volver a crear el procedimiento extendido xp_cmdshell. Hay un montón de variables que entran en juego aquí y en función de ellos este modo se comportará de manera diferente.
Así que lea cuidadosamente, ya que aquí están las cosas que usted debe tener en cuenta:

Los métodos: Hay dos maneras de obtener el xp_cmdshell vuelta:

1.restaurarlo con un procedimiento almacenado (sp_addextendedproc en 2000 y SQL Server sp_configure en SQL Server 2005). Este método requiere un simple comando SQL, pero requiere xplog70.dll que todavía estará allí

2. crear uno personalizado con "CREATE PROCEDURE", sp_oacreate, sp_OAMethod y sp_OADestroy. Este método requiere más código, pero funciona sin importar si xplog70.dll ha sido retirado por razones de seguridad.

El nombre xp_cmdshell: xp_cmdshell re-habilitación no puede pasar desapercibido. O tal vez los desarrolladores de aplicaciones podrían haber seguido estrictamente lo recomienda MS, que es filtrar la "xp_ *" string, sin decir nada sobre "sp_ *" (consulte http://msdn.microsoft.com/library/en-us/ bldgapps/ba_highprog_11kk.asp ). En estos casos, podemos usar CREATE PROCEDURE y un nombre más discreto (por ejemplo: "sp_sqlbackup"). Usted puede elegir el nombre del procedimiento con la opción xp_name del archivo de configuración.

Los privilegios de los usuarios: si la escalada de privilegios no funcionaba (ver modo de escalada por las razones posibles), entonces usted debe utilizar el -p <sa password> parámetro, con el fin de utilizar OPENROWSET para escalar privilegios en cada conexión, y esto lleva con el siguiente punto

OPENROWSET y CREATE PROCEDURE no se pueden combinar. Por lo tanto, si usted está utilizando el -p parámetro no se puede utilizar la sentencia "CREATE PROCEDURE" truco. Sin embargo, hay una solución: se puede incluir todo el código de procedimiento en cada solicitud que se envía al servidor de base de datos, sin necesidad de crear un procedimiento extendido en absoluto. Digamos que este truco "procedimiento de inyección en línea".

Dicho esto, aquí están los pasos que sigue sqlninja cuando se utiliza este método:

1.Si el nombre del procedimiento prolongado, se especifica en el archivo de configuración, es xp_cmdshell (que es el valor predeterminado) y, a continuación sqlninja comienza por tratar de volver a habilitar con sp_addextendedproc / sp_configure. Se le pedirá la versión del servidor SQL Server remoto. Si se olvida de utilizar el modo de huella digital, sqlninja encontrará esta información por su cuenta. Si todo esto funciona, tenemos nuestra xp_cmdshell espalda.

2.Si el nombre del procedimiento extendido no está configurado para xp_cmdshell (tal vez porque quiere ser más astuto) en el archivo de configuración, o el paso # 1 ha fallado (por ejemplo: debido xplog70.dll se ha eliminado), entonces:

>>si tenemos privilegios de administrador nativas (lo que significa que no tenemos que especificar la contraseña en la línea de comandos) el método CREATE PROCEDURE se intenta. Si funciona, tenemos nuestro procedimiento personalizado, lo que hemos nombrado
>>si no tenemos privilegios de administrador nativas (lo que significa que tuvimos que especificar la contraseña en la línea de comandos), el procedimiento de inyección en línea es tratado. Si funciona, entonces usted tendrá que establecer xp_name a NULL en el archivo de configuración. Esto le dirá sqlninja utilizar el procedimiento de inyección en línea en todas las etapas siguientes

Espero que sea claro. Si es así, usted no debe tener ningún problema en tener de vuelta a su xp_cmdshell (o algo perfectamente equivalente) en casi todas las situaciones. Si no está claro, me temo que tendrá que leer todo de nuevo.

Subir

Acceso directo: u
Parámetros:-p <sa contraseña> (opcional)
Parameterd:-g (opcional)

Con este modo se carga un archivo binario utilizando únicamente peticiones GET o POST HTTP al servidor web, por lo que no se necesita FTP / TFTP o cualquier otro tipo de conexión. Se carga el archivo en el directorio especificado por el servidor de %TEMP% variables, por lo que el ataque funciona incluso cuando MSSQL no puede escribir en el directorio por defecto (que parece ser a veces con MSDE). Hay dos métodos disponibles de subida, controlados por el upload_method opción:

script de depuración: Este método es el tradicional, y utiliza el viejo DEBUG.EXE depurador de 16 bits. El archivo binario se codifica como una secuencia de comandos de depuración ( .scr extensión), se carga el guión y se alimenta al depurador. La secuencia de comandos básicamente asigna un área de memoria, escribe los bytes necesarios en ella, y guarda el resultado en el disco. Ser un depurador 16bits obviamente hay una limitación 64k bytes en el tamaño, pero sqlninja pasa por dividir el ejecutable original en trozos de 64 kbytes, subir por separado, y luego finalmente la fusión entre sí. Sqlninja utiliza el mismo algoritmo utilizado en gran dbgtool.exe de Jussi (que se puede encontrar en la dirección http://www.toolcrypt.org) que es capaz de crear secuencias de comandos muy compactos.

VBScript: Este es el nuevo método: básicamente, se codifica el archivo binario en formato base64, lo sube, y luego se alimenta a un pequeño decodificador VBScript subido anteriormente. Por término medio se utiliza menos peticiones, no necesita dividir el archivo original, y tiene más posibilidades de trabajar en los sistemas más recientes. Por lo tanto, aunque el viejo método es mucho más fresco con el truco de depuración y todo, probablemente debería simplemente utiliza éste.

No importa qué método que seleccione para la carga, se le pedirá el nombre del archivo a subir y las cosas van a ser totalmente automatizado. Si el archivo parece estar ya en .scr o .base64 formato sqlninja realizará la carga de todos modos, pero algunas comprobaciones (por ejemplo: el archivo binario cargado tiene el tamaño correcto) no será posible. En general, siempre es mejor proporcionar sqlninja con el binario original.

Para su comodidad, netcat.exe, dnstun.exe, icmpsh.exe, churrasco.exe, vdmallowed.exe y vdmexploit.dll ya están disponibles en las apps y scripts directorios, respectivamente, en binario y debug + formato base64. Los ejecutables se han embalado con UPX con el fin de reducir al mínimo su tamaño (y el tiempo de carga). Debe cargar netcat utilizar backscan / dirshell / revshell, mientras dnstun.exe y icmpsh.exe se utilizan para crear un túnel pseudoshell DNS e ICMP respectivamente. Churrasco.exe se utiliza para tratar una escalada de privilegios a través de secuestro de testigo si SQL Server no se está ejecutando como SYSTEM. Vdmallowed.exe y vdmexploit.dll tratan el mismo ataque con CVE-2.010 hasta 0.232.

Tenga en cuenta que muchas cosas pueden salir mal aquí: si una sola línea del archivo codificado no puede obtener cargado, no se generará correctamente el ejecutable. Por lo tanto, al final del proceso de sqlninja comprueba si el archivo ejecutable está ahí, y si no es que también trata de averiguar cuántas líneas han sido subidos: esto debería proporcionar algunas pistas sobre lo que salió mal. Por ejemplo, durante una pluma-prueba resultó que el número resultante de líneas era exactamente el doble del valor correcto, lo que significa que cada consulta inyectada fue ejecutado dos veces. El truco consistía en crear una tabla temporal que actúa como un contador, añadiendo la línea en el fichero de script sólo cuando el contador fue aún.

Si sólo desea generar el script de depuración o el archivo de base64 sin cargarlo (por ejemplo, para usarlo con alguna otra herramienta), inicie el modo de carga con -g opción y sqlninja generará el archivo en el /tmp del directorio y salir. Es necesario especificar el parámetro de contraseña cuando usted no tiene privilegios de administrador de sistema nativas (ver modo de escalada ).

Dirshell

Atajo: s
Parámetros:-p <sa contraseña> (opcional)

Utilice este método cuando el servidor de base de datos remoto es accesible directamente en algún puerto TCP o UDP. Sqlninja pide el puerto remoto, el protocolo, le dice al servidor DB para enlazar un símbolo del sistema para dicho puerto y luego inicia la conexión. Por supuesto, netcat debe haber sido cargado en el servidor remoto. El parámetro clave es que se utilizará cuando no tenemos privilegios de sysadmin nativas (ver modo de escalada ).

Backscan

Atajo: k
Parámetros:-p <sa contraseña> (opcional)

Típicamente, cuando el servidor de base de datos está detrás de un firewall que no es posible ponerse en contacto con directamente. Sin embargo, podría ser posible que el servidor está autorizado a acceder al mundo exterior en algún puerto (por ejemplo: DNS, HTTP). Este modo le dice al servidor de base de datos para enviar paquetes SYN o paquetes UDP a nuestro equipo en un rango de puertos, con el fin de buscar uno que está permitido. Sqlninja le dirá al usuario si se reciben los paquetes y en el que el puerto (s).

Es necesario especificar en el archivo de configuración, la dirección IP de su máquina ( parámetro lhost ) y la interfaz para escuchar en ( parámetro de dispositivo ). Sqlninja le preguntará sobre el protocolo a utilizar (TCP / UDP) y los puertos, que deben especificarse con la sintaxis netcat común (por ejemplo: "23 25 80-100" tratarán los puertos 23, 25 y todos los puertos entre el 80 y el 100). El parámetro clave es que se utilizará cuando no tenemos privilegios de sysadmin nativas (ver escalada ). Para utilizar este modo, netcat debe haber sido subido primero, y desde bibliotecas pcap es necesario utilizar también hay que ser root.

Revshell

Atajo: r
Parámetros:-p <sa contraseña> (opcional)

Si un shell directa no es posible, pero el modo backscan encontró un puerto abierto desde el servidor de base de datos para nuestra máquina, y luego una shell inversa es posible. Cuando utilice este modo, sqlninja pide el puerto local, el protocolo y luego inicia la conexión. Es necesario especificar en el archivo de configuración, la dirección IP de su máquina ( parámetro lhost ). Por supuesto, netcat debe haber sido cargado en el servidor remoto. Como de costumbre, el parámetro clave es que se utilizará cuando no tenemos privilegios de sysadmin nativas (ver modo de escalada ).

Icmpshell

Atajo: i
Parámetros:-p <sa contraseña> (opcional)

Cuando no shell directa o inversa se permite por el firewall, pero el DBMS remoto puede hacer ping a nuestra caja, que pueden crear un túnel nuestra shell en un túnel ICMP. Sólo subir icmpsh.exe, iniciar el modo icmpshell, y disfrutar de su concha. Todo el tráfico desde y hacia el DBMS remoto serán túnel a través de paquetes ICMP.

Al iniciar este modo de ataque, sqlninja le pedirá la siguiente información:

Tamaño de la memoria intermedia de datos: la cantidad de datos que se encapsula en un solo paquete ICMP. El valor predeterminado es de 64 bytes, pero se puede usar valores mayores para obtener un túnel más rápido. Sólo tenga cuidado al máximo MTU (Maximum Transfer Unit) entre usted y el DBMS. Un valor hasta 1300-1400 bytes debe ser considerado, para los estándares de hoy en día, bastante fiable. Usar paquetes más pequeños si quieres ir a lo seguro

Enviar demora: la cantidad de tiempo entre peticiones de eco ICMP contiguos. El valor predeterminado es de 300 milisegundos, pero se puede usar valores más bajos para obtener un túnel más rápido. Tenga en cuenta que un valor muy bajo puede generar un flujo de ping, que podrían ser notado, o automáticamente estrangulado por algún dispositivo anti-DoS entre usted y su objetivo.

Tiempo de espera de respuesta: la cantidad de tiempo que se esperaba por icmpshell.exe antes de volver a enviar una solicitud ICMP. El valor predeterminado es 3000 milisegundos

Importante: asegúrese de que el cuadro está configurado para no responder a las peticiones de eco ICMP. Por ejemplo, en Linux el siguiente comando hará el truco:

sysctl -w net.ipv4.icmp_echo_ignore_all=1

Dnstunnel

Atajo: d
Parámetros:-p <sa contraseña> (opcional)

Cuando no shell directa o inversa se permite por el firewall, y la cáscara ICMP no funciona bien, podemos tratar de establecer un túnel DNS. Los únicos requisitos son:

El servidor de base de datos debe ser capaz de resolver nombres de host externos (que es muy a menudo el caso)
La IP debe ser el servidor DNS autorizado de un dominio (usted puede comprar uno por unos pocos dólares). Usaremos sqlninja.net en nuestro ejemplo

Si se cumplen ambas condiciones, subir dnstun.exe, iniciar el modo dnstunnel, y poner en marcha los comandos. Lo que sucede es más o menos la siguiente:

1.El comando se pasa a través de inyección de SQL a dnstun.exe (que actúa como nuestro agente remoto) y es ejecutado por el servidor de base de datos remoto. La salida es interceptado y se codifica en un ligeramente modificada Base32 formato

2. La salida codificada se divide en una serie de nombres de host de que el dominio de control (por ejemplo: encoded_output.sqlninja.net )

3. Los nombres de host se pasan a gethostbyname() , de modo que los contactos del servidor de Base de Datos de su servidor DNS para resolver los

4. El servidor DNS busca el servidor autorizado de sqlninja.net (nuestra IP) y reenvía las peticiones a nuestra estación de trabajo

5. sqlninja recibe los pedidos, re-órdenes, si es necesario, decodifica los nombres de host y, finalmente, se imprime el resultado del comando. Por supuesto, sqlninja también responde a las peticiones DNS (con una dirección IP falsa) con el fin de hacer gethostbyname() devuelve rápidamente.


Todo el proceso se transmite, lo que significa que si el resultado del comando es muy largo usted comenzará a ver su salida antes de que el comando haya terminado.

El dominio que se utiliza debe ser especificado en el archivo de configuración . Por supuesto, ya sqlninja debe crear un servidor DNS falso y el puerto 53 se unen, necesita privilegios de root para utilizar este modo. Tenga en cuenta que el DNS utiliza UDP, por lo que la pérdida de paquetes puede ser un problema, aquí.

La versión ejecutable del agente ha sido compilado con Msys . Como siempre, el parámetro clave es que se utilizará cuando no tenemos privilegios de sysadmin nativas (ver modo de escalada ).


Metasploit

Atajo: m
Parámetros: ninguno

No contento con una ventana de DOS simple? ¿Quiere impresionar a sus amigos con un acceso completo GUI? Si tiene privilegios administrativos, xp_cmdshell obras y que ha encontrado un puerto TCP permitido (entrante o saliente), también puede utilizar sqlninja como un contenedor para Metasploit, con el fin de utilizar cualquiera Meterpreter o inyectar un servidor VNC. Piense en Meterpreter como indicador de DOS, pero mucho más potente, que le proporciona un control casi total sobre el sistema operativo remoto, incluyendo el acceso inmediato a los hashes de contraseñas, la posibilidad de cambiar las tablas de enrutamiento, realice el reenvío de puertos y más. Alternativamente, si usted tiene suficiente ancho de banda, también se puede inyectar un servidor VNC y disponer de un buen acceso gráfico a la base de datos remota.

Este modo de ataque es totalmente automatizado, y en pocas palabras, esto es lo que sucede:

1.Sqlninja le pide que especifique si desea utilizar Meterpreter o VNC, que la conexión sea directa o inversa, y el host / puerto conectarse (o puerto local para unirse, en caso de una conexión inversa)

2. Sqlninja llamará msfpayload para crear un archivo ejecutable apropiado que actuará como un servidor de ensayo

3. Sqlninja entonces convertirlo en un script de depuración y subirlo

4. Dado que vamos a necesitar inyectarse una DLL, puede ser que tenga que deshabilitar Data Execution Prevention (aka 'DEP', activada por defecto a partir de Windows 2003 SP1) en el cuadro de mando a distancia.

Las versiones recientes de Metasploit manejan este bit de forma automática, pero también se puede decir sqlninja tratará de hacerlo por usted, mediante el acceso al registro y listas blancas nuestra ejecutable (ver el checkdep parámetro)

5. Por último, sqlninja llamará msfcli para inyectar la DLL necesario y completar la explotación

Usted puede ver una demostración en flash de este ataque en el sitio web sqlninja.

Por supuesto, con el fin de utilizar este modo de ataque es necesario tener Metasploit3 disponible en su caja. Si ejecutables Metasploit (es decir msfpayload , msfcli y msfencode ) no se encuentran en su camino, se puede especificar su ubicación absoluta en el archivo de configuración. Además, si se utiliza el modo VNC, asegúrese de tener instalado un cliente VNC.

Sqlcmd

Atajo: c
Parámetros: ninguno

A veces, incluso si tenemos privilegios de administrador de sistemas y trabaja xp_cmdshell, todavía no es posible obtener un shell, tal vez porque el ejecutable no suba, o porque los puertos están filtrados y resolución DNS externo no está permitido. En estos casos, todavía puede ser útil para emitir comandos individuales en el servidor de base de datos, incluso sin ser capaz de ver la salida. Por ejemplo, es posible que desee agregar un usuario local (tal vez usted puede RDP a la caja), o un usuario de dominio, si SQL Server se ejecuta con los privilegios (sí, sucede más a menudo de lo que cabría esperar). En tales casos, se puede utilizar este modo: simplemente escriba un comando DOS y dejar sqlninja ejecutar de forma remota. Sólo recuerde: el fichero es ejecutado, incluso si usted no ve su salida.

Por supuesto, usted todavía puede usar el tiempo para saber lo que está pasando:

if exist filename (ping -n 5 127.0.0.1)

Si el comando tiene alrededor de 5 segundos para ejecutar, el archivo se encuentra allí.

Para saber si un comando se ejecutó correctamente, compruebe también el valor de la variable ERRORLEVEL, que normalmente se establece en 0 si la última orden no produjo un error. Así, por ejemplo, si queremos saber si el control remoto de SQL Server se ejecuta como SYSTEM, podemos utilizar el siguiente comando:

whoami > who.txt & find /i "\system " who.txt & if not errorlevel = 1 ping -n 5 127.0.0.1 & del who.txt

Si el comando tiene unos 5 segundos en ejecutarse, ya sabes que SQL Server se ejecuta como SYSTEM ( whoami.exe está instalado de forma predeterminada en Windows 2003 y se puede encontrar en Windows 2000 si el Kit de recursos se ha instalado). Actualizar sus habilidades DOS-shaolin y utilizar su fantasía: de anexar comandos de AUTOEXEC.BAT para iniciar / detener servicios y agregar usuarios deshonestos, se puede llegar muy lejos con esto!

Este modo también puede ser útil cuando falla de algún otro modo, para entender lo que salió mal y cómo solucionar el problema. Por último, este comando también es muy útil para mostrar a un cliente que poseyó su servidor DB aunque no obtuviste la shell:

echo You have been owned by sqlninja > c:\sqlninja.txt


getdata

Atajo: g
parámetros: -s <filename>(opcional)

Comencemos por señalar que todavía es muy experimental, es probable que contenga errores más que una versión beta de Win95, y por lo tanto usted no debe esperar su fiabilidad a prueba de bombas. Con eso fuera del camino, vamos a bajar al negocio: este módulo es 100% interactivo, por lo que debe ser bastante intuitiva. Sqlninja actualmente soporta dos canales de extracción, basados en el tiempo y basadas en DNS, se describe a continuación.

Basada en tiempos

Este canal se utiliza cuando data_channel se establece en el tiempo en el archivo de configuración y utiliza el comando WAITFOR DELAY lento pero fiable para extraer información. Sqlninja puede explotar basados en el tiempo inyección de dos maneras, detallada en los párrafos siguientes.

Búsqueda binaria basada en el tiempo

Este método se activa cuando data_extraction se establece en binario en el archivo de configuración. Si usted es incluso marginalmente en un ordenador, usted debe saber cómo funciona un algoritmo de búsqueda binaria, por lo que no voy a conseguir mucho en detalles. Básicamente, este método reduce al mínimo el número de solicitudes para la aplicación, que resulta útil si desea mantener su huella al mínimo. Sin embargo, aproximadamente la mitad de las consultas activará un retraso, lo que significa que este método podría no ser el más rápido.

Búsqueda de serie/optimizada basada en tiempo

Este método se activa cuando data_extraction se establece en optimizado (por defecto) o serie en el archivo de configuración. Con este método, todos los valores posibles son intentados en secuencia hasta la es conjeturada. La diferencia entre la serie y optimizado es del orden de los intentos: mientras el primero sólo trata de todos los valores siguiendo su valor ASCII, éste comienza con los valores más comunes.

El orden exacto es especificado por el parámetro language_map, y tal orden se modifica en tiempo real, adaptándose a la frecuencia real de caracteres se extrae, si el parámetro language_map_adaptive se establece en Yes.

Extracción basadas en DNS

¿Usted tiene control sobre un dominio DNS o subdominio? ¿Usted puede conseguir servidores DNS para disparar "Tipo A" pide que su caja? ¿El DBMS remoto resuelve nombres externos? Si es así, puede olvidarse de eso extracción lenta basada en la inferencia y comenzar tirando datos casi a la velocidad de la luz (bien, comparativamente hablando).

Asegúrese de que ejecuta sqlninja como root, sistema de dominio en el archivo de configuración, y usted está listo para ir.

Información adicional

De forma predeterminada, sqlninja almacena toda la información extraída en una base de SQLite local, cuyo nombre se especifica mediante línea de comandos con el parámetro -s. El nombre predeterminado es session.db. Para todos los otros parámetros y detalles, vea Opciones de extracción de datos.

Otros ataques

Muy a menudo, SQL Server no se ejecuta como sistema pero menos privilegios de usuario (muy a menudo "servicio de red"). Esto crea limitaciones en lo que el atacante puede hacer (por ejemplo: extraer hashes de contraseñas). También crea problemas con la inyección de VNC, causando una pantalla negra a devolverse. Sin embargo, con sqlninja podemos intentar escalar privilegios al sistema, mediante dos técnicas diferentes ataques.

CVE-2010-0232

Si SQL Server que se ejecuta bajo privilegios de usuario y la máquina no está parchada contra CVE-2010-0232, podemos intentar elevar sus privilegios al sistema. Sqlninja se suministra con una versión del exploit original por Tavis Ormandy que ha sido específicamente personalizados: mientras que el exploit original aparece una línea de comandos DOS, nuestra versión busca el proceso sqlservr.exe y obliga a correr como sistema. Con el fin de lanzar el ataque, los pasos siguientes son necesarios:

1.Subir vdmallowed.exe y vdmexploit.dll, que están disponibles en el directorio de aplicaciones en formato ejecutable y en el directorio de secuencias de comandos (en formato de secuencia de comandos de depuración)

2.Usando el modo de ataque sqlcmd, ejecute el siguiente comando: %TEMP%\vdmallowed sql

3.Si el ataque fue exitoso modo de huella digital debe avisar que ahora se ejecuta SQL Server como sistema

Secuestro de token

En Windows 2003 también podemos intentar escalar nuestros privilegios con el token de secuestro, una
técnica investigada por Cesar Cerrudo. Como una prueba de concepto que desarrolló churrasco.exe, que está incluido en el archivo de sqlninja en una versión ligeramente modificada. Si desea escalar al sistema simplemente subirla al servidor remoto usando el modo de carga y luego ajuste la opción de usechurrasco yes: todos los comandos que luego serán envueltas con churrasco.exe. Tenga en cuenta que esto no funcionará si el DBMS remoto ha sido parcheado contra el ataque, pero usted puede comprobar si las cosas están funcionando usando el modo de huellas dactilares, mientras esta opción está activada.

Importante: Asegúrese de usar la versión modificada del churrasco (sí, el uno en el archivo de sqlninja), o las cosas son capaces de romper. Usted puede ver las diferencias en el origen del C en el directorio de fuentes, pero básicamente hervir para:

1.No detallado a menos que se use la opción -d de salida. Salida verbosa interferiría con la opción 5 del modo de huella digital, que utiliza una tabla temporal para almacenar los resultados de una ejecución de churrasco.exe.

2.CreateProcessAsUser() se llama pasando el directorio del usuario (sin privilegios) original % TEMP % como el parámetro lpCurrentDirectory, que es donde nuestros archivos ejecutables (por ejemplo: netcat) son subido (y no en el directorio % TEMP % del sistema).

Archivo de configuración

El archivo de configuración (por defecto: sqlninja.conf) controla la mayor parte del comportamiento de sqlninja. Todas las opciones están en la forma:

option_name = option_value

La única excepción es httprequest, que define la solicitud HTTP y el punto de inyección y que abarca varias líneas (véase abajo).

Opciones pueden dividirse aproximadamente en las siguientes categorías:

Básica: permite configurar el ataque
Extracción de datos: permite configurar el modo de extracción de datos
Avanzado: utilizado para realizar ajustes adicionales

Opciones son más a menudo que no, mayúsculas y minúsculas (por ejemplo: valores de URL). La misma opción puede utilizarse varias veces: sqlninja no cuidado y será simplemente uso la última declaración, reemplazar las anteriores. Comentarios se permiten en cualquier lugar excepto entre--httprequest_start--y--httprequest_end--(véase abajo), y se antepone por el sqlninja.conf.example

Opciones básicas

httprequest

A partir de la versión 0.2.6, sqlninja utiliza una nueva forma de configurar la solicitud HTTP y la cadena de inyección relativa. En lugar de parámetros separados por host, Puerto, página, el método HTTP, cadena de explotación y encabezados adicionales, la solicitud HTTP toda se especifica a la vez, con un marcador (por defecto __SQL2INJECT__) que indica donde los comandos SQL deben ser inyectado. Esto simplifica mucho las cosas y lo más importante, permite total libertad en donde puede ser el vector de inyección: ahora no está limitado a un parámetro GET o POST, pero usted puede inyectar dondequiera que usted necesita (por ejemplo: en una cookie). Sqlninja considerará como la solicitud HTTP todo lo que se incluye entre las líneas--httprequest_start--y--httprequest_end--.

En general, los siguientes elementos deben incluirse:

El método HTTP (generalmente POST o GET)
El URL completo a los recursos, incluyendo http:// o https://
El puerto, si no estándar (por ejemplo: http://www.victim.com:8080)
La versión HTTP
Todas las cabeceras necesarias
El cuerpo después de una línea en blanco, si la solicitud utiliza POST

En general, la mejor estrategia es sólo utilizar a un proxy (por ejemplo, Burpsuite) para interceptar la solicitud que desencadena la inyección de SQL y copiarlo en sqlninja.conf

Por ejemplo, una inyección de GET-basado sobre texto HTTP se verá como la siguiente:

--httprequest_start--
GET http://www.victim.com/page.asp?string_param=aaa';__SQL2INJECT__&other_param=blah HTTP/1.1
Host: www.victim.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060418 Firefox/1.0.8
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*
Accept-Language: en-us,en;q=0.7,it;q=0.3
Accept-Charset: ISO-8859-15,utf-8;q=0.7,*;q=0.7
Connection: close
--httprequest_end--

Por otra parte, una inyección de POST-based sobre HTTPS probablemente se verá como la siguiente (obsérvese el encabezado Content-Type y la línea vacía entre cabeceras y cuerpo):

--httprequest_start--
POST https://www.victim.com/page.asp HTTP/1.0
Host: www.victim.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060418 Firefox/1.0.8
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*
Accept-Language: en-us,en;q=0.7,it;q=0.3
Accept-Charset: ISO-8859-15,utf-8;q=0.7,*;q=0.7
Content-Type: application/x-www-form-urlencoded
Cookie: ASPSESSIONID=xxxxxxxxxxxxxxxxxxxx
Connection: close

numeric_param=12;__SQL2INJECT__
--httprequest_end--

Tenga en cuenta que no está incluido el encabezado Content-Length: sqlninja calculará el valor adecuado y agregar el encabezado automáticamente.

Por último, una inyección de cookie se verá como la siguiente:

--httprequest_start--
GET http://www.victim.com:8080/page.asp?param1=aaa&param2=blah HTTP/1.0
Host: www.victim.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060418 Firefox/1.0.8
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*
Accept-Language: en-us,en;q=0.7,it;q=0.3
Accept-Charset: ISO-8859-15,utf-8;q=0.7,*;q=0.7
Cookie: ASPSESSIONID=xxxxx'%3B__SQL2INJECT__
Connection: close
--httprequest_end--

Tenga en cuenta cómo se ha codificado el punto y coma después el apóstrofe;: esto es porque de lo contrario el servidor sería analizar el punto y coma como separador entre diferentes "cookies".

Antes el marcador __SQL2INJECT__, es necesario incluir todo lo que se necesita para cerrar la consulta original e iniciar uno nuevo, como el parámetro vulnerable y la secuencia de caracteres que permite empezar a inyectar comandos. Esto generalmente significa, al menos:

1.el parámetro vulnerable (nombre, valor)
2.una comilla simple (si el parámetro es una cadena)
3.un punto y coma (para poner fin a la consulta original)
También debe incluir todo lo que se necesita para cerrar correctamente la consulta original, como un número apropiado de paréntesis de cierre. Por ejemplo, si desea inyectar el siguiente comando TSQL:

param1=1&param2=x'));exec+master..xp_cmdshell+'dir+c:'

la solicitud HTTP en el archivo de configuración debe contener lo siguiente:

param1=1&param2=x'));__SQL2INJECT__

Cosas importantes para recordar:

-En general, una buena técnica es replicar tan de cerca como petición de posible el HTTP que usaste para detectar originalmente que el defecto de la inyección de SQL (con un navegador web u otra herramienta), como en algún borde casos una cabecera distinta puede hacer una gran diferencia.

El único sugerido y suele utilizar HTTP/1.0 para evitar problemas con las conexiones restantes abierto modificación seguro

-Para darle toda su potencia y flexibilidad en la elaboración de su hazaña, sqlninja no pretende inmiscuirse en modo alguno: Esto significa que no va a modificar su petición HTTP (aparte del código para inyectar donde el marcador es, obviamente), pero también significa que no tratará de corregir su sintaxis, así que asegúrese de que su solicitud HTTP es correcto (incluyendo todo necesita codificación URL). Para más información, consulte RFC 1945, RFC 2068 y RFC 2616.

-A veces también necesitará añadir código SQL más después de la consulta inyectada (y por lo tanto después el marcador). Generalmente esto no es necesaria, porque sqlninja simplemente añade dos guiones y comenta el resto de la consulta original, pero hay algunos casos (raros) cuando sea necesario añadir código SQL adicional para las consultas por lotes funcionar correctamente.

En este caso, no olvide también establecer appendcomment = no, de lo contrario serán agregados dos guiones y el código SQL especificado aquí se considerará un Comentario

-Si inyectan en una cookie, y necesita un punto y coma para cerrar la consulta original, recuerda codificarlo de lo contrario se será analizado como el final del valor de la cookie

-No deje espacios al principio de cada línea.

-No deje líneas de comentario. ¿Se analiza como parte de la solicitud.

-Por último, si no se especifica el puerto para conectarse, sqlninja asumirá 80 para HTTP y 443 para HTTPS

proxyhost

Un proxy HTTP para conectar con el host de destino, si es necesario. Por ejemplo:

proxyhost = 192.168.1.233

proxyport

El puerto del proxy HTTP que conectemos. Por defecto es 8080. Por ejemplo:

proxyport = 3128

dominio

El atacante controladas dominio o subdominio para utilizarse con el modo de dnstunnel y el modo de extracción de datos basadas en DNS. La dirección IP desde la que se lanza sqlninja debe ser el servidor DNS autorizado para ese dominio. Por ejemplo:

domain = sqlninja.net

msfpath

La ruta de acceso absoluta a Metasploit ejecutables (msfpayload y msfcli). Usted no necesita si ya están en su ruta de acceso predeterminada. Por ejemplo:

msfpath = /home/icesurfer/tools/framework-3.1

evasion

Sqlninja puede utilizar algunas técnicas de evasión, con el fin de confundir y basadas en firmas IPS/IDS de derivación. Actualmente, se aplican técnicas de cuatro, que pueden ser combinados libremente juntos:

1.Codificación hexadecimal de consulta: la consulta es codificada en hexadecimal antes de que pasen
2. Comentarios como separadores: todos los espacios sean sustituidos por la cadena / ** /
3. Caso al azar 4. Codificación de URI al azar

La primera técnica es particularmente útil. Por ejemplo, si queremos inyectar el siguiente comando:

exec master..xp_cmdshell 'cmd /C ping 127.0.0.1'

La consulta real será:

declare @a varchar(8000) set @a=0x65786563206d61737465722e2e78705f636d647368656c6c2027636d64202f432070696e67203132372e302e302e31273b exec (@a)

Una cadena mucho más larga, pero el aviso lo siguiente:

-No SQL comandos excepto DECLARE y EXEC, así que adiós IPS de buscando xp_cmdshell y similares
-No solo frases bien! Esta técnica de evasión por lo tanto es muy útil si usted encuentra un parámetro numérico vulnerable y comillas simples se filtran

Como se mencionó, se pueden combinar todas las técnicas junto con la siguiente opción:

evasion = 1234

Esto generará código bastante críptico, como el siguiente:

%64ECl%41RE%2F%2A%2A%2F%40%61%2F%2A%2A%2F%76Ar%63%48aR%288000%29%2F%2A%2A%2F%73 ET%2F%2A%2A%2F%40A%3D%30%586%35786%3563%3206d617%33746%35%372%32e2%457870%35F63 6d647368%36%35%36%63%36c2%302%37636D%3642%30%32f%34320%37%3069%36%65%36720%331% 332372E%330%32E3%30%32%45%3312%373b%2F%2A%2A%2FeX%65%43%2F%2A%2A%2F%28%40A%29

De forma predeterminada, sqlninja establece evasión cero, y no se utilizará ninguna técnica de evasión.

Importante: Evite el uso innecesario ofuscación si usas solicitudes GET, ya que podría producirse URLs que son demasiado largos y que no son interpretados correctamente por el servidor web!

msfencoder

El codificador a utilizar para el stager Metasploit. Si no se especifica ninguna codificación se realiza. Sin embargo, siempre se recomienda un buen codificador. Por ejemplo:

msfencoder = x86/shikata_ga_nai

upload_method

El método a utilizar para cargar archivos binarios. Los valores posibles son debug o vbscript (por defecto). Por ejemplo:

upload_method = vbscript

Opciones de extraccion de datos

data_channel

El canal a utilizar para extraer los datos. Puede ser tiempo (por defecto) para utilizar un canal de la extracción de WAITFOR (muy lento, pero siempre funciona) o dns (mucho más rápido, pero tienes que controlar un dominio o subdominio a resolverse a su dirección IP pública. Por ejemplo

data_channel = time

data_extraction

Cuando utilice la extracción basados en el tiempo, hay tres métodos de extracción posible. Al elegir el binario, sqlninja llevará a cabo una búsqueda binaria, reduciendo al mínimo el número de solicitudes. Al elegir el serial, sqlninja tratará de todos los valores posibles, que probablemente será más rápidos (ya que WAITFOR se activará sólo una vez) pero dejará más entradas en los registros remotos. Al elegir el serial_optimized, sqlninja tratará todos los valores posibles, a partir de los candidatos más probables. El valor predeterminado es serial_optimized

language_map

Si está utilizando la extracción en función del tiempo y seleccionado serial_optimized como su método de extracción, puede especificar un mapa lenguaje donde puede especificar las órdenes de caracteres que deben ser juzgados en la extracción de datos. Usted puede encontrar algunos mapas predefinidos en lib/langs, donde incluye mapas para inglés, Francés, Italiano, alemán, español y portugués. Tales mapas se basan en la frecuencia de la letra en los idiomas respectivos e incluyen también un espacio en blanco y algunos caracteres de puntuación comunes. Si usted necesita un mapa personalizado, sólo una lista de los personajes en una sola línea. No es necesario especificar todos los personajes posibles: los que no en el mapa simplemente será juzgado si ninguno de los especificado tiene éxito. Por ejemplo:

language_map = lib/langs/en.maps

language_map_adaptive

Al utilizar una extracción serie optimizado, sqlninja puede utilizar un enfoque adaptativo: básicamente, cada personaje en el mapa de la lengua se da un "peso" y cada vez que un personaje es extraído con éxito por la base de datos remota, se incrementa el peso de este personaje en el mapa de la lengua por uno. Cuando el peso de caracter en la posición N es mayor que el peso del carácter en la posición N-1, sus lugares se conmutan en el mapa, para que el personaje con el peso más alto (que por lo tanto es más frecuente) será juzgado primero en la extracción después de caracteres. Valores aquí son sí o no, pero en general, que usted siempre debe pegarse a sí para mejores resultados. Por ejemplo:

language_map_adaptive = yes

store_session

De forma predeterminada, sqlninja almacena todo extraída de la información en una base local de SQLite, especificada mediante línea de comandos (por defecto: session.db). Esto le permite localmente guardar todos los datos extraídos y recuperarlo en un momento posterior. En general, deje este Yes. Por ejemplo:

store_session = yes

sanity_check

Cuando se utiliza la extracción en función del tiempo, la latencia de red pueden limitar la precisión si extrajeron los datos. Sqlninja puede comprobar la exactitud de la información extraída (actualmente DBs, usuarios, tablas, columnas pero no filas todavía) y vuelva a intentar extraer el mismo dato si se detecta un problema. El control implica sólo una consulta, se realiza al final de la extracción de una cadena entera (por ejemplo: un nombre de columna) y utiliza un WAITFOR que se ejecuta solamente si la información es incorrecta. Por lo tanto, el cheque tiene un impacto muy limitado rendimiento. En general, deje este Yes. Por ejemplo:

sanity_check = yes

Opciones avanzadas

lhost

Las direcciones IP o nombre de host que el objetivo debe tratar de ponerse en contacto con en el modo de backscan y revshell. Es * la * máquina. Por supuesto, si el ataque se realiza por Internet, esto debe ser una dirección pública. Por ejemplo:

lhost = tester.sqlninja.net

dispositivo

El dispositivo para rastreo de paquetes en el modo de backscan (por defecto: eth0). Por ejemplo:

device = ppp0

filtrar

Una expresión de pcap válido para filtrar los paquetes entrantes en modo backscan. De forma predeterminada, cuando realice tal ataque, sqlninja escucha los paquetes procedentes de la dirección IP del servidor web remoto y dirigido al host especificado en lhost. Esto podría no funcionar en todos los casos: por ejemplo, las conexiones salientes del servidor DB podrían coordinó a una dirección IP que es diferente de la dirección IP del servidor web. Por lo tanto, tenemos que reemplazar el filtro de pcap por defecto con este parámetro, por ejemplo indicando la subred todo pública del blanco. Sólo necesita especificar hosts y redes, como los detalles del Protocolo (por ejemplo: indicadores tcp) son manejados por sqlninja. Por ejemplo:

filter = src host nat.victim.com

tiempo de espera

Este parámetro se utiliza en el modo de backscan. Especifica cuántos segundos a esperar para más paquetes después de que ha completado la solicitud web (por defecto: 5 segundos). Esto es especialmente útil cuando se especifica una gama muy grande de puertos para analizar, porque la solicitud web posible tiempo de espera antes de que finalice netcat. En este caso, debe aumentar este valor. Por ejemplo:

timeout = 30

Sin embargo, tratar de evitar intervalos de puertos muy grande: mejor dividir el trabajo en múltiples exploraciones

hostnamelength

Longitud máxima de nombre de dominio completo de los nombres falsos que el objetivo será intentar resolver en modo dnstunnel de. RFC del estado que el límite es de 255 caracteres, pero me topé con unos servidores DNS que se negaron los nombres de más de 253. El valor predeterminado es por lo tanto 250, que debe ser aceptado por todos los servidores DNS y al mismo tiempo mantener una velocidad de casi óptima del túnel. Valor mínimo es de 40. Obviamente, el máximo es 255. Por ejemplo:

hostnamelength = 250

También puede ajustar este parámetro para valores inferiores, cuando se piensa que pudieran observar mucho las peticiones DNS. Por supuesto, valores más cortos: un túnel más lento. Si no está seguro, deje el valor por defecto

msfencodecount

Número de veces que el stager debe ser codificado. Valor predeterminado es 5. Por ejemplo:

msfencodecount = 8

usechurrasco

Esta configuración se utiliza para escalar privilegios a través de secuestro token. El valor predeterminado de esta configuración es no. Por ejemplo:

usechurrasco = yes

resolvedip

En el modo de dnstunnel, la dirección IP que será enviada a cada petición DNS (ya que no queremos gethostbyname() para colgar). En general, es recomendable establecer esto a 127.0.0.1 (que es el valor por defecto), para evitar el tráfico de red espuria generado después de que el DBMS remoto reciba una respuesta DNS falsa.

resolvedip = 10.255.255.254

xp_name

Nombre del procedimiento extendido que ejecuta los comandos. El valor predeterminado es obviamente xp_cmdshell. Este parámetro se utiliza de dos maneras diferentes, dependiendo del modo actual de ataque:

-resurrectxp: xp_name contiene el nombre del procedimiento extendido para crear. Si usted cree que podría ser visto reactivar xp_cmdshell, hacer otro nombre (por ejemplo: sp_sqlbackup)
-todos los demás modos: el nombre de procedimiento extendido a usar. Hace falta decir que debe ser el mismo nombre utilizado anteriormente con el modo de resurrectxp.

xp_name se puede establecer en NULL para utilizar la técnica de inyección en línea procedimiento (ver modo de resurrect_xp para más detalles). Por ejemplo:

xp_name = sp_sqlbackup

blindtime

El valor de las llamadas WAITFOR DELAY que se utilizan en los modos de la huella digital y fuerza bruta para la inyección de inferencia. El valor predeterminado es 5 segundos, pero esto podría ser insuficiente para servidores muy lentos y conducen a resultados equivocados. Si esto sucede, intente aumentar valor de este. Por el contrario, si el tiempo de respuesta del servidor es muy corto, puede establecer un valor más bajo para hacer las cosas más rápido (mínimo: 3). Por ejemplo:

blindtime = 4

Si usted no tiene ninguna pista sobre lo que significa la inyección de inferencia, disfrutar de algún tiempo en la sección de fondo.

lines_per_request

Con este parámetro se puede controlar el número de líneas de la secuencia de comandos de depuración se carga en una sola solicitud. Obviamente, un valor más alto significa una carga más rápido, pero sería arriesgado Si utilizas solicitudes GET, ya que la URL podría ser demasiado larga. Aquí el valor por defecto es 10, y el máximo es 30. Ejemplo:

lines_per_request = 15

errorstring

Sqlninja alerta al usuario cuando se recibe un código de error HTTP (por ejemplo: 500 Error del servidor), pero algunas aplicaciones devolución una página personalizada con un mensaje bien 200. En tales casos, es conveniente proporcionar sqlninja con una cadena que está presente en esa página de error (y sólo en esa página). El valor del parámetro se debe poner entre comillas dobles. Por ejemplo:

errorstring = "an error has occurred"

appendcomment

De forma predeterminada, sqlninja anexa dos guiones para la consulta inyectada para comentar cualquier código SQL espurio. Esto es bueno y funciona en aproximadamente el 99% de los casos. Sin embargo, puede cambiar este comportamiento en algunos casos muy específicos. Por ejemplo:

appendcomment = yes

Cambiar esta configuración sólo si realmente sabes lo que haces.

checkdep

Las versiones recientes de Metasploit automáticamente deshabilitar DEP con el servidor de ensayo antes de inyectar la DLL. Sin embargo, si por alguna razón esto no funciona puede hacer retroceder al comportamiento antiguo: sqlninja comprobará la configuración de DEP en el equipo remoto y tratará a la lista blanca el Metasploit stager por llamada xp_regread. Por defecto esta opción está definida no no pero es perfectamente seguro para volver a habilitar el cheque. Sólo hará las cosas un poco más lentas y obviamente dejará una huella ligeramente más grande en el sistema remoto. Ejemplo:

checkdep = no

sqlmarker

También puede reemplazar el valor del marcador que se utiliza para indicar sqlninja Dónde inyectar el código (por defecto: __SQL2INJECT__). Es extremadamente improbable que necesitará cambiar esto.

sqlmarker = SOME_WEIRD_STRING_HERE

b64decoder

Puede reemplazar el nombre de sqlninja aplicaciones para el script utilizado para decodificar base64 archivos una vez que se carguen. El valor predeterminado es b64decoder.vbs. Es extremadamente improbable que necesitará cambiar esto.

b64decoder = somename.vbs

Otra información útil

-Sqlninja es publicado bajo la licencia GPLv3. Consulte el archivo de licencia para más detalles.

-Netcat está incluido en el paquete de sqlninja, ya en formato scr.

-En modo "verbose" podría obtener un "Bareword NetPacket::IP::IP_PROTO_UDP prohibido... bla, bla" error. Con seguridad puede ignorar, lo que parece un error inofensivo de NetPacket. Si usted quiere conseguir librarse de ella, set $proto = 17 en UDP.pm.

-Todos los derechos para los documentos de referencia en la sección antecedentes pertenecen a la siguiente generación de Software de seguridad, ahora forma parte del grupo de NCC. Yo soy hosting les en mi sitio web simplemente porque no me gusta este manual tener enlaces muertos, y los originales fueron constantemente movidos o borrados.

-A menos que seas un principiante, snowboard en pista es cojo.

Responsabilidad

Sqlninja no es trivial para configuración, por lo que debe ser de ninguna utilidad para script kiddies. En cualquier caso, qué hacer con esta herramienta es únicamente su negocio. Para poder utilizarlo que se supone que un profesional penetration tester con algún documento escrito que le autoriza a perforar agujeros en la red que están atacando. Si no tienes dicha autorización, no dude en todas formas de divertirse pero tenga en cuenta que esto podría implicar en problemas con un montón de ley encargados. Significa que usted. Nosotros no.

Autores

icesurfer - < r00t -at- northernfortress -dot- net >

nico - < nico -at- leidecker -dot- info > 

sqlsus

Inyeccion SQL en banda o por inyección ciega
A través de una interfaz de línea de comandos, se puede recuperar la base de datos (s) estructura, inyectar sus propias consultas SQL (aunque sean complejas), descargar archivos desde el servidor Web, el sitio web para rastrear directorios escribibles, cargar y controlar una puerta trasera, clonar la base de datos (s), y más ...
sqlsus se centra en la velocidad y eficiencia, optimizando el espacio disponible inyección, haciendo el mejor uso (se me ocurre) de las funciones de MySQL.

Se utiliza subconsultas apiladas y un algoritmo potente de inyección ciega para maximizar la información obtenida por golpe del servidor web.

El uso multithreading encima de eso, es un dumper sqlsus de base de datos extremadamente rápida, ya sea en banda o por inyección ciega.

Si los privilegios son lo suficientemente altos, sqlsus será de una gran ayuda para cargar una puerta trasera a través del punto de inyección, y toma de control del servidor web.

Se utiliza SQLite como backend, para un uso más fácil de lo que ha sido objeto de dumping, e integra las funciones habituales ,como soporte para cookies, calcetines / proxy http, https ..


SINTAXIS

sqlsus [opciones] [config file]


OPCIONES

-h --help Breve mensage de ayuda
-v --version Informacion de la version
-e --execute <commands> Ejecuta comandos y sale
-g --genconf <filename> Genera el archive de configuracion


EJEMPLOS

Cuando se inicia una nueva sesión (nuevo objetivo), la forma más sencilla es la de generar un fichero de configuracion

sqlsus -g vuln.conf



Ahora habrimos el fichero para editarlo

sqlsus vuln.conf
nano vuln.conf



Bajamos a la linea que pone or $url start=""; e insertamos la url

$url start="http://glyffo.se/show.php?id=1";

Para guardar los cambios, pulsaremos la combinación de teclas Control+o y para salir Control+x

Creamos una session con la url seleccionada

sqlsus vuln.conf



Ejecutamos el comando start y dejamos que trabaje

start



Obtenemos un item con el siguiente commando

get <item>

Posibles items



Vamos a ver las tablas

get tables



Echamos un vistazo y vemos una tabla que nos interesa, terminada en _users, vamos a verla con el siguiente comando

get columns [nombre de la tabla]

get columns iimyj1ieo_users



Probamos a injectar a ver que pasa, con el siguiente comando

select * from iimyj1ieo_users



Vemos que el usuario es "glyffo" y el pass es un hash, lo copiamos y procedemos a descodificarlo con alguna herramienta de Offline Atacks tipo hashcat.

Cerramos sesion

exit




Otros metodos

Si no desea ejecutar sqlsus interactivamente, utilice la opción

-e|--execute

switch, es decir:

sqlsus vuln.conf -e 'start;get tables;get columns;clone'

Puede especificar varios comandos delimitada por ;

Sólo lo que difiere de los valores por defecto son necesarios en el archivo de configuración, lo que le permite tener un archivo de configuración muy pequeño.

Tenga en cuenta que package conf; es necesario en la parte superior de su archivo de configuración.

Todos los valores especificados en el archivo de configuración será anulado por las variables que se pueden establecer en sqlsus usando "set", siempre que $allow_override == 1 (que es el valor predeterminado)

Por ejemplo:

- Primera ejecución, inicie sqlsus con ninguna cookie definida

sqlsus cookie var == conf cookie var == EMPTY

- Segunda pasada, se configura una cookie en el archivo de configuración

Resultado: la variable de cookie sqlsus (es decir: una cookie vacío) anulará la cookie especificada en el archivo de configuración.
En este caso, se desea cambiar el valor de la cookie dentro sqlsus utilizando set cookie <cookie>

Este comportamiento le permite adaptar sqlsus a su destino sin la necesidad de salir sqlsus, cambiar el archivo de configuración, el fuego de sqlsus nuevo, etc ..

Para generar el archivo de configuración que refleje su configuración actual, puede utilizar genconf <filename> dentro sqlsus.


Inband / Blind

En banda significa que la respuesta será visto a través del mismo canal de la inyección se llevó a cabo (el resultado de la consulta será en el HTML)

Blind significa que el resultado no puede ser leída directamente, y que tenemos que adivinar lo que es.

Para que ambos realmente rápido, sqlsus utiliza algunas interesantes características, para hacer frente al hecho de que MySQL no admite consultas apilados y que no había ninguna función SLEEP antes de MySQL 5.0.12

El modo en banda, sqlsus se acumulará subconsultas como mucho puede por consulta, siempre y cuando no sea golpeado o max_subqueries max_sendable.

En el modo Blind, sqlsus hará lo siguiente:
-de acuerdo con cada elemento con un conjunto de expresiones regulares, para reducir el espacio de caracteres a utilizar para el elemento de ataque de fuerza bruta.
-encontrar la longitud del elemento
-bruteforce cada personaje con el espacio de caracteres que se encuentran (o utilizando default_range si no lo eran)

Las tareas se dividen por hilo (en realidad, proceso):
-coincide con RE + encontrar la longitud
-bruteforce caracteres

sqlsus se encargará de que los hilos siguen siendo tan ocupada como sea posible, y siempre y cuando tenga sentido (evitar golpes innecesarios).

Tenga en cuenta que en el modo en banda, es generalmente una buena idea para hacer la consulta no retorno real (append "AND 1=0" for example)


Comandos

Ayuda en línea está disponible en sqlsus.

Escriba help o help <command>

Usted puede romper comandos usando Ctrl-C. Se puede tomar algún tiempo para detenerse en realidad, de modo que usted puede tener resultados explotables cuando se rompe un excesivamente largo SELECT.


Archivo de configuración

Se puede generar un archivo de configuración con valores predeterminados sqlsus utilizando:

sqlsus --genconf my.cfg

El archivo resultante tiene la documentación en línea.


SQLite backend

Puede acceder al backend SQLite directamente desde la línea de comandos con SQLite3.

Las consultas y la tabla asociada se almacenan en las queries de tabla.

Los nombres reales de las columnas se almacenan en las tables de la tabla.

bases de datos de la estructura de las databases de datos de mesa, la historia de la history de la tabla, los privilegios de privileges y variables de la tabla (lo sorprendente) variables.

Para almacenar los resultados de las consultas, sqlsus no utiliza nombres reales de columna directamente a evitar varios posibles problemas, algunos de los cuales son palabras reservadas y citas (por ejemplo: si usted proporciona select NULL, sqlsus tendría que crear una columna llamada NULL, que no se ser permitido.). Este comportamiento también se evita sqlsus de ser el objetivo de la inyección de SQL.

Cuando se utiliza clone, las tablas / columnas resultantes son reales, nombres reales, por lo que puede "modificar" la base de datos SQLite3 con directamente.


Bajo el capó

Buscar la ventaja
La idea de ir a buscar la ventaja es obtener resultados útiles tan rápido como sea posible.

Por lo tanto, cuando la cantidad de datos que se devuelven no se conoce, sqlsus será ir a buscar los N resultados por delante, haciendo uso de la N temas definidos por el usuario después de pulsar Intro, en lugar de esperar a que un hilo para hacer un select count () y sólo entonces comenzar a utilizar todos los hilos para recuperar los datos.

Además, puesto que el usuario puede romper la instrucción select cuando quiere, tiene más sentido tener resultados útiles en lugar de la cantidad de resultados esperados

Tenga en cuenta que en modo ciego, se requiere saber la cantidad de datos a buscar, por lo que en este caso, ir a buscar-por delante sólo se aplica para obtener resultados completos fueron solicitados, de nuevo para tener información útil cuando un usuario rompe el comando.

inband

En el modo de banda (cuando el resultado de la consulta será en el HTML), si su pregunta devuelve mas de una fila, sqlsus utilizará subconsultas tantos puede utilizar al mismo tiempo (por consulta), está bajo un límite configurable.
Por lo tanto, pueden tomar hasta miles de registros en el servidor de sólo 1 golpe (según el espacio disponible de la inyección) (cf banda demo)
Además, es obvio que utiliza varios subprocesos para acelerar las cosas.
El uso de "autoconf" comandos, puede dejar que sqlsus encontrar los mejores valores para maximizar los datos devueltos por golpe-servidor.

blind

En el modo ciego, sqlsus hace el mejor uso de los niños bifurcado de modo que sean tan ocupado como sea posible, realizar tareas pertinentes.

No recupera los datos de un registro poco a poco, lo que seria una gran perdida de tiempo

El algoritmo simplificado ciego se comporta de esta manera (por ejemplo: una consulta de selección devolveria varies filas de varias columnas):

0.Engendro niños

1.Dar a todos los niños disponibles un registro para encontrar la longitud de, y coinciden contra una expresion regular.

Las expresiones regulares que coinciden se basan en los registros más típico que se encuentran en una base de datos (alpha_lower, alfa, hex, numéricas ...)

Encontrar primero la longitud de los caracteres existentes evita el desperdicio de exitos para el ataque contra el servidor por fuerza bruta.
Adaptación de la partida contra una expresión regular reduce mucho el número de golpes requerido por la búsqueda binaria (alrededor del 30% menos de visitas requeridas para los registros típicos).

2 Hacer a cada niño disponible una char de fuerza bruta para encontrar la longitud del conjunto de registros que conocemos + regex .

3 Cuando se encuentra un registro completo, almacena y asigna a un niño para encontrar de la longitud+regex del siguiente registro [1] (los otros niños todavía estarán en bucle [2]).
Al principio buscamos al mismo tiempola longitud + regex de todos los registros. Así que si el usuario quiere romper el comando, tendrá resultados utilizables tanto como sea posible.