Title: Forense Computacional
Post by: Ðark$pawn on 08 de March , 2006, 09:53:44 PM
Post by: Ðark$pawn on 08 de March , 2006, 09:53:44 PM
O que é forense computacional?
Forense computacional é a coleta de dados e evidências digitais a fim de comprovar o comprometimento de um sistema e ou ambiente. Para podermos comprovar o comprometimento de um ambiente e ou sistema precisamos coletar algumas informações e tomar algumas medidas tais como: Visualização do ambiente no estado anterior ao incidente de segurança, verificação física do objeto da analise como o estado de comunicação, serviços e utilização de memória e disco, vale ressaltar que todas as ações devem ser tomadas de forma a não alterar o estado do sistema e todas as evidências devem ser preservadas.
Analise Forense - Uma visão simplificada
O avanço da tecnologia permitiu diversas facilidades para nossas vidas, como fazer compras pela internet, acessar sua conta bancária e etc, com isso surgiu uma outra modalidade de crime os chamados Cyber Crimes, ou crimes cometidos por computador, nesses crimes não há cadáveres, não temos impressões digitais e nem um outros dados de analise forense comuns, temos apenas um computador as evidencias e rastros estão todas neles.
Analisando os dados
Para fazermos nossos analises precisamos coletar diversos dados tais como: Logs do sistema, todas as urls encontradas, todos os endereços pesquisados, recuperar arquivos apagados e etc, sempre tendo o cuidado de espelhar o HD em que se está examinando afim de preservar a integridade das provas, que não podem ser alteradas em nenhuma hipótese.
Procurando por provas
Vamos usar como base um ataque a um Web server, para ficar mais simples, supomos que um servidor Windows 2000 teve seu Web Server IIS(Internet Information Services), invadido. O local padrão para os logs do IIS é C:\WINNT\System32\Logfiles\W3SVC1 o formato padrão é o W3C Extended Log File Format, vejamos mais detalhes abaixo:
#Software: Microsoft Internet Information Services 5.0
#Version: 1.0
#Date: 2006-01-20 15:30:00
#Fields: time c-ip cs-method cs-uri-stem sc-status cs-version
15:30:00 200.150.175.18 GET /index.asp 200 HTTP/1.0
O log acima mostra a versão do softwares Microsoft IIS 5.0, analisando o log vemos que foi um acesso em 20 de janeiro de 2006 as 15:00 do IP 200.150.175.18 um pedido GET para a index.asp que foi atendido com êxito (estatus 200 OK), e também sabemos a versão do HTTP do cliente 1.0.
O Estatus HTTP funciona da seguinte forma, qualquer estatus entre 200 e 299 informam que a solicitação foi atendida com êxito, estatus entre 300 e 399 informam que o cliente precisa tomar alguma ação para que a solicitação seja atendida. estatus entre 400 e 599 mostram algum tipo de erro que pode ser do cliente ou do servidor. Se quiser saber exatamente o que significa cada código de solicitação de uma pesquisada na internet, não é difícil encontrar.
A invasão
Dia 22 de janeiro de 2006 entre 20:00 e 21:30, um site foi invadido e teve sua página principal desconfigurada, era um servidor Web IIS 5.0 rodando sob Windows 2000 Server o administrador do servidor está preocupado pois haviam informações valiosas naquele servidor, ele contrata você para fazer uma investigação e descobrir como o invasor conseguiu entrar e que informações ele pegou do servidor.
A investigação
Você cuidadosamente espelha o HD da máquina atacada de modo a proteger a integridade dos dados, e começa a verificar os logs do servidor de 2 a 3 dias antes do ocorrido, o motivo? Procurar atividades suspeitas como um scanner de vulnerabilidades, espelhamento de site e etc, geralmente um criminoso, estuda antes o sistema a ser invadido, criminosos mais experientes podem levar ate meses para concretizar uma invasão, fazendo diversos analises e estudos do sistema alvo, evitando assim ao máximo sua detecção.
Você começa analisando os logs e descobre que dia 20 de Janeiro de 2006 por volta das 01:00 a muitos pedidos de uma mesma origem (IP 200.150.15.170) em um curtíssimo intervalo de tempo, como mostrado abaixo:
2006-01-20 01:01:05 200.150.15.170 GET / 401
2006-01-20 01:01:05 200.150.15.170 GET /index.asp 200
2006-01-20 01:01:05 200.150.15.170 GET /produtos.asp 200
2006-01-20 01:01:06 200.150.15.170 GET /images/fundo.jpg 200
2006-01-20 01:01:07 200.150.15.170 GET /images/logo.jpg 200
2006-01-20 01:01:08 200.150.15.170 GET /images/principal.jpg 200
2006-01-20 01:01:08 200.150.15.170 GET /images/banner.gif 200
...
Provavelmente o criminoso espelhou o site para poder analisá-lo com mais calma off-line. Indo mais um pouco a frente descobrimos que no dia 21 de Janeiro de 2006 um dia antes do ataque o criminoso varre o sistema em busca de alguma vulnerabilidade conhecida, observe o log abaixo.
2006-01-21 08:23:13 200.150.15.170 GET /scripts/admin.asp 404
2006-01-21 08:23:13 200.150.15.170 GET /winnt/win.ini 404
2006-01-21 08:23:13 200.150.15.170 GET /boot.ini 404
2006-01-21 08:23:14 200.150.15.170 GET /.../.../.../.../winnt/system32/cmd.exe 404
2006-01-21 08:23:14 200.150.15.170 GET /.../.../.../.../.../.../.../winnt/system32/repair/sam._ 404
2006-01-21 08:23:14 200.150.15.170 GET /blabla.idc 500
2006-01-21 08:23:14 200.150.15.170 GET /scripts/root.exe 404
2006-01-21 08:23:15 200.150.15.170 GET /msadc/../../../../../../winnt/system32/cmd.exe?/c+dir 200
2006-01-21 08:23:16 200.150.15.170 GET /inetpub/wwwroot/cmd.exe /c+dir 404
2006-01-21 08:23:16 200.150.15.170 GET /global.asa+.pl 404
...
É comum vermos nesse tipo de ataque diversas requisições com estatus de 404 – pagina não encontrada (Not found), 403 – Proibido (Forbidden), isso acontece porque o criminoso está escaneando o servido em busca de vulnerabilidades conhecidas, então vemos que uma de suas requições teve como resposta 200 OK, olhando o log vimos que é um antigo e conhecido bug de unicode, então descobrimos por onde o criminoso entrou agora precisamos ir mais a fundo e ver o que ele fez exatamente no servidor, então começamos a analisar o log, mais a frente vemos o que ele fez exatamente no servidor no dia 22 de janeiro de 2006.
2006-01-22 21:10:48 200.150.15.170 GET /msadc/../../../../../../winnt/system32/cmd.exe?/c+echo+Pagina+Invadida!!!+>+c:\inetpub\wwwroot\index.asp 200
2006-01-22 21:11:03 200.150.15.170 GET /inetpub\wwwroot\index.asp 200
*No log acima vemos que o criminoso modificou a pagina index.asp e logo depois acessou a página para ver sua "obra". A alteração na página ocorreu às 21:10:48 do dia 01 de janeiro de 2006, utilizando um bug do únicode.
Por sorte aparentemente nenhuma informação confidencial foi roubada o criminoso apenas modificou a pagina principal do site, mais se pensarmos bem entre a descoberta da vulnerabilidade e a sua exploração existe um grande intervalo de tempo em que o IP do invasor não aparece se pensarmos um pouco, não faz muito sentido essa demora tendo em vista que o administrador poderia corrigir esse problema nesse meio tempo, então vamos começar a pensar como um "Sherlock Holmes" da informática, ataques do tipo defacers são comuns, talvez o criminoso não quisesse que a vítima tomasse conhecimento de que informações valiosas foram roubadas, simplesmente apagando essas entradas dos logs do sistema e deixando apenas a invasão ao webserver, assim quem fosse analisar o log iria achar que apenas a página inicial foi alterada e que nenhuma informação sigilosa foi roubada.
Então porque o criminoso não apagou o log inteiro ou então não apagou todas as suas entradas no log?
A reposta para isso pode ser simples, apagar o log inteiro levantaria muita suspeita e o log poderia ser facilmente restaurado por completo usando alguns programas específicos, e apagar todas as suas entradas no log poderia ser extremante demorado e complexo.
Considerações finais
Criminosos com bastantes conhecimentos tentarão encobrir seus rastros de todas as maneiras possíveis, criminosos deste tipo raramente irão desconfigurar páginas (a menos que realmente queiram deixar algum recado) ou tomar qualquer ação que possa anunciar o comprometimento do sistema inclusive ocultando seus processos abertos no sistema, mudando para nomes de arquivos legítimos, tentarão apagar apenas suas entradas nos logs ao invés de apagar o arquivo de log inteiro (o que irá levantar grandes suspeitas), suspeite de intervalos vazios no log(como por exemplo um acesso as 15:00 e o outro só as 14:30), isso pode mostrar que alguém apagou entradas a fim de encobrir sua presença no sistema.
Como vimos no exemplo aqui mostrado o criminoso, aparentemente não roubou nenhuma informação valiosa da empresa, mais como foi visto com um pensamento simples, milhares de outras possibilidades poderiam existir, um bom analista forense deve abrir um leque de possibilidades e ir chegando mais perto da verdade de acordo com as pistas encontradas, como escrito no livro Um estudo em vermelho, Sherlock Holmes ao encontrar uma pista fala com seu amigo Watson "é um erro capital teorizar antes de ter todas as evidências, pois isso influencia no julgamento". Este pensamento é o que na minha opinião todos os analistas forenses que estiverem no meio de uma investigação deviam ter, para não ver a coisa apenas superficialmente.
Elementar meu caro, Watson, "As coisas aparentemente mais insignificantes são as de maior importância", bom é isso, espero que este pequeno artigo tenha sido útil, ele foi bem simples, espero complementa-lô em breve. Comentários no fórum
"Quando elimina-se o impossível, o que resta, por mais improvável que pareça, tem de ser a verdade"
Sherlock Holmes (Personagem criado por Sir Arthur Conan Doyle)
Fonte: www.invasao.com.br (http://www.invasao.com.br) / Por: Rodrigo de Souza Delphino
____________________________________________________________________________________________
Ótima apostila sobre o "Ensino Forense"!!!
Ensino Forense / PDF (//http://www.megaupload.com/?d=GLAL4L4T)
Forense computacional é a coleta de dados e evidências digitais a fim de comprovar o comprometimento de um sistema e ou ambiente. Para podermos comprovar o comprometimento de um ambiente e ou sistema precisamos coletar algumas informações e tomar algumas medidas tais como: Visualização do ambiente no estado anterior ao incidente de segurança, verificação física do objeto da analise como o estado de comunicação, serviços e utilização de memória e disco, vale ressaltar que todas as ações devem ser tomadas de forma a não alterar o estado do sistema e todas as evidências devem ser preservadas.
Analise Forense - Uma visão simplificada
O avanço da tecnologia permitiu diversas facilidades para nossas vidas, como fazer compras pela internet, acessar sua conta bancária e etc, com isso surgiu uma outra modalidade de crime os chamados Cyber Crimes, ou crimes cometidos por computador, nesses crimes não há cadáveres, não temos impressões digitais e nem um outros dados de analise forense comuns, temos apenas um computador as evidencias e rastros estão todas neles.
Analisando os dados
Para fazermos nossos analises precisamos coletar diversos dados tais como: Logs do sistema, todas as urls encontradas, todos os endereços pesquisados, recuperar arquivos apagados e etc, sempre tendo o cuidado de espelhar o HD em que se está examinando afim de preservar a integridade das provas, que não podem ser alteradas em nenhuma hipótese.
Procurando por provas
Vamos usar como base um ataque a um Web server, para ficar mais simples, supomos que um servidor Windows 2000 teve seu Web Server IIS(Internet Information Services), invadido. O local padrão para os logs do IIS é C:\WINNT\System32\Logfiles\W3SVC1 o formato padrão é o W3C Extended Log File Format, vejamos mais detalhes abaixo:
#Software: Microsoft Internet Information Services 5.0
#Version: 1.0
#Date: 2006-01-20 15:30:00
#Fields: time c-ip cs-method cs-uri-stem sc-status cs-version
15:30:00 200.150.175.18 GET /index.asp 200 HTTP/1.0
O log acima mostra a versão do softwares Microsoft IIS 5.0, analisando o log vemos que foi um acesso em 20 de janeiro de 2006 as 15:00 do IP 200.150.175.18 um pedido GET para a index.asp que foi atendido com êxito (estatus 200 OK), e também sabemos a versão do HTTP do cliente 1.0.
O Estatus HTTP funciona da seguinte forma, qualquer estatus entre 200 e 299 informam que a solicitação foi atendida com êxito, estatus entre 300 e 399 informam que o cliente precisa tomar alguma ação para que a solicitação seja atendida. estatus entre 400 e 599 mostram algum tipo de erro que pode ser do cliente ou do servidor. Se quiser saber exatamente o que significa cada código de solicitação de uma pesquisada na internet, não é difícil encontrar.
A invasão
Dia 22 de janeiro de 2006 entre 20:00 e 21:30, um site foi invadido e teve sua página principal desconfigurada, era um servidor Web IIS 5.0 rodando sob Windows 2000 Server o administrador do servidor está preocupado pois haviam informações valiosas naquele servidor, ele contrata você para fazer uma investigação e descobrir como o invasor conseguiu entrar e que informações ele pegou do servidor.
A investigação
Você cuidadosamente espelha o HD da máquina atacada de modo a proteger a integridade dos dados, e começa a verificar os logs do servidor de 2 a 3 dias antes do ocorrido, o motivo? Procurar atividades suspeitas como um scanner de vulnerabilidades, espelhamento de site e etc, geralmente um criminoso, estuda antes o sistema a ser invadido, criminosos mais experientes podem levar ate meses para concretizar uma invasão, fazendo diversos analises e estudos do sistema alvo, evitando assim ao máximo sua detecção.
Você começa analisando os logs e descobre que dia 20 de Janeiro de 2006 por volta das 01:00 a muitos pedidos de uma mesma origem (IP 200.150.15.170) em um curtíssimo intervalo de tempo, como mostrado abaixo:
2006-01-20 01:01:05 200.150.15.170 GET / 401
2006-01-20 01:01:05 200.150.15.170 GET /index.asp 200
2006-01-20 01:01:05 200.150.15.170 GET /produtos.asp 200
2006-01-20 01:01:06 200.150.15.170 GET /images/fundo.jpg 200
2006-01-20 01:01:07 200.150.15.170 GET /images/logo.jpg 200
2006-01-20 01:01:08 200.150.15.170 GET /images/principal.jpg 200
2006-01-20 01:01:08 200.150.15.170 GET /images/banner.gif 200
...
Provavelmente o criminoso espelhou o site para poder analisá-lo com mais calma off-line. Indo mais um pouco a frente descobrimos que no dia 21 de Janeiro de 2006 um dia antes do ataque o criminoso varre o sistema em busca de alguma vulnerabilidade conhecida, observe o log abaixo.
2006-01-21 08:23:13 200.150.15.170 GET /scripts/admin.asp 404
2006-01-21 08:23:13 200.150.15.170 GET /winnt/win.ini 404
2006-01-21 08:23:13 200.150.15.170 GET /boot.ini 404
2006-01-21 08:23:14 200.150.15.170 GET /.../.../.../.../winnt/system32/cmd.exe 404
2006-01-21 08:23:14 200.150.15.170 GET /.../.../.../.../.../.../.../winnt/system32/repair/sam._ 404
2006-01-21 08:23:14 200.150.15.170 GET /blabla.idc 500
2006-01-21 08:23:14 200.150.15.170 GET /scripts/root.exe 404
2006-01-21 08:23:15 200.150.15.170 GET /msadc/../../../../../../winnt/system32/cmd.exe?/c+dir 200
2006-01-21 08:23:16 200.150.15.170 GET /inetpub/wwwroot/cmd.exe /c+dir 404
2006-01-21 08:23:16 200.150.15.170 GET /global.asa+.pl 404
...
É comum vermos nesse tipo de ataque diversas requisições com estatus de 404 – pagina não encontrada (Not found), 403 – Proibido (Forbidden), isso acontece porque o criminoso está escaneando o servido em busca de vulnerabilidades conhecidas, então vemos que uma de suas requições teve como resposta 200 OK, olhando o log vimos que é um antigo e conhecido bug de unicode, então descobrimos por onde o criminoso entrou agora precisamos ir mais a fundo e ver o que ele fez exatamente no servidor, então começamos a analisar o log, mais a frente vemos o que ele fez exatamente no servidor no dia 22 de janeiro de 2006.
2006-01-22 21:10:48 200.150.15.170 GET /msadc/../../../../../../winnt/system32/cmd.exe?/c+echo+Pagina+Invadida!!!+>+c:\inetpub\wwwroot\index.asp 200
2006-01-22 21:11:03 200.150.15.170 GET /inetpub\wwwroot\index.asp 200
*No log acima vemos que o criminoso modificou a pagina index.asp e logo depois acessou a página para ver sua "obra". A alteração na página ocorreu às 21:10:48 do dia 01 de janeiro de 2006, utilizando um bug do únicode.
Por sorte aparentemente nenhuma informação confidencial foi roubada o criminoso apenas modificou a pagina principal do site, mais se pensarmos bem entre a descoberta da vulnerabilidade e a sua exploração existe um grande intervalo de tempo em que o IP do invasor não aparece se pensarmos um pouco, não faz muito sentido essa demora tendo em vista que o administrador poderia corrigir esse problema nesse meio tempo, então vamos começar a pensar como um "Sherlock Holmes" da informática, ataques do tipo defacers são comuns, talvez o criminoso não quisesse que a vítima tomasse conhecimento de que informações valiosas foram roubadas, simplesmente apagando essas entradas dos logs do sistema e deixando apenas a invasão ao webserver, assim quem fosse analisar o log iria achar que apenas a página inicial foi alterada e que nenhuma informação sigilosa foi roubada.
Então porque o criminoso não apagou o log inteiro ou então não apagou todas as suas entradas no log?
A reposta para isso pode ser simples, apagar o log inteiro levantaria muita suspeita e o log poderia ser facilmente restaurado por completo usando alguns programas específicos, e apagar todas as suas entradas no log poderia ser extremante demorado e complexo.
Considerações finais
Criminosos com bastantes conhecimentos tentarão encobrir seus rastros de todas as maneiras possíveis, criminosos deste tipo raramente irão desconfigurar páginas (a menos que realmente queiram deixar algum recado) ou tomar qualquer ação que possa anunciar o comprometimento do sistema inclusive ocultando seus processos abertos no sistema, mudando para nomes de arquivos legítimos, tentarão apagar apenas suas entradas nos logs ao invés de apagar o arquivo de log inteiro (o que irá levantar grandes suspeitas), suspeite de intervalos vazios no log(como por exemplo um acesso as 15:00 e o outro só as 14:30), isso pode mostrar que alguém apagou entradas a fim de encobrir sua presença no sistema.
Como vimos no exemplo aqui mostrado o criminoso, aparentemente não roubou nenhuma informação valiosa da empresa, mais como foi visto com um pensamento simples, milhares de outras possibilidades poderiam existir, um bom analista forense deve abrir um leque de possibilidades e ir chegando mais perto da verdade de acordo com as pistas encontradas, como escrito no livro Um estudo em vermelho, Sherlock Holmes ao encontrar uma pista fala com seu amigo Watson "é um erro capital teorizar antes de ter todas as evidências, pois isso influencia no julgamento". Este pensamento é o que na minha opinião todos os analistas forenses que estiverem no meio de uma investigação deviam ter, para não ver a coisa apenas superficialmente.
Elementar meu caro, Watson, "As coisas aparentemente mais insignificantes são as de maior importância", bom é isso, espero que este pequeno artigo tenha sido útil, ele foi bem simples, espero complementa-lô em breve. Comentários no fórum
"Quando elimina-se o impossível, o que resta, por mais improvável que pareça, tem de ser a verdade"
Sherlock Holmes (Personagem criado por Sir Arthur Conan Doyle)
Fonte: www.invasao.com.br (http://www.invasao.com.br) / Por: Rodrigo de Souza Delphino
____________________________________________________________________________________________
Ótima apostila sobre o "Ensino Forense"!!!
Ensino Forense / PDF (//http://www.megaupload.com/?d=GLAL4L4T)