Failles détectées

Les cartes à puce que nous avons testées nous ont révélé quelques vulnérabilités et des cas de non-conformité à la spécification, parmi ces cas :

Autorisation d’ajout ou de suppression d’une ressource : nous avons remarqué que cer-taines cartes acceptent les commandes PUT et DELETE et les commandes d’administration. La commande PUT permet de créer ou de modifier une ressource et la commande DELETE permet de supprimer une ressource. Ces commandes d’administration sont destinées à être utilisées par l’émetteur de la carte (administrateur de l’application) qui accède de manière sécurisée au serveur de la carte à puce pour effectuer des tâches telles que l’ajout ou la suppression d’un utilisateur, mo-dification d’un fichier de configuration etc. L’ensemble de ces tâches ne devrait pas être accessible par l’utilisateur qui pourrait effectuer des modifications malintentionnées dans le but d’augmenter ses privilèges (par exemple : augmenter le nombre de points sur une application de fidélité) ou attaquer la carte d’une tiece personne. Certaines cartes à puce testées ont révélé des failles dans cette propriété. En effet, l’envoi de la requête PUT a permis d’ajouter une ressource HTML dans la carte. Afin de vérifier que la modification a bien été prise en compte, nous avons exécuté une re-quête GET qui demande de retourner la page HTML ajoutée. Nous avons constaté que la réponse de la carte contenait bien dans son corps, la page HTML que nous avions ajoutée. La fonction DELETE est aussi autorisée, nous avons réussi à supprimer cette ressource de la carte.

Génération d’une exception Java : une erreur au niveau de la carte peut engendrer un code d’erreur de type 6F XX qui correspond à une exception Java. Pour des raisons de sécurité, les cartes à puce masquent les détails de l’erreur en retournant dans tous les cas d’exception Java, le code 6F 00. Les résultats obtenus ont révélé que les cartes à puce SCWS testées génèrent une exception Java (6F 00) suite à l’injection d’une requête vide.

Réponse HTTP non conforme à la spécification : comme présenté précédemment, notre outil permet de détecter des non conformités avec la spécification, lorsque les réponses du serveur à des requêtes bien spécifiées ne correspondent pas à ce qui est prévu dans la spécification. Parmi les résultats de notre analyse nous avons constaté que lors de l’envoi d’un entêteIf-Matchinvalide, les cartes repondent par le code d’erreur HTTP 500 qui signifie qu’une erreur interne au serveur s’est produite, alors que la carte doit envoyer une erreur HTTP 501 (Non implémenté) ou une erreur HTTP 400 (requête incorrecte).

Implémentation incomplète : le respect de la conformité à une spécification consiste égale-ment à vérifier que tous les champs obligatoires sont bien impléégale-mentés. Les résultats obtenus ont montré que les cartes testées n’implémentent pas correctement certaines règles définies dans la spécification :

– Le champ Host qui définit le domaine de l’application ciblé est obligatoire à partir de la version HTTP/1.1. Les tests que nous avons effectués en injectant une requête sans inclure ce champ obligatoire n’a engendré aucune erreur.

– Le dernier entête d’une requête HTTP et son corps doivent être séparées par deux retours à la ligne. Les résultats que nous avons obtenus montrent que cette règle est ignorée dans les

cartes SCWS que nous avons testé. En effet, en envoyant une requête sans respecter cette règle la carte renvoie la réponse APDU90 00signifiant que la transaction s’est bien déroulé mais la réponse ne contient aucune réponse HTTP (pas de réponse du serveur SCWS).

Les tests que nous avons réalisé sur des cartes à puces Java Card 3 ont révélé que seules les méthodes GET et POST étaient implémentées, alors que selon la spécification de Java Card 3, cette plateforme est basée sur le protocole HTTP/1.1, qui définit les méthodes GET, POST, HEAD comme les méthodes qui DOIVENT être obligatoirement implémentées. Cependant, ne s’agissant que du premier et unique prototype (à notre connaissance), il était très probable que l’implémentation ne soit pas complète. L’outil que nous avons proposé permet de faire un audit des serveurs Web embarquées dans les cartes à puce. Cependant, il serait intéressant dans des travaux futurs de tenter d’exploiter ces failles pour effectuer des attaques.

9.5 Conclusion

Dans ce chapitre, nous avons exploré l’efficacité de la méthode de fuzzing pour découvrir des vulnérabilités ou des erreurs de mise en œuvre du protocole HTTP embarqué dans une carte à puce. Nous avons utilisé le logiciel Peach pour développer notre outil qui génère des données de test de manière intelligente grâce à l’utilisation de nos propres modèles de données et des modèles d’état. Notre outil est dédié à tout type de serveurs Web, y compris les serveurs Web embarqués basés sur SCWS ou la plateforme Java Card 3. Nous utilisons l’approche en boîte noire. Pour cela, notre applicationPyHAT est utilisée pour découvrir toutes les fonctionnalités mises en œuvre sur la cible, afin de limiter, par la suite, notre analyse aux seules propriétés existantes, et rendre ainsi notrefuzzingplus performant avec un temps d’exécution réduit.

Cependant, les cartes à puce ont une faible bande passante, pour améliorer encore plus la performance de notre analyse, nous avons appliqué unfuzzing parallèle sur de multiples cartes à puce. Les résultats expérimentaux ont démontré l’efficacité de nos propositions dans la réduction du temps d’exécution. L’analyse automatique des résultats dufuzzingqui est basée sur la comparaison entre les réponses du serveur et de la carte avec un ensemble de motifs bien définis a permis de détecter des vulnérabilités et des non conformités à la spécification RFC 2616 du protocole HTTP implémenté dans des cartes à puce. L’analyse sauvegarde l’ensemble des séquences complètes de requêtes qui ont conduit à une vulnérabilité.

Quatrième partie

Conclusions et perspectives

Chapitre 10

Conclusions et perspectives

Sommaire

10.1 Problématique . . . . 148 10.2 Principales contributions . . . . 148 10.3 Perspectives . . . . 149 10.3.1 Analyse des applications Web . . . 149 10.3.2 Fuzzing HTTP . . . 151 10.4 Synthèse générale . . . . 152

Les cartes à puce à serveur Web embarqué constituent une grande évolution. Grâce à cette nouvelle technologie, la carte devient accessible à une multitude de développeurs via un modèle de programmation basé sur des servlets. Ainsi, les délais de déploiement de nouveaux services sont sensiblement réduits. D’autre part, les services fournis par ces dispositifs sont beaucoup plus faciles d’usage à travers des interfaces graphiques ergonomiques, accessibles à l’utilisateur à partir du navigateur Web installé sur le terminal (téléphone par exemple). Les cartes à serveur Web embarqué offrent également la possibilité d’administrer à distance les applications installées sur la carte de manière sécurisée et une connexion à des applications distantes via une authentification robuste fournie par la carte.

Malgré tous ces avantages, cette nouvelle technologie n’a toujours pas connu l’évolution atten-due, les spécifications étant sorties depuis 2008. En effet, d’une part l’utilisation des plateformes Java Card 3 nécessite des dispositifs haut de gamme, de performances beaucoup plus élevées que la plupart des cartes utilisées dans le monde ; et d’autre part, la plateforme SCWS dédiée à des cartes classiques, ne supporte pas les protocoles TCP/IP. Elle utilise d’autres protocoles plus adaptés tel que BIP. Il est donc nécessaire que le matériel auquel la carte sera connectée soit doté d’un protocole spécifique pour assurer la compatibilité entre les deux parties. Cependant, nous pensons qu’avec la nouvelle technologie des cartes NFC, les cartes à serveur Web embarqué vont finir par susciter l’intérêt des industriels. De plus, la vitesse à laquelle la technologie évolue laisse à croire que les cartes haut de gamme ne vont pas tarder à remplacer les cartes classiques.

10.1 Problématique

Dans le cadre de cette thèse, nous nous sommes intéressés à la sécurité de ces nouveaux disposi-tifs. L’ouverture de la carte au standards du Web oblige à reconsidérer toute la sécurité des cartes à puce. En effet, de nouveaux protocoles (par exemples : TCP/IP, BIP et HTTP) doivent être nécessairement implémentés dans la carte pour assurer sa communication avec le navigateur Web et les différents nœuds du réseau. Des failles d’implémentation de ces protocoles peuvent engendrer des vulnérabilités qui pourraient mettre en péril la sécurité de la carte à puce.

D’autre part, les vulnérabilités peuvent être causées par des failles d’implémentation des ap-plications Web chargées dans ces cartes. Ces apap-plications fournissent des interfaces qui facilitent l’interaction avec l’utilisateur. Avec les nouvelles technologies de génération de contenus dyna-miques (JavaScript, AJAX, etc.), nous pouvons considérer que l’utilisateur contribue à la création de contenus dans des applications Web. En effet, il ne se limite pas à consulter des informations mais il publie aussi du contenu (texte, vidéo, musique). Les applications Web fournissent des points d’accès à partir desquels l’utilisateur est invité à entrer des données. Une personne malintentionnée peut donc exploiter ces points d’entrée pour injecter des données malicieuses dans l’application.

Les attaques Web classiques exploitant les technologies du Web n’arrêtent pas de se multiplier et les cartes à puce à serveur Web embarqué n’en sont pas à l’abri.