Bien que les attaques en bruteforce des SSH fassent partie du bruit blanc du trafic réseau des systèmes connectés, leur étude révèle des profils d'attaquants à l'hétérogénéité intrigante. Leur analyse approfondie grâce à un pot de miel dédié révèle des informations intéressantes sur les agresseurs.
1. Qu'est-ce que c'est ?
Les attaques dites « bruteforce SSH » sont des tentatives de connexions SSH effectuant une succession d'essais pour découvrir un couple utilisateur/mot de passe valide afin de prendre le contrôle de la machine. Il s'agit d'une attaque très répandue et toute machine exposée sur Internet se verra attaquer plusieurs fois par jour.
La fréquence de ces attaques a entraîné l'apparition de diverses méthodes de protection telle que l'utilisation d'un port non standard pour le serveur SSH. Une autre méthode très répandue est l'utilisation d'outils comme Fail2ban [FAIL2BAN] qui analyse les journaux SSH pour trouver les adresses IP responsables de trop nombreux échecs de connexions et modifie la configuration du pare-feu pour bloquer les tentatives ultérieures.
2. Collecte des informations
2.1 Présentation du point de collecte
Cet article présente l’analyse de données collectées sur un ADSL résidentiel français dont l'adresse IPv4 n'est associable à aucun service public. Il s'agit donc d'une adresse anonyme perdue au milieu des 2^32 autres. Des redirections de ports sont utilisées sur le modem routeur pour envoyer le trafic de certains ports vers la machine cible.
2.2 Journaux systèmes
Les premières sources d'information pour récupérer des données sur les bruteforce SSH sont bien entendu les journaux syslog et en particulier ceux générés par le démon SSH :
Aug 24 19:55:10 tiger2 sshd[2525]: Failed password for miscmag from 1.2.3.4 port 48459 ssh2
Ces journaux permettent de récupérer le nom d’utilisateur, l'adresse IP et le port utilisés pour la tentative de connexion. Si cela fournit déjà quelques informations intéressantes, il manque cependant des informations de bas niveaux (niveau TCP) et de haut niveau (niveau applicatif). Il est possible d'obtenir plus de détails dans les journaux en en modifiant le niveau de détail des journaux SSH, mais le côté intrusif de la démarche n'est pas très satisfaisant et elle ne permet pas d'obtenir les informations pour un réseau complet.
2.3 Outils d'analyse réseaux
L'IDPS Suricata [Suricata] présenté dans MISC n°66 est une sonde réseau de détection d'intrusion open source. Elle propose les fonctionnalités d'un IDS basé sur des signatures combiné à des fonctions de surveillance réseau orienté sécurité (Network Security Monitoring) qui ont été renforcées avec la version 2.0 parue en début d'année 2014. De nouveaux protocoles ont été ajoutés et Suricata peut maintenant extraire et journaliser des éléments des protocoles HTTP, TLS, DNS et SSH. Le tout peut être enregistré dans un fichier au format JSON qui est extensible et s’intègre facilement avec des outils d'analyse de données récents comme Splunk [SPLUNK] ou Elasticsearch [ELK]. Cette dernière solution sera présentée et utilisée dans la suite de l'article.
Pour récupérer des informations de bas niveau, c'est ulogd2, le démon de journalisation de Netfilter qui a été utilisée. Depuis la version 2.0.4, un export JSON des informations est disponible ce qui rend facile l'intégration avec Elasticsearch. La configuration pare-feu mise en place journalise les connexions entrantes sur le système en générant un message pour chaque paquet SYN.
2.4 Analyse des données
Les données collectées sont enregistrées et analysées grâce au trio Elasticsearch, Logstash, Kibana communément appelé ELK. Elasticsearch est un moteur de recherche et d'indexation basé sur Lucene de la fondation Apache. Son architecture est distribuée de manière à assurer le passage à l'échelle lors de l'augmentation de la quantité de données par ajout de nœuds. Elasticsearch peut être vu comme une base de données NoSQL qui utilise la méthode REST pour les requêtes.
Logstash est un logiciel qui convertit les données d'une série de greffons d'entrée vers différents greffons de sortie. Les greffons d'entrée vont de l’acquisition de fichiers simples au traitement d’informations de redis ou rabbitmq en passant par la lecture de Twitter. Les sorties sont également très variées et elles adressent notamment Jira ou IRC même si l'export vers Elasticsearch est le plus utilisé. Un système de filtres est intercalé entre les greffons d'entrée et de sortie pour pouvoir réaliser des modifications (normalisation par exemple) et des enrichissements (ajout des données geoip par exemple).
Kibana est un visualiseur de données qui est basé sur des tableaux de bord construits dynamiquement par l'utilisateur. La philosophie de l'interface est une approche en entonnoir avec une création de filtres lorsque l'utilisateur clique sur un élément et un rafraîchissement des différents éléments du tableau de bord.
L'ensemble de ces outils est open source et, est, il convient de le noter, très facile à installer.
3. Première analyse
3.1 Volumétrie
Le point de collecte a subi plus de 10000 tentatives d'authentification SSH par jour. Des pointes à 300 essais par minute ont été observées. Dans la plupart des cas, de tels maximums sont liés aux tentatives de bruteforce effectuées par un attaquant unique dont le script est particulièrement agressif.
3.2 Géographie des attaques
La répartition géographique des attaques correspond à ce qui est généralement observé par les utilisateurs de Fail2ban avec plus de 90% provenant de Chine.
Cependant, la distribution des adresses chinoises est intéressante puisque, au moment de l'écriture de cet article, elles sont concentrées sur les réseaux 61.174.15.0/24 et 116.10.191.0/24 et elles semblent toutes être utilisées pour des attaques par bruteforce. Il est donc imaginable que les serveurs de ces réseaux soient dédiés aux scans et aux bruteforce sur certains protocoles comme SSH et qu’il s’agisse d’une véritable infrastructure d'attaque.
3.3 Technologies utilisées
Suricata journalise la version des logiciels clients et serveurs pour toutes les connexions et il est donc possible de connaître les technologies utilisées. Il s'agit majoritairement de libssh [LIBSSH] et libssh2 [LIBSSH2]. Le tableau suivant montre la répartition des événements SSH sur 1 mois environ :
Parmi les solutions plus exotiques, une des plus fréquentes est « JSCH-0.1.51 » [JSCH] qui est une implémentation en Java de SSH. La répartition géographique de l'utilisation de JSCH pour des bruteforce SSH est bien différente et concerne essentiellement les États-Unis, le Mexique et la France, comme le montre l'image suivante :
La majeure partie des attaques semble être isolée, une même adresse, scannant et se connectant pour effectuer le bruteforce. Cependant, certaines solutions exotiques utilisent des méthodes plus avancées. C'est par exemple le cas d'une attaque réalisée avec un client nommé « Ruby/Net::SSH_2.9.1 x86_64-linux ». En moins de 20 secondes, 20 essais ont été réalisés depuis 5 pays différents. L'image suivante montre la répartition :
Réaliser une telle séquence suppose vraisemblablement un serveur central distribuant des tâches à des esclaves. La répartition géographique exotique de ces derniers fait penser à l'utilisation d'un botnet. Cette dernière attaque montre bien que les tentatives de bruteforce SSH reposent sur des solutions variées allant des scripts artisanaux à des solutions technologiquement complexes.
4. Une attaque spécifique
4.1 Pour les fenêtres, c'est la taille qui compte
Les données collectées par ulogd contiennent l'intégralité des entêtes des paquets et sont une source d'informations potentielles sur les technologies utilisées par les attaquants. Il existe en effet de nombreuses techniques pour déterminer le système d'exploitation d'une machine en analysant certaines des caractéristiques des paquets qu'elle a émis.
Si la plupart des techniques nécessitent des opérations mathématiques non accessibles dans Kibana, il est une donnée accessible directement qui en dit déjà beaucoup sur une machine. Il s'agit de la taille de fenêtre TCP à l'ouverture des sessions. La taille de fenêtre est un champ du paquet TCP définissant la quantité de données pouvant être envoyées sans acquittement. L'évolution de la taille de fenêtre au cours de la vie d'une connexion est définie de manière précise dans la RFC 1323 et c'est d'ailleurs un des paramètres utilisés par les pare-feux pour détecter des tentatives d'injection de données. Cependant, la RFC ne définit pas la taille de fenêtre au démarrage de la session et les systèmes d'exploitation ont donc dû choisir « arbitrairement » les valeurs.
La liste suivante montre les valeurs pour différents systèmes :
- 8192: Windows 7 SP1 ;
- 65535: Mac OS X 10.2 – 10.7, Windows XP, Windows 2003, FreeBSD ;
- 14600: Linux ;
- 5840: D'autres Linux.
La valeur de ce champ à l'initialisation de la connexion est donc un indicateur du système d'exploitation et s’agissant d’un des champs collectés par ulogd, il est intéressant de le tracer dans Kibana. Pour cela, il suffit de visualiser les valeurs de la fenêtre TCP pour l'ensemble des paquets ayant le flag SYN présent.
En demandant un « term » sur la valeur de fenêtre, on obtient le résultat suivant pour une période de 24h sur le système de collecte :
On identifie donc les valeurs dans notre précédent tableau pour les deux plus fréquentes fenêtres TCP contrairement à la troisième qui ne s’y trouve pas. Une étude des références sur les valeurs classiquement rencontrées confirme que cette valeur n'est utilisée par aucun système d'exploitation référencé et qu’elle mérite d’être approfondie.
Les barres du graphe dans l'interface de Kibana sont cliquables et le résultat est l'ajout d'un filtre sur la valeur. La mise à jour se fait sur l'intégralité des éléments de la page et la mise en place de ce filtre explicite des informations significatives sur la carte géographique des sources :
Cette taille de fenêtre est uniquement présente en Chine et une étude sur une plage de temps plus longue montre que cette répartition géographique est confirmée. On trouve toutefois trace de cette taille de fenêtre TCP dans quelque pays d'Amérique, mais si l'on limite l'étude au port 22 on exclut alors ces populations qui sont en fait à la recherche de relais mails ou proxy ouverts.
4.2 Analyse en profondeur
Le tableau de présentation des événements individuels est le suivant :
On remarque immédiatement que les ports sources sont tous égaux à 6000. La probabilité d'un tel événement est quasiment nulle, car si les connexions étaient ouvertes par les systèmes d'exploitation des hôtes concernés, les ports sources seraient alors choisis de manière « aléatoire ». Ce choix du port source combiné à la valeur non référencée de la taille de fenêtre indique qu'il s'agit de paquets générés par une socket raw. Une analyse d'un échange montre que l'attaquant envoie deux paquets par séquence, un SYN suivi d'un RST en réponse au SYN ACK. C'est donc un scanner de port utilisant une socket raw et utilisant un modèle de paquet peu conventionnel en ce qui concerne la taille de la fenêtre TCP
En se focalisant sur une IP donnée, on obtient le profil de l'attaque. Le tableau suivant présente les données reçues dans l'ordre chronologique :
On constate donc un scan (port 6000) suivi d'une série de tentatives de connexions SSH. Comme l'indique le port source aléatoire et la taille de fenêtre, il s'agit là de connexions ouvertes par le système d'exploitation et utilisées pour l'attaque bruteforce à proprement dit.
Si l'on regarde au niveau des événements SSH analysés par Suricata on s'aperçoit que le client SSH utilisé est libssh2_1.4.2 pour toutes les adresses IP utilisant la taille de fenêtre 16384.
Au niveau des alertes générées, les machines sont souvent déjà connues et elles apparaissent dans les règles identifiant les machines compromises ou offensives :
Les machines des réseaux 61.174.15.0/24 et 116.10.191.0/24 précédemment mentionnés utilisent toutes cette technique. Cette homogénéité tend à confirmer le côté industriel [1] des attaques effectuées à partir de ces deux réseaux.
L'ensemble de ces traces réseaux a donc permis de caractériser une plate-forme d'attaque par bruteforce qui n'est déployée qu'en Chine.
5. Un honeypot pour collecter les mots de passe
Les données collectées sont très intéressantes, mais il manque l'un des éléments les plus significatifs d'un bruteforce à savoir les couples utilisateur/mot de passe utilisés.
Il existe des solutions complètes comme Kippo [KIPPO] pour simuler une session SSH et ainsi récupérer les commandes lancées par le client, mais comme cela semble beaucoup pour faire une simple récupération des informations d’authentification,le logiciel pshitt [PSHITT] [2] a été développé dans le cadre de cette étude.
Il s'agit d'un serveur SSH basé sur paramiko [PARAMIKO] qui journalise les mots de passe dans un fichier au format JSON et refuse les connexions dans tous les cas.
Pshitt prend la place du serveur SSH et il est donc souhaitable de ne rediriger que le trafic des adresses utilisant des clients SSH non classiques (non OpenSSH dans le cas de l'étude) pour ne pas perdre la possibilité d'accéder en SSH au système. Pour détecter les IP avec des clients suspects, il suffit d'étudier les informations extraites par Suricata. On peut alors utiliser cette information pour mettre les adresses dans une liste exploitée avec Netfilter pour rediriger les tentatives de connexions vers pshitt.
Cette tâche est réalisée par l’outil « Deny On Monitoring » [3] [DOM] développé aussi dans le cadre de cette étude.DOM s'appuie sur ipset [IPSET] qui est un système de gestion d'ensembles développé pour Netfilter. Ipset utilise des structures adaptées afin d'offrir des temps de recherche très courts et de permettre la mise à jour rapide de ses listes. Dans notre cas, nous avons uniquement besoin d'une table d'adresses IP. Et nous allons rediriger l'ensemble des adresses de la liste vers le port 2200 :
# création de l'ensemble
ipset create sofitel hash:ip
# redirige les IP de l'ensemble vers le port 2200 où écoute pshitt
iptables -A PREROUTING -t nat -m set --match-set sofitel src \
-i eth0 -p tcp -m tcp --dport 22 -j REDIRECT --to-ports 2200
Il suffit alors d’exécuter DOM en le configurant afin de rajouter à la liste les adresses n'utilisant pas (-i) un agent OpenSSH. :
./dom -f /usr/local/var/log/suricata/eve.json -i -m OpenSSH -s sofitel
Le code de DOM est un exemple d'utilisation des journaux JSON de Suricata. Sa simplicité montre à quel point il est facile de développer ses propres tâches utilisant les informations extraites par Suricata.
5.1 Résultats
Les comptes massivement attaqués sont root et admin et on trouve au niveau des mots de passe les combinaisons bien connues, comme l’illustre le tableau suivant qui reprend les données sur sept jours :
La récupération des mots de passe a aussi conduit à observer quelques attaques surprenantes comme par exemple ce bruteforce violent basé sur libssh :
Il semble que l'attaquant a inversé le champ mot de passe et utilisateur dans son dictionnaire. Le cas présenté provient d'une adresse chinoise, mais une attaque similaire venant de Grèce a aussi été observée.
Conclusion
La mise en place d'une infrastructure de monitoring basée sur Suricata et Ulogd, couplée à un pot de miel dédié a permis de mieux classifier les différentes attaques par bruteforce SSH. L'analyse menée facilement grâce à Elastisearch montre que la variété des attaques est considérable. Les moyens vont du script artisanal déployé sur une unique machine à l’utilisation d’une ferme de serveurs provisionnés automatiquement. Une fois le bruit constitué par les nombreux bruteforce, majoritairement chinois, analysé et nettoyé, les attaques technologiquement plus intéressantes comme ces rares cas distribués géographiquement apparaissent et pourraient être approfondis.
Notes
[1] Le lecteur peu soucieux du politiquement correct peut s'autoriser à lire étatique plutôt qu’industriel.
[2] Nommé d'après une citation de Jacques Chirac : [les attaques] c'est qu'elles font « pschitt ».
[3] DOM, grand bloqueur de scans, a été nommé officieusement ainsi en référence à un homme politique français : « Dom, y nique trop de scans ».
Références
[FAIL2BAN] http://www.fail2ban.org/
[SURICATA] Suricata : http://suricata-ids.org/
[SPLUNK]Site de la société Splunk : http://www.splunk.com/
[ELK] http://www.elasticsearch.org/
[Ulogd] http://www.netfilter.org/projects/ulogd
[LIBSSH] http://www.libssh.org/
[LIBSSH2] http://www.libssh2.org/
[JSCH] http://www.jcraft.com/jsch/
[KIPPO] https://github.com/desaster/kippo
[PSHITT] https://github.com/regit/pshitt
[PARAMIKO] https://github.com/paramiko/paramiko
[DOM] https://github.com/regit/DOM