auteur: NostroBO
version: 0.1 alpha
organisation: klc
date: 11/04/2003
Ce texte a pour but de présenter la version alpha du programme bare. Ce programme résulte d'une très légère étude sur la possibilité d'automatiser certaines détections de vulnérabilités de type stack overflow et par la même occasion d'en automatiser l'exploitation. Ce dernier cas ne s'applique qu'aux vulnérabilités de type Buffer Overflow et techniques voisines. Je tiens à préciser que le code est très léger et n'a pas été terminé pour ainsi dire. Le but étant tout d'abord de démontrer la possibilité d'automatiser certaines tâches.
Pour comprendre cet article vous aurez besoin de connaitre le type de faille dont nous parlons ici.
Pour toutes questions relatives à ce projet: nostrobo@klc-research.com
Il est bon de savoir que le code a été écrit et testé sur plateforme intel 32 bits sous le système d'exploitation GNU/Debian et que les shellcodes ne fonctionneront que sous linux.
Bare est un programme dont le but premier est de découvrir une faille de type Buffer Overflow. Via l'utilisation d'options l'utilisateur pourra spécifier nombre de paramètres pour rendre la détection possible en local ou bien même en réseau (TCP/IP). L'utilisateur pourra aller jusqu'a demander au programme d'exploiter la faille seul.
Comme décrit précédemment il existe deux modes d'utilisation majeurs: local et tcp. En mode local (-L), bare essaiera de trouver une faille en utilisant les arguments passés au programme. Ceux ci seront générés pour faire crasher le programme. En mode réseau (-T), le méthode est quasiment identique mise à part que les arguments seront tout simplement transmis directement au programme cible qui cette fois ci tournera déjà.
La technique utilisée pour découvrir une faille est celle du bruteforce, très couteuse en temps et peu discrète, néanmoins elle est simple à mettre en place. Le but du programme n'étant pas de fournir une sorte de scanner de faille révolutionnaire ce détail importe donc peu.
Le fonctionnement est donc très simple. Voyons brièvement le déroulement d'une recherche
de faille puis d'une exploitation théorique en local:
0 - définition des options pour générer les arguments.
/* rechercher de vulnérabilités */
1 - création du nombre d'arguments demandés (avec la taille de départ).
2 - fork() pour ne pas bloquer le processus principal.
3 - éxécution du programme avec les paramètres générés.
4 - si bare a trouvé une faille il arrête la boucle sinon modifie la taille des
arguments en conséquence (-id) et relance la boucle (étape 1).
5 - le programme a terminé sa recherche de vulnérabilité. si sa recherche ne fût pas
concluante, le programme stoppe en avertissant l'utilisateur de l'échec. dans le
cas contraire le programme lance l'exploitation si spécifiée (c'est notre cas).
/* exploitation de la vulnérabilité trouvée */
6 - le programme regénère des arguments de la taille de la vulnérabilité trouvée.
7 - en local le programme utilise l'environnement pour stocker le shellcode. bare
ajoute donc l'adresse en fin de chaine pour faire éxécuter son code.
8 - fork() pour ne pas bloquer le processus principal.
9 - éxécution de la cible avec les paramètres.
10 - soit l'exploitation à réussit et dans ce cas le programme est bloquer puisque
le shellcode éxécute un shell, l'utilisateur dispose donc d'un shell avec
les droits du propriétaire du binaire cible, soit l'exploitation a échouée.
dans ce cas le programme augmente la taille des arguments de un et rééssaie
en relancant l'étape 6.
Il s'avère que la méthode est plutôt concluante en local, mais cette méthode ne fonctionnera que pour un type de vulnérabilité assez simple, du moins je le suppose.
Voyons les mutliples options que propose bare pour forger ses propres arguments.
-T
(Tcp) utilise une connection TCP pour accéder à la cible.
-L
(Local) accède à la cible en local.
-H
(Host) dans le cas d'une connection TCP cette option spécifie la machine cible. dans
le cas d'une attaque locale elle spécifie tout simplement le binaire cible.
-P
(Port) cette option n'est valable qu'en mode TCP (-T) et spécifie simplement le port
sur lequel tourne le service à attaquer.
-f
(format) cette option est la plus importante puisqu'elle définit le format, le squelette
de chaque argument. En effet via cette option vous pouvez forger vos arguments en fonction
de la cible.
Chaque argument est contenu entre crochets ('[', ']'), les symbôles suivants sont utilisés pour
spécifier une inclusion spéciale:
%s: pour spécifier l'emplacement du shellcode à injecter.
%t: pour définir une pause (utilise l'option -t). symbôle seulement valable avec l'option -T.
%[: permet d'afficher un crocher ouvrant.
%]: permet d'afficher un crocher fermant.
%: permet d'afficher un caractère pourcentage.
Imaginons un programme simple, celui ci pourrait être exploité avec l'option suivante:
... -f [%s] ...
Imaginons désormais un programme qui refuserait d'être éxécuté si le premier caractère
était différent du caractère '?'. Voici le format qu'il faudrait utilisé:
... -f [?%s] ...
Imaginons un programme avec plusieurs arguments exploitables:
... -f [+%s][null argument][%t][bare][:: %s] ...
Le dernier exemple va générer cinq arguments donc un nul, "[%t]" vaudra "[]" apres la pause.
Deux des cinq arguments contiendront des NOP avec une adresse pour tenter de faire crasher
ou d'exploiter le programme cible. Ces deux arguments seront également les seuls à être
modifier en taille pour rechercher une vulnérabilité.
-o
(overflow) spécifie la limite de taille pour les arguments destinés à rechercher une vulnérabilité.
valeur par défaut: 500
-g
(padding) spécifie le nombre de tests à effectuer lors de l'exploitation. Lorsque la recherche
est terminée et concluante, le programme passe en mode exploitation (si -x spécifié) et teste alors
avec un shellcode. Pour chaque test la taille des arguments attaquants augmentent. Le padding
spécifie le nombre d'attaques à effectuer.
valeur par défaut: 50
-x
(exploit) définit le type d'action à effectuer, dans le cas présent: EXPLOIT.
-s
(search) définit le type d'action à effectuer, dans le cas présent: SEARCH.
-c
(connect) option utilisable seulement avec l'option -T. Cette option, très utile permet à
l'utilisateur de passer des informations au programme cible avant de tenter toute attaque.
En effet imaginons un programme où la vulnérabilité serait présente après un système d'identification.
La méthode consisterait à envoyer un login puis un pass, pour enfin commencer la recherche de failles.
Le paramètre utilise la même syntaxe générale que l'option -f (format) mais avec les symbôles suivants:
%t: pour définir une pause (utilise l'option -t). symbôle seulement valable avec l'option -T.
%[: permet d'afficher un crocher ouvrant.
%]: permet d'afficher un crocher fermant.
%: permet d'afficher un caractère pourcentage.
Voici un exemple d'utilisation:
... -t 20 -c [login][%tpassword] ...
Cet exemple aura pour effet d'envoyer au service cible la chaine "login\n", d'attendre 20 micro secondes
pour ensuite envoyer la chaine "password\n".
-n
(return) définit le type de retour à la ligne suivant les protocoles et les plateformes.
vous avez la possibilité de spécifier chaque fin d'argument en ce qui concerne l'option -T.
Les valeurs possibles sont: LF ('\n') ou bien CRLF ("\r\n").
valeur par défaut: LF
-i
(increase) définit le type de modification en ce qui concerne la taille des arguments attaquants.
dans ce cas l'attaque commencera avec une longueur nulle et terminera à la longueur définir par
l'option -o.
-d
(decrease) définit le type de modification en ce qui concerne la taille des arguments attaquants.
dans ce cas l'attaque commencera avec une longueur égale à l'option -o et terminera à 0.
cette option est l'option par défaut.
-v
(verbose) permet un suivi par l'utilisateur. en effet cette option indique au programme d'afficher
toutes les actions effectuées par bare.
-t
(time) cette option spécifie le temps de pause à chaque appel au symbôle "%t". Le temps indiqué
est exprimé est micro secondes.
Cette option spécifie également le temps entre chaque tentatives de connection.
valeur par défaut: 1000
-b
(buffer overflow) définit l'attaque à engager contre la cible, ici Buffer Overflow.
-e
(off by one) définit l'attaque à engager contre la cible, ici Off by One.
cette attaque essaie d'overwriter un byte, et teste un nombre conséquent de valeurs, et est donc
beaucoup plus lente que l'option -b.
-a
(all) spécifie toutes les attaques possibles. équivaut aux options: "-be".
-S
(shellcode) spécifie le shellcode à utiliser. Dans la version actuelle il n'en existe que 2,
un pour linux en local et un autre pour linux en remote. L'option accepte un identifiant de shellcode:
0: local linux shellcode
1: remote linux shellcode
valeur par défaut: 0
Quelques tests ont été préparés pour mettre en oeuvre le programme. Ceux ci sont contenus dans le répertoire "tests/"
:: vuln1 ::
nostrobo@klc:~/Bare$ ./bin/bare -L -H tests/vuln1 -f [%s] -sx -o 500 -i -b
*****[ Bare ]*****
*****[ Trying to Exploit Buffer Overflow Vulnerability. ]*****
....sh-2.05a# whoami
root
sh-2.05a# exit
exit
..............................................
***[ end of exploitation ]***
*****[ klc-research ]*****
***[ NostroBO <nostrobo@secureroot.com> <https://www.klc-research.com> ]***
nostrobo@klc:~/Bare$
:: vuln2 ::
nostrobo@klc:~/Bare$ ./bin/bare -L -H tests/vuln2 -f [%s] -sx -o 500 -i -b
*****[ Bare ]*****
*****[ Trying to Exploit Buffer Overflow Vulnerability. ]*****
........sh-2.05a# whoami
root
sh-2.05a# exit
exit
..........................................
***[ end of exploitation ]***
*****[ klc-research ]*****
***[ NostroBO <nostrobo@secureroot.com> <https://www.klc-research.com> ]***
nostrobo@klc:~/Bare$
:: vuln3 ::
nostrobo@klc:~/Bare$ ./bin/bare -L -H tests/vuln3 -f [%s] -sx -o 500 -i -b
*****[ Bare ]*****
*****[ Trying to Exploit Buffer Overflow Vulnerability. ]*****
....sh-2.05# whoami
root
sh-2.05a# exit
exit
....sh-2.05a# exit
exit
..........................................
***[ end of exploitation ]***
*****[ klc-research ]*****
***[ NostroBO <nostrobo@secureroot.com> <https://www.klc-research.com> ]***
nostrobo@klc:~/Bare$
:: vuln4 ::
nostrobo@klc:~/Bare$ ./bin/bare -L -H tests/vuln4 -f [%s] -sx -o 500 -i -b
*****[ Bare ]*****
*****[ Trying to Exploit Buffer Overflow Vulnerability. ]*****
....sh-2.05a# whoami
root
sh-2.05a# exit
exit
....sh-2.05a# exit
exit
..........................................
***[ end of exploitation ]***
*****[ klc-research ]*****
***[ NostroBO <nostrobo@secureroot.com> <https://www.klc-research.com> ]***
nostrobo@klc:~/Bare$
:: vuln5 ::
nostrobo@klc:~/Bare$ ./bin/bare -L -H tests/vuln5 -f [%s] -sx -o 500 -i -b
*****[ Bare ]*****
*****[ Trying to Exploit Buffer Overflow Vulnerability. ]*****
........sh-2.05a# whoami
root
sh-2.05a# exit
exit
..........................................
***[ end of exploitation ]***
*****[ klc-research ]*****
***[ NostroBO <nostrobo@secureroot.com> <https://www.klc-research.com> ]***
nostrobo@klc:~/Bare$
:: vuln6 ::
nostrobo@klc:~/Bare$ ./bin/bare -L -H tests/vuln6 -f [%s] -sx -o 500 -i -b
*****[ Bare ]*****
*****[ Trying to Exploit Buffer Overflow Vulnerability. ]*****
........sh-2.05a# whoami
root
sh-2.05a# exit
exit
..........................................
***[ end of exploitation ]***
*****[ klc-research ]*****
***[ NostroBO <nostrobo@secureroot.com> <https://www.klc-research.com> ]***
nostrobo@klc:~/Bare$
:: vuln7 ::
nostrobo@klc:~/Bare$ ./bin/bare -L -H tests/vuln7 -f [%s] -sx -o 500 -i -b
*****[ Bare ]*****
*****[ Trying to Exploit Buffer Overflow Vulnerability. ]*****
....sh-2.05a# whoami
root
sh-2.05a# exit
exit
..............................................
***[ end of exploitation ]***
*****[ klc-research ]*****
***[ NostroBO <nostrobo@secureroot.com> <https://www.klc-research.com> ]***
nostrobo@klc:~/Bare$
:: vuln8 ::
nostrobo@klc:~/Bare$ ./bin/bare -L -H tests/vuln8 -f [%s] -sx -o 500 -i -b
*****[ Bare ]*****
*****[ Trying to Exploit Buffer Overflow Vulnerability. ]*****
...sh-2.05a# whoami
root
sh-2.05a# exit
exit
....sh-2.05a# exit
exit
...........................................
***[ end of exploitation ]***
*****[ klc-research ]*****
***[ NostroBO <nostrobo@secureroot.com> <https://www.klc-research.com> ]***
nostrobo@klc:~/Bare$
:: vuln9 ::
nostrobo@klc:~/Bare$ ./bin/bare -L -H tests/vuln9 -f [%s] -sx -o 500 -i -b
*****[ Bare ]*****
*****[ Trying to Exploit Buffer Overflow Vulnerability. ]*****
....sh-2.05a# whoami
root
sh-2.05a# exit
exit
..............................................
***[ end of exploitation ]***
*****[ klc-research ]*****
***[ NostroBO <nostrobo@secureroot.com> <https://www.klc-research.com> ]***
nostrobo@klc:~/Bare$
:: vuln10 ::
nostrobo@klc:~/Bare$ ./bin/bare -L -H tests/vuln10 -f [%s] -sx -e 500 -i -g 20
*****[ Bare ]*****
*****[ Trying to Exploit Frame Pointer Overflow Vulnerability. ]*****
....................sh-2.05a# whoami
root
sh-2.05a# exit
exit
nostrobo@klc:~/Bare$
:: ddate ::
nostrobo@klc:~/Bare$ ./bin/bare -L -H tests/ddate -f [+%s] -sx -o 500 -d -b
L'affichage pour ddate était bien trop long pour être mis ici mais l'exploitation fonctionne.
Pour rendre ce programme réellement utilisable il y aurait un nombre conséquent d'améliorations à apporter.
Malgré tout il s'avère que ce programme détient tout de même une bonne base.
Voici les améliorations que vous pourriez apporter pour le rendre plus fonctionnel. Sachez
que l'auteur original n'a aucune intention de continuer ce programme, libre à vous de le faire à sa
place:
- ajouter l'exploitation de off by one avec l'option -T.
- ajouter l'exploitation de format string.
- ajouter un module SSL pour pouvoir crypter et donc simuler une identification RSA par exemple.
- revoir le mode TCP.
- inclure l'option -s en mode TCP. Option qui se chargerait suivant un protocole donné de découvrir une faille.
Par exemple le programme pourrait envoyer des données en connaissant la réponse que devrait renvoyer le serveur.
De telle sorte Bare pourrait analyser la réponse du serveur et déterminer si une faille existe. Cette option
serait très intéressante à programmer puisqu'elle ne ferait pas appel à du bruteforcing.
- ajouter des shellcodes ou bien une sorte de générateurs de shellcodes.
- rendre le programme multi plateformes avec des shellcodes divers.
- ...
Bare ne sortira certainement qu'en version alpha puisque l'auteur n'a pas le temps de s'attarder sur de telles choses. Néanmoins si vous désirez reprendre les sources pour les améliorer, libre à vous du moment que l'auteur ainsi que l'url de sa première publication sont toujours spécifiés dans les sources.
Merci.
klc [http://www.klc-research.com/]
Et merci à tout le chan #klc