Une autre banque de la place genevoise était associée hier dans la presse romande à une intrusion informatique, chapeautée d'une extorsion.

Décryptage.


Contexte

Dans la semaine du 29 décembre au 4 janvier dernier, un ou plusieurs pirates informatiques se présentant sous le nom de Rex Mundi [ci-après: R.M.] a identifié et exploité une faille de sécurité présente dans le formulaire de contact du site web de la banque G., basée à Genève [lettre choisie arbitrairement, le nom réel de l'établissement peut être trouvé en scrutant la presse romande].

Le 8 janvier, R.M. publie un communiqué sur un site web anonymisant. Dans le communiqué, R.M. revendique avoir pu récupérer 30'192 courriers ainsi que les coordonnées structurées associées (identification, moyen de contact en retour, etc.). A titre de preuve, deux messages ont été retranscrits dans le communiqué, incluant l'identité des auteurs des messages.

A la fin du communiqué, R.M. mentionne une rançon: G. doit payer à R.M. 10'000 Euros d'ici à vendredi à 18 heures [ndlr: la date exacte n'est précisée mais il s'agit probablement du 9 janvier 2015], faute de quoi l'intégralité des courriers sera publiée sur Internet.


Réponse de G.?

La Banque G. a répondu, par voie de presse [ndlr: première apparition constatée dans le journal Le Temps] et par communiqué de presse sur le site web de l'établissement financier.

Les détails internes du communiqué indiquent une date d'impression le 7 janvier 2015 à 19:37, par l'utilisateur interne z032758 [ndlr: au passage, une petite recommandation de lecture: CWE-200]. Le communiqué se présente comme suit:

G. a fait l'objet d'une tentative de cyber-attaque,
assortie de pressions, à laquelle elle a résisté.

Cet acte visait à intercepter des informations sur
un site web servant d'interface et d'outil de
communication avec la clientèle et les personnes
intéressées aux services de la banque.

Seules certaines informations, transmises par les
internautes, non critiques et peu exploitables ou
obsolètes ont pu être retranscrites.

G. a mis en oeuvre des actions protectives [ndlr:protectives?!?]
complémentaires. Chaque client concerné a été ou est en
passe d'être informé par son conseiller.

La banque relève que cet incident s'est produit hors
des périmètres hautement sécurisés de la banque.

Tirant le bilan de cette attaque, G. souligne la
robustesse de son système de sécurité tout en
enjoignant sa clientèle d'adopter un comportement
de prudence lors de l'utilisation d'applications sur
le web.

Refus? Diversion? Acceptation?

La stratégie de réponse semble très similaire à celle adoptée par la banque B. (voir billet du 19 décembre dernier). Regardons cela de plus près.

1."G. a fait l'objet d'une tentative de cyberattaque, assortie de pressions, à laquelle elle a résisté."

Faux.

La Banque G. a fait l'objet d'une cyberattaque et non d'une "tentative de". Cette dernière a d'ailleurs réussi, puisque plus de 30'000 courriers internes ont été obtenus et que la Banque G. fait en ce moment l'objet d'une demande de rançon dont l'ultimatum est fixé à vendredi 18 heures.


2."Cet acte visait à intercepter des informations sur un site web servant d'interface et d'outil de communication avec la clientèle et les personnes intéressées aux services de la banque."

Faux.

Il semble y avoir une confusion entre "la motivation" et "le butin". On n'attaque pas le site web d'une banque suisse simplement dans le but d'obtenir l'historique des demandes de contact. Cette démarche s'effectue généralement dans une logique de recherche de faiblesses et d'exploitation des éventuelles failles identifiées, quels qu'en soient les résultats obtenus, qu'ils soient de haute valeur ou non. Le butin était ici des courriers, mais rien ne laisse présager qu'il s'agissait d'une intention.

Le magazine Wired fait état des plus importantes menaces encourues par les organisations en 2015 et l'extorsion occupe la seconde place. Nous avons ici une motivation clairement définie: l'enrichissent financier grâce à la prise d'otage de données confidentielles ou opérationnelles. Un élément de plus montrant que l'attaque a réussi, alors que la demande de rançon, elle, ne réussira peut-être pas.


3."Seules certaines informations, transmises par les internautes, non critiques et peu exploitables ou obsolètes ont pu être retranscrites."

Archi-faux.

Nous avons ici un cas d'école exemplaire d'une violation d'un principe essentiel de la gestion de risque: il incombe au propriétaire de la donnée de déterminer si oui ou non sa diffusion au grand public est "critique" et "non-exploitable". Un tiers effectuant des traitements sur des données personnelles n'est pas en droit de qualifier la criticité de leur éventuelle diffusion au public. N'hésitons pas ici à mentionner que plusieurs instances fiscales européennes et américaines traquent actuellement leurs citoyens suspectés d'avoir placé des fonds non déclarés en Suisse. Au travers de ce communiqué de presse et des éléments relayés dans la presse, l'établissement s'est élevé ici en qualité de propriétaire, ce qui est, bien évidemment, faux.

Deuxièmement, l'établissement a qualifié "d'obsolètes" les données personnelles volées par R.M. Dans la mesure où les éléments volés incluent des noms de personnes, des numéros de téléphone, adresses email et numéros de comptes bancaires, des données qui typiquement changent rarement au travers des années, je peine à trouver la logique de raisonnement qui a permis d'atteindre une telle conclusion.

Troisièmement, les données dérobées incluent des données personnelles. Le courrier cité par R.M. fournit très clairement l'identité d'un client ainsi que son numéro de compte, ce qui semble non seulement être une donnée personnelle mais aussi répondre aux conditions de la définition d'une donnée d'identification client (CID). Cette classe de données particulière est réglementée par la FINMA (p.ex.: Circulaire 2008/21), dont les exigences de protection viennent s'ajouter à celles de la Loi sur la Protection des Données, et est directement associée à la notion de secret bancaire. Est-ce non critique?

Quatrièmement, et c'est ici à la décharge de l'établissement concerné: les structures s'octroyant le droit de qualifier le risque encouru par les propriétaires de données, à leur place, sont légion. La Banque G. n'est donc ici pas un cas isolé mais simplement l'illustration d'une mauvaise habitude répandue: architectes logiciels, chefs de projets, sous-traitants informatiques, éditeurs de sites web, fournisseurs de services en Claude (cloud pour les néophytes de ce blog), etc., la quasi-totalité des acteurs à qui un traitement de données personnelles est confié dépasse ses prérogatives et juge les risques à la place des clients.

Les propos choisis dans le communiqué sont donc malvenus, à mon avis, mais reflètent très bien une pratique généralisée et malheureusement plus que tolérée par les clients de ces organisations...


4."G. a mis en oeuvre des actions protectives complémentaires. Chaque client concerné a été ou est en passe d'être informé par son conseiller."

Très probablement vrai.

Contacter tous les clients potentiellement affectés par l'intrusion est une étape évidente de tout bon processus de résolution d'incidents de sécurité. Dans de nombreux États américains, ne pas contacter les personnes dont les données ont été exposées suite à un incident de sécurité est devenu un crime...

En ce qui concerne les mesures correctives (ou protectives), j'ose espérer que la Banque a corrigé la faille de sécurité et amélioré le dressage de son chien de garde* normalement placé en amont du serveur web. Il est évident que ce dispositif n'a pas fait son travail si l'on lit attentivement les détails techniques de la vulnérabilité qui a été exploitée par R.M. Ces informations auraient dû être fournies dans le communiqué, elles aussi.

*: WAF, pour les intimes


5."La banque relève que cet incident s'est produit hors des périmètres hautement sécurisés de la banque."

Diversion, mais probablement nécessaire pour des raisons légales...


6."Tirant le bilan de cette attaque, G. souligne la robustesse de son système de sécurité tout en enjoignant sa clientèle d'adopter un comportement de prudence lors de l'utilisation d'applications sur le web."

Refus et diversion. Même stratégie que celle adoptée par la Banque B. (cf. billet du 19 décembre): d'une part, la faute n'est pas admise, et d'autre part, une responsabilité semble être ici implicitement reportée sur les clients de la Banque ("adopter un comportement de prudence"??) alors que ces derniers n'ont ici, à priori, commis aucune faute. Pourquoi leur dit-on de faire attention?


Injection?

Les informations fournies dans le communiqué fournissent peu d'indices quant à la nature de la vulnérabilité qui aurait été identifiée et exploitée par les attaquants.

Ma première hypothèse se portait sur l'exploitation d'une vulnérabilité de type IDOR (Insecure Direct Object Reference). Cette vulnérabilité est recensée dans le compendium des vulnérabilités (CWE-639) et classée 4ème dans le Top 10 de la Fondation OWASP. Une exploitation réussie de cette vulnérabilité peut permettre, entre autres, l'extraction d'enregistrements structurés et identifiés par une clé d'identification moyennement à hautement prédictible (p.ex.: le message identifié par la clé 1, puis 2, puis 3, puis 4, etc.).

Mais je me suis trompé...c'est bien pire.

Le flux Twitter de R.M. fait mention d'un élément beaucoup plus inquiétant, dans la mesure où il s'inscrit parfaitement dans la chronologie des événements relatés:



Il est fait mention ici d'une vulnérabilité hautement plus grave (1ère position dans le compendium Top 25 de l'institut MITRE, 1ère position dans le Top 10 de la Fondation OWASP): l'injection SQL.

La présence d'un point d'injection SQL exploitable à travers un site web indiquerait que le principe d'étanchéité aurait été contourné: R.M. aurait obtenu un accès direct au serveur de bases de données alors qu'il était censé ne pouvoir interragir qu'avec le serveur web. Dans de nombreux cas, cette vulnérabilité ouvre une "route" à l'attaquant et lui permet de s'introduire plus profondément si une infrastructure est organisée en couches (le communiqué de presse fait référence à des "périmètres hautement sécurisés", mais il n'est pas précisé s'il s'agit d'une organisation en couches ou en silos). Le piratage de Sony, en 2011, dont le coût a été estimé à 1,25 milliards de dollars, a été rendu possible grâce à cette vulnérabilité.

Le message publié par R.M. sur son compte Twitter ne suffit pas pour établir une association avec le vol de données dont il a été question ici [ce blog n'est pas un journal, évitons les raccourcis]. Le scénario est donc hypothétique, mais hautement probable. Si cette hypothèse venait toutefois à être confirmée et que la Banque G. n'a perdu "que 30'000 demandes de contact", il faut retenir ici que la Banque a probablement échappé à une intrusion bien plus conséquente grâce à d'autres mécanismes venus seconder les défenses placées sur et autour du site web. On chuchote "ouf" au fond de la salle :)


Une affaire de sécurité ou de confiance?

Trois établissements de la place financière suisse ont subi une exposition médiatique relatant des manquements de sécurité informatique, avérés ou suspectés, durant ces 3 dernières semaines. Dans les trois cas, des manquements ont été dénoncés publiquement par des individus sans lien avec la presse.

La Banque G. affirme: "Il [notre site web] est aussi fiable que celui de n'importe quelle autre banque suisse." Comment interpréter une telle prise de position lorsque l'on est sous le coup d'une situation d'extorsion de données? Faut-il comprendre par là que les sites web des autres banques suisses sont eux aussi vulnérables à ce scénario?

Contrairement à ce que pourraient laisser croire des articles parus dans la presse, le niveau de sécurité des systèmes de la Banque G. ne peut pas être qualifié de bon ou mauvais, pas sans plus d'informations. Certes, la faille identifiée dans le site web est la plus grave, mais elle est aussi la priorité numéro 1 de tout auditeur de sécurité. Les tests de résistance aux attaques informatiques sont une obligation légale pour un établissement financier, et la Banque le confirme dans son communiqué: "le site a été audité".

La composante technique ne constitue toutefois qu'une part minimale de l'arsenal de mesures nécessaires à établir une confiance. Le communiqué publié par la Banque est un bon exemple: il n'est pas du tout rassurant. Pire: il est aggravant (déjà-vu?). L'époque où l'on effectue juste un "audit de site web" pour ensuite l'envoyer en production est révolue. Les processus d'accompagnement et d'intégration de la sécurité dans les activités de développement et d'acquisition de logiciels informatiques sont documentés, formalisés et accessible à tous. Quel était le niveau de maturité de la Banque par rapport aux 4 pôles fonctionnels de sécurité (gouvernance / implémentation / vérification / déploiement) pour le site web? Quelles activités d'accompagnement ont-elles été mises en oeuvre? On en compte généralement douze, ici le communiqué botte en touche et n'en mentionne qu'une seule: "le site a été audité".

La communication, pilier fondamental nécessaire à l'établissement de toute confiance, s'est révélée ici calculée, imprécise, lacunaire et accusatrice. Il s'agit pourtant d'un cas d'extorsion d'une Banque locale et citoyenne: nous devrions donc être plutôt enclins à la soutenir dans cette crise.

Difficile lorsque l'on se sent tenu à l'écart...


Pour Conclure (longue conclusion, désolé)

Au final, j'y vois le rejeu du scénario d'il y a trois semaines: la sécurité des systèmes n'est pas vraiment remise en cause, l'erreur est possible et nous le savons tous, mais ces incidents nous permettent de voir un aspect jusque ici globalement maintenu caché du public. Ce que l'on voit ne rassure pas, et inquiète.

Peu d'organisations suisses ont à ce jour un intérêt économique considérable à protéger les données personnelles collectées ou traitées. Leurs dirigeants ne craignent ni l'amende, ni la prison, ni la radiation. La Confédération, les Cantons et les États ne semblent pas vouloir mettre en place un contexte juridique propice à pousser les entreprises vers un comportement responsable vis-à-vis des données personnelles en leur possession. Ces données ne sont pourtant pas aussi "bon marché" qu'il n'y paraît: elles sont réglementées, elles doivent être protégées et tout cela a un coût. Dans de nombreux pays, dont les États-Unis, et l'Union Européenne, la présence d'une faille de type injection SQL constitue une infraction pénale. L'avantage économique créé par une protection lacunaire des données personnelles alimente un contexte concurrentiel inéquitable entre les entreprises.

Créer un contexte propice à l'équité économique me semble pourtant faire partie des prérogatives d'un État de Droit.

Plus important encore: quel accompagnement ou encouragement offre-t-on aux dirigeants investissant les moyens nécessaires à la protection des données personnelles de leurs clients, collaborateurs ou utilisateurs? Faut-il punir ces entreprises lors du moindre manquement? Comment distinguer l'ingérence de la malchance? Faut-il médiatiquement "lyncher" ces organisations lorsque leurs systèmes sont compromis?


opportunités? les assureurs.
Les lois destinées à punir les criminels sont là, mais elles ne semblent pas faire leurs preuves dans un contexte de globalisation où la menace peut provenir de n'importe où dans le monde. La Confédération et les Cantons ont pourtant un moyen d'action: ils peuvent diminuer l'attrait de la place suisse pour le cybercrime, d'une part, en la rendant plus coûteuse à compromettre et d'autre part, en aidant les acteurs disposant de moyens limités. La FINMA distribue des directives (et des claques) aux institutions financières mais qui s'adresse à toutes les autres organisations? Études d'avocats (protection des ordinateurs des avocats?), centres de soins (fichiers médicaux), écoles (informations confidentielles sur les élèves), etc.?

Celui ou celle qui me répond "il y a la LPD*!" est aimablement invité à prendre la porte.

*:Loi sur la Protection des Données


Le contexte actuel est tel que les établissements bancaires peuvent se faire voler des données identifiant leurs clients, exposer une vulnérabilité logicielle classée en première position de TOUTES les directives, standards ou recommandations de sécurisation de systèmes depuis plus de 10 ans, et annoncer par écrit que ce n'est pas critique. Le champ d'application de la LPD n'est clairement pas suffisant.

Une régulation par l'État est souvent la première solution envisagée mais des problèmes se posent rapidement: qui fixe les limites? qui contrôle? qui sévit? On le sait assez bien: cette approche est exposée à l'instrumentation et les entreprises les plus impactées par ces mesures enverront quelques lobbyistes de plus à Berne.

Il existe à mon avis une alternative: les assurances, et plus particulièrement, les assurances RC et protection juridique. Lorsque ces assurances entameront un dialogue avec les experts en sécurité de systèmes, elles pourront formuler des directives technologiques, organisationnelles et physiques mesurables dans leurs contrats. Une opération gagnante pour tous: les citoyens bénéficieront d'une meilleure protection de leurs données personnelles, les entreprises exposeront des systèmes mieux protégés dans un paysage concurrentiel plus équitable et les assureurs réduiront le périmètre des sinistres à leur charge.

Et si l'État se sent un peu délaissé, je recommande à ses dirigeants de mettre à jour le guide pour la sécurisation des infrastructures IT de l'entreprise (ça coûte sûrement moins cher qu'un Grippen). Figé depuis 2010, ce guide brille par l'absence notable de toute recommandation en matière d'acquisition et de développement de systèmes informatiques. Ironie du sort: c'est bien de cela dont il s'agit depuis trois semaines...

On a tous le droit de rêver un peu, non? ;)



A vos agendas, il est bientôt 18 heures...

MISE A JOUR: 9 janvier @ 18:27

R.M. annonce avoir publié un fichier contenant les données. La Banque G. n'aurait donc à priori pas cédé au chantage.

MISE A JOUR: 9 janvier @ 19:03
Selon la régie publicitaire Tribune de Genève, le fichier diffusé contiendrait effectivement les données de la Banque G.

Du côté de la banque, on tempère: "Les données saisies sont uniquement celles de clients qui ont rempli notre formulaire de contact". Le message est clair et sans équivoque: une personne contactant une banque suisse via son formulaire de contact en ligne doit s'attendre à ce que des tiers lisent le contenu du message...

MISE A JOUR: 10 janvier @ 09:30
On vient de m'apprendre que la Banque G. a publié une offre d'emploi pour un poste de "spécialiste de la sécurité informatique". Après consultation des compétences attendues et tâches principales, le constat est sans-appel: absence de toute mention ou référence de compétences ou tâches relatives à l'intégration de la sécurité dans les processus d'acquisition ou de développement de systèmes. J'espère que c'est sans lien avec l'incident susmentionné, ou alors ça ne va pas régler grand chose...