Résumé

  • APNIC a observé 2 621 adresses source lancer la même commande après une connexion SSH à un leurre. Elle supprimait le répertoire ~/.ssh, écrivait une clé dans authorized_keys, puis réglait les permissions.
  • Une fois la clé en place, le mot de passe ne sert plus à cette voie d’accès. APNIC publie l’empreinte SHA-256 de la clé et affirme qu’un serveur qui la contient dans authorized_keys est compromis.

Le mot de passe ouvre la porte. La clé est le double qui reste dans la serrure.

Dans son rapport d’une semaine sur le honeynet reconstruit, APNIC relève 2 621 adresses source ayant exécuté la même commande après une connexion SSH. Celle-ci supprimait le répertoire ~/.ssh existant, écrivait une clé contrôlée par l’attaquant dans authorized_keys, puis en fixait les permissions. APNIC décrit clairement la suite : une fois la clé installée, le mot de passe n’est plus nécessaire.

La différence entre ces deux étapes est le cœur du signal. Un mot de passe faible facilite le premier accès. Une clé autorisée inscrit un nouvel accès dans le compte. La commande observée ne se contente pas d’ajouter une entrée à une liste déjà en place : elle supprime d’abord le répertoire qui contient les clés. Après la connexion, le système de confiance a changé.

Le honeynet a enregistré cette séquence sur ses propres leurres. Ce cadre donne à l’observation une portée précise : APNIC peut décrire un comportement post-connexion récurrent et fournir un indicateur vérifiable. L’empreinte publiée est SHA256:MkYY9qiVsFGBC5WkjoClCkwEFW5iSjcGQF7m4n4H7Cw; le commentaire de la clé se termine par mdrfckr. Selon APNIC, tout serveur dont le fichier authorized_keys contient cette clé est compromis.

Entre le 21 et le 27 septembre, 9 669 adresses source ont tenté une connexion SSH et 2 621 ont lancé la même commande après connexion. Une autre mesure compte 8 797 adresses ayant laissé des fichiers sur les capteurs, soit 506 fichiers distincts. APNIC ne publie pas le recoupement entre ces groupes; chaque mesure garde son périmètre.

Le mot de passe et la clé publique contrôlent deux voies d’accès distinctes. Renouveler le mot de passe met à jour la première; la clé plantée reste valide tant qu’elle figure dans authorized_keys et que le serveur accepte l’authentification par clé.

La réponse commence par la trace : chercher l’empreinte publiée dans les fichiers authorized_keys, examiner les modifications inattendues de ~/.ssh et vérifier les changements produits par la connexion. Si la clé apparaît, APNIC qualifie le serveur de compromis. Retirer l’accès non autorisé, établir l’étendue des modifications, restaurer les clés légitimes depuis une source fiable, puis renouveler les mots de passe exposés.

Le honeynet d’APNIC observe SSH, Telnet, Windows et d’autres services-leurres. La ligne décisive montre comment une connexion devient un nouvel identifiant durable.

Source : le rapport hebdomadaire d’APNIC sur son honeynet.