Avec l’augmentation du risque cyber, il devient de plus en plus évident de réaliser un pentest (test d’intrusion) pour rassurer clients, partenaires et investisseurs.
De plus, pour les entreprises engagées dans un processus de certification ou une démarche ISO 27001, SOC2, HDS, PCI-DSS, etc., un pentest est un impératif. Et pour les autres, une condition sine qua non pour satisfaire les demandes de rapport de pentest de leurs clients et prospects.
Vous connaissez certainement le phishing qui consiste à envoyer des emails malveillants pour inciter les destinataires à réaliser des actions sensibles, comme renseigner leurs identifiants de connexion VPN sur une fausse page d’authentification par exemple.
Le smishing est quasiment identique, à ceci près que l’attaquant n’envoie non pas des emails, mais des SMS, d’où le nom de smishing. Essentiellement, le smishing est ni plus ni moins que du phishing par SMS.
Burp est un outil incontournable en sécurité offensive. En effet, il s’agit d’un logiciel utilisé par une majorité de professionnels (dont les pentesters que nous sommes) et dédié notamment aux pentests d’applications web.
Dans cet article, nous passerons en revue les principales fonctionnalités (les modules fondamentaux), extensions clés et spécificités de Burp Suite.
Les mots de passe restent le moyen le plus répandu pour authentifier un utilisateur. Cependant, mettre en place un système de gestion des mots de passe à la fois simple et suffisamment sécurisé peut parfois s’avérer délicat.
En effet, la fonctionnalité de réinitialisation de mot de passe est une cible intéressante pour un attaquant, puisque mal implémentée, elle peut faciliter le vol de comptes utilisateurs.
Dans un environnement de bureau, les postes utilisateurs utilisent généralement le système d’exploitation Windows et s’authentifient donc via des protocoles développés par Microsoft.
Et pour centraliser la gestion de l’authentification, Microsoft propose son Active Directory (AD) qui s’appuie sur le protocole Kerberos. Cependant, certaines machines n’implémentent pas ce protocole et certains réseaux ne sont tout simplement pas pourvus d’un Active Directory. Dans ces cas de figure, il existe le protocole NTLM, qui peut fonctionner entre deux machines sans AD ou via le processus Netlogon.
Les APIs sont des cibles de choix pour les attaquants en raison de leur exposition et de leur caractère « critique », notamment en termes de manipulation de données sensibles. De fait, pour minimiser le risque de failles de sécurité, il est impératif de mettre en œuvre des mesures de sécurité robustes, de comprendre les types d’attaques et d’évaluer leur impact potentiel.
Il existe plusieurs moyens d’évaluer la sécurité d’une API. Dans cet article, nous vous présentons l’approche « offensive » qui reste, selon nous, la plus efficace : les tests d’intrusion d’API (ou pentest API). Nous y détaillons les principes et objectifs ainsi que des use cases de pentest en boite noire, grise et blanche.
Les applications mobiles sont de plus en plus utilisées dans tous les domaines d’activités : RH, finance, assurances, transports, etc. De fait, elles constituent des cibles de choix pour les attaquants.
Il existe plusieurs moyens d’évaluer la sécurité d’une application mobile. Dans cet article, nous vous présentons l’approche « offensive » qui reste, selon nous, la plus efficace : les tests d’intrusion mobile (ou pentest mobile). Nous y détaillons les principes, objectifs ainsi que la méthodologie et les éléments testés lors de tests d’intrusion d’application mobile.
Avant de présenter des cas pratiques autour des problèmes de CORS, il est important de définir plusieurs points. D’abord, expliquer le principe de la same origin policy (SOP), puisque le mécanisme des CORS vient modifier ces règles en les rendant plus souples. On expliquera ensuite le fonctionnement des CORS. Enfin nous aborderons des cas pratiques de problèmes de configurations.
Exploiter une vulnérabilité RCE pour un pentester, c’est un peu le graal. En fonction du contexte, il existe de nombreuses techniques pour exécuter du code à distance et donc exploiter une RCE.
Au-delà du principe de ce type de vulnérabilité, nous vous présentons dans cet article des exemples d’attaques et d’exploitations de RCE ainsi que les bonnes pratiques et mesures à implémenter pour se protéger.
La mauvaise configuration de sécurité est un problème préoccupant puisqu’il occupe la cinquième place du Top 10 de l’OWASP. En effet, nous rencontrons assez fréquemment de nombreuses vulnérabilités de ce type lors de nos tests d’intrusion d’application web. Par ailleurs, cette problématique sécurité toucherait un grand nombre d’applications web (90% selon l’OWASP).
Dans cet article, nous vous présentons ce type de failles à travers le prisme de l’OWASP Top 10, et ce via des scénarios d’attaques. Nous y détaillons également les bonnes pratiques et les mesures à mettre en œuvre pour s’en prémunir.
Les composants tiers sont omniprésents dans les applications web. En effet, librairies, frameworks et autres composants système sont de plus en plus utilisés car ils permettent de réduire les coûts et de faciliter les développements.
Cependant, comme tout système, ces composants tiers peuvent contenir des vulnérabilités exploitables lors d’attaques sur des applications web. De plus, les exploits découverts, et souvent rendus public, peuvent avoir un effet boule de neige et ainsi compromettre l’intégralité d’une application web, les serveurs, les systèmes de base de données, etc.
Le phishing est toujours aussi redoutable, car il mêle de plus en plus souvent des compétences techniques pointues et des connaissances clés de certains ressorts psychologiques humains. Ce faisant, les attaquants les plus chevronnés arrivent assez facilement à inciter leurs cibles à ouvrir un email malveillant avant de les pousser au clic.
Chez Vaadata, nous réalisons régulièrement des campagnes de phishing dans le cadre d’audits d’ingénierie sociale. Aujourd’hui, nous vous ouvrons les coulisses de notre métier afin de vous sensibiliser aux risques de phishing.
La plupart des applications intègrent une fonctionnalité, au demeurant critique, permettant d’identifier les utilisateurs. L’objectif : garantir la confidentialité et l’intégrité de leurs données. Parmi les méthodes couramment utilisées pour permettre au serveur d’identifier un utilisateur, figurent les cookies de session, les tokens JWT, ou, dans certains cas, des solutions personnalisées.
De fait, la logique de génération de ces jetons de session est essentielle car, en cas de contournement ou de détournement, cela peut aboutir à un vol de compte et donc à des impacts critiques sur la sécurité des données voire à la compromission totale du système.