Baixe o app para aproveitar ainda mais
Prévia do material em texto
1 Conceitos para perícia forense computacional Adriano Mauro Cansian UNESP – Universidade Estadual Paulista Depto. de Ciências da Computação e Estatística Laboratório ACME! de Pesquisa em Segurança1 Campus de São José do Rio Preto R. Cristóvão Colombo, 2265 15055-000, São José do Rio Preto, SP, Brasil adriano@ieee.org Abstract This work presents basic concepts about forensics analysis on computers and networks that have been involved in some security incident. Two main strings of action are developed. Initially are presented concepts that allow to understand the current panorama of problems related with attacks to networks and computers systems. In this direction, a presentation on behavior and methodology of the attacker is made, following a philosophy that is necessary to know the enemy, to be able to analyze and combat it. Basic concepts on the collection of auditorship data, and the importance of these logs on network devices are argued. Also, fundaments related with organization’s security policies are focused. In one second part, the concepts of forensic skill and collection of evidences for security events analysis are indexed. Aspects on data capture and freezing are dealt, as well as the reconstruction of last and past events. This methodology is adopted based on the importance of evidences collection for a standardization, which allows to analyze and to prove the occurred events. Resumo Este trabalho apresenta uma discussão a respeito de conceitos fundamentais para a realização de perícia forense em computadores e redes que tenham experimentado algum incidente de segurança. São abordadas duas linhas principais de ação. Inicialmente são apresentados conceitos que permitem entender o panorama atual dos problemas relacionados com os ataques às redes e sistemas de computadores. Neste sentido, é feita uma apresentação sobre o comportamento e a metodologia do atacante, dentro de uma filosofia de que é necessário conhecer o inimigo, para poder analisa-lo e combate-lo. São discutidos conceitos básicos sobre a coleta de dados de auditoria, e a importância destes registros nos equipamentos de uma rede. Também são enfocados conceitos relacionados com políticas de segurança da organização. Numa segunda parte, são discutidos os conceitos de perícia forense e coleta de evidências para análise de eventos de segurança. São tratados aspectos sobre captura e congelamento dos dados, bem como a reconstrução de eventos passados. Adota-se uma metodologia de trabalho baseada na importância da coleta de evidências dentro de um padrão sistematizado, o qual permita analisar e comprovar os eventos ocorridos. 1 http://www.acme-ids.org 2 I. INTRODUÇÃO Apesar de analistas internacionais considerarem que os crimes em redes de computador representam perdas de milhões de dólares, é muito difícil estimar qual o real montante de prejuízos envolvidos anualmente, principalmente porque, na grande maioria das vezes, os ataques não são relatados em função da perda de prestígio e credibilidade que eles podem representar [1] . Sabe-se também que o risco tende a aumentar pois, com o passar dos anos e com a disseminação de informações (notadamente através da Internet), houve um significativo avanço no entendimento de como os sistemas operam. Isso fez com que intrusos se tornassem verdadeiros especialistas em determinar e explorar vulnerabilidades a fim de obterem acessos privilegiados. Estes mesmos intrusos também passaram a se utilizar de técnicas de ataque de difícil rastreamento e identificação. Freqüentemente usam diversos níveis de ocultação e dissimulação, antes de realizar um ataque. Procuram despistar o alvo, e raramente são surpreendidos, realizando ataques massivos, que evidenciem facilmente uma atividade suspeita ou anormal. Além disso costumam cobrir seus rastros, de forma que as atividades realizadas no sistema penetrado não são facilmente descobertas [2]. De uma forma abrangente, Garfinkel e Spafford [3] definem um sistema computacional seguro como sendo aquele que se comporta da maneira esperada. A observação do comportamento esperado, em comparação com o comportamento apresentado, pode ser entendido como o nível de confiança do sistema, e indica o quanto podemos confiar no seu funcionamento. O comportamento esperado é formalizado dentro da política de segurança do sistema, e regula as metas que este deve cumprir. Dessa forma, um evento de segurança normalmente está relacionado a uma violação de normas ou procedimentos, que dependem do sistema computacional em uso. Uma definição mais rígida de segurança de computadores baseia-se na confidencialidade, na integridade e na disponibilidade dos recursos do sistema [4]. Confidencialidade requer que a informação seja acessível somente àquelas pessoas autorizados para tal; integridade requer que a informação permaneça intacta e inalterada por acidentes ou ataques, e disponibilidade requer que o sistema computacional funcione adequadamente, sem degradação de acesso, fornecendo recursos aos usuários autorizados, quando eles assim necessitarem. A confidencialidade pode ser importante para o sucesso comercial ou até mesmo sobrevivência de uma empresa; integridade pode ser importante para um hospital que mantém históricos médicos de seus pacientes e os utiliza para tomadas de decisões em situações críticas. A disponibilidade de um recurso pode ser fator determinante no controle de um sistema de tráfego aéreo ou possibilidade de 3 retaliar um ataque militar. Nesta definição, um sistema computacional que não forneça todos os recursos necessários no devido momento, é tratado como não-confiável, uma vez que o conjunto representa os requisitos de segurança e, isolados ou em conjunto, podem representar um risco em potencial. O que se pretende discutir aqui é que, apesar de possuir muitos pontos comuns, a definição de segurança em sistemas de computadores é extremamente flexível e dependente de uma série de fatores e características. É preciso entender a segurança de um sistema computacional não como sendo um item particular, um produto ou uma determinada medida ou ação. A segurança deve ser interpretada como um processo, o qual envolve elementos tecnológicos complexos ou não, mas que deve considerar também aspectos humanos. Um sistema seguro deve conter um conjunto de ações que permitam proteger seus dados, e seus recursos, de acesso não-autorizado, de intromissão ou de bloqueio de uso. Sabe-se que segurança é obtida a custo da conveniência e facilidade de uso dos sistemas. Pode-se afirmar também que a facilidade de conectividade de computadores é inversamente proporcional à segurança. Controle de acesso e modelos de proteção não são muito úteis contra atacantes internos ou contra o comprometimento dos módulos de autenticação de acesso a um sistema computacional [5]. Se uma senha de acesso a uma conta do sistema é fraca, e foi comprometida, as medidas de controle de acesso não têm como prevenir a perda ou corrupção dos dados aos quais aquela conta tem acesso. Em geral, métodos estáticos de proteção podem simplesmente ser insuficientes, ou podem tornar o sistema extremamente restritivo aos seus próprios usuários. Por exemplo, considere que uma determinada técnica de segurança não seja capaz de prevenir ou detectar violação de política de segurança resultante de buscas generalizadas em arquivos de dados; e se por essa razão o acesso a todos os arquivos tenha que ser controlado rigorosamente, o sistema pode se tornar ineficiente para o uso proposto. Um outro aspecto a se considerar é que a dificuldade em se produzir softwares complexos, funcionais e isentos de erros ainda é uma questão a ser resolvida. Diversas falhas em sistemas freqüentemente se manifestam como vulnerabilidades na segurança. Há que se considerar também, que os ciclos de vida útil dos softwaresestão se tornando cada vez mais curtos devido à competitividade do mercado. Isso geralmente tem como efeito colateral uma programação pobre e inadequada, ou então leva a testes e validações insuficientes ou mal planejados, fatos estes que só vem a agravar o problema. Desse modo, acredita-se que sistemas computacionais, e principalmente redes, continuarão potencialmente inseguros ainda por muito tempo [6]. 4 Dentro deste contexto, a análise e a perícia de computadores que tenham passado por algum tipo de violação ou ataque, torna-se uma matéria importante no conjunto de ações de um processo de segurança. A perícia tem diversos aspectos relevantes. Dois deles se destacam: primeiramente, ela é importante porque permite que se entenda o que aconteceu, de forma a corrigir falhas que tenham sido cometidas no processo. Em segundo lugar, ao olharmos para o passado, interpretando o que aconteceu, pode ser possível coletar evidências necessárias a identificar o atacante, de tal forma que possam ser adotadas medidas legais ou jurídicas pertinentes. Novamente, uma violação de segurança é fortemente dependente da política de utilização do sistema, e deve ser entendida nesta particularidade. Este fato é muito importante e será memorado insistentemente ao longo deste trabalho. A perícia de computadores é uma tarefa que envolve a consideração de aspectos objetivos e subjetivos, por vezes associada a análise tecnológica, mas por outras vezes fortemente dependente de questões comportamentais e de perfil, relativas ao atacante. Desta forma, torna-se fundamental o conhecimento acerca de como pensam e agem os inimigos. II. PANORAMA ATUAL Os rumos da Segurança A sofisticação dos ataques e ferramentas de intrusões e, por conseqüência, a eficiência dos intrusos está aumentando. O conhecimento vem sendo passado aos intrusos menos hábeis pelos atacantes mais experientes. Além disso, complexidade das redes cresce a passos largos, resultando sempre em novas oportunidades de violações de segurança, tanto em nível local, como provenientes do mundo exterior, principalmente através da Internet [7]. Em função destes aspectos, atualmente, o número de intrusões e ataques a redes de computadores vem sofrendo taxas de crescimento significativas. A infra-estrutura de informação tem muitos problemas de segurança fundamentais, os quais não podem ser resolvidos rapidamente. O número de pessoas com conhecimento em segurança está aumentando, mas a uma taxa significativamente menor que o aumento no número de usuários. O número de ferramentas de segurança disponíveis está aumentando, mas não necessariamente tão rápido quanto a complexidade de softwares, sistemas e redes. O número de equipes de resposta a incidentes tem crescido, entretanto a relação entre pessoal de resposta a incidentes e usuários de Internet, e de redes em geral, está diminuindo [1]. Por razões econômicas e mercadológicas, o ciclo de desenvolvimento e testes de produtos está sendo reduzido cada vez mais, fazendo com que, novamente, apareçam outras possibilidades de exploração de vulnerabilidades. 5 Assim, empresas continuam produzindo softwares com vulnerabilidades, incluindo tipos onde a prevenção já é bem compreendida, como por exemplo, problemas envolvendo falhas de buffer overflow [3]. Conhecendo o atacante O perfil dos atacantes pode ser dividido genericamente em dois padrões: os atacantes provenientes do meio interno, oriundos da própria organização, empresa ou instituição, e os atacantes externos, normalmente provenientes da Internet [8]. É comum acreditar-se, erroneamente, que os ataques mais sérios, e que causam mais prejuízos, são provenientes da Internet. Esta crença comum geralmente é compartilhada em virtude da cobertura da mídia, que destaca, muitas vezes de forma sensacionalista, determinados casos de hacking que ocorrem através da Internet. Entretanto, pesquisas recentes mostram que a maioria dos ataques que envolvem perdas financeiras ocorrem, ou contam com a cooperação, de alguém de dentro das próprias organizações atacadas [1]. Os atacantes oriundos do meio interno tem um comportamento mais complexo do que os atacantes externos. As análises destes casos mostram que estes tipos de crimes eletrônicos, intrusões ou tentativas de ataque ocorrem em virtude dos mesmos motivos pelos quais ocorrem a maioria dos crimes regulares. São associados principalmente com cobiça, obtenção ilegal de dinheiro, lucro, riqueza ou acesso a recursos adicionais ou restritos, ou ganho de vantagem competitiva, seja ela econômica, política ou pessoal. Freqüentemente estão também ligados a revanches pessoais ou vinganças [9]. Em se tratando de violações de segurança provenientes do meio externo, o atacante tem sido sempre alguém em busca de um alvo fácil, que não está em busca de algo específico. Entretanto, seu objetivo é claro: ganhar acesso privilegiado, da maneira mais fácil possível, concentrando-se num número pequeno de ferramentas e exploits, varrendo toda a Internet. Estes atacantes são denominados genericamente de script kiddies [9]. Alguns são usuários avançados que desenvolvem suas próprias ferramentas, e deixam backdoors sofisticados, ao passo que outros não têm a menor idéia do que estão fazendo. Independentemente de suas habilidades, eles compartilham de uma estratégia comum: buscam aleatoriamente por uma vulnerabilidade específica e, então, exploram aquela vulnerabilidade. Em algum momento os atacantes encontrarão alguém vulnerável. A seleção aleatória de alvos é que torna o script kiddie uma ameaça, pois ao não buscar alvos específicos, todos os sistemas estão potencialmente ameaçados [10]. As ferramentas de busca de vulnerabilidades e ataques estão amplamente divulgadas, de 6 tal forma que qualquer pessoa pode obte-las e usa-las. Há um número crescente de atacantes fazendo uso delas. Uma vez que a Internet, obviamente, não possui fronteiras, estas ameaças estão se espalhando mundialmente. Os sistemas que os script kiddies estão procurando são aqueles não supervisionados, sem registros de auditoria (“logs”), sem política de uso, desprotegidos, e fáceis de serem explorados. Ao encontrarem algumas barreiras, eles geralmente mudam de alvo. Estes atacantes são motivados, principalmente, por curiosidade, ganho de acesso a recursos computacionais restritos, distúrbios comportamentais ligados a vandalismo e vontade de provocar danos, ou busca por atenção e projeção. Padrões comportamentais ligados a revanche e vingança pessoal também são freqüentes. Obtenção de vantagens financeiras aparecem em menor escala, mas também estão presentes, entretanto, com gravidade inferior se comparados aos danos causados pelos atacantes internos. Entretanto, com o aumento gradativo de operações comerciais ocorrendo por intermédio da Internet, é provável que esta característica venha a se modificar. Em resumo, há um senso comum de que os intrusos estão preparados e bem organizados. Os ataques, provenientes da Internet ou internos, são fáceis, de baixo risco e muito difíceis de serem rastreados. As ferramentas dos intrusos estão crescendo em sofisticação, são fáceis de usar, especialmente por novatos, e são desenhadas para darem suporte a ataques em larga escala. A metodologia dos atacantes Tanto os ataques internos como os externos acontecem dentro de padrões bem definidos e de acordo com uma seqüência de eventos que permitem estabelecer perfis ou padrões comportamentais. A metodologia básica é simples: rastrear a rede, ou o computador alvo, buscando vulnerabilidades específicas, estabelecendo uma base de dados de endereços IP que possam ser atacados. Assim que encontrar uma vulnerabilidade, tentar explora-la, verificando se existe realmente a falha naquele equipamento [11]. Por exemplo, atualmente muitos sistemas Linuxpossuem uma vulnerabilidade nativa no processo denominado imapd . É feita uma busca por IPs válidos e ativos e desenvolve-se uma base de dados relacionando os sistemas rodando Linux. Por intermédio de ferramentas específicas [12], verifica-se quais estão rodando imapd vulnerável. A partir desta informação, os sistemas vulneráveis são explorados. Um terreno fértil para a proliferação deste tipo de ataque é a ausência de monitoração e inspeção dos computadores e redes. Muitas organizações não monitoram seus sistemas de forma alguma, e nunca 7 percebem que estão sendo atacados ou rastreados. São raros os sistemas com uma política clara e bem definida e escrita sobre geração e inspeção regular de registros de auditoria (logs). Quando há logs, estes não são sequer monitorados, nem automaticamente, nem por um humano. Os atacantes muitas vezes buscam silenciosamente por um sistema que possam explorar e, ao ganharem acesso a este, encobrem seus rastros eliminando registros de auditoria que eventualmente existam. Em seguida, utilizam o computador comprometido como base de lançamento para outros ataques, ocultando sua posição real e colocando a responsabilidade em outros administradores. A figura 1 mostra um esquema típico do desenvolvimento de um ataque deste tipo. Localizar Sistema para atacar Obter acesso privilegiado ( root ) Obter acesso de nível de usuário Instalar backdoors Atacar outros Roubar ou alterar dados Executar outras atividades não autorizadas Encobrir os rastros Figura 1 – Comportamento típico da evolução de um ataque Os resultados dos rastreamentos costumam ser armazenados, e são freqüentemente compartilhados com outros atacantes. Quando uma nova vulnerabilidade aparece, os resultados de prospeções anteriores podem ser usados como referência. Isso significa que, mesmo que um sistema não tenha sido rastreado recentemente, ele não está isento de um ataque ou exploração de uma vulnerabilidade. Atacantes mais sofisticados implementam e instalam programas que comprometem completamente os sistemas invadidos. Estes programas maliciosos, conhecidos genericamente como trojans e backdoors, permitem acesso fácil e oculto, de tal forma que os intrusos passam a usar o sistema sem serem notados. Os sistemas auditores, indicadores de processos, ou mesmo filesystems, são freqüentemente comprometidos ou corrompidos e tornam-se não confiáveis. Quando se consideram ataques através da Internet, a questão temporal e os horário não são significativos. 8 Os ataques acontecem a qualquer hora e, muitas vezes, em larga escala. Existem ferramentas automáticas de busca de vulnerabilidade, as quais operam 24 horas por dia, coletando dados. Além disso, há abrangência mundial dos ataques, o que torna a questão de fuso horário pouco útil. Ao contrário dos ataques que ocorriam no passado, as ferramentas de ataque, muitas das quais disponíveis publicamente na Internet, são de fácil utilização e não exigem conhecimento específico em redes ou em sistemas. Algumas são limitadas a um único propósito, com poucas opções, e outras são mais versáteis, varrendo indiscriminadamente as redes ou os computadores alvo, a procura de vulnerabilidades. Observando os atacantes Informações importantes sobre as questões e eventos de segurança de um sistema podem ser obtidas por intermédio dos registros de auditoria. Com alguns procedimentos simples é possível analisar questões importantes, sem necessidade de investimentos ou recursos adicionais, além daqueles já regularmente presentes na maioria dos sistemas. Através de informações básicas extraídas dos logs é possível determinar se os sistemas foram examinados, o que os atacantes buscaram saber, que ferramentas ou técnicas foram usadas e, eventualmente, se obtiveram sucesso. Informações significativamente úteis podem ser obtidas através da simples análise e revisão de registros de auditoria. Entretanto, numa quantidade alarmante de instalações, sequer existe qualquer sistema auditor, que registre as ocorrências e faça as contabilizações nos sistemas. Também é importante ressaltar que sistemas de auditoria são freqüentemente os primeiros alvos dos atacantes. Desta forma, é preciso proteger e garantir a integridade dos registros, caso contrário eles se tornam inúteis. Há uma variedade de ferramentas que removem a presença dos atacantes dos registros, e existem processos auditores (syslogd) corrompidos, os quais não registram as ações dos intrusos. O atacante que tenha comprometido uma máquina pode estabelecer um ação automática que remova completamente todos os registros, ou até mesmo uma partição inteira. A importância dos logs Em vista destas considerações, um dos principais aspectos que permite a execução de uma perícia bem sucedida em um sistema, é a existência de registros de auditoria que estejam íntegros e confiáveis. Independentemente de quão seguro é um computador ou uma rede, nunca será possível confiar totalmente nos registros de um sistema que tenha sido comprometido. Isso dificulta, ou mesmo impossibilita, uma 9 perícia com sucesso. Desta forma, um dos principais conceitos a serem aplicados é o registro dos logs tanto no sistema local, como num servidor de auditoria remoto. Quando os registros de auditoria estão seguros num equipamento especial, existem maiores possibilidades de sucesso ao se correlacionar e identificar padrões, ou rever rapidamente o que está acontecendo em todas as máquinas da rede, usando só uma fonte de informação. Além disso, é possível realizar comparações para determinar se os logs de origem foram modificados. Para alcançar estes objetivos, uma recomendação é estabelecer um sistema de logs centralizado e dedicado, ou seja, que tenha como função exclusiva a coleta de registros de auditoria, sem outros processos ou serviços. Uma opção recomendável pode ser estabelecida, com baixo custo, por intermédio de uma máquina com sistema operacional gratuito, como por exemplo Linux ou FreeBSD, agindo exclusivamente como coletora de logs na rede local. Como exemplo da importância deste procedimento, podemos analisar o caso anteriormente mencionado, onde a maioria dos Script Kiddies varre a rede em busca de uma única vulnerabilidade. Se os logs indicam múltiplas conexões, do mesmo sistema remoto, na mesma porta, possivelmente trata-se de uma varredura de alguma vulnerabilidade. A figura 2 apresenta um registro que permite correlacionar os eventos de uma rede local. A figura 3 mostra a identificação de uma varredura genérica, e a figura 4 mostra a identificação de um ataque de buffer overflow. A figura 5 mostra uma tentativa de exploração de uma vulnerabilidade num servidor de http. Servidor de logs - /var/adm/logs Oct 09 22:13:48 wolverine in.ftpd[8723]: connect from 200.145.202.223 Oct 09 22:13:51 shadowcat in.ftpd[8723]: connect from 200.145.202.223 Oct 09 22:13:54 casper in.ftpd[8723]: connect from 200.145.202.223 Oct 09 22:13:57 fantasma in.ftpd[8723]: connect from 200.145.202.223 Oct 09 22:13:58 nimitz in.ftpd[8723]: connect from 200.145.202.223 Oct 09 22:14:02 bart in.ftpd[8723]: connect from 200.145.202.223 Figura 2 – Uma varredura ocorrida em servidores de ftp numa rede local, provenientes do computador 200.145.202.223 10 Servidor de logs - /var/log/secure Oct 09 22:13:56 bart in.telnetd[22221]: connect from 200.145.202.223 Oct 09 22:13:56 bart imapd[22331]: connect from 200.145.202.223 Oct 09 22:13:56 bart in.fingerd[22249]: connect from 200.145.202.223 Oct 09 22:13:56 bart ipop3d[22322]: connect from 200.145.202.223 Oct 09 22:13:56 bart in.telnetd[22378]: connect from 200.145.202.223 Oct 09 22:13:56 bart in.ftpd[22541]: connect from 200.145.202.223 Oct 09 22:16:03 bart ipop3d[22542]: connect from 200.145.202.223 Oct 09 22:16:03 bart imapd[22543]: connect from 200.145.202.223Oct 09 22:16:04 bart in.fingerd[22546]: connect from 200.145.202.223 Oct 09 22:16:05 bart in.fingerd[22552]: connect from 200.145.202.223 Figura 3 – Uma varredura genérica na máquina “bart” da rede local, proveniente do computador 200.145.202.223, buscando por serviços disponíveis. Servidor de logs - /var/log/secure Oct 10 22:04:51 bart mountd[6688]: Unauthorized access by NFS client 200.145.202.223. Oct 10 22:04:51 bart syslogd: Cannot glue message parts together Oct 10 22:04:51 bart mountd[6688]: Blocked attempt of 200.145.202.223 to mount ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~ P~P~P3Û3À°^[Í~@3Ò3À~KÚ°^FÍ~@þÂuô1À°^BÍ~@~EÀubëb^V¬<ýt^FþÀt^Këõ°0þÈ~HFÿëì^°^B~ I^FþÈ~IF^D°^F~IF^H°f1ÛþÃ~IñÍ~@~I^F°^Bf~IF^L°*f~IF^N~MF^L~IF^D1À~IF^P°^P~IF^H° fþÃÍ~@°^A~IF^D°f³^DÍ~@ë^DëLëR1À~IF^D~IF^H°fþÃÍ~@~Hð?1ÉÍ~@°?þÁÍ~@°?þÁÍ~@¸.bin@~ I^F¸.sh!@~IF^D1À~HF^G~Iv^H~IF^L°^K~Ió~MN^H~MV^LÍ~@1À°^A1ÛÍ~@èEÿÿÿÿýÿPrivet ADMcrew~P(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(Oct 10 22:04:51 bart ^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^ E^H(-^E^H-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E ^H(-^E^H-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^ H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E ^H(-^E^H(-^E Figura 4 – Um ataque de buffer overflow, possivelmente com sucesso, proveniente de 200.145.2.223, tendo como alvo a máquina “bart”. 11 Servidor de logs - /var/log/httpd/access_log 200.145.202.223- - [10/Oct/2000:22:04:13 -0300] "GET /cgi-bin/phf HTTP/1.0" 302 192 200.145.202.223- - [10/Oct/2000:22:04:13 -0300] "GET /cgi-bin/Count.cgi HTTP/1.0" 404 170 200.145.202.223- - [10/Oct/2000:22:04:13 -0300] "GET /cgi-bin/test-cgi HTTP/1.0" 404 169 200.145.202.223- - [10/Oct/2000:22:04:13 -0300] "GET /cgi-bin/php.cgi HTTP/1.0" 404 168 200.145.202.223- - [10/Oct/2000:22:04:13 -0300] "GET /cgi-bin/handler HTTP/1.0" 404 168 200.145.202.223- - [10/Oct/2000:22:04:13 -0300] "GET /cgi-bin/webgais HTTP/1.0" 404 168 200.145.202.223- - [10/Oct/2000:22:04:13 -0300] "GET /cgi-bin/websendmail HTTP/1.0" 404 172 200.145.202.223- - [10/Oct/2000:22:04:13 -0300] "GET /cgi-bin/webdist.cgi HTTP/1.0" 404 172 200.145.202.223- - [10/Oct/2000:22:04:13 -0300] "GET /cgi-bin/faxsurvey HTTP/1.0" 404 170 200.145.202.223- - [10/Oct/2000:22:04:13 -0300] "GET /cgi-bin/htmlscript HTTP/1.0" 404 171 200.145.202.223- - [10/Oct/2000:22:04:13 -0300] "GET /cgi-bin/pfdisplay.cgi HTTP/1.0" 404 174 200.145.202.223- - [10/Oct/2000:22:04:13 -0300] "GET /cgi-bin/perl.exe HTTP/1.0" 404 169 200.145.202.223- - [10/Oct/2000:22:04:13 -0300] "GET /cgi-bin/wwwboard.pl HTTP/1.0" 404 172 200.145.202.223- - [10/Oct/2000:22:04:14 -0300] "GET /cgi-bin/ews/ews/architext_query.pl HTTP/1.0" 404 187 200.145.202.223- - [10/Oct/2000:22:04:14 -0300] "GET /cgi-bin/jj HTTP/1.0" 404 163 Figura 5 – Uma tentativa de exploração de uma vulnerabilidade cgi-bin num servidor de http. Conforme pode ser notado, a centralização dos logs assume um papel determinante na análise de incidentes, e até mesmo na adoção de contra medidas. Entretanto, é importante mencionar que, obviamente, se um serviço não está sendo auditorado ou registrado, não é possível determinar se o sistema foi rastreado por aquela vulnerabilidade em particular. Além disso, outro aspecto importante que os peritos e analistas de segurança devem considerar é o conhecimento acerca do que os registros de auditoria não podem fornecer. Nem sempre os registros de auditoria resultam em informações úteis. Diversas ferramentas de ataque possuem a opção de realizar varreduras com falsificação de endereços IP de origem (IP spoofing). Algumas ferramentas automatizadas, como por exemplo o nmap [12], têm condições de falsificar a origem do ataque, apresentando as varreduras como provenientes de 15 fontes diferentes, onde, entretanto, somente uma é a real. Isso que torna bastante complexa a tarefa de determinar qual delas é a verdadeira. Também existem técnicas de prospeção chamadas de “half-scan”. Esta é uma das técnicas de ocultação e dissimulação mais freqüente. A varredura de half-scan usa só um pacote SYN do handshake de 3 vias do estabelecimento da conexão TCP. Se o sistema remoto responde, a conexão é descartada com um pacote RST. Isso torna bastante difícil a determinação da origem do ataque, apenas com a utilização dos registros de auditoria. Neste caso, outras técnicas de análise precisam ser empregadas em conjunto. A figura 6 apresenta um registro de auditoria de uma varredura de half-scan. 12 Servidor de logs - /var/adm/log Oct 10 22:12:08 bart in.rshd[12717]: warning: can't get client address: Connection reset by peer Oct 10 22:12:08 bart in.rshd[12717]: connect from unknown Oct 10 22:12:09 bart in.timed[11718]: warning: can't get client address: Connection reset by peer Oct 10 22:12:09 bart in.timed[12718]: connect from unknown Oct 10 22:12:09 bart imapd[12719]: warning: can't get client address: Connection reset by peer Oct 10 22:12:09 bart imapd[12719]: connect from unknown Oct 10 22:12:09 bart ipop3d[12720]: warning: can't get client address: Connection reset by peer Oct 10 22:12:09 bart ipop3d[12720]: connect from unknown Oct 10 22:12:09 bart in.rlogind[12722]: warning: can't get client address: Connection reset by peer Oct 10 22:12:09 bart in.rlogind[12722]: connect from unknown Figura 6 – Um registro de auditoria de uma varredura de half-scan. Observe que a origem não pode ser determinada Como conclusão desta discussão, é importante ressaltar que os registros de auditoria tratam-se de uma técnica simples que pode dizer muito sobre o atacante, desde que existam de fato, e estejam protegidos, dentro de uma política bem definida. Uma vez que existem os registros, é possível identificar padrões e correlações, permitindo até mesmo saber o que o intruso procura, ou (talvez) se ele teve ou não sucesso [13]. III. FORENSICS Uma introdução às técnicas de perícia forense em computadores e redes Segundo Dan Farmer, a perícia computacional (forensics) “trata-se da captura e análise de evidências, tanto quanto possível livres de estarem distorcidas ou tendenciosas, de tal forma a reconstruir determinados dados ou o que aconteceu num sistema no passado”. Existem muitos desafios para a concussão destes objetivos. Os sistemas são grandes e complexos, e mudam rapidamente, e os fatos e as evidências podem estar ocultos em qualquer lugar, praticamente inexistindo softwares especializados disponíveis para tratar o problema. Em função disso, exige-se muito conhecimento e experiência. É fácil coletar dados, mas a análise é difícil. Além disso, esta análise exige muito tempo disponível. Associe-se a isto o problema de se armazenar as grandes quantidades de dados resultantes de registros de auditoria e perícia. Desta forma, um perito em análise de sistemas invadidos ou comprometidos necessita dispor de certas características especiais, principalmente conhecimentos e habilidades relativas aos sistemas em questão, e entendimento pleno acerca das implicações técnicas e legais de suas ações. Características concernentes a espírito investigativo, suspeição e ética também são determinantes para o sucesso oufracasso das ações. 13 Ao se deparar com a condução de uma análise, o perito deve isolar e assegurar o perímetro, registrando a “cena do crime” da melhor maneira possível, e conduzindo uma busca sistemática por evidências, coletando e armazenando as que encontrar. A velocidade das ações é essencial, mas estas devem ser levadas em consideração sem colocar em risco a coleta ou a veracidade das informações. O perito também deve ter em mente que qualquer operação executada num sistema, causará alguma perturbação em seu estado. Além disso, atacantes hábeis conhecem como as perícias são feitas e podem fornecer informações falsas em locais específicos. Por esta razão, o perito nunca deve confiar plenamente no sistema em questão. Além deste fato, outro aspecto importante diz respeito às leis vigentes na jurisdição, e as políticas da organização ou instituição. Estas devem ser levadas em consideração, e respeitadas. Sem este procedimento, a coleta de evidências pode ser inócua, ineficaz ou ilegítima. Durante a busca por evidências, a preservação do estado do sistema é um fator determinante. Sem a preservação do estado, pode acontecer de nunca se saber o passado. Desta forma, o perito sempre deve fazer a coleta de dados de acordo com a ordem de volatilidade. Como ordem de volatilidade, deve-se considerar coletar primeiramente os dados que forem mais efêmeros. A figura 7 apresenta a ordem de volatilidade dos dados de perícia mais usados. Registros de memória periférica, cache, etc... Memória do kernel e física Estado da rede, rotas, interfaces, etc... Registros de memória periférica, cache, etc... Processos em execução Discos, filesystems, partições Floppies, fitas e outros meios magnéticos CD-ROMs, cópias impressas, etc... Figura 7 – Ordem de volatilidade dos elementos de perícia mais utilizados. De cima para baixo, estão os dados mais efêmeros, a serem coletados primeiramente. Durante o tratamento de uma perícia em um sistema invadido ou atacado, alguns fatores muitas vezes imperceptíveis são as maiores causas dos problemas e dificuldades. Não saber exatamente o que aconteceu, e não conhecer contra quem, ou o que, se está lutando, são as maiores fontes dos problemas e dificuldades, 14 e por isso mesmo tornam-se os grandes desafios. Não saber em que dados confiar, dentre todos aqueles disponíveis para a perícia, fazem com que problemas mais complexos requeiram uma preparação mais elaborada, e um plano claro e bem definido para trata-los. Se o analista de segurança ou o perito não conhece o sistema, a situação deve ser abordada ainda com mais cautela. Deve-se conhecer e entender as limitações humanas, relativas a conhecimento técnico, para abordagem do problema, da mesma forma como devem ser conhecidas as limitações técnicas do sistema, da rede ou do equipamento sob análise. Esta abordagem deve ser adotada porque é muito fácil danificar, corromper ou mascarar inadvertidamente as evidências da perícia. Mesmo uma análise simples num sistema desconhecido pode ser arriscada, comprometendo definitivamente o trabalho a ser realizado, ou mesmo a validade legal da análise. Desta forma, o analista de segurança deve trabalhar o menos possível com os dados originais, ou seja, deve-se optar por providenciar uma imagem dos dados que serão usados e deve-se operar sobre este conjunto, seguindo sempre a ordem de volatilidade discutida acima. Dentro deste contexto, cumpre ressaltar novamente a importância de se aplicar sempre a política de segurança da organização, da mesma forma que devem ser observadas a legislação da jurisdição em questão. Com base nestes procedimentos, podem ser definidas metas claras de trabalho, de tal forma que a perícia seja válida, tanto em termos institucionais como legais e jurídicos. Dentre os aspectos relativos à política de segurança da organização, devem ser consideradas questões tais como: quem deve ser informado dos eventos encontrados, o que deve ser registrado, o que fazer com as evidências, que seqüência de ações devem ser seguidas, quais as prioridades, entre outros cuidados. Além disso, a maioria dos dados tem um componente fortemente dependente do tempo e do horário. Em função disso, deve-se construir uma base de tempo de referência, de tal forma que seja possível examinar uma certa janela de tempo, dentro daquela linha, permitindo determinar os eventos que tenham acontecido durante aquele período Congelamento de dados Segundo a física quântica, o Princípio da Incerteza de Heisenberg define que é impossível determinar, ao mesmo tempo, a velocidade e a posição de uma partícula, de tal forma que, ao se observar um deles, afeta- se o estado do outro. Tratamento similar pode ser adotado em computadores e redes, ou seja, em praticamente todos os casos, o ato de examinar ou coletar uma parte do sistema irá perturbar outros componentes. É impossível capturar completamente o estado total do sistema, num dado momento do 15 tempo. Desta forma, o analista de segurança deve esforçar-se, ao máximo, para capturar uma representação fiel do sistema, tão livre de distorções ou influências quanto possível. Esta é a essência da perícia, seja ela em computadores, ou numa cena de crime convencional. O perito deve ter extremo cuidado para não tocar em nada que possa perturbar a cena e, desta forma, comprometer a investigação. Durante a análise também é importante considerar que o perito não poderá confiar nos dados que obtiver, se não puder confiar nas suas ferramentas de trabalho. Portanto, é importante que o perito possua seu próprio conjunto de ferramentas de software para inspeção, captura e análise dos dados. A composição do conjunto de ferramentas irá depender sempre do tipo de sistema sob análise, e também do tipo de mídia disponível para transporte e manipulação. Como exemplo, em se tratando de um sistema UNIX, algumas ferramentas listadas a seguir podem ser consideradas indispensáveis. Opções semelhantes podem ser adaptadas para outros sistemas: • Ferramentas de coleta de dados tipo “statically linked”, tais como: dd, cp, du, cat, ls. • Ferramentas de identificação de estado do sistema, tais como: netstat, route, arp, last, who, finger. • FTP ou outro mecanismo para obter mais ferramentas ou extrair dados através da rede. • Linguagem de scripts Perl Este é um procedimento padrão, pois uma vez que um sistema foi comprometido, e dependendo do nível de conhecimento do atacante, não se pode confiar nem mesmo nos recursos mais simples, como por exemplo, listar os arquivos de um diretório (ls). Os recursos podem ter sido completamente modificados para ocultar a presença das ações do atacante, ou mesmo apresentar apenas o que este deseja. O conjunto de ferramentas deve sempre estar pronto antes de se precisar dele. Questões relativas ao Sistema Operacional em uso, qual a versão ou distribuição, se existe rede ou equipamentos auxiliares disponíveis, se existe um Notebook ou outras mídias, dentre outros, necessitam ser observadas na preparação das ações. Durante a realização da captura de dados de perícia, além de seguir a ordem de volatilidade dos dados, já discutida anteriormente, deve-se também levar em conta a “cadeia de confiança” do sistema. Esta cadeia de confiança está associada com maneira na qual ocorre a execução de um binário dentro de um sistema operacional. A cadeia de confiança apresenta a maneira como um sistema é perturbado durante a execução de um comando ou programa. A figura 8 apresenta a execução da cadeia de confiança, com as ações de execução de um binário. 16 Shell e variáveis de ambiente Comando ou programa Bibliotecas dinâmicas Device drivers Kernel Controladoras Hardware Ordem de perturbação ocorrida quando se executa um binário Figura 8 – A execução da cadeia de confiança,com as ações de execução e perturbação de um comando ou programa Uma das decisões que o analista de segurança deve tomar é com relação à manutenção da operacionalidade do sistema, ou seja, se o sistema deve ser mantido no ar ou não. Esta é uma decisão complexa, a qual deve, novamente, ser tomada com base na política de segurança e nas determinações superiores da organização. Deve ser considerado se o fato de manter o sistema no ar permitirá obter mais evidências ou, ao contrário, trará mais risco aos dados de perícia. Outro fato a ser considerado é com relação a restrições de tempo, maiores ou menores, dependendo da necessidade de se restabelecer o sistema. Por exemplo, em função da criticidade do sistema, pode ser necessário restabelece-lo imediatamente, o que deixa menos tempo livre para coletar as evidências. Além disso a decisão de manter ou retirar do ar, podem resultar em erros na replicação ou interpretação dos dados. Não existe uma regra geral para a tomada desta decisão, e é preciso que a política de segurança da organização seja seguida à risca. Reconstruindo eventos Durante a realização de uma perícia será necessário realizar uma reconstrução de eventos passados. Neste caso, o procedimento principal a ser adotado é a correlação de fatos. Ou seja, o analista deve estar apto a associar e comparar informações de diferentes fontes, para tentar espelhar a situação encontrada no sistema, com a maior fidelidade possível. Durante estes procedimentos será necessário observar cuidadosamente a 17 atividade de interesse, de tal forma a se determinar e reconstruir o que aconteceu no passado. Estas ações deverão permitir entender, determinar e relatar os danos ocorridos, e os acontecimentos passados. Também é preciso ter em mente que nenhum método ou técnica funciona sozinho. O perito deve combinar táticas para obter as respostas que procura, de tal forma a associar o que aconteceu, operando dentro de um tempo específico. Entre os métodos a serem aplicados na correlação de eventos, pode-se citar, em ordem de importância, os seguintes procedimentos e técnicas, bem como algumas questões associadas a eles: • Reconstrução do histórico dos usuários e suas operações. ! Quais usuários acessaram o sistema numa determinada hora ? ! Qual foi o padrão de uso de uma conta em particular ? • Reconstrução do histórico dos processos executados, ou em execução. ! Qual o Username, terminal e hora de início da sessão de cada processo ? ! Qual a quantidade de uso de memória e CPU ? ! Quais as linhas de comando de chamada do processo ? ! Qual o estado do processo no momento (running, sleeping, suspended, dead, etc...) ? ! Quais os comandos executados por um processo específico ? ! Quais os comandos dentro de uma sessão específica ? ! Quais as sucessivas instâncias de um processo ? ! Quais as seqüências de comandos específicos de um usuário ? ! Quais os processos rodando durante uma determinada janela de tempo ? ! Quais os processos residentes que iniciaram após o tempo de reboot ? • Reconstrução da situação das conexões de rede e roteamento. ! Qual a data, horário e destino da conexão ? ! Qual o nome do processo de rede e seu ID ? ! Qual o host cliente ? ! Opcional: Qual o usuário cliente ? (depende da existência de processo identd). • Arquivos dos registros de auditoria (logs). ! Quais as conexões de, e para, um site específico ? ! Quais as conexões para um serviço específico (por exemplo, telnetd ou ftpd) ? ! Quais as seqüências sucessivas de conexão de um site (por ex. finger seguido de telnet) ? ! Quais as conexões ocorridas num intervalo de tempo ? • Horários de acesso (ou modificação) de arquivos ou diretórios (M/A/C/times) [14]. ! mtime = modification time ! atime = access time ! ctime = status change time ! dtime = deletion time (presente em alguns Linux) ! Estes tempos são associados a qualquer arquivo ou diretório no UNIX, no Windows NT e em outros filesystems. Trazem uma quantidade significativa de informação. ! Existem cerca de 100.000 arquivos numa máquina Unix, representando 10 Mb de dados de M/A/C/times. ! Se disponível, é um conjunto de evidências que deve ser seriamente considerado. 18 • Network Sniffing (se possível). ! É difícil de detectar. ! Pode capturar todo o tráfego de rede. ! Excelente para acompanhar o ataque em andamento ou o retorno do atacante. ! Útil para controle de danos, e inútil para recuperação de dados. ! Exige alta capacidade de armazenamento. ! Dados encriptados são um problema e impossibilitam a aplicação desta técnica. ! Pode violar a privacidade de outros usuários. É fortemente dependente da política da organização e das leis vigentes. IV. CONCLUSÕES Dentro da discussão anteriormente apresentada, algumas conclusões podem ser obtidas para aplicação antes e depois de um incidente envolvendo computadores e redes. A principal conclusão deve ser centralizada na importância da existência de uma boa política de segurança. A política de segurança deve ser bastante clara e concisa, permitindo que seja utilizada como um procedimento-padrão, no caso de incidentes. Além disso, é importante que a política de segurança seja de amplo conhecimento dentro da organização. Também é muito importante conhecer os sistemas que estão em uso na organização. Uma vez que os sistemas sejam bem conhecidos, devem ser ativados os processos de registros auditores, de tal forma que seja possível inspecionar regularmente o ambiente. A inspeção e a auditoria devem ser uma prática rotineira, da mesma forma que sejam também aplicados mecanismos que permitam sincronizar os relógios dos diversos equipamentos. Sem a sincronização dos relógios, com uma base de tempo unificada, torna-se muito difícil correlacionar os eventos dos diversos registros de auditoria. Deve-se considerar também manter os sistemas atualizados, por intermédio de correções regulares (patches) dos softwares instalados. Outro aspecto pouco abordado, mas de grande importância é a manutenção de uma educação continuada dos usuários. Os usuários devem ser envolvidos como parte da solução do problema. É preciso entender que um ambiente de segurança é tão forte quanto o elo mais fraco da cadeia de sistemas e usuários que o formam. Isso significa que não adiantará manter um sistema controlado, se os usuários possuem comportamentos de risco, como por exemplo, usando senhas fracas ou instalando de softwares de origem duvidosa ou desconhecida. Os usuários devem ser envolvidos e estarem conscientes do seu poder modificador e dos riscos envolvidos em suas ações. Portanto, é de fundamental importância uma educação 19 continuada dos recursos humanos da organização. As emergências acontecem nos momentos menos esperados. A prevenção e a preparação devem fazer parte das rotinas de procedimentos dos analistas de segurança. Neste sentido, é importante a simulação e o treinamento dos procedimentos de emergência, de acordo com a política da organização. Os analistas de segurança devem se manter atualizados, ou seja, devem estar informados sobre como os intrusos agem. Além disso, devem estar preparados para, pelo menos, conhecer como capturar dados de perícia, ainda que não saibam como analisa-los e interpreta-los. Este conhecimento é importante de forma a preservar as evidências dentro de um ambiente comprometido, em função da volatilidade das informações, conforme anteriormente discutido. Devem também estar preparados para contatar alguém no caso de uma emergência, de tal forma que os dados e evidências possam ser interpretados por pessoal especializado. Finalmente, os peritos e analistas de segurança devem estar muito atentos a aspectos éticos e legais, dentro de suas jurisdições. Devem entender as implicações de suas ações quando inspecionam um sistema. É importante o respeito à privacidade das pessoas. Deve-se ter em menteque este tipo de operação traz responsabilidades muito importantes. A invasão de privacidade, a espionagem e a possibilidade de se cometer abusos, ainda que inadvertidos, são possibilidades concretas. Além disso, o comportamento correto ou incorreto do perito, ou do analista de segurança, terá efeitos profundos na validade legal das evidências. Portanto, assim como em outros tipos de operações, nestas ações a ética e a clareza são fatores preponderantes. AGRADECIMENTOS O Laboratório ACME! de pesquisa em segurança de redes agradece o suporte financeiro da FAPESP – Fundação de Amparo à Pesquisa do Estado de São Paulo. O autor agradece a Sérgio A. Leugi Filho, Thiago L. Charnet Ellero, Jarbas de Freitas Peixoto e Rodrigo Pace de Barros, pelas relevantes colaborações e discussões pertinentes a este trabalho. REFERÊNCIAS [1] Computer Security Institute. “2001 Computer Crime and Security Survey”, San Franciso, CA, USA.12/03/2001 – http://www.gocsi.com [2] Computer Security Institute. “Current and Future Danger: A CSI Primer on Computer Crime and Information Warfare”. San Franciso, CA, USA. 2001. [3] Simson Garfinkel & Gene Spafford. Pratical Unix and Internet Security - 2nd Edition.O'Reilly and Associates, Sebastopol, California, 1996. [4] D. Russell & G. T. Gangemi Sr. Computer Security Basics. O'Reilly and Associates, Sebastopol, California, December, 1991. 20 [5] SANS - System Administration, Networking, and Security Institute. “How To Eliminate The Ten Most Critical Internet Security Threats - The Experts’ Consensus”. Version 1.32 January 18, 2001 . http://www.sans.org/topten.htm (verif. 14/04/2001). [6] Alan Paller and Stephen Northcutt (editors). “ Expert Predictions for Security Trends in 2001”. SANS Institute . December/2000. http://www.sans.org/SANSSecAlert2_102000.pdf (verif. 14/04/2001). [7] Yin Zhang. “Detecting Backdoors”. 9th USENIX Security Symposium Denver, Colorado, USA August 14-17, 2000. [8] Hal Burch, and Bill Cheswick. “Tracing Anonymous Packets to Their Approximate Source”. 14th USENIX Systems Administration Conference . New Orleans, Louisiana, USA. December 3-8, 2000 [9] Paul A. Taylor. Hackers – Crime in the Digital Sublime. Routledge Edit., London, 1999. [10] Calvin Ko, Timothy Fraser, Lee Badger, and Douglas Kilpatrick. “Detecting and Countering System Intrusions Using Software Wrappers”. 9th USENIX Security Symposium Denver, Colorado, USA August 14-17, 2000 [11] Dan Farmer and Wietse Venema. “Being Prepared for Intrusion” . Dr. Dobb's Journal , April 2001. http://www.ddj.com/articles/2001/0104/0104f/0104f.htm (verif. 14/04/2001). [12] NMAP . http://www.insecure.org/nmap/ [13] Soumyo D. Moitra and Suresh L. Konda. “A Simulation Model for Managing Survivability of Networked Information Systems”. Carnegie Mellon University , Software Engineering Institute. CMU/SEI-2000-TR-020 Technical Report. December 2000. http://www.cert.org/research/00tr020.pdf (verif. 14/04/2001). [14] Dan Farmer. “What Are MACtimes?”. Dr. Dobb's Journal , October 2000. http://www.ddj.com/articles/2000/0010/0010f/0010f.htm (verif. 14/04/2001).
Compartilhar