Tony\'s Top 10 Computer Forensics Artifacts

Preview:

DESCRIPTION

Presentation for Owasp Appsec Brazil 2010; Tony Rodrigues V1.1

Citation preview

The OWASP Foundationhttp://www.owasp.org

OWASP AppSecBrazil 2010, Campinas, SP

Tony‟s Top 10 Application ArtifactsA Computer Forensics Approach to OWASP Top 10

Tony Rodrigues, CISSP, CFCP

Provider IT Business Solution

inv.forense arroba gmail ponto com

Quem sou ?

Tony Rodrigues, CISSP, CFCP, Security+

Gestor/TI e Consultor em Segurança de

Informações

Perito/Investigador em Computação Forense

Blog: http://forcomp.blogspot.com

AgendaIntrodução

• CF de aplicações

Top 10 – Vestígios

• Web Server Log

• Banco de Dados

• Timelines

• Logs do SO

• Logs da Aplicação

• Monitoramento de Rede

• Registry

• Sistema de Arquivos

• Memória

• Documentação

Conclusão

Computação Forense de Aplicações

• Incidente já ocorreu !

• Busca descobrir

• Quem ?

• Quando ?

• Como ?

• Alcance (DoP – Depth of Penetration)

• Analisa os vestígios deixados

• Nas aplicações

• No seu ambiente

Computação Forense de Aplicações (II)

• Destaca-se:

• Necessidade de respostas rápidas

• Requerem entendimento específico

da aplicação

• Forte dependência de outras

disciplinas forenses

• Disco, Memória

• Correlação nos resultados

• Requisitada em diversas normas

• PCI (DSS), SUSEP (285)

Computação Forense de Aplicações (III)

• Desafios:

• Volume de informações

• Ausência de monitoramentos e logs

• Pouca disponibilidade do ambiente

• Ausência de padrão nos logs

dificulta correlação

OWASP Top 10

• Os dez riscos mais críticos para

aplicações Web

• Top 10 anual

• Conceitos

• Como verificar as vulnerabilidades

• Como evitá-las

• Exemplos de vulnerabilidades

Tony’s Top 10 ???

• Relação dos vestígios mais comuns em

Forense de Aplicações

• Correlacionam-se com os OWASP Top 10

• Ferramentas e técnicas aplicáveis

#1 – Log do WebServer

• Registra cada requisição ao Web

Server

• Formato de texto

• Geralmente podem ser configurados

quanto às informações a logar

• É a porta de entrada dos sistemas Web

#1 – Log do WebServer (IIS)

• Formato W3C Extended

• Em geral, ficam em LogFiles\W3SVCx

• Por default, logam:

• Data/Hora, Client IP, Server Info,

HTTP Method, URL e Parâmetros,

Http Status Code e User Agent

• Pode ser habilitado:

• Bytes transferidos, Host Header,

Cookies, Referrer

• Dados do POST nunca são logados

#1 – Log do WebServer (IIS)

#Software: Microsoft Internet Information Services 5.0

#Version: 1.0

#Date: 2008-06-20 01:03:15

#Fields:time c-ip cs-method cs-uri-stem cs-uri-query Status version1:03:15 172.16.22.33 POST /execute.asp

sessionid=90198e1525e4b03797f833ff4320af39 200 HTTP/1.0

#1 – Log do WebServer (IIS)

#Software: Microsoft Internet Information Services 5.0

#Version: 1.0

#Date: 2005-05-13 07:40:49

#Fields: date time c-ip cs-username s-sitename s-computername s-ip s-port cs-

method cs-uri-stem cs-uri-query sc-status sc-win32-status sc-bytes cs-bytes

time-taken cs-version cs(User-Agent) cs(Cookie) cs(Referer)

2005-05-13 07:40:49 203.164.88.39 - W3SVC235 W2KWEB5B 207.172.13.44 80

GET /rcn.htm - 200 0 1982 381 594 HTTP/1.1

Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.0;+.NET+CLR+1.1.4322) - -

#1 – Log do WebServer (Apache)

• Formato e localização bastante

customizáveis

• Configuração fica em httpd.conf

• Access.log armazena todas as

requisições

• LogFormat "%h %l %u %t \"%r\" %>s %b“

• Host remoto, logname remoto, usuário

remoto, hora, linha do request, status

e bytes enviados

• Mod_log_config e Mod_logio ampliam

informações logadas

• Dados do POST nunca são logados

#1 – Log do WebServer (Apache)

Usando:

LogFormat "%h %l %u %t \"%r\" %>s %b

\"%{Referer}i\" \"%{User-Agent}i\" %I %O"

combinedio

Gera:

192.168.200.105 - - [24/Nov/2006:11:23:30 -0500]

"GET / HTTP/1.1" 200 8054

"http://wooga.drbacchus.com/index.php?"

"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)

Gecko/20041107 Firefox/1.0" 935 8522

#1 – Log do WebServer - Ferramenta

• Microsoft LogParser

• Ferramenta free para manipular logs

• Suporta vários formatos de log

• Usa sintaxe SQL para manipular dados

C:\WINNT\System32\LogFiles\W3SVC1>logparser "SELECT

DISTINCT TO_LOWERCASE(cs-uri-stem) AS URL, Count(*)

AS Hits FROM ex*.log WHERE sc-status=200 GROUP BY

URL ORDER BY URL" -rtp:-1

#1 – Log do WebServer – Visual LogParser

#1 – Log do WebServer – Principais campos

Campo Descrição Uso

Client IP Address (c-ip) IP do requisitante Identifica usuário

User Name (cs-

username)Nome de usuário usado na autenticação Identifica possível credencial comprometida

URI Stem (cs-uri-stem) O que foi acessado no servidor Pode identificar vetores de ataque

URI Query (cs-uri-query) Query string do acesso Pode identificar XSS e Injections

Protocol Status (sc-

status)Código do resultado Pode identificar ataques de SQLi

Bytes Sent (sc-bytes) Bytes enviados ao cliente Pode identificar tráfego suspeito

Bytes Received (cs-

bytes)

Número de bytes recebidos pelo

servidorPode identificar tráfego suspeito

Time Taken (time-taken) Tempo para processar a requisição Pode identificar Blind SQLi

Host (cs-host)Conteúdo do HTTP Host header

enviado pelo clienteIdentifica se navegação foi por nome ou IP

User Agent (cs(User-

Agent))Conteúdo do HTTP User-Agent header

Pode identificar usuário. Indica versão do browser,

por exemplo

Cookie (cs(Cookie)) Conteúdo do cookie Pode identificar usuário

Referer (cs(Referer)) Conteúdo do HTTP Referer headerIdentifica de onde o usuário veio (de um site de

buscas, por exemplo)

#1 – Log do WebServer - Investigando

SQL Injection:

logparser "SELECT date, time,s-ip,c-ip,cs-uri-stem AS query

INTO C:\Log_op\sql1.txt

FROM C:\W3SVC1\ex*.log

WHERE (sc-status>=200 AND sc-status<400)

AND (cs-uri-stem LIKE '%--%' OR

cs-uri-stem LIKE '%;%' OR

cs-uri-stem LIKE'%\'%' OR

cs-uri-stem LIKE '%#%')

AND (cs-uri-stem LIKE '%|%' OR

cs-uri-stem LIKE '%+%' OR

cs-uri-stem LIKE '%OR%„ OR

cs-uri-stem LIKE '%AND%' OR

cs-uri-stem LIKE '%SELECT%' OR

cs-uri-stem LIKE '%UPDATE%„ OR

cs-uri-stem LIKE '%INSERT%' OR

… outras keywords de SQL)

ORDER BY date, time"

#1 – Log do WebServer - Investigando

XSS:

logparser "SELECT date, time, s-ip, c-ip, cs-uri-stem AS query

INTO C:\Log_op\xss.txt

FROM C:\W3SVC1\ex*.log

WHERE cs-uri-stem LIKE '%<%' OR

cs-uri-stem LIKE '%>%' OR

cs-uri-stem LIKE '%\'%' OR

cs-uri-stem LIKE '%:%' OR

cs-uri-stem LIKE '%\"%' OR

cs-uri-stem LIKE '%\--%„ OR

… outras keywords html (script, iframe, por exemplo)

ORDER BY date, time"

#1 – Log do WebServer - Investigando

Session Mgt:

logparser "SELECT date, cs-uri-query, c-ip,

count(cs-uri-query) as Ocorrencias

INTO C:\Log_op\session.txt

FROM C:\W3SVC1\ex*.log

WHERE cs-uri-query LIKE

'%sessionID%„

GROUP BY date, cs-uri-query, c-ip “

Suspeite de mesmo sessionID na mesma data e

com IPs diferentes

#1 – Log do WebServer - Investigando

Envio de informações:

logparser "SELECT date, c-ip, max(sc-bytes) as

MaiorEnvio

INTO C:\Log_op\envio.txt

FROM C:\W3SVC1\ex*.log

GROUP BY date, c-ip “

Valor de MaiorEnvio destoando dos outros deve ser

averiguado. Faça devidos filtros por data

#1 – Log do WebServer - Investigando

Redirection/CSRF:

logparser "SELECT cs-uri-stem, cs-referer, count()

as Ocorrencias

INTO C:\Log_op\referer.txt

FROM C:\W3SVC1\ex*.log

GROUP BY cs-uri-stem, cs-referer

HAVING cs-uri-stem <> „/paginainicial‟“

Em geral, páginas tem um pequeno conjunto

específico de referers

#1 – Log do WebServer - Investigando

Subqueries:logparser "SELECT c-ip, cs-uri-stem, Count(*) as Hits

FROM ex*.log

WHERE TO_LOWERCASE(cs-uri-stem) NOT

LIKE '%.gif' AND

TO_LOWERCASE(cs-uri-stem) NOT LIKE

'%.jpg%' AND

c-ip IN (SELECT c-ip FROM

c:\Log_op\arquivo.txt WHERE sc-status=404)

AND sc-status=200

GROUP BY c-ip, cs-uri-stem" -rtp:-1“

Resultados podem ser aninhados

Caso – Ações em Alta

• Vários clientes da corretora alegaram que operações foram feitas em suas contas sem sua autorização. Ações de uma empresa desconhecida foram compradas a partir de suas contas

• Informações iniciais: Data/Hora das transações Log do WebServer (IIS)

• O que foi localizado no log: SessionID passado pela URL (GET) Vários IPs em datas diferentes com o mesmo

SessionID

Caso – Ações em Alta

• O que foi localizado na máquina da vítima: Nenhum trojan ou keylogger Um email (phishing) explorando session fixation

• Conclusão As pessoas lesadas tinham clicado em um email

fraudulento que explorava a falha da aplicação. Vestígios localizados no log do webserver e no

computador de uma das vítimas apoiaram a conclusão.

#2 – Banco de Dados

• Fundamental nas aplicações Web

• Vestígios importantes mesmo sem

auditorias ligadas

• Alvo comum em ataques

• Vestígios em DML e DDL

#2 – Banco de Dados – Ordem de Coleta

• Dados voláteis do SGBD

• Sessões e Conexões

• Requests ativos

• Usuários ativos

• Memória

• Transaction Logs

• Arquivos de Base de Dados

• Error Logs do SGBD

• Logs de eventos do sistema

• Arquivos de Trace

#2 – Banco de Dados – Coletando dados voláteis

• Ferramenta: sqlcmd

• Command line para SQL Server

• Permite executar queries no banco de

dados e logar os resultados

• Outros bancos possuem conceitos

similares

• Coletando o transaction log ativo:

sp_helpdb

#2 – Banco de Dados – Coletando dados voláteis

• Sessões abertas no banco:

select * from sys.dm_exec_sessions

#2 – Banco de Dados – Coletando dados voláteis

• Conexões ativas no banco:

select c.session_id, c.connect_time,

c.net_transport, c.last_read,

c.last_write, c.client_net_address,

c.local_tcp_port, s.text

from sys.dm_exec_connections c

cross apply sys.dm_exec_sql_text

(c.most_recent_sql_handle) s

#2 – Banco de Dados – Coletando dados voláteis

• Contas do banco:

select name, type_desc, create_date,

modify_date

from sys.sql_logins

order by

create_date, modify_date

#2 – Banco de Dados – Coletando dados voláteis

• Informações sobre execuções:

select * from sys.dm_exec_requests

1.SELECT [text] FROM sys.dm_exec_sql_textResults:

1.Text2.SELECT AccountDescription FROM DimAccount WHEREAccountKey = 2

#2 – Banco de Dados – Selects

• Informações sobre queries recentemente

executadas: Query Plans Cache

• Exemplo:

#2 – Banco de Dados – Selects – Plan Cache

• Armazenam quantidade considerável de

informações

• Em um server com 28Gb, pode chegar a 16Gb

de cache em um SQL Server 2005

• Podem ficar dias na memória

• Dependências:

• Demanda de memória do servidor

• Mudança em objetos associados

• Limpeza manual do cache

• Restart do serviço do SQL Server

#2 – Banco de Dados – Selects – Plan Cache

• Capturando informações do Query Plan Cache:

Select *

from sys.dm_exec_cached_plans

cross apply sys.dm_exec_sql_text(plan_handle)

• Outras informações no Cache:

Select * from sys.dm_exec_query_stats

Select *

from sys.dm_exec_cached_plans

cross apply sys.dm_exec_plan_attributes(plan_handle)

#2 – Banco de Dados – Selects – Plan Cache

• Analise queries que apresentem anomalias em relação ao

padrão de queries da aplicação

#2 – Banco de Dados – Transaction Log

• Transaction Log

• Não pode ser desligado como um item de

auditoria

• Registra DDLs e DMLs aplicadas ao banco

• Permite recuperar conteúdos apagados

• Permite detectar valores antes e após

modificações

#2 – Banco de Dados – Transaction Log

• Coletando

- Select * from ::fn_dblog(NULL,NULL)

- Dbcc log (<nome do banco>,3)

#2 – Banco de Dados – Transaction Log

• Campos mais importantes:

Campo Descrição

Operation Tipo de operação

PageID Página de dados afetada pela operação

SlotID Linha dentro da página de dados afetada pela

operação

Offset in Row Offset das informações dentro da linha

SPID Identificador do processo no servidor SQL Server

Begin Time Início da transação

End Time Fim da transação

RowLogContents

0

Conteúdo antes da operação

RowLogContents

1

Conteúdo após a operação

#2 – Banco de Dados – Transaction Log

• RowContents – Estrutura:

#2 – Banco de Dados – Ferramenta: SQLJuicer

• Lista transações marcadas no transaction log

• Reconstrói da transação mais recente à mais

antiga após o último checkpoint

• Informa data/hora, operação, campos afetados e

valores antes/depois da transação

• Dependente do SQL Server e do SQLCmd

• Escrita em PERL

• HELP !

• Ainda não lista DDLs

• Algumas operações ainda não foram

mapeadas

• Avançado: Independência do SQL Server e

dos checkpoints

#2 – Banco de Dados – Outros vestígios

• Arquivos de trace default:

• Diretório MSSQL\LOG\LOG_#.TRC

• Logs de erro do SQL Server

• Diretório MSSQL\LOG\ERRORLOG

Caso – Super Promoção de Eletros

• Uma operadora de cartões de crédito alertou a uma companhia de vendas de departamento que opera pela Web que estava recebendo de lá repetidas transações fora do perfil

• Informações iniciais: Data/Hora das transações Log do WebServer (IIS) Banco de Dados SQL Server

• O que foi localizado: No transaction log havia vários updates, colocando preços ínfimos para os produtos anunciados no site No query plan cache havia selects na tabela de compras, recuperando números de cartão de crédito Esses números de cartão foram usados nas compras Havia várias tentativas seguidas de login do usuário SA assinaladas no SQL Server Error Log As queries dos updates foram realizadas pelo SA

Caso – Super Promoção de Eletros

Conclusão

A senha do SA foi quebrada e o atacante se logou no banco. Ele veio a partir de uma máquina interna

Ele buscou números de CC para usar e realizou compras pela aplicação, depois de trocar os preços de vários produtos

Depois foi apurado que alguém resgatou os produtos no endereço de entrega usando Engenharia Social

#3 – Timelines

• Análise temporal dos eventos

• Permitem filtrar por datas próximas ao

evento

• Envolvem:

• Sistema de Arquivos

• Eventos do SO

• Logs diversos

• System Restore Points

• Sensível ao sincronismo de relógio !

#3 – Timelines

• Ferramentas:

• FLS (The SleuthKit)

• Log2Timeline

• Ex-Tip

#3 – Timelines – Log2timeline

#4 – Logs do SO

• Registram eventos específicos do SO

• Podem ser usados em timelines

• Envolvem:

• Logs de eventos do Windows

• Logs de Atividades Agendadas

• SetupApi

• Arquivos Prefetch

• System Restore Points

• Shadow Copy

#4 – Logs do SO

• Podem indicar:

• Erros de execução em exploits

• Execução de programas estranhos

ao ambiente

• Uso de mídia removível no servidor

• Mudança de versão de arquivo

#4 – Logs do SO

• Ferramentas:

• Evtxdump

• Evtxparser

• LogParser

• Prefetch_info

• WFA

• SAEX (SetupApi Extractor)

• ShadowExplorer

• Restore Point Analyser

#4 – Logs do SO - WFA

#4 – Logs do SO - SAEX

#4 – Logs do SO – Shadow Explorer

#4 – Logs do SO - Mandiant Restore Point Analyser

#5 – Logs da Aplicação

• Registram eventos específicos das aplicações

• Podem ser usados em timelines, mas em geral

precisam de tradução entre formatos

• Envolvem:

• Logs de erros da aplicação

• Logs de Acesso

• Violation Report

• Lista de Usuários Ativos

• Auditorias

• Nem sempre estão implementados

#5 – Logs da Aplicação

• Podem indicar:

• Tentativa de exploração de erros

• Acesso não autorizado

• Comprometimento de credenciais

• SQLi

• Alteração de dados fora da aplicação

• Tentativa de Anti-Forense (logs podem indicar

operações removidas dos logs do SO)

#5 – Logs da Aplicação

• Ferramentas

• LogParser

• Perl, Python, Ruby, etc

• Scripts

Caso – Estranho no Ninho

• Um dos Analistas de Segurança alertou a equipe de Resposta a Incidentes que verificasse uma tentativa de exploração do website da Companhia.

• Ele percebeu que, durante a realização do monitoramento de controle periódico conhecido como Violation Report, havia registro de tentativa sem sucesso para usuário XXX‟ Or 1=1; --

• Informações iniciais: Data/Hora das tentativas Log de uso da aplicação Relatório de Active Users da aplicação

Caso – Estranho no Ninho

• O que foi localizado: O relatório de Active Users mostrou um novo usuário

criado com data próxima ao registro da tentativa de SQLi

Não havia registro de requisição formal para a criação do tal usuário

O relatório de uso da aplicação também mostrou atividade para o Admin próximo a data do ataque e antes da criação do novo usuário

O relatório de uso da aplicação mostrou toda a atividade realizada pela nova conta

Caso – Estranho no Ninho• Conclusão O atacante teve sucesso em explorar o módulo de

login por SQLi e conseguiu obter a credencial de administrador

Um timeline usando as informações dos relatórios permitiu perceber que um novo usuário foi criado e as informações fornecidas pelo sistema foram comprometidas

A área de Segurança de Informações não tinha recebido o módulo de Login para fazer a homologação. Alegação: o projeto precisava entrar no “ar” e isso seria feito depois ...

#6 – Monitoramento de Rede

• Registram comunicações entre as aplicações

• Registram comunicações no ambiente

• Geram grande quantidade de dados

• Envolve:

• Conteúdo de todas as comunicações

realizadas para um determinado servidor ou

grupo de servidores

• Incluindo info passada por POST !

• Nem sempre estão implementados

• Soluções comerciais são MUITO caras

• Se bem implementado, pode indicar qualquer tipo

de ataque não local

#6 – Monitoramento de Rede

• Ferramentas

• Wireshark

• TCPDump

• Packetyzer

• NetworkMiner

• XPlico

#6 – Monitoramento de Rede – Xplico

• Mostra os dados coletados em formato “human-

readable”

• Permite ver as telas trafegadas

• Permite escutar conversas VoIP

• Permite recuperar arquivos (download e

upload)

• Permite ver vídeos e imagens trafegados

#6 – Monitoramento de Rede – Xplico

#6 – Monitoramento de Rede – Xplico

#7 – Registry

• Banco de dados de configurações do Windows

• Pode funcionar como um grande log

• Chaves possuem timestamp de Ultima

Modificação

• Algumas aplicações guardam nele suas

configurações

• Podem conter elementos de persistência

• Envolve:

• Contas de Usuários

• Policies

• Configurações de TCP/IP

• Uso de mídia removível

• Ações de usuário no servidor

#7 – Registry

• Ferramentas

• RegRipper

• WindowsRipper

• RipXP

• Windows registry Analysis (WRA)

• Registry File Viewer (RFV)

#7 – Registry - WRA

Caso – Operador Malicioso

• Dados de uma grande empresa foram parar em todas as esquinas de uma grande cidade, vendidos em DVDs. A diretoria tinha várias suspeitas e investigava cada uma delas em sigilo.

• O que foi localizado: Havia um select anômalo aplicado na base de dados Nada foi localizado nos logs do SO ou do Webserver O Registry indica, com data e hora, que um drive

externo foi usado recentemente O mesmo serial foi localizado no Registry da máquina

do operador

• Conclusão Buscas adicionais acharam traços do arquivo com dump

da base de dados no drive externo, que foi recuperado.

#8 – Sistema de Arquivos

• Elementos de controle do Sistema de Arquivos

• Pode funcionar como log

• Podem indicar alteração de arquivos ou sua

pré-existência

• Envolve:

• Espaços não alocados

• Slack space

• Estruturas de Journal

• Indexadores ($I30)

• Podem indicar:

• Uso de técnicas Anti-Forenses

• Vetores de ataque

#8 – Sistema de Arquivos – NTFS USN Journal

• Trabalha na manutenção de integridade do

sistema de arquivos

• Armazena atributos alterados

• Não armazena conteúdos !

• Conteúdo (arquivo esparso) fica em uma ADS

($J) dentro do $extend\$UsnJrnl

• Existem códigos que listam o antes/depois

#8 – Sistema de Arquivos – NTFS $I30

• Atributo de diretórios

• Trabalha na indexação

• Armazena atributos

FN com

timestamps (MAC

times)

#8 – Sistema de Arquivos

• Ferramentas

• Utilitários do TSK - The Sleuth Kit

• Icat, istat, jls, jcat, fls, blkcat

• Utilitários do Byte Investigator

• parseI30, ADS, ADSExt

• AnalisaMFT.py

• UsnJrnl.py

#9 – Memória

• Um dos itens mais ricos em vestígios

• Pode funcionar como log

• Algumas estruturas de controle possuem

timestamps

• Envolve:

• Processos já terminados

• Conteúdos de arquivos

• Captura de malware

• Vestígios que não tocaram o disco ou foram

removidos

• Podem indicar:

• Uso de técnicas Anti-Forenses

• Vetores de ataque

#9 – Memória • Ainda assim:

• Bastante volátil

• Coleta invasiva

• Técnicas não completamente

amadurecidas

• Dificuldade de correlação entre os hosts

• Constantemente prejudicada por ações de

resposta mal planejadas

• Desligar a máquina, por exemplo.

#9 – Memória • Ferramentas:

• Coleta

• Win32DD, Win64DD (MoonSols)

• ManTech MemoryDD (mdd)

• Mandiant Memoryze

• Análise

• Mandiant Memoryze

• Volatility

• PTFinder

Caso – Nenhuma pista

• Durante as investigações de um incidente, dois peritos ficaram intrigados ao perceber que as ações maliciosas executadas na máquina não respondiam ao “como”

• O que foi localizado: O log de eventos acusou que houve login via RDP

na máquina Várias ações poderiam ser assim explicadas,

porém como o acesso foi conseguido ? Antes de lançar suspeitas sobre os

Administradores terem repassado a senha, foi feito uma análise da memória do servidor

Localizou-se vestígios de uso do Meterpreter/SAMJuicer

Caso – Nenhuma pista

• Conclusão Havia uma vulnerabilidade que permitia a

exploração pelo módulo Meterpreter do Metasploit Através do Meterpreter, o SAMJuicer baixou o SAM

da máquina sem tocar no disco e o enviou para o atacante

A senha de uma das contas foi quebrada e o servidor foi acessado por RDP

#10 – Documentação !

• Um dos vestígios mais ignorados pelos

investigadores digitais

• Deve ser requisitada ainda na fase de levantamento

• Faz parte dos Vestígios Documentais

• Envolve:

• Diagramas e topologia de rede

• Códigos Fontes

• Descrição de arquitetura

• Regras de negócio

• Podem indicar:

• A diferença entre uma investigação rápida e uma

bem demorada ou infrutífera

Caso – LogmeIn

• Um CEO de uma companhia recebeu um email extorsivo, onde uma pessoa alegava ter todos os dados de cartão de crédito usado pela empresa e iria divulgá-los para redes de crime organizado a não ser que recebesse uma não pequena quantia em dinheiro• Os diretores procuraram ganhar tempo enquanto se determinava a veracidade da ameaça e se procurava descobrir mais

Caso – LogmeIn

• O que foi localizado: Inicialmente, nada foi localizado no log do webserver O Query Plan Cache indicava uma operação de select

em todas as colunas e linhas da tabela de Cartões de Crédito, mas nada indicava como os dados teriam sido retirados

Uma análise mais minuciosa do log do webservermostrou que uma quantidade excessiva de dados foi enviada em resposta a uma requisição

Havia um backdoor no módulo de login que executava o select no caso do usuário “LogmeIn” fizesse o login

Caso – LogmeIn

• Conclusão Houve confirmação da saída dos dados de CC Uma análise do software de controle de versões

mostrou o responsável pela alteração e que introduziu o backdoor

Investigações posteriores ligaram o autor do backdoor à conta de envio do email com a extorsão

Concluindo

Computação Forense de Aplicações

apresenta alguns desafios

interessantes por praticamente

exigir correlação para chegar às

conclusões.

Conhecer onde estão os principais

vestígios é mais do que um

diferencial e pode definir o

sucesso da investigação.

Referências

OWASP Top 10 Project

• http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project Live

View

Kevvie Fowler - SQL Server Forensics

• http://www.applicationforensics.com/

David Litchfield - Oracle Forensics

• http://www.ngssoftware.com /

Forensic Log Parsing with Microsoft's LogParser

• Mark Burnett para SecurityFocus

Referências II

Incident Handling and Log Analysis in a Web Driven World

• Manindra Kishore – ClubHack 2009

Web Application Incident Response & Forensics: A Whole New Ball Game!

• Chuck Willis & Rohyt Belani – Mandiant – Black Hat USA 2006

LogParser

• http://www.microsoft.com/downloads/details.aspx?FamilyID=890cd06b-

abf8-4c25-91b2-f8d975cf8c07&displaylang=en

Visual LogParser

• http://en.serialcoder.net/logiciels/visual-logparser.aspx

Referências III

SQLJuicer

• http://code.google.com/p/sqljuicer/

Log2Timeline

• http://log2timeline.net/

Shadow Explorer

• http://www.shadowexplorer.com/

XPlico

• http://www.xplico.org

RegRipper

• http://regripper.net/

Byte Investigator

• http://sourceforge.net/projects/byteinvestigato/

Sugestões de Leitura

http://forcomp.blogspot.com

http://www.e-evidence.info

Obrigado !

inv.forense arroba gmail

ponto com

(Tony Rodrigues)