Déboguer les attaques Hydra

Introduction

Dans ce laboratoire, vous apprendrez à déboguer les attaques Hydra en configurant un serveur Telnet et en analysant la sortie de débogage d'Hydra. Le laboratoire se concentre sur la compréhension du comportement d'Hydra pendant une attaque grâce à des informations de débogage détaillées.

Tout d'abord, vous configurerez un serveur Telnet sur la machine virtuelle LabEx en utilisant xinetd pour gérer le service Telnet. Cela implique d'installer telnetd et xinetd, de configurer xinetd pour gérer les connexions Telnet et de redémarrer le service xinetd. Ensuite, vous exécuterez Hydra en mode débogage en utilisant le paramètre -d pour générer une sortie détaillée. Enfin, vous analyserez cette sortie de débogage pour comprendre le processus d'attaque et identifier les problèmes potentiels.

Skills Graph

Configuration d'un serveur Telnet

Dans cette étape, nous allons configurer un serveur Telnet sur la machine virtuelle LabEx. Telnet est un protocole réseau utilisé pour fournir une capacité de communication interactive bidirectionnelle orientée texte en utilisant une connexion de terminal virtuel. Bien que Telnet soit généralement considéré comme peu sécurisé en raison de son manque de chiffrement, il peut être utile pour des tests et des démonstrations dans un environnement contrôlé comme notre machine virtuelle LabEx.

Étant donné que la machine virtuelle LabEx utilise des conteneurs Docker, nous ne pouvons pas utiliser directement systemctl pour gérer les services. Au lieu de cela, nous utiliserons xinetd pour gérer le service Telnet. xinetd (extended Internet daemon) est un super-daemon qui écoute les connexions réseau entrantes et lance le service approprié.

Tout d'abord, installons les paquets telnetd et xinetd. Ouvrez votre terminal dans la machine virtuelle LabEx et exécutez la commande suivante :

sudo apt update
sudo apt install telnetd xinetd -y

Cette commande met à jour la liste des paquets et installe les paquets telnetd (daemon du serveur Telnet) et xinetd. Le paramètre -y répond automatiquement "oui" à toutes les invitations pendant l'installation.

Ensuite, nous devons configurer xinetd pour gérer le service Telnet. Créez un fichier de configuration pour Telnet dans le répertoire /etc/xinetd.d/. Utilisez nano pour créer et éditer le fichier :

sudo nano /etc/xinetd.d/telnet

Collez la configuration suivante dans l'éditeur nano :

service telnet
{
        flags           = REUSE
        socket_type     = stream
        wait            = no
        user            = root
        server          = /usr/sbin/in.telnetd
        log_on_failure  += USERID
        disable         = no
}

Cette configuration indique à xinetd d'écouter les connexions Telnet, de lancer le serveur /usr/sbin/in.telnetd en tant que root et de consigner les échecs de connexion. disable = no garantit que le service est activé.

Appuyez sur Ctrl+X, puis sur Y, puis sur Entrée pour enregistrer le fichier et quitter nano.

Maintenant, redémarrez le service xinetd pour appliquer les modifications. Étant donné que nous ne pouvons pas utiliser systemctl, nous allons utiliser une solution de contournement en envoyant un signal HUP au processus xinetd. Tout d'abord, trouvez l'identifiant du processus xinetd :

ps -ef | grep xinetd

Vous devriez voir une sortie similaire à :

root       1234  1     0 10:00 ?        00:00:00 /usr/sbin/xinetd -stayalive -pidfile /run/xinetd.pid
labex      5678  5600  0 10:01 pts/0    00:00:00 grep --color=auto xinetd

Notez l'identifiant du processus xinetd (dans cet exemple, c'est 1234). Remplacez 1234 par l'identifiant du processus réel de votre sortie dans la commande suivante :

sudo kill -HUP 1234

Cette commande envoie un signal HUP au processus xinetd, ce qui le force à recharger sa configuration.

Enfin, vérifions que le serveur Telnet est en cours d'exécution. Vous pouvez essayer de vous y connecter depuis la même machine en utilisant la commande telnet. Étant donné que le client telnet n'est peut-être pas installé par défaut, nous utiliserons netcat pour tester la connexion.

nc localhost 23

Si le serveur Telnet est en cours d'exécution, vous devriez voir un écran blanc ou une invite Telnet. Vous pouvez ensuite fermer la connexion en tapant Ctrl+] puis quit. Si vous obtenez "Connection refused", vérifiez à nouveau les étapes ci-dessus.

Exécution en mode débogage avec l'option -d

Dans cette étape, nous allons configurer xinetd pour exécuter le serveur Telnet en mode débogage. L'exécution en mode débogage peut fournir des informations précieuses sur le fonctionnement du serveur, ce qui peut être utile pour la résolution de problèmes et la compréhension de son fonctionnement.

Pour activer le mode débogage, nous devons modifier le fichier de configuration xinetd pour Telnet que nous avons créé à l'étape précédente. Ouvrez le fichier /etc/xinetd.d/telnet en utilisant nano :

sudo nano /etc/xinetd.d/telnet

Modifiez la ligne server pour inclure l'option -d pour le mode débogage. La ligne devrait maintenant ressembler à ceci :

        server          = /usr/sbin/in.telnetd -d

L'option -d indique à in.telnetd d'exécuter en mode débogage, fournissant une sortie plus détaillée.

Appuyez sur Ctrl+X, puis sur Y, puis sur Entrée pour enregistrer le fichier et quitter nano.

Maintenant, redémarrez le service xinetd pour appliquer les modifications. Comme précédemment, nous utiliserons la commande kill -HUP. Tout d'abord, trouvez l'identifiant du processus xinetd :

ps -ef | grep xinetd

Notez l'identifiant du processus xinetd (par exemple, 1234). Remplacez 1234 par l'identifiant du processus réel de votre sortie dans la commande suivante :

sudo kill -HUP 1234

Cette commande envoie un signal HUP au processus xinetd, ce qui le force à recharger sa configuration, avec maintenant le serveur Telnet exécuté en mode débogage.

Pour observer la sortie de débogage, nous devons rediriger la sortie standard de xinetd vers un fichier. Cependant, xinetd lui-même n'envoie pas directement de sortie vers un fichier. La sortie de débogage de in.telnetd -d sera envoyée aux journaux système. Nous pouvons surveiller ces journaux en utilisant tail -f.

Ouvrez une nouvelle fenêtre ou un nouvel onglet de terminal. Dans ce nouveau terminal, exécutez la commande suivante pour surveiller les journaux système :

sudo tail -f /var/log/syslog

Maintenant, revenez à votre terminal d'origine et essayez de vous connecter au serveur Telnet en utilisant netcat :

nc localhost 23

Après vous être connecté (et vous être déconnecté en tapant Ctrl+] puis quit), revenez au terminal où vous exécutez tail -f /var/log/syslog. Vous devriez voir la sortie de débogage de in.telnetd liée à la connexion. Cette sortie fournira des informations sur les activités du serveur Telnet, telles que l'établissement et la terminaison de la connexion.

Analyse de la sortie de débogage

Dans cette étape, nous allons analyser la sortie de débogage générée par le serveur Telnet lorsqu'il est exécuté en mode débogage. Comprendre cette sortie peut vous aider à diagnostiquer des problèmes, à comprendre le protocole Telnet et potentiellement à identifier des vulnérabilités.

Comme vous l'avez vu à l'étape précédente, la sortie de débogage est écrite dans le journal système (/var/log/syslog). Examinons quelques sorties de débogage typiques et ce qu'elles signifient.

Tout d'abord, assurez-vous que vous surveillez toujours le journal système dans une fenêtre de terminal séparée :

sudo tail -f /var/log/syslog

Ensuite, connectez-vous au serveur Telnet en utilisant netcat dans votre terminal d'origine :

nc localhost 23

Tapez quelques caractères, puis déconnectez-vous en tapant Ctrl+] suivi de quit.

Maintenant, examinez la sortie dans le terminal affichant le syslog. Vous devriez voir des lignes similaires aux suivantes (la sortie exacte peut varier) :

Oct 26 14:30:00 labex in.telnetd[1234]: connect from ::1
Oct 26 14:30:00 labex in.telnetd[1234]: telnetd: sock_host_addr: ::1
Oct 26 14:30:05 labex in.telnetd[1234]: ttloop: client wrote 5 bytes
Oct 26 14:30:05 labex in.telnetd[1234]: recv: got IAC
Oct 26 14:30:05 labex in.telnetd[1234]: recv: IAC SB
Oct 26 14:30:05 labex in.telnetd[1234]: recv: got IAC SE
Oct 26 14:30:10 labex in.telnetd[1234]: ttloop: client wrote 6 bytes
Oct 26 14:30:10 labex in.telnetd[1234]: recv: got IAC
Oct 26 14:30:10 labex in.telnetd[1234]: recv: IAC SB
Oct 26 14:30:10 labex in.telnetd[1234]: recv: got IAC SE
Oct 26 14:30:15 labex in.telnetd[1234]: Exit on signal 15

Décortiquons quelques-unes de ces lignes :

• connect from ::1 : Cela indique qu'une connexion a été établie depuis l'adresse de bouclage IPv6 (::1), qui est l'équivalent de 127.0.0.1 pour IPv4.
• telnetd: sock_host_addr: ::1 : Cela confirme l'adresse source de la connexion.
• ttloop: client wrote 5 bytes : Cela montre que le client (votre session netcat) a envoyé 5 octets de données au serveur.
• recv: got IAC : IAC signifie "Interpret As Command" (Interpréter comme une commande). Telnet utilise des codes de contrôle spéciaux, et IAC est le préfixe de ces codes.
• recv: IAC SB et recv: got IAC SE : SB signifie "Subnegotiation Begin" (Début de sous-négociation) et SE signifie "Subnegotiation End" (Fin de sous-négociation). Ces lignes indiquent que le client et le serveur négocient des options.
• Exit on signal 15 : Cela indique que le processus telnetd s'est arrêté après avoir reçu le signal 15, qui est le signal par défaut envoyé par kill sans spécifier de numéro de signal. Cela s'est produit lorsque vous avez fermé la connexion netcat.

En analysant cette sortie de débogage, vous pouvez obtenir des informations sur le protocole Telnet et sur la façon dont le serveur gère les connexions et les données. Ces informations peuvent être précieuses pour l'analyse de sécurité, la résolution de problèmes et la compréhension de la communication réseau.

Par exemple, si vous essayiez d'exploiter une vulnérabilité dans le serveur Telnet, vous pourriez utiliser cette sortie de débogage pour comprendre comment votre attaque est traitée et identifier des faiblesses potentielles.

Résumé

Dans ce laboratoire, nous avons commencé par configurer un serveur Telnet sur la machine virtuelle LabEx en utilisant xinetd pour gérer le service telnetd. Cela a impliqué l'installation des paquets nécessaires (telnetd et xinetd) et la configuration de xinetd pour écouter les connexions Telnet et exécuter le démon du serveur Telnet.

Le fichier de configuration /etc/xinetd.d/telnet a été créé et rempli de paramètres pour activer le service Telnet, spécifier l'exécutable du serveur et gérer la journalisation des connexions. Enfin, le service xinetd a été redémarré pour appliquer les modifications de configuration, préparant le serveur Telnet aux tests.