Cette fois-ci, j'ai préféré ne pas évaluer l'efficience de solutions de sécurité à l'instant T où la menace atteignait le poste, mais quelques temps après...
Voici le courriel, assez bien fait d'ailleurs :
Thunderbird 64 (Miramar) avait alerté sur un risque de "scam" pour ce courriel.
Mais que donnent les protections pour l'utilisateur, niveau navigateur, 6 jours donc après avoir reçu le courriel ?
- Internet Explorer 9 : OK, avertissement
- Opéra 11.50 : OK, avertissement
- Netcraft : OK, avertissement
- Firefox 5 : aucune alerte
- Safari 5 : aucune alerte
- Chrome 13 : aucune alerte
- WOT : aucune alerte
- Webutation : aucune alerte...
Pour Safari :
Pour Chrome :
Et le plus intéressant, FIrefox 64 bits 4.0b12pre (avec WOT, Webutation, Netcraft...)
Webutation, encore plus explicite ("tout va bien") :
Heureusement, Netcraft réagit :
------------------------------------------------------------------
Et maintenant, si je tente de faire marcher la duperie jusqu'au bout ?
Remplissons le formulaire, adresse email et mot de passe, et validons...
Firebug indique clairement où part le mot de passe :
La page qui suit l'envoi frauduleux des identifiants utilisateur, est assez intéressante !
Serait-ce lié à la campagne actuelle de fraude à la fausse facture ?
Au niveau réseau, le traffic est lui-aussi assez révélateur :
Diverses requêtes vers maghegy.com n'aboutissnet pas... pourtant le kit de hameçonnage semble marcher globalement.
Il est notable que l'image avec tous les logso bancaires (certainement pour rassurer l'utilisateur, comme de "faux partenariats" : http://nsa25.casimages.com/img/2011/04/09//110409011725248635.jpg :
Le serveur hébergeant cette image est chez OVH...
D'autres éléments (notamment images) sont récupérées ailleurs que chez Orange.fr... exemple pour le bonhomme orange : http://img.woopic.com/common/g8/img/new_user_welcome.gif
Jouons le jeu jusqu'au bout... je remplis donc le formulaire. Etrange, il m'est demandé à la fois mon numéro de carte ET mon numéro de compte !
On notera que le formulaire est tellement bien fait que je ne peux lui rentrer des numéros complètement fantaisistes :
En fait, c'est le vérificateur de Luhn qui est appliqué... (cf. http://www.thetaoofmakingmoney.com/2007/04/12/324.html)
Donc pour leurer le contrôle, je prends l'exemple 4552 7204 1234 5677.
Finalement, quand le formulaire est accepté, un clic sur "Valider" envoie une requête POST toujours vers le même domaine :
Les données du formulaire sont bien visibles, et c'est la page "xeon.php" qui récupère le tout.
De manière assez classique, mais déjà éprouvée, cette requête POST est suivie d'une redirection vers le VRAI site Orange (id.orange.fr).
Et enfin, si l'on tente d'accéder à la racine de l'environnement de hameçonnage, la réponse HTML du serveur est étudiée pour renvoyer une vraie-fausse page Webmail Orange :
<html> <script type="text/javascript"> echo = "logins2.html?-http/webmail1e.orange.fr/webmail/fr_FR/inbox.html?w=0&FromSubmit\
=true?rpsnv=11&ct=1258553363&rver=6.0.5285.0&wp=MBI&wreply=http:%2F" self.location.replace(echo); window.location = echo; </script> </html>
------------------------------------------------------------------------------------------------------
Et à propos du serveur, me direz-vous ?
Un vieux réflexe m'amène à tenter un nmap -O --osscan-guess. Le résultat est plutôt intriguant :
Starting Nmap 5.51 ( http://nmap.org ) at 2011-08-20 00:01 Paris, Madrid (heure dÆÚtÚ)
Nmap scan report for maghegy.com (46.252.201.1)
Host is up (0.040s latency).
rDNS record for 46.252.201.1: n1nlhg286c1286.shr.prod.ams1.secureserver.net
Not shown: 986 filtered ports
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
80/tcp open http
443/tcp open https
50000/tcp closed ibm-db2
50001/tcp closed unknown
50002/tcp closed iiimsf
50003/tcp closed unknown
50006/tcp closed unknown
50300/tcp closed unknown
50389/tcp closed unknown
50500/tcp closed unknown
50636/tcp closed unknown
50800/tcp closed unknown
Device type: general purpose|WAP|firewall|phone|printer
Running (JUST GUESSING): OpenBSD 4.X (95%), Linux 2.6.X|2.4.X (91%), Linksys Linux 2.4.X (91%), HID embedded (90%), Nokia Linux 2.6.X (89%), Netgear embedded (88%), Asus Linux 2.6.X (87%), Epson embedded (87%)
Aggressive OS guesses: OpenBSD 4.3 (95%), Linux 2.6.18-8.el5 (Red Hat Enterprise Linux 5) (91%), Linux 2.6.20 (91%), Linux 2.6.20 (Ubuntu, x86_64) (91%), Linux 2.6.22 (91%), Linux 2.6.22 (Ubuntu, x86) (91%), OpenWrt White Russian 0.9 (Linux 2.4.30) (91%), OpenWrt 0.9 - 7.09 (Linux 2.4.30 - 2.4.34) (91%), OpenWrt Kamikaze 7.09 (Linux 2.6.22) (91%), HID EdgePlus Solo ES400 firewall (90%)
No exact OS matches for host (test conditions non-ideal).
OS detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 17.80 seconds
BSD, linux, point d'accès WiFI ?... le tout hébergé sur un prod.ams1.secureserver.net ? késako... (WTH? ;) certains comprendront).
Et toujours lancé sur Nmap, la détection de services me fait hausser les sourcils :
PORT STATE SERVICE VERSION
21/tcp open ftp Pure-FTPd
22/tcp open ssh OpenSSH 5.1 (protocol 2.0)
80/tcp open http Apache httpd
443/tcp open http Apache httpd
OpenSSH 5.1 ? même sur des machines dites sécurisées, je ne le croise presque jamais...!
Du coup, je vais tenter une identification par signature : HTTPrecon.
Bingo, Apache 2.2.8 !
J'ai vu pire, mais c'est déjà une première porte d'entrée suceptible d'avoir compromis le serveur. Nessus tourne...
