Banques vulnérables à POODLE — mais pas seulement.

Un article, paru dans Le Matin du jour¹, met en avant des problèmes de configuration des serveurs e-banking de deux organismes bancaires suisses.

Les commentaires, outre le fait qu'ils passent juste à côté du sujet principal, montrent aussi le manque de connaissances des utilisateurs de ces services. La réponse d'une des banques citées² est, quant à elle, un ramassis de langues de bois.

Penchons-nous un tout petit peu sur le fond du problème.

POODLE
Sous ce joli nom tout mignon se cache un truc un peu vicieux. On ne va pas entrer dans les détails, déjà expliqués en long³, en large⁴ et en travers⁵.
Ce qu'il faut retenir, c'est que c'est exploitable moyennant un peu de connaissances techniques, et que ça permet, entre autres, de récupérer un cookie⁶ de session⁷, permettant à un attaquant de vous personnifier auprès des services demandant une authentification (comme une banque, par exemple).

Il est certain que les instituts bancaires ont des mesures de sécurité empêchant un cookie d'être réutilisé. On imagine sans peine que les adresses IP sont contrôlées lors de chaque action, de même que les éléments fournis par les navigateurs des clients. De toutes façons, les informations utilisables pour de tels contrôles sont enregistrées pour le suivi des transactions, leur validation, etc. Avec ou sans POODLE, Heartbleed ou autres à venir.

Il est donc clair que le système e-banking en soi est sécurisé ou, du moins, ne devrait pas être assez mauvais pour que POODLE soit réellement efficace.

C'est quoi le problème alors ?
Le problème, enfin, les problèmes, sont mutliples.

En premier, le silence des banques face à POODLE. Mais pas seulement : peu ont communiqué suite à Heartbleed⁸ qui a pourtant été pas mal médiatisé. En gros, on paie les banques pour un service et un accès par voie électronique (e-banking), mais on ne sait jamais réellement si elles sont au courant des failles, ni ce qu'elles font pour nous protéger, nous, les clients qui leur confions notre argent.

Outre le silence, le temps de réaction est affligeant : il faut compter des semaines si ce n'est des mois avant de voir le correctif appliqué.

Dans le cas précis de la BCV, on pourra aussi noter leur superbe résultat sur SSLlabs⁹, montrant qu'ils n'ont pas forcément les moyens de contester quoi que ce soit : leur configuration SSL est mauvaise, du certificat SSL mal fait jusquà la configuration de leur serveur web. Même leur certificat intermédiare est faux et comporte des éléments en trop…



Dans le cas de la Raiffeisen, pareil, leur résultat¹⁰ est tout aussi parlant, bien que meilleur que la BCV. Ce qui n'est, en soit, pas très dur…



Et alors… C'est sécurisé, oui ou non ?
Oui. Enfin… On ne peut que l'espérer, à savoir que le protocole de connexion est pourri, donc on doit faire confiance au backend (l'application d'e-banking) pour qu'elle possède les contrôles nécessaires, et qu'elle soit exempte de failles exploitables. Errare humanum est, comme disait l'autre.

Sans tomber dans la paranoïa complète, voici quelques conseils pour éviter les problèmes en attendant que la situation soit claire :

• Ne jamais employer une connexion publique sans fil
• Éviter de passer par les connexions mobile (oui, même avec leur app, le réseau DATA mobile est insécure)
• Contrôlez que le certificat soit bien émis par une autorité reconnue (VeriSign pour la BCV,  et QuoVadis Global pour Raiffeisen)
• Dans la mesure du possible utilisez la connexion de votre domicile.

Note: l'émetteur du certificat. À ce niveau, rien n'est gravé dans le marbre, surtout en sachant que ces deux banques ont "prévu de corriger le problème" début 2015. 

Mot de la fin
Ce qui est consternant dans toute cette histoire, c'est le manque de communication des banques.
Si elles savent qu'elles sont protégées, pourquoi ne pas le mettre sur leur page d'accueil ?
Quand on les contacte par mail, en passant par leur messagerie interne (accessible uniquement par les clients donc), pourquoi ne répondent-elles pas ?

Ce qui est aussi consternant, c'est de voir que des instituts censés protéger leurs usagers ne semblent pas prendre réellement au sérieux l'image qu'elles donnent d'elles-mêmes : en effet, se ramasser un F pour un truc aussi basique qu'une configuration SSL, ça ne donne pas confiance.

Pour notre part, cela nous fait nous interroger sur les compétences de leurs équipes (ou prestataires) à gérer correctement une infrastructure.
Du coup, est-ce que nos données sont réellement protégées ?
Est-ce que tout est réellement mis en œuvre pour éviter les fuites ou les vols ?

Autant de questions qui, nous le craignons, resteront sans réponse. Le manque de transparence à ce niveau est mauvais, et n'inspire en tous cas pas la confiance requise pour confier son argent et ses données à de tels instituts.

En comparaison, la connexion fournie par EthACK est plus sécurisée que celle de ces deux banques¹¹. Et on ne vous fait rien payer pour ça ;).

• ¹http://www.lematin.ch/economie/faille-banques-ignorent/story/15022718
• ²http://www.bcv.ch/fr/la_bcv/actualites_et_medias/actualite_bcv/2014/securite_bcv_net_article_errone_dans_le_matin
• ³http://fedoramagazine.org/what-you-need-to-know-about-the-sslv3-poodle-flaw-cve-2014-3566/
• ⁴http://www.oracle.com/technetwork/topics/security/poodlecve-2014-3566-2339408.html
• ⁵https://www.poodlescan.com/
• ⁶https://fr.wikipedia.org/wiki/Cookie_%28informatique%29
• ⁷https://fr.wikipedia.org/wiki/Session_%28informatique%29
• ⁸https://en.wikipedia.org/wiki/Heartbleed
• ⁹https://www.ssllabs.com/ssltest/analyze.html?d=bcv.ch
• ¹⁰https://www.ssllabs.com/ssltest/analyze.html?d=tb.raiffeisendirect.ch
• ¹¹https://www.ssllabs.com/ssltest/analyze.html?d=ethack.org

Catégories en relation

• Privacy
• Réseaux
• Technologies
• software
• Protection des données
• français

Soutenir l'auteur

• Flattr
• 13JSecpDvje3vCF3Zw4Hwv3jdApsYxDh8k
  
• LeABMMhNA3wXBRK8BoC81YZjitfEncwckG
  

• CC-by-sa 4.0
• Rapporter un abus

Ajouter un commentaire

Nom d'utilisateur

Email

Website

Commentaire

Enregistrer