TRANSITION NUMÉRIQUE - INNOVATION - COMPÉTITIVITÉ

Le bruit de fond de l’internet, ou comment les pirates détectent nos systèmes d’information.

[Un article de notre RSSI, Bertrand Maujean.] 

Le vintage est à la mode, la cassette audio sort de ses tiroirs !

Pourquoi commencer cet article en parlant de la cassette audio ? Pour évoquer la notion de bruit de fond, cette composante non désirée dans la musique que vous écoutez, composante qui n’a pas été souhaitée par les musiciens dans leur enregistrement.

Internet ressemble à nos cassettes audio. Un bruit de fond incessant caractérise cet Internet que nous utilisons tous. Et ce bruit de fond n’est vraiment pas souhaitable, nous allons voir pourquoi.

Dans cet article, nous allons vous parler de statistiques sur ce bruit de fond incessant sur internet. Un bruit qui correspond à la recherche automatique des services disponibles, adresse IP par adresse IP. Les résultats présentés correspondent à des mesures réelles, effectuées cet été, sur le réseau d’Adista.

Par ces exemples de services internet et de statistiques, nous allons vous faire partager les motivations des pirates, pour vous donner quelques idées sur leurs modes d’actions.

Que fait un pirate qui lance une attaque ? Dans la méthodologie du hacker, la première étape est une « reconnaissance » qui consiste à récupérer le maximum d’information sur sa cible. Cette phase n’est pas forcément que technique, et peut inclure du « Social Engineering ». Juste après, vient une étape de « scanning », qui se passe là sur internet, avec des outils spécialisés, et qui consiste à inventorier les services exposés à internet par la cible.

Si un pirate ne souhaite pas cibler une entreprise en particulier, mais uniquement pénétrer des systèmes « à la chaine » pour en revendre les accès au marché noir, ou pour demander des rançons, alors la technique internet lui apporte une facilité décisive : les « adresses IP » qui composent notre internet ne sont que 4 milliards environ en tout, il est donc envisageable de les tester toutes. C’est ce constat qui est à l’origine d’un véritable « bruit de fond » permanent sur internet, dont nous allons discuter maintenant.

Concrétement, comment se matérialise ce bruit de fond dans nos systèmes ?

Sur des systèmes d’information bien configurés, ce bruit de fond doit générer des traces, des « logs ». Nous allons montrer quelques exemples simples.

L’exemple ci-dessous est issu d’un serveur web. Un attaquant essaie de se connecter à une URL « /wp-admin », qui donne accès au système d’administration d’un serveur web construit avec le logiciel « WordPress ». Mais ce site web est ici construit avec un autre logiciel, cette requête ne peut pas être légitime…

[Wed May 02 13:15:02.464747 2017] [:error] [pid 17426] [client 198.999.999.999] 
ModSecurity: Multipart parsing error (init): Multipart: Invalid boundary in C-T (characters). 
[hostname "usanzzz.ffspeleo.frzzz"] [uri "/wp-admin/admin-ajax.php"] [unique_id "WRMR3sHIKw4AAEQSMHwAAAAQ"]

 

Ci-dessous, nous avons un exemple de scan spécialisé sur un produit populaire dans l’ «internet des objets», la domotique, et chez les «geeks». L’attaquant essaie de se connecter au compte par défaut d’un mini-ordinateur de type Raspberry Pi. Il n’y parviendra pas, car ce système n’est pas un Raspberry Pi, et le compte n’existe pas…

Aug 12 06:54:21 usan sshd[28768]: Invalid user pi from 82.999.999.999
Aug 12 06:54:24 usan sshd[28768]: Failed password for invalid user pi from 82.999.999.999 port 44454 ssh2

 

Voyant ceci, il est facile de comprendre pourquoi il faut changer le mot de passe par défaut avant de brancher la prise RJ45…

 

Dans ces deux exemples, les adresses IP utilisées par les pirates sont visibles[1]. La plupart du temps, ces adresses ne sont pas directement celles des pirates, qui rebondissent de système compromis en système compromis pour brouiller les pistes.

Un dernier exemple, qui donne une idée du volume. Combien de temps faut-il pour recevoir une centaine de paquets de ce type de trafic ?

# tcpdump -n -c 100 ip
09:04:06.319087 IP 104.197.49.117.41005 > 128.127.139.165.23: Flags [S], seq 2155842469, win 26580, length 0
[…]
09:04:06.517672 IP 66.240.205.34.24858 > 62.102.255.184.53: Flags [S], seq 1109093670, win 52952, options [mss 1460], length 0

09:04:06.517816 IP 92.154.95.236.57334 > 37.18.173.31.5800: Flags [S], seq 2518544397, win 1024, length 0

09:04:06.529652 IP 45.84.196.11.32106 > 62.102.242.47.23: Flags [S], seq 1046934063, win 22858, length 0

09:04:06.531657 IP 51.158.99.204.53092 > 62.102.252.235.23: Flags [S], seq 1046936811, win 60228, length 0

09:04:06.538656 IP 51.178.78.153.58826 > 62.102.241.102.587: Flags [S], seq 635151151, win 65535, length 0

09:04:06.551413 IP 45.148.10.115.33167 > 185.204.143.109.8002: Flags [S], seq 1865740102, win 65535, length 0

09:04:06.554454 IP 51.91.247.125.40109 > 37.58.221.222.8081: Flags [S], seq 3623946567, win 65535, length 0

09:04:06.556665 IP 185.132.53.24.48800 > 62.102.242.153.8080: Flags [S], seq 1046934169, win 22872, length 0

100 packets captured

 

Un peu plus de 2 dixièmes de secondes… Il faut dire que pour cet exemple, nous captons les paquets envoyés à environ la moitié des adresses IP non encore utilisées du backbone d’ADISTA[2], soit une surface de collecte beaucoup plus importante que la plupart des entreprises et organisations potentiellement ciblées.

En effet, ce bruit de fond envoyé aveuglément à tout internet est d’autant plus mesurable que l’on dispose d’une surface de collecte importante, c’est-à-dire qu’on l’observe sur un grand nombre de postes et serveurs, ou en tout cas, à destination d’un grand nombre d’adresses IP publiques distinctes. Comme la plupart des réseaux d’entreprises ne sont pas directement visibles sur internet[3], la grande taille d’une organisation ne suffit pas pour observer ce bruit de fond. En fait, les opérateurs internet, ceux qui possèdent un réseau, un « backbone » dans lequel un grand nombre d’adresses publiques sont utilisées, sont les mieux placés pour observer ce bruit de fond à l’échelle de l’internet.

Nous voyons aussi dans cet exemple un petit avant-goût des services internet ciblés, dont nous allons discuter maintenant.

 

Que recherchent les pirates ?

Pour le savoir, intéressons-nous à ces « services », au sens internet, qui sont l’objet de ces scans.

Répartition des services scannés par le bruit de fond internet (cliquez sur l’image pour en voir le détail)Avant tout, c’est le fort bruit de fond sur le service « telnet » qui domine. En fait, dans ce cas, le pirate en chair est en os n’est pas directement au bout du fil car il s’agit essentiellement des scans générés par des « Botnets » constitués de « vers », comme par exemple le Mirai qui avait été bien médiatisé à sa sortie. Chaque objet connecté compromis, comme une caméra IP, essaie de scanner les adresses voisines pour dupliquer le malware qu’il porte[4].

Quand les pirates s’intéressent à nos bases de données, ce sont les services MSSQL, MYSQL, POSTGRESQL dont il s’agit. Mais aussi LDAP, et tout simplement FTP. Pour les entreprises qui miseraient sur les outils libres du monde pour leur « Big Data », attention : la console Elastic Search est également couramment ciblée[5].

On a bien sûr tout une catégorie de pirates spécialisés dans la compromission des sites web, des « Content Management System » comme Drupal, WordPress, Joomla. Ces « CMS » sont couramment porteurs de faiblesses permettant de prendre le contrôle du système qui les héberge. Eux vont scanner les services HTTP et HTTPS. Le contrôle du site web ne sera pas forcément exploité immédiatement, ni même par celui qui a réussi l’intrusion. Il pourra être mis sur le marché noir, et racheté par exemple par des activistes pour une action de défiguration.

La téléphonie est bien sûr bien représentée. Qui n’a pas entendu parler d’une affaire d’ «IPBX» corrompu, avec une facture téléphonique astronomique à la clé ? C’est ce qui peut arriver quand on expose son service « SIP », la console d’administration, qu’on utilise des mots de passe par défaut ou faibles.

Parmi les services d’administration distante du SI, on retrouve bien sûr SSH et RDP, mais aussi VNC, GoToMyPC. Ces services ne devraient jamais être publiés directement. C’est un fait certain, la surexposition des services RDP intervient dans une grande proportion des attaques réussies sur des entreprises françaises. Et les outils de prises de main à distance sont chacun une épine dans le pied de votre RSSI…

Les « proxys ouverts » sont des systèmes qui, sans le vouloir, permettent à un malveillant de relayer des connexions. Là, les pirates cherchent à dissimuler leurs traces, voir à contourner une limitation de visibilité d’un service en rebondissant via un système voisin et plus proche de leur cible. Ce relayage peut être limité au mail via le service SMTP, que nous avons compté dans la même catégorie, ou au contraire permettre au pirate de relayer absolument n’importe quelle connexion. C’est un peu comme un service de VPN, mais aux dépends du propriétaire légitime du système concerné.

Les services amplificateurs d’attaque DDOS sont toujours recherchés, même s’il semblerait que les « attaques de déni de service distribuées » (DDOS) soient désormais un peu plus « intelligentes » que de la saturation aveugle du réseau.

Ce que cherche ici le pirate, c’est un service qui permet, ayant envoyé un paquet de 100 octets par exemple, d’obtenir une réponse de 1500 octets. Utilisé en conjonction avec l’usurpation de l’adresse IP source, une bonne liste de tels réflecteurs est l’ingrédient de base d’une attaque DDOS bien volumétrique.

Dans la catégorie « Autres », on va retrouver des scans plus spécialisés : service « smart install » de Cisco, console d’administration VMWare, IPSEC/IKE… Mais encore une fois, que des choses qui devraient toujours rester cachées à l’intérieur.

Les pirates recherchent aussi bien sûr le graal de la vulnérabilité 0-day : la vulnérabilité «wormable», celle qui permet de prendre le contrôle d’un ordinateur à distance sans aucune interaction avec l’utilisateur ou les administrateurs légitimes. De telles vulnérabilités existent (ou ont existé, ça, dépend de votre politique de gestion des patchs !), dans les services Remote Desktop Protocol de Microsoft (Bureau à distance), le partage de fichier de Windows, et en ce moment, dans le service de Domain Name System des même Windows. Ces vulnérabilités sont assez rares, mais permettent des attaques puissantes. Dans cette perspective, les pirates constituent à l’avance des catalogues de machines visibles, en inventoriant autant que possible les noms de logiciels, les versions. Lorsqu’une qu’une vulnérabilité est annoncée, elle peut ainsi être exploitée dans la foulée.

Le résultat, c’est un bruit de fond incessant, qui ressemble à ceci (pour quelques services « populaires » seulement) :

Bruit

(cliquez sur l’image pour en voir le détail)

(Échelle : nombre de paquets interceptés par quart d’heure, toujours sur une partie des adresses IP non encore utilisées chez ADISTA)

 

D’où viennent les scans ?

Une petite statistique géographique permet de donner une première idée de réponse :

Cliquez sur l’image pour en voir le détail

Cependant, il faut prendre cette statistique avec prudence. Ce graphique est basé sur le nombre d’alertes[6] (selon une certaine appréciation), par semaine. C’est un critère pertinent pour le défenseur. Mais pour apprécier le caractère malveillant de telle ou telle région du monde, il serait utile de normaliser ces chiffres en tenant compte du taux de pénétration d’internet dans la population, du nombre d’adresses IP publiquement visible par pays, de la diffusion des pratiques de sécurité dans la population. Le taux de pénétration des malwares sur les ordinateurs résidentiels n’est pas forcément le même d’un pays à l’autre.

On peut parfois repérer des blocs d’adresses IP contigües parmi les sources de ces scans. Dans ce cas, il est assez clair que l’organisation qui est responsable du bloc d’adresses IP a une responsabilité dans l’utilisation du bloc à des fins de scan. Mais souvent, les sources de scan sont des adresses disparates, sur de grands réseaux de fournisseurs d’accès : les ordinateurs, tablettes, objets connectés grand publics, les vôtres et les nôtres. Ces appareils ont été compromis d’une manière ou d’une autre, et un pirate peut les utiliser (en plus de voler, ou chiffrer contre rançon, les données qui s’y trouvent).

 

Les organisations qui scannent l’internet pour le bien public

Et oui, ça existe. Des chevaliers blancs qui scannent l’internet, pour notre bien, et publient parfois ouvertement les informations trouvées sur nos faiblesses. Comme leur méthodologie est similaire, ces organisations participent à ce bruit de fond, et sont donc repérables. Ainsi, dans nos statistiques, nous découvrons que Shodan nomme ses serveurs avec des noms amusants comme « refrigerator.census.shodan.io », que Censys utilise effectivement les adresses IP qu’il annonce pour ses actions de scan. On découvre également des blocs d’adresses dont les noms sont évocateurs de centres de recherche, qui procèdent certainement à des statistiques des services ouverts.

 

Comment protéger mon organisation de ce genre de scans ?

Mais voulons-nous nous en protéger ? Soyons cohérents : si on publie sur l’internet public un service, c’est pour que le monde le voit non ?

En fait, ce n’est pas de ces scans dont il faut se protéger, mais bien des attaques dont ils font partie. Et pour cela, une petite réflexion au bon moment apporte déjà une bonne protection[7] :

  • Est-il nécessaire de publier mon service de bureau à distance à toute la planète alors que mes salariés n’habitent qu’en France ?
  • Ai-je bien pensé à changer le mot de passe par défaut de la webcam que je viens d’acheter ?
  • Ce prestataire qui m’a demandé d’ouvrir ma base de données sur internet pour pouvoir en faire la maintenance à distance : est-ce bien prudent ?
  • Comment se fait la télémaintenance de notre dernier copieur connecté avec scanner et OCR ?

Le principe est que le pirate ne doit trouver que les services que vous avez explicitement consenti à lui laisser voir. Aucun service ne doit être exposé à internet sans que cela soit nécessaire, apprécié, et donc voulu.

Un service SSH c’est robuste, je peux l’exposer sans risque : non. Il est robuste aujourd’hui, mais demain, si une vulnérabilité 0-day est divulguée ? La maîtrise de la surface exposée s’inscrit dans la démarche de défense en profondeur.

Les tentatives d’« exploitation » des services découverts donnent lieu à des logs, tels que nous en avons vus au début de cet article. Ceci implique que ces tentatives peuvent être surveillées. C’est également un axe de défense : surveiller ses logs, en déduire des alertes, puis agir. Comme par exemple en bloquant une adresse IP, en bloquant un compte… Le déploiement d’un outil de « Security Information and Events Managment » (SIEM) est un projet lourd, coûteux, long, qu’une petite organisation peut rarement se permettre. Mais des mécanismes d’atténuation simples et légers peuvent être mise en place, comme le blocage automatique d’un compte ou d’une adresse IP source après un certain nombre de tentatives ratées.

Sans que cela ne remplace jamais la surveillance de ses logs, il est aussi possible de procéder à un « test de pénétration » ou « pentest », qui consiste à prendre le rôle de l’attaquant pour découvrir quel chemin d’attaque serait possible. Même un pentest « superficiel », qui dévoilerait des interfaces d’administration visibles et pourtant inconnues, est très bénéfique. Comme toujours, pour faire les 80 premiers pourcents du travail, vous n’aurez que 20 pourcents du budget à dépenser.

Oui, ce sont bien les mesures de défenses habituelles, dans leur ensemble, qui vont nous prémunir des attaques, à défaut de pouvoir se prémunir vraiment des scans. N’oublions pas non plus la gestion des patchs (pour atténuer les vulnérabilités « 0-day »), la gestion des mots de passe (pour éviter qu’un compte ne tombe sous une attaque de « force brute »).

 

 

Nous avons évoqué au cours cet article un grand nombre de scénarios d’attaque, de mesures de sécurité, de faiblesses, représentant un échantillon assez large des incidents qui peuvent impacter les systèmes d’information. Ceci confirme bien l’importance du « scanning », de la phase de découverte du système d’information attaqué. On est bien sur une activité de base de l’adversaire.

Dans ce cas précis, la découverte des services par une énumération exhaustive de toutes les adresses IP existantes est possible. Demain, avec l’avènement d’IPv6, ce ne sera plus possible, car les adresses IPv6 sont tellement nombreuses qu’il n’est pas possible de les énumérer. Mais il ne faut pas compter là-dessus pour dissimuler nos réseaux. D’autres ressources internet ont déjà la propriété d’être impossibles à énumérer : les noms de domaine et les adresses e-mails. Et pour autant, nos adresses e-mails sont bien empoisonnées tous les jours par le spam, et les sites web utilisant des noms de domaine finissent toujours par se retrouver indexés par Google.

Mais comme nous l’avons vu, la défense est loin d’être démunie : il n’appartient qu’aux décideurs de doser leur effort contre la menace cyber !

 

 

[1] Les adresses IP ont cependant été modifiées, pour préserver l’anonymat des pirates…
[2] Une adresse inutilisée n’est pas censée recevoir du trafic bien sûr. Et que faire de nos adresses IP en attendant de les mettre à disposition d’un client ? S’en servir pour capter ce bruit de fond !
[3] Car utilisant la technique de « translation d’adresse » derrière un « pare-feu »
[4] Nous ne le répèterons jamais assez : les mots de passe constructeurs par défaut sont une calamité !
[5] La suite ELK, dans son installation de base, ne gère par toujours l’authentification. Comme il s’agit d’un outil qui sert justement à indexer les données, il faut vraiment faire attention.
[6] Log10 du nombre d’alertes, sur une semaine, tel que détecté par l’outil Snort, et pour environ la moitié des adresses IP non routées cet été dans le backbone d’ADISTA.
[7] C’est le « security by design » : il est facile de sécuriser son système si on intègre le besoin de sécurité au bon moment.