Home Forense em Geral Análise de Evidências de Uso de USB no Linux

Análise de Evidências de Uso de USB no Linux

por - TI Forense

Neste artigo vou descrever em quais áreas é possível detectar o uso de dispositivos de armazenamento USB em um sistema operacional Linux. No Windows já existem inúmeros software’s forenses que permitem com alguns cliques apontar tais evidências, no Linux é um pouco diferente mas nada muito complexo.

Vamos ver abaixo as opções que temos para tentar identificar se foram utilizados dispositivos USB em Linux.

Nossa primeira opção é o DMESG ou “display message” esse utilitário imprime o buffer das mensagens do kernel. E geralmente são mensagens de drivers utilizados no sistema operacional sendo periciado. Vale notar que o dmesg é um buffer de anel que tem um limite fixo e quando este é utilizado ele apaga mensagens mais antigas para preencher com as mensagens mais novas.

$ dmesg | grep -i usb
[165095.376615] usb 1-2: new high-speed USB device number 9 using xhci_hcd
[165095.527846] usb 1-2: New USB device found, idVendor=0930, idProduct=6544
[165095.527857] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[165095.527864] usb 1-2: Product: DataTraveler 2.0
[165095.527873] usb 1-2: Manufacturer: Kingston
[165095.527879] usb 1-2: SerialNumber: 60A44C3FAC18CEB0B967268D
[165095.599309] usb-storage 1-2:1.0: USB Mass Storage device detected
[165095.599524] scsi host3: usb-storage 1-2:1.0
[165095.599753] usbcore: registered new interface driver usb-storage
[165095.603057] usbcore: registered new interface driver uas
[165268.452362] usb 1-2: USB disconnect, device number 9

No comando acima já podemos evidenciar que houve a utilização de pelo menos 1 dispositivo de armazenamento USB sendo ele da marca Kingston Modelo DataTraveler 2.0 e com Serial Number: 60A44C3FAC18CEB0B967268D.

Importante notar que a data e hora do DMESG podem não ser precisas, principalmente se o sistema hibernou. Pode-se utilizar o dmesg com a opção ” -T ” para mostrar em formato humano a data e hora. Mas  não muda o possível erro de hora. O ideal para efeitos de apuração de data e hora e utilizar logs do sistema.

$ grep -i usb /var/log/kern.log
Nov  1 09:55:18 jupiter kernel: [165095.376615] usb 1-2: new high-speed USB device number 9 using xhci_hcd
Nov  1 09:55:18 jupiter kernel: [165095.527846] usb 1-2: New USB device found, idVendor=0930, idProduct=6544
Nov  1 09:55:18 jupiter kernel: [165095.527857] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Nov  1 09:55:18 jupiter kernel: [165095.527864] usb 1-2: Product: DataTraveler 2.0
Nov  1 09:55:18 jupiter kernel: [165095.527873] usb 1-2: Manufacturer: Kingston
Nov  1 09:55:18 jupiter kernel: [165095.527879] usb 1-2: SerialNumber: 60A44C3FAC18CEB0B967268D
Nov  1 09:55:18 jupiter kernel: [165095.599309] usb-storage 1-2:1.0: USB Mass Storage device detected
Nov  1 09:55:18 jupiter kernel: [165095.599524] scsi host3: usb-storage 1-2:1.0
Nov  1 09:55:18 jupiter kernel: [165095.599753] usbcore: registered new interface driver usb-storage
Nov  1 09:55:18 jupiter kernel: [165095.603057] usbcore: registered new interface driver uas
Nov  1 09:58:11 jupiter kernel: [165268.452362] usb 1-2: USB disconnect, device number 9

O mesmo LOG pode ser apurado em /var/log/kern.log com uma data confiável do sistema. Obviamente é necessário validar o timestamp do sistema operacional, bem como se houve alterações de data/hora ou fuso-horário.

Vamos analisar o seguinte comando:

$ tail -f /var/log/syslog

O comando acima fica “lendo” em tempo real o syslog a medida em que ele é escrito, após começar o comando eu insere um pendrive no meu notebook e o resultado foi o registro do LOG que podemos ver abaixo. Existem uma série de informações valiosas do ponto de vista forense que permitem uma análise do que pode ter ocorrido nesta hora.

Nov  1 11:06:03 jupiter kernel: [169340.267284] scsi 3:0:0:0: Direct-Access     Kingston DataTraveler 2.0 1.00 PQ: 0 ANSI: 4
Nov  1 11:06:03 jupiter kernel: [169340.268534] sd 3:0:0:0: Attached scsi generic sg1 type 0
Nov  1 11:06:03 jupiter kernel: [169340.269384] sd 3:0:0:0: [sdb] 30310400 512-byte logical blocks: (15.5 GB/14.5 GiB)
Nov  1 11:06:03 jupiter kernel: [169340.269672] sd 3:0:0:0: [sdb] Write Protect is off
Nov  1 11:06:03 jupiter kernel: [169340.269682] sd 3:0:0:0: [sdb] Mode Sense: 45 00 00 00
Nov  1 11:06:03 jupiter kernel: [169340.269953] sd 3:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
Nov  1 11:06:03 jupiter kernel: [169340.275206]  sdb:
Nov  1 11:06:03 jupiter kernel: [169340.276449] sd 3:0:0:0: [sdb] Attached SCSI removable disk
Nov  1 11:06:03 jupiter ntfs-3g[24423]: Version 2017.3.23 integrated FUSE 28
Nov  1 11:06:03 jupiter ntfs-3g[24423]: Mounted /dev/sdb (Read-Write, label "", NTFS 3.1)
Nov  1 11:06:03 jupiter ntfs-3g[24423]: Cmdline options: rw,nodev,nosuid,uid=1000,gid=1000,uhelper=udisks2
Nov  1 11:06:03 jupiter ntfs-3g[24423]: Mount options: rw,nodev,nosuid,uhelper=udisks2,allow_other,nonempty,relatime,default_permissions,fsname=/dev/sdb,blkdev,blksize=4096
Nov  1 11:06:03 jupiter ntfs-3g[24423]: Global ownership and permissions enforced, configuration type 7
Nov  1 11:06:03 jupiter systemd[1]: Started Clean the /media/devzero/64F27C534DC74379 mount point.
Nov  1 11:06:03 jupiter udisksd[787]: Mounted /dev/sdb at /media/devzero/64F27C534DC74379 on behalf of uid 1000

Outro procedimento que fiz lendo os LOG’s foi copiar um arquivo, via interface gráfica usando o NEMO, do HD para o pendrive. Nada em LOGs ordinários do sistema foi registrado.

devzero@jupiter:~$ cp COMANDOS_mysql /media/devzero/64F27C534DC74379/
devzero@jupiter:~$

Caso a cópia tenha sido feita via linha de comando podemos recorrer ao history daquele usuário.

devzero@jupiter:~$  
  172  cp COMANDOS_mysql /media/devzero/64F27C534DC74379/
  173  clear
  174  history 
devzero@jupiter:~$

A saída do comando acima permite mostrar que o comando gravado na linha 172 foi um copy de arquivo para um dispositivo de armazenamento externo cujo ponto de montagem pode ser comparado com o que está presente no syslog.

Para ter controle de arquivos sendo lidos, escritos e copiados no Linux com precisão é ideal que estes arquivos fiquem em um Servidor de Arquivos como o SAMBA, aonde podemos ativar o LOG Audit e ter o rastro da forma como estes arquivos estão sendo manuseados.

Veja abaixo o exemplo de um AUDIT do SAMBA:

Nov 18 15:21:15 m5 smbd_audit: joao|192.168.1.23|arquivos|opendir|ok|.
Nov 18 15:21:29 m5 smbd_audit: joao|192.168.1.23|arquivos|open|ok|r|addr.txt
Nov 18 15:21:34 m5 smbd_audit: joao|192.168.1.23|arquivos|mkdir|ok|trabalho
Nov 18 15:21:36 m5 smbd_audit: joao|192.168.1.23|arquivos|opendir|ok|trabalho
Nov 18 15:21:43 m5 smbd_audit: joao|192.168.1.23|arquivos|open|ok|w|trabalho/Samba.sxw
Nov 18 15:21:44 m5 smbd_audit: joao|192.168.1.23|arquivos|open|ok|w|trabalho/foto.jpg

Este exemplo de AUDIT foi retirado de: https://www.hardware.com.br/tutoriais/samba-configuracao-avancada/pagina7.html

Uma opção para quem não usa SAMBA e deseja saber mapear os movimentos de arquivos em estações de trabalho Windows é usar o AUDITD que permite logar a escrita, leitura e acesso em sistemas de arquivos Linux.

Exemplo:

Instalar em Debian-Like
# apt-get install auditd

Monitorar uma pasta específica
# auditctl -w /media/ -p war -k MEDIA

Ler o LOG do AUDITD
# ausearch -k MEDIA

 

Uma outra opção de monitoração de sistemas de arquivos em Linux é o INOTIFY

Instalar em Debian-Like com:

# apt-get install inotify-tools
Exemplo:
# sudo inotifywait -mr --timefmt '%H:%M' --format '%T %w %e %f' /media/

Resultado:
16:30 /media/ OPEN,ISDIR 
16:30 /media/ ACCESS,ISDIR 
16:30 /media/ CLOSE_NOWRITE,CLOSE,ISDIR 
16:30 /media/ OPEN wp-config.php
16:30 /media/ CLOSE_NOWRITE,CLOSE wp-config.php
16:30 /media/ OPEN wp-config.php
16:30 /media/ CREATE wp-config.php.2
16:30 /media/ OPEN wp-config.php.2
16:30 /media/ ACCESS wp-config.php
16:30 /media/ MODIFY wp-config.php.2
16:30 /media/ CLOSE_WRITE,CLOSE wp-config.php.2
16:30 /media/ CLOSE_NOWRITE,CLOSE wp-config.php
16:30 /media/ OPEN wp-config.php.2
16:30 /media/ ACCESS wp-config.php.2
16:30 /media/ CLOSE_NOWRITE,CLOSE wp-config.php.2
16:30 /media/ OPEN wp-config.php.2
16:30 /media/ ACCESS wp-config.php.2
16:30 /media/ CLOSE_NOWRITE,CLOSE wp-config.php.2
16:30 /media/ OPEN,ISDIR 
16:30 /media/ ACCESS,ISDIR 
16:30 /media/ ACCESS,ISDIR 
16:30 /media/ CLOSE_NOWRITE,CLOSE,ISDIR 
16:30 /media/ OPEN,ISDIR 
16:30 /media/ ACCESS,ISDIR 
16:30 /media/ CLOSE_NOWRITE,CLOSE,ISDIR 
16:30 /media/ OPEN,ISDIR 
16:30 /media/ ACCESS,ISDIR 
16:30 /media/ CLOSE_NOWRITE,CLOSE,ISDIR 
16:31 /media/ DELETE wp-config.php

Conhece outras maneiras de registrar movimentações USB em sistema Linux ? Comente!

Artigos Similares

Deixe seu comentário