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.
Face à des attaques internes de plus en plus nombreuses, la sécurité des infrastructures réseaux est un enjeu central pour garantir la confidentialité et l’intégrité des données ainsi que la continuité des activités d’une organisation.
Il existe plusieurs moyens d’évaluer la sécurité d’un réseau interne. Dans cet article, nous vous présentons l’approche « offensive » qui reste, selon nous, la plus efficace : les tests d’intrusion interne (ou pentest interne). Nous y détaillons les principes et objectifs ainsi que des use cases de tests d’intrusion en boite noire et grise d’un réseau interne.
Lorsque nous visitons un site web, il est courant de pouvoir parcourir différentes pages. Chaque page peut être représentée par un fichier sur le serveur. Afin de déterminer quel fichier fournir, l’application a besoin que le client spécifie le fichier qui l’intéresse. Pour cela, il arrive que la page souhaitée par l’utilisateur soit présente dans un paramètre de la requête.
Face à des attaques de plus en plus nombreuses et élaborées, la sécurité des applications web est un enjeu majeur. En effet, la sécurité revêt aujourd’hui une importance capitale pour rassurer et fidéliser des clients, ou convertir des prospects.
Il existe plusieurs moyens d’évaluer la sécurité d’une application web. Dans cet article, nous vous présentons l’approche « offensive » qui reste, selon nous, la plus efficace : les tests d’intrusion web (ou pentest web). Nous y détaillons les principes et objectifs ainsi que des use cases de tests d’intrusion en boite noire, grise et blanche sur diverses cibles.
Pour faciliter la tâche aux développeurs, de nombreux frameworks intègrent des fonctionnalités qui associent automatiquement les paramètres d’une requête HTTP à des variables liées à un objet dans le code de l’application.
Une vulnérabilité de type Mass Assignment survient lorsque le serveur ne filtre pas correctement les données transmises par l’utilisateur et les associe directement à un objet sans vérification.
Dans un précédent article, nous avions passé en revue la vulnérabilité la plus critique des applications web selon le Top 10 OWASP : le défaut de contrôle d’accès. Aujourd’hui, nous nous attaquons aux vulnérabilités et exploitations courantes liées au manque ou à l’absence de chiffrement dans les applications.
Récemment, un de nos clients nous a demandé d’examiner son pipeline d’intégration et de déploiement continu (CI/CD), déployé sur une infrastructure AWS.
Dans cet article, nous allons montrer comment un développeur disposant d’un accès limité à GitLab aurait pu élever ses privilèges et accéder à des informations sensibles permettant de prendre le contrôle de l’infrastructure AWS et causer des dommages importants à l’organisation. Nous détaillerons également des bonnes pratiques et mesures à implémenter pour contrer ce type de risques.
Dans un précédent article, nous avons vu pourquoi il était important de stocker les mots de passe en base de données avec des fonctions de hachage robustes telles que Bcrypt et Argon2. Cela permet notamment de rendre totalement ineffectif des attaques brute force ou des attaques par dictionnaire.
Cependant, une problématique est régulièrement relevée sur des applications déjà existantes : comment utiliser les dernières recommandations sur le stockage des mots de passe sur une base de données déjà existante ?
