Récemment, une famille de vulnérabilités liées à un Bash BUG, l'interpréteur le plus courant sur GNU / Linux, MAC OS et certains Unix, et a été appelé SenferChoc ou alors Bashdoor (CVE-2014-6271). Le problème le plus important et le plus alarmant à cet égard a à voir avec le fait que ledit BUG est présent dans Bash depuis 20 ans, on estime donc que la gravité de l'affaire est encore plus grande que Heartbleed.
Le BASH BUG ou alors ShellChoc Il ne s'agit pas en soi d'un code malveillant (tel que des virus informatiques, des logiciels espions, des logiciels malveillants, etc.), il ne peut donc pas être détecté et bloqué par un antivirus ou des systèmes similaires, mais doit être corrigé dans la mise en œuvre du logiciel lui-même qui le "souffre".
Il est recommandé d'appliquer ce tutoriel dans des environnements contrôlés, à des fins liées à la recherche et à l'étude en informatique, comme expliqué ici.
Qu'est-ce que le Bash BUG ShellShock ?
Fondamentalement, le problème réside dans la possibilité pour Bash de stocker la définition des fonctions de script dans des variables d'environnement, plus précisément dans la façon dont ces fonctions sont chargées par Bash.
Le BUG se manifeste lorsque dans une variable d'environnement, après la définition de la fonction, du code supplémentaire est ajouté que Bash continuera à analyser et à exécuter après le chargement de la fonction.
Avec la commande suivante, une définition de fonction vide, du code arbitraire, a été chargée dans la variable "x" puis Bash a été appelée.
Ce qui se passe, c'est qu'avant d'appeler Bash, la variable d'environnement a été chargée et le code injecté a été exécuté qui affiche simplement la chaîne "vulnérable" sur la console (ça aurait pu être pire bien sûr !). Ensuite, Bash a été exécuté et la commande echo a été appelée à titre d'exemple. Une variante plus simple de la commande pour effectuer le test :
$ env x = '() {:;}; echo vulnérable 'bash Cette dernière commande affichera la chaîne "vulnérable" à l'écran si la version Bash a le BUG ou elle n'affichera rien s'il s'agit d'une version patchée.
Comme indiqué en introduction, ce BUG détermine une famille de vulnérabilités qui pourraient être utilisées par un attaquant pour contrôler des ordinateurs à distance. Au sein de ces variantes, il y a certaines un peu plus complexes, d'autres très simples et certaines plus ou moins complexes. Il existe des variantes liées aux modules Apache et CGI, d'autres pour le client DHCP, et certaines un peu plus élaborées que d'autres.
L'un des cas les plus simples sera utilisé pour ce guide, attaque shellShock sur le client DHCP GNU/Linux.
Systèmes impliquésHôte de la victime :
GNU/Linux avec Bash 4.3
Client DHCP isc-dhclient-4.2.4
IP 192.168.1.88 (via DHCP)
Hôte attaquant :
Windows XP
Serveur DHCP "tftp32" par Ph. Jounin
IP : 192.168.1.100
AGRANDIR
Pour la preuve de concept, nous supposons un réseau local dans lequel la victime et l'attaquant sont connectés.
Étant donné que le logiciel client DHCP est exécuté avec des autorisations d'administration, l'attaquant essaiera d'inclure du code malveillant dans certains paramètres d'option DHCP dans la configuration DHCP attribuée à la victime.
Traiter
1) L'attaquant exécute le logiciel de service DHCP {(ftp32 ”par Ph. Jounin) a été utilisé pour ce guide}
1.1) Sélectionnez l'interface réseau à utiliser et appuyez sur le bouton "Paramètres"
1.2) Configurez les options pour exécuter uniquement le service DHCP.
1.3) Allez dans l'onglet "DHCP" et configurez comme suit :
1.4) A noter dans le champ "Option supplémentaire", l'option 114 (utilisée en VOIP) a été précisée et la définition de la fonction Bash et le code malveillant ont été renseignés dans le champ de détail de l'option :
() {ignoré;}; echo 'CODE INJECTE'; / bin / cat / etc / passwd 1.5) Appuyez sur "OK", le service DHCP est prêt.
2) Dans le terminal système de la victime, exécutez la commande suivante pour exposer le Syslog du système lorsque nous exécutons la requête DHCP :
# tail -f / var / log / syslog &3) En supposant que eth1 est l'interface réseau de la victime, exécutez le client DHCP :
# dhclient eth14) La commande fera de la requête DHCP et de l'attaquant l'affectation correspondante :
5) Dans le terminal de la victime, grâce à la commande tail qui était en arrière-plan affichant le syslog du système, l'exécution du code injecté sera affichée, dans ce cas, la chaîne "CODE INJECTÉ" sera affichée puis le contenu du fichier /etc/passwd de la victime (aurait pu être bien pire…) :
Cette dernière partie est grâce à la commande "/ bin / cat / etc / passwd« Qui fait partie de la chaîne spécifiée comme option 114.
L'attaquant aurait pu exécuter d'autres commandes et effectuer n'importe quelle action puisqu'il dispose des autorisations « root » puisque le client DHCP de la victime s'exécute avec ces privilèges.
ConsidérationsUn logiciel commun a été utilisé pour ce guide, sans variations sur le système Victim. Cette vulnérabilité est présente dans d'autres applications qui utilisent Bash pour exécuter des paramètres ou des scripts sur le système.
est impératif appliquer les mises à jour correspondantes au système pour empêcher ce type d'attaque.
Il convient de préciser que le contenu présenté ici est utile à la fois pour comprendre les mécanismes de l'attaque ainsi que pour sensibiliser sur ce dernier point. Gardez à l'esprit que cette décision existe depuis au moins 20 ans, elle a donc peut-être été appliquée bien avant sa publication.
Avez-vous aimé et aidé ce tutoriel ?Vous pouvez récompenser l'auteur en appuyant sur ce bouton pour lui donner un point positif
