Anda di halaman 1dari 37

sqlninja logotipo

... Uma injeção de SQL Server e ferramenta de aquisição

Sobre Demonstração Baixar Documentação FAQ

Manual do usuário Sqlninja

rel. svn-0.2.999-alfa1

1. Introdução

1.1 Requisitos

1.2 Background

1.3 Como usá-lo

2. modos de ataque

2.1 teste

2.2 impressão digital

2.3 bruteforce

2.4 escalada

2,5 resurrectxp

2.6 enviar

2.7 dirshell

2.8 backscan

2.9 revshell

2.10 icmpshell

2.11 dnstunnel

2.12 Metasploit

2.13 sqlcmd
2.14 getdata

2,15 Outros ataques

3. arquivo de configuração

3.1 Opções básicas

3.2 opções de extração de dados

3.3 Opções avançadas

4. Outras informações úteis

4.1 Créditos

4.2 Renúncia

4.3 Comentários

4.4 Sabedoria

4,5 Autores

1. Introdução

O objetivo da Sqlninja é explorar vulnerabilidades de injeção SQL em aplicações web que usam o Microsoft
SQL Server como back-end. Ele é liberado sob a GPLv3 .

O principal objetivo da Sqlninja é obter interativo de nível OS acesso no servidor remoto DB e usá-lo como
um ponto de apoio na rede de destino. Como um recurso experimental, também pode extrair dados do
banco de dados. Em poucas palavras, aqui está o que ele faz:

Impressão digital de controle remoto SQL Server (versão, o usuário realizar as consultas, os privilégios do
usuário, xp_cmdshell disponibilidade, modo de autenticação DB Server)

Bruteforce da senha 'sa' (SQL Server 2000 apenas)

Privilege escalada para 'sa' (SQL Server 2000 apenas)


Criação de um xp_cmdshell personalizado se o original foi desativada

Carregar de executáveis

Reverter varredura a fim de procurar uma porta que pode ser usado para um shell reverso

Shell direta e reversa, TCP e UDP

DNS túnel pseudoshell, quando há portas estão disponíveis para uma bindshell

ICMP encapsulada shell, se o alvo DBMS pode se comunicar via ICMP Echo com a máquina de ataque

Metasploit acondicionamento, quando você quiser usar Meterpreter ou ainda quer ter acesso GUI no
servidor remoto DB

OS escalação de privilégios no servidor remoto DB usando seqüestro de token ou através CVE-2010-0232

Extração de dados da DB remoto, utilizando inferência baseada WAITFOR ou túneis baseados em DNS

Todos os itens acima pode ser feito com ofuscado código SQL, a fim de confundir os sistemas de IDS / IPS

Como você provavelmente já descobriu, sqlninja não procurar vulnerabilidades de injeção SQL. Novamente,
já existem várias ferramentas que realizam essa tarefa já, como BurpSuite .

Para a versão mais recente e dois demos em flash, confira o endereço http://sqlninja.sourceforge.net . Os
demos referir a uma versão anterior, mas ainda são perfeitamente bom para obter um melhor
entendimento da ferramenta.

Leia atentamente este manual (sim, eu quero dizer tudo isso), como ele vai explicar o que é e tudo sobre
como fazer o seu caminho através de todas as opções sqlninja. Sim, eu sei que é terrivelmente longo e
chato, mas desde sqlninja tem uma infinidade de opções para jogar (e não botões brilhantes verdes), para
tentar ler a coisa toda: ele vai ajudá-lo a obter o máximo da ferramenta e da vontade poupar muito tempo
depois.

1.1 Requisitos

Desde sqlninja é completamente escrito em Perl, não há muito para instalar, exceto em si Perl e os
seguintes módulos, se ausente:

NetPacket

Net-Pcap

Net-DNS
Net-RawIP

IO-soquete-SSL

Net-Pcap

DBI

Você também vai precisar do Metasploit Framework 3 em seu caixa para usar o modo de ataque
Metasploit, e também um cliente VNC, se você usar o payload VNC.

Se algo der errado, ativando a saída detalhada ( -v opção) e / ou depuração ( -d ) deve fornecer algumas
dicas. Desenvolvido em uma caixa de Gentoo, sqlninja tem sido relatada a trabalhar nos seguintes sistemas
operacionais:

Linux

FreeBSD

Mac OS X

iOS

1.2 Background

Às vezes, quando você encontrar uma vulnerabilidade de injeção SQL em uma aplicação web que usa o SQL
Server, tudo é 2001 de novo: você descobre que suas dúvidas são executados como 'sa', você verificar que
xp_cmdshell não foi desativado, então você faz o servidor baixar netcat (via FTP ou TFTP) e, finalmente,
obter o seu shell direta ou inversa. Na maioria das vezes, porém, as coisas são diferentes: talvez o firewall
filtra todas as conexões de entrada / saída, ou um shell reverso só é permitido em algum serviço obscuro,
ou xp_cmdshell não está lá, ou as consultas são executadas com baixos privilégios. Ou talvez todas estas
coisas juntas ;). Sqlninja oferece alguma ajuda no sentido de obter o shell remoto merecida, mesmo nesses
casos. E se isso falhar, ele ainda pode ajudá-lo a apertar alguns dados de controle remoto DBMS.

Estou assumindo que você tem uma boa compreensão das técnicas de injeção de SQL e de internos do
Microsoft SQL Server. Se você tem dificuldade para entender o que se segue, eu recomendo que você leia
este , este e este . Eu também estou supondo que você entender o que o protocolo de encapsulamento é,
em particular sobre ICMP e DNS. Se você não fizer isso, uma boa introdução ao conceito de DNS é aqui .

1.3 Como usá-lo


O comportamento de Sqlninja é controlado através do arquivo de configuração (padrão: sqlninja.conf ), que
diz sqlninja o que atacar e como (host de destino, página vulnerável, explorar cordas, ...), e algumas opções
de linha de comando, o que dizer sqlninja que ação para executar. Estas opções de linha de comando são os
seguintes:

-M <attack <modo: especifica o modo de ataque. Basicamente, diz sqlninja o que fazer. Os valores
possíveis são:

teste

impressão digital

bruteforce

escalada

resurrectxp

fazer upload

dirshell

backscan

revshell

dnstunnel

icmpshell

Metasploit

sqlcmd

getdata

-V: verbose

-F <arquivo: especifica um arquivo de configuração para usar.

-P <senha 'sa'>: usado no modo escalada para adicionar usuário atual DB ao grupo sysadmin, e em outros
modos para executar a consulta como administrador, se o usuário DB não pertence a esse grupo. Esta opção
raramente é usado, como modo de bruteforce por padrão adiciona o usuário DB ao grupo sysadmin quando
a senha 'sa' é encontrado. Para obter mais informações sobre quando usar este parâmetro, consulte o
modo de escalada

-W <wordlist>: lista de palavras para usar em modo de bruteforce

-G: combinado com o modo de upload, gerar script de depuração e saída

-D <debug <modo: ativa debug, para ver o que está acontecendo sob o capô. Os valores possíveis são:

1: imprimir cada comando SQL que está sendo injetado


2: imprimir cada pedido HTTP que é enviada para o destino

3: imprimir cada resposta HTTP que é recebido do target

tudo: todos os itens acima

Veja a descrição dos vários modos para ver quando cada parâmetro deve ser usado.

2. modos de ataque

Sqlninja atualmente tem 14 modos de ataque. O modo de usar pode ser especificada pelo seu nome:

sqlninja -m upload

ou pelo atalho:

sqlninja -mu

A lista com os modos disponíveis e seus atalhos correspondentes podem ser recuperados com o
lançamento sqlninja sem parâmetros.

Para obter uma primeira compreensão dos diferentes modos de ataque, aqui está uma forma habitual de
utilizar sqlninja:

Configure o arquivo de configuração, e usar o modo de teste para verificar se o código SQL está sendo
injetado corretamente

Fingerprint o servidor DB remoto, utilizando o modo de impressão digital

Se necessário, use o modo de bruteforce para encontrar a senha 'sa' e escalar privilégios (SQL Server 2000
apenas)

Se necessário, use o modo de resurrectxp para recriar o procedimento estendido xp_cmdshell (SQL
Server 2000 apenas)

Envie netcat, usando o modo de upload

Se for possível entrar em contato com o DB Server em alguma porta, use o modo de dirshell e obter um
shell direta. Alternativamente, se a porta é TCP, use o modo de Metasploit para obter acesso gráfico

Caso contrário, use o modo de backscan encontrar um permitido "saída" porta TCP / UDP

Se a etapa 7 é bem sucedida, utilize o modo de revshell para obter um shell reverso. Alternativamente, se
a porta é TCP, use o modo de Metasploit para obter acesso gráfico

Se a etapa 8 falhou, e tentar fazer o upload icmpsh.exe modo icmpshell para obter uma shell icmp-
encapsulada

Se a etapa 9 não, carregar dnstun.exe e começar dnstunnel modo a obter um dns-túnel pseudo-shell

Se a etapa 10 falhou, aumente getdata modo e começar a extrair algumas mesas!

2.1 teste

Atalho: t

Parâmetros: Nenhum

Este modo simplesmente injeta uma simples WAITFOR DELAY e verifica se ele é executado com sucesso pelo
servidor remoto. Utilize este modo para testar se seu arquivo de configuração está correto ea injeção está
funcionando.

2.2 impressão digital

Atalho: f

Parâmetros:-p <sa password> (opcional)

Usando injeção cega baseada WAITFOR, este modo as impressões digitais do servidor remoto. Os seguintes
elementos de informação podem ser obtidos:

Versão de banco de dados (2000/2005/2008/2012)

Usuário que está executando as consultas

Se o usuário pertence ao grupo sysadmin

Se xp_cmdshell está disponível para que o usuário

Se o servidor remoto usa a autenticação mista ou somente para Windows (você precisa saber isso, se
você quiser BruteForce senha 'sa')

Se o controle remoto do SQL Server é executado como SYSTEM. Isto pode também ser usado para
verificar se churrasco.exe foi correctamente carregado e é capaz de aumentar privilégios através do
sequestro de token.

Nome da DB atual

Se você está atacando SQL Server 2000, o usuário atual DB não pertence ao grupo sysadmin, mas a senha
do direito 'sa' é especificado como um parâmetro, a impressão digital é realizada com direitos
administrativos. A técnica WAITFOR é muito mais lenta em comparação com outros métodos de inferência,
mas é, de longe, o mais flexível. No entanto, uma vez que fatores externos, como o tráfego de rede e carga
do servidor poderia interferir com as medições do tempo, você pode querer repetir a impressão digital de
um par de vezes, se o primeiro resultado não parece certo, ou brincar com o blindtime parâmetro no
arquivo de configuração . Note-se que, a fim de usar a impressão digital do usuário executando o SQL
Server o seguinte devem estar disponíveis na caixa de controle remoto:

xp_cmdshell (ou processo equivalente)

whoami.exe . Isso está presente por padrão no Windows 2003, mas se você suspeitar que este utilitário
não está na caixa de controle remoto, basta baixá-lo a partir de microsoft.com e enviar -lo.

2.3 bruteforce

Atalho: b

Parâmetros:-w <wordlist> (opcional)

Este modo deve ser utilizado se o utilizador que executa as consultas de não pertencer ao grupo
administrador de sistema (ver modo de impressão digital ). Se este for o caso, precisamos aumentar os
nossos privilégios. Desde usando OPENROWSET podemos fazer o banco de dados alvo conectar-se com
credenciais alternativas, podemos tentar BruteForce a senha 'sa'. Se a senha correta seja encontrada, o
usuário atual é automaticamente adicionado ao grupo sysadmin. Para este ataque funcionar, o SQL Server
remoto deve usar "autenticação mista". Use o modo de impressão digital para verificar se este é o caso.

Este modo de ataque pode usar dois métodos diferentes: "dicionário" e "gradual". Você é livre para usar o
método que melhor se adapte às suas necessidades.

Dicionário
Este método é usado, quando uma lista de palavras é especificado, usando o -w opção. Usando este
método, os possíveis senhas são obtidos a partir da lista de palavras, e cada um é julgado em um pedido
separado. Tenha certeza que sua lista de palavras contém 'sa' ea senha vazia, todos os dois-tempos favoritos
para instalações MS SQL Server.

Prós:

Muito eficaz se a senha é uma palavra do dicionário

Não colocar uma carga pesada sobre o DB Servidor

Contras:

Não é eficaz contra as senhas que não são dicionário baseado. Se a senha não está na sua lista de
palavras, você está fora do jogo

Tem um monte de conexões de rede, de modo que o ataque é muito fácil de detectar, olhando para os
logs do servidor web

Incremental

Este método é usado quando uma lista de palavras não é especificado. Sqlninja apresenta um conjunto de
consultas que tentam * todos * combinações possíveis de caracteres até um determinado período, que é
especificado pelo usuário. O aspecto legal dessa tática é que desde que as consultas são executados no
servidor DB, o bruteforce é realmente realizada utilizando os recursos da CPU do alvo.

Prós:

Extremamente eficaz na busca de senhas que não são baseadas dicionário

Precisa relativamente poucas conexões, por isso há muito poucas entradas nos logs do servidor web

Contras:

Se a senha é longo, pode levar as idades


Pode empurrar o uso da CPU do Servidor DB até 100% durante todo o tempo, o que pode ser perigoso
com uma aplicação ao vivo. Também tenha em mente que os servidores críticos têm alarmes que são
acionados se o uso da CPU permanece muito alta para um determinado período de tempo. Como medida
de segurança, sqlninja divide a tarefa em pequenos pedaços (cada pedaço tentando n ^ 3 senhas, com n
sendo o comprimento do charset usado). Se algo der errado, basta parar sqlninja, eo bruteforce remoto vai
parar no fim do trecho atual

Dependendo de como o aplicativo se conecta ao DB Server, esta técnica pode não funcionar (por
exemplo: ODBC é conhecido por criar problemas). Sqlninja tenta descobrir isso quase que imediatamente e
alerta o usuário, de forma que nenhum tempo precioso é perdido

Notas importantes

A partir do SQL Server 2005, OPENROWSET está desativado por padrão para usuários não-
administrativos. Se o modo de impressão digital lhe disse que você está lidando com SQL Server
2005/2008/2012 e que você não é 'sa', então você provavelmente fora da sorte (mas você ainda pode
extrair dados com o getdata modo

No SQL Server 2000, as senhas são case insensitive, o que simplifica enormemente o trabalho de
craqueamento.

O bit de escalada pode ser afetado se o aplicativo usa ODBC (ver modo de escalada )

2.4 escalada

Atalho: e

Parâmetros:-p <sa password> (obrigatório)

Quando a senha 'sa' correto é especificado, o usuário atual DB é adicionado ao grupo sysadmin.

Em geral, você não deve precisar desse método, como sqlninja cuida da escalada no modo bruteforce já. No
entanto, pode haver casos em que você precisa executar este bit de forma independente (talvez você
descobriu a senha com um ataque de engenharia social).

Se você quer saber como a escalada funciona, ou se você encontrou a senha 'sa', mas a escalada parece não
funcionar, continue lendo. Caso contrário, você pode pular para o modo resurrectxp .
A escalada é feita combinando OPENROWSET, password 'sa' a direita, e sp_addsrvrolemember, adicionando
o usuário atual DB ao grupo sysadmin. É bastante improvável que sp_addsrvrolemember foi desativado,
então o truque deve funcionar muito bem sempre. Se isso não funcionar, pode haver dois casos:

O servidor usa ODBC, e você estiver usando conexões ODBC antigas do pool de conexão, que ainda usam
os velhos privilégios

O procedimento sp_addsrvrolemember foi desativado

No primeiro caso, você pode ter apenas um litro de espera para a conexão ODBC ao tempo limite de idade e
ser descartado: por padrão, uma conexão ODBC é descartado após 60 segundos ociosos, ea chance de um
evento como esse depende de quantos clientes estão se conectando com a aplicação web e como esse
número varia ao longo do tempo.

No segundo caso (ou também no primeiro, se você não quiser esperar), você só precisa especificar o -p <sa
password> parâmetro em todas as etapas do ataque: que vai dizer sqlninja usar OPENROWSET em cada
conexão, executando cada comando como 'sa' e não como o usuário atual.

2,5 resurrectxp

Atalho: x

Parâmetros:-p <sa password> (opcional)

Este modo é para ser usado quando as seguintes condições forem atendidas:

Temos privilégios sysadmin ou sabemos a senha 'sa'

xp_cmdshell foi desativado

O objectivo deste modo é, é claro, para recriar o procedimento prolongado xp_cmdshell. Há um monte de
variáveis que vêm jogar aqui e dependendo deles este modo irá se comportar de maneiras diferentes.
Portanto, leia com cuidado, pois aqui estão as coisas que você deve ter em mente:

Os métodos: existem duas maneiras de obter o xp_cmdshell de volta:

restaurá-lo com um procedimento armazenado (sp_addextendedproc em 2000 SQLServer e


sp_configure em SQLServer 2005). Este método requer um simples comando SQL, mas exige Xplog70.dll
ainda estar lá

criar um personalizado com "CREATE PROCEDURE", sp_oacreate, sp_OAMethod e sp_OADestroy. Este


método requer mais código, mas funciona, não importa se Xplog70.dll foi removido por razões de
segurança.

O nome xp_cmdshell: xp_cmdshell re-habilitação não pode passar despercebida. Ou talvez os


desenvolvedores de aplicativos poderiam ter seguido estritamente o MS recomenda, que é a de filtrar o
"xp_ *" string, sem dizer nada a respeito "sp_ *" (confira http://msdn.microsoft.com/library/en-us/
bldgapps/ba_highprog_11kk.asp ). Nestes casos, pode-se utilizar CRIAR procedimento e um nome mais
discreta (por exemplo: "sp_sqlbackup"). Você pode escolher o nome do procedimento com a opção
xp_name do arquivo de configuração.

Os privilégios do usuário: se a escalação de privilégios não funcionou (ver modo de escalada para as
possíveis razões), então você deve usar o -p <sa password> parâmetro, a fim de usar OPENROWSET para
escalar privilégios em cada ligação, e isso leva para o ponto seguinte

OPENROWSET e CREATE PROCEDURE não podem ser combinados. Portanto, se você estiver usando o -p
parâmetro que você não pode usar o "CREATE PROCEDURE" truque. No entanto, há uma solução: você
pode incluir todo o código do procedimento em cada solicitação que é enviada para o DB Server, sem a
criação de um procedimento estendido a todos. Vamos chamar esse truque "linha de injeção interno."

Dito isto, aqui estão os passos que sqlninja segue quando esse método é usado:

Se o nome do procedimento estendido, especificado no arquivo de configuração, é xp_cmdshell (que é o


valor padrão), então sqlninja começa por tentar reativá-lo com sp_addextendedproc / sp_configure. Você
será solicitado a versão do SQL Server remoto. Se você se esqueceu de usar o modo de impressão digital,
sqlninja vai encontrar esta informação por conta própria. Se essa coisa toda funciona, temos o nosso
xp_cmdshell volta.

Se o nome do procedimento estendido não está definido para xp_cmdshell (talvez porque você quer ser
mais sorrateira) no arquivo de configuração, ou o passo n º 1 falhou (por exemplo: porque Xplog70.dll foi
removido), então:

se temos privilégios de administrador nativas (o que significa que não tem que especificar a senha na
linha de comando) o método CREATE PROCEDURE é tentada. Se ele funciona, temos o nosso procedimento
personalizado, o que temos chamado ele

se não temos privilégios de administrador nativos (ou seja, tivemos que especificar a senha na linha de
comando), a linha de injeção procedimento é tentado. Se funcionar, então você terá que definir xp_name
para NULL no arquivo de configuração. Isto irá dizer sqlninja usar a linha de injeção procedimento em todas
as etapas subseqüentes

Espero que seja claro. Se for, você não deve ter nenhum problema em ter de volta o seu xp_cmdshell (ou
algo perfeitamente equivalente) em quase todas as situações. Se não está claro, eu tenho medo que você
vai ter que ler a coisa toda de novo.

Nota: o código usado por sqlninja para o procedimento personalizado é uma ligeira modificação do código
de Antonin Foller, que você pode encontrar no endereço http://www.motobit.com/tips/detpg_cmdshell/

2.6 enviar

Atalho: u

Parâmetros:-p <sa password> (opcional)

Parameterd:-g (opcional)

Este modo upload de um arquivo binário usando apenas GET ou POST solicitações HTTP para o servidor
web, de forma que nenhum FTP / TFTP ou qualquer outra conexão é necessária. O arquivo é enviado para o
diretório especificado pelo do servidor %TEMP% variável, de modo que o ataque funciona mesmo quando
MSSQL não pode escrever no diretório default (o que parece ser, por vezes, o caso com MSDE). Existem dois
métodos de upload disponíveis, controladas pela upload_method opção:

script de depuração: Este método é o tradicional, e usa o velho DEBUG.EXE depurador 16bits. O arquivo
binário é codificado como um script debug ( .scr extensão), o script é carregado e alimentado para o
depurador. O script basicamente aloca uma área de memória, grava os bytes necessários, e salva o
resultado em disco. Sendo um depurador 16bits há, obviamente, uma limitação de 64k bytes no tamanho,
mas sqlninja ignora-lo dividindo o executável original, em pedaços de bytes 64k, enviá-las separadamente,
e, finalmente, fundindo-los juntos. Sqlninja usa o mesmo algoritmo usado em grande dbgtool.exe de Jussi
(que você pode encontrar no http://www.toolcrypt.org endereço) que é capaz de criar scripts muito
compactas.

VBScript: Este é o novo método: basicamente, ele codifica o arquivo binário em formato base64, carrega-
lo e, em seguida, alimenta-lo para um pequeno decodificador vbscript previamente carregado. Em média
ele usa menos pedidos, ele não precisa dividir o arquivo original, e tem maiores chances de trabalhar em
sistemas recentes. Portanto, embora o método antigo é muito mais frio com o truque debug e tudo mais,
você provavelmente deve usar apenas um presente.

Não importa o método que você escolher para o upload, você será solicitado a informar o nome do arquivo
para fazer o upload e as coisas vão ser totalmente automatizado. Se o arquivo parece já estar em .scr ou
.base64 formato, sqlninja irá realizar o upload de qualquer jeito, mas algumas verificações (por exemplo: o
arquivo binário carregado tem o tamanho correto), não será possível. Em geral, é sempre melhor fornecer
sqlninja com o binário original.
Para seu conforto, netcat.exe, dnstun.exe, icmpsh.exe, churrasco.exe, vdmallowed.exe e vdmexploit.dll já
estão disponíveis nos apps e scripts diretórios, respectivamente em binário e debug + formato base64. Os
executáveis foram embalados com UPX de modo a minimizar o seu tamanho (e o tempo de carregamento).
Você precisa fazer o upload netcat a usar backscan / dirshell / revshell, enquanto dnstun.exe e icmpsh.exe
são usados para criar um túnel pseudoshell DNS e ICMP, respectivamente. Churrasco.exe usado para tentar
uma escalada de privilégios via seqüestro sinal se o SQL Server não está executando como SYSTEM.
Vdmallowed.exe e vdmexploit.dll tentar o mesmo ataque usando CVE-2010-0232.

Tenha em mente que muitas coisas podem dar errado aqui: se uma única linha do arquivo codificado não
são enviados, o executável não será gerado corretamente. Portanto, no final do sqlninja processo verifica se
o arquivo executável está lá, e se não for ele também tenta descobrir quantas linhas foram carregados: deve
fornecer algumas dicas sobre o que deu errado. Por exemplo, durante um teste de caneta descobriu-se que
o número resultante de linhas era exatamente o dobro do valor correto, o que significa que cada consulta
injetado foi executado duas vezes. O truque era criar uma tabela temporária que atuou como um contador,
acrescentando a linha para o arquivo de script somente quando o contador foi mesmo.

Se você só deseja gerar o script de depuração ou o arquivo base64 sem enviá-lo (por exemplo, para usá-lo
com alguma outra ferramenta), inicie o modo de upload com o -g opção e sqlninja irá gerar o arquivo no
/tmp diretório e sair. É necessário especificar o parâmetro de senha quando você não tem privilégios
sysadmin nativas (ver modo de escalada ).

2.7 dirshell

Atalho: s

Parâmetros:-p <sa password> (opcional)

Utilize este método quando o DB servidor remoto é acessado diretamente em alguma porta TCP ou UDP.
Sqlninja pede a porta remota, o protocolo, diz o servidor DB para ligar um rápido a essa porta de comando
e, em seguida, inicia a conexão. Claro, netcat deve ter sido carregado no servidor remoto. O parâmetro
password é para ser usado quando não temos privilégios sysadmin nativas (ver modo de escalada ).

2.8 backscan

Atalho: k

Parâmetros:-p <sa password> (opcional)

Tipicamente, quando o DB Server está atrás de um firewall que não é possível entrar em contato com ele
diretamente. No entanto, pode ser possível que o servidor tem permissão para acessar o mundo exterior
em alguma porta (por exemplo: DNS, HTTP). Esse modo conta a DB Server para enviar pacotes SYN ou
pacotes UDP para a nossa máquina em um intervalo de portas, a fim de olhar para aquele que é permitido.
Sqlninja irá informar ao usuário se os pacotes são recebidos e em qual porta (s).

Você precisa especificar, no arquivo de configuração, o endereço IP da sua máquina ( parâmetro lhost ) ea
interface para escutar ( parâmetro dispositivo ). Sqlninja irá perguntar-lhe sobre o protocolo a ser usado
(TCP / UDP) e para os portos, que devem ser especificados com a sintaxe netcat comum (por exemplo: "23
25 80-100" vai tentar portas 23, 25 e todas as portas entre 80 a 100). O parâmetro password é para ser
usado quando não temos privilégios sysadmin nativas (ver escalada ). Para usar este modo, netcat deve ter
sido carregado em primeiro lugar, e uma vez que as bibliotecas pcap precisam ser usados também precisa
ser root.

2.9 revshell

Atalho: r

Parâmetros:-p <sa password> (opcional)

Se um shell direta não é possível, mas o modo backscan encontrado uma porta aberta do DB Server para
nossa máquina, em seguida, um shell reverso é possível. Ao utilizar este modo, sqlninja pede a porta local, o
protocolo e, em seguida, inicia a conexão. Você precisa especificar, no arquivo de configuração, o endereço
IP da sua máquina ( parâmetro lhost ). Claro, netcat deve ter sido carregado no servidor remoto. Como de
costume, o parâmetro password é para ser usado quando não temos privilégios sysadmin nativas (ver modo
de escalada ).

2.10 icmpshell

Atalho: i

Parâmetros:-p <sa password> (opcional)

Quando não há shell direta ou inversa são permitidas pelo firewall, mas o DBMS remoto pode pingar nossa
caixa, podemos túnel nosso shell em um túnel ICMP. Apenas carregar icmpsh.exe, iniciar o modo icmpshell,
e desfrutar do seu shell. Todo o tráfego de e para o DBMS remoto será encapsulado através de pacotes
ICMP.

Ao iniciar este modo de ataque, sqlninja pedirá as seguintes informações:


Tamanho do buffer de dados: a quantidade de dados que será encapsulado em um único pacote ICMP. O
padrão é de 64 bytes, mas você pode usar valores maiores para obter um túnel mais rápido. Só tome
cuidado com o MTU máximo (Maximum Transfer Unit) entre você eo DBMS. Um valor até 1300-1400 bytes
deve ser considerado, pelos padrões de hoje, bastante confiável. Use pacotes menores, se você quiser jogar
pelo seguro

Enviar atrasar: a quantidade de tempo entre contíguos solicitações de eco ICMP. O padrão é 300
milisegundos, mas você pode usar valores mais baixos para obter um túnel mais rápido. Tenha em mente
que um valor muito baixo pode gerar uma inundação de ping que pode ser notado, ou automaticamente
estrangulado baixo por algum dispositivo anti-DoS entre você e seu alvo.

Tempo limite de resposta: a quantidade de tempo que será esperado por icmpshell.exe antes de re-envio
de um pedido ICMP. O padrão é 3000 milissegundos

Importante: certifique-se de que sua caixa está configurado para não responder às solicitações de eco ICMP.
Por exemplo, no Linux o seguinte comando fará o truque:

sysctl -w net.ipv4.icmp_echo_ignore_all=1

2.11 dnstunnel

Atalho: d

Parâmetros:-p <sa password> (opcional)

Quando não há shell direta ou inversa são permitidas pelo firewall, ea shell ICMP não quer trabalhar,
podemos tentar estabelecer um túnel DNS. As únicas exigências são:

O servidor de banco de dados deve ser capaz de resolver nomes de hosts externos (que é muitas vezes o
caso)

Nosso IP deve ser o servidor DNS com autoridade de algum domínio (você pode comprar um para alguns
dólares). Usaremos sqlninja.net no nosso exemplo

Se se verificarem ambas as condições, fazer o upload dnstun.exe, iniciar o modo dnstunnel, e lançar seus
comandos. O que acontece é mais ou menos a seguinte:

O comando é passado via SQL Injection para dnstun.exe (que atua como o agente remoto) e é executado
pelo DB servidor remoto. A saída é interceptada e codificado num ligeiramente modificado Base32 formato

A saída codificada é dividida numa série de nomes de máquinas de que o domínio de controlo (por
exemplo: encoded_output.sqlninja.net )

Esses nomes de host são passados para gethostbyname() , de modo que os contatos do servidor de banco
de dados o seu Servidor DNS para resolvê-los

O servidor DNS procura o servidor autoritário de sqlninja.net (nosso IP) e encaminha as solicitações para
o nosso posto de trabalho

sqlninja recebe as solicitações, re-ordena-lhes, se necessário, decodifica os nomes de host e finalmente


imprime a saída do comando. Claro, sqlninja também responde às solicitações de DNS (com um endereço
de IP falso), a fim de fazer gethostbyname() retornar rapidamente.

Todo o processo é transmitido, o que significa que, se a saída do comando é muito tempo você vai começar
a ver a sua saída antes que o comando tenha terminado.

O domínio utilizar deve ser especificado no arquivo de configuração . Claro, desde que sqlninja deve criar
um servidor DNS falso e porta de ligação 53, você precisa de privilégios de root para usar este modo. Tenha
em mente que o DNS usa UDP, por isso a perda de pacotes pode ser um problema, aqui.

A versão executável do agente foi compilado com Msys . Como sempre, o parâmetro password é para ser
usado quando não temos privilégios sysadmin nativas (ver modo de escalada ).

2.12 Metasploit

Atalho: m

Parâmetros: Nenhum

Não está satisfeito com um prompt de DOS simples? Quer impressionar seus amigos com um acesso
completo GUI? Se você tiver privilégios administrativos, xp_cmdshell obras e de ter encontrado uma porta
TCP permitido (entrada ou saída), você também pode usar sqlninja como um wrapper para Metasploit, para
usar Meterpreter ou injetar um servidor VNC. Pense Meterpreter como um prompt do DOS, mas muito
mais potente, proporcionando-lhe um controle quase completo sobre o sistema operacional remoto,
incluindo o acesso imediato aos hashes de senha, a possibilidade de alterar as tabelas de roteamento,
realizar o encaminhamento de porta e até mais. Alternativamente, se você tem banda suficiente, você
também pode injetar um servidor VNC e estar equipados com um bom acesso gráfico ao banco de dados
remoto.
Este modo de ataque é totalmente automatizado, e em poucas palavras aqui está o que acontece:

Sqlninja pede que você especifique se você quer usar Meterpreter ou VNC, se a ligação será direta ou
inversa, eo host / port para conectar-se (ou porta local para se ligar, no caso de uma conexão reversa)

Sqlninja chamará msfpayload para criar um executável apropriado que irá funcionar como um encenador

Sqlninja então convertê-lo em um script de depuração e enviá-lo

Desde que terá de injetar uma DLL, que talvez seja necessário desativar a Prevenção de Execução de
Dados (aka 'DEP ", ativado por padrão a partir do Windows 2003 SP1) na caixa remoto. As versões recentes
do Metasploit lidar com este bit automaticamente, mas você também pode dizer sqlninja vai tentar fazê-lo
para você, acessando o registro e whitelisting nosso executável (ver o checkdep parâmetro)

Finalmente, Sqlninja chamará msfcli para injetar a DLL necessário e completar a exploração

Você pode assistir a uma demonstração de flash deste ataque no site da sqlninja.

Claro que, para usar este modo de ataque que você precisa ter Metasploit3 disponível em seu caixa. Se
executáveis Metasploit (nomeadamente msfpayload , msfcli e msfencode ) não estão em seu caminho, você
pode especificar sua localização absoluta no arquivo de configuração. Além disso, se você usar o modo VNC,
certifique-se de ter um cliente VNC instalado.

2.13 sqlcmd

Atalho: c

Parâmetros: Nenhum

Às vezes, mesmo que tenhamos privilégios sysadmin e obras xp_cmdshell, ainda não é possível obter um
shell, talvez porque o executável não upload, ou porque as portas são todas filtradas e resolução de DNS
externo não é permitido. Nestes casos, pode ainda ser útil para emitir comandos individuais para o servidor
DB, mesmo sem ser capaz de ver a saída. Por exemplo, você pode querer adicionar um usuário local (talvez
você possa RDP para a caixa), ou um usuário de domínio, se o SQL Server é executado com privilégios (sim,
isso acontece com mais frequência do que seria de esperar). Nesses casos, você pode usar este modo: basta
digitar um comando DOS e deixe sqlninja executá-lo remotamente. Apenas lembre-se: ele é executado,
mesmo que você não vê sua saída.

Claro, você ainda pode usar o tempo para saber o que está acontecendo:
if exist filename (ping -n 5 127.0.0.1)

Se o comando leva cerca de 5 segundos para executar, o arquivo está lá.

Para saber se um comando bem sucedido, também verificar o valor da variável ERRORLEVEL, que
normalmente é definido como 0 se o último comando não produziu um erro. Assim, por exemplo, se
queremos saber se o controle remoto do SQL Server está sendo executado como SYSTEM, podemos usar o
seguinte comando:

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

Se o comando leva cerca de 5 segundos para executar, você sabe que o SQL Server está sendo executado
como SYSTEM ( whoami.exe é instalado por padrão no Windows 2003 e pode ser encontrado no Windows
2000 se o Resource Kit foi instalado). Atualize suas habilidades DOS-shaolin e usar a sua fantasia: de
acrescentar comandos AUTOEXEC.BAT para iniciar / parar serviços e adição de usuários desonestos, você
pode ficar muito longe com isso!

Este modo também pode ser útil quando algum outro modo de falha, a fim de entender o que deu errado e
como corrigir o problema. Finalmente, este comando também é muito útil para mostrar a um cliente que
pertence o servidor DB, mesmo que você não conseguiu o shell:

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

2.14 getdata

Atalho: g

Parâmetros:-s <filename> (opcional)

Vamos começar por salientar que esta ainda é muito experimental, é provável que contêm mais bugs do
que a beta Win95, e, portanto, você não deve esperar sua confiabilidade para ser à prova de bomba. Com
isso fora do caminho, vamos ao que interessa: este módulo é 100% interativo, por isso deve ser bastante
intuitivo. Sqlninja atualmente suporta dois canais de extração, tempo e baseados em DNS, descrito abaixo.
Time-base

Este canal é usado quando data_channel está definido para time no arquivo de configuração, e usa o
comando lento, mas confiável ATRASO WAITFOR para extrair informações. Sqlninja podem explorar injeção
com base no tempo de duas maneiras, detalhados nos parágrafos seguintes.

Busca binária baseada no tempo

Este método é ativado quando data_extraction está definido para binary no arquivo de configuração. Se
você é mesmo marginalmente em computadores, você deve saber como um binário algoritmo de busca
funciona, por isso não estou indo para ficar muito em detalhes aqui. Basicamente, este método minimiza o
número de solicitações para o aplicativo, o que o torna útil se você quiser manter sua pegada ao mínimo.
Contudo, cerca de metade das consultas irá desencadear um atraso, o que significa que este método pode
não ser o mais rápido.

Pesquisa serial / otimizado com base no tempo

Este método é ativado quando data_extraction está definido para optimized (padrão) ou serial no arquivo
de configuração. Com este método, todos os possíveis valores são julgados em seqüência até que o
caminho certo é adivinhado. A diferença entre a serial e optimized é da ordem das tentativas: enquanto a
primeira apenas tenta todos os valores após o seu valor ASCII, este último começa com os valores mais
comuns. A ordem exata é especificada com a language_map parâmetro, e essa ordem é modificado em
tempo real, adaptando-se a frequência real de personagens sendo extraídas, se o language_map_adaptive
parâmetro é definido como a yes .

Extração baseada em DNS

Você tem controle sobre um domínio ou subdomínio DNS? Você pode obter servidores de DNS para filmar
"tipo A" pedidos para a sua caixa? Será que o DBMS remoto resolver nomes externos? Se assim for, você
pode esquecer que a extração lenta baseada em inferência e começar a puxar dados quase à velocidade da
luz (bem, relativamente falando). Certifique-se de executar sqlninja como root, conjunto domain no arquivo
de configuração, e você está pronto para ir.

Informações adicionais
Por padrão, sqlninja armazena todas as informações extraídas de um banco de dados SQLite local, cujo
nome é especificado através da linha de comando com o -s parâmetro. O nome padrão é session.db . Para
todos os outros parâmetros e detalhes, consulte as opções de extração de dados .

2,15 Outros ataques

Muitas vezes, o SQL Server não é executado como sistema, mas como um usuário menos privilegiado
(muitas vezes "Serviço de Rede"). Isso cria limitações no que o atacante pode fazer (por exemplo: extrair os
hashes de senha). Ele também cria problemas com a injeção VNC, fazendo com que uma tela preta a ser
retornado. No entanto, com sqlninja podemos tentar escalar privilégios de sistema, usando duas técnicas de
ataques diferentes.

CVE-2010-0232

Se o SQL Server é executado como um usuário com poucos privilégios, ea máquina não é remendado contra
CVE-2010-0232, podemos tentar elevar seus privilégios de SYSTEM. Navios Sqlninja com uma versão do
exploit original, Tavis Ormandy, que foi especialmente personalizado: enquanto o exploit originais gera um
prompt do DOS, a nossa versão olha para o processo de sqlservr.exe e obriga a correr como sistema. Para
lançar o ataque, são necessários os seguintes passos:

Envie vdmallowed.exe e vdmexploit.dll , que estão disponíveis no apps diretório em formato executável e
na scripts diretório (em formato de script debug)

Usando o modo de ataque sqlcmd , execute o seguinte comando: %TEMP%\vdmallowed sql

Se o ataque foi bem sucedido, o modo de impressão digital deve dizer-lhe que o SQL Server está sendo
executado como SYSTEM

Símbolo de seqüestro

No Windows 2003, podemos também tentar escalar nossos privilégios usando seqüestro forma, uma
técnica pesquisada por Cesar Cerrudo . Como prova de conceito que ele desenvolveu churrasco.exe , que
está incluído no tarball sqlninja em uma versão ligeiramente modificada. Se você precisa escalar para
SISTEMA simplesmente enviá-lo para o servidor remoto usando o upload modo e, em seguida, definir o
usechurrasco opção de yes : todos os comandos, então, ser envolvido com churrasco.exe. Tenha em mente
que isso não vai funcionar se o controle remoto DBMS foi corrigido em relação ao ataque, mas você pode
verificar se as coisas estão funcionando usando o modo de impressão digital quando esta opção estiver
ativada.

Importante: não se esqueça de usar a versão modificada do churrasco (sim, a do tarball sqlninja), ou as
coisas são propensos a quebrar. Você pode ver as diferenças entre a fonte de C no sources do diretório, mas
basicamente eles se resumem a:

Sem saída detalhada a menos que o -d opção é usada. Saída detalhada iria interferir com a opção 5 do
modo de impressão digital, que utiliza uma tabela temporária para armazenar os resultados de uma
execução churrasco.exe.

CreateProcessAsUser() é chamado, passando o diretório%% original (sem privilégios) do usuário TEMP


como o lpCurrentDirectory parâmetro, que é o lugar onde nossos arquivos executáveis (por exemplo:
netcat) são enviados (e não no diretório% TEMP% do sistema).

3. arquivo de configuração

O arquivo de configuração (padrão: sqlninja.conf ) controla a maior parte do comportamento sqlninja.


Todas as opções estão sob a forma:

option_name = option_value

A única exceção é httprequest , que define a solicitação HTTP e do ponto de injeção e que se estende por
várias linhas (veja abaixo).

As opções podem ser divididos nas seguintes categorias:

Básico : usado para configurar o ataque

Extração de dados : usado para configurar o modo de extração de dados

Avançada : usado para o ajuste fino adicional

As opções são, na maioria das vezes, maiúsculas e minúsculas (por exemplo, valores de URL). A mesma
opção pode ser usada várias vezes: sqlninja não se importa e simplesmente usar a última declaração,
substituindo os anteriores. Comentários são permitidos em qualquer lugar exceto entre
--httprequest_start-- e --httprequest_end-- (veja abaixo), e são precedidas por caractere '#'. Uma breve
recapitulação do que se segue, também pode ser encontrado em sqlninja.conf.example .

3.1 Opções básicas

httprequest
A partir da versão 0.2.6, sqlninja utiliza uma nova forma de configurar a solicitação HTTP ea seqüência de
injeção relativo. Em vez de parâmetros separados para host, porta página, o método HTTP, corda exploração
e cabeçalhos adicionais, toda a solicitação HTTP é especificado de uma vez, com um marcador (por padrão
__SQL2INJECT__ ) que indica onde os comandos SQL precisa ser injetado. Isso simplifica muito as coisas e,
mais importante permite total liberdade em onde o vetor de injeção pode ser: agora você não está limitado
a um parâmetro GET ou POST, mas você pode injetar sempre que você precisar (por exemplo: em um
cookie). Sqlninja irá considerar que a solicitação HTTP tudo o que está incluído entre as linhas
--httprequest_start-- e --httprequest_end-- .

Em geral, os seguintes elementos devem ser compreendidos

O método HTTP (geralmente POST ou GET)

A URL completa para os recursos, incluindo ou

O porto, se não padrão (ex.: http://www.victim.com:8080 )

A versão HTTP

Todos os cabeçalhos necessários

O corpo depois de uma linha em branco, se o pedido usa POST

Em geral, a melhor estratégia é simplesmente usar um proxy (por exemplo Burpsuite) para interceptar a
solicitação que aciona o SQL Injection e copiá-lo para sqlninja.conf

Por exemplo, uma injeção baseada em texto simples sobre HTTP GET será parecido com o seguinte:

- Httprequest_start -

GET http://www.victim.com/page.asp?string_param=aaa '; __SQL2INJECT__ & other_param = blá


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: pt-br, en, q = 0,7, que, q = 0,3

Accept-Charset: ISO-8859-15, UTF-8, q = 0,7, *, q = 0,7


Connection: close

- Httprequest_end -

Alternativamente, uma injeção à base de POST HTTPS provavelmente será parecido com o seguinte
(observe o cabeçalho Content-Type ea linha vazia entre os cabeçalhos e corpo):

- 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: pt-br, en, q = 0,7, que, q = 0,3

Accept-Charset: ISO-8859-15, UTF-8, q = 0,7, *, q = 0,7

Content-Type: application / x-www-form-x urlencoded

Cookie: ASPSESSIONID = xxxxxxxxxxxxxxxxxxxx

Connection: close

numeric_param = 12; __SQL2INJECT__

- Httprequest_end -

Note que o cabeçalho Content-Length não está incluído: sqlninja irá calcular o valor adequado e adicionar o
cabeçalho automaticamente.

Finalmente, uma injeção baseada em cookie será parecido com o seguinte:

- 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: pt-br, en, q = 0,7, que, 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 -

Note-se como o ponto e vírgula após o apóstrofo foi codificado em% 3B: isso é porque de outra forma o
servidor iria analisar o ponto e vírgula como separador entre diferentes cookies.

Antes da __SQL2INJECT__ marcador, você precisa incluir tudo o que é necessário para fechar a consulta
original e começar um novo, como o parâmetro de vulnerável e a seqüência de caracteres que nos permite
começar a injetar comandos. Isto significa geralmente, pelo menos:

o parâmetro de vulnerável (nome valor +)

aspas simples (se o parâmetro é uma string)

um ponto e vírgula (para acabar com a consulta original)

Ele também deve incluir tudo o que é necessário para fechar corretamente a consulta original, como um
número adequado de suportes finais. Por exemplo, se quer injetar o seguinte comando TSQL:

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

a solicitação HTTP no arquivo de configuração deve conter o seguinte:

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

Coisas importantes para lembrar:

Em geral, uma boa técnica é replicar o mais próximo possível da solicitação HTTP que você usou
originalmente para detectar a falha de SQL Injection (com um navegador web ou outra ferramenta), como
em alguns casos extremos de cabeça ligeiramente diferente pode fazer uma grande diferença . A única
modificação sugerida e normalmente é seguro para utilizar HTTP/1.0 para evitar problemas com as
conexões permanecendo aberta

A fim de dar-lhe pleno poder e flexibilidade na elaboração de seu exploit, sqlninja não tenta interferir de
forma alguma: isso significa que ele não irá modificar o seu pedido HTTP (para além do código para injetar
onde o marcador é, obviamente), mas isso também significa que ele não vai tentar corrigir a sua sintaxe,
verifique se o seu pedido HTTP está correta (incluindo todos os necessários URL-encoding). Para mais
informações, consulte o RFC 1945, RFC 2068 e RFC 2616.

Às vezes, você também pode precisar de adicionar um pouco mais de código SQL após a consulta injetado
(e, portanto, após o marcador). Normalmente, isso não é necessário, uma vez que sqlninja simplesmente
anexa dois hífens e comentários fora do restante da consulta original, mas há alguns casos (raros) em que
você precisa anexar código SQL adicional para as consultas em lote para funcionar corretamente. Neste
caso, não se esqueça de também definir appendcomment = no , caso contrário, os dois hífens será anexado
eo código SQL especificado aqui será considerado um comentário

Se você está injetando em um cookie, e você precisa de um ponto e vírgula para fechar a consulta
original, lembre-se codificá-lo (% 3B), caso contrário, será analisado como o fim do valor do cookie

Não deixar espaços no início de cada linha!

Não deixe linhas de comentário! Eles seriam analisados como parte do pedido!

Finalmente, se você não especificar a porta para conectar, sqlninja assumirá 80 para HTTP ea 443 para
HTTPS

proxyHost

Um proxy HTTP para se conectar ao host de destino, se necessário. Por exemplo:

proxyhost = 192.168.1.233

proxyPort

A porta do proxy HTTP que conectar. O padrão é 8080. Por exemplo:

proxyport = 3128
domínio

Domínio ou subdomínio controlado do atacante para ser usado com o modo dnstunnel e modo de extração
de dados baseado em DNS. O endereço IP do qual sqlninja é lançado deve ser o servidor DNS com
autoridade para esse domínio. Por exemplo:

domain = sqlninja.net

msfpath

O caminho absoluto para executáveis Metasploit ( msfpayload e msfcli ). Você não precisa disso, se eles já
estão em seu caminho padrão. Por exemplo:

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

evasão

Sqlninja pode usar algumas técnicas de evasão, a fim de confundir e desviar IPS / IDS baseado em
assinatura. Atualmente, quatro técnicas são implementadas, que podem ser livremente combinadas entre
si:

Consulta hex-encoding: a consulta é hexadecimal codificado antes de ser executado

Comentários como separadores: todos os espaços são substituídos pela seqüência /**/

Caso aleatório

Codificação URI aleatória

A primeira técnica é particularmente útil. Por exemplo, se queremos injetar o seguinte comando:

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

A consulta real será:


declare @a varchar(8000) set
@a=0x65786563206d61737465722e2e78705f636d647368656c6c2027636d64202f432070696e672031323
72e302e302e31273b exec (@a)

A muito tempo string, mas observe o seguinte:

Não há comandos SQL, exceto declarar e EXEC, então bye-bye IPS está procurando por xp_cmdshell e
afins

Sem aspas simples também! Esta técnica de evasão é, portanto, extremamente útil se você encontrar um
parâmetro numérico vulnerável e aspas simples são filtrados

Como mencionado, você pode combinar todas as técnicas em conjunto com a seguinte opção:

evasion = 1234

Isso irá gerar um código bastante enigmática, como a seguinte:

%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

Como padrão, sqlninja define evasion de zero, e nenhuma técnica de evasão será usado.

Importante: evite usar ofuscação desnecessária se você estiver usando requisições GET, pois isso pode levar
a URLs que são muito longos e que não são analisados com sucesso pelo servidor web!

msfencoder

O codificador para usar o encenador Metasploit. Se não for especificado, nenhuma codificação é executada.
No entanto, um bom encoder é sempre recomendável. Por exemplo:
msfencoder = x86/shikata_ga_nai

upload_method

O método a utilizar para fazer upload de arquivos binários. Os valores possíveis são debug ou vbscript
(padrão). Por exemplo:

upload_method = vbscript

3.2 opções de extração de dados

data_channel

O canal a usar para extrair dados. Pode ser time (padrão) para usar um canal de extração baseado WAITFOR
(muito lento, mas sempre funciona) ou dns (muito mais rápido, mas você precisa para controlar um domínio
ou subdomínio a ser resolvido para o seu endereço de IP público, por exemplo.:

data_channel = time

data_extraction

Ao utilizar extração baseado em tempo, existem três métodos de extração possíveis. Ao escolher binary ,
sqlninja irá executar uma busca binária, minimizando o número de pedidos. Ao escolher serial , sqlninja vai
tentar todos os valores possíveis, o que provavelmente será mais rápido (desde WAITFOR será acionado
apenas uma vez), mas vai deixar mais entradas nos logs remotos. Ao escolher serial_optimized , sqlninja vai
tentar todos os valores possíveis, a partir da maioria dos prováveis candidatos. O padrão é serial_optimized

language_map

Se você estiver usando extração baseado em tempo e você tiver selecionado serial_optimized como
método de extração, você pode especificar um mapa de linguagem onde você pode especificar as ordens de
caracteres que devem ser experimentadas quando a extração de dados. Você pode encontrar alguns mapas
pré-definidos em lib / langs, onde incluídos mapas para Inglês, Francês, Italiano, Alemão, Espanhol e
Português. Tais mapas são baseados na frequência carta nos respectivos idiomas e incluem também um
espaço em branco e alguns caracteres de pontuação comuns. Se você precisa de um mapa personalizado,
basta listar os caracteres em uma única linha. Você não precisa especificar todos os caracteres possíveis: os
que não estão no mapa será simplesmente tentou se nenhum dos queridos especificadas é bem sucedida.
Por exemplo:

language_map = lib/langs/en.maps

language_map_adaptive

Ao usar uma extração de serial-otimizada, sqlninja pode usar uma abordagem adaptativa: basicamente,
cada personagem no mapa de linguagem é dado um "peso" e cada vez que um personagem é extraído com
sucesso pelo banco de dados remoto, o peso do personagem na língua mapa é aumentado em um. Quando
o peso do caracter na posição N é maior do que o peso do carácter na posição N-1, os seus lugares são
comutadas no mapa em si, de modo que o carácter com maior peso (que é, por conseguinte, mais
frequente) serão tentadas primeiro ao extrair seguintes caracteres. Os valores aqui são ou yes ou no , mas,
em geral, você deve sempre manter yes para obter melhores resultados. Por exemplo:

language_map_adaptive = yes

store_session

Por padrão, sqlninja armazena todas as informações extraídas de um banco de dados local SQLite,
especificado através da linha de comando (padrão: session.db). Isso permite que você salve todos os dados
extraídos localmente e para recuperá-lo em um momento posterior. Em geral, deixar isso para yes . Por
exemplo:

store_session = yes

sanity_check

Ao utilizar extração baseado em tempo, a latência da rede pode limitar a precisão se extraíram os dados.
Sqlninja pode verificar a exatidão das informações extraídas (atualmente DBs, usuários, tabelas, colunas,
mas não linhas ainda) e tente extrair o mesmo tipo de informação, se for detectado um problema. A
verificação envolve apenas uma consulta, é realizada no final da extracção de toda uma série (por exemplo,
um nome da coluna), e utiliza um WAITFOR que é executado apenas se a informação estiver errada. Por
isso, a verificação tem um impacto no desempenho muito limitado. Em geral, deixar isso para yes . Por
exemplo:
sanity_check = yes

3.3 Opções avançadas

lhost

Os endereços IP ou o nome que o alvo deve tentar entrar em contato em backscan e modo revshell. Isso é *
o * máquina. Claro que, se o ataque é realizado através da Internet, este deve ser um endereço público. Por
exemplo:

lhost = tester.sqlninja.net

dispositivo

O dispositivo a ser usado para farejar pacotes quando no modo backscan (default: eth0). Por exemplo:

device = ppp0

filtrar

A expressão pcap válido para filtrar os pacotes de entrada no modo backscan. Por padrão, ao executar tal
ataque, sqlninja escuta de pacotes vindos do endereço IP do servidor web remoto e direcionado para o host
especificado no lhost . Isso pode não funcionar em todos os casos: por exemplo, as conexões de saída do
servidor de DB poderia ser NAT para um endereço IP, que é diferente do endereço IP do servidor web.
Portanto, é preciso substituir o filtro pcap padrão com este parâmetro, por exemplo, indicando toda a sub-
rede pública do alvo. Você só precisa especificar hosts / redes aqui, como os detalhes de protocolo (por
exemplo: flags TCP) são manipulados por sqlninja. Por exemplo:

filter = src host nat.victim.com

tempo limite
Este parâmetro é usado quando em modo backscan. Ele especifica quantos segundos para esperar por mais
pacotes após a solicitação web foi concluído (padrão: 5 segundos). Isto é especialmente útil quando
especificar uma gama muito grande de portas para digitalizar, porque o pedido web pode tempo limite
antes netcat foi concluída. Neste caso, você deve aumentar este valor. Por exemplo:

timeout = 30

No entanto, para tentar evitar intervalos de portas muito grandes: melhor dividir o trabalho em vários
scans.

hostnamelength

Comprimento máximo de FQDN dos hostnames falsos que o alvo vai tentar resolver no modo dnstunnel.
RFCs estado que 255 caracteres é o limite, mas eu esbarrei em alguns servidores de DNS que se recusaram
nomes com mais de 253. O valor padrão é 250, portanto, que deve ser aceito por todos os servidores DNS,
e ao mesmo tempo manter uma velocidade túnel quase ideal. O valor mínimo é 40. Máxima é, obviamente,
255. Por exemplo:

hostnamelength = 250

Você também pode ajustar este parâmetro para os valores mais baixos quando você pensa que as
solicitações de DNS muito longos pode ser manchado. Claro, os valores mais curtos significam um túnel
mais lento. Se tiver dúvidas, deixe o valor padrão.

msfencodecount

O número de vezes que o stager devem ser codificados. O padrão é 5. Por exemplo:

msfencodecount = 8

usechurrasco

Esta configuração é usada para escalar privilégios através de seqüestro sinal . O padrão desta configuração é
no . Por exemplo:
usechurrasco = yes

resolvedip

No modo dnstunnel, o endereço IP que é enviado de volta para cada pedido DNS (desde que não queremos
gethostbyname () para pendurar). Em geral, é aconselhável definir isso para 127.0.0.1 (que é o padrão),
para evitar o tráfego de rede espúrio gerado após o DBMS remoto recebe uma resposta de DNS falso.

resolvedip = 10.255.255.254

xp_name

Nome do procedimento estendido que executa nossas ordens. O padrão é obviamente xp_cmdshell . Este
parâmetro é utilizado de duas formas diferentes, dependendo do modo actual ataque:

resurrectxp: xp_name contém o nome do processo de alargado a ser criado. Se você acredita que re-
habilitar xp_cmdshell pode ser manchado, use outro nome aqui (por exemplo: sp_sqlbackup )

todos os outros modos: o nome do procedimento estendido para uso. Escusado será dizer que devem ser
o mesmo nome anteriormente utilizadas com o modo resurrectxp.

xp_name pode ser definido como NULL para usar a técnica de injeção procedimento inline (ver resurrect_xp
modo para mais detalhes). Por exemplo:

xp_name = sp_sqlbackup

blindtime

O valor para as chamadas ATRASO WAITFOR que são usados na impressão digital e bruteforce modos para a
injecção à base de inferência. O valor padrão é de 5 segundos, mas isso pode ser muito baixa para
servidores muito lento e levar a resultados errados. Se isso acontecer, tente aumentar esse valor. Por outro
lado, se o tempo de resposta do servidor é muito curta, você pode definir um valor mais baixo para fazer as
coisas mais rápido (mínimo: 3). Por exemplo:
blindtime = 4

Se você não tem nenhuma pista sobre o que baseada em inferência injeção meio, desfrutar de algum
tempo na seção de fundo .

lines_per_request

Com este parâmetro, você pode controlar quantas linhas do script debug são enviados em um único pedido.
Um valor mais alto significa, obviamente, um carregamento mais rápido, mas pode ser arriscado, se você
usar requisições GET, já que a URL pode se tornar muito longo. O padrão é 10 eo máximo é 30. Exemplo:

lines_per_request = 15

errorString

Sqlninja alerta o usuário quando um código de erro HTTP é recebida (por exemplo: 500 Server Error), mas
algumas aplicações voltar uma página personalizada com uma mensagem 200 OK. Nesses casos, é
aconselhável fornecer sqlninja com uma corda que está presente em que página de erro (e somente nessa
página). O valor do parâmetro deve ser colocada entre aspas. Por exemplo:

errorstring = "an error has occurred"

appendcomment

Por padrão, anexa sqlninja dois hífens para a consulta injetado a fim de comentar qualquer código SQL
espúria. Isto é bom e funciona em aproximadamente 99% dos casos. No entanto, você pode querer mudar
esse comportamento em algumas situações muito específicas. Por exemplo:

appendcomment = yes

Altere esta configuração somente se você realmente sabe o que está fazendo.
checkdep

As versões recentes do Metasploit desativar automaticamente DEP com o encenador antes de injetar a DLL.
No entanto, se por algum motivo isso não funcionar, você pode reverter para o comportamento antigo:
sqlninja irá verificar a configuração DEP na máquina remota e vai tentar whitelist o encenador Metasploit
chamando Xp_regread. Por padrão, essa configuração está definida nenhuma no , mas é perfeitamente
seguro para reativar o cheque. Ele só vai tornar as coisas um pouco mais lento e, obviamente, vai deixar
uma pegada um pouco maior no sistema remoto. Exemplo:

checkdep = no

sqlmarker

Você também pode substituir o valor do marcador que é usado para dizer sqlninja onde injectar o código
(padrão: __SQL2INJECT__ ). É extremamente improvável que você vai precisar para mudar isso.

sqlmarker = SOME_WEIRD_STRING_HERE

b64decoder

Você pode substituir o nome que sqlninja usa para o script usado para decodificar arquivos Base64, uma vez
que são enviados. O padrão é b64decoder.vbs . É extremamente improvável que você vai precisar para
mudar isso.

b64decoder = somename.vbs

4. Outras informações úteis

Sqlninja é liberado sob a GPLv3. Veja o arquivo de licença para mais detalhes.

Netcat está incluído no pacote sqlninja, já no formato scr.

No modo detalhado que você pode obter um "bareword NetPacket :: IP :: IP_PROTO_UDP não é
permitido ... blá, blá" de erro. Você pode ignorar que, ao que parece um inseto inofensivo de NetPacket. Se
você quiser se livrar dele, configure $proto=17 em UDP.pm.

Todos os direitos para os papéis referenciados no fundo seção pertence a Próxima Geração de Software
de Segurança, agora parte do Grupo NCC . Eu estou hospedando-los no meu site, simplesmente porque eu
não gosto deste manual com links quebrados, e os originais estavam constantemente movida / excluída.

A menos que você é um novato, snowboard em pista é coxo.

4.1 Créditos

Se sqlninja tem sido útil para você, ou porque ele ajudou em um teste de penetração ou porque você se
tornou um milionário roubo de cartões de crédito a partir de sites de e-commerce, estar ciente de que ele
também é obrigado a:

julie - para as discussões sobre DNS tunelamento, e muito mais

David Litchfield e Chris Anley, autores dos trabalhos constantes do fundo secção

lele - para o SQL feitiçaria

pentestmonkey.net - para mais feitiçaria SQL

sp0nge - para todas as discussões e as dicas de codificação

hobbit - para netcat, claro

A equipe de desenvolvimento do Metasploit - para .... Bem, óbvio

Cesar Cerrudo - para o ataque seqüestro símbolo

Antonin Foller - para o código xp_cmdshell original personalizado

Nmonkey - para um monte de dicas, truques e comentários, e por me deixar roubar um monte de coisas
do seu bobcat ferramenta.

Tavis Ormandy - para o exploit KiTrap0d originais

Birillo e Cima-asso.it - para tomar sqlninja ao topo de uma montanha 6130m em Ladakh (não pergunte)

Os pilotos da equipe de Spike - vê-lo no snowpark, gajos!

Créditos adicionais para {idéias | sugestões | manchas | apoio | álcool} acesse: s4tan, Stefano Di Paola,
Elliot Kendall, gansos, Philippe Schaeffer, Angelo Dell'Aera, WarGame, jussi, bambam, Ross Bushby, Konrad
Malewski, Hubert Seiwert , Raul Siles, e um cara de # descontrolada que prefere manter o anonimato
4.2 Renúncia

Sqlninja não é trivial para a instalação, por isso deve ser de nenhum uso para os script kiddies. Em qualquer
caso, o que fazer com esta ferramenta é exclusivamente o seu negócio. A fim de usá-lo você deve ser um
testador de penetração profissional com algum documento escrito que autoriza a fazer furos na rede que
você está atacando. Se você não tiver essa autorização, sinta-se livre para se divertir, mas mesmo assim
estar cientes de que isso pode levá-lo em apuros com um monte de agências de aplicação da lei. Isso
significa que você. Não nós.

4.3 Comentários

Se você tiver algumas observações construtivas ou idéias sobre as funcionalidades actuais ou novos, ou se
você quiser relatar um bug, ou se sqlninja foi útil de alguma forma, por favor, mande-nos uma linha :). Além
disso, se você usar essa ferramenta com sucesso em um teste de penetração, e que fez o seu chefe ganha
mais alguns projetos que irão ajudá-lo a comprar um novo Porsche ou trazendo sua esposa troféu para
Vegas, convencê-lo de que a comunidade de hackers merece uma doação para pagar algumas contas e
comprar alguma bebida.

4.4 Sabedoria

Qualquer idiota pode pedir algum tipo de trabalho, é necessário ser sábio para torná-lo sem trabalhar -
Charles Bukowski

4,5 Autores

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

nico - <nico-at-Leidecker-dot-info>

Logo SourceForge S upport Este projecto