Exemple (inattendu?) de fuite d’information de données cartes

Thierry ZOLLER a publié un exemple de fuite d’information de données cartes.

La cause : Génération de “truncated Pan” sur différents systèmes de paiement

Les bonnes pratique de sécurité sur les “Truncated Pan”  ne prennent généralement pas en compte l’existence de multiples systèmes de paiement dont les concepteurs ont une certaine latitude pour  “choisir” quels numéros de la carte doivent être tronqués

Résultats: Cf. copie d’écran sur le blog de Thierry ZOLLER: http://blog.zoller.lu/2011/12/pci-compliance-security-in-isolated.html

Il existe donc un risque de compromission des numeros de cartes car il “serait” possible de reconstruire un numero de PAN complet en collectant plusieurs TRUNCATED PAN générés par  différents systemes de paiement (si ces derniers n’appliquent pas les bonnes pratiques de sécurité , Cf doc VISA http://usa.visa.com/download/merchants/PAN_truncation_best_practices.pdf)

 

 

Malicious Use Case Analysis : ou comment limiter les failles applicatives dites ‘de business logic’

Une récente publication du centre de recherche Microsoft montre quelques exemples de faiblesse de sécurité fonctionnelle (Logic flaw ou business logic flaw). L’étude porte sur certains processus de paiement offerts par plusieurs grands fournisseurs et sur l’implémentation coté sites marchands.

Les chercheurs ont ainsi démontré au moins 9 vulnérabilités ayant comme origine des failles dans la logique applicative liée au processus de paiement ou aux choix d’implémentation fait par les marchands.

Les principales causes remontées par l’étude sont:

• Le manque de validation des interactions et des échanges d’informations entre les parties prenantes du paiement : l’acheteur (ou son navigateur), le site du marchand en ligne (son application web E-commerce), le fournisseur de paiement (les services exposés)
• Le manque de contrôle sur l’intégrité des données, l’authentification de l’origine des demandes de transaction, …
• La complexité d’intégration des modules/fonctions de paiement

Nous vous recommandons la lecture de cette publication pour plus de détail : http://research.microsoft.com/apps/pubs/?id=145858

Faille de logique fonctionnelle : Les solutions ?

Selon notre expérience, les outils de détection de vulnérabilité ne peuvent que (très) difficilement pointer ce type de faiblesse. Une analyse humaine nous semble généralement plus appropriée et surtout (beaucoup) plus efficace.

Dans ce contexte,  il est  possible d’effectuer une analyse que nous appelons : « Malicious use case analysis».

La notion de « Malicious use case» n’est pas neuve (http://www.acsac.org/1999/papers/wed-b-1030-john.pdf)  mais mériterait peut-être plus d’attention dans le cadre de la mise en place  des  cycles de développement sécurisé (ou SDLC pour  Secure Developpement Life Cycle).

En synthèse, l’objectif est d’analyser les interactions entre les différents acteurs/modules applicatifs et de bâtir des scénarios d’attaque.

Le moyen ?

Il est possible d’utiliser les « use case diagrams » (ou un autre équivalent méthodologique)

et de simuler fonctionnellement les scénarios d’attaque :

Quelques exemples (dans le contexte de l’étude des paiements en ligne)

• Que se passe-t-il si un « acheteur » modifie son ID de transaction ?
• Est-il possible de de renvoyer à la plate-forme de paiement un ID de transaction différent avec un autre message de paiement authentifié mais d’un autre achat effectué par le même  acheteur (malicieux !)
• Etc…

Il s’agit :

• De déterminer les risques de contournement (et donc les impacts financiers ou métiers) dès les phases de conception des applications Web :
• De définir les points de contrôle nécessaire à la sécurisation des échanges (contrôle d’origine des requêtes, contrôle de l’authentification des demandeurs et des valeurs de transactions…) en fonction des scénarios d’attaque définis

En prenant un raccourci, il s’agit en quelque sorte de réaliser un test d’intrusion fonctionnel !

Outre le fait de limiter les vulnérabilités, cette démarche offre d’autres avantages : cette activité facilite l’intégration des besoins de sécurité :

• Dans les processus de développement au niveau des spécifications fonctionnelles
• Dans le respect des méthodologies utilisées plus particulièrement par les équipes de développement

L’acceptation des mesures de sécurité à mettre en place est donc souvent plus simple (et donc plus efficace)

Opale Security reste à votre disposition pour vous accompagner dans la sécurisation de vos applications Web au niveau technique et… fonctionnel.

La sécurité des systèmes embarqués (SSE) : un domaine à appréhender?

La sécurité des systèmes embarqués (SSE) est un domaine qui semble moins souvent prise en compte  que les aspects directement liés de sécurité des SI (SSI) :

•  Il existe peu de sites dédiés à ce sujet (pas d’équivalent de l’OWASP  à notre connaissance), ce domaine reste donc  globalement assez marginalement traité.
• Même si on voit pointer, ici ou là, un intérêt grandissant dans la communauté des  « chercheurs » en sécurité, cette problématique est très peu incluse dans les politiques de sécurité des entreprises utilisatrices.
• Enfin, souvent les industriels eux même semblent parfois peu concernés. Ainsi, quand on discute avec des ingénieurs de conception de leur  prise en compte des menaces, les réactions restent…comment dire…classiques : « Combien ça va me couter en temps de conception ces recommandations de sécurité  !?… Nous utilisons le SSL Monsieur !… cela ne nous vous rappelle rien ?

Bref, SSE et Maturité…(ou pas)

Pourtant, selon notre expérience, aussi bien sur les aspects offensif que défensif, ce domaine mériterait plus d’attention car si on fait une rapide analyse, on s’aperçoit que :

• Ces équipements deviennent omniprésents dans les systèmes d’information professionnels ou privés et tout simplement dans la vie de tous les jours (téléphone mobile, badge d’accès, passeport, carte de paiement sans fil, box de connexion à Internet…).
• De plus en plus d’objets deviennent communiquant (alarme, vêtement, carte de crédit, voiture …).
• Ils vont (sont déjà !) tous plus au moins connecter aux réseaux classiques (Internet, UMTS, 3/4G, RFID, NFC…) et  sont donc en contact avec les nombreuses menace associées
• Les systèmes embarqués fonctionnent avec des ressources et des fonctions de sécurité souvent plus limitées que les systèmes traditionnels (moins de mémoire, pas forcément de fonction de sécurité OS tel que ASLR, est-il utile de parler du patch management ou encore de la sensibilisation des équipes de développement hardware et software de systèmes embarqués…)

Mais quel est leur niveau réel de sécurité ?

•  Sont-ils capables de résister aux attaques classiques ?
• Offrent-ils de nouvelles opportunités pour les cybercriminels ?
• Comment auditer ou évaluer la robustesse de tels systèmes ?
• Quelles sont les méthodes de conception qui permettraient de limiter les vulnérabilités ?

C’est pourquoi, nous vous proposons dans les semaines avenir, une série d’article consacrés à ce vaste domaine : la SSE (Sécurité des Systèmes embarqués) ; aussi bien sur les aspects offensif (un peu) que défensif.

Sachez aussi, qu’OPALE SECURITY proposera sous peu des formations liées à l’audit ou à la sécurisation des systèmes embarqués.

Formation à destination à toutes personnes qui pourraient être intéressées par ce domaine dans le cadre de ses activités (pas de prérequis en électronique, nous créons une formation simple, pratique et adaptée à des personnes connaissant déjà la SSI). Vous pouvez nous contacter directement si cela vous intéresse formation@opale-security.com

Plus de détail sur http://www.opale-security.com/securisation-systemes-embarques.html

Obligation de notification des failles de sécurité à la Cnil ?

Selon un nouveau texte législatif paru courant août (Ordonnance n° 2011-1012 du 24 août 2011 relative aux communications électroniques), les entreprises ayant subi une « violation de données à caractère personnel » auraient de nouvelles obligations légales. Il est précisé que « Pour l’application du présent article, on entend Toute violation de la sécurité entraînant accidentellement ou de manière illicite la destruction, la perte, l’altération, la divulgation ou l’accès non autorisé à des données à caractère personnel ». (Il s’agit ici de l’article 38)

Les nouvelles obligations seraient :

Lorsque cette violation peut porter atteinte aux données à caractère personnel ou à la vie privée d’un abonné ou d’une autre personne physique, le fournisseur avertit également, sans délai, l’intéressé

La notification d’une violation des données à caractère personnel à l’intéressé n’est toutefois pas nécessaire si la Commission nationale de l’informatique et des libertés a constaté que des mesures de protection appropriées ont été mises en œuvre par le fournisseur afin de rendre les données incompréhensibles à toute personne non autorisée à y avoir accès et ont été appliquées aux données concernées par ladite violation.

A défaut, la Commission nationale de l’informatique et des libertés peut, après avoir examiné la gravité de la violation, mettre en demeure le fournisseur d’informer également les intéressés.

Chaque fournisseur de services de communications électroniques tient à jour un inventaire des violations de données à caractère personnel, notamment de leurs modalités, de leur effet et des mesures prises pour y remédier et le conserve à la disposition

L’impact pour les entreprises semble double:

1. Obligation de notification à la CNIL en cas de faille ayant entrainée une violation de la sécurité des données personnelles
2. Obligation de réaction pour prouver à la CNIL que les mesures prises permettent de remédier à la violation

PCI DSS & Virtualisation : de nouvelles obligations ?

Le PCI DSS Council  est l’organisme en charge du standard PCI DSS. Il vient de publier un nouveau document précisant les règles de sécurité à appliquer dans un environnement virtualisé: de nouvelles et nombreuses obligations en perspective !

Source : https://www.pcisecuritystandards.org/documents/Virtualization_InfoSupp_v2.pdf

Il est à noter que la notion de virtualisation est prise dans un sens très large par le PCI DSS Council : Bien évidement cela concerne la Virtualisation des systèmes d’exploitation (OS) mais aussi des réseaux, des systèmes de stockage (NAS/SAN) et… de la mémoire !  Les recommandations devraient donc s’appliquer à tous ces types de virtualisation; cependant la virtualisation des OS semble plus particulièrement visée.

Voici un résumé du contenu :

Le document explique quels sont les critères qui permettent d’inclure (ou d’exclure) les environnements virtualisés dans (du) périmètre PCI DSS. Ensuite, il est  précisé les  « nouvelles obligations associées » à la sécurisation des technologies de virtualisation. D’après notre compréhension,  Il semble notamment nécessaire :

1. De faire une analyse de risque spécifique de vos environnements virtualisés
2. De conduire une évaluation sécurité de la technologie de virtualisation que vous avez choisie (bilan des forces et faiblesses, capacité de la technologie à couvrir les menaces, choix des options de sécurisation à mettre en place,  formalisation de ces choix…)
3. De mettre en place des séances de formation de vos équipes de production/Sécurité pour les sensibiliser aux risques spécifiques associés à la virtualisation
4. D’auditer les flux de communications interne à votre environnement virtualisé (sorte de matrice des flux virtualisés!)
5. De créer des procédures de sécurisation renforcée de vos environnements virtualisés (Hôte, Hyperviseur, machine virtuelle, Console d’administration…)
6. De mettre en place des autorisations d’accès renforcées sur ces environnements (Notamment pour respecter le principe de séparations des privilèges)

 Nous restons à votre disposition pour vous accompagner dans le cadre de la sécurisation de vos environnements, notamment ceux soumis à PCI DSS.