N26 corrige plusieurs failles, la sécurité des « néo-banques » en question

N26 corrige plusieurs failles, la sécurité des « néo-banques » en question

UX is not enough

Avatar de l'auteur
Vincent Hermann

Publié dans

Internet

29/12/2016 7 minutes
71

N26 corrige plusieurs failles, la sécurité des « néo-banques » en question

N26, souvent décrite comme « l’étoile montante de la FinTech », publiait récemment un billet expliquant la correction de failles de sécurité découvertes par Vincent Haupert. Celui-ci participait cette semaine à la conférence 33C3 pour en donner les détails. De quoi inciter à s'interroger sur la sécurité des « néo-banques ».

Les « néo-banques », ces nouveaux services « FinTech » entièrement tournés vers un usage mobile qui promettent de révolutionner notre relation à la gestion de notre argent passent une mauvaise fin d'année.

Outre les soucis financiers de MorningN26 (anciennement Number26) évoquait le 14 décembre avoir été alertée par un chercheur en sécurité, Vincent Haupert, au sujet d’un problème potentiel. Pour celle qui se décrit sur son site comme « la banque la plus moderne d’Europe », cela pose souci.

Une annonce passée presque inaperçue

Les détails de la brèche n’ont pas été donnés dans l’immédiat. N26 indiquait seulement avoir travaillé main dans la main avec Haupert pour examiner le problème et le résoudre. Ce dernier s’est donc rendu dans les locaux de l’entreprise à Berlin, et la faille, quelle qu’elle soit, a été déclarée comme résolue. N26 le cite d’ailleurs, indiquant qu'il loue la réactivité de la banque sur le sujet.

Plusieurs informations importantes étaient néanmoins données. D’une part, aucun client n’avait été touché par la faille. Les comptes n’ont donc pas été en danger, et il n’y a pas eu de transferts frauduleux d’argent. D’autre part, N26 a ouvert un programme de chasse aux bugs (bug bounty), une pratique bien connue des entreprises, qui récompensent les découvreurs de failles afin de les dissuader de les vendre aux plus offrants.

Quand simple s'approche trop de simpliste

Mais on en sait désormais davantage sur ce qu'il s'est passé. Vincent Haupert participait cette semaine à la 33ème édition du Chaos Communication Congress (33C3) et intervenait sur la sécurité des banques en ligne, avant de basculer sur le cas précis de N26 pour détailler sa découverte. Il a ouvert son intervention par un avertissement sur la sécurité générale de la FinTech (Financial technology), qu’il estime souvent plus intéressée par les belles interfaces à succès que par la protection des données et, dans le cas présent, des sommes placées.

Il a commencé par rappeler quelques fondamentaux sur N26, plantant le décor du succès de l’entreprise. Fondée en 2013 et active depuis 2015, la banque annonce gérer aujourd’hui 200 000 clients en Europe. La simplification extrême du processus voulu par N26 permet au client d’ouvrir un compte en seulement 8 minutes, faisant du smartphone un « hub financier ». La conception de l’application permet de se concentrer sur le principe de simplicité.

Mais selon Haupert, « simple » ne doit pas signifier « simpliste », surtout quand on parle de sécurité. Il a commencé par redonner les quelques étapes requises pour créer un compte et commencer à transférer de l’argent. D’abord un couple adresse email et mot de passe, puis un code PIN qui servira à valider les opérations, et enfin un code d’appairage pour un appareil unique.

Ce dernier est la mesure la plus importante. Au premier démarrage, l’application génère une paire de clés RSA et envoie la clé publique sur les serveurs de N26. Chaque nouvelle transaction est confrontée au service distant, l’application déchiffrant alors la communication avec sa clé privée. C’est celle-ci qui limite évidemment l’appairage à un seul smartphone.

Une attaque par homme-du-milieu

La communication entre l’application et l’infrastructure de N26 se fait en JSON sur une connexion HTTPS, mais sans couche de chiffrement supplémentaire sur les données échangées. Vincent Haupert a donc été capable de réaliser une attaque de type « homme du milieu » (MITM) en ciblant leur protocole. Une attaque d’autant plus facilitée que le client (donc l’application) n’effectue aucune vérification spécifique (notamment via un « épinglage de certificat »).

À partir de là, le chercheur était capable de manipuler un certain nombre d’éléments. Par exemple, modifier le récipiendaire, c’est-à-dire la personne qui doit recevoir les fonds. On comprend aisément le danger d’une telle faille, tout comme le titre de son intervention (« Shut up and take my money »). Si un attaquant avait pu prendre le contrôle du DNS pour l’adresse api.tech26.de – qui sert à valider les opérations – il pouvait manipuler les transactions en temps réel.

Le détournement du DNS entraîne tout le reste

Mais parvenir avec succès à détourner le DNS ne permet pas seulement de réorienter les transactions. L’attaquant peut en effet obtenir aussi le contrôle complet du compte, à condition d’en connaître les détails. Avec une technique assez classique de phishing (choix d’un domaine très proche), on peut contacter l’utilisateur et l’inviter à changer son mot de passe. Une fois les identifiants obtenus, la version iOS de N26 peut procéder à des transferts sans même réclamer le code PIN.

Haupert s’est aussi attaqué à une affirmation de la banque : toute activité suspecte est détectée et bloquée avant même qu’elle ne survienne. 2 000 transactions d’un centime ont donc été envoyées en 30 minutes. Non seulement N26 n’a réagi qu’au bout de trois semaines pour demander des explications, mais la banque souhaitait même fermer le compte… du récipiendaire (Dominik Maier, professeur d'Haupert).

Apparaige et code PIN : pas de problème

Il était également possible d’obtenir le désappairage du smartphone principal, pour en déclarer un autre. Cette procédure est normalement très sécurisée, car il faut posséder les identifiants, la Mastercard obtenue avec le compte et la carte SIM, puisqu’un jeton de sécurité est envoyé par SMS. Mais le lien de désapparaige est renvoyé par le serveur, et l’identifiant de la Mastercard circule dans chaque transaction. Des informations que l’on peut donc récupérer quand l’attaque MITM a réussi.

Quant au code PIN, on pourrait ajouter qu’il s’agit du clou du spectacle. Tout ce qu’il faut pour le réinitialiser est en effet... l’identifiant de la Mastercard. Dès qu’il est entré, l’utilisateur peut entrer un nouveau code PIN, sans que l’application ne réclame l’ancien.

Tous les problèmes ont été résolus

De fait, la « vulnérabilité théorique » abordée par N26 consiste en une liste de problèmes dont Vincent Haupert a fait l’inventaire durant la conférence. D’un certain côté, on peut effectivement les ramener à une brèche unique, puisque l’exploitation frauduleuse des comptes et le contrôle des transactions ne peuvent être mis en place que si l’attaque MITM a fonctionné.

Cependant, et même si cette faille est corrigée, certaines pratiques élémentaires méritaient d’être révisées. On peut ainsi s'interroger sur le fait qu'un nouveau code PIN puisse être déclaré sans réclamer une information que seul l’utilisateur est censé connaître, comme son ancien code. L’identifiant de la Mastercard n’est en effet pas suffisant puisque l’information circule notamment dans les ordres de transaction.

Quoi qu’il en soit, N26 assure que le problème est résolu, et Vincent Haupert a confirmé que plus aucune des vulnérabilités signalées ne subsistait. Reste maintenant à voir si tous les autres acteurs du domaine bancaire, nouveaux venus ou non, gèrent correctement la sécurité de leurs différentes applications.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Une annonce passée presque inaperçue

Quand simple s'approche trop de simpliste

Une attaque par homme-du-milieu

Le détournement du DNS entraîne tout le reste

Apparaige et code PIN : pas de problème

Tous les problèmes ont été résolus

Fermer

Commentaires (71)


bas oui mais à pousser le salaire des devs par le bas et à se retrouver avec des chef de projets qui ont à peine 6 mois de boite ça finit à “rien foutre de la sécu, l’appli tourne c’est tout ce qu’on m’a demandé”


C’est une des possibilités.

Après t’as aussi ceux bien payé, qui se croient compétents et qui en fait ne le sotn pas.


Appli mobile comme web d’ailleurs.

Là où je travaille, notre appli web qui gère la génération des licences de ce que nous vendons n’est pas sécurisée. Pas de HTTPS, mes identifiants sont mes initiales et mot de passe… pareil avec 2 chiffres en +. Je ne peux évidemment pas le changer. Et pour couronner le tout, pas de timeout sur la session, si mon navigateur reste ouvert je suis connecté ad vitam aeternam.

J’ai signalé ces quelques trucs mais ce qu’on m’a dit c’est que “c’est bon ça craint rien” et que “pleins de gens utilisent ça donc on peut pas faire de maintenance dessus”…


Le principe d’une faille c’est justement que personne y a penser. Expérimenté, Débutant, Bien payé ou mauvais payeur. Tu peux même avoir eu un audit de sécurité qui soit passé par là et ne l’ai pas détecté.



L’important dans ce domaines c’est surtout le suivi et la réactivité.


Pareil chez nous, on a même pousser le vice jusqu’à enregistrer tout les mots de passes (y compris des manager) dans une seule et même…matrice Google Sheets.



Je suis dans une boite Multi-produits, et nos techniciens n’ont même pas séparés les disques dur des différents services, tu bosse pour une boite X t’a accès aux docs de la boite Y&nbsp;<img data-src=" /><img data-src=" /><img data-src=" />


Etre mal payé ne justifie pas de faire un boulot de merde et en principe, même débutant, tu es sensé être formé à ton métier. Du reste, s’il suffisait d’avoir des développeurs de tout premier ordre et du personnels sur payés pour éviter les failles, ça se saurait <img data-src=" />








darkbeast a écrit :



bas oui mais à pousser le salaire des devs par le bas et à se retrouver avec des chef de projets qui ont à peine 6 mois de boite ça finit à “rien foutre de la sécu, l’appli tourne c’est tout ce qu’on m’a demandé”







Un point anti-jeunisme primaire pour toi, bravo

Tu veux qu’on parle des vieux qui pètent plus haut que leur cul et qui savent tout mieux que toi parce qu’ils ont travaillé avant que tu naisses, ou tu admets que la stupidité et l’incompétence ne dépendent pas de l’âge?



Si c’est un vieux troll très bonne pêche cependant



Effectivement, le chef a toujours raison, quel que soit son âge : c’est lui qui décide et c’est toi qui creuse.


Article intéressant. La sécurité bancaire est trop souvent laissée à la discrétion des banques.








ike a écrit :



Le principe d’une faille c’est justement que personne y a penser. Expérimenté, Débutant, Bien payé ou mauvais payeur. Tu peux même avoir eu un audit de sécurité qui soit passé par là et ne l’ai pas détecté.



L’important dans ce domaines c’est surtout le suivi et la réactivité.







Enfin les attaque MITM c’est un classique tout de même. Surtout que là, là communication était bien en HTTPS mais sans vrai contrôle du certificat !?! C’est pratique pour passer les proxy d’entreprise qui font de la désencapsulation https pour le filtrage/antivirus mais c’est tout. Quitte à faire çà, on ajoute une couche d’identification des serveurs par l’appli et du chiffrement.







joma74fr a écrit :



Article intéressant. La sécurité bancaire est trop souvent laissée à la discrétion des banques.







Euh oui, comment pourrait il en être autrement ?




Lol quand on regarde les autres banques c’est loin d’être mieux. Pourquoi se focaliser sur N26 ?



J’ai assisté a une conf Credit Agricole ou le présentateur envoyait un SMS et piquait 1€ en direct a toute l’audience.

Quand on voit les inepties des banques classiques, codes a 4 chiffres, clavier “anti-keylogging” sur un smartphone, validation par SMS ou date de naissance, etc… Les failles sont partout, et N26 est loin d’être la pire.



N26, Monzo, etc. ont justement tout à prouver et sont basées sur des archi modernes, ça craint certainement moins que certaines banques utilisant des serveurs qui font tourner du Cobol depuis 30 ans.








CryoGen a écrit :



Euh oui, comment pourrait il en être autrement ?





On pourrait imaginer une solution unifiée pour tous les sites critiques par exemple non ?









Antwan a écrit :



Lol quand on regarde les autres banques c’est loin d’être mieux. Pourquoi se focaliser sur N26 ?



J’ai assisté a une conf Credit Agricole ou le présentateur envoyait un SMS et piquait 1€ en direct a toute l’audience.

Quand on voit les inepties des banques classiques, codes a 4 chiffres, clavier “anti-keylogging” sur un smartphone, validation par SMS ou date de naissance, etc… Les failles sont partout, et N26 est loin d’être la pire.



N26, Monzo, etc. ont justement tout à prouver et sont basées sur des archi modernes, ça craint certainement moins que certaines banques utilisant des serveurs qui font tourner du Cobol depuis 30 ans.





Keep calm and breath .





Deux choses intéressantes pour moi dans l’article :




  • une banque en ligne qui n’envoie pas balader un chercheur en sécurité et qui bosse avec lui rapidement sur le problème

  • des sécurités qui ne le sont pas vraiment, avec même un gros trouage en règle (les 2000 transactions de 1 centime).



    Bref c’est cool d’avoir des infos sur ce petit monde plein de néologisme propre à ces nouvelles banques.



&nbsp;







CryoGen a écrit :



Enfin les attaque MITM c’est un classique tout de même. Surtout que là, là communication était bien en HTTPS mais sans vrai contrôle du certificat !?! C’est pratique pour passer les proxy d’entreprise qui font de la désencapsulation https pour le filtrage/antivirus mais c’est tout.





J’ai vu ça une fois, je m’en suis rendu compte en regardant les détails de la connexion SSL, j’ai trouvé ça totalement inadmissible <img data-src=" /> . Je me demande si c’est vraiment légal d’ailleurs.

Heureusement, le site de ma banque (une des grandes) devait être dans une liste blanche car le chiffrement était bien de bout en bout, ainsi que pour quelques autres sites.









Antwan a écrit :



N26, Monzo, etc. ont justement tout à prouver et sont basées sur des archi modernes, ça craint certainement moins que certaines banques utilisant des serveurs qui font tourner du Cobol depuis 30 ans.





Le Cobol, ça tourne pas sur des serveurs mais sur du mainframe, et depuis plus de 40 ans. Et c’est plus dur à pirater vu que plus personne connaît comment ça marche.



Et désolé, côté banque la sécurité n’est pas laissée “à leur discrétion”. Y a 3 tonnes de règlements et de lois à respecter.



Ce qui est intéressant, c’est que les règles des “fintechs” sont différentes, mais il y a quand même une base. Les affaires N26 et Morning montrent que la qualité ça se paye, notamment en expérience.



Oui c’est légal, mais il y a des conditions. Et oui les banques sont sensée être exclus de la désencapsulation https.








CryoGen a écrit :



(…)



 Euh oui, comment pourrait il en être autrement ?








Par exemple,      





Quand on lit dans la presse qu’il n’y pas de soucis de sécurité avec la CB et que par ailleurs j’ai subi en tant que client des irrégularités alors que mes interlocuteurs bancaires étaient dans l’impossibilité de m’expliquer clairement comment fonctionne ma CB (les plafonds de paiement/retrait, le découvert autorisé ou non mais qui passe quand même, etc),



&nbsp;      

Quand j'ai entendu par ailleurs l'AFUB dénoncer une fraude conséquente chez des clients du Crédit mutuel Nord Europe et de La Banque postale et que les services de banque en ligne de La Banque postale ont progressivement mis en place des limites aux virements (délai de 48h pour enregistrer un nouveau bénéficiaire, limite de quelques milliers d'euros par virement), alors que j'aurais préféré être prévenu de ces changements et que j'aurais préféré que La Banque postale me propose une solution de sécurité beaucoup plus "user-friendly" comme font d'autres banques (limites paramétrables par le client lui-même, contact avec un interlocuteur qui gère le compte de son client et qui assure un vrai service payant),



&nbsp;https://www.facebook.com/AFUBofficiel/videos/vb.260069017422394/568208869941739/



&nbsp;http://www.leparisien.fr/espace-premium/actu/alerte-a-la-fraude-au-credit-mutuel...  

&nbsp;http://www.lavoixdunord.fr/economie/fraude-des-comptes-bancaires-pirates-au-cred...

&nbsp;http://www.lesechos.fr/19/05/2014/lesechos.fr/0203505817494\_comptes-bancaires-pi...



&nbsp;



J'aime bien que ma banque m'explique comment fonctionne mon moyen de paiement et avoir un interlocuteur qui prend contact avec moi quand mon compte bancaire passe en découvert non-autorisé. Et j'aime la presse qui tente d'expliquer comment tout ça fonctionne (Next inpact, cbanque, meilleurebanque, CPChardware par exemples).


Comme çà, il n’y aurait qu’une seule cible à faire tomber ?

Et qui est responsable de la sécurité entre cette solution centralisée et les différentes banques ?


L’idée n’est pas anti jeunisme. C’est juste qu’un chef de projet, sur des appli critiques, vaut mieux qu’il ai un peut de bouteille. Quant il est tout frais (moins de 6 mois comme il dit), tu prend bien plus de risque.



Après comme pour tout y a des exceptions.


Ah ok, si tu parles effectivement d’un gros problème de connaissances et communications alors je suis entièrement d’accord.



J’ai un exemple aussi: ma carte visa a été utilisé pour faire des achats en ligne (je me demande bien d’où vient la fuite…). Évidemment, j’ai fait opposition, et donc ma carte a été désactivée.



Par contre ma nouvelle carte à mis du temps à être disponible: le lot de nouvelles cartes a été perdues/volées au niveau du transporteur… mais çà je ne l’ai jamais su officiellement, çà leur à échappé oralement… c’est dingue tout de même. Même quand ce n’est pas complètement de leur faute, il ne faut pas communiquer.


Oui enfin le cahier des charges et les specs elles ne sont pas à la charge du chef de projet théoriquement… ou au moins, il doit y avoir des validations par la direction/hiérarchie.


triste époque


Ça fait seulement quelques années que je vois la sécurité venir sur le devant de la scène.



C’est ralenti aussi par le fait du “pourquoi en changer, ça marche très bien comme ça”, dans certaines boîtes où j’ai bossé, le mot de passe principal était le même car “codé en dur” dans certains binaires et trop complexes à changer partout et bien sur mot de passe en clair dans les fichiers de conf.



Donc en gros si t’as bossé pour cette boîte, tu vas chez n’importe quel de leur client, tu peux faire tout ce que tu veux car le mot de passe est le même, et vu l’appli, tu peux en tirer un bon bénéf.



C’est toujours basé sur le ratio “coût/risque” mais d’année en année le risque augmente, d’ailleurs on le voit avec la fréquence des leak de données.


Là, on a quand même des problèmes technique. Donc si c’est à la charge du chef de projet. Même s’il est pas le seul responsable.


La première des sécurités de N26, c’est surtout qu’on ne peut pas s’y inscrire à cause d’un processus de vérification d’identité calamiteux et un SAV aux oubliettes.


Il veut dire par là que l’on laisse les banques juger elles-même de la qualité de leur sécurité, sans avoir de comptes à rendre. Pour “qu’il en soit autrement,” il suffit d’introduire dans le processus un tiers régulateur et des sanctions.



Le fond du problème ici est l’externalisation du risque : ce n’est pas la banque elle-même qui souffre d’une faible sécurité. Améliorer cela réduit les revenus de la banque. Elle n’a donc aucune motivation pour corriger sa sécurité. La régulation, tellement détesté par la finance, est une façon d’écrire dans la loi que la banque a la responsabilité de la sécurité financière de ses clients, et donc qu’elle peut être sanctionnée. Du coup, le risque est réinternalisé (la banque paye pour ses manquements) et la situation s’améliore.








DetunizedGravity a écrit :



Il veut dire par là que l’on laisse les banques juger elles-même de la qualité de leur sécurité, sans avoir de comptes à rendre. Pour “qu’il en soit autrement,” il suffit d’introduire dans le processus un tiers régulateur et des sanctions.



Le fond du problème ici est l’externalisation du risque : ce n’est pas la banque elle-même qui souffre d’une faible sécurité. Améliorer cela réduit les revenus de la banque. Elle n’a donc aucune motivation pour corriger sa sécurité. La régulation, tellement détesté par la finance, est une façon d’écrire dans la loi que la banque a la responsabilité de la sécurité financière de ses clients, et donc qu’elle peut être sanctionnée. Du coup, le risque est réinternalisé (la banque paye pour ses manquements) et la situation s’améliore.





ah bon si une faille de sécurité est exploitée ce n’est pas la banque qui en paye le prix?









megadub a écrit :



Etre mal payé ne justifie pas de faire un boulot de merde et en principe, même débutant, tu es sensé être formé à ton métier. Du reste, s’il suffisait d’avoir des développeurs de tout premier ordre et du personnels sur payés pour éviter les failles, ça se saurait <img data-src=" />





ce que je voulais dire c’est un confirmé ou senior tu le gardes pas avec un bas salaire du coups ils se cassent de la boite et tu te retrouves avec une armée de newbie. C’est ce qui arrive dans ma boite.









ndjpoye a écrit :



Là, on a quand même des problèmes technique. Donc si c’est à la charge du chef de projet. Même s’il est pas le seul responsable.







Non pas forcément: si les specs se limitent au HTTPS sans vérification autre du certificat que “c’est un certificat valable” alors le chef de projet n’y est pour rien.

S’il a soutenu l’idée comme étant bonne, oui il y est pour quelque chose.







DetunizedGravity a écrit :



Il veut dire par là que l’on laisse les banques juger elles-même de la qualité de leur sécurité, sans avoir de comptes à rendre. Pour “qu’il en soit autrement,” il suffit d’introduire dans le processus un tiers régulateur et des sanctions.



Et qui va payer pour çà ? Et comment le tiers trouve les failles ? Avec un audit ? Sur ce genre d’infra ca ne se règle pas en 2 jours un audit <img data-src=" /> , à multiplier par le nombre de banque…









DetunizedGravity a écrit :



Le fond du problème ici est l’externalisation du risque : ce n’est pas la banque elle-même qui souffre d’une faible sécurité. Améliorer cela réduit les revenus de la banque. Elle n’a donc aucune motivation pour corriger sa sécurité. La régulation, tellement détesté par la finance, est une façon d’écrire dans la loi que la banque a la responsabilité de la sécurité financière de ses clients, et donc qu’elle peut être sanctionnée. Du coup, le risque est réinternalisé (la banque paye pour ses manquements) et la situation s’améliore.







Mais on a beaucoup d’exemple de piratage bancaire via les accès clients ?

Je vois beaucoup de monde ici se plaindre, mais finalement elle est où la grande news de détournement de fond massif ?









joma74fr a écrit :



Par exemple,




Quand on lit dans la presse qu'il n'y pas de soucis de sécurité avec la CB et que par ailleurs j'ai subi en tant que client des irrégularités alors que mes interlocuteurs bancaires étaient dans l'impossibilité de m'expliquer clairement comment fonctionne ma CB (les plafonds de paiement/retrait, le découvert autorisé ou non mais qui passe quand même, etc),        

&nbsp;

Quand j'ai entendu par ailleurs l'AFUB dénoncer une fraude conséquente chez des clients du Crédit mutuel Nord Europe et de La Banque postale et que les services de banque en ligne de La Banque postale ont progressivement mis en place des limites aux virements (délai de 48h pour enregistrer un nouveau bénéficiaire, limite de quelques milliers d'euros par virement), alors que j'aurais préféré être prévenu de ces changements et que j'aurais préféré que La Banque postale me propose une solution de sécurité beaucoup plus "user-friendly" comme font d'autres banques (limites paramétrables par le client lui-même, contact avec un interlocuteur qui gère le compte de son client et qui assure un vrai service payant),

&nbsp;https://www.facebook.com/AFUBofficiel/videos/vb.260069017422394/568208869941739/

&nbsp;http://www.leparisien.fr/espace-premium/actu/alerte-a-la-fraude-au-credit-mutuel...

&nbsp;http://www.lavoixdunord.fr/economie/fraude-des-comptes-bancaires-pirates-au-cred...

&nbsp;http://www.lesechos.fr/19/05/2014/lesechos.fr/0203505817494\_comptes-bancaires-pi...

&nbsp;

J'aime bien que ma banque m'explique comment fonctionne mon moyen de paiement et avoir un interlocuteur qui prend contact avec moi quand mon compte bancaire passe en découvert non-autorisé. Et j'aime la presse qui tente d'expliquer comment tout ça fonctionne (Next inpact, cbanque, meilleurebanque, CPChardware par exemples).







En l’occurrence, ces fraudes n’ont rien à voir avec ma conception des sites ou la sécurité du portail web. Si j’ai bien saisi pour le crédit mutuel le problème vient de l’envoi des identifiants par courrier, courriers qui ont été interceptés, et à la banque postale c’est un “bête” phishing.&nbsp;



Non, ce qui pose problème c’est surtout qu’en principe, une telle fraude n’a qu’un impact très limité pour le client qui a systématiquement le bénéfice du doute le temps de l’enquête. C’est là la défaillance pour ces 2 banques.









the_frogkiller a écrit :



ah bon si une faille de sécurité est exploitée ce n’est pas la banque qui en paye le prix?





Ca dépend. Si c’est une fraude sur la CB c’est Visa ou Mastercard qui supporte le risque. Pour le reste, j’imagine que les banques contractent des assurances pour couvrir ce risque :)



Il est tout aussi légal de dire “On déchiffre tout pour notre propre sécurité et les accès aux données déchiffrées sont contrôlés suivant le cadre légal. Si vous allez sur votre site bancaire dans ces conditions, c’est votre problème.”

Dès lors que ce cadre est posé, il n’y a plus d’obligation d’exclure quoi que ce soit.

Dans la même veine, pour éviter les conflits, il est aussi légal de dire: “On déchiffre tout, et on interdit complètement les sites bancaires (et quelques autres du même genre inutiles pour votre boulot) comme ça vous ne viendrez pas vous plaindre qu’on vous espionne.”

Ce qui est important, c’est de poser officiellement les règles. Une entreprise n’a pas d’obligation légale de respecter la tolérance habituelle en termes d’utilisation personnelle de l’accès Internet en France, du moment que ses employés sont au courant des règles, et qu’elles ne sont pas discriminatoires. C’est seulement si elle choisi d’être tolérante qu’elle a intérêt d’exclure les sites bancaires, administratifs, etc., pour éviter les conflits au prud’hommes.


Certes, s’il y a une faille ça touche tout le monde mais en même temps, quand elle est corrigée, elle l’est pour tout le monde. Parce que bon, dans les faits, les failles sont plus souvent dans les protocoles ou les api quand dans le code lui-même, donc de toute façon, une faille touche un grand nombre de site.


Mais là tu parles d’une grosse boîte avec un process de développement bien défini.

Dans la vraie vie les boîtes comme N26 recrutent 10 personnes pour lancer le projet et basta, les specs sont données par des personnes qui n’y connaissent techniquement rien, la sécurité est gérée par des mecs qui ont probablement des notions mais qui ne sont pas experts, et comme toujours l’emploi du temps est très serré donc pas le temps de se former proprement.


Pour le coup ça me paraîtrait normal qu’une banque soit dans l’obligation de faire passer un audit de sécurité par un organisme indépendant à ses frais. Ca fait un peu partie des choses dont tu dois tenir compte quand tu finances ton projet et ça ne devrait pas être un problème que la banque supporte les coûts.



J’ai même envie d’aller plus loin, le produit devrait recevoir une certification type EAL4+ ou un truc similaire.


La régulation ça commence déjà par faire porter par la banque le dédommagement des pertes subies par ses clients qui prouvent qu’ils ont été fraudés (c’est partiellement implémenté). Ensuite, tu peux imposer aux banques la réalisation d’audits one shot ou réguliers &gt;&gt;à ses frais&lt;&lt; pour être autorisée à fournir certains services. Les audits sont faits par des entreprises tierces spécialisées. C’est un modèle qui marche bien et qui est utilisé dans un nombre incalculable de cas de figure aujourd’hui, pas seulement bancaires. Les points importants à surveiller sont que le coût de l’habilitation ne soit pas exorbitant au point d’empêcher l’entrée de nouveaux acteurs, et que les autorités certifiantes soient bel et bien indépendantes des intérêts économiques et financiers des entreprises à certifier.


“Pour celle qui se décrit sur son site&nbsp;comme «&nbsp;la banque la plus moderne d’Europe&nbsp;»”



Faudra qu’on m’explique en quoi elle est plus moderne qu’une autre banque en ligne type boursorama?



Elle est plus chère, impose un nombre limite de retraits par mois dans les distributeurs…








megadub a écrit :



Certes, s’il y a une faille ça touche tout le monde mais en même temps, quand elle est corrigée, elle l’est pour tout le monde. Parce que bon, dans les faits, les failles sont plus souvent dans les protocoles ou les api quand dans le code lui-même, donc de toute façon, une faille touche un grand nombre de site.





Oui mais non… si la faille permet de s’attaquer à toutes les banques d’un coup, j’imagine le désastre.

Et puis je me répète, mais elles sont où les grandes attaques de banque via les accès web clients ?







ErGo_404 a écrit :



Mais là tu parles d’une grosse boîte avec un process de développement bien défini.

Dans la vraie vie les boîtes comme N26 recrutent 10 personnes pour lancer le projet et basta, les specs sont données par des personnes qui n’y connaissent techniquement rien, la sécurité est gérée par des mecs qui ont probablement des notions mais qui ne sont pas experts, et comme toujours l’emploi du temps est très serré donc pas le temps de se former proprement.





Oui je suis d’accord. Mais ce n’est pas une raison pour tout coller sur le chef de projet donc.







ErGo_404 a écrit :



Pour le coup ça me paraîtrait normal qu’une banque soit dans l’obligation de faire passer un audit de sécurité par un organisme indépendant à ses frais. Ca fait un peu partie des choses dont tu dois tenir compte quand tu finances ton projet et ça ne devrait pas être un problème que la banque supporte les coûts.



J’ai même envie d’aller plus loin, le produit devrait recevoir une certification type EAL4+ ou un truc similaire.







Les banques font déjà des audits de sécurité… je ne crois pas qu’elles aient envie de se manger des millions d’euros qui fuient <img data-src=" /> frais, mauvaise pub etc.

Imposer des certifications est une bonne idée, d’ailleurs il y a déjà des règles qui sont imposées.












DetunizedGravity a écrit :



La régulation ça commence déjà par faire porter par la banque le dédommagement des pertes subies par ses clients qui prouvent qu’ils ont été fraudés (c’est partiellement implémenté).





C’est déjà le cas non ? Pourquoi partiellement ? (vrai question)

Donc il n’y a pas de problème ici…







DetunizedGravity a écrit :



Ensuite, tu peux imposer aux banques la réalisation d’audits one shot ou réguliers &gt;&gt;à ses frais&lt;&lt; pour être autorisée à fournir certains services.





Les banques font déjà des audits. Les banques ont même souvent des audits permanents, et pas seulement sur l’infra informatique.







DetunizedGravity a écrit :



Les audits sont faits par des entreprises tierces spécialisées. C’est un modèle qui marche bien et qui est utilisé dans un nombre incalculable de cas de figure aujourd’hui, pas seulement bancaires. Les points importants à surveiller sont que le coût de l’habilitation ne soit pas exorbitant au point d’empêcher l’entrée de nouveaux acteurs, et que les autorités certifiantes soient bel et bien indépendantes des intérêts économiques et financiers des entreprises à certifier.







Merci je sais ce qu’est un audit, et les banques en font déjà. Ce n’est pas pour çà que les failles seront complètement éliminées. Je n’ai absolument rien contre les audits, mais çà n’est en rien une solution miracle ! C’est là où je veux en venir.









the_frogkiller a écrit :



ah bon si une faille de sécurité est exploitée ce n’est pas la banque qui en paye le prix?







Je pense que la réponse correcte est: “ça dépend”. Il n’est pas toujours facile de déterminer qui est le responsable/fautif:

* Une faille de sécu de la banque?

* Le laxisme moyen de l’interface chaise clavier dans la gestion de ses identifiants?

* Une faille de sécu dans l’O.S. du téléphone que le client a utilisé pour accéder au service en ligne?

* Une 0day dans un protocole que tout le monde croyait sûr jusque là, ce qui fait que la banque peut dire de bonne foi avoir fait tout ce que la loi lui imposait?

* Etc.



Et si on n’impose pas une certaine transparence à la banque (régulation!), il devient impossible de répondre à cette question. Et ça commence par une obligation faite aux entreprises (dont les banques) de déclarer aux autorités les intrusions dans leurs système (Je ne sais plus où nous en sommes dans ce domaine en France), et la mise en œuvre de normes comme PCI DSS, etc.









ErGo_404 a écrit :



Pour le coup ça me paraîtrait normal qu’une banque soit dans l’obligation de faire passer un audit de sécurité par un organisme indépendant à ses frais. Ca fait un peu partie des choses dont tu dois tenir compte quand tu finances ton projet et ça ne devrait pas être un problème que la banque supporte les coûts.



J’ai même envie d’aller plus loin, le produit devrait recevoir une certification type EAL4+ ou un truc similaire.





EAL4+ ? On aura vachement moins de banques <img data-src=" />



J’y connais pas grand chose, j’ai sorti ce nom là parce que c’est ce que j’ai vu dans un précédent boulot.

Mais la finance est la base de notre société (que l’on trouve ça bien ou pas), ça serait pas mal que cette base soit fiable.


MAis enfait il y a déjà des normes et audit/controles…



Exemple: ACPR

Un pdf Quelques infos


Le problème est que le dev doit faire son taf de dev et pas s’improviser architecte. En l’occurrence il manque sûrement ce genre de profil chez N26 (ou alors il est super mauvais) pour définir tous les aspects d’une application


Je ne prétends pas non plus décrire une solution miracle. Tous les athéistes présents seront d’accord avec moi sur le fait que, de toutes façons, les miracles ça n’existe pas. Ce n’est pas le sujet.



Mon intervention était en réponse à “je ne vois pas comment il pourrait en être autrement” (que laisser la sécurité des banques aux seules mains des banques). Et bien voilà, comme ça. Il en est autrement, comme ça. Réglementations, obligations d’audit, charge de la preuve et obligation de rembourser qui pèsent par défaut sur la banque dans certains cas, etc. Les banques ont des comptes à rendre sur leur sécurité et elles se voient partiellement dicter par des tiers comment l’implémenter. C’est tout ce que je dis.








jackjack2 a écrit :



Un point anti-jeunisme primaire pour toi, bravo

Tu veux qu’on parle des vieux qui pètent plus haut que leur cul et qui savent tout mieux que toi parce qu’ils ont travaillé avant que tu naisses, ou tu admets que la stupidité et l’incompétence ne dépendent pas de l’âge?



Si c’est un vieux troll très bonne pêche cependant





Ah non j’ai rien contre les jeunes, les nôtres sont pas compétant, mais les mecs au dessus d’eux le sont tout aussi, c’est ça qui est beau.&nbsp; et comme je dis plus haut vu que l’on prend les dev le moins cher possible on aura jamais des bon (quand certains qui sont compétents voient qu’ils seraient payé en 1.5 et 2 fois plus cher chez le concurrent, ils se barrent vite fait)



Pas de certificate pinning sur une appli bancaire c’est un peu chaud. Après pour réussir un MITM sur du TLS il faut quand même parvenir à installer son certificat sur la machine cible, ce qui est loin d’être gagné sans accès physique.



Edit: après y’a pire, bien pire :phttps://boris.in/blog/2016/the-bank-job/








CryoGen a écrit :



Non pas forcément: si les specs se limitent au HTTPS sans vérification autre du certificat que “c’est un certificat valable” alors le chef de projet n’y est pour rien.

S’il a soutenu l’idée comme étant bonne, oui il y est pour quelque chose.



Tes specs technique, elle provienne de qui ?

Si y la pas le pouvoir sur ca, chef de P, il en a que le titre. C’est peut être sur ce point qu’on diverge.



Architecte cela ne veut rien dire seul, cela peut être un architecte solution, technique généraliste, web, mobile, infra… En soit, ce n’est pas le role de l’architecte d’être un expert securité.&nbsp; Il y a des rôles pour cela, notamment l’officier de sécurité.&nbsp;



J’aimerai à penser que le secteur bancaire est suffisament reglementé pour imposer des audits de sécurités.


D’après la video, c’est surtout possible après le détournement DNS.&nbsp; Par contre il ne dit pas comment il fait pour avoir un certificat valide sur le domain détourné. A moins que l’app accepte les certificats self signed, ce qui serait quand même étonnant.


pour résumer les boites feraient mieux d’investir dans la sécurité digitale plutôt que dans le marketing digital.


Pour la sécurité digitale, je préconise des gants, pour éviter aux doigts de nombreux problèmes. <img data-src=" />



—–



Sur l’appli de ma banque, la Caisse d’Epargne, il y a un suivi des comptes (le solde par exemple) sans connexion nécessaire. (Oui, c’est bien mis à jour sans la connexion.)

J’ai bien envie d’aller écouter les requêtes, je sens que je vais être surpris. <img data-src=" />








t1nt1n a écrit :



Edit: après y’a pire, bien pire :phttps://boris.in/blog/2016/the-bank-job/





<img data-src=" />









ndjpoye a écrit :



Tes specs technique, elle provienne de qui ?

Si y la pas le pouvoir sur ca, chef de P, il en a que le titre. C’est peut être sur ce point qu’on diverge.







Oui c’est ce que je dis. Si le cdp c’est vu imposer des specs limitées/pourries ce n’est pas de sa faute. S’il a omis ce point, alors c’est de sa faute.



Du coup on est sur la même longueur d’onde :)



Au temps pour moi, je faisais plusieurs trucs à la fois en plus de lire NextInpact, j’ai effectivement mal compris ton message <img data-src=" />

On est bien d’accord du coup <img data-src=" />








Nithril a écrit :



D’après la video, c’est surtout possible après le détournement DNS.&nbsp; Par contre il ne dit pas comment il fait pour avoir un certificat valide sur le domain détourné. A moins que l’app accepte les certificats self signed, ce qui serait quand même étonnant.





Ben oui, c’est ce qu’il dit : pas de certificate pinning = l’app acceptait tout les certif. (edit : je dis peut-etre une bêtise et que ce n’est pas lié au fait que le certif soit épinglé ou non).

Mais de toute façon, il faut considérer que le MiTM est toujours possible (modification de l’APK / Android bidouillé etc.) et protéger l’API en conséquence. Chose qui ne l’était pas.





Vincent Haupert a confirmé que plus aucune des vulnérabilités signalées ne subsistait



Euh il me semble qu’il dit ne pas avoir vérifié pourtant <img data-src=" /> (c’est plus très frais dans ma tête, je l’ai visionné en live)









Nithril a écrit :



D’après la video, c’est surtout possible après le détournement DNS.  Par contre il ne dit pas comment il fait pour avoir un certificat valide sur le domain détourné. A moins que l’app accepte les certificats self signed, ce qui serait quand même étonnant.







Pas obligatoirement de certificat autosigné, mais valide suffit.







scientifik_u a écrit :



Ben oui, c’est ce qu’il dit : pas de certificate pinning = l’app acceptait tout les certif. (edit : je dis peut-etre une bêtise et que ce n’est pas lié au fait que le certif soit épinglé ou non).







L4épinglage signifie qu’on se fout que le certificat soit valide (via autorité) ou auto signé : l’application attend un seul certificat en particulier (un peu comme en ssh)







Stackexchange a écrit :



Typically certificates are validated by checking the signature hierarchy; MyCert is signed by IntermediateCert which is signed by RootCert, and RootCert is listed in my computer’s “certificates to trust” store.



Certificate Pinning is where you ignore that whole thing, and say trust this certificate only or perhaps trust only certificates signed by this certificate.







Source



En quoi le cobol serait moins securitaire ?

Les trous de sécurité sont tous au niveau de la couche d’échange avec un éventuel traitement sur du mainframe.


A quoi ça sert de corriger des failles si le service n’est même pas utilisable ?








CryoGen a écrit :



Pas obligatoirement de certificat autosigné, mais valide suffit.







Pour qu’il soit valide, il faut qu’il soit signé pour le domaine cible. Compliqué d’en avoir un mais faisable a priori.

http://security.stackexchange.com/a/3859

&nbsp;









scientifik_u a écrit :



Ben oui, c’est ce qu’il dit : pas de certificate pinning = l’app acceptait tout les certif. (edit : je dis peut-etre une bêtise et que ce n’est pas lié au fait que le certif soit épinglé ou non).

Mais de toute façon, il faut considérer que le MiTM est toujours possible (modification de l’APK / Android bidouillé etc.) et protéger l’API en conséquence. Chose qui ne l’était pas.





Pas de certificate pinning = l’application accepte tous les certificats tant qu’ils sont signés par les CA (certificate authorities) présents sur le device. Cela ne veut pas dire qu’elle accepte même les certificats auto signé car la c’est d’un autre niveau niveau négligence.



Ton argument sur le Cobol n’est pas vraiment valide. SI tu as regardé la vidéo de la conférence, tu peux voir qu’à aucun moment il ne s’attaque à l’application qui tourne sur les serveurs de N26. Il exploite des failles dans le protocole. Donc que ce soit codé en Cobol, C, PHP ou JS n’y change absolument rien.


De plus, bien qu’il y ait 3 tonnes de règlements (c’est effectivement le cas ‘^_^), peu de vérifications externes sont réalisées (pour ainsi dire, aucune). Et N26, disposant d’une licence bancaire, doit se conformer aux même règlements que les autres banques.


Des exemples d’exploitations de failles de sécurité on n’en a pas beaucoup car dès que la banque s’en rend compte elle prend sur ses fonds propres (ils provisionnent pour ce genre de risques), replace les sous sur les comptes clients ni vu ni connu, et l’affaire est glissée sous le tapis.

Ca fait quand même les gros titres de temps en temps :http://www.leparisien.fr/corbeil-essonnes-91100/a-corbeil-800-000-eur-detournes-…


Pas besoin d’installer son certificat sur la machine cliente. Il “suffit” de compromettre les enregistrements DNS (plusieurs méthodes, telles que le DNS cache poisonning) pour que l’adresse voulue (api.tech26.de dans le cas présent) pointe vers ton serveur, et obtenir un certificat signé par une autorité (l’exemple de let’s encrypt est utilisé dans la conférence, mais d’autres autorités ont délivrés des certificats à des pirates par le passé…).


Oui alors là, c’est de la grosse négligence interne, pas un hack depuis l’extérieur via le site d’accès client. En gros la porte était ouverte, il est entré.


J’ai mis le premier lien que j’ai trouvé, et bien que ça ne passe pas par le web-banking, ça reste dû à un manquement dans la politique de sécurité informatique interne de LBP.

Je travaille dans la sécurité informatique, j’ai eu pas mal de banques (et pas qu’en France) parmi mes clients, et je peux te garantir que les équipes en charge de rattraper la fraude ne chôme pas ;-)


Non, sérieusement ? sans dec ? ils en étaient là ? vraiment ?



Oulala… la base de la sécu même pas respectée ? la base de la monétique non considérée ? <img data-src=" />



Et après ça vient parler des grands groupes bancaires… j’ai un sérieux doute sur leur sérieux a eux aussi.



Effectivement, il ne faut pas confondre vitesse et précipitation <img data-src=" />








CryoGen a écrit :



Enfin les attaque MITM c’est un classique tout de même. Surtout que là, là communication était bien en HTTPS mais sans vrai contrôle du certificat !?! C’est pratique pour passer les proxy d’entreprise qui font de la désencapsulation https pour le filtrage/antivirus mais c’est tout. Quitte à faire çà, on ajoute une couche d’identification des serveurs par l’appli et du chiffrement.







Pour les communications HTTPS des employés, c’est pas le proxy d’entreprise, et non la machine de l’employé, qui opère habituellement la négociation TLS et l’échange de clés ? Donc l’entreprise serait à priori en mesure de savoir ce qui transite entre l’extérieur et la machine de son employé ?



Oui l’entreprise le peut, d’une méthode similaire à un Man In The Middle.

C’est assez pratique en réalité : possibilité d’appliquer des règles de filtrage, possibilités d’exécuter des antivirus, QoS etc. La plus part du temps, çà ce limite à çà : aucun humain ne peut accéder au contenu de ce que l’utilisateur visite. D’ailleurs, la loi en France (Europe ?) demande à ce que les sites bancaires soient exemptés de ce “déchiffrement” à la volée.



Le proxy intercepte la requête du client, et se charge de négocier le “tunnel https”, il chiffre à nouveau la connexion entre lui et le client sur le LAN via son propre certificat.


Car l’age et le nombre de mainteneurs de cette techno, ainsi que son design non pensé pour les archi actuelles le rendent potentiellement moins sûr.