Attaques sur la mémoire vive; antiphishing chez firefox

La RAM est un vecteur de divulgation d'information intéressant. L'ensemble des opérations effectuées par le système est enregistrée par celle-ci, aussi est elle un bon candidat pour lire des données. Que ce soit des documents, des clés de chiffrement, des clés de sessions ou tout autre information. Je citerai entre autre l'attaque Cold-boot, ingénieuse et spectaculaire qui permet de retrouver des clés de chiffrement de disque durs.

Je propose un article sur une étude rapide de la mémoire vive d'un système linux (le mien, en l'occurence). Cette étude se base en deux étapes, la première consiste sur le meilleur moyen d'accéder à cette mémoire, la seconde sur un cas concret d'analyse de données nous menant sur les mécanismes d'antiphishing de firefox 2.

1/
Comment accéder à la RAM d'une machine.
La mémoire sous linux est directement accessible via /dev/mem. C'est un fichier spécial de type caractère, le tout premier:

$ ls -l /dev/mem
crw-r----- 1 root kmem 1, 1 2008-12-31 17:31 /dev/mem

Ce fichier représente la mémoire complète physique du système. Un autre fichier important est le /proc/iomem indiquant l'état du découpage de la mémoire:

$ cat /proc/iomem
00000000-0000ffff : reserved
00010000-0009ffff : System RAM
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000f0000-000fffff : reserved
  000f0000-000fffff : System ROM
00100000-07fbffff : System RAM
  00100000-00432e07 : Kernel code
  00432e08-00586313 : Kernel data
  005d3000-005fc51b : Kernel bss
01101000-01101fff : Local APIC
efffb000-efffb0ff : 0000:00:14.0
  efffb000-efffb0ff : 8139too
efffc000-efffc0ff : 0000:00:13.0
  efffc000-efffc0ff : 8139too
efffd000-efffd0ff : 0000:00:12.0
  efffd000-efffd0ff : 8139too
ffff0000-ffffffff : reserved

On peut voir que mon système possède 07fbffff octets de RAM, soit 128Mo, ce qui est effectivement le cas.

Se pose maintenant la question d'accès à ces données. La première méthode consiste à passer root puis à dumper le fichier périphérique /dev/mem dans un fichier local et à l'analyser. Cette méthode permet d'obtenir une image statique de la mémoire pour analyse future.
Les outils classiques d'analyse de contenu sont utilisables, comme strings suivi de grep pour rechercher des motifs textes, ou des outils comme ceux de cgsecurity (photorec et tesdisk).

A titre d'exemple encore une fois, sur mes 128Mo de RAM analysées, photorec me trouve 283 fichiers, dont plusieurs scripts shells et programmes elf ( ce qui semble logique).

Un seconde méthode permettant d'analyser la RAM, beaucoup plus longue consiste à utiliser hexdump. En effet, hexdump -C /dev/mem fournit le contenu de la RAM sous forme hexadécimale, bien plus lisible.

C'est d'ailleurs en consultant ce fichier dump hexa que j'ai découvert une série de messages uggc:// ce qui m'a mis intrigué, du fait de a ressemblance avec http:// (aux caractères près). La deuxième partie de ce post donne l'explication de ces URL encodées.

2/
Pour ceux qui ne connaisse pas le rot13, uggc correspond à un décalage de 13 lettres dans l'alphabet du mot http://. Or donc, je trouvai dans la RAM d'une machine une grande quantité de lien http encodés en rot13.
De plus, les domaines considérés ressemblaient tous à des domaines de phishing, de faux sites bancaires ou autres sites à la légalité douteuse. Enfin, la majorité des sites étaient fermés.

Une analyse de la machine montra qu'elle n'était pas infectée, ni vérolée, néanmoins, la provenance de ces URL était intriguante. Lors du dump de la mémoire rien de spécifique n'était lancé sur cette machine, si ce n'était firefox v2.

Et firefox propose une extension appelée "safe browsing".

Cette extension pour firefox v2 est un service proposé par google http://sb.google.com/safebrowsing/update qui donne les dernières mises à jour d'une liste de sites web contrefaits, de malfaçons, ou de site référencés comme phisher. La syntaxe est la suivante: http://sb.google.com/safebrowsing/update?version=goog-white-domain:1:1 pour avoir la liste des domaines whitelistés par google depuis le numéro 1.
Firefox2 télécharge et stocke cette liste de sites dans le fichier urlclassifier2.sqlite, situé dans le profil de l'user. Ce profil est effectivement (comme son nom l'indique) une base de données sqlite:

$ sqlite3 urlclassifier2.sqlite
SQLite version 3.5.6
Enter ".help" for instructions
sqlite> .schema
CREATE TABLE 'goog_black_enchash' (key TEXT PRIMARY KEY, value TEXT);
CREATE TABLE 'goog_black_url' (key TEXT PRIMARY KEY, value TEXT);
CREATE TABLE 'goog_white_domain' (key TEXT PRIMARY KEY, value TEXT);
CREATE TABLE 'goog_white_url' (key TEXT PRIMARY KEY, value TEXT);
sqlite> select key from goog_white_domain limit 3;
02onapbec.pbz
163.pbz/cubgbf
1fg-naancbyvf.pbz
sqlite> .quit

Nous retrouvons bien la liste des URL ROT13-encodées.
J'ai de fait ma réponse sur la raison d'être de trouver dans la mémoire d'une machine une quantité extrêmement grande d'URL encodées en ROT13.

Suite a ces information, une question reste: pourquoi donc ces URL sont-elles codées en ROT13?
Une rapide recherche à l'aide de google codesearch amène à un fichier source appelé nsUrlClassifierDBService.cpp, dont un commentaire attire l'attention:

// We use ROT13 versions of keys to avoid antivirus utilities from
// flagging us as a virus.
nsCString keyROT13(key);
Rot13Line(keyROT13);

Ainsi, firefox2 utilise une simple rotation de 13 caractères pour que leurs listes d'URL ne se fassent pas détecter par des antivirus, ce qui semble surprenant de premier abord.

Firefox 2 n'est plus vraiment utilisé de nos jours. Qu'en est il de firefox 3?

Firefox 3 utilise la nouvelle version de la spec google disponible à l'adresse http://code.google.com/p/google-safe-browsing/wiki/Protocolv2Spec
Ainsi, firefox utilise un fichier urlclassifier3.sqlite et un fichier de clé urlclassifier3key.txt. Cette méthode semble plus sûre pour éviter de se faire détecter par des antivirus. Seul les hashs sont calculés et comparés. Les détails de l'implémentation antiphishing sont présentés chez mozilla.


CONCLUSION/
Une simple analyse de RAM nous a emmenés très loin de la recherche initiale, sur les mécanismes d'antiphishing de firefox; ceci restant intéressant, j'ai axé la seconde partie de l'article sur ce point.

Cette analyse de RAM apprend beaucoup de choses sur le fonctionnement de la machine, notamment sur les caches utilisés. J'ai été surpris de retrouver certains documents toujours en RAM quelques jours après utilisation.
Pour éviter les accès à cette RAM, il faudrait que je me penche sans doute sur les outils existants permettant soit de flusher l'intégralité des caches RAM, ce qui pourrait être improductif, soit de flusher les caches RAM d'une application particulière lors de sa fermeture.