Levantamento de informações de um servidor.
Técnicas não intrusivas e passivas, quando possível.
Autor: Paulo. (^[H,L]aetc - raio de nome esquisito)
Todos os dias, aparecem nos logs de servidores espalhados pela Internet os registros de técnicas diversas de scanning. Quais eventos serão registrados e talvez compreendidos como uma varredura pelo administrador, depende da técnica empregada e da habilidade do administrador. O objetivo aqui é mostrar formas de se obter informações de um alvo, recorrendo à ferramentas tradicionais de rede, quando possível. Mostrar que na verdade o uso de IDS e firewall nunca deve ser usado como a solução de todos os problemas, e de que o cuidado com as falhas é prioritário.
Partindo de um exemplo fictício: a página sbrubles.com , dedicada à disseminação dos conhecimentos da Confraria do Pinguim Artista, C.:P.:A.: . Um dissidente da ordem, sabendo ser a página sbrubbles.com ligada à Grande Loja do Peixe Dourado, pelo
R.:E.:A.: (rito esquimó antigo, favor não confundir com rito escocês antigo. Tudo bem que os esquimós estão no Polo Norte e os pinguins no sul, mas eu preferi usar uma licença poética.), decide que desfigurar a página traria desonra à ordem. Dominado
pela inveja, Isaac, o neófito frustrado, segue à risca os ensinamentos da Escola script kiddie de aporrinhação:
1) Ele roda um programa scanner, como Stealth ou similar, para verificar se existem falhas exploráveis no servidor.
2) Ele cola o resultado do scanner em um fórum de discussão, perguntando: (SIC) "SCANEEI UM SEVIDOR NAUM SEIO QUE EU FASSO ELE MOSTRA ESSE TAL DE UNICODE COMO EXPLORAR EU NAUM SEI O QUE FAZER DIGAM PRECISO OWNAR ESSE SITE".
3) Alguém, achando que é mais fácil se livrar do chato assim, simplesmente manda o cara pegar o exploit exatamente no endereço fornecido pelo próprio scanner. O Isaac o faz.
4) Oh, precisa ser compilado! Bem, esses detalhes seriam muito sórdidos.. no final das contas ele consegue, depois de
encher o saco das pessoas em um canal de IRC.
5) Ele testa um dos exploits, quebra a cara pq é um exploit local, não remoto. Usa outro, e pensa que deu certo. Nada. falhou miseravelmente.
Voltando agora para C:.P:.A:. Eles possuem firewalls e IDS em seus servidores, e a tentativa de Isaac foi observada com um sorriso sarcástico pelo Grão Mestre ROOT, cujo uid é 0, membro do círculo fechado wheel, e autoridade máxima. Uma olhada nos logs forneceu ao ROOT informações bastante interessantes como IP de origem, data e hora. As tentativas de scanning foram prontamente percebidas devido ao IDS instalado. As informações recebidas pelo scanner eram falsificadas de modo a enganar a horda de script kiddies que rondava o site.
Ergam seus fortes, Mestres do círculo wheel! Ergam suas muralhas, e coloquem seus Sentinelas e Porcos guardiães a postos! (portsentry e snort pra quem não sacou) Mas não se esqueçam de apagar as placas indicando o caminho para a cidade, e entendam que invasores espertos e furtivos podem estar à espreita!
Vejamos de que forma podemos aprender mais sobre um alvo (aprender realmente), e não fazermos muito barulho. Visite a página: o que vemos? Talvez algum comentário, banners e coisas do tipo te dizendo que o servidor roda o sistema operacional xyz e o webserver sbrubles? Telefones? Informações sobre firewall? Serviços fornecidos naquele servidor, ou ainda o hardware empregado, se ele está ou não em cluster, e possíveis portas abertas (fora a http, que vc ja sabe).Vaidade, vaidade.. a primavera da vida, e o ego dos administradores, tudo é vaidade. Veja quanta informação pode ser encontrada quando há descuido. Temos ainda uma outra fonte importante de informações: whois. Basta usar um cliente de whois, ou simplesmente acessar uma página que ofereça o serviço. Aqui no Brasil, os domínios são fornecidos pela Fapesp (Fundação de Amparo à Pesquisa do Estado de São Paulo), e você pode fazer uma "whois query" na página registro.br . Para outros lugares, visite o IANA,
www.iana.org .
Muito bem, temos algumas informações.. mas o que mais podemos saber? Nem sempre temos um manancial tão grande de informações no próprio site. Ponto positivo para o mestre root. O que Isaac precisaria saber sobre o servidor?
Vamos usar de um comando bastante simples.. ping. Exemplo em localhost:
Quote
redog:~# ping -v -s 1 -c 2 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 1 data bytes
9 bytes from Redog (127.0.0.1): Echo Request
9 bytes from 127.0.0.1: icmp_seq=0 ttl=255
9 bytes from Redog (127.0.0.1): Echo Request
9 bytes from 127.0.0.1: icmp_seq=1 ttl=255
--- 127.0.0.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
Aqui eu envio um datagrama de 9 bytes com echo request. São 8 bytes para o cabeçalho e um para o payload, embora o default no linux seja de 64 (8+56). Repare o valor do ttl. TTL significa Time to Live, e é um parâmetro dos cabeçalhos de datagramas ip. A cada roteador/host que o pacote passa, esse valor é decrementado em 1, e se por acaso ele expirar(ttl=0), ele é descartado. Um valor como
255 é utilizado por diversos sistemas. O kernel 2.4+ do linux é um exemplo. Kerneis antigos usavam 64, se não me engano. Note tambem que alguns sistemas utilizam valores de ttl diferentes para echo replies e para conexões TCP/UDP. De qualquer forma, esse ping pode revelar se:
1) A máquina está ativa
2) Se os pacotes icmp estão sendo filtrados
3) qual o ttl usado, pode ajudar a identificar SO (ajudar.. e pouco), e dispositivos de rede.
Para mais informações sobre como usar ICMP para verificar hosts, consulte um texto de Ofir Arkin, acho que é ICMP scanning techniques. Dá pra achar na internet.
Ok, vemos aqui um ttl de 255, o que exclui máquinas windows, que, até onde eu sei, usam 128, com exceção do windows 95 (32 eu acho..). Se vc quiser saber qual é o sistema operacional usado, essa informação não é suficiente. 255 pode ser tanto um linux 2.4 (qual distro? nem imagino), um *BSD, etc.. Para isso, precisamos de técnicas mais avançadas de fingerprinting. Fyodor mostra várias técnicas em um artigo que pode ser encontrado em
www.insecure.org. O nmap, ferramenta criada por ele, é capaz de identificar vários sistemas com grande precisão, além de ser um ótimo portscanner. Dê uma olhada, e teste as opções "furtivas" dele.
Continuando, poderíamos ainda ver que portas estão abertas, e quais serviços rodam nelas.. o isaac poderia ainda estar lendo isso e ficando irritado pq eu não vou ensinar o peste a usar o nmap.. ele tb quer saber o S.O! Ta bom, ta bom.. eu vou tentar passar por algumas coisas que poderiamos fazer sem precisar forjar pacotes.
Um firewall irá possivelmente bloquear as portas fechadas, e vc não recebe nenhuma resposta. O IDS, como PortSentry, Snort e outros, sacaria rapidamente que vc está tentando scannear. É muito comum (eu particularmente acho divertido.. perdão, eu não deveria rir da desgraça dos outros.. LOL ROFLMAO!!! :DDDD) alguem scannear o servidor e ver que todas as portas TCP, de 1 até sabe-se lá qual, estão abertas. Parabéns, vc encontrou um IDS. E não, não vai conseguir usar finger, ele não está lá. Qual deles é o certo? questão difícil.. :P . Bem, isso posto, a idéia é que um atacante esperto pode usar bouncing, acessos com intervalos de tempo bastante grandes, e acessos a partir de diversos hosts. Outra coisa é que vc não precisa acessar todas as portas, visto que ninguem usaria quotd, chargen, tftp ou telnet em um sistema que se diz "seguro".
Mas o que tem em cada porta? As portas TCP/UDP oficiais são listadas no RFC 1700. Se vc usa linux, tambem pode encontrar a lista dos serviços em /etc/services. Vamos então checar se as portas 80 (http), 443(https), 22 (ssh) e 21(ftp) estão disponíveis. E tb, o que podemos saber sobre os serviços, e acredite, tb o SO :-)
Para isso, podemos usar o nosso amigo netcat. O netcat é uma excelente ferramenta, capaz de usar TCP e UDP, não possui as limitações do telnet quanto a caracteres especiais (ele não muda nada. Não use para jogar MUD, ele não vai filtrar os códigos ANSI de cores! :P) como EOF, pode escutar portas, é em suma, um canivete suíço. E como poderíamos usar esse canivete?
Bem, vamos checar a porta 80 primeiro.. podemos usar o netcat para enviar uma requisição inválida e descobrir o servidor utilizado. Outra forma seria simplesmente conectar-se ao alvo usando lynx e teclar = . Com o netcat, poderíamos fazer isso:
Citar:
|
Originalmente enviado por [b
|
Normalmente temos a resposta, como Apache 1.3.22 ou IIS blablba.. Claro que pode-se forjar isso, assim como fingerprinting, e eu posso falar disso em outra ocasião. Bem, anote a versão do servidor.
O que poderíamos saber do ssh? Bem, testando aqui, temos..
printf 'nao entendo nada de ssh\n' |nc 127.0.0.1 22
SSH-2.0-OpenSSH_3.4p1 Debian 1:3.4p1-1
Protocol mismatch.
Aha! Temos aqui até a distribuição utilizada.. Cool. Versão do protocolo, do openssh e tb sabemos agora que estamos lidando com um Debian. Claro que eu já sabia disso, o computador é meu :P.
Claro que não se usa ssh assim. Nem sonho em usar ssh com telnet ou algo parecido.. Oh, lembrete: muitos ids fecham detectam scanning depois que vc se conecta a pelo menos um numero x de portas seguidas. Com 4, pode ter certeza que vc é percebido.
Bem, tentando então dias depois, ou de outro host, podemos dar uma olhada na porta 21 e só por curiosidade, ver se o alvo roda rpc.
Bem, muito fácil. Fazendo ftp ftp.exemplo.com.br , podemos ver se o acesso anonymous é permitido. Aproveite e veja tb se o banner
mostra qual é o servidor usado. Imaginando que vc consiga acesso via user ftp, aproveite para rodar SYST, usar get para pegar um binário do sistema e alguns ls -l aqui e acolá para identificar lugares onde vc tenha permissão de gravação. Ok, digamos que vc pegou o ls do host alvo. Basta usar o file:
$ file ls
ls: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), stripped
ELF=Executable Linux File. Precisa dizer algo mais?
Oh, eu deveria falar sobre rpc tb? man rpcinfo. Use rpcinfo -p host para ter uma lista de todos os programas RPC. NFS costuma ser um exemplo.. :/
Outro exemplo de descoberta do serviço por banner (+ 1!) é o smtp. Cheque tb, de outro host. Vamos ver tb o que poderíamos saber desse serviço. Primeiro, a versão dele. Segundo, podemos verificar logins válidos. Conecte-se ao servidor. O mais comum é o Sendmail, e vc poderá ver a versão do serviço (a não ser que tenham mudado). O qmail, por outro lado, não mostra a versão =:-) . Ok. Você conhece vrfy e expn? Eles podem te dizer se um usuário é válido no sistema, use vrfy nome . Bem, essa é uma opção normalmente desabilitada. Cheque pra ver se vc não esqueceu.. dê um vrfy root. No entanto, se o servidor estiver em open relay, vc pode verificar usando rcpt to: userquevcquertestar@host.com. Não mande o email..
Eu estou aqui acreditando que conheça algo de smtp. Perdão, mas vocês podem aprender sem mim. O quanto vc conhece dos serviços ajuda a extrair mais informações.. bem, vamos pensar em mais algumas poucas técnicas, dessa vez passivas.
Ótimo, temos informações de whois, e não precisamos acessar o alvo para isso. Navegação na página e checar o serviço não chama tanto a atenção.. bem, talvez o segundo. De qualquer forma, comparado com usar um scanner da vida, é como comparar um rato e um elefante espiões.. De onde mais tiramos informação? Bem, poderíamos usar um sniffer.. acreditando-se que haja um meio de se instalar um no mesmo segmento de rede do alvo. Nem sempre é possível. Droga, o que resta? Oh, que tal conseguir informações através do
DNS? Jay, do Bastille Linux, escreveu um texto bastante interessante sobre como se evitar ataques via DNS, e ele mostra como nslookup e dig (duas ferramentas bastante interessantes) podem ser usadas para se obter informações da rede (how to spoil dns attacks, eu acho). Vale a lida. Leia tb o manual do dig, e RFCs correspondentes. Infelizmente, eu não fiz nada disso que eu estou recomendando, logo vc pode imaginar que eu não sei nada de DNS (bah, eu devia ter coisa melhor pra fazer :p).
Bem, o que nos resta? Oh, temos CGI tb.. será que temos falhas aqui?
http://www.wiretrip.net/rfp . Whisker é a solução. ele possui diversas técnicas para passar por ids. Note que vc pode verificar os arquivos, usando GET ou HEAD, pode tb usar // para despistar o ids, etc.. tudo na unha. Mas convenhamos, uma hora tinha que cansar, não? Eu já não estou cansado de escrever esse treco? Vc ja não está cansado(a) tb? Baixa o whisker..
O que mais pode ser feito? Bem, temos o resto da rede, não é mesmo? E claro, roteadores, switches, etc.. todos esses podem dar informações sobre a rede em si, e seus hosts. Bem, eu estava falando de um host só, não? Bem, snmp e coisas parecidas não irão caber nesse texto. Ora, mas não tem mais nada a ser dito? Ta, ta.. Se o alvo estiver atrás de um firewall que não cheque o estado da conexão (e argh! configurado de forma a permitir qq tráfego vindo da porta 53 (DNS) ), vc pode usar hping2 para forjar pacotes que passem por ele, cuja porta de origem é 53. Pode querer usar nmap, visto que banners podem ser facilmente mudados e vc pode ter dificuldades em reconhecer o S.O. A descoberta do S.O. pode ser feita juntando peças.. bem, temos esse ttl, o servidor roda asp, etc.. Bem, se vc der uma lida no artigo do fyodor sobre OS fingerprinting, pode ver exemplos de como sistemas diferentes implementam a pilha TCP/IP, e se puder forjar os pacotes, pode fazer o levantamento de vários hosts, e com janela de tempo significativa. Exemplo, vc envia um pacote FIN e ve a resposta, e por aí vai. Outra forma de se obter essas informações é pelo netcraft.
www.netcraft.com acho eu. Veja que mesmo a falta do banner não necessariamente significa que tudo está perdido. Muitas vezes, basta digitar help (depende do serviço) e o servidor se denuncia. As mensagens de erro tb podem mudar (exemplo, iis x apache), e quanto mais vc os conhecer, mais fácil será essa identificação. Oh, e vcs já viram que muitas vezes é colocado um arquivo passwd falso em servidores de ftp? Bem, mas imagine que a linha do root não sofreu alterações.. Qual é mesmo o *nix que usa "Charlie" como nome real do root? Será que é exclusivo desse "sabor"? Algumas particularidades podem ser bem aproveitadas. Ah, e nem me lembro mais qual é.. por favor, quem souber me fale.
Fico por aqui. Deixo claro que esse texto não é destinado aos script kiddies. Não use as informações aqui para prejudicar os outros, ainda mais pq isso não é um kit enlatado de invasão. Use para verificar suas defesas e/ou para aprender sobre os protocolos, e como funcionam as diferentes versões dos serviços. Vou ver se brinco com Apache aqui, e em breve, escrevo algo sobre edição de banners e formas de se criar uma nova assinatura para o S.O. Que tal fazer o seu linux fingir que é um VAX? hehe.
Reprodução é permitida. Não vou me importar, juro. Mas cite a fonte.
Minhas fontes de informação e tambem as que podem vir a ser as suas:
http://coracaodeleao.virtualave.net
http://www.insecure.org
http://www.wiretrip.net/rfp
http://www.isc.org/bind
http://www.rfc-editor.org
http://www.iana.org
http://www.atstake.com /* Procure em research pelo netcat..*/
É, não lembro de mais nada. Melhor terminar aqui. Obrigado pela paciência. Termino com FIN ou eof?
Bah, RST
For those about to rock, we salute you
![Avatar de ^[H,L]aetc](http://www.istf.com.br/vb/avatars/-h-l-aetc.gif?dateline=1110038414)
![^[H,L]aetc está offline](/vb/images/statusicon/user_offline.gif)
![Enviar uma mensagem via ICQ para ^[H,L]aetc](/vb/images/misc/im_icq.gif)
![Enviar uma mensagem via Yahoo para ^[H,L]aetc](/vb/images/misc/im_yahoo.gif)
Modo linear
