- Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
- **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
- **Partagez vos astuces de piratage en soumettant des PR au [repo hacktricks](https://github.com/carlospolop/hacktricks) et au [repo hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)**.
**Ce contenu a été pris à partir de** [**https://www.errno.fr/artifactory/Attacking\_Artifactory**](https://www.errno.fr/artifactory/Attacking\_Artifactory)
Par défaut, aucune politique de verrouillage de mot de passe n'est en place, ce qui fait d'Artifactory une cible privilégiée pour les attaques de bourrage de mots de passe et de pulvérisation de mots de passe.
Cela signifie que l'accès anonyme a été activé dans le panneau d'administration, ce qui est un paramètre courant utilisé pour permettre aux applications de récupérer des artefacts sans tracas, mais vous permet, en tant qu'attaquant, de voir plus que ce qui est préférable.
Si des entrées `repoKey` sont présentes dans la requête, un utilisateur anonyme peut y déployer des fichiers, ce qui est vraiment très dangereux. Vous devez absolument être authentifié pour déployer des fichiers.
Pour une raison quelconque, la liste des utilisateurs est réservée aux administrateurs uniquement. J'ai trouvé une méthode alternative pour lister les utilisateurs (ceux qui déploient au moins) qui repose sur la valeur "Déployé par" des artefacts :
[Ce script](https://gist.github.com/gquere/347e8e042490be87e6e9e32e428cb47a) essaie simplement de trouver de manière récursive tous les utilisateurs qui ont déployé des artefacts. Notez que cela peut prendre un certain temps pour se terminer s'il y a beaucoup de référentiels (>1000).
Celle-ci commence à dater et il est peu probable que vous tombiez sur une version Artifactory aussi obsolète. Néanmoins, elle est assez efficace, car il s'agit d'une simple traversée de répertoire qui permet une exécution de code arbitraire au niveau de Tomcat.
Ce compte local est normalement interdit d'accès à l'interface utilisateur ou à l'API, mais jusqu'à la version 6.8.6, Artifactory pouvait être trompé en croyant que la demande émanait localement si l'en-tête HTTP `X-Forwarded-For` était défini sur `127.0.0.1`.
La vulnérabilité est assez simple : si une ressource déployée est définie comme filtrée, elle est interprétée comme un modèle Freemarker, ce qui donne à l'attaquant une fenêtre d'attaque SSTI. 
Ces primitives devraient suffire à vous donner une exécution de code à distance de plusieurs manières, de la plus facile/la plus silencieuse à la plus difficile/la plus bruyante :
* lecture d'un secret sur le système de fichiers qui vous permet de pivoter (/home/user/.bash\_history, /home/user/password.txt, /home/user/.ssh/id\_rsa ...)
* ajout d'une clé SSH à l'utilisateur
* déploiement d'un fichier .war pour exécuter un servlet
* déploiement d'un script utilisateur Groovy Artifactory
### Histoires de .war : les manigances de Java renameTo() <a href="#war-stories-java-renameto-shenanigans" id="war-stories-java-renameto-shenanigans"></a>
Voici une petite histoire de comment j'ai cogné ma tête contre le mur pendant des heures, voire des jours, lors d'un pentest. Je suis tombé sur une version obsolète d'Artifactory que je savais vulnérable à CVE-2020-7931. J'ai déployé le modèle SSTI de l'avis original et j'ai commencé à parcourir le système de fichiers. Il semblait qu'Artifactory avait été installé dans un emplacement non standard, ce qui n'est pas trop inhabituel car les administrateurs aiment garder des partitions séparées entre les binaires d'application, les données, les journaux et la configuration (ce qui est une bonne chose !). Il n'y avait pas de clés SSH ou de mots de passe dans le répertoire personnel de l'utilisateur qui m'auraient permis de pivoter facilement, donc il était temps d'être moins discret et d'écrire sur le système de fichiers. Le dépôt de la charge utile initiale (une clé publique) dans le répertoire de téléchargement d'Artifactory s'est bien passé, mais je n'ai tout simplement pas réussi à la déplacer vers le répertoire des clés SSH. Alors je suis retourné dans mon bac à sable d'exploitation, je l'ai testé à nouveau et ça a marché. Il devait donc y avoir une configuration différente qui m'empêchait de terminer la méthode `renameTo()`. À ce stade, il est toujours bon de [vérifier la documentation](https://docs.oracle.com/javase/8/docs/api/java/io/File.html#renameTo-java.io.File-) ... qui indique clairement que vous ne pouvez pas renommer des fichiers entre différents systèmes de fichiers, ce qui a du sens en fonction de la mise en œuvre de la méthode, c'est-à-dire si elle fonctionne au niveau de l'inode. Arg.
Rappelez-vous ce que j'ai dit sur les administrateurs qui aiment les partitions ? Eh bien, c'est un cas d'un administrateur qui a durci sa configuration à l'insu de son plein gré contre mon exploit ! J'ai donc dû fouiller dans ce qui est essentiellement une prison Java pour trouver une autre méthode qui me permettrait d'écrire un fichier sur le disque. Et ce n'était pas amusant du tout, car je ne suis pas familier avec aucune des choses impliquées : les modèles FTL, Java, Tomcat/Catalina. J'ai rapidement découvert que les évasions de prison Java régulières ne suffiraient pas, car l'instanciation de nouvelles classes était interdite. Après des heures de lecture de la documentation des classes Java et Catalina, j'ai enfin trouvé une méthode write() sur un objet auquel je pouvais accéder. Mais elle était limitée au chemin de base de l'application web... Alors j'ai pensé à combiner l'écriture sur un autre système de fichiers et le `renameTo()` sur ce nouveau système de fichiers accessible pour espérer pouvoir écrire n'importe où ? Et ça a marché un peu. J'ai réussi à écrire en dehors du répertoire de téléchargement temporaire... mais pas très loin de celui-ci car j'étais maintenant bloqué sur un autre système de fichiers qui était le point de montage de toutes les choses Artifactory : configuration, application et autres. Donc toujours pas de clé SSH pour moi.
D'accord, je pourrais écrire dans le dossier racine d'Artifactory, sûrement je pourrais faire quelque chose ici ? Hé, Tomcat par défaut déploie automatiquement les fichiers WAR écrits dans son chemin d'application, n'est-ce pas ? Alors j'ai utilisé msfvenom pour générer un shell web JSP empaqueté dans un fichier WAR et je l'ai testé dans mon bac à sable... eh bien, il a été déployé correctement, mais ne m'a pas donné d'exécution de commande. Il semble que Tomcat par défaut ne gère pas les JSP. Ugh. De plus en plus frustré, j'ai cherché un autre moyen d'exécuter du code dans Tomcat et j'ai trouvé une autre méthode d'exécution en utilisant des servlets. Je n'ai pas trouvé de charge utile appropriée, alors je me suis dit que je suis tout dedans à ce stade et [j'ai développé le mien que vous pouvez trouver ici](https://github.com/gquere/javaWebShell). Je l'ai testé dans le bac à sable, ça marche, ok
Artifactory peut avoir besoin de stocker des secrets pour s'identifier auprès de services distants. Ces secrets ne sont évidemment pas hashés, ils sont stockés chiffrés sur le disque, avec la clé à côté d'eux. Il existe deux types de secrets mentionnés dans la [documentation officielle](https://jfrog.com/knowledge-base/what-are-the-artifactory-key-master-key-and-what-are-they-used-for/).
Les secrets externes (tels que les mots de passe des serveurs distants) se trouvent dans les [descripteurs de configuration](https://www.jfrog.com/confluence/display/JFROG/Configuration+Files#ConfigurationFiles-GlobalConfigurationDescriptor), par exemple `/var/opt/jfrog/artifactory/etc/artifactory.config.latest.xml` et ressemblent à:
Cet outil que j'ai écrit peut être utilisé hors ligne pour décrypter les secrets d'Artifactory : [ArtifactoryDecryptor](https://github.com/gquere/ArtifactoryDecryptor).
* maintenir Artifactory à jour, surtout lorsqu'il y a des mises à jour critiques
* mettre en place une politique de mot de passe solide (pas de mots de passe par défaut, des mots de passe forts obligatoires, des verrouillages), de préférence différée à un LDAP externe pour une meilleure supervision
* restreindre les accès (respecter le principe du moindre privilège), en particulier pour l'utilisateur anonyme
