A melhor defesa é...
CAPA
Um bom ataque
Para se proteger, é preciso pensar como o invasor.
por Kurt Seifried
E
m junho de 2009, descobriu-se
que um produto de virtualização destinado a servidores web
possuía algumas vulnerabilidades de
segurança. O resultado final foi que
aproximadamente 100.000 websites
foram hackeados e apagados em vários provedores diferentes (mas não
está claro como vários deles foram
recuperados). Também em junho,
o site de segurança astalavista.com
foi invadido e diversos arquivos e
bancos de dados, além dos becapes
remotos, foram apagados. Essas foram apenas as “grandes” invasões que
foram noticiadas; o número total de
websites e servidores comprometidos
é muito maior.
As técnicas para ataques de rede
evoluem sempre. Este artigo oferece
uma introdução às estratégias preferidas dos invasores da última geração.
Aviso legal
Saiba que realizar os tipos de atividades descritos neste artigo pode trazer
problemas, desde uma conversa séria
com o administrador da rede até uma
temporada de férias nada agradáveis
com tudo pago pela polícia ou qualquer
outra agência que se sinta incomodada por você. Então, por que abordar
este assunto? Se você quiser criar e
manter sistemas seguros, é preciso
compreender como levá-los a falhar.
34
Para comprar uma boa tranca, é preciso comprar várias e aprender como
funcionam ou encontrar alguém que
já o tenha feito [1]. O ideal, portanto,
é pegar uma máquina quad-core barata com montes de memória RAM,
instalar um sistema de virtualização
como VirtualBox ou VMware e usar
os sistemas e rede virtuais oferecidos,
sem perturbar ninguém além dos limites dessa máquina física.
Breve histórico
A vida costumava ser fácil. As pessoas
tinham um servidor no qual executavam alguns serviços (email, arquivos,
DNS etc.). Se os usuários quisessem
algum aplicativo, o administrador o
instalava em suas máquinas. Se os
usuários desejassem editar ou atualizar conteúdo remotamente para
a Web, o administrador dava a eles
acesso FTP. Emails eram somente
texto, arquivos PDF não incluíam
JavaScript e arquivos de imagem
eram apenas imagens – não tinham
conteúdo executável. Para manter a
rede segura, bastava manter os softwares atualizados, o firewall no ar e
executar os serviços sem acesso de root.
Ataques de força bruta
Algumas ferramentas automatizadas
simplesmente “martelam” o sistemaalvo com uma grande variedade de
exploits comuns, qualquer que seja
o servidor a que consigam conectarse. Com isso, trocam velocidade e
sofisticação por força bruta. Essa
técnica costuma funcionar simplesmente por causa do número de
servidores e aplicações web e, mais
importante, por causa do número
de aplicativos desatualizados com
falhas de segurança muito conhecidas (por exemplo, a Adobe levou
várias semanas ou meses para corrigir diversas vulnerabilidades de seu
Reader). Alguns estudos calculam
em 95% a porcentagem de logs de
rede abandonados e, se ninguém os
atualiza com conteúdo, é provável
que eles não estejam recebendo as
correções de segurança [2].
Passo 1:
Reconhecimento
Em poucas palavras, o reconhecimento nem sempre é necessário,
mas informar-se sobre a arquitetura
da rede de uma empresa, sua estrutura organizacional e seu pessoal pode
ajudar em outros ataques. Para descobrir o nome do domínio de uma
empresa ou organização, geralmente
basta incluir um .com ou .com.br ao
final do nome. Se isso não funcionar,
pergunte ao Google. Com o nome
do domínio já é possível aprender
http://www.linuxmagazine.com.br
Invasão | CAPA
Figura 1Saída do comando dig -t axfr para seifried.org.
bastante sobre a empresa por meio
de ferramentas como o whois. Invasores costumam procurar detalhes técnicos, como a localização
dos servidores DNS da empresa e
a competência da gerência técnica
da empresa. Se uma organização for
incapaz de configurar seu DNS de
forma competente, é provável que
sua segurança não seja boa.
Um exemplo perfeito disso é o
seifried.org, hospedado num servidor virtual privado. Infelizmente, o
painel de controle é tão ruim que
define o servidor DNS de forma a
permitir transferências de zona remotas. Portanto, o comando dig -t axfr
permite baixar zonas DNS inteiras,
revelando em poucos segundos todos
os computadores (figura 1).
Se transferências de zona não forem permitidas, outra forma de descobrir computadores na Web é por
meio da busca com site: no Google,
usada para filtrar outros sites nos resultados. Obviamente, isso pode ser
combinado com vários outros termos
de busca, como user name:, login:,
password:, reset password e outros
para descobrir telas de login. O Google e outros meganismos de busca
também oferecem informações tais
como números de telefone da empresa, listas de executivos, diagramas
Linux Magazine #59 | Outubro de 2009
da estrutura corporativa e listagens
de funcionários (figura 2).
Então, o que acontece depois que
o agressor descobre onde você reside
(metafórica ou literalmente)?
Passo 2: Rede
Se você receber mais de um IP ou se
o IP mudar, provavelmente há um
balanceamento de carga por DNS.
Alternativamente, ferramentas como
o Nmap podem identificar balanceadores de carga por meio de suas
impressões digitais TCP-IP (já que
praticamente não há dois dispositivos
TCP-IP que se comportem exatamente da mesma forma). Detectar
firewalls e WAFs também é fácil;
basta enviar um ataque conhecido
por meio de uma máquina remota
ou um proxy anônimo como o Tor e
ver se a conexão é terminada ou se
tentativas subsequentes de conexão
são bloqueadas. Se você realmente
quiser aprender como os profissionais fazem, confira a apresentação do
DojoSec de Joseph McCray [3][4].
Contornar os dispositivos que
bloqueiam a entrada na rede certamente é possível. No caso de um
balanceador de carga baseado em
DNS, simplesmente usar o IP em
vez do nome DNS num ataque já
Um dos primeiros problemas que
os atacantes enfrentam é o de sites
que usam balanceadores de carga,
firewalls, sistemas de prevenção de
intrusão (IPSs) e firewalls de aplicação
web (WAFs, na sigla). Ao tentar atacar um site atrás de um balanceador
de carga, a primeira parte do ataque
pode ser direcionada ao servidor A,
enquanto a segunda vai para o servidor B, o que resultará em falha no
ataque. Da mesma forma, se o site
estiver usando um firewall, IPS ou
WAF, ele pode detectar e bloquear
os ataques (supondo que esses mecanismos funcionem).
Como detectar tais dispositivos
e contornar suas medidas de proteção? Os balanceadores de carga geralmente não são feitos ou instalados com
discrição em mente.
Se o site utilizar o
DNS para balancear
a carga, ferramentas
como o dig os mos- Figura 2Saída de algumas buscas interessantes
no Google.
trarão com facilidade.
35
CAPA | Invasão
mente são basicamente servidores
de aplicação) e o último é atacar
por email (que também é o aplicativo padrão de troca de arquivos para
várias pessoas).
O primeiro método é muito bem
compreendido; geralmente falando,
o atacante busca servidores vulneráveis por meio de uma ferramenta
como Nmap [5][6] ou Nessus [7] e
em seguida ataca-os usando código
de exploits ou verdadeiros toolkits
como o Metasploit [8]. Explorar essas
vulnerabilidades geralmente permite
que o agressor execute na máquina
código hostil, como um shell de root.
Buscar ataques
Figura 3Milw0rm.com – resultados da busca de ataques de injeção de SQL.
vai garantir que todos os ataques sejam enviados para o mesmo sistema.
Contornar firewalls também é relativamente trivial, pois basicamente
todos os firewalls permitem receber
tráfego de email e Web. O mesmo vale
para sistemas IPS e WAF; a maioria
dos sites morre de medo de bloquear
tráfego legítimo, então costumam
baixar a sensibilidade dos sistemas,
o que também reduz sua eficácia.
Web 2.0 e email
Antigamente, páginas web e emails
eram basicamente o mesmo: texto
estático com formatação mínima
e pouco conteúdo executável. O
pêndulo agora está no outro lado;
a maioria dos clientes de email suportam texto e HTML, assim como
arquivos anexos. O HTML, como
você sabe, suporta várias tecnologias
executáveis, sendo a mais popular o
JavaScript (navegadores web, clientes
de email e até o Adobe Reader), o
que significa não apenas que é preciso preocupar-se com estouros de
buffer e de inteiros em imagens, mas
também que temos uma máquina de
Turing completa embutida em vários
aplicativos. Como quase ninguém
bloqueia ou desativa JavaScript, não
há forma melhor de atacar aplicativos de forma confiável.
Passo 3: O ataque
Figura 4PacketStorm Security – descrição do
código de exploit.
36
Há alguns poucos métodos comuns
de ataque que funcionam bem contra
usuários e redes modernos. O primeiro é atacar servidores e serviços
expostos (como DNS), o segundo
é atacar servidores web (que atual-
Como encontrar todos esses ataques?
Dado um pacote de software specífico
(por exemplo, Sendmail, WordPress,
DokuWiki ou MediaWiki), como
rastrear as vulnerabilidades que o
afetam? As melhores possibilidades
são acompanhar os bancos de dados
CVE [9] e OSVDB [10], que possuem
links para recursos em cada relatório
de segurança e, no caso de códigos de
exploit, o Milw0rm [11] (figura 3) e o
PacketStorm Security [12] (figura 4).
O framework Metasploit na realidade
inclui surpreendentemente poucos
exploits – aproximadamente 300 na
última contagem. O PacketStorm
Security tem aproximadamente 300
a 400 exploits por mês. É provável
que, se o site estiver usando softwares
desatualizados, você encontre algo
no Milw0rm ou no PacketStorm
Security que permita atacá-los.Caso
contrário, os bancos CVE e OSVDB
frequentemente contêm informações
suficientes para indicar a direção certa.
Ataque a
servidores web
Hoje, servidores web são basicamente
servidores de aplicação, e onde há
aplicações, há falhas de segurança. Um dos maiores problemas é
a complexidade desses programas.
http://www.linuxmagazine.com.br
Invasão | CAPA
No mínimo, uma aplicação “básica” geralmente inclui: a aplicação
propriamente dita, um servidor web,
um sistema operacional e um banco
de dados. Todos esses componentes
podem ser atacados por meio de falhas da aplicação e, muitas vezes,
várias pequenas falhas podem ser
combinadas de forma a permitir a
execução de código que permita a
um agressor entrar no servidor.
Se você estiver com preguiça, também pode simplesmente baixar um
buscador de aplicações web e apontálo para o alvo. Ferramentas automatizadas como o Nessus ou o Nikto,
que busca mais de 3.500 arquivos e
scripts CGI potencialmente perigosos,
podem buscar um servidor em busca
de aplicações vulneráveis. Se essas
ferramentas não encontrarem nada
com vulnerabilidades conhecidas, o
atacante sempre pode usar ferramentas
como o WebScarab para examinar e
atacar diretamente as aplicações web.
Procurar aleatoriamente costuma expor
problemas interessantes mais rápido
do que se imagina [13].
Injeção de SQL
A maioria das aplicações
web precisa armazenar dados localmente no servidor,
e em vez de lidar com arquivos locais ou o SQLite,
as aplicações costumam
usar um banco de dados de
verdade, como MySQL ou
PostgreSQL. Infelizmente,
várias aplicações deixam de
tratar corretamente os dados
antes de passá-los para uma
consulta SQL, e muitas não
constroem consultas de forma segura. Alguns ataques
comuns incluem:
de autenticação (por exemplo, nome
de usuário ou senha); se não for corretamente manipulada, essa consulta
ficará como name or ‘1’=’1’. Como
1=1 sempre retorna verdadeiro no
SQL, isso permite que o agressor se
autentique sem sequer ter uma senha ou usuário válidos. O segundo
ataque ajuda o invasor a descobrir se
uma consulta é vulnerável à injeção
de SQL; ele procura productid, mas
como 1 não é igual a 2 (e portanto a
operação retorna falso), o termo and
forçará a consulta SQL a ser falsa,
o que provavelmente resultará num
erro. No caso de uma página de um
produto que deveria mostrar os resultados de productid, isso não ocorrerá,
pois a consulta SQL é inválida ou
causa um erro.
Agressores adoram injeção de SQL
porque conseguem contornar toda a
autenticação e, dependendo do banco de dados e da configuração em
questão, também conseguem atacar
o diretamente servidor local de banco
de dados. Além disso, se a aplicação
web obtiver seu conteúdo a partir do
banco de dados (como descrições de
produto), um agressor poderá modificar a descrição do produto para
incluir código PHP (ou qualquer outra linguagem usada para escrever a
aplicação web), que em seguida será
executado da próxima vez que a página for carregada, permitindo que o
agressor execute código no servidor.
Para uma lista completa de dicas e
truques, confira a “SQL Injection
Cheat Sheet” [14]. Para uma ótima
ferramenta de injeção de SQL, veja
o SQLMap (agora disponível como
pacote oficial no Debian!) [15].
XSS
O Cross-site scripting (XSS) é um
exemplo perfeito de por que jamais
se deve misturar dados e código num
único objeto. O HTML já foi apenas
uma simples linguagem de marcação
que não envolvia conteúdo executado no lado do cliente. Claro que isso
tornava a Web muito monótona, e
não demorou muito para ganharmos
o JavaScript da Sun e várias opções
da Microsoft (ActiveScript, ActiveX
etc.). Agora o problema é que o navegador web não tem como saber qual
Figura 5Poluição de parâmetros HTTP com o servidor web Apache.
name’ or ‘1’=’1
productid’ and ‘1’=’2
O primeiro ataque costuma ser usado em campos
Linux Magazine #59 | Outubro de 2009
Figura 6Exemplo de email enviado 15 minutos antes da hora do almoço.
37
CAPA | Invasão
JavaScript deve ou não estar presente
numa página web (e se o JavaScript é
“mau” ou não), então o agressor que
conseguir inserir conteúdo também
conseguirá inserir JavaScript com a
mesma facilidade. Inclusive esse código (normalmente) será executado
no lado do cliente, a menos que o usuário cliente seja paranóico e tenha
desativado o JavaScript ou instalado
a extensão NoScript.
A beleza dos ataques XSS é que
eles são muito comuns. É possível
incluir conteúdo hostil e código no
site onde o usuário está navegando,
permitindo ao agressor roubar cookies
(que geralmente contêm credenciais
de autenticação), teclas, dados de
formulário e assim por diante – todos levando, no fim das contas, ao
acesso administrativo à aplicação e
a ataques mais detalhados. Além disso, ao combinar o XSS a ataques de
email direcionados e coletar informações pessoais na Web, as chances
de enganar com sucesso o usuário,
de forma a fazê-lo clicar num link
malicioso, aumentam. Mas o que
acontece quando um site tem um
bom firewall de aplicação (ou talvez o mod_security), que bloqueia
ataques XSS? Nesse caso, use a codificação (UTF-8), incluindo espaços
em branco (que o navegador geralmente ignora) e adicione caracteres
estranhos na tag do script (como /),
para citar alguns métodos.
garantir que os comandos enviados a
ela sejam válidos, um agressor pode
potencialmente enganar o navegador
da vítima para esta fazer uma requisição que contenha comandos que a
aplicação web executará (tais como
adicionar um novo usuário ou alterar
as permissões de um já existente). A
má notícia é que muitas aplicações
ainda não oferecem proteção eficaz
contra CSRF; o motivo mais simples
é que realmente não há qualquer biblioteca difundida para lidar com esse
problema; o fato de que as pessoas são
forçadas a reinventar a roda já levou
a várias implementações quebradas.
Poluição de
parâmetros HTTP
A poluição de parâmetros HTTP
(HPP na sigla em inglês) é uma nova
técnica de ataque anunciada publicamente há apenas alguns meses. A
HPP é tão simples que chega a ser
surpreendente o fato de ninguém
ter pensado nela antes. Quando
uma aplicação envia dados para um
servidor na forma de parâmetros, o
servidor pode não conseguir lidar
com a situação de forma simples
quando um parâmetro aparece mais
de uma vez. Em outras palavras, se
você incluir productid duas vezes na
string GET, talvez você consiga explodir a aplicação (figura 5). Essa classe
de vulnerabilidade é admirável por
um simples motivo: ela envolve interações entre servidores web, que
Eu cobri o cross-site request forgery passam a se comportar de maneira
(CSRF) em minha coluna na Linux estranha e frequentemente inesperaMagazine 51 [16]. Para recapitular ra- da, e aplicações web (não há como
pidamente: se uma aplicação web não saber como elas se comportam frente a parâmetros poluídos). Até o momento
não há uma forma
“correta” de lidar com
múltiplos parâmetros.
É possível argumentar
que a aplicação deveFigura 7Exemplo de arquivo PDF com uma mensaria tomar somente o
gem pop-up JavaScript.
primeiro e o último,
CSRF
38
concatená-los e até passá-los como
vetor em vez do tipo string esperado.
Portanto, é improvável que o mundo
chegue a ver uma boa solução de
longo prazo [17].
Inclusão de
arquivo local
A maioria das aplicações faz uso de
arquivos de inclusão (arquivos CSS,
bibliotecas etc.) e frequentemente
podem ser enganadas de forma a
incluir arquivos em outros pontos
do sistema. Navegar pelo sistema
de arquivos, principalmente de locais remotos, oferece informações
detalhadas ao agressor. Ele pode,
por exemplo, verificar o diretório
/etc/ em busca de arquivos de configuração, os diretórios de páginas de
manual (para softwares instalados e
informações de versões) e os diretórios de binários e bibliotecas. Como
a maioria das aplicações web são
executadas sob demanda, qualquer
informação de configuração de que
necessitem precisa estar disponível
para elas; arquivos de configuração
como wp-config.php, config.inc.php
e LocalSettings.php permitem que
agressores coletem remotamente
as credenciais do banco de dados.
Criação de arquivos
com MySQL
Se um agressor for incapaz de executar código no sistema mas tiver
acesso ao banco de dados (seja por
injeção de SQL ou por coletar credenciais a partir de um arquivo de
configuração), qual a pior coisa que
pode acontecer? Supondo que eles
não simplesmente apaguem o banco
de dados, eles podem criar arquivos
no sistema usando o comando SQL
INTO OUTFILE. Felizmente, o agressor
não conseguirá sobrescrever arquivos
já existentes; caso contrário, seria capaz de modificar ou destruir todos os
bancos de dados do sistema!
http://www.linuxmagazine.com.br
Invasão | CAPA
Porém, com uso do comando
INTO OUTFILE em conjunto com um
conteúdo de banco de dados personalizado, um agressor pode criar
arquivos de script no diretório /tmp/
– por exemplo:
CREATE TABLE `database`.`scripts`
(`contents` TEXT NOT NULL) ENGINE
= MYISAM
INSERT INTO `database`.`scripts`
(`contents`) VALUES (‘#!/bin/bash
\necho “hello world”’);
SELECT * INTO OUTFILE “/tmp/mau.sh”
from `scripts` WHERE 1
O agressor pode até mesmo criar
arquivos binários com uso do comando DUMPFILE, permitindo que o
ataque faça uso de bugs na inclusão
de arquivos locais por meio de arquivos de imagem ou documentos que
contêm estouros de buffer.
Ataques de email
O que acontece se você chegar a
um beco sem saída e não conseguir
encontrar serviços vulneráveis para
o ataque? E se a rede estiver corretamente segmentada e não houver
caminho a partir do servidor web
comprometido até a rede interna?
Vá pelo email. Como quase todos os
clientes de email já “topam” HTML,
conteúdos multimídia e assim por
diante, eles se baseiam nas bibliotecas subjacentes do sistema para
lidar com esses conteúdos.
A má notícia é que praticamente
todos os mecanismos de renderização de HTML (WebKit, Gecko, Microsoft HTML Rendering Engine,
Microsoft Word etc.) possuem falhas
exploráveis, assim como a maioria
das imagens e arquivos multimídia.
Se você conseguir fazer um email
malicioso passar pelos antivírus e
filtros, provavelmente conseguirá
causar a execução de código na máquina da vítima.
Para piorar ainda mais a situação,
você também tem a opção de anexar
Linux Magazine #59 | Outubro de 2009
um arquivo que tenha como alvo
qualquer programa local, sendo os
mais populares atualmente o Adobe
Reader (com várias vulnerabilidades
relacionadas ao JBIG2), Open Office
e, evidentemente, Microsoft Office.
Mas os sites não têm antivírus
que atuam nos emails recebidos e
bloqueiam anexos executáveis? É aí
que as informações coletadas sobre
o alvo se tornam importantes. Se
você conseguir encontrar uma lista
dos executivos ou um diretório de
telefones da empresa (que às vezes
até lista o departamento de cada
funcionário), é possível criar emails
que se pareçam com a mensagem
exibida na figura 6.
PDFs maliciosos
O único motivo para escolher
PDFs em vez de outros formatos (como TIFF, AVI, DOC
e ODT) é que nos últimos
meses foram lançados vários
exploits e ferramentas fáceis
de usar para o Adobe Reader,
que é um dos poucos aplicativos presentes em quase todos
os sistemas (caso contrário, o
sistema provavelmente tem
outro programa igualmente
vulnerável, como o Foxit). E
é possível embutir JavaScript
em arquivos PDF (figura 7)
para ser executado por padrão,
embora seja possível desativar
o suporte a JavaScript no Adobe Reader [18].
Didier Stevens liberou uma
ferramenta chamada make-pdfjavascript.py, que permite
embutir JavaScript arbitrário
num arquivo PDF [19]. Felizmente, essa ferramenta não faz
qualquer ofuscação ou outros
truques para esconder o Java­
Script, embora outras o façam.
Entretanto, deixarei que o leitor se divirta procurando-as.
Note que talvez seja preciso executar o script por meio
do dos2unix para corrigir as quebras
de linha, e dependendo da versão
do Python na sua máquina, há um
comando finally: na linha 63 que
talvez precise ser apagado. Na linha
seguinte, apague uma tabulação do
início da linha. Assim o script deve
rodar com sucesso.
Agora tudo junto
Individualmente, a maioria desses
ataques não leva o agressor muito
longe. É possível ganhar acesso a
uma aplicação web, ler o email de
alguém ou visualizar um arquivo
do servidor. Mas ao combinar as
técnicas, tais como escrever conteú­
dos arbitrários num arquivo e em
seguida incluir esse arquivo para
Figura 8Exemplo de combinação de XSS
com execução de código remoto.
39
CAPA | Invasão
que seu código PHP seja executado
(figura 8), o agressor pode realizar
ataques locais, dos quais há vários
exemplos. Somente na primeira metade de 2009, o kernel Linux sofreu
por causa de várias vulnerabilidades
localmente exploráveis (ptrace_attach, udev, netlink e exit_notify),
que possuem código público para
exploração (procure Linux Kernel
no Milw0rm).
Explorar um sistema por meio
do kernel é particularmente eficaz
porque (i) você sabe que ele está
instalado e (ii) atualizar um kernel
Linux em vários servidores web é doloroso ou simplesmente impossível.
Uma vez que os agressores ganhem
acesso ao código de exploração localmente, é uma questão de tempo
até ele conseguir executar código
como usuário root.
Passo 4: Lá dentro
Então você conseguiu comprometer um servidor, executar um
ataque local e ganhar acesso de
root. E agora? Para a maioria dos
invasores, a resposta é simples: instalar um rootkit [20] para manter
o acesso e depois continuar. Com
acesso aos sistemas internos (como
servidores de arquivo), um agressor pode criar links para arquivos
compartilhados, que no Windows,
por exemplo, serão executados na
“Intranet” caso estejam na mesma
rede, contornando assim várias
proteções de segurança.
Mesmo que o invasor só consiga
acessar um servidor web limitado
dentro do domínio, ele conseguirá
atacar a infraestrutura de rede (como
roteadores e switches) diretamente
e forjar emails com mais facilidade. Uma alternativa é o agressor
simplesmente usar os sistemas da
empresa como partes de uma botnet para atacar outras máquinas e
redes, enviar spam e coletar informações pessoais. As possibilidades
são infinitas. n
40
Mais informações
[1]Devian Ollam, “Dez coisas que todo mundo deveria saber sobre
invasões e segurança física” (em inglês):
http://www.blackhat.com/presentations/bh-europe-08/
Deviant_Ollam/Whitepaper/bh-eu-08-deviant_ollam-WP.pdf
[2]“Blogs caindo numa floresta vazia” (em inglês):
http://www.nytimes.com/2009/06/07/fashion/07blogs.html
[3]DojoSec: http://www.dojosec.com/
[4]Joseph McCray, Boletim mensal DojoSec, Abril de 2009:
http://vimeo.com/4109188
[5]Eric Amberg, “Varredura automática”: http://lnm.com.br/article/1505
[6]Christian Ney, “Invasão”: http://lnm.com.br/article/561
[7]Nessus: http://nessus.org/nessus/
[8]Kurt Seifried, “Explorar vulnerabilidades é fácil com o Metasploit”:
http://lnm.com.br/article/2472
[9]CVE: http://cve.mitre.org/cve/
[10]OSVDB: http://osvdb.org/
[11]Milw0rm: http://www.milw0rm.com/
[12]PacketStorm Security:
http://packetstormsecurity.com/exploits100.html
[13]Dez melhores buscadores de vulnerabilidades:
http://sectools.org/web-scanners.html
[14]SQL Injection Cheat Sheet:
http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/
[15]SQLMap: http://sqlmap.sourceforge.net/
[16]Kurt Seifried, “O ataque das requisições cross-site”:
http://lnm.com.br/article/2570
[17]Poluição de parâmetros HTTP: http://www.owasp.org/
images/b/ba/AppsecEU09_CarettoniDiPaola_v0.8.pdf
[18]Desativação do JavaScript no Adobe Reader: http://blogs.
adobe.com/psirt/2009/04/update_on_adobe_reader_issue.html
[19]Didier Stevens, “PDF Tools” (em inglês):
http://blog.didierstevens.com/programs/pdf-tools/
[20]Kurt Seifried, “A quarta geração dos rootkits...”:
http://lnm.com.br/article/2520
Gostou do artigo?
Queremos ouvir sua opinião. Fale conosco em
[email protected]
Este artigo no nosso site:
http://lnm.com.br/article/3041
http://www.linuxmagazine.com.br