Problème de sécurité de l’API 157

Cette semaine, nous avons des détails sur une vulnérabilité potentielle dans les installations Prometheus existantes sans aucune sécurité des points de terminaison activée, les détails d’un nouvel outil pour aider les organisations à cartographier leur surface d’attaque API, un rapport sur l’analyse des fichiers de définition OpenAPI disponibles publiquement dans le domaine public , et des nouvelles sur la sensibilisation et la formation à venir en matière de sécurité des API de We Hack Purple.

Vulnérabilité : valeurs par défaut dangereuses dans Prometheus Expose Secrets

JFrog a récemment publié un rapport sur une vulnérabilité potentielle dans Prometheus, une solution open source populaire de surveillance et d’alerte d’événements. Les attaquants pourraient analyser les points de terminaison non sécurisés pour récupérer des données sensibles.

Auparavant, les métriques n’étaient pas du tout considérées comme sensibles, mais dans la version 2.24.0, la prise en charge de TLS et l’authentification de base ont été ajoutées. Malheureusement, étant donné qu’il s’agit d’une fonctionnalité relativement nouvelle (la version 2.24.0 est sortie en janvier 2021) et que de nombreuses installations du domaine public utilisent encore une version plus ancienne, JFrog conclut que l’exfiltration de données à grande échelle est toujours possible actuellement.

Les auteurs décrivent certaines techniques élémentaires de collecte de renseignements utilisant Shodan et ZoomEye pour ingérer les données de plus de 27 000 hôtes. Leurs conclusions comprenaient :

• Des informations opérationnelles sensibles telles que les noms d’utilisateur et les mots de passe ont été exposées.
• 15,6 % des terminaux avaient des interfaces d’administration exposées et non sécurisées.

Les principaux points à retenir ici sont :

• Si vous êtes préoccupé par l’exposition involontaire d’informations, activez à la fois l’authentification de base et TLS dans votre configuration Prometheus.
• Méfiez-vous des paramètres par défaut dans n’importe quel système, leur niveau de sécurité peut ne pas être ce que vous voulez et peut avoir des conséquences imprévues.

Outils : outil gratuit pour cartographier la surface d’attaque de l’API

Le vieil adage « vous ne pouvez pas améliorer ce que vous ne pouvez pas mesurer » s’applique tout aussi bien à la sécurité : vous ne pouvez pas sécuriser ce que vous ne connaissez pas. La sécurité des API n’est pas une bête différente ici.

La découverte d’API est de plus en plus sous le feu des projecteurs car elle permet aux organisations de comprendre l’étendue de leur exposition aux risques découlant de leur patrimoine d’API. Dans les organisations complexes, la grande variété d’API internes et externes, les choix de langage de programmation et de framework, et les environnements d’hébergement ou de cloud peuvent rendre cela, ou même estimer votre surface d’attaque, une entreprise difficile. Le résultat le plus probable est une estimation sauvage de « doigt en l’air ».

Heureusement, il existe un calculateur de surface d’attaque API gratuit pour vous aider à démarrer. Il vous permet d’obtenir une estimation (bien que très basique) de votre surface d’attaque API basée sur quelques paramètres de base facilement identifiés. Bien qu’il ne s’agisse pas d’un outil de découverte à proprement parler, entreprendre une telle estimation devrait être éclairant en soi : quels sont les éléments connus, quels sont les éléments inconnus, où davantage d’informations sont nécessaires et par où une organisation doit-elle commencer avec son initiative de sécurité des API.

Rapport : Analyser les tendances dans les fichiers OpenAPI

L’adoption croissante de la norme OpenAPI Specification (OAS) au cours de la dernière décennie a entraîné un grand nombre de fichiers de définition OpenAPI dans les référentiels publics.

Dans un rapport fascinant, gracieuseté des API nordiques, la société de sécurité australienne Assetnote a analysé plus de 200 000 fichiers OpenAPI accessibles au public, dans le but de découvrir les tendances et les modèles sous-jacents.

En résumé, voici quelques-unes des principales conclusions :

• 79 % des définitions d’API sont des définitions OpenAPI valides (conformes à la norme), ce qui est de bon augure pour la poursuite de l’adoption de l’OEA dans son ensemble.
• Les API sont de plus en plus complexes : en moyenne, chaque API avait 37 chemins et 51 points de terminaison.
• Naturellement, GET est la méthode la plus fréquemment utilisée, suivie par POST.
• La plupart des API ont tendance à privilégier l’authentification de base, suivi des méthodes de clé API. Chose assez inquiétante, la troisième option la plus populaire est n’ayant aucune sécurité!

Formation : We Hack Purple offre une sensibilisation et une formation à la sécurité des API

L’intérêt continu pour la sécurité des API se reflète dans la disponibilité de nouvelles offres de formation de qualité.

Cette semaine, nous avons des nouvelles d’un Événement de sensibilisation à la sécurité des API, mettant en vedette Isabelle Mauny (CTO terrain de 42Crunch) dans une conversation avec Tanya Janca (alias. @shehackspurple) dans le cadre du nouveau Nous piratons le violet académie et communauté.

Le prochain mini-cours de la communauté We Hack Purple intéressera également les praticiens de la sécurité des API. J’ai hâte de présenter le cours dans ce bulletin une fois qu’il sera disponible.

Vous pouvez vous inscrire à cette newsletter sur APIsecurity.io.