Teste de intrusão 3

veronmaiden Qui Jul 08, 2010 5:17 pm

Nos primeiros 2 capitulos deste megatutorial vimos como funcionavam as técnicas de footprinting e fingerprinting e vimos algumas ferramentas como a google hacking database, os traceroutes, nmap ou hping2 (já está disponível hping3). Agora vamos a estabilizar-nos na busca de vulnerabilidades.

Identificação de Serviços e Software:
Uma vez que sabemos quais são os sistemas operativos, firewalls e/ou portas abertas é necessário descobrir as versões de software que correm por esses serviços. O primeiro é tentar ver a informação que nos oferece abertamente. Para isso, costuma bastar uma conexão e apanhar o banner do mesmo serviço. No tópico anterior vimos como respondia um servidor web, mas isto pode-se realizar com serviços FTP, SMTP ou Listeners de Bases de Dados.

Imagem:
Link: http://cache04.stormap.sapo.pt/fotostore01/fotos//6d/bc/47/1772026_qH8sL.jpeg

Imagem:
Link: http://cache04.stormap.sapo.pt/fotostore02/fotos//28/25/f1/1772024_PZJLv.jpeg

No caso de não poder afinar com o banner, com a inferência de cruzar o sistema operativo, a porta utilizada, etc…, para identificar a versão, teremos que utilizar ferramentas de de serviço fingerprinting. A maioria dos scanners de vulnerabilidades (que vamos ver no terceiro artigo) implementam estas técnicas para a maioria de serviços. Uma vez instalado o software, é preciso procurar os problemas.

Bug:
O bug ou erro de segurança é uma característica de um software que pode fazer com que o programa funcione incorrectamente ou de maneira não pensada. Muitos hackers definem bug como “funcionalidade não definida de um programa”. Entendemos como Software confiável aquele que faz o que tem que fazer e como software seguro aquele que faz o que tem que fazer e mais nada. Esse algo mais entre o software confiável e o software seguro são os bugs.

Um software não tenha bugs é muito difícil de se conseguir, é preciso levar em conta que um programa escrito em linguagem C, compilado com dois compiladores diferentes não gera o mesmo código binário, depois um mesmo código pode ser ou não vulnerável dependendo de compiladores, arquitecturas onde se execute, linkadores, etc..

Na busca de bugs se utilizam duas técnicas diferentes, as que podem realizar-se manualmente e com olhos espertos, mas que se automatizam e que são as ferramentas de análise estático de código e análise dinâmico.

Ferramentas de Análise Estático de Código:
Este tipo de ferramentas mantêm uma base de dados de patrões reconhecidos como erros de segurança, como cópia de parâmetros com strcopy sem comprovar tamanhos, etc… e o que realizam é uma busca desses parâmetros no código de um programa sem que este se esteja executando. Esta forma de scanear o código é o que recebe o nome de análise estático. Estas ferramentas podem analisar códigos em ensamblador, desensamblados directamente do binário, ou códigos fonte em linguagens mãe con .NET, C, php, C++, etc… ou em códigos intermédios como Bytecodes ou IL. A diferença qualitativa entre estas ferramentas é a base de dados de patrões que utilizam e a maioria das grandes casas de desenvolvimento de software consideram isto como um conhecimento competitivo e de valor da companhia. Microsoft, desde o ano 2002, utiliza ferramentas próprias de análise de código estático em todos seus produtos. No mundo do software livre, por causa do projeto “bug hunting” financiado pelo governo americano, utiliza à companhia Coverity para realizar análise estático de bugs nos principais projetos de software livre desde Janeiro de 2006. Os relatórios com os primeiros resultados das análises de Coverity estão disponíveis em http://scan.coverity.com

Existem múltiplas ferramentas de Análise Estática de Código disponíveis no site, e inclusive, muitos compiladores acompanham seu ambiente de desenvolvimento com ferramentas deste tipo, como por exemplo FxCop em Vistual Studio que comprova transbordamentos de buffer, condições de carreira, etc…

Imagem:
Link: http://cache04.stormap.sapo.pt/fotostore02/fotos//e1/11/e8/1772061_OlqWd.jpeg

Projeto Bug Hunting:
Em Janeiro do ano 2006 começou as instâncias de uma universidade e o governo Americano do projeto Bug Hunting, cujo objectivo era analisar os 50 projetos Open Source mais populares com as ferramentas de Análise Estático de Código da empresa Coverity. Os resultados que apareceram em Março de 2006 (um ano para quando saia publicado o artigo) estão disponíveis na seguinte URL: http://scan.coverity.com. Se pode ver na tábua, alguns dos resultados que se obtiveram depois de utilizar as ferramentas de análise estática.

Imagem:
Link: http://cache04.stormap.sapo.pt/fotostore02/fotos//d0/7d/09/1772011_HAn8c.jpeg

Ferramentas de Análise dinâmico:
A busca de bugs com ferramentas de análise dinâmica tem outra aproximação diferente. Neste caso o programa a avaliar se executa e lhe passam provas e verificações automáticas que vão avaliar as respostas e todo tipo de situações diferentes. Uma ferramenta deste tipo deve ser capaz de avaliar todas as possibilidades de todos os pontos de entrada de informação desde qualquer ponto externo para a aplicação e detectar os casos anómalos.

Alguns exemplos de ferramentas deste tipo são Valgrind, pensada para detectar condições de carreira em ambientes multihilo e erros de cor, Dmalloc.h, que é uma livraria que se usa para comprovar as reservas de cor ou VB Watch que injecta códigos de análise dinâmicos dentro dos programas para monitorizar seu funcionamento.

Exploits:
Uma vez que se encontraram os bugs, o objectivo é criar uma ferramenta que saque partido deles, isto é, que seja capaz de fazer uso dessa “funcionalidade não definida do programa”. Para isso, se analisam as possibilidades e alcance desse bug e se opta por um determinado exploit. Todos os exploits têm duas partes diferenciadas, a cabeceira, que é o que se denomina exploit puramente, e o corpo, denominado payload. A cabeceira é a parte artesã que depende de cada bug concretamente, enquanto o payload são ações já programadas que se reutilizam. Por exemplo, uma ação típica de um exploit seria devolver uma a shell de comandos da máquina explorada a um determinado porto. Este payload se vai poder reutilizar para múltiplos cabeceiras diferentes.

Metasploit Framework:
Esta ferramenta é uma ferramenta básica na tarefa de realizar um teste de intrusão em uma empresa. É um ambiente que aúna uma base de dados de cabeceiras de exploits e de payloads para poder realizar o teste em uns determinados servidores. Actualmente na versão 3.0 em beta 3 tem um actualizador automático das bases de dados e ferramenta de administração site.

Imagem:
Link: http://cache01.stormap.sapo.pt/fotostore01/fotos//4e/bb/e7/1772017_ZOsiR.jpeg

Na seguinte imagem pode-se ver como, mediante o interface web, podemos configurar os diferentes payloads para um exploit, neste caso, um exploit de Samba para Linux.

Imagem:
Link: http://cache01.stormap.sapo.pt/fotostore02/fotos//ec/87/6a/1772014_zi1f1.jpeg

0 days:
O termo “0-days” se vai repetir muito nas auditorias de segurança:

- Um servidor em 0-days é aquele que tem actualizado todo seu software às últimas versões, isto é, que o software não tem nenhum bug conhecido. Esse é o ponto mais seguro em que se pode ter o software de um servidor.

- Um exploit de 0-days é aquele que funciona em servidores 0-day, isto é, que actualmente não existe uma versão de software mais moderna para solucionar esse problema.

O objectivo de uma auditoria de segurança será obter um servidor de 0-days e, se existissem exploits de 0-days, tomem as medidas para que o software vulnerável não se veja exposto. Isto é, bloqueando petições em firewalls, fortificando as restrições nas máquinas ou com políticas de segurança nas diretivas de segurança da rede.

POC e Os Meses temáticos:
Quando se quer realizar um teste de intrusão completo em um servidor, não valem só as ferramentas comerciais e as que nos oferecem os fabricantes já que há muita informação que não sai pelos canais comuns. As chamadas Provas de Conceito (POC) actualmente são muitas e é normal que se saiba que existe um exploit mas que não seja de uso público. Durante o ano passado H.D. Moore, um dos principais contribuintes ao projecto Metasploit, decidiu realizar meses temáticos junto de outros pesquisadores de segurança, orientados a buscar exploits 0-days em diferentes áreas. Assim, durante o mês de Julio se centrou nos navegadores de Internet, durante o mês de Novembro nos kernels dos sistemas operativos, durante o mês de Janeiro em Apple e já, Stefan Esser anunciou para o mês de março, o mês dos erros em PHP. Haverá que estar atentos. Nestes projectos “temáticos” o objectivo é buscar um bug por dia e fazê-lo público. Isto, logicamente, acho muita controvérsia já que os canais de informação tradicionais são os de avisar ao fabricante para que o corrija sem que os clientes fiquem expostos. Esta controvérsia levou, a que se anunciasse para a última semana do ano 2006 a Semana dos erros de Oracle Database, por parte de Cesar Cerrudo, um investigador de segurança centrado em Bases de dados, mas, devido à pressão pública a cancelasse.

As POC podem encontrar-se em muitas Websites dedicados à segurança informática: FRSirt (http://www.frsirt.com), Milworm (http://www.milwOrm.com) ou Packet Storm (http://packetstormsecurity.org/) são alguns dos mais utilizados.

Imagem:
Link: http://cache03.stormap.sapo.pt/fotostore02/fotos//bb/64/e4/1772021_rKCjU.jpeg

Os meses temáticos se podem encontrar nas seguintes URLS:

Imagem:
Link: http://cache02.stormap.sapo.pt/fotostore01/fotos//0a/da/46/1772023_QhW5G.jpeg

Bom pessoal por hoje termina…

Fim do capitulo-3.

Autor: placker

Comentem esse tutorial