Comme les autres r-commands, rsh ne fournit aucun chiffrement, si bien qu'un attaquant sur le chemin lit tout l'échange : la commande exécutée, sa sortie complète et toute donnée transférée. Parce que rsh repose couramment sur la confiance basée sur l'hôte plutôt que sur des mots de passe, le butin est généralement la commande et la sortie (qui incluent souvent des données sensibles ou des identifiants secondaires que la commande manipule) plutôt qu'un mot de passe de connexion, mais là où une authentification par mot de passe est en jeu, elle est capturée aussi. Le flux TCP non authentifié après l'établissement est également détournable, correspondant à la technique de prise de contrôle de session Telnet/rlogin.
# capture rsh traffic from an on-path position
tcpdump -i eth0 -A port 514 -w rsh.pcap
# follow the TCP stream to read the command, output, and any data/credentials
tshark -r rsh.pcap -q -z follow,tcp,ascii,0
Notes d'exploitation#
- La principale valeur de capture est la commande et sa sortie, qui portent fréquemment des données sensibles ou des identifiants secondaires ; le rsh en confiance d'hôte n'a souvent aucun mot de passe à sniffer, donc le contenu est la cible.
- Le flux est détournable (injecter une commande dans la session TCP établie), la même technique que le détournement de session rlogin et Telnet ; une seule commande injectée peut planter une confiance
.rhostsdurable. - Nécessite une position on-path ou tap ; les r-commands sur un segment hérité plat sont facilement interceptées.
- C'est la faiblesse en clair partagée de toutes les r-commands ; voir le groupe interception de trafic pour le traitement transversal.