Bind: Explorando e evitando falhas

Cooler_

Bind é o servidor de DNS mais popular da Internet e consequentemente o mais popular quando se fala em vulnerabilidades. Saiba neste artigo como explorar suas falhas, assim como evitá-las.

[ Hits: 36.883 ]

Por: C00L3R_ em 21/08/2008 | Blog: https://github.com/CoolerVoid

0 0

Denuncie Favoritos Indicar Impressora

Explorando

Onde vejo versões vulneráveis de BIND e onde encontro Exploits?

Isso é simples, gosto de procurar exploits no "milw0rm" direto, sem perder tempo no Google, mas para quem tempo acho bacana procurar exploits no Google russo, turco, árabe e não só no Google "BR", pois este é muito limitado. Google gringo tem mais chance de encontrar exploits que não foram postados no milw0rm, packet storm etc. Vou deixar um exemplo de exploit novo aí:

http://www.milw0rm.com/exploits/4266

Ele está sendo muito usado para envenenamento de DNS explorando o "Bind 9".

Tem também exploits remotos como este:

http://www.milw0rm.com/exploits/282

Como posso automatizar meus scans de Bind?

Você pode fazer isso com shell script, perl, python, C, ruby ou qualquer linguagem. Veja uma idéia lógica:

for ( $variavel=0; $variavel<=255; $variavel++) {
nslookup -type=txt -class=chaos version.bind 202.12.12.$variavel
}

Loop simples para escanear uma faixa de IPs de 1 a 255.

Também podemos usar o "nmap" procurando hosts com BIND:

# nmap -sU -vv -P0 -A -D ip_laranja 200.21.12.1-255 -p53

A idéia deste comando foi mandar scan com pacotes datagrama (-sU=UDP scan) na porta 53 do BIND, este ip "200.21.12.1-255" na sua faixa final vai de 1 até 255, ou seja, ele escaneará 255 máquinas. Aí você coloca a faixa de ip que quiser...

Como posso evitar que meu servidor receba estes ataques?

Com o IDS Snort você pode tentar colocar um alerta toda vez que alguém procura saber a versão do seu Bind, ou scan UDP etc.

Use a regra:

alert UDP $EXTERNAL any -> $INTERNAL 53 (msg: "IDS482/named-exploit-tsig-infoleak"; content: "|AB CD 09 80 00 00 00 01 00 00 00 00 00 00 01 00 01 20 20 20 20 02 61|"

A forma mais simples de evitar é manter seu BIND atualizado e manter controle de usuários no servidor, saber quem entrou e quem saiu...

Terminando por aqui, um salve pro pessoal.

Página anterior

Páginas do artigo

   1. Introdução ao Bind
   2. Descobrindo a versão do Bind
   3. Explorando

Outros artigos deste autor

Trabalhando com arquivos no Perl

Apache + PHP + MySQL + ftpd no OpenBSD

Buffer Overflow: Entendendo e explorando

Ponteiros - Saindo de Pesadelos

Usando o PF - Packet Filter

Leitura recomendada

OSSEC HIDS - Instalação e configuração no CentOS 6.5

Nmap do início ao fim (parte 1)

Como forçar alteração de senha de usuário no próximo login no Linux

VPN: IPSec vs SSL

Criptografar sua atual partição root usando dm-crypt com luks

Comentários

[1] Comentário enviado por y2h4ck em 21/08/2008 - 10:59h

Bom, nosso amigo do artigo nao comentou mas a grande maioria 99% dos ataques a servidores de DNS como o bind por exemplo acontecem nao devido a versao deles... mas sim a configuracao.

Entre as principais vulnerabilidades encontradas esta:
- Recursividade Habilitada;

Estas ultimas falhas de Cache Poison principalmente referen-se a configuracao e nao a versao.

O artigo ficou bem simples e superficial, mas deu pra passar uma ideia basica pro pessoal.

[]s

0 0

[2] Comentário enviado por Cooler_ em 21/08/2008 - 14:41h

99% foi um numero estranho não...( se ainda tem falhas de DCOM por ai por que não teria bind antigos ? ),mas este artigo meu é antigo retirei da Cóva de um dos muitos artigos que fiz não publicados...

quanto a "cache poison" estava analisando um exploit agora vi que é bacana
http://www.securiteam.com/exploits/5DP0220MAO.html

Mas acho que você y2h4ck esta mais atualizado devia passar um artigo para os irmãos do site ;)

0 0

[3] Comentário enviado por diegofsouza em 22/08/2008 - 08:24h

Um ponto errado no bind gera uma dor de cabeça enorme. Vlw pelo artigo. Vai ajudar muito!
Grande abraço.

0 0

[4] Comentário enviado por y2h4ck em 22/08/2008 - 20:13h

"grande maioria 99% dos ataques a servidores de DNS" nao sei se vc sabe mas o DNS nao tem DCOM :)
Bom ... nao e questao de estar mais atualizado ou nao, a questao e que e simples ... as falhas de DNS estao intrincicamente relacionadas com permissividade nas informacoes que eles fornecem e nao exatamente em fornecer o meio de acesso.

Como voce deve saber servidores de DNS sao os principais e mais procurados no momento de enumeracao pois e deles que vao partir os outros ataque seja a rede local ou seja o perimetro externo. Mas nao vou perder tempo aqui te explicando isso afinal vc sabe do que eu estou falando.

Nao precisa ficar nervoso so pq eu disse que o artigo e superficial, afinal, vc realmente acha que ele e aprofundado ??

Com relacao aos 99% ... eu acho que estou bem atualizado :)

forte abraco.

y2h4ck

1 0