[ SEGURANÇA ] 

Detecção de Sistema Operacional Remotamente via o 

FingerPrinting da Pilha TCP/IP  

---

INTRODUÇÃO 

Este artigo discute como obter informações valiosas de uma máquina través da pilha TCP/IP. 
Primeiramente vou apresentar alguns métodos "classicos" para determinar o S.O. de uma máquina sem envolver o fingerprinting. Depois eu descrevo o "estado da arte" corrente com a utilização de ferramentas de fingerprinting. A seguir vamos começar com uma descrição de várias tecnicas que fazem com que as máquinas remotas divulgem informações sobre elas mesma. Finalmente vou detalhar minha implementação (nmap) destas técnicas, seguido de uma relação de Sistemas Operacionas que rodam em alguns sites da Internet, descobertas com o nmap. 
 

MOTIVAÇÃO 

Eu acho que é obvio o por que de determinar qual sistema operacional estar rodando em uma máquina, devido a isso esta seção será curta. Uma das razões principais é que muitos furros de segurança dependem da versão do sistema operacional. Vamos supor que você vá realizar um teste de invasão e você encontra a porta 53 aberta. Se for uma versão do BIND vulnerável, você terá uma única chance de explora-la, pois uma tentativa falha vai matar o daemon. Com uma boa ferramenta de fingerprinter, você pode facilmente determinar qual sistema operacional está rodando 'Solaris 2.5.1' ou  'Linux 2.0.35', ai você pode ajustar suas ferramentas adquadamente, no caso seu código shell. 

Outra possibilidade é alguem que esteja rastreando 500.000 máqinas para descobrir qual sistema roda e quais portas estão abertas. Ai quando alguem anunciar um furro de segurança no daemon comsat da Sun, nosso pequeno cracker pode procurar em sua lista por 'UDP/512' e 'Solaris 2.6' e imediatamente ele vai ter páginas e páginas de máquinas vulneráveis. Devemos notar que esta é uma das metodologias mais comuns e universal conhecida como SCRIPT KIDDIE*. Você não demostrou nenhuma habilidade e ninguem ficara impressionado por você ter achado um sistema remoto que não aplicou o patch a tempo. As pessoas também  ficarão  _menos_  impresionadas se você usar seu novo acesso para pichar o site e deixar um discurso dizendo o quanto que você é bom e o quanto o administrador do site é estúpido. 

*  Nota do tradutor: A metodologia script kiddie é atribuida a alguém que invade as máquinas de forma "fácil". Ele não busca informações e/ou máquinas especificas. O objetivo dele é ganhar acesso de root da forma mais fácil possível. A técnica consiste em mater relações de exploits, e ficar rastreando a rede atraz de máquinas vulneráveis, cedo ou tarde ele acaba encontrando alguma máquina vulnerável. Alguns deles são usuários que desenvolvem suas próprias ferramentas e deixam backdoors sofisticados nas instituições onde já trabalharam. Outros não tem a menor idêia do que estão fazendo, e tudo o que sabem fazer é executar as ferramentas. Eles não possuem um nível de habilidade bom, mas a estratégia é a mesma, ou seja,  ficam procurando por furos específicos e ao encontra-lo exploram estes furos.

Outra possibilidade de uso é na engenharia social. Vamos supor que você esteja escaniando seu alvo e o nmap encontra  um 'Datavoice TxPORT PRISM 3000 T1 CSU/DSU 6.22/2.06'. Agora o hacker pode ligar para o suporte e discutir alguns pontos relacionados ao PRISMA 3000. Ele pode argumentar da seguinte forma: "Nós vamos anunciar um novo furo de segurança, mas antes queremos ter certeza de que todos os nossos clientes atuais estejam com o patch instalado -- a pouco enviamos um email para vocês informando...", alguns administradores ingênuos poderiam assumir que somente um funcionário autorizado da Datavoice poderia saber tantas coisas sobre o seu CSU/DSU. 

Você também pode usar isso para avaliar as companhias com as quais vai negociar. Antes de escolher um novo ISP, analise-o e verifique que tipo de equipamento ele utiliza. As ofertas de $99 por anos não parecem tão boas ao descobrie que ele utiliza roteadores de má qualidade e servidores rodando windows. 
 

TÉCNICAS CLASSICAS 

A análise de fingerprinting resolve o problema de identificação de S.O. de forma unica. Eu acho que esta é uma das técnicas mais promissoras, mas atualmente existem outras soluções para descobrio o S.O.. Infelizmente umas das técnicas mais utilizadas é a que se segue: 

playground~> telnet hpux.u-aizu.ac.jp 
Trying 163.143.103.12... 
Connected to hpux.u-aizu.ac.jp. 
Escape character is '^]'. 

HP-UX hpux B.10.01 A 9000/715 (ttyp2) 

login: 

Você não precisa usar a técnica de fingerprinting se a máquina anuncia para todo o mundo qual é o seu S.O. corrente! Infelizmente, muitos fabricantes de sistema deixam este tipo de informação e os administradores não as removem. Só porque existem outras formas de descobrir qual o sistema que está rodando (como fingerprinting), não significa que devamos anunciar qual é noso sistema e arquitetura para todo imbecil que tenta conectar. 

O problema de confiar netas técnica é que muitos administradores estão desabilitando este tipo de informação, muitos sistemas oferecem poucas informações e é muito fácil o administrador mudar a configuração com o objetivo de aparecer informações que não refretem a realidade. 

A leitura dos banners é tudo o que voce pode conseguir em relação a S.O. e sua versão com um scanner comercial como o ISS, onde você gasta algumas centenas de dolares. Download nmap ou queso e economize seu dinheiro :). 

Mas mesmo que você desabilite os banners, muitas aplicações permitem recupera este tipo de informações sobre o sistema. Por exemplo, vamos verificar um servidor FTP: 

payfonez> telnet ftp.netscape.com 21 
Trying 207.200.74.26... 
Connected to ftp.netscape.com. 
Escape character is '^]'. 
220 ftp29 FTP server (UNIX(r) System V Release 4.0) ready. 
SYST 
215 UNIX Type: L8 Version: SUNOS 

Inicialmente ele nos mostra detalhes do sistema com seu banner padrão. Então se entrarmos com o comando  ' SYST ' obtemos mais informações sobre o sistema. 

Se é permitido o FTP anonymous, nós podemos fazer o download do /bin/ls ou outro comando binário e determinar para qual arquitetura este comando foi desenvolvido. 

Muitas outras aplicações possuem este tipo de informação. Vejamos um servidor web: 

playground> echo 'GET / HTTP/1.0\n' | nc hotbot.com 80 | egrep '^Server:' 
Server: Microsoft-IIS/4.0 
playground> 

Hmmm... eu queria saber qual S.O. este  lamer está usando. :) 

Outra técnica clássica inclui a recuperação do registro info do DNS (raramente funciona) e engenharia social. Se a máquima está com a porta 161/udp (snmp) aberta, você pode conseguir muitas informações usando a ferramenta  ' snmpwalk ' da distribuição CMU SNMP e a comunidade publica (public). 
 

PROGRAMAS DE FINGERPRINTIN CORRENTES 

A ferramente nmap não é a primeira que utiliza a técnica TCP/IP de fingerprinting para reconhecimento de sistema operacional. A ferramente sirc de spoofer de IRC desenvolvida por Johan inclui técnicas de fingerprinting muito rudimentares nas versões 3 ou anteriores. Ela classifica a máquina como "linux", "4.4BSD", "Win95" ou "desconhecida" usando um teste de sinalização TCP muito simples. 

Outro programa é o checkos, que foi disponibilizado publicamente em janeiro deste ano (1998) por Shok na Confidence Remains High Issue #7. A técnica de fingerprinting é exatamente igual a SIRC e até mesmo o código é identico em vários pontos. Checkos ficou disponível de forma reservada por muito tempo antes de ser liberado publicamente, assim não tenho a mínima idéia de quem copiou o código de quem. Mas nehum faz referencia ao outro. Uma coisa útil que o checkos possuie é a verificação do banner do telnet, mas isso cai no problema descrito anteriormente. [Atualização: Shok enviou um email dizendo que não pretendia tornar checkos público e por isso não colocou os créditos para o SIRC] 

Su1d também escreveu um programa de verificação de sistema operaciona. Chama-se SS e apartir da versão 3.11 consegue identificar 12 tipos diferentes de sistemas operacionais. Em relação a este eu sou um pouco parcial, pois ele creditou parte do código a meu programa o nmap :). 

Exite também o queso. Este programa é mais novo e possui muitas melhorias em relação aos outros programas. Ele não só incluiu novos testes como também foi o primeiro (que eu vi) a ler o fingerprinter do sistema operacional. Os outros scanner incluem o seguinte trecho de código: 

/* from SS */ 
if ((flagsfour & TH_RST) && (flagsfour & TH_ACK) && (winfour == 0) && 
   (flagsthree & TH_ACK)) 
       reportos(argv[2],argv[3],"Livingston Portmaster ComOS"); 

Ao contrário dos outros, queso inclui os testes em um arquivo de configuração que obviamente torna mais simples a inclusão de novos sistemas operacionais, ou seja, basta incluir as linhas com os novos fingerprinter. 

Queso foi escrito por Savage, um dos caras legais do apostols.org. 

Um problema com todos os programas descritos acima é que eles são muito limitados no número de testes realizados com o fingerprinting, esta limitação reduz o detalhamento das informações. Eu quero saber mais sobre a máquina se é  'OpenBSD', 'FreeBSD' ou 'NetBSD', ou seja, quero saber exatamente qual é o sistema operacional e qual a versão. Do mesmo modo eu quero saber se o sistema é um 'Solaris 2.6' ao invés de simplesmente 'Solaris'. Para chegar a este nível de refinamento eu utilizo várias técnicas de fingerprinting que são descritas a seguir. 
 

METODOLOGIA DE FINGERPRINTING 

Exitem muitas técnicas que podem ser utilizadas para identificação da fingerprint da pilha de rede. Basicamente a técnica consiste em identificar diferenças entre sistemas operacionais e desenvolver um código que classifique estas diferenças. Se você combinar este dois processos, poderá chegar a um nível de refinamento da informação muito bom. O nmap por exemplo pode diferenciar Solaris 2.4  vs.  Solaris 2.5-2.5.1  vs.  Solaris 2.6, isso também é válido para o linux 2.0.30  vs.  2.0.31-34  vs.  2.0.35, entre outros sistemas. Aqui estão algumas das técnicas utilizadas: 

Investigação de FIN ( FIN probe ) - nesta técnica nos enviamos uma pacote FIN ( ou qualquer pacote sem o flag de ACK ou SYN) para uma porta aberta e esperamos por uma resposta. A implementação correta da RFC793 diz para NÃO responder*, mas muitas implementações "furadas" como MS Windows, BSDI, CISCO, HP/UX, MVS e IRIX respondem com um RESET. A maioria das ferramentas atuais utiliza esta técnica. 

*Nota do tradutor: A RFC793, especifica que portas FECHADAS devem responder com RST (RESET) e portas ABERTAS devem ignorar o pacote, mas muitos dos nossos fornecedores amigos, NÃO seguem as especificações, e respondem com RST aos pacotes FIN enviados para portas abertas.

Investigação FALSA ( BOGUS flag ) - queso foi o primeiro scanner a  utilizar este tipo de teste, pelo menos que eu saiba. A idéia consiste em enviar um flag TCP indefinido (64 ou 128) no cabeçalho TCP de um pacote SYN. O Linux anterior ao 2.0.35 mantem este flag setado em sua resposta. Eu não encontrei em outro sistema este erro. Porém, outros sistemas operacionais paresem resetar a conexão (resposta com RST) quando recebem um pacote SYN+BOGUS. Este comportamento pode ser útil para identificar o sistema. 

Padrão TCP de ISN ( TCP ISN Sampling ) - a idéia por traz desta técnica é a identificação de padrões do Número Inicial de Seqüencia ( ISN - Initial Sequence Number ) escolhido pelo TCP ao responder um pedido de conexão. Este números podem ser classificados em vários grupos como o tradicional 64K ( utilizados em muitas versões antigas de UNIX ), incrementação randomica ( versões mais novas de Solaris, IRIX, FreeBSD, Digital, UNIX, Cray e muitos outros ), randomico "verdadeiro" ( Linux 2.0. *, OpenVMS, AIX mais novo, etc ). O sistema Windows e outros sistemas utilizam um modelo que depende do horário onde o ISN é incrementado por um valor fixo a cada período de tempo. É desnecessário dizer que isso é muito fácil de quebrar assim como o antigo modelo de 64K. Lógico que minha técnica preferida é a constante, pois as máquinas SEMPRE utilizam o mesmo valor...:). Eu vi isso em um hub 3Com ( usa 0x803 ) e em uma impressora, Apple LaserWriter printers ( usa 0xC7001 ). 

Você pode fazer uma subdivisão dos grupos, como a incrementação randomica, pode ser subdividido em variação computacional, maiores divisores comuns,  outras funções de criação de números seqüenciais e diferença entre números. 

Deve-se notar que a geração do ISN tem algumas implicações de segurança. Para maiores informações sobre esta questão, entre em contato com o "especialista em segurança"  Tsutomu "Shimmy" ele é do SDSC, pergunte para ele como seu sistema foi invadido. nmap é o primeiro sistema que eu conheço que utiliza esta técnica para identificação do sistema operacional. 

Bit de não fragmentação ( Don't Fragment bit ) - Muitos sistema operacionais começaram a setar o bit de não fragmentação em alguns pacotes enviados. Com isso temos vários benefícios de desempenho ( mas isso também pode ser chato -- é por isso que o scanner de fragmentação do nmap não funciona com Solaris ). De qualquer forma, nem todos os sistema operacionais fazem isso e alguns  fazem em diferentes casos, sendo assim, se analisarmos estes bits podemos obter mais informações sobre o nosso alvo. Eu nunca vi esta técnica ser empregada anteriormente. 

Janela deslizante inicial do TCP ( TCP Initial Window ) - esta técnica envolve a analise do tamanho da janela devolvida pelos pacotes de retorno. Os scanners antigos classificam o sistema operacional como BSD 4.4, quando o pacote RST possui uma janela com valor diferente de zero. Os scanners mais novos como queso e nmap através das janelas conseguem deterninar o tipo de sistema operacional. Este teste nos da uma série de informações, uma vez que alguns sistema operacionais podem ser identificados unicamente pela janela ( por exemplo, AIX é o único sistema operacional que usa 0x3F25 ). Na sua nova pilha  TCP, que foi completamente re-escrita para o NT5 a Microsoft usa 0x402E. Isto é interessante, pois trata-se exatamente do mesmo número utilizado pelo OpenBSD e FreeBSD. 

Valor do ACK ( ACK Value ) - Embora você possa pensar que este valor seja um padrão, as 
implementações usam valores diferentes para o bit ACK em alguns casos. Por exemplo, vamos supor que você envie um FIN|PSH|URG para uma porta TCP fechada. Muitas implementações vai setar o ACK com o mesmo ISN inicial enviado por você, entretanto o Windows e algumas impressoras estúpidas enviarão seu seq+1. Se você enviar SYN|FIN|URG|PSH para uma porta aberta, o Windows comporta-se de forma inconcistente. Algumas vezes ele devolve seu seq, outras ele devolve S++ e ainda em outras situações ele devolve um valor randomico. As pessoas precisam saber que tipo de código estão escrevendo, a MS para não saber disso. 

Diminuindo as mensagens de erro ICMP ( ICMP Error Message Quenching ) - Alguns sistemas operacionais ( inteligentes ) seguem as sugestões da RFC 1812 no sentido de limitar a taxa de envio de mensagens de erro. Por exemplo, o kernel do Linux ( net/ipv4/icmp.h ) limita a geração de mensagens destination unreachable de 80 para 4 segundos, com uma penalidade de 1/4 segundos se o tempo for excedido. Uma forma de testar isso é enviar um grupo de pacotes para para uma porta UDP alta e contar o número de unreachables recebidos. Eu não vi esta técnica ser utilizada por outro programa e de fato eu não a inclui no nmap ( exceto para realizar port scan de UDP ). Este teste tornaria a deteccao do sistema operacional muito lenta pois teriamos que enviar um grupo de pacotes UDP e aguardar pelas respostas. Além de termos que trabalhar com a possibilidade de pacotes serem perdidos pela rede. 

Mensagem ICMP de erro ( ICMP Message Quoting ) - As RFCs especificam que as mensagens ICMP de erro devem conter uma pequena parte da mensagem ICMP que causou o erro. Por exemplo, para uma mensagem de porta unreachable, quase todas as implementações enviam somente um cabeçalho IP + 8 bytes. Porém, Solaris retorna um pouco mais e Linux retorna muito mais que o Solaris. O bom disso é que a ferramente nmap pode identificar se um sistema é Solaris ou Linux mesmo que els não tenham portas abertas. 

Tipo de serviço ( Type of Service ) - Eu verifico o valor do tipo de serviço ( TOS - type of service ) retornado pelas mensagens de ICMP port unreachable. Quase todas as implementações setam este tipo de erro ICMP com o valor 0, mas o Linux usa 0cC0. Este não é um valor padrão para TOS, pelo contrário, isso faz parte do campo de precedência ( AFAIK ). Eu não sei por que este valor é setado, mas se ele for 0 nós podemos identificar as versões antigas, logo com este recurso é possível identificar entre as versões velas e as novas.

Controle de fragmentação ( Fragmentation Handling ) - Esta é a técnica preferida de Thomas H. Ptacek da Secure Networks, Inc ( agora pertence a um grupo de usuários de Windows NAI ). Esta técnica tira proveito do fato de que as várias  implementações freqüentemente fazem a remontagem dos pacotes de forma diferete. Algumas escrevem a porção antiga juntamente com a nova em outros casos a porção antiga tem precedência. Existem várias formas diferentes para você determinar como o pacote foi remontado. Eu não adicionei esta facilidade, uma vez que desconheco uma forma portável de enviar pacotes IP fragmentados ( em particular, em sistemas Solaris ) Para maiores informações sobre remontagem de fragmentos voce pode ler um documento sobre IDS ( www.secnet.com ). 

Opções do TCP ( TCP Options ) - As opções TCP realmente são uma mina de ouro em termos de divulgação de informção. Algumas das maravilhas destas opções são: 

1) Geralmente elas são opções (duh!):) sendo assim nem todas as máquinas implementam. 

2)  Você identifica se uma máquina implementou as opções enviado um pacote com as opções setadas. O alvo geralmente possui suporte se responder com as opções setadas. 

3) Você pode colocar um grupo de opções em um único pacote, com o objetivo de testa-las em 
uma única vez. 

Window Scale=10; NOP; Max Segment Size = 265; Timestamp; End of Ops; 

Quando receber sua resposta, você dá uma olhada em quais opções foram devolvidas, logo, estas são suportadas. Alguns sistemas operacionais como a recente versão do FreeBSD suporta todas as opções acima, enquanto outros, como Linux suporta poucas. O kernel mais recente do Linux 2.1.X suporta todas as opções anteriores. Esta caracteristica do sistema operaciona o tona mais vulnerável a ataques TCP. 

Mesmo que vários sistemas operacionais suportem opções semelhantes, você pode diferencialos pelo valor das opções. Por exemplo, se você enviar um pequeno valor  MSS para o Linux, ele geralmente devolve o MSS para você. Outras máquinas devolverão valores diferentes. 

E se você obter o mesmo grupo de opções com os mesmo valores, você ainda pode diferenciar o sistema operacional pela ordem na qual as opções são determinadas. Por exemplo, o sistema Solaris retorna 'NNTNWME' que significa: 
  <no op><no op><timestamp><no op><window scale><echoed MSS> 

Enquanto o Linux 2.1.122 retorna 'MENNTNW'.  As mesmas opções, os mesmos valores, mas em ordem diferente. 

Eu nunca vi outra ferramenta de detecção de sistema operacional que utilize este técnica, mas ela é muito boa. 

Existem outras opções úteis que eu poderia utilizar para alguns pontos, como as do T/TCP e de
reconhecimento seletivo. 

Exploit Chronology -- Even with all the tests above, nmap is unable to 
    distinguish between the TCP stacks of Win95, WinNT, or Win98. 
    This is rather surprising, especially since Win98 came out about 4 
    years after Win95.  You would think they would have bothered to 
    improve the stack in some way (like supporting more TCP options) 
    and so we would be able to detect the change and distinguish the 
    operating systems.  Unfortunately, this is not the case.  The NT 
    stack is apparently the same crappy stack they put into '95.  And 
    they didn't bother to upgrade it for '98. 

    But do not give up hope, for there is a solution.  You can simply 
    start with early Windows DOS attacks (Ping of Death, Winnuke, etc) 
    and move up a little further to attacks such as Teardrop and Land. 
    After each attack, ping them to see whether they have crashed. 
    When you finally crash them, you will likely have narrowed what 
    they are running down to one service pack or hotfix. 

    I have not added this functionality to nmap, although I must admit 
    it is very tempting :). 
 

SYN Flood Resistance -- Some operating systems will stop accepting new 
    connections if you send too many forged SYN packets at them 
    (forging the packets avoids trouble with your kernel resetting the 
    connections).  Many operating systems can only handle 8 packets. 
    Recent Linux kernels (among other operating systems) allow 
    various methods such as SYN cookies to prevent this from being a 
    serious problem.  Thus you can learn something about your target 
    OS by sending 8 packets from a forged source to an open port and 
    then testing whether you can establish a connection to that port 
    yourself.  This was not implemented in nmap since some people get 
    upset when you SYN flood them.  Even explaining that you were 
    simply trying to determine what OS they are running might not help 
    calm them. 

NMAP IMPLEMENTATION AND RESULTS 

I have created a reference implementation of the OS detection 
techniques mentioned above (except those I said were excluded).  I 
have added this to my Nmap scanner which has the advantage that it 
already _knows_ what ports are open and closed for fingerprinting so 
you do not have to tell it.  It is also portable among Linux, *BSD, 
and Solaris 2.51 and 2.6, and some other operating systems. 

The new version of nmap reads a file filled with Fingerprint templates 
that follow a simple grammar.  Here is an example: 

FingerPrint  IRIX 6.2 - 6.4 # Thanks to Lamont Granquist 
TSeq(Class=i800) 
T1(DF=N%W=C000|EF2A%ACK=S++%Flags=AS%Ops=MNWNNT) 
T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=) 
T3(Resp=Y%DF=N%W=C000|EF2A%ACK=O%Flags=A%Ops=NNT) 
T4(DF=N%W=0%ACK=O%Flags=R%Ops=) 
T5(DF=N%W=0%ACK=S++%Flags=AR%Ops=) 
T6(DF=N%W=0%ACK=O%Flags=R%Ops=)
T7(DF=N%W=0%ACK=S%Flags=AR%Ops=) 
PU(DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E) 

Lets look at the first line (I'm adding '>' quote markers): 

> FingerPrint  IRIX 6.2 - 6.3 # Thanks to Lamont Granquist 

This simply says that the fingerprint covers IRIX versions 6.2 through 
6.3 and the comment states that Lamont Granquist kindly sent me the IP 
addresses or fingerprints of the IRIX boxes tested. 

> TSeq(Class=i800) 

This means that ISN sampling put it in the "i800 class".  This means 
that each new sequence number is a multiple of 800 greater than the 
last one. 

> T1(DF=N%W=C000|EF2A%ACK=S++%Flags=AS%Ops=MNWNNT) 

The test is named T1 (for test1, clever eh?).  In this test we send a 
SYN packet with a bunch of TCP options to an open port.  DF=N means 
that the "Don't fragment" bit of the response must not be set. 
W=C000|EF2A means that the window advertisement we received must 
be 0xC000 or EF2A.  ACK=S++ means the acknowledgement we receive must 
be our initial sequence number plus 1.  Flags = AS means the ACK and 
SYN flags were sent in the response.  Ops = MNWNNT means the options 
in the response must be (in this order): 

<MSS (not echoed)><NOP><Window scale><NOP><NOP><Timestamp> 

> T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=) 

Test 2 involves a NULL with the same options to an open port.  Resp=Y 
means we must get a response.  Ops= means that there must not be any 
options included in the response packet.  If we took out '%Ops=' 
entirely then any options sent would match. 

> T3(Resp=Y%DF=N%W=400%ACK=S++%Flags=AS%Ops=M) 

Test 3 is a SYN|FIN|URG|PSH w/options to an open port. 

> T4(DF=N%W=0%ACK=O%Flags=R%Ops=) 

This is an ACK to an open port.  Note that we do not have a Resp= 
here.  This means that lack of a response (such as the packet being 
dropped on the network or an evil firewall) will not disqualify a 
match as long as all the other tests match.  We do this because 
virtually any OS will send a response, so a lack of response is 
generally an attribute of the network conditions and not the OS 
itself.  We put the Resp tag in tests 2 and 3 because some operating 
systems _do_ drop those without responding. 

> T5(DF=N%W=0%ACK=S++%Flags=AR%Ops=) 
> T6(DF=N%W=0%ACK=O%Flags=R%Ops=) 
> T7(DF=N%W=0%ACK=S%Flags=AR%Ops=) 

These tests are a SYN, ACK, and FIN|PSH|URG, respectively, to a closed 
port.  The same options as always are set.  Of course this is all 
probably obvious given the descriptive names 'T5', 'T6', and 'T7' :). 

> PU(DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%
ULEN=134%DAT=E) 

This big sucker is the 'port unreachable' message test.  You should 
recognize the DF=N by now.  TOS=0 means that IP type of service field 
was 0.  The next two fields give the (hex) values of the IP total 
length field of the message IP header and the total length given in 
the IP header they are echoing back to us.  RID=E means the RID value 
we got back in the copy of our original UDP packet was expected (ie 
the same as we sent).  RIPCK=E means they didn't fuck up the checksum 
(if they did, it would say RIPCK=F).  UCK=E means the UDP checksum is 
also correct.  Next comes the UDP length which was 0x134 and DAT=E 
means they echoed our UDP data correctly.  Since most implementations 
(including this one) do not send any of our UDP data back, they get 
DAT=E by default. 

The version of nmap with this functionality is currently in the 6th 
private beta cycle.  It may be out by the time you read this in 
Phrack.  Then again, it might not.  See http://nmap.org/ 
for the latest version. 

S.O. DE SITES POPULARES

Aqui está o divertido resultado de todo o nosso trabalho. Agora nos vamos de forma randômica visitar alguns sites da Internet e determinar que sistema eles estão utilizando. Muitos destes sites eliminaram o banner do telnet, etc para manter esta informação ( o tidpo do S.O. ) privada. Mas isso é inutil para o nosso novo fingerprinter! Isto também é uma forma divertida de export o sistema operacional e mostrar quantos lamers estão por ai :)!

O comando utilizado neste exemplo foi: nmap -sS -p 80 -O -v <host>

Note que a maioria deste testes foram realizados em 18/10/1998. Alguns destes dever ter realizado atualizações/mudanças em seus servidores.

Eu não gosto de todos os sites que estãi listados aqui.

# Sites "hacker" ou  ( em alguns casos) sites que pensam que são
www.l0pht.com        => OpenBSD 2.2 - 2.4 
insecure.org     => Linux 2.0.31-34 
www.rhino9.ml.org    => Windows 95/NT     # Sem comentários :) 
www.technotronic.com => Linux 2.0.31-34 
www.nmrc.org         => FreeBSD 2.2.6 - 3.0 
www.cultdeadcow.com  => OpenBSD 2.2 - 2.4 
www.kevinmitnick.com => Linux 2.0.31-34  # Free Kevin! 
www.2600.com         => FreeBSD 2.2.6 - 3.0 Beta 
www.antionline.com   => FreeBSD 2.2.6 - 3.0 Beta 
www.rootshell.com    => Linux 2.0.35  # Mudaram para OpenBSD

# Empresas de segurança, colsultoria,  etc. 
www.repsec.com       => Linux 2.0.35 
www.iss.net          => Linux 2.0.31-34 
www.checkpoint.com   => Solaris 2.5 - 2.51 
www.infowar.com      => Win95/NT 

# Os distribuidores são leais ao seu sistema operacional 
www.li.org           => Linux 2.0.35 # Linux Internacional 
www.redhat.com       => Linux 2.0.31-34 # Eu acho esta distribuição muito boa :) 
www.debian.org       => Linux 2.0.35 
www.linux.org        => Linux 2.1.122 - 2.1.126 
www.sgi.com          => IRIX 6.2 - 6.4 
www.netbsd.org       => NetBSD 1.3X 
www.openbsd.org      => Solaris 2.6     # Aham :) 
www.freebsd.org      => FreeBSD 2.2.6-3.0 Beta 

# Ivy league 
www.harvard.edu      => Solaris 2.6 
www.yale.edu         => Solaris 2.5 - 2.51 
www.caltech.edu      => SunOS 4.1.2-4.1.4  # Hello! This is the 90's :) 
www.stanford.edu     => Solaris 2.6 
www.mit.edu          => Solaris 2.5 - 2.51 # É uma coincidência que a maioria das boas
                                          # escolas usem Sun?
                                          # Talvez seja por que os .edu tenham 40% de desconto :)
www.berkeley.edu     => UNIX OSF1 V 4.0,4.0B,4.0D 
www.oxford.edu       => Linux 2.0.33-34  # Rock on! 

# Sites Lamer 
www.aol.com          => IRIX 6.2 - 6.4  # Nenhuma novidade, eles são tão inseguros :) 
www.happyhacker.org  => OpenBSD 2.2-2.4 #Cansada de ser invadida , Carolyn? 
                                         #Até mesmo o SO mais seguro é 
                                         #inútil nas mãos de um 
                                         #admin incompetente. 

# Misc 
www.lwn.net          => Linux 2.0.31-34 # This Linux news site rocks! 
www.slashdot.org     => Linux 2.1.122 - 2.1.126 
www.whitehouse.gov   => IRIX 5.3 
sunsite.unc.edu      => Solaris 2.6 

Notas: Em seu documento de segurança,  a Microsoft falou sobre sua imcompetencia nesta questão: "Com a popularidade do Windows NT este panorama mudou, isso em grande parte devido às suas caracteristicas de segurança.". Hmm, não me parece que o Windows seje muito popular na comunidade de segurança :) Em todo o grupo eu vi somente dois Windows e para o nmao é MUITO fácil descobrir sistemas Windows.

E claro, existe mais um site que devemos verificar. Este é o web site da ultra-secreta 
corporação Transmeta. O interessante é que a empres foi em grande parte fundada por 
Paul Allen da Microsoft, mas é onde trabalha Linus Torvalds. Eles estão com Paul e rodam NT ou estão com os rebeldes e participam da revolução do Linux? Vamos verificar:

Nós usamos o comando: 
nmap -sS -F -o transmeta.log -v -O www.transmeta.com/24 

Este comando faz um SYN scan nas portas conhecidas ( /etc/services ), loga o resultado no arquivo 'transmeta.log', em seguida faz um scan do SO e um scan na classe 'C' pertencente a 
www.transmeta.com. Vamos ver o resultado: 

neon-best.transmeta.com (206.184.214.10) => Linux 2.0.33-34 
www.transmeta.com (206.184.214.11) => Linux 2.0.30 
neosilicon.transmeta.com (206.184.214.14) => Linux 2.0.33-34 
ssl.transmeta.com (206.184.214.15) => Linux unknown version 
linux.kernel.org (206.184.214.34) => Linux 2.0.35 
www.linuxbase.org (206.184.214.35) => Linux 2.0.35 ( possivelmente a mesma máquina acima )

Bem, eu acho que isso responde nossa pergunta de forma bem clara :).
 

AGRADECIMENTOS 

Atualmente nmap pode descobrir tantos sistemas operacionais diferentes devido ao esforço
de várias pessoas que ajudaram de forma privada nos testes e realizaram um grande esforço
para descobrir novos fingerprint! Em particular, Jan Koum, van Hauser, Dmess0r, David O'Brien, James W. Abendschan, Solar Designer, Chris Wilson, Stuart Stock, Mea Culpa, 
Lamont Granquist, Dr. Who, Jordan Ritter, Brett Eldridge e Pluvius que enviou uma tonelada de fingerprint de máquinas que não encontramos a Internet.

Obrigado a Richard Stallman por escrever GNU Emacs.  Este artigo não seria escrito de forma tao fácil se eu estivese utilizando somente vi, cat e ^D.

Dúvidas e comentários podem ser enviadas para fyodor@insecure.org (se este não funcionar por algum motivo, use fyodor@insecure.org).  Nmap pode ser obtido em  http://insecure.org/nmap .