[ --- The Bug! Magazine _____ _ ___ _ /__ \ |__ ___ / __\_ _ __ _ / \ / /\/ '_ \ / _ \ /__\// | | |/ _` |/ / / / | | | | __/ / \/ \ |_| | (_| /\_/ \/ |_| |_|\___| \_____/\__,_|\__, \/ |___/ [ M . A . G . A . Z . I . N . E ] [ Numero 0x02 <---> Edicao 0x02 <---> Artigo 0x08 ] .> 14 de Fevereiro de 2007, .> The Bug! Magazine < staff [at] thebugmagazine [dot] org > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sistemas de Deteccao de Intrusos: Parte II +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .> 10 de Fevereiro de 2007, .> y0Rk < gfm [at] rfdslabs [dot] com [dot] br > "It is of the highest importance in the art of detection to be able to recogni- ze, out of a number of facts, which are incidental and which vital. Otherwise your energy and attention must be dissipated instead of being concentrated." -Sherlock Holmes [ --- Indice + 1. <---> Primeiras palavras + 2. <---> Em que lugar da minha rede? + 2.1. <-> Antes do Firewall + 2.2. <-> Dentro do Firewall + 2.3. <-> Outros lugares + 3. <---> Regras e Filtros + 3.1. <-> As Politica de Filtros + 3.1.1 <-> Negue tudo! + 3.1.2 <-> Aceite tudo! + 3.2. <---> Assinaturas + 3.2.1 <-> O Filtro de assinatura + 3.2.2 <-> Faca filtros eficientes + .4.0 <---> Tipos diferentes de filtros + 4.1. <-> Exploits + 4.2 <-> Protocolos + 5. <---> Algumas tecnicas e conceitos de evasao + 5.1. <-> Unicode + 5.1.1 <-> Problemas + 5.2. <-> Polimorfismo + 5.3 <-> DDoS + 5.4 <-> Fragmentacao e Reassembly [ --- 1. Primeiras Palavras Chegamos a segunda parte. Agora, depois de conhecer os principios e nomeclatu- ras basicas de um Sistema de Deteccao de Intrusos, vamos conhecer um pouco do funcionamento em si com algumas dicas de implementacao. Nessa parte, a logica dos passos e' muito importante. Fique sempre de olho pois os assuntos sao bastante lineares. A logica seguida sera a seguinte: [Localidade]--[Regras/Filtros/Assinaturas]--[Evasao] Onde, Localidade: Serao apresentadas opcoes de localidades de rede, a depender da sua necessidade. Filtros: Algumas dicas importantes de filtros `a serem consideradas. Evasao: Depois dos filtros, o que podera' dar errado? O IDS adotado em alguns exemplos e' o Snort, que, alem de ter uma otima docu- mentacao, esta' ao alcance de todos. [ --- 2. Posicionamento: Em que lugar da minha rede? Como todos sabem, um NIDS depende de um sensor para detectar algo e trabalhar. E, se colocado numa boa posicao, ele trabalhara' melhor ainda. Entretanto, antes de discutir a colocacao e posicionamento do sensor na rede, e' preciso analisa-la: Questoes sobre sistemas internos e a infraestrutura cri- tica da rede, como bancos de dados por exemplo, devem ser consideradas. E' importante perceber que qualquer que seja a escolha, ela trara' vantagens e desvantagens que deverao ser ponderadas ate que se maximize a eficacia do sen- sor. Mapa: ----- 2.1 [Sensor] | [Internet]-------|--------[Fw]-------[Rede] | 2.2 [Internet]-----[Fw]------|-----------[Rede] | [Sensor] [ --- 2.1 Antes do Firewall Usualmente os sensores sao colocados na DMZ -- fora do Firewall. Nesse posi- cionamento, o sensor pode captar todos os ataques vindos da internet, inclu- sive os que o firewall eventualmente bloquearia. Por isso, a quantidade de falsos-positivo e' bem maior. Nesse posicionamento, caso o atacante ache o sensor, ele poderia ataca-lo, afetando a auditoria do mesmo. [ --- 2.2 Depois do Firewall Com o sensor depois do firewall, ele detectara' apenas os ataques que passam pelas regras do firewall (vindos de fora para dentro), diminuindo os falsos- positivos. Tambem e' possivel identificar ataques de dentro da propria rede, ja que o sensor esta nela. Alem disso, varias tecnicas de evasao poderao ser evitadas (pacotes anomalos por exemplo), pois os pacotes analisados serao, como dito antes, apenas os que o firewall deixou passar. Ja outras tambem poderao ser evitadas, por que o three-way-handshake nao sera' completado. [ --- 2.3 Localidades Adicionais O posicionamento mais comum, de uma maneira geral, e' antes do firewall. Mas o certo e' que nao e' o unico que beneficiara' sua rede. Por isso, como foi dito antes, e' preciso analisar questoes internas e de infraestrutura da rede. Por exemplo; -Considerar colocar um sensor numa rede de parceiros, na qual voce tem conexoes diretas. -Questoes sobre Compartilhamento: Os recursos da rede (file system, devices, application servers, etc...), Vale lembrar que a rede pode ter multiplos pontos de entrada. O bom e' analisar todos. [ --- 3. Regras e Filtros A eficiencia de um IDS, depende nao so da sua localidade na rede, mas muito tambem da qualidade dos seus filtros. O design e a configuracao e a gerencia desses filtros sao cruciais quando um IDS e' montado. [ --- 3.1 Politica de Filtros Defina uma politica de filtros que se adeque com o design e as necessidades da rede. Isso e' muito importante. As politicas sao configuradas, e podem ser edi- tadas depois, de acordo com a demanda e necessidade da rede. Nota: Nem todos os IDSs suportam essa flexibilidade dos filtros. O da ISS por exemplo nao permite que os usuario alterem seus filtros. Uma boa forma de comecar o trabalho de definicao de politicas, e' seguindo uma das politicas abaixo: [ --- 3.1.1 Negue tudo! A leitura e' simples: Negue tudo que nao for especificamente permitido. Ou se- ja, tudo sera' negado, ate que as necessidades aparecam. Isso pode trazer pro- blemas -- se seu IDS resetar conexoes por exemplo, e aplicacoes deixarem de funcionar (vpns, filtros de spam, etc..). [ --- 3.1.2 Aceite tudo! E' justamente o contrario da politica acima: Aceite tudo que nao esteja especi- ficamente negado e depois negue os servicos considerados inaceitaveis. Para al- gumas redes e' necessario liberdade e flexibilidade (ex: universidades, labora- torios), por isso, nem sempre olhe com maus olhos essa politica. [ --- 3.2 Assinaturas [ --- 3.2.1 O Filtro de assinatura. Vamos construir um raciocinio: Um ataque possui, geralmente, alguma particularidade que o identifica. Um fil- tro de assinatura procura essa particularidade nos fluxo de dados fornecidos por um sensor. E, essa assinatura pode ser descrita como uma relacao booleana chamada regra (rules). Parece facil, nao? Porem nem tudo sao flores, e os filtros de assinatura tem limitacoes. Eles so- mente podem reconhecer um ataque quando existe uma assinatura para esse ataque. Por isso a gerencia desses filtros sao tao importantes. Essa limitacao se aplica essencialmente quando sai alguma ameaca nova pela Rede (0days, worms, etc). Se voce nao tiver acesso ao codigo-fonte dessa ameaca, ou pelo menos entender o funcionamento dela, fica bem dificil elaborar um filtro que impeca os ataques. A maioria das pessoas no entanto espera que alguem elabore a assinatura para essa nova ameaca, o que as vezes demora dias, e que termina em alguns casos, sendo tarde de mais. [ --- 3.2.2 Faca filtros eficientes O que pode ser considerado um filtro eficiente? A ideia e' que seja um filtro que entenda os dados que analisa e gere alertas relevantes com um minimo de falsos positivos. O primeiro passo dessa caminhada e' definir e delimitar claramente a area de analise dos filtros. Tambem e' importante projetar filtros que permitam a inte- gracao de um modulo da detecao de anomalias nos protocolos. Relembrando: Faca filtros que reduza a quantidade de falsos positivos e gere alertas com um alto nivel de informacao. [ --- 3.2.3 Tipos diferentes de filtros -Exploits -Anomalia em Protocolos [ --- 4.1 Exploits Resgatando o raciocinio construido na sessao 3.2.1, uma maneira facil mas nao totalmente eficaz de escrever um filtro para exploits, e' usar, por exemplo, uma string distinta que contenha instrucoes de maquina que sao passadas dire- tamente ao computador alvo, assim que o overflow obtiver sucesso. Vamos usar um exemplo ilustrativo: O Windows Vista RPC Buffer Overflow: (Fake) EB 12 5E 31 C9 81 E9 88 FF FF FF 81 36 80 BF 32 81 94 FC EE FF FF FF E2 F2 EB F5 E8 E2 FF FF FV 03 53 06 1F 74 57 75 91 80 BF BB 95 7F 89 5A 1A CE B1 DE 7C E1 BE 31 Se fosse elaborado um filtro para esse tipo especifico de exploit, essa string seria nosso alvo de filtragem. A desvantagem desse tipo de filtro e' que ele se limita a um exploit em particular, ou alguns outros que usem o mesmo shellcode. O perigo disso e' que, se um pedaco de codigo diferente explorar a mesma vulne- rabilidade, o filtro sera inutil. Mas isso sera visto mais adiante. [--- 4.2 Filtros de Protocolo Para desenvolver um filtro de protocolo, e' preciso dividir o procedimento em algumas etapas: 1. Ler toda a documentacao (RFC included!) sobre o protocolo. 2. Identificar todos os pontos que devem ser checados (cabecalho, campos, etc.) 3. Pegar a lista de todos os ataques conhecidos usando esse protocolo. A maioria dos fabricantes reforcam a ideia de que quanto mais conformidades o protocolo com a RFC, mais seguro dos ataques ele estara'. Entretanto, essa ideia nao se aplica a todos os protocolos, nem a todos os casos. As aplicacoes legitimas que produzem trafego podem render um grande numero de falsos positivo. Reconhecer um ataque web-based usando um esquema de anomalia e' bastante dificil. Um atacante pode fornecer um valor malicioso no seu request, que comprometa o webserver, sem que viole as especificacoes do proto- colo HTTP. Por exemplo, o ataque do "phf" nao viola o Uniform Resource Locator (URL) RFC 1738. Para um I{P|D}S tentar detectar via anomalia, era preciso saber o que especificamente era fornecido pelo phf a variavel de QAlias. http://127.0.0.1/cgi-bin/phf?Qalias=x%0a/bin/cat%20/etc/passwd Nota: A vulnerabilidade permite comandos arbitrarios na shell, nao apenas /bin/cat /etc/passwd. Seria preciso o protocolo entender com o esquema de aplicacoes web-based lida com suas entradas, por isso e' de extrema importancia o uso de filtros especi- ficos (nesse caso web-based, feitos a partir do levantamento dos passos 2 e 3) para diminuir a chance de um ataque passar despercebido simplesmente por nao ferir a RFC. Baixando mais o nivel, vamos ver o Simple Mail Transfer Protocol ou o smtp: Cada comando do SMTP descrito na RFC 821 (MAIL, RCPT, HELO, VRFY, EXPN e HELP) eram vulneraveis a buffer overflows. Visando ficar o mais conforme com o protocolo SMTP, um I{P|D}S poderia procurar por valores inapropriados no argumento dos comandos, evitando, deste modo, alguns ataques antigos de buffer overflow. Ou seja, ele procuraria por argumen- tos estranhos em cada comando utilizado numa sessao. Nesse caso os filtros da anomalia detectam as circunstancias que sao necessa- rias ao sucesso do ataque e que nunca ocorrem no trafego normal(no exemplo smtp). Sob estas circunstancias ideais, um filtro da anomalia do protocolo e' uma generalizacao eficaz de um filtro do vulnerabilidade. Entretanto, sua eficacia e' diminuida se o trafego for legitimo (no exemplo web-based). [ --- 5. Algumas tecnicas e conceitos de evasao No mundo real, ataques de evasao em sua grande maioria nao sao tao faceis de se explorar. Geralmente um atacante nao se da o "luxo" de injetar codigos arbitra- rios em streams, por exemplo. Aqui, vou mostrar alguns conceitos de evasao que vao servir de pontape' inicial para estudos mais profundos. [ --- 5.1 Unicode O Unicode e' o padrao de codificacao de caracteres desenvolvido pelo Unicode Consortium. Essa codificacao sempre foi problematica devido a existencia de diferentes padroes (ASCII pt, en, etc..) e da incompatibilidade entre eles de- vido `as diferentes interpretacoes, por exemplo, dos caracteres especiais e acentuados. O conjunto de caracteres Unicode tem varias formas de representacao como UTF-8, UTF-16 e UTF-32. Unicode e' requerido por varios padroes incluindo Java, LDAP e XML. [ --- 5.1.1 Problemas Um exemplo e' o caracter "\". Sob o UTF-8 original, poderia ser representado por um hex 5C, C19C e E0819C. Muitas aplicacoes mais velhas que suportam UTF-8 aceitarao os tres valores e executam a transformacao ao backslash. Um claro problema das representacoes multiplas e' o Microsoft IIS 4/5 Extended Unicode Directory Traversal Vulnerabilty: O IIS verifica se ha' o diretorio transversal antes de descodificar UTF-8. O ataque era simples (os leitores mais antigos devem lembrar): O objetivo era acessar o endereco http://victim/../../winnt/system32/cmd.exe, e para isso, o atacante codifica os "../.." em UTF-8 para "..%C1%9C.." Isso tambem e' o chamado String Obfuscation/Manipulation. [ --- 5.2 Codigos Polimorficos - ShellCode Essa e' uma boa tatica, e os IDSs nao se defendem facilmente. Basicamente, um shellcode polimorfico e' aquele que possui em seu payload de dados um codigo que e' capaz de se modificar quando executado na maquina alvo. Sua forma de evadir foi pensada nos moldes dos virus em relacao ao anti-virus, e por isso ele se torna mais perigoso em filtros de assinaturas, ja que ele nao tem uma unica assinatura detectavel. Isso recai naquela historia tratada na sessao 3.2.1. Uma tentativa de evitar o sucesso desse ataque e' procurar por uma quantidade razoavel de instrucoes no-op ou tentar deixar o filtro o mais abrangente pos- sivel. Nota: Os usuarios do Snort pode conferir o pre-processador (spp_fnord), desen- volvido por Dragos Ruiu e feito para essas ocasioes. Pra falar a verdade eu nunca testei esse pre-processador e por isso nao posso dizer o quanto ele e' eficiente. Para maiores informacoes, um otimo material em portugues e' a monografia de Rodrigo Rubira Branco a.k.a BSDaemon [ --- 5.3 DDoS Um ataque DDoS, de maneira geral, e' essencialmente uma tentativa de tornar os recursos de um sistema indisponiveis, e e' sem duvida, a forma menos elegante de evasao. Existem varias ferramentas (ou faca voce mesmo, em ambiente de testes) que fazem o seguinte: * Consumem o poder de processamento, memoria, banda; * Estouro de disco; * Geracao de excessivos alertas; * Travar dispositivo; Questoes a serem pensadas: Na questao relacionada a consumir CPU, um bom exemplo e' quando o Snort faz seu output de logs num DB. O problema disso e' que cada vez que um output for inse- rido, ele ira fazer um INSERT no banco, consumindo um bom recurso de cpu. Para geracao excessiva de alertas e' se pode gerar diversos eventos do tipo "falso-positivo" ou simplesmente irrelevantes, e no meio deles um evento poten- cialmente perigoso, que termina por ser um "falso-negativo" dentro do contexto. Isso torna dificil a analise do operador, tendo em vista que o mesmo vera' diversos eventos legitimos, e apenas 1 ilegitimo, no meio de milhares de even- tos. No caso do estouro de disco, um exemplo e': Se for gerado denovo um numero excessivo de logs e isso faca com que a particao em que os logs (assumindo que voce deixa os logs na mesma maquina do IDS) chegue a 100% de uso, nada podera' ser logado, inclusive ataques reais. [ --- 5.4 Fragmentacao e Reassembly Eu considero essa a mais "low-level" de todas as tecnicas apresentadas. Vamos entender: Quando um pacote extrapola seu limite maximo (MTU), um recurso usado pelo IP (e por outros protocolos) e' o da fragmentacao e remontagem (reassembly). O roteador negocia com os perifericos de rede e com o proximo roteador o tamanho maximo que pode ser usado naquela sub-rede. Datagramas com tamanhos maiores deverao ser entao fragmentados. A operacao de fragmentacao consiste em quebrar os dados do datagrama em unida- des transportaveis, copiar o cabecalho para cada uma delas e finalmente enviar. Mas eles podem chegar em seu destino fora de ordem, mesmo quando transmitido em ordem, por isso, a cada pacote e' dado um numero que indique seu lugar dentro da ordem da stream. Isso 'e chamado de numero de sequencia. Voltando: Para descobrir o que esta acontecendo numa determinada conexao TCP, o IDS realiza a reconstrucao exata do trafego que esta sendo gerado sobre uma conexao do TCP. Ordem de chegada------------------> [1] [2] [3] [4] [5] [A] [C] [H] [!] [K] <---------------------Ordem de saida [1] [2] [3] [4] [5] [H] [A] [C] [K] [!] Um dos fatos que torna dificil essa reconstrucao e' seguir o numero de sequen- cia exato dos pacotes. Se um IDS esquecer muitos pacotes ele pode, consequente- mente, perder tambem alguns numeros de sequencia. Isso causaria uma falta de sincronia na conexao, fazendo com que a recuperacao de perda de pacote, assim como a sua resincronizacao, seja impossibilitada. Entao, ate o IDS conseguir resincronizar a conexao, um ataque poderia ter acon- tecido. Ou seja, o ataque acontece justamente no modo como os pacotes sao remontados e reagrupados no final da fragmentacao. Outro ponto e' que se alguns fragmentos forem perdidos, o datagrama nao pode ser remontado. Quem recebe os fragmentos inicia um temporizador de remontagem quando chega o primeiro fragmento. Se o temporizador terminar antes que todos os fragmentos cheguem, o receptor descarta os fragmentos remanescentes sem processar o datagrama. Assim, a probabilidade de perda de datagrama cresce quando a fragmentacao ocorre, porque a perda de um fragmento unico resulta na perda do datagrama inteiro. [ --- 6. Referencias [1] :Guidelines for a Long Term Competitive Intrusion Detection System Erwan Lemonnier [2] :The Science of Vulnerability Filters: A Virtual Software Patch [3] :Network Intrusion Detection: An Analyst Handbook [4] :Ataques Polimorficos Rodrigo Rubira Branco [3] :Wikipedia, Google