Une campagne de spear-phishing

Une campagne de spear-phishing – semble-t-il très ciblée – a été perpétrée à l’encontre de certains fonctionnaires du Ministère de l’économie, des finances et de l’industrie. Le spear-phishing est un phishing ciblé, où, contrairement à une campagne de phishing traditionnel, un travail de renseignement est fait en amont afin de connaitre sa victime, mais aussi ses liens avec d’autres acteurs de l’entité ciblée. Elle se traduit au final par l’envoi de mail(s) possédant(s) une pièce jointe ou un lien vers une page web exploitant une vulnérabilité dans le navigateur ou un des plugins du navigateur de la victime. Les campagnes de spear-phishing se décomposent en deux phases distinctes :

1. Le Renseignement : La partie la plus complexe. Il faut connaitre sa victime, dont ses liens avec d’autres acteurs du système d’information mais également son équipement logiciel. A ce jour, les liens peuvent facilement être découverts en cherchant un peu sur internet, surtout grâce aux réseaux sociaux et aux sites institutionnels (d’où l’utilité de Maltego). L’adresse email de la victime à laquelle on enverra une charge finale peut facilement être déduite grâce au nom et prénom de l’acteur. C’est toujours le même pattern du type nom.prenom ou nprenom ou prenom.nom etc. Une liste d’adresses email valides peut ainsi être facilement constituée automatiquement à l’aide d’un seul échantillon récupéré sur un site institutionnel ou dans un document administratif.

L’équipement logiciel de la victime pourra être soustrait grâce à la visite au préalable d’un des acteurs du Système d’Information sur un site internet piégé. Un petit bout de code Javascript permettra de récupérer les versions des différents plugins installés, du navigateur et du système d’exploitation. Pour les logiciels de bureautique (tels qu’MS Office), une simple visite sur le site institutionnel permettra au(x) pirates(s) de connaitre, à l’aide des méta données des documents publiés, le type et la version des logiciels utilisés (Foca, Metagoofil).

2. L’attaque : L’attaque prendra donc la forme d’un email piégé usurpant l’identité de l’un ou de plusieurs collaborateurs de la victime. Du fait des faiblesses du protocole d’envoi de mail SMTP, il est très facile d’envoyer un mail usurpant l’identité d’une personne quelconque. Cet email conduira la victime – à l’aide d’un prétexte quelconque – à ouvrir une pièce jointe piégée (un fichier PDF semble-t-il dans le cadre de l’attaque de Bercy) ou à parcourir un lien contenu dans l’email.

Une fois ce lien ou cette pièce jointe ouverte, une faille logicielle sera utilisée afin de faire exécuter du code arbitraire à distance sur l’ordinateur de la victime. Aujourd’hui, les shellcodes de papa ne sont plus utilisés. Dans le cadre de telles attaques, les shellcodes permettent de télécharger et d’exécuter un binaire (le malware). Une fois installé sur le client (l’ordinateur de la victime), le malware essayera d’être furtif afin de ne pas se faire voir par l’analyse heuristique des antivirus, mais également persistant, afin d’être exécuté à chaque redémarrage de l’ordinateur de la victime. Enfin, il enverra un petit message à un serveur sur internet (contournant le NAT en passant) pour dire « Hep, j’suis installé, j’attends tes commandes bro :D ! »

Afin d’éviter un piège, la première règle est d’en connaitre l’existence.

Les attaques de spear-phishing sont aujourd’hui celles qui ont le plus de chances de réussir en remote (à distance). De plus, même s’il existe des parades afin de contrer ce type d’attaque (comparaison entre le domaine auquel est rattachée l’adresse email usurpée et le serveur SMTP ayant envoyé l’email, créations de profils « honey-pots » ayant des adresses mail institutionnelles « honey pot », utilisation de signatures numériques) ces mesures sont loin d’être démocratisées, tant dans le public que dans le privé.

Nous n’avons aucune information sur le malware employé, si c’est du « home made » ou quelque chose que l’on trouve un peu partout sur internet (comme GhostRAT dans le cadre de GhostNet). Toujours est-il que là encore, la sécurité antivirale est un échec. La seule chose qui a fuité est la communication du malware par HTTP vers l’extérieur [NOTE 1]. Ce type de communication est aujourd’hui très démocratisé par les malwares car cela permet facilement de s’évader du réseau, tout en contournant les règles des firewalls laissant sortir les flux HTTP. Les NIDS dans ce cas ne jouent plus aucun rôle – ils fonctionnent principalement sur la base de signatures ou sur des données heuristiques (pour les scans de ports, le DNS tunneling, malwares « connus » etc.). Sachant que le flux employé était un flux « légitime » et n’ayant pas de signatures préalables, le malware pouvait communiquer avec l’extérieur tranquillement sans se faire voir.

Quelle portée de l’attaque contre Bercy ?

Jusqu’à présent, aucune information n’a fuité sur la portée réelle de l’attaque, notamment sur sa complexité. Une attaque de spear-phishing, bien que semblant complexe, est simple à mettre en oeuvre. Pour connaitre la réelle complexité de l’attaque, il nous faut savoir si les pirates informatiques ont pivoté sur d’autres postes/serveurs composant le Système d’Information de Bercy à partir « de bases avancées » composées des postes clients piratés lors de l’attaque de spear-phishing. Là, on pourra dire « woot, woot, woot » car pivoter sur un réseau est une tâche relativement complexe de l’extérieur, surtout sans se faire catcher par les NIDS.

De plus, certains indices peuvent nous amener à penser qu’un 0day sur Adobe Acrobat reader a été utilisé, même si le sujet, repris par certains médias [NOTE 2], reste très nébuleux : ne sachant pas s’ils parlaient du malware non reconnu par l’antivirus du Ministère de l’économie, des finances et de l’industrie ou de la faille utilisée permettant l’exécution de code arbitraire à distance.

Qui est derrière cette campagne ?

Les médias ne nous apportent rien sur l’origine de l’attaque, seul un indice est sorti : le(s) malware(s) communiquai(en)t avec des serveurs présents en chine. OK. Wahou, ça c’est de l’information. Enfin, il est aujourd’hui facile de mettre en oeuvre un système de proxying-international-de-la-mort-qui-tue afin de cacher la provenance d’une attaque. (Shodan, my friend, si tu m’entends ? <3)

Ma petite idée s’oriente tout de même vers la superbe PLA chinoise (désolé pour l’humour, voir : 人民解放军) et ses supers-hackers-qui-font-peur. Ceci pour la simple et bonne raison que des attaques d’espionnage de grande envergure utilisant cette technique (GhostNet & Aurora) ont été imputées aux chinois et à certaines de leurs universités. Cependant, seule une analyse par reverse engineering du malware et de(s) l’exploit(s) utilisé(s), mais aussi une coopération internationale avec la Chine (LOL) et le Canada (qui a été victime d’une campagne de spear-phishing similaire) pourra permettre d’y voir plus clair.

D’autres voix s’orientent vers les Anonymous ou un cyber-altermodialisme, là, je dis « AH AH » et vous orriente vers mon article sur la « cyberguerre » pour mieux comprendre ma réaction.

Quelques leçons à retenir

Bref, je ne vais pas faire dans la « conclusion kévin » simplifiant la vie à beaucoup de personnes du genre « aucun système n’est inviolable *FEAR* ». Non non, nous allons aller plus loin. Le premier enseignement à tirer de cette attaque c’est que les systèmes d’information sont encore trop parlants sur leurs équipements. Une simple désactivation du Javascript et une réécriture de l’user-agent à la volée par un proxy intermédiaire peut permettre d’éviter bien des soucis. Cependant, on ne vit pas au pays des bisousnours : ce type de protection est difficilement portable sur un SI composé de milliers d’hôtes[NOTE 3] ayant des besoins de compatibilité logicielle (qui a parlé des intranets développés pour IE6 ?).

Deuxième leçon : Encore beaucoup trop de SI ne sont pas équipés de solutions logicielles contre le spear-phishing telles que la mise en place d’un système de PKI (difficile à garder à jour) ou une vérification de l’appartenance d’une adresse email au domaine auquel est rattaché le serveur d’envoi. Toutefois, des solutions existent, tant open-source que propriétaires rattachées aux serveurs mail.

Troisième leçon (pour les rageux) : On ne peut pas jeter la pierre sur les équipes de l’ANSSI ou de la DCRI. Les mesures qui ont été prises suite à la découverte de l’attaque ont été appropriées à l’envergure de cette dernière. Ces dernières ont d’ailleurs – semble-t-il – envoyé de fausses informations aux serveurs de contrôles, permettant de noyer les vraies informations dans de fausses informations et ça, c’est loin d’être con. Enfin, la discrétion de cette opération est à applaudir, sachant que la découverte de l’attaque remonte à quelques mois. Cela prouve une réelle intégrité de nos services de renseignement.

Cette attaque, une opportunité pour la France ?

Cette attaque, tout en ayant démontré encore une fois la vulnérabilité des Systèmes d’Information français, peut être une véritable opportunité pour la France. La prise de conscience dans les hautes sphères du gouvernement de la vulnérabilité du système va permettre de remuer un peu le secteur, avec la mise en place de VRAIES mesures rapidement face à ce type d’attaques. Enfin, je parlerai de ce point là dans mon deuxième article consacré à la « cyber-guerre » (un mot qui n’est pas approprié pour ce genre d’attaque, on parlera plus de cyber-espionnage ou de campagne espionnage), portant pour la prochaine fois sur les doctrines et stratégiques à mettre en oeuvre par les Etats face aux attaques émanant du cyberespace.

Mise à jour au 08/03/2011 : Un article de l’ANSSI confirme que les assaillants ont bien utilisé un 0 day dans Adobe Acrobat Reader, d’ailleurs, un avis du CERTA a été émis début février concernant plusieurs vulnérabilités sur ce même logiciel. Ce même article confirme également un pivot sur le réseau, cependant aucune mention sur la technique utilisée est présente.

Un article du site SecurityVibes nous en apprend un peu plus. Afin d’élever leurs privilèges sur les machines – permettant de pivoter sur le(s) réseau(x), les pirates auraient utilisé des vulnérabilités dans des programmes ayant des privilèges administrateurs pendant leur exécution ou réécrit des scripts exécutés en tant que SYSTEM. Ces astuces sont vielles comme le monde mais toujours d’actualité dans beaucoup de réseaux. Elles permettent même, dans certains cas, d’élever ses privilèges verticalement sur l’Active Directory d’une l’entité. Méfiez-vous des scripts bat/vbs traînant sur les partages réseaux qui sont exécutés en tâche planifiée avec un niveau de privilèges administrateur alors que tout le monde peut les rééditer…

Enfin, il est fait allusion à la problématique des SIEM et de la remontée de certains évènements réseaux. En effet, l’attaque aurait pu être décelée peut être plus rapidement avec un système de SIEM relié à des (H/K)IDS. Restera la problématique des fameux faux positifs.

Mise à jour au 09/03/2011 : Un article d’un célèbre site internet français sur la sécurité informatique revient sur une tentative d’attaque par injection d’iframes sur le site internet de Reporters Sans Frontières, faisant beaucoup trop vite une possible liaison avec l’affaire de Bercy. Cette attaque est, contrairement à ce qui a été annoncé dans l’article, d’une toute autre mesure et ne visant pas le réseau interne de RSF. De plus, l’injection d’iframes sur le site de RSF cible les visiteurs du site et non pas l’organisation en elle-même. Le RAT diffusé par le site internet est PoisonIvy, un RAT très connu et plus maintenu par son auteur (dont son C&C est d’ailleurs faillible à un RCE).

Bien que cette attaque aie comme origine, semble-t-il, la Chine, sa très faible complexité et son amateurisme (l’utilisation de PoisonIvy) peut laisser penser à un piratage occasionnel contre les visiteurs du site internet d’RSF. Pour finir, ce n’est pas la première fois que le site internet d’RSF sert de pont à un exploit kit suite à un piratage. Il ne faut pas faire des liens entre des affaires là où il n’y en a aucun.

Mise à jour au 10/03/2011 : Selon le magazine Paris Match, la campagne de Spear Phishing serait très aboutie dans la pertinence des messages envoyés aux acteurs ciblés. Ils auraient envoyé des emails en lien à différentes réunions préparatoires au G20, ce qui peut laisser présager une taupe en interne ou une fuite d’information liée à une première attaque aboutie sur un des acteurs.

Cependant, le message indiqué dans l’article – « Vous trouverez en pièce jointe un document pour préparer la ­prochaine réunion » – est souvent utilisé dans les campagnes de Spear Phishing ou de Social Engineering à l’encontre d’entités car les réunions sont fréquentes en entreprise ou dans l’administration. Donc sans posséder plus d’informations sur ce message, nous ne pouvons pas savoir si la campagne de Spear Phishing était réellement aboutie (date/heure de la réunion, objectifs de la réunion indiqués dans le message etc.).

Mise à jour au 20/03/2011 : Quelques informations supplémentaires tirées de conférences et contacts : 1. Le malware utilisé n’a semble-t-il pas été drafté pour une attaque « one-shoot », mais était déjà existant, il a subi néanmoins quelques modifications propres à l’attaque. 2. L’ANSSI n’avait semble-t-il pas objectif de communiquer sur l’affaire. Cette affaire aurait fuité à partir de Bercy, dont les employés avaient été amenés à laisser leurs ordinateurs portables au bureau le temps d’un weekend.

Une émission de France O revient sur les attaques informationnelles avec quelques spécialistes en Intelligence Economique et cyber-criminalité. L’émission est assez bien, cependant beaucoup d’éléments techniques mis en avant sont faux et pas métrisés. (Le tout est à découvrir ici)

NOTE 1 : « On a constaté qu’un certain nombre d’informations étaient redirigées vers des sites chinois. Mais cela ne veut pas dire grand-chose » (Paris Match)

NOTE 2,3 : Dominique Lamiot : « le Cheval de Troie est arrivé via une pièce jointe PDF dans un e-mail. Il s’agit d’une faille encore non détectée par les éditeurs » [...] « Au total, 150 ordinateurs sur 170.000 postes ont été infectés » (Le nouvel Obs)

Les vacances de Noël sont passées et j’ai un scoop à vous proposer : nous sommes en 2011. Wahou. L’année 2011 rime pour moi avec l’abandon des études pour vivre de mes propres ailes et je n’ai qu’un mot à la bouche : ENFIN ! Cependant, il faut déjà finir cette licence, finir mon stage et trouver quelque chose de stable sur Paris pour l’année.

Vous l’aurez donc deviné : je fais un stage sur Paname me permettant de décompresser un peu. Bon c’est assez ric-rac point de vue argent, car je dois payer deux loyers et le train à cause de cette connerie d’alternance. De toute façon, chercher un stage en Full-sécurité aux alentours de Maubeuge revient à partir en quête du St Graal : cette ville est loin de tout. Je ne comprends pas comment on peut faire une telle formation dans une ville aussi reculée et morte économiquement. *ça, c’est dit.*

La progression des cours

En ce qui concerne les cours, ils commencent à être bon voir même très bon. Au programme, un très bon training sur Scapy de quelques jours, du reversing basique de binaires ELF sous forme de crackme sous gdb, des cours de synergologie/manipulation sous un angle théâtral et encore quelques cours de vulnérabilités « web » et physiques. Les prochaines semaines devraient être principalement consacrées aux vulnérabilités systèmes, ça risque d’être bien sympa également.

Et TinyRAT alors ?

Concernant le projet TinyRAT, ce dernier est terminé. Malheureusement nous ne sommes pas allés jusqu’où on voulait, car une partie du groupe s’est complètement désolidarisée du projet à tel point qu’on a dû le finir à deux.

Du côté client, une grande partie du code reste à faire contre la lutte heuristique mais également sur la persistance du binaire dans un environnement bien configuré (Accès au registre désactivé etc.). Le serveur de commandes quant à lui est fini et prêt à être sujet à quelques modifications futures suivant ce que voudra faire le client (Screenshots, envoi/réception de fichiers etc). Les notes finales sur le projet sont bonnes, mais le résultat aurait pu être encore mieux avec l’investissement de l’autre partie du groupe dans le projet. (Je ne vous cache pas que j’ai vraiment la haine sur ce point-là).

Les certifications

La grande question en suspens pendant les derniers épisodes était celle des certifications. Eh bien j’ai quelques nouvelles ! C’est donc de 170 à 220 euros la certification. A ce prix-là, je me suis dit qu’il était mieux d’en passer deux, CEH et ECSA. La première va surement être facile à passer, après, pour la deuxième Ich Allah, car en passer deux à la suite…

Et puis, vu que ce ce n’était pas assez de travail, j’ai décidé de me mettre en parallèle à apprendre le Chinois traditionnel sur Paris, dans le but de compliquer la chose… Sur ce, Keep update !

De w3af (mon préféré…) à Skipfish en passant par Wapiti, le petit français : les fuzzers deviennent de plus en plus évolués pour déceler une très large variété de vulnérabilités ou d’information disclosures. Cependant, les applications web sont, comme toutes applications, systémiques. De ce fait, dans une grande majorité des cas, des conditions doivent souvent être remplies afin d’accéder à certaines vulnérabilités. Ces conditions (authentifications, patterns à respecter etc.), souvent additionnelles entre elles sont très largement omises par les fuzzers, ne lisant pas, sauf dans le cadre de certains PoCs, les informations contenues dans la page (tels que les names/types des champs inputs pouvant donner pas mal d’information sur la nature des données attendues en POST/GET). Ceci aboutissant le plus généralement à de faux négatifs et donc au passage à la trappe d’un très grand nombre de vulnérabilités potentielles.

Le nombre de requêtes vers une application ciblée durant une phrase de fuzzing est aussi à ne pas négliger. Ainsi, elles se comptent en dizaines de milliers, voir, centaines de milliers pour le petit dernier Skipfish laissant une trace plus que repérable dans les logs pouvant par la suite être interprétée par un IDS/IPS.

En parlant de dispositifs ajoutés un serveur web lambda nous pouvons de plus mentionner les WAF. Ces derniers ne permettront pas de déceler une vulnérabilité même si elle est présente dernière le reverse proxy et exploitable (par exemple en utilisant des attaques du type HPP, HPF ou même plus inhérentes aux services SGBD ; voir cette très bonne présentation pour plus de détails). Ce, pour la simple et bonne raison que les fuzzers sont développés pour déceler les vulnérabilités et non bypasser certaines protections tierces protégeant l’accès à ces vulnérabilités.

Bref, les tests d’intrusions sur les applications web en front-end avec un simple navigateur et quelques plugins ont encore de beaux jours devant eux, rien ne remplacera l’expérience de l’auditeur dans son travail tant dans l’analyse du code que dans une attaque en font-end. Cependant, fuzzer une application peut s’avérer utile en appoint, notamment en local.

Pour information, j’ai passé sur w3af et sur Skipfish le script php calendar avant de réaliser cet article. Voici ce qu’ils ont découverts :

[-] Skipfish :

Il a simplement découvert l’injection SQL et une XSS dans le formulaire d’authentification de la zone d’admin (et le dossier de la zone d’admin). Aucune SQL injection dans l’index de l’application ni même l’include locale présente aussi dans l’index de l’application.

[-] w3af :

Il découvre le full path disclosure lorsque la valeur de la variable lang passée en GET n’est pas celle attendue. Il découvre aussi la LFI et une XSS (que je n’avais pas vu, présente grâce à l’erreur de retour en cas de non inclusion du fichier) mais aucune SQL injection dans l’index là aussi. Il ne découvre pas la zone d’administration, donc pas d’SQL injection ou de XSS dans le formulaire d’authentification de cette dernière.

Je ferai peut-être, un audit plus complet, avec de vraies statistiques pour comparer les fuzzers avec un audit fait à la main.

PS : Merci à @wadael pour me pousser à faire des articles =)

Ce dernier me sert afin de relayer des articles, papiers, images, citations que je trouve intéressants dans le domaine de la Sécurité des Systèmes d’Information. J’essaye d’y publier quelques liens par jour suivant le temps que j’ai. De plus, il y figurera certaines anecdotes que je rencontre de temps à autres… Cette image par exemple…

Ce script s’appelle Security Bugs Hunter et permet donc l’indexation de vulnérabilités suivant des scripts, avec la possibilité d’enregistrer le code vulnérable, le Proof of Concept de la vulnérabilité, des combos de vulnérabilités etc. Il possède par ailleurs un système de membres ayant plusieurs permissions, permettant ainsi au super administrateur de les régler suivant la confiance qu’il possède envers les abonnés.

Bref, le script aujourd’hui est beau certes, mais très pauvre en fonctionnalités (au pire, c’était juste pour me faire la main sur jQuery pour passer ensuite à autre chose…). Bref, je pense rajouter différentes petites choses telles que la possibilité d’Uploader l’application à auditer (et d’indexer ensuite par versions), de rechercher dans son code des vulnérabilités potentielles à grand coup de Regex (ce qui va ralentir un max.) et différentes choses.

Si vous voulez voir ce que cela donne, c’est par ici. Je mettrai le code source à télécharger dans quelques jours, histoire de bien le commenter et de l’alléger avec un peu de docs. (en y allant, vous gagnerez des 0dayz sur un script =)