Introdução

Capítulo 1 - Quebra de senhas

Brute force

John the Ripper

Investigação social

Senhas remotas

Solução contra quebras de senhas

Capítulo 2 - Trojans

Trojan para iniciantes

Trojan que não abre porta

Solução

Antivírus

Ferramentas de integridade

Auditoria de processos

Capítulo 3 - Scanner

Scanners de portas

Scanners de SO

Scanners de falhas
Solução para scanners

Capítulo 4 - Falhas de código em sites

Unicode

SQL Injection

Soluções para falhas de códigos em sites

Este livro possui uma abordagem direta aos principais assuntos da atualidade
no que diz respeito à segurança de sistemas.

Os temas são abordados gradualmente, conforme o nível de complexidade,

mas sempre entrando em detalhes, para não gerar dificuldades de compreensão.

Dessa forma, inicialmente são abordados assuntos menos complexos,

relacionados à quebras de senhas por tentativa e erro, usando técnicas nomeadas
como o Brute Force, além de investigação social, ataques remotos, trojans e
concatenação de arquivos, temas muito pesquisados ainda hoje.

0 conteúdo do livro é finalizado com assuntos mais complexos como scanner,

Unicode, SQL Injection, entre outros.

Em todos eles, tentei ser o mais didático possível, apresentando diversos

códigos-fontes, com o intuito de fornecer as mais diversas informações ao leitor
leigo e de servir como uma boa referência para aqueles que já possuem bastante
conhecimento sobre o tema.
 Antigamente, a criptografia não tinha o mesmo poder que tem hoje. A
tecnologia de segurança de sistemas foi avançando de acordo com os recursos
que tinha em mãos. Hoje, os algoritmos são muito complexos e, se fossem rodar
nas máquinas de antigamente, não seriam viáveis.

A senhas de hoje são muito difíceis de serem decodificadas. Os algoritmos

estão cada vez mais complexos e poderosos, o que torna a decodificação quase
impossível. A única coisa que ainda pode ficar a favor de um invasor, nesse
ponto, é o erro humano. Erro este que muitas pessoas cometem quando estão
criando senhas, jogando todo o esforço dos desenvolvedores e administradores
por água abaixo.

Neste capítulo, serão mostradas as técnicas usadas ainda hoje para tentar
descobrir senhas consideradas fracas.

Em nosso primeiro exemplo, criei um programa simples que criptografa uma

determinada frase mediante um componente.

0 componente que escolhi não é muito aconselhável para uma aplicação real,
pois ele não tem criptografia forte, como as de hoje. 0 ideal, para o exemplo,
seria algum componente que siga o padrão PGP, mas o que escolhi deve-se
simplesmente pela portabilidade, pois ele já foi instalado em todos os Delphi que
já usei e até mesmo no Kylix. Assim, ninguém terá dificuldades em instalá-lo.
Basta clicar em Component> Instalicomponent, selecionar o arquivo com a
terminação.pas e mandar instalar. 0 código foi criado por Tom Lee. Ele é
gratuito, opera source, e pode ser facilmente encontrado na Internet.

Não se esqueça de adicionar o diretório do componente em Library Path, no

Enviroment options. Veja o código do componente:
Encryp.pas
 Baseado nesse componente, eu criei um programa que o aplica. Esse
programa criptografa um texto de um TMemo de acordo com uma senha
digitada em um TEdit, usando o componente TEncryption.

0 programa tem de ficar parecido com a figura seguinte:

Figura 1.1.

0 programa é bem simples. Observe:

Unitl.pas
 Nesse programa, eu digitei uma coisa qualquer, no caso 0 rato roeu a roupa do
rei de Roma, e a senha testada foi 12345. Isso resultou no seguinte texto:

Vale adiantar que, sempre que você manda criptografar, é mesclado um valor
randômico, portanto, se você testar, dificilmente terá o mesmo resultado.

Brute force

Essa é a forma a partir da qual podemos ter certeza de que a senha será
descoberta. Ela pode ser a mais demorada, porém se a senha tiver poucos
caracteres, trabalha muito bem. Consiste em tentar todas as combinações
possíveis (1, 2, 3... 1a, 1b, 1c...), até que seja encontrada a senha correta.

Obviamente, seria extremamente exaustivo tentar as senhas uma a uma, por

isso é mais prático automatizar o serviço.

Eu criei uma Unit em Delphi que faz a maior parte do trabalho. Ela contém
uma função que retorna qual será a próxima senha a ser tentada. Ela pede como
parâmetros a senha atual e os caracteres que estão sendo usados:

Brute.pas
 Assim, nós temos uma função que retorna a próxima senha e sabemos qual o
algoritmo usado (no caso, o do componente). Então, agora, o que nos resta é unir
as duas coisas em um programa. Nosso programa será assim:
 Figura 1.2.

Criei um código que tenta ser o mais útil possível.

De tempos em tempos, ele salva a posição atual em um arquivo, caso algum

problema ocorra (como queda de energia, ou travamento do computador).

A cada um segundo, ele também mostra o status e quantas senhas estão sendo
tentadas por segundo, a posição atual e o total de senhas tentadas desde o início
da execução. Veja o código:

Unitl.pas
 Agora é só rodar. Eu o especifiquei para tentar apenas caracteres numéricos.
Em pouco tempo ele mostrou qual senha foi usada para encriptar o texto.
 Figura 1.3.

John the Ripper

Esse programa para Linux foi feito por hackers e mescla Dicionary attack e
Brute force. Utiliza também uma lógica de senhas muito interessante, além de
ser muito rápido.

Se um hacker consegue invadir o sistema de alguma forma, ele irá tentar

manter esse acesso. Copiando o arquivo de senhas do Linux ou de alguns outros
sistemas Unix, no qual esse password cracker é compatível, ele pode conseguir
quebrar a senha de outros usuários, facilitando uma futura segunda invasão:

No exemplo anterior, ele conseguiu encontrar a senha do usuário "sam" em

menos de um minuto. A senha 123456 é muito comum e estava no meio da lista
de senhas comuns que vêm junto com o John the Ripper, o que explica o fato de
ela ter sido quebrada rapidamente:

Investigação social

Essa técnica é a mais elaborada. Consiste em investigar a vida da pessoa e

tentar descobrir nome de coisas e pessoas envolvidas a sua vida. Cenas como as
do filme Hacker, no qual os protagonistas vasculham o lixo de uma empresa, não
são muito comuns, apesar de não serem impossíveis. Hoje, é mais fácil fazer
esse tipo de pesquisa digitalmente.

Vamos supor, por exemplo, que uma pessoa dentro da empresa use nosso
programa de criptografia para guardar informações confidenciais e tenha
diversos documentos com a mesma senha. Vamos supor, também, que, por
algum momento, por exemplo, a noite, alguém conseguiu obter o acesso ao HD
da pessoa. Esse é um caso em que uma varredura seria muito útil para um
invasor. Ele pode obter uma lista de palavras mediante informações espalhadas
em seu disco rígido, e, se a pessoa tem o costume de usar como senha coisas
comuns a sua vida, possivelmente o invasor será bem sucedido. Ele também irá
varrer e-mails não apagados e históricos da Internet.

Vamos criar um programa que faça essa varredura. Ele deve ser mais ou
menos assim:
 Figura 1.5.

Esse programa abrirá diversos documentos de diversas espécies e gerar uma

lista de palavras. 0 programa vai abrir documento por documento, linha por
linha, separando palavra por palavra. Ele também não pode deixar que as
palavras se repitam, para evitar desperdício de tempo. Deve ter um tratamento
carinhoso com arquivos .INI, tendo em vista que, neles, alguns programas
gravam senhas sem criptografia.

Também seria interessante ter a opção de deixar palavras em letras

minúsculas, apagando caracteres indesejados, que muita gente não usa como
parte de senhas:

Unit1.pas
 Em computadores domésticos, esse programa poderia gerar detalhes
assustadores de acordo com as pessoas que o utilizam, graças a programas como
ICQ, mIRC e outros, relativos a bate papo, que preservam as conversações em
arquivos de log.

Senhas remotas

Senhas remotas são mais difíceis de descobrir, pois o tempo entre tentar uma
senha e outra é maior do que processar localmente. Isso se deve a três fatores
básicos:

•tempo de atraso no envio dos dados para o servidor;

•processamento do servidor;
•tempo de atraso na resposta do servidor.

Brutus

Existem algumas técnicas para tentar amenizar a demora. A primeira é a

utilização de múltiplos soquetes, que abrem diversas conexões simultaneamente:
enquanto um dado está sendo enviado, outro está sendo processado, outro
recebido etc.

Um programa que faz isso é o Brutus:

Figura 1.6.

Quem sabe, então, uma conexão ADSL boa não ajudaria? Servidores bem
configurados permitem apenas N conexões por IP, o que acaba limitando essa
técnica.

Poderíamos utilizar vários servidores proxy, além de todo IP mascarado. Além

deles, normalmente, serem lentos, o problema agravaria, pois o ciclo seria
dobrado. Teríamos então:

1.Tempo de atraso no envio dos dados para o proxy.

2.Processamento do proxy.
3.Tempo de atraso no envio do proxy para o servidor.
4.Processamento do servidor.
5.Tempo de atraso da resposta do servidor para o proxy.
6.Processamento do proxy.
7.Tempo de atraso na resposta do proxy.

Então, como podemos ver, seria melhor descartar essa possibilidade também.

A única alternativa que parece viável, então, seria diversas máquinas com uma
boa conexão, trabalhando em conjunto, tentando descobrir tal senha, o que torna
a tarefa inviável para uma pessoa sozinha. A não ser que alguém crie um worm
com esse objetivo. Mesmo assim, os servidores têm um limite máximo de
conexões. Então, aconteceria um DoS (Ataque de recusa de Serviço).

Preferi não entrar em detalhes na questão "senhas remotas", pois não vi muita
utilidade no assunto, tendo em vista que as técnicas empregadas, hoje, são muito
fracas perto das proteções oferecidas.

Existem servidores que desabilitam o login por n segundos, ou minutos,

depois de n tentativas falhas.

Um servidor bem configurado atrás de um bom firewall aniquilaria qualquer

uma dessas tentativas.

Solução contra quebras de senhas

A melhor solução é forçar os usuários a ter senhas fortes, com uma boa
quantidade de caracteres e com letras e números.

0 Linux vem com o Linux-PAM, módulo de autenticação. Ele segue com

muitos recursos, o suficiente para aumentar o grau de segurança. Por exemplo,
tentei mudar minha senha atual para "teste", "america" e "123456". Veja as
respostas que ele me retornou:
 Ele força um limite mínimo de caracteres, vem com uma lista de palavras
comuns, e, ainda, verifica se a senha é muito simples ou sistemática. Permite
diversas configurações e, ainda, existem algumas interfaces gráficas que
facilitam o trabalho:

Figura 1.7.

Quanto à política de acessos remotos, o Linux também possui diversos

firewalls gratuitos, como ipchains, iptables etc. Mais adiante, darei algumas
dicas de configuração do iptables.

Nota: programas como John the Ripper podem ajudar a descobrir quais
usuários possuem senhas fracas, sendo, então, não só útil para o hacker,
como, também, para o administrador. Assim o administrador pode solicitar
ao usuário alterar sua senha para uma outra mais forte.
 Não podemos falar de trojans sem, antes, falar um pouco de sockets. 0
conceito é simples: um socket pode ficar no estado Listen (Ouvindo),
aguardando que alguém se conecte e envie dados, para que ele devolva uma
resposta. Ele também pode ser do tipo Connect (Conectar), que envia dados e
recebe uma resposta.

Trojan para iniciantes

Existem diversos tipos de trojans. Nesse tópico, mostrarei detalhadamente

como funciona o trojan de lamers (para iniciantes). Esse tipo de trojan conecta-
se a uma máquina que está rodando o trojan servidor e envia textos para o
programa. De acordo com o texto enviado, uma ação é executada:

Figura 2.1.

Os trojans que hackers de servidores normalmente usam têm a função de abrir

uma porta no servidor. Então, ele se conecta via Telnet (ou similar), enviando
comandos no modo texto. Depois, o trojan é executado e retorna uma resposta.
 Nota: hoje, alguns conceitos foram aperfeiçoados e nem sempre o trojan
abre uma nova porta. Esse novo conceito será explicado no final deste
capítulo.

Apesar de ambos terem o mesmo conceito, normalmente a construção do

trojan de lamer é um pouco mais complicada que a de trojans de hackers, mas
tem um manuseio mais simples.

Trojan cliente

0 nosso trojan divide-se em duas partes. 0 cliente é a parte mais fácil. Ele deve
se parecer com a figura seguinte:

Figura 2.2.
 Na primeira aba, temos as funções de manipulação de arquivo, enviadas para
o servidor. Note que existem dois parâmetros. O primeiro parâmetro é
obrigatório em todas as ações.

Caso queria listar um diretório, por exemplo, no Parametrol, digite c:I*.

Então, clique no botão Listar. Isso fará com que o conteúdo do diretório do
servidor seja retornado.

Para abrir o Bloco de notas no servidor com o conteúdo do autoexec.bat, por

exemplo, no Parametrol digite C:IW/NDOWSIsystem321notepad.exe e, no
Parametro2, c:\autoexec.bat. Somente execução e cópia de arquivo utilizam o
Parametro2.

0 cliente exibirá um log de tudo que ele está enviando para melhor
compreensão do que está acontecendo.

Ele usará um TClientSocket para enviar os dados para o servidor. Eu escrevi

tanto o cliente como o servidor a partir do exemplo chat, que vem com os
Delphi. Se nunca utilizou sockets, convém analisar o código desse chat para
entender o conceito. Veja uma listagem do código do cliente do trojan:

Main.pas
 Basicamente, só enviamos texto para o servidor, de acordo com o botão
clicado. Ou seja, clicamos no botão que envia a mensagem, em que o primeiro
parâmetro envia um /msg para indicar a que ação é apresentada uma mensagem,
depois colocamos um &, apenas para separar o conteúdo do campo Edit1. 0
segundo parâmetro é apenas uma descrição a ser colocada no log.

Trojan servidor

Agora, iremos criar o principal: o servidor. 0 servidor irá aguardar uma

conexão por meio do TServerSocket e interpretar os dados de acordo com o
texto recebido. Ele executará uma ação no evento OnRead do componente. Você
pode adicionar todas as funcionalidades que um exe pode proporcionar (quase
tudo). Ele deve ser assim:
 Figura 2.3.

Em nosso exemplo, o servidor estará sempre visível. Claro que um usuário

mal-intencionado utiliza diversos recursos para esconder esse cavalo de tróia,
existem até componentes que fazem isso, mas esse não é o escopo do nosso
teste. Nosso servidor também terá um log exibindo todo texto que ele recebe.
Veja o código do servidor:

Main.pas
 Aprocedure Entrada é a que coordena todas as requisições enviadas pelo
cliente.

De acordo com cada texto recebido, o trojan executa uma função:

 Mais adiante, serão explicadas as utilidades da procedure sai e da constante
nTrojanSize. Aprocedure será muito importante para escondermos o servidor em
outro programa. No momento, vamos executar e testar ambas as aplicações,
conectando em /ocalhost:
 Figura 2.4.

Nota: existem trojans poderosos, como os que foram distribuídos pela

Internet com seus códigos-fontes, o Deep Trotle (Delphi) e o Back
Orifice/2K (C++). Muitos invasores alteram seus códigos criando
'variações', para que os antivírus não consigam detectá-los.

Para diminuir o tamanho do trojan servidor, devemos usar compactadores de

exe. Esses programas compactam o exe e, diferentemente de compactadores
normais (como tar, rar, zip etc) o programa continua sendo um executável.
Porém, quando aplicado, o executável é descompactado na memória e rodado.
Um conhecido compactador gratuito é o UPX:
 Figura 2.5.

Nota: esse método não protege o.exe, como muitos pensam. É muito fácil
achar unpackers (desenpacotadores) pelos sites de busca mais conhecidos.

Camuflando o trojan servidor

Quando um usuário mal-intencionado quer controlar uma máquina,

normalmente esconde seu programa malicioso em outro programa para não
levantar suspeita. Uma das técnicas utilizadas para isso é a concatenação de
arquivos. 0 que vamos fazer aqui é gerar um executável de saída concatenado,
ou seja, juntar os dois programas. De forma que colocaremos o trojan no começo
do arquivo e o programa de disfarce no final:

Figura 2.6.

Criei uma aplicação que, além de juntar os arquivos, fornece o ponto em que
começa o programa de disfarce:
 Figura 2.7.

0 código desse programa é simples:

 No primeiro campo, selecionaremos o trojan e, no segundo, o programa a ser
contaminado (no caso, o putty).

Nota: é comum utilizar um programa que, por natureza, abre portas de

comunicação pela Internet, como um cliente de FTP, SSH, ou e-mail,
diminuindo as suspeitas no caso de um firewall alertar abertura de portas.

Depois de clicar no botão Salvar Como, os dois arquivos serão agrupados em

um arquivo de saída escolhido por você. Após o trojan ser alterado e compactado
com o UPX, o tamanho do aplicativo muda. Assim, o que faremos? Primeiro,
compilamos e compactamos. Depois, vamos executar nosso programa de
concatenação. Ele forneceu uma informação muito importante na barra de status:

176128 é o ponto do arquivo que termina o trojan quando está compactado.

Este número deve ser colocado na constante nTrojansize. Dessa forma, vamos
compilar, compactar com UPX e concatenar novamente.

Note que a posição será a mesma. Como a constante já foi declarada, o

tamanho do arquivo não muda.

0 trojan trabalhará da seguinte forma:

1.Se ele estiver sendo executado na pasta system32, abrirá a porta do trojan.
2.Caso esteja em qualquer outra pasta (como c:\down/oad, por exemplo), ele fará
uma cópia dele mesmo para a pasta system32 com o nome de Temp.exe.
Esse arquivo será manipulado.
3.É feita uma cópia do arquivo com o nome de sysexec.exe e executado. (note
que esse novo arquivo está na pasta system, assim ele abrirá a porta). Por
fim, o arquivo Temp é lido com a função seek. Ele vai até a posição do
arquivo declarada na constante nTrojanSize (no caso 176128) e copia tudo, a
partir daí, para outro arquivo, chamado file.exe (que no caso é o putty.exe).
Só então, é executado.
4.Esse arquivo copiado para fora e executado é justamente o arquivo que
concatenamos. Nosso trojan servidor estava programado para fazer essa
ação no procedimento de saída. Por fim, esse procedimento sai, aguarda dez
segundos e vai tentando apagar o arquivo file.exe. Só irá apagar com
sucesso após o programa ser fechado.

Trojan que não abre porta

Muitas pessoas perguntam se toda essa segurança é necessária. A resposta é

sim!

Do mesmo jeito que existem cada vez mais proteções, os ataques estão cada
vez mais avançados, e até mesmo os trojans estão ficando mais complexos.

Um exemplo disso está em uma das diversas documentações e publicações

sobre segurança de sistemas, o Zine chamado fatal3rror, que fala bastante sobre
diversos temas, sendo que um em específico chama muito a atenção.

Watch

Monitora determinado protocolo e, de acordo com uma palavrachave (no

nosso caso será STRUCKOWN), enviada ao servidor em qualquer hora, ele
executa uma determinada ação. Aqui está o fonte desse trojan para uma análise
mais completa:
Veja um exemplo de como esse trojan pode atuar:

Em nosso exemplo, foi criado o login "invasor", que tem permissão de root e
não precisa de senha para se conectar.

Para dificultar a descoberta do trojan, nenhuma porta adicional foi aberta. E

isso é um certo problema:
Solução

A melhor alternativa seria executar uma auditoria de portas abertas, ou possuir

um software que realize uma varredura, enviando um relatório. 0 primeiro passo
é a auditoria das portas abertas.

Existem comandos, tanto no Windows, como no Linux, que facilitam essa

tarefa.

No Windows, podemos digitar:

No Linux, os mais utilizados são isof-ienetstat-a:
 Porém, um sistema invadido não é confiável, pois o invasor pode ter instalado
os famosos rootkits.
 Rootkits são pacotes criados por hackers que podem mudar o sistemas de
diversas formas, com o intuito de abrir portas, adicionar usuários ou instalar
programas, para que o invasor não perca o acesso ao sistema. Rootkits podem,
também, ocultar determinadas respostas do sistema.

Para se ter um exemplo, vou esconder a porta 6000, que, como visto na
listagem anterior, está aberta:
 Se tais comandos forem adicionados ao arquivo /root/.bashrc, o arquivo de
inicialização do usuário, quando o bash é executado e o administrador usa esses
comandos, ele poderia passar despercebido por qualquer trojan que esteja em
funcionamento. 0 mesmo pode ser feito com o comando ps, que lista os
processos.

Há quem confie só em passar um portscanner em seu próprio servidor.

Mas isso, talvez, não resolva, pois o invasor pode ter adicionado uma regra
em um firewall.

Antivírus

Chkrootkit

0 chkrootkit atua de forma semelhante aos antivírus, porém, seu foco é

procurar pelos rootkits mais conhecidos.

Existem rootkits muito bem elaborados, que alteram até mesmo as iibs de
rede, dificultando a detecção.

Portanto, é sempre bom ter a última versão do chkrootkit em mãos.

Ferramentas de integridade

AIDE

0 AIDE (Advancedintrusion Detection Environment) cria um banco de dados

com permissões, número de links, usuário, grupo, tamanho, md5 e tudo de que
você precisa. É uma ótima ferramenta para verificar alterações nas configurações
de nosso sistema.

Nota: já tive problemas para compilar o AIDE, pois, dependendo, do sistema

ele não detecta a zlib. Portanto, se você também tiver esse problema, antes
de compilar use:

0 arquivo de configuração vem com bastante regras de seguranças:

 0 R manda verificar praticamente toda a integridade do arquivo
(p+i+n+u+g+s+m+c+md5) nos diretórios selecionados. Verifique as opções a
seguir:
 Como podemos ver, ele faz um registro completo da integridade do arquivo.
Recomendo, apenas, adicionar a seguinte linha no arquivo de configuração:

Você também pode criar regras personalizadas. Por exemplo:

Uma vez compilado e configurado, é só mandar o programa criar o banco de

dados dos arquivos nos diretórios:

Isso pode demorar algum tempo, de acordo com a quantidade de programas

que você tem instalado e com a velocidade do seu processador. 0 AIDE grava
por padrão o arquivo no diretório /var/a/de.

Tripwire

0 mais famoso software do gênero, bem mais complicado e pesado:

Ele tem um recurso bem interessante, a criptografia no banco de dados

gerado. A instalação desse software é feita por um script de instalação. Esse
script tem um arquivo de configuração que permite alterarmos os diretórios de
instalação. Você pode mudá-los a seu gosto.

Caso tenha uma versão anterior do Tripwire instalada, mude a linha:

Para:

Isso faz com que os arquivos antigos sejam atualizados. Acompanhe o

processo de instalação:

Como indica a linha anterior, pressione Enter e leia os termos da licença:

Depois, digite accept, para aceitar os termos da licença:

Nessa etapa, pressione Y:
 Nesse momento, o Tripwire vai pedir uma frase secreta. Insira uma frase
inteligente, que você não vai esquecer. A primeira é para o arquivo principal de
frases secretas. Depois digite a frase novamente.

Nota: frases secretas devem conter no mínimo oito caracteres.

 Pronto, a instalação está concluída! Agora, precisamos fazer alguns
preparativos. Digite esses comandos e, em seguida, coloque sua frase secreta.
Porém, primeiro vamos gerar o arquivo de configuração criptografado:

Algumas linhas no arquivo de políticas (twpol.txt) não vêm configuradas da

forma adequada. Temos de mudar as linha que estão com $(SEC_CONFIG) para
$ (SECBIN). Use o editor de sua preferência para localizar as seguintes linhas
dentro do arquivo:

Altere-as para:

Agora, vamos gerar o arquivo de políticas criptografado:

 Com tudo isso feito, devemos mandar o Tripwire criar um banco de dados de
nossos arquivos (como o AIDE também fez). Lembre-se de que esse processo
deve demorar um bom tempo. Execute esse comando e digite a sua frase secreta
local:

Note que, dependendo da configuração de seu sistema, alguns alertas foram

exibidos. Você deve alterar o arquivo de política novamente. Se não tiver o
programa instalado, adicione o sinal # no início da linha. Veja algumas formas
de saber se determinado programa está instalado:

Nesse exemplo, o firewaii ipfwadmin não está instalado. Então, comentarei a

linha 300:

Porém, se tiver o programa instalado, coloque o caminho correto. Veja esse

exemplo:

Esse foi fácil, o firewaii Iptables está instalado no patch, basta mudar o
caminho:

Nota: um bom administrador de sistemas deve conhecer todos os programas

que estão instalados e saber a funcionalidade de todos eles.

Salve o arquivo com todas as alterações a serem feitas e crie novamente o

arquivo de configuração codificado:

Executando novamente:

AIDE X Tripwire

Vamos fazer uma breve comparação entre as duas ferramentas aqui mostradas:
0 AIDE percebeu que nosso arquivo /etc/passwd foi alterado.

De forma simples, ele aponta tudo que foi alterado em nosso arquivo. A
varredura demorou exatos nove minutos. Vejamos como o Tripwire se comporta:
 0 Tripwire, de forma limpa, apontou que nosso arquivo /etc/passwd foi
alterado. As verificações demoraram exatos 18 minutos.

0 AIDE é mais rápido, mais fácil de configurar, além de mostrar de forma

precisa o que foi alterado em determinado arquivo. 0 Tripwire oferece
criptografia e um relatório geral mais completo e organizado. Cabe a você
decidir qual ferramenta usar.

0 AIDE ou o Tripwire devem ser executados após o sistema estar

completamente configurado e modificado de acordo com a nossa necessidade.

É altamente aconselhável que você grave em algum tipo de mídia os arquivos

de configuração e de banco de dados gerados por esses programas. Devemos
monitorá-los freqüentemente.

Auditoria de processos

Podemos achar o processo do trojan:

Mas, e se o trojan estiver com um nome mais familiar? Um simples ps -A não

é confiavel:
 Com o comando pstree, podemos encontrar qual processo está diferente dos
outros. Em nosso caso, é o httpd (4342) :
 Devemos finalizar esse processo e localizar os arquivos que possuem esse
nome:

Se tiver dúvida sobre qual arquivo apagar, use o rpm:

Como podemos ver, as coisas não são tão simples como a maioria dos
administradores pensam.

De uma forma ou de outra, um invasor prudente sempre vai tentar mascarar a

invasão e, por isso, é importante termos em mãos ferramentas nas quais
possamos confiar.
 Existem diversos scanners, sendo que cada um pode ser útil para uma
determinada função. Eles podem ser usados tanto por hackers como por
administradores de rede.

Scanners de portas

Scanner de portas procuram por portas abertas em um ou mais servidores de

uma rede, exibindo uma lista de portas que permitem conexão. Existem vários
scanners dessa categoria. Porém, vou citar somente o mais conhecido, o que
considero melhor, o Nmap.

0 Nmap é o mais rápido de sua categoria. É bem completo, podendo scannear

diversos hosts. Também tenta identificar qual sistema operacional que o alvo
está rodando.

Ele pode ser usado no modo gráfico, com o Nmapfe:

 Figura 3.1.

Ou no modo texto:
scanners de SO

Não existem muitos scanners dessa categoria, mas os que existem suprem as
necessidades dos invasores. Esses scanners verificam as respostas que o
servidores dão às conexões e identificam o Sistema Operacional no qual estão
rodando.

QueSO

O QueSO é o pioneiro de sua categoria. Ele é simples, tem poucos recursos,

mas funciona muito bem:
Cheops

0 Cheops é um scanner gráfico um pouco mais avançado. Consegue varrer

uma rede inteira, traçando uma rota entre as estações e indentificando seus
sistemas. Possui várias opções e é bem simples de usar:

Observe:
 Figura 3.2.

A nova versão do Cheops chama-se Cheops-ng (New Generation). É um

pouco mais avançada, por ser cliente-servidor.

Primeiro, você aciona o servidor:

Depois, você executa a interface:

A primeira coisa que o Cheops-ng vai lhe pedir é o endereço de uma máquina
que tenha o agente instalado, em nosso caso, 127.0.0.1. Pronto, é só rodar:
 Figura 3.3.

Nota: o Cheops-agent não possui nenhum tipo de autenticação de senha,

portanto é recomendável fechar a porta pelo firewaii e deixar o serviço ativo
somente quando estiver utilizando-o, caso contrário, qualquer um poderá
mapear sua Intranet. Acho que você não vai querer isso, não é? Finalize o
agente com: #

killall cheops-agent

Scanners de falhas

Scanners de falhas procuram por portas abertas em um ou mais servidores de

uma rede e procuram por falhas conhecidas de determinados serviços que rodam
no sistema.

Nikto
 0 Nikto é um scanner simples, feito em Perl, que procura por falhas em um
servidor. Por ter poucos recursos, ele é bem rápido, executando bem sua função:

Nessus

Esse, no meu conceito, é o melhor de todos os scanners de falha, por causa de

suas muitas funcionalidades.
 Em primeiro lugar, ele procura por todos os tipo de falhas de,buffer overflow,
Unicode, DoS etc.

A segunda grande vantagem é o fato dele ser baseado em p/ug-ins, caso uma
nova falha apareça, alguém, ou você mesmo, pode criar p/ugins que a indique e
postar no site do Nessus: http://www.nessus.org.

Ele se divide em duas partes: cliente e servidor.

0 serviço de varredura é feito no servidor, enquanto um programa visual envia

ordens para o servidor. Também é possível enviar p/ug-ins para esse servidor,
que, aliás, tem todo um controle de login e senha. Podemos controlar quem pode
enviar/apagar p/ug-/ns.

Ele permite conexão via SSL e gera uma chave privada RSA de 1.024 bit:

Nota: o Nessus vem em um script que já o descompacta, compila e instala.

Esse script já falhou, mas se pode resolver o problema adicionando o
seguinte caminho:

Agora, devemos criar um certificado para o servidor, para o cliente e adicionar

um usuário:

Para criar o certificado:

É preciso configurar esse certificado:
Isso feito, proceda à verificação:

Crie o usuário no servidor:

Depois, carregamos o servidor (que é bem pesado) e iniciamos o Nessus:

Veja a figura a seguir:

 Figura 3.4.

Entre com o login e a senha e conecte-se. 0 servidor, teoricamente, deve estar

no localhost.

Em Target selection, coloque o IP ou host do alvo, que, no caso, será você

mesmo (localhost), mas lembre-se de que ele pode varrer múltiplos hosts. Clique
em Start the scan.

A busca demora um pouco, pois o Nessus possue uma vasta biblioteca de

bugs:
 Figura 3.5.

Com a busca terminada, o Nessus mostra um relatório completo e organizado

falando onde podem ocorrer falhas no servidor e como corrigi-Ias:

Figura 3.6.
 Esse relatório pode ser salvo em Ascii, HTM, HTML com gráficos, XML,
Latex e outros.

Solução para scanners

Snort

0 Snort, um sistema IDS, pode ser útil. Ele detecta varreduras e tentativas de
invasão de vários tipos:

Feche todos os serviços que não estão sendo utilizados.

Tenha um firewaii bem configurado bloqueando o acesso externo a serviços

que somente a Intranet deveria ter acesso.

PortSentry

0 PortSentry é um monitor de redes que pode bloquear o acesso do invasor

mediante regras no firewall. Isso pode proteger o servidor de tentativas de
invasões feitas por iniciantes.

Para melhor organização, recomendo fazer algumas alterações.

 Em /usr/local/psionic/portsentry/ ficam os arquivos de configuração do
PortSentry. Porém, é melhor deixar o executável em /usr/ sbin e colocar os
arquivos de configuração em /etc/portsentry. Apesar de podermos alterar o
código-fonte, a maneira mais prática é criar um link:

No arquivo de configuração, comente a seguinte linha:

E descomente o acesso ao iptables:

Vamos executar o Nmap primeiro:

 O Nmap listou as portas que estão abertas. Agora, vamos executar o
PortSentry e o Nmap:
 Veja que o PortSentry envia respostas falsas ao Nmap, confundindo o invasor,
e, ainda, envia uma mensagem de alerta em /var/ log/messages:
 Se uma varredura está sendo feita, é possível executar o iptables bloqueando o
acesso. Porém, também podemos redirecionar esse acesso a um segundo
servidor.

Honeypots

Com o PortSentry, também podemos redirecionar o acesso a um segundo

servidor. Esse servidor é chamado de honeypot e deve conter algumas portas
abertas, que simula determinados serviços rodando; isso criará logs das ações do
invasor:

Figura 3.7.
 Single honey-pot

0 programa Single honey-pot é um dos mais simples de instalar. Ele vem com
um script de instalação:
Com ele instalado, faça uma cópia dos arquivos /etc/services e /etc/inetd.conf:

0 arquivo /etc/services deve conter as seguintes linhas:

0 arquivo /etc/inetd.conf deve conter as seguintes linhas:
Crie um arquivo simulando um is de sua máquina:

Vamos simular um acesso ao nosso honeypot:

 Enquanto isso, nosso honeypot estava registrando tudo que o invasor tentava
fazer:
 Dificilmente encontramos um servidor Web que não tenha nenhum script
PHP, Peri, ASP etc. Nesse capítulo, estudaremos falhas de codificação em sites e
utilizaremos, para tanto, PHP, MySQL, Apache e Linux. Portanto, certifique-se
de que os módulos de PHP e o MySQL tenham sido instalados. Se não, instale-
os.

Abra o arquivo de configuração do Apache (no Suse Linux 10 fica em

/etc/apache2/defau/t-server.conf) e altere o root no servidor de teste:

Descomente ou adicione as linhas em suas devida seções:

E adicione ao campo Directorylndex o arquivo index.php:

Inicialize ou reinicialize o seu HTTPD:

Unicode

Unicode é um sistema de invasão muito usado em servidores que provem

HTTP ou HTTPS. Esses sistemas são usados para diversos motivos, como login
em uma loja virtual, ou, simplesmente, para deixar a aparência melhor.

Vamos criar alguns arquivos de teste.

O arquivo cima.php é simplesmente um cabeçalho inicial do suposto site:

0 baixo.php é o rodapé:
 Como já podemos perceber, index.php é a pagina inicial:

0 arquivo imagelist.php é uma página contendo um script que iremos explorar.

Esse script irá criar links para determinadas pastas a partir de $topdir. Se a pasta
clicada tiver imagens, ele irá pegar a resolução e criar um link para que possa ser
exibida. E assim recursivamente:
Usaremos o arquivo restrito.php:
Nota: preste muita atenção na permissão de acesso a esses arquivos.

Feito isso, vamos ver como o site ficou:

 Figura 4.1.

Aparentemente, parece estar funcionando de acordo.

Mas o script não deveria permitir a volta de diretórios indevidamente, e não é

isso o que está acontecendo. Ele não tem nenhum filtro.

Ataques com Unicode podem ser feitos simplesmente com um browser.

Vamos ver o que acontece se forçarmos uma navegação inversa:

Veja o resultado:
 Figura 4.2.

Como podemos ver, eu consegui obter uma listagem dos usuários da máquina,
mas o problema é mais grave do que aparenta.

Estamos executando um comando extremamente perigoso no PHP, o exec ().

Vejamos o que acontece se digitarmos a seguinte linha:

 Figura 4.3.

Aqui, eu obtive uma listagem do arquivo usando 1 cat/etc/ passwd, mas, do

mesmo modo, poderia apagar um arquivo, fazer um download usando o wget, e,
depois, executar tudo a que o servidor HTTP tivesse acesso:

SQL Injection

Scripts PHP, ASP e de outras linguagens podem conter falhas fechando a

string com ' (aspas) e isso também pode acontecer com o Kylix (mesmo criando
um CGI binário). Em nosso exemplo, iremos burlar o controle de login de uma
página PHP com MySQL. Para isso, será necessário criar algumas tabelas e
adicionar alguns dados:
 Inicialmente, vamos efetuar o login normalmente. Fizemos um insert na tabela
tbusuário com o usuário master e a senha "minha senha":

Figura 4.4.

0 nosso objetivo, aqui, é tentar entrar sem saber usuário ou senha. No campo
de usuário, vamos colocar o seguinte texto 'or 1=1#:
 Figura 4.5.

No campo senha, digite teste. Clique no botão Verificar:

 Figura 4.6.

Entramos! Agora, como isso pode ter acontecido? Para entendermos melhor o
que ocorreu, vamos alterar a variável $bDebug no arquivo restrito.php colocando
como True. Isso irá retornar as consultas executadas nesse script:

Vamos atualizar a página:

Figura 4.7.

Como podemos notar, a consulta final foi alterada, pegando o primeiro login
cadastrado. Nessa consulta, o script tenta localizar o usuário ", ou qualquer outra
coisa. 0 caractere # ignorou tudo em seguida:

Essa é uma falha muito grave. Com isso, um usuário mal-intencionado

poderia, até mesmo, alterar dados no banco de dados em comandos similares a
esses:
 Também é possível obter informações do banco de dados e, em alguns casos,
até executar comandos. Exibir as tabelas do banco de dados:

Tabela 4.1.

Nota: vale lembrar que bancos de dados de grande porte, como o SQL
Server, Oracle, e outros contém storedprocedures perigosas. Tais procedures
devem ser eliminadas ou setadas em regras de permissões, evitando que
CGIs/Scripts tenha acesso a elas. No SQL Server, por exemplo, é possível
executar comandos com extended procedure: master..xp cmdshell.

Mesmo em um CO binário, é possível explorar esse tipo de falha. Uma vez,

em um sistema feito em Kylix, foi notado uma falha que permitia ao usuário
aumentar seu acesso:

Uma solução simples e rápida foi colocar as entradas do usuário como

parâmetro do Tquery:
 Felizmente a falha foi corrigida antes de o CGI ir para o ar. Fique atento ao
site oficial de bibliotecas externas, caso você use alguma, ela pode conter falhas.

Soluções para falhas de códigos em sites

Devemos prestar muita atenção ao criar um CO ou um script em um servidor.

Tais arquivos devem conter filtros para excluir caracteres não pertencentes a
letras e números, sempre que necessário, como, por exemplo, ./\&r I %$@!.

Comandos perigosos, como exec() devem ser evitados a qualquer custo e, se

aplicados, devemos evitar qualquer input do usuário, como parâmetro do
comando.

Todos os scripts e CGIs podem conter falhas de acordo com sua programação,
independente da linguagem usada.

Auditoria de Iog

Nunca deixe de analisar os logs do servidor. Ele pode dar pistas de possíveis
tentativas de invasão por Unicode. Normalmente, os invasores usam como teste
de invasão o arquivo /etc/passwd. Use o comando cat e alguns filtros para
visualizar seu log:
Analog

0 Analog é um dos melhores e mais conhecidos programas para auditar os

logs do Apache. Ele é mais voltado para análise de tráfe go, mas não deixa de ser
uma ferramenta interessante. Ele vem com um script para que essa análise seja
feita via Web.

Nota: é extremamente recomendável o acesso a serviços desse tipo via

HTTPS, caso o acesso seja remoto.

Então, ele deve mostrar uma página que permite escolher os relatórios que
podem ser visualizados. Selecione uma e clique no botão Produce statistics:
 Figura 4.8.

Curiosamente, Directory Report apontou que foi executado o comando cat:

0 Request Report mostrou uma informação um pouco mais completa:

Veja:
 Figura 4.9.

Então, obtive um relatório mais completo, dizendo a origem e com todos os

acessos:
 Caso tenha mais uma ferramenta de administração via Web como esta, mova
para uma pasta protegida por senha.