Dans l’article précédent, nous avons vu ce qu’est une vulnérabilité SSRF et comment, de manière générale, celle-ci peut être exploitée. Pour cela, nous nous étions placés dans un cadre théorique assez simple, mais différents éléments (soit dus à la nature de la vulnérabilité ou à des implémentations de sécurité) peuvent rendre la tâche plus compliquée.

Dans cet article, nous allons voir diverses méthodes permettant d’aller plus loin. Au programme :

• Différentes méthodes de contournement manuel de
  filtres ;
• SSRFMap : un outil d’exploitation semi-automatique

Maintenant que nous avons introduit quatre fonctionnalités centrales de Burp Suite dans l’article précédent, nous allons aller un peu plus loin avec quelques fonctionnalités et extensions qui peuvent augmenter la qualité d’un audit et votre efficacité.

Les fonctionnalités et captures
d’écran présentées dans cet article correspondent à la version Professional
2.1.01.

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).

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.

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.

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.
A chaque fois que l’utilisateur envoie une requête vers le serveur, le navigateur envoie également automatiquement ce cookie de session. Vous trouverez dans l’article lié plus d’informations à propos des attaques CSRF.

Notez bien qu’il suffit que l’utilisateur soit resté connecté (sans avoir une page ou un onglet du site ouvert) pour qu’une attaque CSRF fonctionne.

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.

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.

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