Em outubro eu postei sobre o pdgmail, uma ferramenta desenvolvida em python e disponibilizada por Jeff Bryner, que auxilia em muito a análise de dumps de memória de browsers por informações relacionadas ao uso do Gmail.
Pois bem, o mesmo autor publicou hoje o pdymail, uma ferramenta análoga para a nova interface do Yahoo! Mail, que como o Gmail utiliza JSON/AJAX/XML para manter várias informações em memória e deixa poucos vestígios de seu uso em disco.
O mais importante é definir antecipadamente a forma que você coletará o dump de memória (full ou do processo do browser em execução) - depois disto feito - o uso do pdymail é bastante simples (em linux ou cygwin):
$ strings -el pid1234.dump| ./pdymail -f -
Trocando em miúdos, este tipo de ferramenta é muito útil na fase de análise de investigações que envolvam interfaces modernas de WebMail como o Gmail e o Yahoo! Mail, pois não será muito útil utilizar o processo tradicional de vasculhar o disco por artefatos de Webmail (incluindo espaço não alocado/arquivos deletados).
Uma informação adicional, o dump terá informações úteis desde que o browser tenha sido utilizado anteriormente (naquela execução) para acesso a interface do Yahoo! Mail / Gmail. Ou seja, não é necessário que o usuário esteja logado do Webmail no momento do dump.
Monday, January 12, 2009
Monday, January 5, 2009
Forjando certificados SSL que utilizam o MD5
O tema da virada do ano foi o ataque demonstrado por Alexander Sotirov et al que mostra a necessidade de se deixar de utilizar o algorítimo de hashes criptográficos MD5 em mais uma aplicação: PKI, ou Public Key Infrastructure (slides PDF) / (site SSL prova de conceito)
A implicação mais óbvia é a utilização desta vulnerabilidade em ataques de phishing/pharming mais sofisticados (combinados com ataques de DNS possibilitariam a um atacante a falsificação quase perfeita (e talvez o tunelamento do acesso do cliente através de um site forjado) de instituições de comércio eletrônico e personal banking (https://)
Há quem argumente que não é de grande impacto a notícia, porque o usuário comum simplesmente clicaria em "Add Exception" no Browser quando um ataque similar é feito com um certificado SSL não forjado, mas as implicações são ainda mais sérias neste caso, tanto é que a Verisign estará substituindo gratuitamente para seus clientes os certificados que ainda utilizam o MD5...
Segundo os pesquisadores, além da aplicação da colisão de hashes MD5, o ataque foi possível porque a Verisign e outras (RapidSSL, FreeSSL, TrustCenter, RSA Data Security, Thawte, verisign.co.jp):
- ainda utilizavam (até dias atrás) certificados com assinaturas criadas utilizando MD5 (caso você seja responsável por certificados SSL em uma PKI interna, verifique também... )
- automatizam as solicitações de certificados
- não verificam solicitações anômalas
- permitem a previsão da combinação entre número de série e validade do certificado
- não limitam o tamanho da cadeia de certificados
Vale lembrar que o MD5 tem um crescente histórico de identificações de vulnerabilidades que possibilitaram esta prova de conceito.
Segundo a Netcraft, 14% dos sites que usam SSL utilizam o MD5 como algoritimo de hash.
Estas duas extensões para Firefox podem auxiliá-lo a detectar se o site HTTPS que você está acessando usa certificados que utilizam MD5:
Além disto, recentemente foi disponibilizado um módulo para o metasploit framework que pode varrer o endereçamente interno da sua empresa e identificar se existem certificados que precisam ser trocados:
Uma lista de referências sobre o assunto segue abaixo:
- http://www.win.tue.nl/hashclash/rogue-ca/
- http://www.phreedom.org/research/rogue-ca/
- http://www.rsa.com/blog/blog_entry.aspx?id=1411
- http://blog.mozilla.com/security/2008/12/30/md5-weaknesses-could-lead-to-certificate-forgery/
- http://www.microsoft.com/technet/security/advisory/961509.mspx
- http://doggdot.us/security/Free_SSL_Certificates_?FC=PRCK0
- http://feeds.feedburner.com/~r/SecuritySoapbox/~3/501614128/broken-md5-cracked-ssl-and-end-of-all.html
Um outro detalhe interessante é que para parte da computação necessária para o sucesso do ataque, foram utilizados os cores SPU do processador "Cell" de um cluster de mais de 200 videogames Playstation 3.
Monday, December 22, 2008
Encase + Memscript + Memoryze - facilitando a analise forense de memória
Como sabemos, a importância de se coletar e analisar a memória física de máquinas envolvidas em crimes ou sob investigação de incidentes de segurança é cada vez maior. Os seguintes posts já foram publicados neste blog sobre o assunto:
- Forense de Memória - Uma comparação de Ferramentas Disponíveis
- FACE: Automated digital evidence discovery and correlation
- pdgmail: nova ferramenta para Forense de Memória do GMAIL
- ColdBoot Attack em Forense Computacional
- UPDATE - Forense: aquisição e análise de dumps de memória RAM
São pré-requisitos para ele: Memoryze, Audit Viewer (escrito em Python). Estas ferramentas tem licença BSD - o que facilita seu uso corporativo.
Depois de instalado na máquina do investigador, o processo é muito simplificado, pois basta escolher as máquinas a terem a memória coletada, efetuar o dump de memória pelo próprio Encase e depois utilzar o Memscript para efetuar a análise de memória, que contém os seguintes itens/subtitens:
ProcessAuditMemory (Files, Directories, Processes, Keys, Mutants, Events, Dlls, Strings, Memory Sections, Ports)
DriverAuditSignature (Root/All) (ImageBase, DriverName, DriverInit, DriverStartIO, DriverUnload, IRP_MJ_CLOSE, IRP_MJ_READ, + 20 campos IRP_MJ_*)
DriverAuditModuleList (ModulePath, ModuleName, ModuleInt, ModuleBase, ModuleSize, ModuleAddress)
RootkitAudit (HookedFunction, HookedModule, HookingModule, HookingAddress)
Existe um User Guide (PDF) muito bem escrito, descrevendo as funcionalidades do Audit Viewer.
No link incluído para o site da Mandiant, existe um passo a passo detalhado com capturas de telas, para auxiliar o investigador a configurar as ferramentas descritas.
Tuesday, December 16, 2008
ATENÇÃO: Patch para Vulnerabilidade Crítica do Internet Explorer sai amanhã
Atualização: 2008/12/16 22:43
O pessoal do Time de Segurança da Microsoft no Brasil postou sobre o Patch que será liberado amanhã, informando que o boletim de segurança sairá às 15h, horário de Brasília - segue parte do post:
"A Microsoft liberará um boletim de segurança (fora da programação normal das segundas terça-feiras do mês) que resolve uma vulnerabilidade do navegador Internet Explorer em todas as versões correntes e suportadas de Windows. Esse boletim sairá aproximadamente às 15:00 horas, horário de Brasília em 17 de Dezembro de 2008.
Essa atualização estará disponível fora do ciclo mensal de boletins de segurança em um esforça da Microsoft de proteger seus clientes. A Microsoft recomenda que seus clientes preparem seus sistemas e redes para aplicar esse boletim imediatamente após liberada para que seus computadores fiquem melhor preparados contra ações de ataques criminosos. Para mais informações sobre essas atualizações, por favor visite a página web em Inglês http://www.microsoft.com/protect."
Post Original: 2008/12/16 19:08
A Microsoft está prometendo o patch para a vulnerabilidade "0-day" do IE (todas versões) para amanhã.
anúncio:
http://www.microsoft.com/technet/security/bulletin/ms08-dec.mspx
outros links da microsoft relacionados:
http://www.microsoft.com/technet/security/advisory/961051.mspx
http://blogs.technet.com/swi/archive/2008/12/12/Clarification-on-the-various-workarounds-from-the-recent-IE-advisory.aspx
inscrição para webcast da MS amanhã (17/12/2008) sobre a vuln:
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032399448&Culture=en-US
inscrição para webcast da MS do dia 18/12/2008:
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032399449&Culture=en-US
repercussão do anúncio do Patch para amanhã:
http://blogs.zdnet.com/security/?p=2317
http://isc.sans.org/diary.html?storyid=5497&rss
http://security.blogs.techtarget.com/2008/12/16/microsoft-to-release-emergency-patch-for-ie-xml-flaw/
Tudo começou em um fórum hacker chinês (2) e foi trazido ao ocidente através de um Post da PC-WORLD em 09/12/2008 - Uma das melhores análises técnicas das explorações iniciais foi feita pelo HD Moore. Hoje já estão disponíveis vários exploits.
Enquanto isto o número de sites explorando a vulnerabilidade já subiu para 10.000 e o número de usuários afetados é de mais de 1 em cada 400 internautas. É interessante notar que a maioria são sites legítimos que são invadidos e passam a disseminar trojans através da exploração da falha não corrigida.
No meio tempo, entre as ações com real efeito, vale a pena - quando possível - utilizar um navegador mais seguro (Firefox, Chrome) e bloquear (via filtro de conteúdo, proxy, acls) os domínios maliciosos já identificados. Algumas regras de IDS podem ajudar, mas não resolvem.
Como - ainda por cima - os "workarounds" de mitigação oferecidos pela Microsoft não estão sendo levados muito a sério (são realmente confusos), o negócio é esperar o Patch sair amanhã e TESTAR/APLICAR em regime de urgência em todas as máquinas Windows - para minimizar o impacto nas máquinas sob sua resposabilidade.
Para mais informações, veja:
http://www.kb.cert.org/vuls/id/493881
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4844
http://xforce.iss.net/xforce/xfdb/47208
http://milw0rm.com/exploits/7477
http://www.securityfocus.com/bid/32721
http://feeds.feedburner.com/~r/SpywareSucks/~3/482165575/1656545.aspx
http://www.f-secure.com/weblog/archives/00001561.html
http://www.breakingpointsystems.com/community/blog/patch-tuesdays-and-drive-by-sundays
http://www.darknet.org.uk/2008/12/ie7-exploit-also-affects-ie5-ie6-and-ie8-more-users-in-trouble/
http://securitylabs.websense.com/content/Alerts/3259.aspx
O pessoal do Time de Segurança da Microsoft no Brasil postou sobre o Patch que será liberado amanhã, informando que o boletim de segurança sairá às 15h, horário de Brasília - segue parte do post:
"A Microsoft liberará um boletim de segurança (fora da programação normal das segundas terça-feiras do mês) que resolve uma vulnerabilidade do navegador Internet Explorer em todas as versões correntes e suportadas de Windows. Esse boletim sairá aproximadamente às 15:00 horas, horário de Brasília em 17 de Dezembro de 2008.
Essa atualização estará disponível fora do ciclo mensal de boletins de segurança em um esforça da Microsoft de proteger seus clientes. A Microsoft recomenda que seus clientes preparem seus sistemas e redes para aplicar esse boletim imediatamente após liberada para que seus computadores fiquem melhor preparados contra ações de ataques criminosos. Para mais informações sobre essas atualizações, por favor visite a página web em Inglês http://www.microsoft.com/protect."
Post Original: 2008/12/16 19:08
A Microsoft está prometendo o patch para a vulnerabilidade "0-day" do IE (todas versões) para amanhã.
anúncio:
http://www.microsoft.com/
outros links da microsoft relacionados:
http://www.microsoft.com/
http://blogs.technet.com/swi/
inscrição para webcast da MS amanhã (17/12/2008) sobre a vuln:
http://msevents.microsoft.com/
inscrição para webcast da MS do dia 18/12/2008:
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032399449&Culture=en-US
repercussão do anúncio do Patch para amanhã:
http://blogs.zdnet.com/
http://isc.sans.org/diary.
http://security.blogs.
Tudo começou em um fórum hacker chinês (2) e foi trazido ao ocidente através de um Post da PC-WORLD em 09/12/2008 - Uma das melhores análises técnicas das explorações iniciais foi feita pelo HD Moore. Hoje já estão disponíveis vários exploits.
Enquanto isto o número de sites explorando a vulnerabilidade já subiu para 10.000 e o número de usuários afetados é de mais de 1 em cada 400 internautas. É interessante notar que a maioria são sites legítimos que são invadidos e passam a disseminar trojans através da exploração da falha não corrigida.
No meio tempo, entre as ações com real efeito, vale a pena - quando possível - utilizar um navegador mais seguro (Firefox, Chrome) e bloquear (via filtro de conteúdo, proxy, acls) os domínios maliciosos já identificados. Algumas regras de IDS podem ajudar, mas não resolvem.
Como - ainda por cima - os "workarounds" de mitigação oferecidos pela Microsoft não estão sendo levados muito a sério (são realmente confusos), o negócio é esperar o Patch sair amanhã e TESTAR/APLICAR em regime de urgência em todas as máquinas Windows - para minimizar o impacto nas máquinas sob sua resposabilidade.
Para mais informações, veja:
http://www.kb.cert.org/vuls/
http://cve.mitre.org/cgi-bin/
http://xforce.iss.net/xforce/
http://milw0rm.com/exploits/
http://www.securityfocus.com/
http://feeds.feedburner.com/~
http://www.f-secure.com/
http://www.
http://www.darknet.org.uk/
http://securitylabs.websense.com/content/Alerts/3259.aspx
Thursday, December 4, 2008
DNSChanger - v4
O primeiro post deste blog - em 13 de junho deste ano - foi sobre um trojan chamado "DNSChanger" que tentava acessar com senhas padrão o gateway (modem/AP/router) da rede interna e automatizava a exploração da rede local da vítima, além de reconfigurar os endereços DNS atribuídos automaticamente e assim possibilitar o controle da navegação e phishing/pharming em uma nova dimensão.
Pois bem, passados 6 meses, estamos no 48.0 post deste blog e uma nova variante do DNSChanger está chamando a atenção da comunidade de segurança, por sua inovação.
De uma forma geral, estes trojans que buscam alterar as configurações de DNS das máquinas locais ou da rede do usuário, têm agido até o momento com um três dos seguintes modus operandi:
É instalado na máquina infectada um driver (ArcNet NDIS) que irá a partir deste momento atuar como um servidor DHCP falso, e vai concorrer com o servidor real na distribuição dos endereçamentos da rede local - e - como você já deve ter imaginado - quando ele atribui o endereço ele também fornece ao equipamento os IPs de servidores DNS falsos para que a navegação das máquinas seja controlada por ele.
Dois pontos interessantes levantados pela Mcafee/Sans:
1 - o número de equipamentos afetados com este tipo de abordagem é maior, já que não há limitação por sistema operacional.
2 - a detecção da causa-raiz da alteração do DNS das máquinas afetadas é muito difícil (você teria que analisar o tráfego de rede para identificar os endereços MAC dos pacotes "DHCP Offer" para identificar onde a máquina infectada está..)
Os DNS falsos utilizados na variante analisada são:
A Mcafee informa também que o driver legítimo "ArcNet NDIS Protocol Driver" que é utilizado pode ser encontrado no caminho a seguir: (%SYSROOT%\system32\drivers\ndisprot.sys)
Além dos links de referência já citados, a Symantec publicou uma análise do trojan contendo as modificações efetuadas no sistema afetado.
Pois bem, passados 6 meses, estamos no 48.0 post deste blog e uma nova variante do DNSChanger está chamando a atenção da comunidade de segurança, por sua inovação.
De uma forma geral, estes trojans que buscam alterar as configurações de DNS das máquinas locais ou da rede do usuário, têm agido até o momento com um três dos seguintes modus operandi:
- Modificar o arquivo Hosts do Windows Modify (%SYSROOT%\windows32\drivers\etc\hosts)
- Modificar a entrada de registro incluindo um DNS server malicioso (HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\NameServer)
- Explorar vulnerabilidades do tipo "cross-site request forgery" em routers (ou via força bruta como nosso post de junho aponta) para sobrescrever a configuração DNS das máquinas na rede local
É instalado na máquina infectada um driver (ArcNet NDIS) que irá a partir deste momento atuar como um servidor DHCP falso, e vai concorrer com o servidor real na distribuição dos endereçamentos da rede local - e - como você já deve ter imaginado - quando ele atribui o endereço ele também fornece ao equipamento os IPs de servidores DNS falsos para que a navegação das máquinas seja controlada por ele.
Dois pontos interessantes levantados pela Mcafee/Sans:
1 - o número de equipamentos afetados com este tipo de abordagem é maior, já que não há limitação por sistema operacional.
2 - a detecção da causa-raiz da alteração do DNS das máquinas afetadas é muito difícil (você teria que analisar o tráfego de rede para identificar os endereços MAC dos pacotes "DHCP Offer" para identificar onde a máquina infectada está..)
Os DNS falsos utilizados na variante analisada são:
- 85.255.112.36
- 85.255.112.41
A Mcafee informa também que o driver legítimo "ArcNet NDIS Protocol Driver" que é utilizado pode ser encontrado no caminho a seguir: (%SYSROOT%\system32\drivers\ndisprot.sys)
Além dos links de referência já citados, a Symantec publicou uma análise do trojan contendo as modificações efetuadas no sistema afetado.
Monday, December 1, 2008
FACE: Automated digital evidence discovery and correlation
Interessante pesquisa/protótipo de ferramenta para
correlacionar resultados de forense de disco/ forense
de memória/ forense de rede: (pdf).
O conceito é muito interessante, e é bem possível que
vejamos isto como commodity em alguns anos, talvez
através de um padrão/protocolo aberto de
relacionamento entre estas tecnologias e fabricantes...
Abstract:
"Digital forensic tools are being developed at a brisk pace in response
to the ever increasing variety of forensic targets. Most tools are
created for specific tasks – filesystem analysis,memory analysis,
network analysis, etc. – and make little effort to interoperate with
one another. This makes it difficult and extremely time-consuming
for an investigator to build a wider view of the state of the system
under investigation. In this work, we present FACE, a framework
for automatic evidence discovery and correlation from a variety of
forensic targets. Our prototype implementation demonstrates the
integrated analysis and correlation of a disk image, memory image,
network capture, and configuration log files. The results of this
analysis are presented as a coherent view of the state of a target
system, allowing investigators to quickly understand it. We also
present an advanced open-source memory analysis tool, ramparser,
for the automated analysis of Linux systems."
correlacionar resultados de forense de disco/ forense
de memória/ forense de rede: (pdf).
O conceito é muito interessante, e é bem possível que
vejamos isto como commodity em alguns anos, talvez
através de um padrão/protocolo aberto de
relacionamento entre estas tecnologias e fabricantes...
Abstract:
"Digital forensic tools are being developed at a brisk pace in response
to the ever increasing variety of forensic targets. Most tools are
created for specific tasks – filesystem analysis,memory analysis,
network analysis, etc. – and make little effort to interoperate with
one another. This makes it difficult and extremely time-consuming
for an investigator to build a wider view of the state of the system
under investigation. In this work, we present FACE, a framework
for automatic evidence discovery and correlation from a variety of
forensic targets. Our prototype implementation demonstrates the
integrated analysis and correlation of a disk image, memory image,
network capture, and configuration log files. The results of this
analysis are presented as a coherent view of the state of a target
system, allowing investigators to quickly understand it. We also
present an advanced open-source memory analysis tool, ramparser,
for the automated analysis of Linux systems."
Wednesday, November 26, 2008
MS08-067 - O Trojan está aí, e o uso em Bots e o Worm CHEGOU
UPDATE 26/11/2008:
Demorou um mês, mas o worm "Conficker" e os bots "IRCBot.BH" que exploram a vulnerabilidade descrita no MS08-067 já são uma realidade... (inclusive no Brasil)...
25/10/2008:
O Trojan Gimmiv.A já está explorando a vulnerabildade recentemente corrigida pela Microsoft no "Server Service" do Windows.
Interessante notar que o trojan Gimmiv. A permite execução remota de código (via RCP-DCOM - a la Blaster de cinco anos atrás ... de volta ao passado?) .
Algumas coisas que p que o Gimmiv.A pode fazer:
A falha de desenvolvimento que proporciona a vulnerabilidade está na mesma área de código do MS06-040 - segundo decompilação da função "sub_5B86A51B" da lib netapi32.dll do XP SP3 feita por Alexander Sotirov.
A SourceFire disponibilizou assinaturas para detectar ataques relacionados: baixe aqui.
Caso você ainda não tenha feito patch em seus Windows (Workstations E Servers): dê uma olhada neste post no Blog do time SWI da Microsoft. Em resumo, para XP,2000 e 2003, o risco é de execução remota de código.. para Vista e 2008 é (só) Denial of Service.. Lembra daquelas janelinhas de crash do DCOM com o Blaster...
Enquanto você não conseguir "patchear"todas suas máquinas, ao menos tente habilitar o Firewall e desabilitar - quando possível, o compartilhamento de arquivos/impressoras.. Dê uma olhada no link da SWI nas outras opções de remediação.
O pessoal da Threat Expert analisou o Gimmiv.A e ele baixa arquivos dos seguintes sites (vale a pena bloquear acesso à eles via FW/Controle de Conteúdo):
Demorou um mês, mas o worm "Conficker" e os bots "IRCBot.BH" que exploram a vulnerabilidade descrita no MS08-067 já são uma realidade... (inclusive no Brasil)...
25/10/2008:
O Trojan Gimmiv.A já está explorando a vulnerabildade recentemente corrigida pela Microsoft no "Server Service" do Windows.
Interessante notar que o trojan Gimmiv. A permite execução remota de código (via RCP-DCOM - a la Blaster de cinco anos atrás ... de volta ao passado?) .
Algumas coisas que p que o Gimmiv.A pode fazer:
- Identificar e desabilitar Anti-Vírus (Trend Micro, Symantec, BitDefender, Rising, Kaspersky, Kingsoft, Microsoft One Care, Jiangmin)
- Roubar usuario e senha do MSN Messenger
- Roubar usuario e senha do Outlook Express
- Roubar password salvos do Internet Explorer
- Roubar Cookies com tokens de autenticação
- Baixar qualquer arquivo que o atacante indique.
A falha de desenvolvimento que proporciona a vulnerabilidade está na mesma área de código do MS06-040 - segundo decompilação da função "sub_5B86A51B" da lib netapi32.dll do XP SP3 feita por Alexander Sotirov.
A SourceFire disponibilizou assinaturas para detectar ataques relacionados: baixe aqui.
Caso você ainda não tenha feito patch em seus Windows (Workstations E Servers): dê uma olhada neste post no Blog do time SWI da Microsoft. Em resumo, para XP,2000 e 2003, o risco é de execução remota de código.. para Vista e 2008 é (só) Denial of Service.. Lembra daquelas janelinhas de crash do DCOM com o Blaster...
Enquanto você não conseguir "patchear"todas suas máquinas, ao menos tente habilitar o Firewall e desabilitar - quando possível, o compartilhamento de arquivos/impressoras.. Dê uma olhada no link da SWI nas outras opções de remediação.
O pessoal da Threat Expert analisou o Gimmiv.A e ele baixa arquivos dos seguintes sites (vale a pena bloquear acesso à eles via FW/Controle de Conteúdo):
- http://summertime.1gokurimu.com
- http://perlbody.t35.com
- http://doradora.atzend.com
Friday, November 21, 2008
UPDATE - Forense: aquisição e análise de dumps de memória RAM
21-11-2008 - Atualização:Rob Lee (da Mandiant e Sans Institute) publicou um interessantíssimo post contendo um how-to sobre o que comentamos em setembro neste blog (Live Response versus Memory Analysis) , usando como exemplo o Memoryze e o Volatility. Vale a pena conferir estas referências sobre o assunto:
- http://www.hbgary.com/papers/The%20value%20of%20physical%20memory%20for%20incident%20response.pdf
- http://www.search.org/files/pdf/collectevidenceruncomputer.pdf
- http://sansforensics.wordpress.com/2008/11/19/memory-forensic-analysis-finding-hidden-processes/
05-09-2008 - Atualização:
Os pesquisadores Cal Waits, Joseph Ayo Akinyele, Richard Nolan e Larry Rogers - do Carnegie Mellon University’s Software Engineering Institute - publicaram ontem um interessante relatório - intitulado "Computer Forensics: Results of Live Response Inquiry vs. Memory Image Analysis. (SEI Technical Note CMU/SEI-2008-TN-017)".
O documento apresenta cenários onde evidências voláteis úteis à investigação são obtidas de duas formas diferentes:
1) coletadas de uma máquina ligada - utilizando ferramentas da Sysinternals (agora Microsoft).
2) colatadas através de dump da memória RAM da máquina - utilizando o Volatility e o PTFinder.
Para cada caso é mostrada a abordagem de resposta e de análise dos dados coletados, além de ser feita uma apresentação das vantagens e desvantagens dos métodos em questão e sua utilidade no curso de uma investigação envolvendo computadores ligados.
Ao final é sugerido pelos pesquisadores uma abordagem híbrida, utilizando tanto a análise de dados voláteis quanto dumps de memória durante a triagem do incidente em curso.
Para auxiliar grandes corporações a alcançar este objetivo em redes com milhares de pontos e grande complexidade, existem soluções comerciais como o Encase Enterprise, da Guidance Software.
23-06-2008:
Conforme apontado por 32bits : "winen.exe" e 64bits: "winen64.exe" - que funcionam nos sistemas operacionais Windows 2000, XP, 2003 & Vista).
Z:\>winen.exe -h
Usage: [Options]
-p : Evidence File Path
-m : Evidence Name (Max Size:50)
-c : Case Number (Max Size:64)
-e : Examiner Name (Max Size:64)
-r : Evidence Number (Max Size:64)
-d : Compression level (0=None, 1=Fast, 2=Best) (Default: 0)
-a : A semicolon delimated list of Alternate paths
-n : Notes (Max Size:32768)
-s : Maximum file size in mb (Default: 640) (min:1 max:10485760)
-g : Error granularity (Sectors) (Default: 1) (min:1 max:1024)
-b : Block size (Sectors) (Default: 64) (min:1 max:1024)
-f : Path to configuration file
-t: Turns off hashing the evidence file (default: true)
-h: This help message
Para efetuar o parsing das imagens de memória adquiridas, podem ser utilizados:
1 - Encase + Enscripts Encase publicados por - para XP SP2 e para Windows 2000
2 - FTK Imager Lite
3 - Volatility Open Source (CygWin/OSX/Linux) - escrito em python
Volatility Supported Commands:
connections Print list of open connections
connscan Scan for connection objects
datetime Get date/time information for image
dlllist Print list of loaded dlls for each process (VERY verbose)
files Print list of open files for each process (VERY verbose)
ident Identify image properties such as DTB and VM type (may take a while)
modules Print list of loaded modules
pslist Print list of running processes
psscan Scan for EPROCESS objects
sockets Print list of open sockets
sockscan Scan for socket objects
strings Match physical offsets to virtual addresses (VERY verbose)
thrdscan Scan for ETHREAD objects
vaddump Dump the Vad sections to files
vadinfo Dump the VAD info
vadwalk Walk the vad tree
1 - Exemplo de extração de processos executando de um Windows XP:
ss@ss:~/Volatility-1.1.2$ python volatility pslist -f memory-images/xp-laptop-2005-06-25.img
Name Pid PPid Thds Hnds Time
System 4 0 61 1140 Thu Jan 01 00:00:00 1970
smss.exe 448 4 3 21 Sat Jun 25 16:47:28 2005
services.exe 580 528 18 401 Sat Jun 25 16:47:31 2005
lsass.exe 592 528 21 374 Sat Jun 25 16:47:31 2005
(...)
wuauclt.exe 2424 840 4 160 Sat Jun 25 16:49:21 2005
firefox.exe 2160 1812 6 182 Sat Jun 25 16:49:22 2005
PluckSvr.exe 944 740 9 227 Sat Jun 25 16:51:00 2005
iexplore.exe 2392 1812 9 365 Sat Jun 25 16:51:02 2005
PluckTray.exe 2740 944 3 105 Sat Jun 25 16:51:10 2005
PluckTray.exe 3256 1812 0 -1 Sat Jun 25 16:54:28 2005
cmd.exe 2624 1812 1 29 Sat Jun 25 16:57:36 2005
wmiprvse.exe 4080 740 7 0 Sat Jun 25 16:57:53 2005
PluckTray.exe 3100 1812 0 -1 Sat Jun 25 16:57:59 2005
dd.exe 4012 2624 1 22 Sat Jun 25 16:58:46 2005
2 - Exemplo de extração de conexões estabelecidasem de um Windows XP:
ss@ss-ubuntu:~/Volatility-1.1.2$ python volatility connections -f memory-images/xp-laptop-2005-06-25.img
Local Address Remote Address Pid
127.0.0.1:1056 127.0.0.1:1055 2160
127.0.0.1:1055 127.0.0.1:1056 2160
192.168.2.7:1077 64.62.243.144:80 2392
192.168.2.7:1082 205.161.7.134:80 2392
192.168.2.7:1066 199.239.137.200:80 2392
3 - Exemplo de extração de objetos EPROCESS em de um Windows XP:
ss@ss:~/Volatility-1.1.2$ ./volatility psscan -f memory-images/xp-laptop-2005-07-04-1430.img
No. PID Time created Time exited Offset PDB Remarks
---- ------ ------------------------ ------------------------ ---------- ---------- ----------------
1 0 0x00558e80 0x00039000 Idle
2 3612 Mon Jul 04 18:24:00 2005 0x013383b0 0x19d19000 PluckTray.exe
3 3276 Mon Jul 04 18:21:11 2005 0x0133d810 0x1ebc8000 firefox.exe
4 2496 Mon Jul 04 18:18:06 2005 0x01462be0 0x185c5000 VPTray.exe
5 2392 Mon Jul 04 18:18:03 2005 0x0146e860 0x17b7f000 explorer.exe
6 3128 Mon Jul 04 18:19:11 2005 0x01474510 0x1c1b5000 wuauclt.exe
7 368 Mon Jul 04 18:24:30 2005 Mon Jul 04 18:26:44 2005 0x01488350 0x1bb44000 PluckUpdater.ex
8 2692 Mon Jul 04 18:18:15 2005 0x014b8a58 0x1972e000 WZQKPICK.EXE
9 480 Mon Jul 04 18:17:29 2005 0x014dc020 0x0dec3000 winlogon.exe
10 2548 Mon Jul 04 18:18:07 2005 0x014ecc00 0x18962000 jusched.exe
11 680 Mon Jul 04 18:17:31 2005 0x014f0020 0x0e7b3000 svchost.exe
12 1380 Mon Jul 04 18:17:40 2005 0x01521da0 0x12701000 DefWatch.exe
13 524 Mon Jul 04 18:17:30 2005 0x015221c8 0x0e0de000 services.exe
(...)
Seguem para referência dois guias interessantes que detalham os passos a serem seguidos nos casos em que é necessária a Forense de Dados Voláteis:
- The Value of Physical Memory Analysis for Incident Response - HBGary
- Collecting Evidence From a Running Computer - SEARCH.ORG
- Dr. Brian Carrier (Basis Technology)
- Eoghan Casey (ONKC)
- Dr. Michael Cohen (Australian Federal Police)
- Brian Dykstra (Jones Dykstra & Associates)
- Brendan Dolan-Gavitt (Georgia Institute of Technology)
- Matthew Geiger (CERT)
- Keith Jones (Jones Dykstra & Associates)
- Jesse Kornblum (ManTech)
- Andreas Schuster (Deutsche Telekom AG)
- AAron Walters (Volatile Systems, LLC)
Tuesday, November 18, 2008
Preparação / Procedimentos em alto nível para suspeita de vazamento de dados por comprometimento de um servidor
Pergunta: Quais seriam os Procedimentos (incluindo a preparação) em alto nível para tratar um incidente de suspeita de vazamento de dados por comprometimento de um servidor?
Este assunto foi suscitado no ótimo blog "Resposta a Incidentes e Forense Computacional".
Segue minha resposta (incluindo links) - e já com a correção (F-Response e não F-Secure...) feita pelo Tony:
Para responder de uma maneira mais completa ao problema proposto, o ideal é que a equipe de resposta a incidentes responsável possa contar com 3 tipos de soluções, listadas por ordem de importância para o caso em pauta:
I - Uma infra-estrutura de "Network Forensics" que seja capaz de reconstruir e fazer o "replay" dos pacotes relacionados ao ataque (ex: NetWitness NextGen / CA Network Forensics)
II - Uma solução de SIEM/SEM para correlacionamento em near-real time dos logs (firewall, roteadores, servidor comprometido, ids/ips, dhcp, dns, aplicações internas, catracas de acesso, sistema de ponto, controle de acesso lógico, etc) (ex: ArcSight / ISM Intellitatics / Symantec SIM)
III - Uma solução (idealmente enterprise) de forense computacional que possibilite a análise de dados voláteis (incluindo memória) e de disco (ex: Encase Enterprise / F-Response / AccessData Enterprise )
Este assunto foi suscitado no ótimo blog "Resposta a Incidentes e Forense Computacional".
Segue minha resposta (incluindo links) - e já com a correção (F-Response e não F-Secure...) feita pelo Tony:
Para responder de uma maneira mais completa ao problema proposto, o ideal é que a equipe de resposta a incidentes responsável possa contar com 3 tipos de soluções, listadas por ordem de importância para o caso em pauta:
I - Uma infra-estrutura de "Network Forensics" que seja capaz de reconstruir e fazer o "replay" dos pacotes relacionados ao ataque (ex: NetWitness NextGen / CA Network Forensics)
II - Uma solução de SIEM/SEM para correlacionamento em near-real time dos logs (firewall, roteadores, servidor comprometido, ids/ips, dhcp, dns, aplicações internas, catracas de acesso, sistema de ponto, controle de acesso lógico, etc) (ex: ArcSight / ISM Intellitatics / Symantec SIM)
III - Uma solução (idealmente enterprise) de forense computacional que possibilite a análise de dados voláteis (incluindo memória) e de disco (ex: Encase Enterprise / F-Response / AccessData Enterprise )
IV - Uma ferarmenta de monitoração de atividade de desktops (ex: SpectorCNE, WorkExaminer) [item incluído em 18/10/2009]
Friday, November 7, 2008
Espionagem Industrial - Engenheiro da Intel que foi para a AMD é indiciado por roubar 13 documentos de projetos
Como já escrevi por aqui, a Intel é uma empresa que se preocupa muito com a segurança de suas informações, especialmente as relacionadas aos projetos de novos chips para microcomputadores.
Não é por acaso. Um ex-engenheiro da Intel que foi trabalhar na concorrente AMD foi indiciado por roubar 13 documentos de projetos secretos da empresa, incluindo alguns que possuiam o design de novos chips - (veja o documento legal do indiciamento).
Durante uma férias que tirou na Intel, o engenheiro Biswamohan Pani foi contratado pela AMD e acessou via VPN a Intel para obter os documentos. Um dos projetos que ele trabalhou na Intel foi o desenvolvimento do processador Itanium.
As investigações até o momento não acharam provas de que a AMD solicitou ou sabia dos planos de Pani, e as duas empresas estão cooperando com o FBI no tratamento do caso.
Apesar das tentativas de defesa - dizendo que os arquivos foram baixados para auxiliar o trabalho da esposa, que também é da Intel, o engenheiro corre o risco de ser preso por 10 ou 20 anos...
Subscribe to:
Posts (Atom)
