Este vídeo foi produzido pela Associação Baiana de Criminalística em conjunto com a TV Câmara Salvador, parte de uma série sobre a Perícia Criminal na Bahia. O vídeo original e outros sobre o tema você pode encontrar no canal da TV Câmara, no Vimeo.
Rastreamento de E-mails – Parte V – Campos de rastreio
Neste post vamos analisar com mais detalhes os campos de cabeçalho que podem fornecer informações importantes para a identificação de origem e autor, conhecidos como Trace Fields ou campos de rastreamento que são de grande importância na identificação real do remetente.
Continuaremos a utilizar o cabeçalho da figura 5 do post anterior como referência para os campos discutidos a seguir.
Figura 5 – Cabeçalho de uma mensagem resultante de um diálogo
X Headers são campos de cabeçalhos iniciados pela letra X maiúscula seguido de um hífen, de caráter informativo, que podem ser extremamente úteis na identificação da autoria de um e-mail. Os X Headers mais comuns são:
“X-Mailer:” Indica qual o cliente de correio foi utilizado para compor a mensagem.
“X-Yahoo-Post-IP:”, “X-AOL-IP:”, “X-Apparently-From:”, “X-SenderIP:”, “X-Originating-IP:”, etc. Indicam o endereço IP da conexão à internet que o usuário utilizou para o envio da mensagem. Se este usuário utilizou-se de um artifício qualquer para encobrir seu endereço IP real, o conteúdo não terá nenhum valor.
“X-OriginalArrivalTime:” Informa a data e hora do envio da mensagem no fuso (UTC) seguido dessa mesma informação no formato Windows Filetime, que consiste em um valor de 64 bits representado pelo número de intervalos de 100 nano segundos a partir de 01 de janeiro de 1601. Esse valor pode ser convertido para confirmação da hora real do envio e, associado ao endereço IP, indicarão o “quando” e “onde”.
“Message-ID:” Este campo contém um identificador único gerado pelo primeiro servidor de correio que submete a mensagem (MSA) e tem um formato parecido com “ID”@“HOST”, onde o ID constitui um identificador composto por uma sequência de caracteres (gerados por diversos algoritmos), inteligíveis ou não. HOST é o nome da máquina que gera o identificador. Se o host que gerou o ID fizer parte de um domínio, HOST será o nome do domínio. Se o Message-ID apresentar discrepâncias com o padrão A@B, como uma string vazia, ausência do “@” ou ainda apresentar um nome de host diferente do MSA, pode implicar na utilização de um servidor de correio eletrônico com open relay, diferente do domínio original do remetente ou uma mensagem forjada, como vimos na figura 3 do terceiro post.
Os campos “In-Reply-To:” e “References:” só aparecem quando uma mensagem é respondida ou encaminhada. O campo “References:” também pode ser utilizado para identificar uma conversação.
“In-Reply-To:” Contém o Message-ID da mensagem que está sendo respondida/encaminhada.
“References:” Contém o(s) Message-ID(s) da(s) mensagem(ns) que está(ão) relacionadas com a mensagem em análise.
Os campos “Received:” relacionam os servidores MTAs por onde passaram a mensagem, incluindo o MSA e o MDA (Ambos são MTAs). Este campo pode conter informações forjadas e se isso ocorrer, estas informações estarão sempre nos primeiros campos, já que há um empilhamento a partir do primeiro (base) até o último (topo) servidor.
O campo “Received:” possui a seguinte sintaxe:
Received: from “A” (Nome de A [IP de A])(Obs.) by B (Informações de B) via C with D id E for F; date-time
Onde A é o host de origem, B é o servidor que recebeu a mensagem e gera o campo “Received:“, C é o protocolo, D é o serviço, E é o id gerado pelo servidor B e F é a conta do destinatário. Date-time é o instante em que ocorre a entrega da mensagem à B. As variáveis A, B, C, D, E e F podem não estar todas no conteúdo do campo, variando de acordo com cada situação. Vejamos alguns exemplos.
Exemplo 1:
Figura 6: Campo “Received:” sem a variável “C”
Podemos dizer que neste caso a mensagem foi composta em um cliente de correio (Microsoft Outlook Express 6.00.2900.5931) instalado na “estação_remetente”. Podemos ver que a estação não faz parte de um domínio pois o Message-ID tem como “HOST” a “estação_remetente”. Caso a estação fizesse parte de um domínio (por exemplo: dominio_destinatario.org), o “Message-ID:” teria como valor <44206789192B4FB4ADA3D69390304921@dominio_destinatario.org>.
Exemplo 2:
Figura 7
Este campo “Received:” da figura 7 não apresenta o host de origem (A) porque o host de destino (B) está no mesmo domínio de A.
Exemplo 3:
Figura 8
O campo “Received-SPF:” indica que o servidor implementou o SPF (Sender Policy Framework). O SPF é um padrão aberto que especifica um método técnico para evitar a falsificação endereço do remetente (envelope), comumente chamado de return-path, que é utilizado pelos MTAs para enviar a mensagem de um para o outro especificando o endereço de retorno em caso de falha. O SPF dificulta a utilização de endereços forjados através de políticas de permissão de envio de mensagens oriundas de domínios confiáveis.
Veja que o campo “Received:” identifica o nome do host remetente através do comando HELO ou EHLO e o registra como “estação_remetente” e identifica o usuário que utilizou sua conta (“remetente”) para autenticar no domínio e enviar a mensagem. O host tem sua identidade registrada no campo “Received-SPF:” quando aponta o resultado do comando HELO.
No próximo post faremos uma análise em um cabeçalho de uma mensagem eletrônica.
Para saber nais sobre campo “Received-SPF:” visite o site do Sender Policy Framework
A Timeline e Metadados de Data e Hora
Apesar de já termos abordado o assunto em um post anterior, gostaria de aprofundar um pouco mais sobre os campos de metadados do sistema de arquivos, os MAC Times. Todo arquivo ou registro digital ao ser modificado, acessado agrega informações de data e hora associados à ação submetida, inerentes ao sistema de arquivos da mídia onde foram modificados ou acessados. Dessa forma todo evento relacionado a um arquivo digital possuirá uma referência que lhe situará em uma linha de tempo (timeline) de um determinado caso e sua localização nesta linha temporal poderá indicar sua relação com um fato analisado. A timeline é uma forma cronológica de apresentar informações relativas a um determinado evento. A análise da linha de tempo pode situar uma prova em um determinado instante associado a um evento ou colocá-la em um contexto não plausível para o caso estudado, inviabilizando-a. Informações mal interpretadas poderão gerar dúvidas quanto à confiabilidade da prova.
MAC Time Stamps
São chamados de MAC times stamps os campos que armazenam os registros relativos à data e hora de modificação/modification (mtime), acesso/access (atime) e mudança/change (ctime) dos arquivos. Em sistemas UNIX o ctime é o momento em que o metadado relativo à permissão ou propriedade de um determinado arquivo é alterado. Nos sistemas Microsoft Windows o ctime armazena o instante em que um arquivo é criado.
O mtime registra apenas o instante em que um arquivo foi modificado, ou seja, quando foi submetido à ação de salvar. Portanto mesmo que não haja alteração do seu conteúdo, apenas o ato de abrir e salvar um arquivo altera o registro do campo mtime.
O atime por sua vez registra o instante do acesso de um arquivo, ou seja, quando o mesmo foi aberto. Caso o arquivo fique aberto por muito tempo o conteúdo deste campo pode não refletir o instante preciso em que seu conteúdo foi lido.
FORMATO DE 32 BITS WINDOWS/DOS
A data e hora é armazenada em uma estrutura de 32 bits ou 4 bytes, onde:
- Os segundos ocupam 5 bits a partir do offset 0
- Os minutos ocupam 6 bits a partir do offset 5
- As horas ocupam 5 bits a partir do offset 11
- Os dias ocupam 5 bits a partir do offset 16
- Os meses ocupam 4 bits a partir do offset 21
- Os anos ocupam 7 bits a partir do offset 25 à partir de 1980
Este formato é utilizado no sistema de arquivos FAT para gravar registros de data e hora como data de criação do arquivo (File Created Date), data de modificação do arquivo (File Modified Date) e data de último acesso (Last Access Date). Este formato é normalmente referido como Formato de Data e Hora MS DOS e gravado conforme o horário local ajustado no computador
FORMATO DE 64 BITS WINDOWS FILETIME
A data e hora é armazenada em um número de 64 bits ou 8 bytes, iniciado em 00:00:00 de 1 de janeiro de 1601 UTC e incrementado em intervalos de 100 nano segundos.
Este formato é utilizado na Master File Table (MTF) do NTFS para gravar registros de data e hora como data de criação do arquivo (File Created Date), data de modificação do arquivo (File Modified Date) e data de último acesso (Last Access Date). O sistema NFTS grava a data e hora no formato UTC.
FORMATO DE 32 BITS C/UNIX
A data e hora é armazenada em um número de 32 bits ou 4 bytes, com valor em segundos, iniciado em 00:00:00 de 1 de janeiro de 1970 UTC.
Este formato é utilizado comumente em sistemas Unix.
FORMATO DE 32 BITS HFS/HFS+
A data e hora é armazenada em um número de 32 bits ou 4 bytes, com valor em segundos, iniciado em 00:00:00 de 1 de janeiro de 1904 UTC.
Este formato é utilizado comumente em sistemas Apple
CUIDADOS COM METADADOS DE DATA E HORA
Primeiramente vimos que todo arquivo tem metadados que registram os momentos de criação, acesso e modificação dos arquivos e eles serão gravados de acordo com a hora do sistema em que foram criados, sendo assim é de fundamental importância verificar os ajustes de data e hora do equipamento que os produziu.
É necessário adotar um horário de referência para alinhá-lo a cada equipamento que tenha produzido evidências digitais em um caso. Assim teremos uma linha de tempo coerente, onde cada evidência estará situada em seu devido lugar.
As câmeras fotográficas digitais, inclusive aquelas presentes nos aparelhos de telefonia móvel, tablets, etc., registram imagens e também associam MAC Time aos arquivos criados, entretanto se os arquivos forem copiados para outras mídias, refletirão os momentos do sistema para onde copiados/movidos. Entretanto estas também criam metadados que são armazenados internamente no arquivo digital, também conhecidos como metadados EXIF (Exchangeable Image File Format) que entre outras coisas armazenam dados acerca da câmera/telefone, ajustes da imagem, data e hora de produção da imagem, geotags, copyright, autoria, etc. Logo se uma imagem tem seus metadados alterados em função de cópia ou de forma intencional, ainda temos a possibilidade de verificar o instante em que foi produzida pelo equipamento através dos metadados EXIF. Aqui vale um cuidado extra. As câmeras podem estar com horário desajustado ou os metadados EXIF podem ter sidos alterados com auxílio de editores EXIF. O conteúdo das imagens podem auxiliar nos mostrando posição de sombras, relógios, fatos conhecidos, etc.
Arquivos como os do Microsoft Office, Adobe Acrobat, Word Perfect, Open Office, Microsoft Works, etc., podem registrar data e hora da produção do conteúdo, autor e outras informações em metadados próprios dos seus arquivos.
Ao analisar um computador com sistema Windows Vista ou 7, lembre-se que por padrão eles não registram o acesso ao arquivo (atime). Isto se deve porque a chave HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ControlFileSystem possui o valor NtfsDisableLastAccessUpdate igual a 1.
Figura 1 – “Valor NtfsDisableLastAccessUpdate=1”
Máquinas com Linux que montam dispositivos de armazenamento com a opção noatime, configurada em /etc/fstab, possuem o mesmo comportamento.
Figura 2 – Arquivo “fstab” com a opção “noatime”
Outro aspecto importante é verificar qual o fuso horário ajustado no equipamento examinado. Esta informação fica armazenada, no registro dos sistemas Microsoft Windows, na chave HKEY_LOCAL_MACHINESYSTEM CurrentControlSetControlTimeZoneInformation, no valor ActiveTimeBias, como vemos a seguir:
Figura 3 – O valor ActiveTimeBias contendo o número de minutos para o padrão UTC
Já o Linux guarda estas informações na pasta /usr/share/zoneinfo.
Por fim certifique-se se o arquivo da evidência possui metadados inerentes à aplicação que o criou e caso haja, compare-os aos metadados do sistema de arquivos, assim você terá uma visão mais ampla do que ocorreu com a evidência em questão.
Saiba mais sobre…
…MAC Times –
http://drdobbs.com/cpp/184404275 e http://pt.wikipedia.org/wiki/MAC_times
…Metadados EXIF –
http://pt.wikipedia.org/wiki/Exif
Cabeçalhos de mensagens do webmail da Oi
A Oi alterou seu webmail, passando para o Google, dessa forma a visualização do código-fonte da mensagem e a extração do cabeçalho completo seguem os mesmos padrões do Gmail e família. Confira aqui.
Rastreamento de E-mails – Parte IV – Campos de cabeçalho
Após a composição e envio da mensagem, o cabeçalho sofre acréscimos à medida que passa pelos servidores de correio, até seu destino final. Este cabeçalho nos permite entender toda a trajetória da mensagem, desde sua origem até a entrega ao destinatário, apresentando dados que podem nos levar a determinar origem e autoria.
Abaixo vemos um cabeçalho completo originado a partir da comunicação entre dois usuários hipotéticos, “[email protected]” e “destinatá[email protected]” e o utilizaremos para iniciarmos a descrição dos campos mais comuns nas mensagens de correio eletrônico, o seu significado e o do seu conteúdo.
Figura 5 – Cabeçalho de uma mensagem resultante de um diálogo
O campo “From:” contém o endereço do suposto remetente, que conforme vimos anteriormente pode ser fraudado, portanto não pode ser tomado como verdade absoluta.
O campo “To:” contém o endereço do destinatário que obviamente não será fraudado, já que a mensagem tem de chegar à ele. Ainda assim deverá ser observado se não corresponder com o destinatário, pois este pode ter recebido a mensagem por cópia oculta.
“CC:” Possui a mesma função do To: servindo para envio de cópia da mensagem a um segundo destinatário.
“BCC:” Significa Bind Carbon Copy e tem função similar ao To: e ao CC: entretanto este campo não mostra seu conteúdo, servindo para que a mensagem chegue a um terceiro destinatário sem que o destinatário principal ou o secundário saibam.
“Subject:” Contém o assunto da mensagem.
“Date:” Contém a data/hora em que a mensagem é submetida ou escrita, dependendo do sistema utilizado (RFC 822: 5.1, RFC 1123: 5.2.14 ou RFC 1036: 2.1.2.).
“MIME-Version:” Indica que o conteúdo da mensagem foi formatado no padrão MIME e seu conteúdo indica qual a versão do MIME utilizada (RFC 1521).
“Importance:” Indica o grau de importância da mensagem (High, Normal e Low). É preenchido na composição e não interfere na velocidade com que a mensagem é transmitida.
“Content-Type:” Indica o formato do conteúdo (RFC 1049).
“Return-Path:” Utilizado na entrega final como o atributo do envelope MAIL FROM.
No próximo post falaremos sobre campos úteis para determinação de autoria.
Até lá.