Category

Technique

Category

Alternative du Bluetooth
classique, le Bluetooth Low Energy est choisi de manière croissante pour l’IoT.
Cette technologie, aussi connue sous l’abréviation BLE, s’impose de plus en
plus pour l’Internet des objets parce qu’elle est idéale pour envoyer de
petites quantités de données entre appareils et pour préserver la batterie ;
ce qui correspond parfaitement aux besoins de l’IoT. Le Bluetooth classique, de
son côté, reste utilisé pour envoyer de grande quantité de données entre un
appareil et l’utilisateur (les casques et enceintes sans fil se servent du
Bluetooth par exemple).

Bluetooth Low Energy et sécurité

Si ces deux protocoles Bluetooth
sont utilisés à des fins différentes et ne sont pas compatibles, ils restent
toutefois dans une certaine mesure similaires parce qu’ils ont des technologies
(software et hardware) communes, comme celles qui gèrent l’appairage. Ainsi,
les responsables sécurité doivent garder en tête que les failles de sécurité
touchant le Bluetooth classique, affectent parfois aussi le Bluetooth Low
Energy, mais que ce dernier garde néanmoins ses spécificités et donc des
failles qui lui sont propres.

Nous sommes particulièrement heureux et fiers d’annoncer que nous sommes à présent officiellement certifiés CREST pour nos services de tests d’intrusion.

Vaadata devient la première entreprise de pentest française certifée CREST

Cette
certification démontre notre engagement à offrir des services professionnels de
pentest de haut niveau. Elle atteste que Vaadata respecte des processus et des procédures
appropriés pour réaliser des tests d’intrusion ainsi que pour garantir la
protection des informations de ses clients.

Les périphériques USB sont tellement pratiques. Lorsque l’on a besoin de stocker des petites quantités de données, nous utilisons une clé USB. Tout le monde en a une, et nous leur faisons confiance. Les clés USB sont l’un des moyens principaux pour faire de l’espionnage industriel, mais les attaques au hasard contre des civils et des entreprises sont également courantes.
Le rapport Honeywell 2018 sur les menaces USB pour les opérateurs industriels (en anglais) a analysé un échantillon de 50 sites. Energie, chimie, pâte et papiers, pétrole et gaz et autres secteurs industriels étaient concernés par l’étude. Parmi les sites ciblés, 44 % ont bloqué un fichier suspect venant de ports USB, et 15 % des menaces détectées et bloquées étaient des menaces de haut niveau, comme Stuxnet, Wannacry et Mirai.

Attaques par port USB

Une expérience conduite sur le campus de l’université Illinois Urbana-Champaign en 2016 a montré que sur les 297 clés USB déposées dans l’université, les étudiants et membres du personnel en ont ramassé 98 %.  Pour près de la moitié des clés ramassés, quelqu’un les a branchées et a cliqué sur un fichier. Un sondage est ensuite mené auprès des personnes ayant utilisé les clés USB. 68 % des répondants n’ont pris aucune mesure de sécurité en branchant la clé USB. 68 % déclarent avoir pris un périphérique pour le redonner et 18% l’ont pris par curiosité. Cette étude montre à quel point un simple périphérique USB peut être dangereux.

La sécurité des objets connectés est un sujet d’actualité, cependant les tests d’intrusion IoT sont encore loin d’être une pratique généralisée. La plupart des constructeurs priorisent d’abord les fonctionnalités et le design du produit. Cependant, même avec une approche « security by design », le test d’intrusion reste incontournable pour connaître les risques de sécurité réels, puis pour prendre les mesures nécessaires.

Pentest Internet of Things : 10 types de tests hardware and software

Qu’est-ce qu’un pentest IoT ?

Un objet connecté est une solution complexe, avec différents points d’entrée potentiels pour un attaquant. Un audit de sécurité d’objet connecté (ou pentest IoT) comprend des tests sur l’ensemble de l’écosystème de l’objet, c’est-à-dire : la couche électronique, le logiciel embarqué, les protocoles de communication, le serveur, les interfaces web et mobiles. Les tests côté serveur, interfaces web et applications mobiles ne sont pas spécifiques à l’IoT, cependant ce sont des tests importants, car il s’agit de pans particulièrement à risques. Les tests côté électronique, logiciel embarqué et protocoles de communication concernent des vulnérabilités plus spécifiques à l’IoT.

Il existe trois types d’attaques spécifiques sur les objets connectés et les systèmes embarqués. Les attaques software, les attaques hardware non invasives et les attaques hardware invasives. Les premières profitent des failles logicielles, les secondes récupèrent des informations du hardware sans l’endommager tandis que les dernières impliquent l’ouverture des composants et donc leur destruction pour pouvoir en tirer des secrets. Si les deux premiers types d’attaques ne nécessitent pas beaucoup de moyens, ce n’est pas le cas des attaques invasives pour lesquelles des équipements très coûteux sont nécessaires.

Voici dix types de tests concrets conduits lors de l’audit de sécurité d’un objet connecté, illustrés par quelques exemples médiatisés et emblématiques. Pour chaque point abordé ci-dessous, il existe de nombreux outils et méthodes qui profitent de failles très diverses. Il s’agit donc d’une liste non exhaustive.

Qu’est-ce qu’une attaque Cross Site Request Forgery ?

L’attaque CSRF (ou en français falsification de requête intersite) est une attaque qui oblige un utilisateur final à exécuter des actions non désirées et sans qu’il s’en rende compte sur une application web dans laquelle il est actuellement authentifié.
Les attaques CSRF visent spécifiquement les demandes de modification et non le vol de données, car l’attaquant n’a aucun moyen de voir la réponse à la demande falsifiée. Le résultat des actions est ce qui intéresse l’attaquant.

Ce type d’attaque s’appuie sur le fait que lorsqu’un utilisateur est authentifié sur une application, celle-ci lui fournit la plupart du temps un identifiant de session, stocké dans un cookie sur son navigateur.

Nous pensons souvent qu’un pare-feu suffisamment restrictif protège l’accès aux services non ouverts. Nous croyons aussi que seule une machine compromise peut donner accès au reste du réseau interne.

Et bien nous avons tort, et c’est ce que nous allons voir avec une vulnérabilité des applications web : le Server-Side Request Forgery (SSRF).

Qu’est-ce que les SSRF ?

A partir d’une application web vulnérable, les SSRF permettent d’interagir avec le serveur, afin d’en extraire des fichiers et de trouver ses autres services actifs. Mais cela ne s’arrête pas là. Il est également possible de scanner le réseau interne afin d’en cartographier les IP et Ports ouverts.

Durant nos audits il nous arrive encore très souvent de rencontrer des énumérations utilisateurs qui pourraient avec les bonnes méthodes être facilement évitées. Dans cet article, nous traiterons des énumérations d’utilisateurs sur les formulaires de connexion, de réinitialisation de mot de passe et de création de compte. Cependant, les énumérations utilisateur peuvent se trouver sur d’autres fonctionnalités, telles que, par exemple, des formulaires de recherches ou des envois de messages.

Description

Définition

Une énumération d’utilisateur permet comme son nom l’indique de trouver des identifiants de connexion utilisateurs valides sur une application. Pour ce faire, un attaquant tentera d’entrer un certain nombre de noms d’utilisateurs et observera le comportement de l’application pour déterminer si un identifiant est valide ou non (message d’erreur différent, temps de réponse différents et plus généralement toute différence au niveau réponse HTTP).

Pour constituer une liste de candidats, un attaquant pourra par exemple essayer de trouver des adresses email ou des personnes liées à sa cible sur des moteurs de recherche ou sur les réseaux sociaux.

Pourquoi cela pose problème

Cela pose problème tout d’abord parce que si un attaquant trouve un identifiant utilisateur valide, il pourra l’utiliser pour affiner ses attaques. Il pourra par exemple tenter une attaque par bruteforce sur le formulaire de connexion de la plateforme si celui-ci est vulnérable à ce type d’attaque, ou bien encore cibler plus spécifiquement les personnes identifiées avec des attaques par phishing.

account found - security

Qui est concerné

Il est vrai que sur les formulaires de connexion cette vulnérabilité est assez rare à l’heure actuelle. Cependant, elle reste assez répandue sur les formulaires de réinitialisation de mots de passe et encore plus sur les formulaires de création de compte.

Afin d’effectuer cette démonstration, nous avons développé une application vulnérable sous PHP qui contient un formulaire de connexion, un formulaire de réinitialisation de mot de passe ainsi qu’un formulaire de création de compte.

Sous PHP, la méthode principale pour gérer des sessions utilisateurs est l’utilisation de cookies de sessions appelés par défaut « PHPSESSID ». Lorsqu’un utilisateur se connecte sur une application, celle-ci demande la génération d’un identifiant de session au programme PHP présent sur le serveur Web. Celui-ci s’exécute et créé un code unique qu’il va stocker dans sa mémoire vive puis renvoyer au client grâce au header « Set-Cookie ». Les cookies étant conçus pour être automatiquement renvoyés dans chaque requête du navigateur vers le serveur, l’identifiant de session sera transmis systématiquement. Cette solution permet de gérer les cas classiques de connexion/déconnexion d’un utilisateur.

Cependant, ce type de fonctionnement ne permet pas de partager facilement un même compte pour s’authentifier sur plusieurs plateformes distinctes et le serveur a l’obligation de stocker l’état et les informations des sessions dans sa mémoire vive.

Les jetons JWT quant à eux sont “stateless”, cela signifie que les informations des sessions ouvertes ne sont pas stockées côté serveur. Outre le gain de mémoire que cela procure, les jetons JWT peuvent être utiles si vous souhaitez utiliser les mêmes comptes utilisateurs pour plusieurs applications. Il suffira que les applications utilisent la même clé privée pour signer et vérifier les jetons JWT. Les utilisateurs pourront ainsi s’authentifier une fois sur l’application hébergeant les comptes utilisateurs, puis ils pourront se connecter aux autres applications, celles-ci n’ayant qu’à vérifier la validité des jetons.

Description

Les « JSON Web Token » ou JWT sont des jetons générés par un serveur lors de l’authentification d’un utilisateur sur une application Web, et qui sont ensuite transmis au client.

Ils seront renvoyés avec chaque requête HTTP au serveur, ce qui lui permettra d’identifier l’utilisateur.

Pour ce faire, les informations contenues dans le jeton sont signées à l’aide d’une clé privée détenue par le serveur. Quand il recevra à nouveau le jeton, le serveur n’aura qu’à comparer la signature envoyée par le client et celle qu’il aura générée avec sa propre clé privée et à comparer les résultats. Si les signatures sont identiques, le jeton est valide.

Structure d’un jeton JWT

Si la norme RFC 7519 est bien respectée, un jeton JWT se compose de cette façon :
Une partie “Header”, contenant l’algorithme utilisé pour la signature ainsi que le type de jeton (dans notre cas toujours “JWT »), en JSON encodé en Base64
Une partie “Payload” contenant les informations du jeton, comme par exemple le nom de l’utilisateur, la date d’émission du jeton ou sa date d’expiration le tout en JSON encodé en Base64
Une partie “Signature”, qui correspond à la concaténation des parties “Header” et “Payload” chiffrée avec la clé privée.

Cette série d’articles aborde les points les plus importants de la sécurité des applications mobiles, quelle que soit la plateforme (iOS, Android ou autre).
L’objectif est de démystifier les différents aspects de la sécurité mobile, avec des mots très simples.

Ce troisième épisode présente les failles liées aux échanges de données

Une application mobile fonctionne rarement en mode non-connecté. Une exception pourrait être une application de type dictionnaire, qui n’a pas besoin de communiquer avec un quelconque serveur pour fonctionner : toutes les données sont déjà présentes dans l’application et l’utilisateur affiche des définitions de mots du dictionnaire.

Mais il s’agit d’un cas bien spécifique, car la plupart des applications mobiles communiquent avec un serveur web.

Données échangées par l’application mobile

Suivant les besoins métier, une application mobile peut être amenée à envoyer ou recevoir différents types de données, comme par exemple :

  • Identifiants de connexion
  • Données de session utilisateur
  • Données personnelles
  • Données transactionnelles liées au métier de l’application
  • Données bancaires

Comment les données sont-elles échangées avec l’extérieur ?

Suivant les cas, différents flux de données peuvent être présents au sein d’une même application.
Prenons l’exemple d’une application ecommerce permettant à ses utilisateurs d’acheter des articles, et de laisser des commentaires.

Les différentes données transférées peuvent être :

  • Données d’identification de l’utilisateur
  • Statistiques d’utilisation de l’application
  • Données relatives aux commentaires sur les produits

Flux de données d'une application mobile

Dans notre exemple, trois serveurs interagissent avec l’application. Certains flux contiennent des données sensibles, d’autres non.

Cette série d’articles aborde les points les plus importants de la sécurité des applications mobiles, quelle que soit la plateforme (iOS, Android ou autre).
L’objectif est de démystifier les différents aspects de la sécurité mobile, avec des mots très simples.

Ce second épisode présente les failles liées au stockage non sécurisé des données.

Une application mobile peut stocker différents types d’informations :

  • Données de géolocalisation
  • Transactions
  • Identifiants ou tokens d’authentification
  • Données personnelles (PII)
  • Données métier
  • Données mises en cache (stockage temporaire)

Comment les données sont-elles stockées sur l’application?

En fonction de la plateforme (iOS, Android…), différents moyens de stockage peuvent être utilisés. Base de données, fichiers plats, fichiers XML, fichiers Plist, carte de stockage type SD… Des emplacements différents pour des contextes différents.
De plus, les données peuvent être cryptées, plus ou moins efficacement.