- 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 ou le groupe Telegram 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).
Si vous avez accès à un serveur FTP de rebond, vous pouvez le faire demander des fichiers d'un autre serveur FTP (où vous connaissez des identifiants) et télécharger ce fichier sur votre propre serveur.
1. Connectez-vous à votre propre serveur FTP et rendez la connexion passive (commande pasv) pour qu'elle écoute dans un répertoire où le service victime enverra le fichier
2. Faites le fichier qui va envoyer le serveur FTP intermédiaire au serveur victime (l'exploit). Ce fichier sera un texte simple des commandes nécessaires pour s'authentifier contre le serveur victime, changer de répertoire et télécharger un fichier sur votre propre serveur.
3. Connectez-vous au serveur FTP intermédiaire et téléchargez le fichier précédent
4. Faites en sorte que le serveur FTP intermédiaire établisse une connexion avec le serveur victime et envoie le fichier d'exploitation
5. Capturez le fichier sur votre propre serveur FTP
6. Supprimez le fichier d'exploitation du serveur FTP intermédiaire
Ceci discute l'une des nombreuses utilisations possibles de l' "attaque de rebond de serveur FTP". Le mécanisme utilisé est probablement bien connu, mais jusqu'à présent, l'intérêt pour le détailler ou le corriger semble faible à inexistant. Cet exemple particulier démontre encore une autre façon dont la plupart des "restrictions d'exportation" électroniquement appliquées sont complètement inutiles et faciles à contourner. Il est choisi dans un effort pour faire en sorte que le lecteur se rende compte qu'il y a certains aspects vraiment mal conçus du protocole FTP standard.
Merci également à Alain Knaff chez imag.fr pour une discussion brève mais divertissante de certaines de ces questions il y a quelques mois qui m'a fait réfléchir plus profondément à leur sujet.
Vous êtes un utilisateur sur foreign.fr, adresse IP F.F.F.F, et vous voulez récupérer le code source cryptographique de crypto.com aux États-Unis. Le serveur FTP de crypto.com est configuré pour permettre votre connexion, mais refuser l'accès aux sources cryptographiques parce que votre adresse IP source est celle d'un site non américain [aussi près que leur serveur FTP peut le déterminer à partir du DNS, c'est-à-dire]. En tout cas, vous ne pouvez pas récupérer directement ce que vous voulez à partir du serveur de crypto.com.
Cependant, crypto.com permettra à ufred.edu de télécharger des sources cryptographiques parce que ufred.edu est également aux États-Unis. Vous savez que /incoming sur ufred.edu est un répertoire accessible en écriture dans le monde entier que tout utilisateur anonyme peut déposer des fichiers et les lire. L'adresse IP de crypto.com est C.C.C.C.
Cela suppose que vous avez un serveur FTP qui fait du mode passif. Ouvrez une connexion FTP à l'adresse IP réelle de votre propre machine [pas localhost] et connectez-vous. Changez de répertoire pour un répertoire pratique auquel vous avez accès en écriture, puis faites :
Prenez note de l'adresse et du port renvoyés par la commande PASV, F,F,F,F,X,X. Cette session FTP va maintenant être suspendue, donc mettez-la en arrière-plan ou passez à une autre fenêtre ou quelque chose pour continuer le reste de la procédure.
F,F,F,F,X,X représente la même adresse et le même port que votre propre machine vous a fourni lors de la première connexion. Les données inutiles à la fin sont des lignes supplémentaires que vous créez, chacune contenant 250 NULLS et rien d'autre, suffisamment pour remplir environ 60 Ko de données supplémentaires. La raison de ce remplissage sera expliquée plus tard.
Ouvrez une connexion FTP vers ufred.edu, connectez-vous en tant qu'utilisateur anonyme et accédez à /incoming. Maintenant, tapez ce qui suit dans cette session FTP, qui transfère une copie de votre fichier "`instrs`" puis demande au serveur FTP d'ufred.edu de se connecter au serveur FTP de crypto.com en utilisant votre fichier comme commandes :
`Crypto.tar.Z` devrait maintenant apparaître comme "`foobar`" sur votre machine via votre première connexion FTP. Si la connexion à ufred.edu ne s'est pas interrompue d'elle-même en raison d'un bogue de serveur apparemment courant, nettoyez en supprimant "`instrs`" et en sortant. Sinon, vous devrez vous reconnecter pour terminer.
Il existe plusieurs variantes de cela. Votre connexion de récepteur PASV peut être ouverte sur n'importe quelle machine à laquelle vous avez accès en écriture de fichiers - la vôtre, une autre connexion à ufred.edu ou quelque part complètement différent. En fait, cela n'a même pas besoin d'être un serveur FTP - n'importe quelle utilité qui écoutera sur un port TCP connu et lira des données brutes à partir de celui-ci dans un fichier fera l'affaire. Une connexion de données FTP en mode passif est simplement un moyen pratique de le faire.
Les zéros supplémentaires à la fin du fichier de commande sont là pour remplir les fenêtres TCP des deux côtés de la connexion ufred -> crypto, et garantir que la connexion de commande reste ouverte suffisamment longtemps pour que toute la session soit exécutée. Sinon, la plupart des serveurs FTP ont tendance à interrompre tous les transferts et le traitement des commandes lorsque la connexion de contrôle se ferme prématurément. La taille des données est suffisante pour remplir les fenêtres de réception et de transmission, qui sur certains systèmes d'exploitation sont assez grandes \[de l'ordre de 30K\]. Vous pouvez réduire cela si vous connaissez les systèmes d'exploitation des deux extrémités et la somme de leurs tailles de fenêtre TCP par défaut. Il est divisé en lignes de 250 caractères pour éviter de dépasser les tampons de commandes sur le serveur cible - probablement académique puisque vous avez déjà demandé au serveur de quitter.
Si crypto.com interdit \*toute\* connexion de client FTP de votre part à foreign.fr et que vous devez voir quels fichiers sont où, vous pouvez toujours mettre "`list -aR`" dans votre fichier de commande et obtenir une liste de répertoire de l'arborescence entière via ufred.
Vous devrez peut-être récupérer votre fichier de commande sur le serveur FTP cible en mode ASCII plutôt qu'en mode binaire. Certains serveurs FTP peuvent traiter les nouvelles lignes brutes, mais d'autres peuvent avoir besoin de lignes de commande terminées par des paires CRLF. Gardez cela à l'esprit lorsque vous récupérez des fichiers vers des démons autres que des serveurs FTP.
Malgré le fait que de telles connexions tierces ne soient que dans un sens, elles peuvent être utilisées pour toutes sortes de choses. Des méthodes similaires peuvent être utilisées pour poster des courriers et des nouvelles virtuellement non traçables, marteler des serveurs sur divers sites, remplir des disques, essayer de sauter des pare-feu et être généralement ennuyeux et difficiles à suivre en même temps. Un peu de réflexion permettra de réaliser de nombreuses autres possibilités effrayantes.
Les connexions lancées de cette manière proviennent du port source 20, que certains sites autorisent à travers leurs pare-feu dans un effort pour traiter le problème "ftp-data". Pour certains usages, cela peut être la meilleure chose suivante aux attaques à routage source, et est susceptible de réussir là où le routage source échoue contre les filtres de paquets. Et tout cela est rendu possible par la façon dont la spécification du protocole FTP a été écrite, permettant aux connexions de contrôle de venir de n'importe où et aux connexions de données d'aller n'importe où.
Il y aura toujours des sites sur le net avec des serveurs FTP craquelés et des répertoires inscriptibles qui permettent ce genre de trafic, donc dire "réparez tous les serveurs FTP" est la mauvaise réponse. Mais vous pouvez protéger le vôtre contre le fait d'être un point de rebond tiers et contre l'utilisation d'un autre contre vous.
La première chose évidente à faire est de permettre à un serveur FTP de ne faire des connexions de données qu'à partir de l'hôte même d'où est originaire la connexion de contrôle. Cela n'empêche pas l'attaque ci-dessus, bien sûr, puisque le récepteur PASV pourrait tout aussi bien être sur ufred.edu et donc répondre à cette exigence, mais cela empêche que votre site soit un point de rebond potentiel. Cela rompt également le concept de "proxy FTP", mais quelque part caché dans ce paragraphe se trouve un très petit violon.
La prochaine chose évidente est d'interdire les connexions de contrôle FTP qui proviennent de ports réservés, ou du moins du port 20. Cela empêche le scénario ci-dessus tel qu'il est décrit.
Ces deux choses, plus les habituelles bêtises sur le blocage des paquets à routage source et d'autres avenues de spoofing, sont nécessaires pour empêcher les hacks de ce genre. Et réfléchissez à la question de savoir si vous avez vraiment besoin d'un répertoire "entrant" ouvert.
Ne permettre que des connexions de données client en mode passif est une autre possibilité, mais il y a encore trop de clients FTP en cours d'utilisation qui ne sont pas conscients du mode passif.
Il existe des travaux existants qui abordent cela disponibles ici sur avian.org \[et cela fait plusieurs mois, je pourrais ajouter\] dans l'archive "[fixkits](ftp://ftp.avian.org:/src/fixkits/)". Plusieurs mods pour wu-ftpd-2.4 sont présentés, qui incluent du code pour empêcher et journaliser les tentatives d'utilisation de commandes PORT bidon. Des correctifs de sécurité récents d'ailleurs sont également inclus, ainsi que la prise en charge de s/key et diverses options de compilation pour renforcer la sécurité pour des applications spécifiques.
Stan Barber chez academ.com travaille à la fusion de ces correctifs et de plusieurs autres correctifs dans une véritable version mise à jour de wu-ftpd. Il y a quelques autres efforts divergents en cours. Nulle part il n'est affirmé que tout ce travail est complet pour le moment, mais c'est un début vers quelque chose que j'ai en tête depuis un certain temps - une version de wu-ftpd-2.5 à l'échelle du réseau, avec des contributions de partout sur le net. Le serveur wu-ftpd est devenu très populaire, mais a grand besoin d'une autre mise à niveau de sécurité. Il serait agréable de rassembler toutes les améliorations en un seul endroit coordonné, et il semble que cela se produira. Tout cela n'aidera toujours pas les personnes qui insistent pour exécuter des serveurs fournis par le fournisseur, bien sûr.
La vérification de la source du port de connexion du client n'est pas implémentée spécifiquement dans les correctifs du serveur FTP, mais dans des modifications du package tcp-wrappers de Wietse, car ce problème est plus général. Une option PORT simple est ajoutée qui refuse les connexions à partir de plages configurables de ports source à l'étape tcpd, avant qu'un démon appelé ne soit exécuté.
Certaines de ces modifications sont indiquées dans [/src/fixkits/README](ftp://ftp.avian.org:/src/fixkits/README) dans la zone FTP anonyme ici. Lisez cette feuille de route avant de prendre d'autres choses.
Ajouter les zéros à la fin du fichier de commande était la clé pour faire fonctionner cela contre une variété de démons. L'envoi simplement des données souhaitées échouerait généralement en raison de la fermeture immédiate signalant au démon de se retirer.
Si WUSTL n'a pas abandonné complètement le projet wu-ftpd, ils sont très discrets sur les travaux ultérieurs. Bryan O'Connor semble avoir beaucoup d'autres projets à gérer maintenant...
C'est un script trivial pour trouver des répertoires et des fichiers appartenant au monde et appartenant à FTP sur un serveur FTP anonyme basé sur Unix. Vous seriez surpris de voir combien de ces "points de rebond" inscriptibles apparaissent après une courte exécution de quelque chose comme cela. Vous devrez ensuite vérifier que vous pouvez à la fois mettre et obtenir des fichiers à partir de tels endroits ; certains serveurs protègent les fichiers téléchargés contre la lecture. Beaucoup ne le font pas, et se demandent ensuite pourquoi ils font partie des dix meilleurs sites de warez de cette semaine...
Je suppose qu'on pourrait appeler cela un livre blanc. Il est disponible sur avian.org dans [/random/ftp-attack](ftp://ftp.avian.org:/random/ftp-attack) ainsi que dans divers endroits pertinents. \_H\* 950712
- 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)**.
