Les logiciels malveillants, quel qu'en soit l'objectif, doivent d'abord arriver sur la plate-forme visée. Il n'y a, fort heureusement, pas de génération spontanée en la matière. Les vecteurs sont multiples, le courrier électronique en étant un. Nous avons ainsi reçu un message, contenant un lien vers un document PDF dont l'innocence s'est révélée tout à fait sujette à caution.

Amorçage

L'armorce est très classique : le message électronique est une confirmation d'achat (ici semblant provenir de la société Apple). Thunderbird signale qu'il considère le dit message comme suspect.

 

L'idée est que le destinataire, voyant la confirmation d'un achat qu'il n'a pas réalisé, cherchera certainement à en savoir plus afin de pouvoir procéder à l'annulation de la dite commande.

L'examen du corps du message ne laisse guère de doute quant à l'origine frauduleuse. Les en-têtes montrent que le message n'est pas parti d'un serveur contrôlé par Apple (mais il n'est pas toujours facile de savoir quelle est l'architecture d'émission d'une société, donc ce contrôle peut provoquer des faux négatifs)

Sans aucune surprise, l'URL visible dans le message n'est pas celle sur laquelle le navigateur sera envoyé.

Domaine utilisé

Le domaine associé à l'URL sur laquelle le navigateur va aller est de création très récente (moins de trois jours), ce qui ne peut que renforcer, si besoin était, l'impression que la situation n'est pas tout à fait normale.

Contenu de l'URL

Si l'on se connecte sur l'URL concernée, une redirection nous renvoie sur le même serveur afin de récupérer une archive compressée.

$ wget -S http://zabizabi.hamzajolina.net/14478555/
--2014-02-03 12:36:57--  http://zabizabi.hamzajolina.net/14478555/
Proxy request sent, awaiting response...
  HTTP/1.1 302 Moved Temporarily
  Date: Mon, 03 Feb 2014 11:38:32 GMT
  Server: Apache/2.2.15 (CentOS)
  X-Powered-By: PHP/5.3.3
  Location: http://zabizabi.hamzajolina.net/14478555/47888888.zip
  Content-Length: 0
  Content-Type: text/html; charset=UTF-8
  Connection: keep-alive
Location: http://zabizabi.hamzajolina.net/14478555/47888888.zip [following]
--2014-02-03 12:36:57--  http://zabizabi.hamzajolina.net/14478555/47888888.zip
  HTTP/1.1 200 OK
  Date: Mon, 03 Feb 2014 11:38:32 GMT
  Server: Apache/2.2.15 (CentOS)
  Last-Modified: Mon, 03 Feb 2014 02:24:12 GMT
  ETag: "3da68f-57d79-4f17738220b00"
  Accept-Ranges: bytes
  Content-Length: 359801
  Content-Type: application/zip
  Connection: keep-alive
Length: 359801 (351K) [application/zip]
Saving to: ‘index.html’
2014-02-03 12:36:58 (1.08 MB/s) - ‘index.html’ saved [359801/359801]


Le document récupéré contient un exécutable Windows

$ unzip -t index.html
Archive:  index.html
    testing: 47888888.exe             OK
No errors detected in compressed data of index.html.
$ unzip index.html
Archive:  index.html
  inflating: 47888888.exe           
$ file 47888888.exe
47888888.exe: PE32 executable (GUI) Intel 80386 Mono/.Net assembly, for MS Windows


Cet exécutable n'est pas encore identifié comme certainement malveillent (score 5/51 seulement sur VirusTotal). Il n'a été signalé que très récemment, ce qui explique le faible score.

Toutefois, les quelques détections ne laissent pas de doute sur la malveillance de l'exécutable en question.

 

 

Il est facile, sans recourir à des stratagèmes particulièrement alambiqués, d'amener un utilisateur un tantinet naïf à télécharger un exécutable malveillant. Peut-on empêcher cela ?

Le message originel passera probablement la majorité des outils anti-spam et les éventuelles anti-virus configurés sur la plate-forme de messagerie. Ensuite, c'est un téléchargement Web qui va faire entrer le logiciel malveillant sur le système d'informations.

On peut utiliser un anti-virus sur le relais de navigation Web, sous réserve évidemment qu'un tel relais existe et qu'il soit le seul système autorisé à se connecter sur des sites Web. Vu le faible taux de détection de VirusTotal dans notre exemple, la probabilité que l'outil malveillant passe ce filtre est loin d'être négligeable. Malgré tout, cela donnera une trace du téléchargement (URL d'origine, poste ayant procédé au téléchargement), et donc un peu plus de chances de remonter à la primo-infection.

Et après ?

La sensiblisation des utilisateurs a ses limites, que l'on connaît bien. Cela ne la rend pas inutile pour autant. L'impossibilité pour l'utilisateur d'installer des programmes sur sa machine améliorera aussi la situation.

Si l'on cumule ces différents éléments, qui chacun unitairement n'est pas suffisant, la situation s'améliore - sans arriver à être parfaite. C'est pourquoi il faut travailler sur la résilience du système d'informations : intégrer le fait que l'incident arrivera, et se donner les moyens de le détecter, rapidement de préférence. Aussi inconfortable que ce soit, c'est largement préférable à la conviction trop souvent rencontrée que le système est impénétrable