Lors de son analyse hebdomadaire, le scan externe peut faire remonter des vulnérabilités. Ces dernières sont affichées dans l'onglet « Infrastructure » de Stoïk Protect.
Pour accéder au contenu relatif à une vulnérabilité spécifique – description, ressources concernées, comment la corriger – cliquez sur celle-ci dans la liste ci-dessous :
Password authentication enabled
WordPress Core < 4.7.1 - Username Enumeration (CVE-2017-5487)
Subdomain takeover
De manière simple
Une exploitation réussie de ce type de vulnérabilité permet à un adversaire de revendiquer et de prendre le contrôle du sous-domaine de la victime.
La prise de contrôle d'un sous-domaine est possible dans diverses applications, telles que Github, Shopify, Netlify, Wix et AWS S3 bucket.
D'un point de vue technique
- L'enregistrement du sous-domaine du serveur DNS externe de la victime est configuré pour pointer vers une ressource/service externe/endpoint inexistant ou non actif. La prolifération des produits XaaS (Anything as a Service) et des services de Cloud publics offre de nombreuses cibles potentielles qu'il faut surveiller ;
- Le fournisseur de services qui héberge la ressource/le service/le point de terminaison externe ne gère pas correctement la vérification de la propriété du sous-domaine.
Lorsque nous arrivons sur le sous-domaine vulnérable, nous sommes accueillis par ce qui suit :
Remédiations
- A court terme, dans le cas où le sous-domaine vulnérable n'est pas utilisé à des fins professionnelles, nous recommandons de supprimer l'enregistrement DNS ;
- A moyen terme, la gestion de l'infrastructure en tant que code (IaC) devrait certainement permettre d'éviter les situations où le sous-domaine est supprimé mais où l'enregistrement DNS associé reste en place.
De manière simple
Cette vulnérabilité a été publiée par Gitlab. Elle concerne un problème de sécurité de la gestion des images via leur bibliothèque interne Exiftool. L'envoi d'images malveillantes conduit à l'exécution de code à distance sur le serveur hébergeant le GitLab vulnérable.
D'un point de vue technique
Cette vulnérabilité est due au passage d'images fournies par l'utilisateur à la version intégrée d'ExifTool du service. Un attaquant pourrait exécuter des commandes à distance en tant qu'utilisateur Gitlab, en raison de la mauvaise gestion des fichiers DjVu par ExifTool.
Cette vulnérabilité, si exploitée, peut impacter le serveur sous-jacent hébergeant l'application GitLab. Comme la vulnérabilité permet à l'attaquant de prendre le contrôle du serveur, l'impact peut conduire à une propagation latérale sur les biens connectés en fonction de la configuration de sécurité.
Cette vulnérabilité peut être retrouvée de manière publique sur Internet. Une recherche rapide du mot clé "CVE-2021-22205" conduit à ce dépôt public Github. Dès lors, il suffit d'utiliser la proof of concept et d'exécuter commandes, comme dans l'exemple ci-dessous listant le contenu du répertoire du serveur :
Conséquences
- D'un point de vue cyber, cela peut avoir un impact direct sur la confidentialité, l'intégrité, la disponibilité et la traçabilité des actifs stockés dans le serveur. Comme l'exploitation de la vulnérabilité ne nécessite pas d'authentification à la plateforme ou au serveur, son impact est critique et permet à l'attaquant d'accéder au shell ;
- D'un point de vue organisationnel, l'exploitation de la vulnérabilité entraîne des pertes financières directes en affectant la sécurité des actifs de l'entreprise et nécessite une enquête a posteriori par des experts en sécurité pour s'assurer que le réseau sous-jacent n'a pas été compromis.
Remédiation
- A court terme, une restriction d'accès doit être immédiatement déployée pour limiter l'accès au serveur GitLab aux seuls développeurs connus. En tant que tel, GitLab est un service interne et ne devrait pas être accessible depuis Internet. Cela peut se faire en limitant les fonctionnalités du serveur, par exemple en configurant des fichiers .htaccess pour les serveurs Apache ou en créant des règles de filtrage dans le cas où un pare-feu protège le serveur ;
- A moyen terme, les actions ci-dessus perdent fortement en efficacité et gagnent en complexité. La seule remédiation possible est de mettre à jour la version de GitLab avec la dernière version en cours.
Password Authentication Enabled
De manière simple
Le SSH (Secure SHell) est un protocole réseau qui permet aux administrateurs d'accéder à distance à un ordinateur en toute sécurité. Il y a 2 moyens d'authentification pour se connecter au serveur via SSH :
- Utilisation d'une clé cryptographique : ne peuvent pas être devinées par un attaquant car le fichier est complexe et long ;
- Combinaison utilisateur / mot de passe : une authentification par mot de passe a plus de chance de se faire contourner par des pirates informatiques via du brute force.
Si un hacker malveillant parvient à trouver la combinaison mot de passe/identifiant, il peut alors avoir des droits d’administrateur et avoir accès aux données sur le serveur. Il peut ainsi les rendre inaccessibles ou les dérober.
D'un point de vue technique
SSH est un protocole utilisé principalement pour l’administration des machines Linux. Il permet, entre autre, d’accéder à distance à un pseudo terminal, ce qui signifie que la compromission de SSH sur un serveur est souvent synonyme de compromission du serveur dans son ensemble.
Remédiation
mkdir .ssh
cd .ssh
ssh-keygen -f my_new_ssh_key
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/user/.ssh/my_new_ssh_key' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/home/user/.ssh/my_new_ssh_key": bad permissions
PasswordAuthentication no
Database publicly exposed
De manière simple
L'exposition d'une base de données sur Internet est intrinsèquement non-sécurisé :
- L'authentification par nom d'utilisateur/mot de passe est une authentification faible et sujette à des attaques par bruteforce et à la pulvérisation de mots de passe. La double authentification est complexe à mettre en œuvre ;
- Si certaines bases de données prennent en charge le chiffrage des communications, la plupart ne le font pas et sont donc vulnérables à l'interception des communications ;
- Les attaques par déni de service (DDoS) sont faciles à réaliser ;
- La gestion des utilisateurs est difficile, la plupart des entreprises n'utilisent qu'un seul utilisateur pour se connecter à la base de données ;
- Les mises à jour des correctifs sont compliquées à installer.
D'un point de vue technique
Dans le cas où l'attaquant parvient à deviner un mot de passe et à accéder à la base de données, il peut alors accéder aux données stockées et éventuellement au serveur hébergeant la base de données.
Développer un script de bruteforce du protocole de la base de données est assez facile, la partie compliquée étant de deviner la combinaison utilisateur/mot de passe pour se connecter. Selon le type de base de données, il existe souvent un compte par défaut tel que mysql ou postgresql.
Conséquences
- D'un point de vue cyber, cela peut avoir un impact direct sur la confidentialité, l'intégrité, la disponibilité et la traçabilité des informations stockées dans la base de données ;
- D'un point de vue organisationnel, une connexion réussie entraîne des pertes non directes pour l'entreprise car des sauvegardes doivent être déployées afin de récupérer les données perdues ou modifiées.
Remédiation
- A court terme, nous recommandons de mettre en place un pare-feu afin d'établir une liste blanche des adresses IP autorisées à se connecter à la base de données ;
- A moyen terme, l'accès à la base de données doit se faire à partir d'une API publique. Il faut que l'API se connecte, de préférence via un WAF, à la base de données. L'API peut accorder des tokens qui ont des droits particuliers (vues de la base de données) et un temps d'accès. Ces jetons sont facilement révoqués et votre base de données est beaucoup plus sûre lorsqu'elle est correctement configurée. L'API peut être facilement sécurisée à l'aide de TLS, de listes blanches, de MFA et d'autres contrôles tels que le verrouillage d'une personne après un certain nombre de tentatives infructueuses.
Symfony FOSJsRoutingBundle
De manière simple
D'un point de vue technique
{IMPACTED-ASSET}/js/routing
Voici un exemple de résultat :
CVE-2018-15473
De manière simple
Cette vulnérabilité rend possible l'énumération d'utilisateurs, ce qui permet d'afficher une liste d'utilisateurs et d'identifiants du protocole OpenSSh. Dans le cas où le mode d'authentification par mot de passe est activé, l'attaquant peut cibler les comptes dont il connaît l'existence et les attaquer par bruteforce, jusqu'à ce qu'il réussisse à se connecter.
D'un point de vue technique
Cette vulnérabilité concerne le protocole OpenSSH dans les versions comprises entre 2.3 et 7.6.
En raison d'un mauvais traitement des paquets reçus par le protocole, un attaquant peut énumérer les utilisateurs valides.
Dans la capture d'écran ci-dessous, nous avons réussi à trouver les utilisateurs 'root' et 'mail' qui sont valides dans le serveur. Ces informations aideront les attaquants à élaborer des attaques par force brute. Dans le cas où le mode d'authentification par mot de passe est activé, l'attaquant peut cibler les comptes dont il connaît l'existence et les attaquer par force brute jusqu'à ce qu'il réussisse à se connecter.
Le code d'exploitation est public et accessible sur Internet. Le code utilisé ici pour la démonstration est disponible sur GitHub.
Conséquences
- D'un point de vue cyber, dans le cas où l'attaquant trouve un couple nom d'utilisateur / mot de passe valide, la sécurité du serveur d'hébergement est mise en danger ;
- D'un point de vue organisationnel, l'exploitation de la vulnérabilité et la découverte d'informations d'identification valides entraînent des pertes financières directes en affectant la disponibilité des actifs de l'entreprise, et nécessitent une enquête a posteriori par des experts en sécurité pour affirmer que le réseau n'a pas été compromis.
Remédiation
A court et moyen termes, la seule façon de remédier à cette vulnérabilité est soit de restreindre l'accès au point d'extrémité SSH à des adresses IP dédiées, ce qui est difficile à maintenir à long terme, soit de mettre à jour le protocole SSH avec la version la plus récente (recommandé).
Symfony-profiler
De manière simple
Symfony est un framework applicatif open source utilisé pour les applications PHP. Lorsque l'application est déployée en mode développement, Symfony active un composant de débogage appelé web profiler. Ce composant offre de nombreuses fonctionnalités aux développeurs pour inspecter l'application au moment de l'exécution. Cependant, de nombreuses informations peuvent alors être extraites du profiler par des attaquants : routes, cookies, identifiants, fichiers, etc.
D'un point de vue technique
Cette vulnérabilité peut toucher le serveur sous-jacent hébergeant le framework Symfony ainsi que les composants applicatifs interagissant si des informations d'identification sont trouvées.
Vous pouvez accéder au tableau de bord du profileur Symfony avec l'URL suivante :
{IMPACTED-ASSET}/app_dev.php/_profiler/vide/recherche/résultats?limit=10
Depuis Symfony 3.x, le Web Profiler permet de lire les fichiers de l'application sous le répertoire racine. Cette fonctionnalité est utilisée par les développeurs pour identifier rapidement le code source responsable du traitement d'une requête. Cependant, elle peut être utilisée de manière abusive pour lire les fichiers de configuration :
Il est alors possible de lire des fichiers de configuration applicative contenant potentiellement des secrets techniques (identifiants de base de données, jetons de sessions applicatives).
Conséquences
- D'un point de vue cyber, dans le scénario où l'attaquant obtient des identifiants valides, l'impact peut aller de la confidentialité de détails techniques à la compromission des informations de la base de données ;
- D'un point de vue organisationnel, l'impact de la vulnérabilité peut aller jusqu'à des pertes financières directes par l'altération du contenu de la base de données compromise ou du serveur sous-jacent.
Remédiation
Il suffit de désactiver le mode debug en modifiant le fichier de configuration Symfony :
# app/config/config.yml
framework:
profiler:
enabled: false
SQLMap: SQL Injection
De manière simple
Une attaque par injection SQL ou SQLI consiste à exploiter les vulnérabilités logicielles d'une application web dans le but de voler, supprimer ou modifier des données, obtenir le contrôle des systèmes exécutant les applications infectées. Ces attaques, bien que faciles à contrecarrer, sont tout autant faciles à mettre en place.
Ces informations peuvent comprendre un grand nombre d'éléments, y compris des données sensibles de l'entreprise, telles que les noms d'utilisateur et les mots de passe, des détails personnels de l'utilisateur ou même des données privées des clients telles que les informations relatives aux cartes de crédit.
L'impact de l'injection SQL sur une entreprise est considérable. Une attaque réussie peut entraîner la consultation non autorisée de listes d'utilisateurs, la suppression de tables entières et, dans certains cas, l'obtention par le pirate de droits d'administration sur une base de données, autant d'éléments très préjudiciables pour une entreprise.
D'un point de vue technique
L'injection SQL est un vecteur d'attaque courant qui utilise un code SQL malveillant pour manipuler une base de données dorsale afin d'accéder à des informations qui n'étaient pas destinées à être affichées.
Conséquences
- D'un point de vue cyber, cela peut avoir un impact direct sur la confidentialité des données. Toutes les données stockées dans la base de données sont compromises et, selon la configuration, d'autres accès peuvent être obtenus, comme l'exécution de code sur le serveur hébergeant la base de données. Comme l'exploitation de la vulnérabilité ne nécessite pas d'authentification à l'application, son impact est critique ;
- D'un point de vue organisationnel, l'exploitation de la vulnérabilité peut entraîner des pertes financières indirectes en affectant la confidentialité des données stockées, ce qui peut entraîner des conséquences publiques et une perte de confiance. L'accès à tous les services qui dépendent de la base de données affectée sera potentiellement indisponible jusqu'à ce que l'attaque soit atténuée, ce qui peut entraîner d'importants temps d'arrêt.
Remédiation
- Mettre en place une API avec des déclarations paramétrées : le passage de la saisie directe dans une application web à l'utilisation d'une API sûre est le moyen le plus sûr de faire face à une injection SQL. Cela évite de faire appel à l'interpréteur SQL en utilisant à la place des appels préétablis. La création d'une API paramétrée est la meilleure méthode pour atténuer les attaques par injection SQL.
- Mettre en place l'échappatoire de caractères : si aucune API n'est disponible, vos applications web doivent être en mesure d'échapper aux caractères spéciaux (c'est-à-dire tous les caractères ayant un impact sur la syntaxe des langages SQL). Cela doit être considéré comme une dernière ligne de défense, car l'échappement de caractères n'est pas apte à faire face à toutes les situations. Par ailleurs, l'application web elle-même peut tenter d'échapper aux requêtes, mais en fonction de la manière dont les requêtes sont traitées, il devient encore plus difficile d'y échapper.
CVE-2022-23808
De manière simple
Cette vulnérabilité concerne phpMyAdmin, un outil d'administration libre et gratuit pour MySQL et MariaDB. En tant qu'application web portable écrite principalement en PHP, il est devenu l'un des outils d'administration MySQL les plus populaires, en particulier pour les services d'hébergement web.
D'un point de vue technique
Cette CVE a été découverte dans le panneau d'administration de la base de données de PhpMyAdmin version 5.1.1 à 5.1.2. En raison de la nécessité d'être authentifié dans le panneau d'administration, nous n'avons pas pu exploiter cette vulnérabilité. Cependant, des détails publics sont accessibles sur GitHub.
Conséquences
- D'un point de vue cyber, il est possible de déclencher une vulnérabilité XSS (entrée utilisateur malveillante qui conduit à l'exécution de Javascript sur le navigateur de la victime). L'exploitation de la vulnérabilité XSS peut conduire à l'usurpation de l'identité d'un utilisateur ou au vol de son compte sur la plateforme PhpMyAdmin.
- D'un point de vue organisationnel, un utilisateur authentifié pourrait exploiter l'absence d'assainissement des entrées utilisateur et se faire passer pour un compte à privilèges élevés. L'utilisation de ces comptes à privilèges peut entraîner des pertes financières indirectes.
Remédiation
La seule façon de remédier à cette vulnérabilité est de mettre à jour la plateforme PhpMyAdmin avec la dernière version disponible.
Wordpress-accessible-wpconfig
De manière simple
Le fichier wp-config est l'un des plus importants de WordPress. Ce fichier de configuration peut contenir des informations clés, telles que la connexion à la base de données. Si cette dernière est accessible, la confidentialité et l'intégrité des données peuvent être compromises.
D'un point de vue technique
Le fichier wp-config est généralement situé dans https://wordpress-path/wp-config.php.
Remédiation
La solution est de restreindre l'accès au fichier, comme indiqué dans cet article.
Pour un serveur Apache :
- Ouvrez le fichier .htaccess à l'aide d'unl éditeur de texte ;
- Integrez les lignes de code suivantes à la fin du fichier .htaccess :
# Deny access to wp-config/php
<Files wp-config.php>
Order allow,deny
Deny from all
</Files>
Pour d'autres serveurs d'application apparentés, référez-vous au manuel du fichier de configuration (Par exemple, le fichier de configuration nginx est situé dans /usr/local/nginx/conf (serveur Unix).)
/location ~ /(wp-config.php) {
deny all;
return 404;
}
...
Laravel env.
De manière simple
Le fichier .env contient les secrets chargés à partir du code source dans l'environnement de production ou de développement. Il ne doit jamais être déployé en production car il contient des secrets de développement potentiellement réutilisés en production.
D'un point de vue technique
Voici un exemple de fichier .env :
Une compromission de ce fichier menace directement chaque actif concerné dans les informations d'identification du fichier .env. Il peut être généralement trouvé dans le chemin https://web-server-path/.env.
Conséquences
Dans le cas où les informations d'identification donnent accès au dépôt de code public, la confidentialité et l'intégrité du code source peuvent être compromises. Ces fichiers peuvent également contenir des identifiants de connexion à des bases de données. Ce scénario, combiné à une base de données publiquement exposée, peut avoir un impact direct sur les données stockées.
Remédiation
Deux solutions s'offrent à vous :
- Restreindre l'accès au fichier en modifiant le fichier de configuration du serveur. La modification du fichier .htaccess comme dans le code suivant restreindra l'accès au fichier .env :
# Deny access to .env
<Files .env>
Order allow,deny
Deny from all
</Files> - Supprimer le fichier déployé, car aucun fichier .env ne doit être déployé, que son accès soit restreint ou non.
CVE-2021-34473
De manière simple
Cette vulnérabilité, aussi nommée Proxyshell, est la combinaison de 3 CVE :
- CVE-2021-31207 : contournement du contrôle d'accès ;
- CVE-2021-34523 : escalade de privilèges sur le backend du serveur Exchange ;
- CVE-2021-34473 : exécution de code à distance sur le serveur via l'écriture de fichiers arbitraires.
D'un point de vue technique
L'exploitation peut se faire par l'utilisation de code public. Les recherches effectuées dans les navigateurs web conduisent à des sources de code accessibles sur GitHub.
Il est possible de tester la première étape de l'exploit en exécutant le script python proxyshell_enumerate, qui nous fournira la liste des adresses électroniques du serveur de messagerie :
Cette étape prouve que le serveur Exchange est vulnérable à l'exploit, et que l'exécution de code à distance est également possible.
Conséquences
- D'un point de vue cyber, un attaquant qui interagit avec le serveur Exchange touché peut obtenir des privilèges d'administrateur local sur le serveur. Comme le serveur de messagerie Exchange fonctionne souvent avec des privilèges d'administrateur de domaine, l'ensemble du domaine Active Directory risque d'être compromis ;
- D'un point de vue organisationnel, l'exploitation de la vulnérabilité entraîne des pertes financières directes et indirectes en accordant à un attaquant un accès privilégié au réseau.
Remédiation
La seule façon de remédier à cette vulnérabilité est de mettre à jour la version du serveur Exchange. Comme cette vulnérabilité a été activement exploitée, nous recommandons de faire appel à des professionnels de la cybersécurité afin de s'assurer que le réseau n'a pas été compromis.
WordPress Core < 4.7.1 - Username Enumeration (CVE-2017-5487)
D'un point de vue technique
Remédiation
- Si vous utilisez la version de WordPress < 4.7.1, vous devez mettre à jour WordPress via le panneau d'administration vers la dernière version disponible.
- Si votre version de Wordpress est à jour, la méthode est d'installer un plugin de sécurité appelé Disable REST API plugin.
-
- Depuis votre tableau de bord WordPress, allez dans Ajouter un plugin ;
- Recherchez le plugin Disable REST API ou iThemes Security (ou d'autres avec de bonnes critiques sur le même sujet) ;
- Installez et activez le plugin.
CVE-2020-9490
De manière simple
Cette vulnérabilité peut permettre à un hacker malveillant de déclencher une attaque par déni de service (DDoS), pouvant nuire à la disponibilité de votre infrastructure.
D'un point de vue technique
Cette vulnérabilité est une attaque par déni de service affecte les serveurs Apache HTTPD dans les versions antérieures à 2.4.46. En fabriquant des en-têtes HTTP spéciaux (Cache-Digest), un attaquant peut compromettre un serveur HTTPD vulnérable.
Conséquences
- D'un point de vue cyber, il peut y avoir un impact direct sur la disponibilité du serveur vulnérable. L'exploitation de la vulnérabilité ne nécessite aucune authentification, ce qui la rend d'autant plus facile à mettre en place ;
- D'un point de vue organisationnel, dans le cas où le serveur héberge une application utilisée par la production, l'exploitation conduira à des pertes financières directes par perte d'exploitation car l'actif sera hors service et essaiera de redémarrer à chaque fois que l'exploitation réussira. Tous les sites web hébergés sur la machine affectée seront inaccessibles.
Remédiation
Il faut mettre à jour le serveur HTTP Apache avec la dernière version disponible prête pour la production (version 2.4.54 publiée le 06-08-2022).
Directory-listing
De manière simple
Une liste de répertoire fournit à un attaquant l'index complet de toutes les ressources situées à l'intérieur du répertoire. Les risques et conséquences spécifiques varient en fonction des fichiers listés et accessibles.
Stoïk ne dévoile cette vulnérabilité que lorsque les fichiers impactés sont :
- Le code source de l'application ;
- Des noms d'utilisateurs, des mots de passe ou des hashs ;
- Les données personnelles des utilisateurs (données bancaires, ID's, CV)
D'un point de vue technique
Il n'y a pas de commande à exécuter, on accède à un index de répertoire pour lister les fichiers.
La plupart d'entre eux se trouvent sur des instances WordPress, telles que /wp-content/uploads.
Conséquences
L'exposition du contenu d'un répertoire peut permettre à un attaquant d'accéder au code source ou de fournir des informations utiles pour concevoir des exploits, telles que les heures de création des fichiers ou toute information pouvant être encodée dans les noms de fichiers.
La liste des répertoires peut également compromettre des données privées ou confidentielles.
Remédiation
Sur Apache, vous devez ajouter du code au fichier .htaccess de votre site pour désactiver le listage des répertoires.
Pour accéder au fichier, vous aurez besoin d'un client FTP. Sinon, vous pouvez utiliser l'application de gestion de fichiers dans votre panneau de contrôle d'hébergement WordPress.
Après vous être connecté à votre site, ouvrez simplement le dossier public de votre site Internet et trouvez le fichier .htaccess. Vous pouvez modifier le fichier .htaccess en le téléchargeant sur votre bureau, puis en l'ouvrant dans un éditeur de texte tel que le Bloc-notes.
Tout en bas du fichier, ajoutez le code suivant :
Cela ressemblera à ceci :
Une fois que vous avez terminé, enregistrez votre fichier .htaccess et téléchargez-le sur votre serveur à l'aide d'un client FTP.
Si votre serveur web diffère d'Apache, vous pouvez consulter cet article.
Docker-compose.yml exposure
De manière simple
Docker compose est un outil permettant de définir et d'exécuter des applications Docker. L'exposition de ce fichier peut permettre d'accéder à toutes les informations nécessaires au déploiement d'une application. Il n'est pas rare que des mots de passe et autres secrets soient présents dans ce fichier.
D'un point de vue technique
Avec Compose, les développeurs utilisent un seul fichier de configuration (docker-compose.yml) pour définir et exécuter plusieurs services de l'application. Parfois, les développeurs poussent par erreur ce fichier dans les environnements de production. Comme ce fichier contient généralement toutes les informations nécessaires au déploiement d'une application, il n'est pas rare que des mots de passe et autres secrets soient présents dans ce fichier.
Il est possible d' accéder au fichier docker-compose via l'URL suivante dans votre navigateur web favori : 0/docker-compose.yml
Conséquences
En accédant à un fichier docker-compose.yml exposé, un attaquant pourrait tirer parti de la vulnérabilité pour obtenir un accès non autorisé à des informations sensibles. Si des mots de passe sont trouvés, un accès immédiat au serveur peut être obtenu – et même si aucun secret n'est présent, des informations importantes sur les aspects internes de l'application peuvent être révélées, permettant ainsi à un acteur malveillant d'élaborer une attaque ciblée.
Voici un exemple ci-dessous :
Remédiation
Il faut s'assurer que le fichier docker-compose.yml n'est pas déployé avec l'application ou, du moins, n'est pas exposé dans un répertoire du serveur web en définissant les permissions appropriées.
Si des informations sensibles telles que des informations d'identification sont divulguées dans le fichier exposé, elles doivent être révoquées et réinitialisées sur les actifs concernés.
CVE-2022-41040
De manière simple
Cette vulnérabilité, lorsque combiné à la vulnérabilité CVE-2022-41082, permet à un attaquant authentifié de déclencher une exécution de code à distance.
D'un point de vue technique :
Deux vulnérabilités de type zero-day (n'ayant jamais été publiées) affectent Microsoft Exchange Server 2013, Exchange Server 2016 et Exchange Server 2019.
- D'un point de vue cyber, l'exploitation de ces deux vulnérabilités permet une exécution de code à distance sur le serveur, souvent lancée avec des droits d'administrateurs. Un attaquant peut ainsi obtenir un contrôle total sur le domaine ou le réseau relié au serveur Exchange ;
- D'un point de vue organisationnel, un attaquant provoquera des pertes financières directes et indirectes pour la victime, en perturbant la disponibilité et l'intégrité du réseau.
Remédiation
CVE-2022-35914
De manière simple
Cette vulnérabilité exploite une faille de mise à jour qui permet d'écrire du code malveillant à distance dans votre infrastructure.
D'un point de vue technique
%20%5BEn%20fonction%5D%20-%20Oracle%20VM%20VirtualBox.png?alt=media&token=26c8db2e-2ff2-4c7c-8506-97b074a5a93a)
Conséquences
- D'un point de vue cyber, il y a un impact direct sur la confidentialité, l'intégrité, la disponibilité et la traçabilité des actifs stockés sur le serveur. L'exploitation de la vulnérabilité ne nécessitant pas d'authentification à la plateforme ou au serveur, son impact est critique et permet un accès direct au serveur d'hébergement ;
- D'un point de vue organisationnel, l'exploitation de la vulnérabilité entraîne des pertes financières directes en affectant la disponibilité des actifs de l'entreprise et nécessite une enquête a posteriori par des experts en sécurité pour s'assurer que le réseau n'a pas été compromis.
Rémédiation
Pour remédier à cette vulnérabilité, mettez à jour le logiciel GLPI avec la dernière version disponible.
VMSA-2021-0002
De manière simple
Cette vulnérabilité réside dans l'exploitation d'une faille d'un système appelé ESXi. Elle peut permettre à un hacker malveillant d'exécuter du code à distance et lancer une attaque de type ransomware.
D'un point de vue technique
-
ESXi 7.0 Update 1c (security Only)
-
Date de sortie : 2020/12/17 ;
-
Numéro de build : 17325020.
-
ESXi 6.7 P04
-
Date de sortie : 2020/11/19 ;
-
Numéro de build : 17167734.
-
ESXi 6.5 EP 23
-
Date de sortie : 2020/11/19 ;
-
Numéro de build : 17167537.
-
Toutes les versions d'ESXi 6.0
- A court terme, il est possible de désactiver le service SLP directement sur l'ESXi, via la documentation de VMware ;
- A moyen terme, il est recommandé de mettre à jour la dernière version de l'ESXi.