ompant avec la tradition de la blague printanière, Uri Rivner nous livrait vendredi un billet fort intéressant, commenté à de nombreuses reprises ce week-end, détaillant les différentes phases de l'attaque qui a conduit à la compromission de RSA. Il faut lire cet article pour deux raisons.
La première, c'est qu'on y apprend pleins de choses sur le déroulement de l'attaque. Que tout est parti d'un phishing ciblé, désormais appelé "spear phishing", destiné à délivrer d'un objet embarquant un 0day Flash. Qu'il a servi à déployer un malware type RAT qui a permis une escalade de privilèges sur le réseau et une collecte d'informations tout azimut. Un scénario qui n'est pas sans rappeler ce qui s'est passé dernièrement à Bercy. La seconde, c'est l'affligeante introduction, à la limite du foutage de gueule...
Un phishing ciblé a donc été utilisé pour délivrer un fichier Excel contenant un 0day pour une faille Flash dont le correctif a été publié il y a deux semaines. Beaucoup ne manqueront pas de s'étonner de ce qu'une feuille Excel puisse embarquer du Flash, mais ça n'a finalement rien de vraiment surprenant quand on y réfléchit deux secondes... Ce qui est plus étonnant, c'est qu'une boîte comme RSA n'ait pas les moyens de se protéger de ce genre de construction, à commencer par la non utilisation de Flash sur son réseau...
L'outil super sophistiqué déployé à l'exploitation de cette faille est le désormais bien connu PoisonIvy, outil que je mentionnais il y a peu. Via cet outil d'administration distante, les attaquant ont collecté diverses données, à commencer par des logins et mots de passe pour se propager à travers le réseau et accéder à des ressources contenant des informations de valeur. Ces dernières ont alors été copiées vers des machines ayant accès au monde extérieur, compressées et chiffrées dans des containers RAR protégés, lesquels ont finalement été exfiltrés en FTP avant d'être effacés pour supprimer d'éventuelles traces.
L'attaque aurait été détectée pendant la phase de propagation, mais force est de constater que cette dernière était déjà suffisamment avancée pour que les intrus n'aient pas pu être stoppés. D'un autre côté, c'est probablement ce qui a permis de collecter les informations permettant d'avoir une idée de ce qui avait été volé et vers quelles destinations ces données avaient été exfiltrées. Parce que le truc avec PoisonIvy, c'est que comme tout est chargé en mémoire[1], un forensics après coup ne donne souvent pas énormément de résultats, en tout cas par rapport à ce que pourra apporter une observation en live. Là encore, ça devrait vous rappeler le traitement des mésaventures du Ministère des Finances...
Si d'aucuns se prennent à saluer une telle transparence de la part de RSA, exactement comme l'effort de communication de l'ANSSI a pu être remarqué et salué, il reste une différence de taille. À savoir que la compromission de Bercy n'impacte pas la sécurité des autres[2]. Ce qui n'est pas le cas de RSA puisqu'on ne sait toujours pas ce qui a été dérobé et à quel point cela impacte l'efficacité du produit SecurID et donc la sécurité de ses utilisateurs. Tout ce qu'on peut comprendre entre les lignes et à travers diverses analyses, c'est que le produit est affaibli. Au point de pousser l'éditeur à recommander l'utilisation de mots de passe fort, ce qui la fout mal quand on vend un système d'authentification double facteur qualifié de fort...
Mais ce qui prête à sourire dans cette lecture, c'est surtout le plaidoyer limite larmoyant sur le fait que les APT, c'est un truc tellement super violent que tout le monde se fait pwner. Et là, sérieusement, il faudrait arrêter de se foutre de la gueule du monde. Juste cinq minutes. Si on pourra accepter l'exemple de la compromission de Google, le fait de nous citer le cas HBGary démontre une langue de bois assez massive. Non HBGary ne déployait pas "toutes les combinaisons imaginables de moyens de sécurité à la pointe". Ils se sont fait déchirer comme des bleus parce qu'ils tombaient dans la réutilisation massive de mots de passe faible. Un bon gros #FAIL, rien de sophistiqué, c'est le même genre de problématique qui explique que, par exemple, Hacker Croll ait pu se faire Twitter.
"What does that tell you?" demande l'auteur. Ben moi, ça me dit que soit il n'a rien compris au problème, soit il essaye de noyer le poisson. La vérité se trouvant probablement quelque part au niveau d'un maximum local entre les deux... Ça me dit aussi que la sécurité déployée chez RSA devait faire beaucoup de cas de ses périmètres, et peu du reste. Le syndrome de la coquille vide. Et que, là encore, il était temps que RSA découvre un nouveau paradigme qui est devenu la réalité de beaucoup ces quatre ou cinq dernières années.
Sur le 0day lui-même, ce n'est pas comme si ça faisait quelques années qu'on sait qu'il faut tenir pour un fait acquis que des 0days pour toutes les applications populaires sont en circulation. Et en tête de celles-ci, on trouvera évidemment la suite bureautique Office, Acrobat Reader et Flash. Donc se prendre un 0day Flash n'a rien d'une APT, c'est un truc que, considérant l'état de la menace depuis deux ou trois ans, on pourra qualifier sans risque de normal et d'attendu. Et quand bien même il n'y a pas de honte à se faire compromettre une machine par un 0day, essayer de nous faire croire qu'il s'agit d'une pratique hors-norme et super sophistiquée relève l'escroquerie intellectuelle.
On notera d'ailleurs que le 0day dont il est question tourne dans des feuilles Excel depuis quelques temps déjà, y compris pour des campagnes d'exploitation massives...
Maintenant sur le fameux spear phishing. Là encore, rien de nouveau sous le soleil. L'utilisation d'informations personnelles pour cibler une attaque et construire un social engineering crédible ne date pas d'aujourd'hui, pas plus que la mise à profit des réseaux sociaux à cet effet. Mais maintenant qu'on lui a donné un nom qui sonne bien à l'oreille, croyez-moi, vous n'avez pas fini d'en entendre parler à toutes les sauces, en particulier parce que la plupart de ceux qui diabolisent l'usage des réseaux sociaux n'avaient jusqu'alors que peu d'exemples croustillants à mettre sur la table pour donner du corps à un propos pas très convaincant sur le fond. En outre, ça ne manquera pas de revenir au menu à chaque nouvelle fuite de données personnelles. Si au moins ça pouvait sensibiliser sur l'importance de la protection des données personnelles...
Enfin, on pourra perdre deux minutes sur cette perle magnifique :
In our case the weapon of choice was a Poison Ivy variant set in a reverse-connect mode that makes it more difficult to detect, as the PC reaches out to the command and control rather than the other way around.
Ah ouais. Le reverse-connect c'est tellement plus difficile à détecter. Ça fait combien de temps que tous les pentesters de la planète utilisent ça tous les jours au point que ça en soit devenu la tarte à la crème du shellcode Metasploit ?! Comme le disait si bien un confrère mais néanmoins ami, "APT man... APT... 'nuf said..."...
Bref, tout ça pour dire que s'il s'agit là d'une de ces fameuses APT, force est de constater qu'il s'agit d'un concept qui existe depuis longtemps, qui a été documenté à de très nombreuses reprises et pour lequel des pistes de réflexion ont été lancées, et qu'on retrouve utilisé dans la vraie vie depuis quelques années déjà. Le document Office embarquant un 0day envoyé dans un email usant d'un social engineering très bien construit à quelques dizaines de personnes bien ciblées, on a déjà vu ça à de nombreuses reprises. Et quand on me parle de ça, le premier exemple qui vient à l'esprit date de... 2006... Je concède malgré tout volontiers que dans ce dernier cas, il n'était pas fait usage de PoisonIvy. Peut-être cela rend-il cet exemple inéligible à l'appellation d'APT...
Et il est intéressant qu'une analogie avec les sous-marins allemands de la seconde guerre mondiale soit faite. Car contrairement à ce qui est sous-entendu, les sous-marins n'avaient rien d'une menace nouvelle en 1939, bien au contraire. C'était juste une menace à laquelle on n'avait probablement pas jugé bon de s'intéresser... Avec les conséquences qu'on connait...
En cela, c'est une bonne analogie : les APT sont une menace qui ne date pas d'hier, c'est juste que l'industrie, qui les avait laissé de côté jusqu'à présent, commence à s'apercevoir qu'elles posent un gros problème... À ses dépens...
Notes
[1] La DLL serveur chargée sur la cible sera de toute manière chiffrée si elle doit toucher le disque, ce qui reste optionnel.
[2] Ou très marginalement.