Une étude des bruteforce SSH

Magazine
Marque
MISC
Numéro
76
Mois de parution
novembre 2014
Spécialité(s)


Résumé

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.


Body

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.

 

kibana-dashboard

 

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.

 

classement-pays

 

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 :

 

ssh-client-repartition

 

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 :

 

jsch-attack

 

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 :

 

ruby-attack

 

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 :

 

tcp-window

 

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 :

 

geoip-china

 

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 :

 

attempt-list

 

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 :

 

complete-seq

 

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 :

 

complete-seq

 

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 :

 

pass-user

 

La récupération des mots de passe a aussi conduit à observer quelques attaques surprenantes comme par exemple ce bruteforce violent basé sur libssh :

 

user-pass-invert

 

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

 



Article rédigé par

Par le(s) même(s) auteur(s)

Nftables, une révolution dans le pare-feu Linux

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
76
Mois de parution
janvier 2015
Spécialité(s)
Résumé

Après 10 ans d'une domination implacable sur le monde des pare-feu open source, iptables est sur le point d'être remplacé par nftables. Les développeurs de Netfilter ont choisi de revoir leur copie et proposent un nouveau système de filtrage en rupture avec l'existant. Quelles sont leurs motivations et qu'apporte nftables par rapport à son vénérable ancêtre ?

Les derniers articles Premiums

Les derniers articles Premium

Quarkus : applications Java pour conteneurs

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Initié par Red Hat, il y a quelques années le projet Quarkus a pris son envol et en est désormais à sa troisième version majeure. Il propose un cadre d’exécution pour une application de Java radicalement différente, où son exécution ultra optimisée en fait un parfait candidat pour le déploiement sur des conteneurs tels que ceux de Docker ou Podman. Quarkus va même encore plus loin, en permettant de transformer l’application Java en un exécutable natif ! Voici une rapide introduction, par la pratique, à cet incroyable framework, qui nous offrira l’opportunité d’illustrer également sa facilité de prise en main.

De la scytale au bit quantique : l’avenir de la cryptographie

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Imaginez un monde où nos données seraient aussi insaisissables que le célèbre chat de Schrödinger : à la fois sécurisées et non sécurisées jusqu'à ce qu'un cryptographe quantique décide d’y jeter un œil. Cet article nous emmène dans les méandres de la cryptographie quantique, où la physique quantique n'est pas seulement une affaire de laboratoires, mais la clé d'un futur numérique très sécurisé. Entre principes quantiques mystérieux, défis techniques, et applications pratiques, nous allons découvrir comment cette technologie s'apprête à encoder nos données dans une dimension où même les meilleurs cryptographes n’y pourraient rien faire.

Les nouvelles menaces liées à l’intelligence artificielle

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Sommes-nous proches de la singularité technologique ? Peu probable. Même si l’intelligence artificielle a fait un bond ces dernières années (elle est étudiée depuis des dizaines d’années), nous sommes loin d’en perdre le contrôle. Et pourtant, une partie de l’utilisation de l’intelligence artificielle échappe aux analystes. Eh oui ! Comme tout système, elle est utilisée par des acteurs malveillants essayant d’en tirer profit pécuniairement. Cet article met en exergue quelques-unes des applications de l’intelligence artificielle par des acteurs malveillants et décrit succinctement comment parer à leurs attaques.

Les listes de lecture

11 article(s) - ajoutée le 01/07/2020
Clé de voûte d'une infrastructure Windows, Active Directory est l'une des cibles les plus appréciées des attaquants. Les articles regroupés dans cette liste vous permettront de découvrir l'état de la menace, les attaques et, bien sûr, les contre-mesures.
8 article(s) - ajoutée le 13/10/2020
Découvrez les méthodologies d'analyse de la sécurité des terminaux mobiles au travers d'exemples concrets sur Android et iOS.
10 article(s) - ajoutée le 13/10/2020
Vous retrouverez ici un ensemble d'articles sur les usages contemporains de la cryptographie (whitebox, courbes elliptiques, embarqué, post-quantique), qu'il s'agisse de rechercher des vulnérabilités ou simplement comprendre les fondamentaux du domaine.
Voir les 66 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous