| CERT

INTRODUCTION

Comprendre la manière dont les attaquants travaillent est une réelle plus value si l’on veut mettre en place des mécanismes de défenses pertinents. Aujourd’hui, il est simple d’avoir accès à de nombreux feeds de données et d’IOCs permettant d’alimenter des outils de sécurité.

Le problème est qu’il est souvent difficile d’avoir un vrai contexte à partir de feeds d’IOCs. Des listes de hashs ou d’IPs ne suffisent souvent pas pour bien appréhender certains types d’attaques et il devient alors possible pour certains attaquants de contourner les solutions de sécurité.

Une des solution les plus simples permettant de monitorer le comportement des attaquants en terme d’approche et de rapidité de mise en oeuvre sont : les Honeypots.

A travers une suite de blog posts, nous allons vous décrire les méthodes du CERT OPMD pour avoir une vue sur le niveau de la menace et le comportement des attaquants.

LES HONEYPOTS

Le principe est simple, il suffit d’exposer des services vulnérables sur Internet et d’étudier le comportement des attaquants vis à vis de ces services. L’objectif est de permettre au CERT d’observer les comportements et méthodologies des attaquants :

  • Quels type d’exploits utilisent-ils?
  • Que cherchent-ils à faire ?
  • Comment travaillent-ils?

 

Mais les honeypots ont leurs avantages et leurs inconvénients.

  • L’avantage majeur des honeypots est qu’ils permettent d’étudier facilement le “bruit” ambiant.

– Grâce aux honeypots nous allons surtout capturer des attaques lancées par des outils automatiques qui scannent Internet en permanence.

– On peut facilement cartographier les services les plus attaqués, les méthodes utilisées, etc et ainsi catégoriser le “bruit” ambiant des attaques les plus lancées.

  • L’inconvénient majeur est qu’on ne capture majoritairement que la masse des attaques (les scanners…) et très peu d’attaques avancées.

– Les Honeypots permettent au moins d’éliminer les attaques de masses pour faciliter le déploiement d’outils plus élaborés pour attraper des attaques plus avancées.

DÉLIMITATION DU PÉRIMÈTRE

Pour produire des données bien contextualisées et pertinentes, une des premières étapes clé est de délimiter son périmètre.
En effet, il n’est pas aisé de monitorer tout Internet, car chaque pays n’est pas ciblé de la même manière, ni avec la même intensité, ni par les mêmes types de personnes.
Par exemple, les pays n’utilisant pas la carte à puce des cartes de paiement sont beaucoup plus ciblés par l’installation de malware ciblant les terminaux “point de vente » .
L’activité du CERT-OPMD sur cette approche étant relativement récente et servant principalement une clientèle composée d’entreprises françaises, nous n’allons utiliser dans un premier temps que des serveurs en France.

ÉTAPE 1 - L'ÉTAT DES LIEUX

Avant de se lancer dans la création de honeypots, il est déjà important de :

  • Comprendre l’état de la menace actuelle.
  • Chercher quels services sont le plus attaqués
  • Identifier le “Comment”

Répondre à ces questions permet ensuite d’adapter ses honeypots et d’avoir très vite des résultats.

Nous allons ainsi commencer par une phase de reconnaissance. Pour cela, il nous faut des serveurs situés dans notre périmètre (ici la France). Nous avons le choix entre des IP de type Hébergeurs (OVH, 1&1, Gandi etc) ou des IP de type FAI.

-> Notre objectif étant de monitorer la menace des services exposés sur Internet, nous choisirons une IP chez un hébergeur.
Ensuite nous lançons une capture réseau :
– Nous utilisons Tcpdump pour la capture
– Le trafic est capturé sur tous les ports TCP/UDP
– Le réseau est capturé pendant 4 jours

Cela permet de pouvoir étudier quels sont les services les plus attaqués et ainsi de prévoir le déploiement de services vulnérables.

Nombre de paquets par secondes tous protocoles confondus

ÉTAPE 2 - UN PCAP DE 4 JOURS: OVERVIEW

Commençons par quelques chiffres autour du pcap généré pour 4 jours d’écoute du réseau.

Particularités du PCAP :
– Premier paquet: 2017-06-07 18:46:32
– Dernier paquet: 2017-06-12 09:34:46
– 1 212 759 paquets capturés
– Moyenne de 3 pps
– Le fichier pcap généré pèse 255Mo
– 6172 IPs uniques nous ont scannées

Ces 4 jours de monitoring nous apprennent un premier fait intéressant : sur les 6172 IPs récoltées, les serveurs 61.177.172.10 61.177.172.52 et 61.177.172.53 ont été responsables à elles seules de 50% de la totalité du trafic.
Ces trois serveurs, situés en Chine, ont été utilisés pour faire du Brute-force SSH.
Pour la suite de l’étude, nous avons choisi d’exclure ces 3 IPs. Ces serveurs représentants la moitié du trafic, elles ont le biais de déformer les statistiques faites sur le reste de la capture.

Une fois qu’on a filtré ces IP du PCAP initial, nous pouvons nous attaquer à l’analyse des paquets TCP de celui-ci.

TCP

Le trafic TCP représente 99% de la totalité du trafic.
Notre objectif est de déterminer les services que nous allons auditer via le honeypot afin de pouvoir monitorer ces attaques. Nous allons donc nous concentrer sur les ports ciblés dans le PCAP, que nous allons détailler ci-dessous.

(si nous n’avons pas vu votre service préféré sur ces 4 jours là, ne vous inquiétez pas, nous relançerons ces étapes plus tard et vous aurez peut-être la chance de le trouver).

Notre serveur a été scanné sur 700 ports différents (allant de 11 à 62 222), 174 ports ayant été scannés au moins trois fois.

Le top 10 des ports ciblés est assez attendu.

  • Le protocole SSH (port 22) domine le classement:
    – C’est un service énormément brute-forcé pour installer des DDoS bots, notamment par ceux qu’on pourrait appeler la team “China-Z” et les groupuscules autours des malwares GayFgt et Kaiten.
  • Le Telnet (port 23/2323) est aussi beaucoup brute-forcé,
    – en grande partie par les botnets Mirai
    – mais plus généralement par quiconque souhaitant attaquer des objets connectés.
  • Le SMB (port 445) arrive en troisième position:
    – Il est très ciblé en ce moment avec les dernières vulnérabilités Eternal Blue/Eternal Red et Wannacry.
    – De plus le 445 fait du bruit depuis longtemps à cause de worms comme Conficker qui exploitent la vulnérabilité MS06-068.
  • Les services de bases de données sont aussi ciblés par des attaques brute-forces:
    – MSSQL (1433)
    – MySQL (3306)
    – MongoDB (27017).
  • Le protocole RDP (port 3389).
    – Une fois brute-forcé, les serveurs RDP attaqués sont utilisés pour de nombreuses tâches: Minage bitcoin, Ransomware, Scans, …
    – Le protocole RDP est très utilisé par les sociétés de maintenance informatique pour dépanner des clients à distance. Ainsi, de nombreux Point of Sales et autres applications comme SCADA se retrouvent accessibles sur Internet et sont très ciblés.
  • Le HTTP (ports 80 et 81) est évidemment très attaqué.
    – Les serveurs web sont des vecteurs d’attaque puissants, très souvent mal configurés et utilisés par beaucoup d’applications web (du CMS à l’intranet en passant par des outils métier et autre PhpMyAdmin, CPanel et Tomcat).
    – C’est une grande surface d’attaque accessible par des attaquants pauvres techniquement (skids).

Nous ne nous occuperons pas de décortiquer les attaques ciblant les serveurs web, car cela prendrait un article à lui seul.

Le cas du port 9000
Le port 9000 se retrouve très haut dans la liste des port scannés (8ème position). Plusieurs personnes ont déjà remarqué ce comportement.
Notre objectif, nous le rappelons, est d’essayer de comprendre rapidement si cela a un intérêt de monitorer ce port avec un Honeypot qui émule un service.
En ouvrant une socket TCP sur le port 9000, (le three-way handshake est joué) nous serons capables de capturer la première requête envoyée sur le port 9000 par l’attaquant.
Nous avons utilisé le script python suivant :
https://pastebin.com/LEPEK4TS
Après quelques heures, les premières requêtes arrivent :

C’est un scan tentant de trouver un DVR vulnérable pour l’exploiter et probablement installer un malware.
Ce sujet étant déjà traité, nous passerons sur l’analyse de celui-ci pour le moment.

QUID DU RESTE DES PORTS

Il reste dans ce PCAP 690 ports que nous n’avons pas encore traités. Nous pouvons les diviser de la façon suivante :

  • Les services connus non-listés dans notre Top 10 comme:
    FTP (21)
    Port Management de box ADSL (7547)
    Proxy (3128,8080)
    VNC/rAdmin (5900,4899)
  • Des ports alternatifs aux services connus, avec majoritairement :
    RDP (33389 ou 33899 par exemple) ou d’autres ports random
    HTTP
  • Des ports scannés par des outils de scans automatiques :
    Des ports “prédictibles” (4444,5555 ou encore 6666…)
    Des ports RDP alternatifs, …
  • Des ports scannés pour des vulnérabilité spécifiques
    Redis (6379) pour une vulnérabilité de 2015
    Elasticsearch (9200) pour la CVE-2015-1427

Fun fact : Nous avons remarqué que Shodan scannait Internet à la recherche de C&C NJRAT.

On remarque en plus de cette analyse TCP qu’il existe plusieurs types de scans automatisés :

  • l’IP qui va chercher un service sur plusieurs ports
  • l’IP qui va chercher toutes sortes de services sur un même port

 

Cela est en effet très courant dans le cas du RDP et HTTP.
Retrouvez le TOP 50 des ports scannées ici : https://pastebin.com/xVn2cfvU.

Après cette brève analyse des ports TCP nous allons étudier les <1% paquets restants : UDP

UDP
De la même manière que pour le TCP, commençons par quelques chiffres clés sur ces 4 jours de capture de trafic UDP :

  • 381 IPs uniques nous ont scanné
  • 148 port différents allant de 7 à 64738

La majorité de ces ports sont utilisés par les attaquants pour lancer des attaques DDoS. C’est le cas des ports suivants :
1900 (UPnP SSDP).
53 (DNS)

– Nous avons reçu de nombreuses tentatives de résolutions DNS telles que:
1×1.cz

  • ppal-kundenservice.gdn
  • leth.cc
  • hoffmeister.be
  • activum.nu
  • c.afekv.com
  • cpsc.gov
  • lywy.995eaca3.wc.syssec.rub.de

– Les résolveurs DNS ouverts sont prisés par les personnes cherchant à faire du DDoS par amplification DNS

 

161 (SNMP)
19 (Chargen)

Le port 5060 est lui très attaqué pour d’autres raisons:
C’est le port SIP (lié à la VOIP).
Le protocole SIP est un vecteur d’attaque largement sous estimé, les attaquants exploitant la VOIP pour de nombreuses raisons :
– Voler de l’argent via des appels sur des numéros surtaxés
– Utiliser des standards VOIP pour faire du scam de masse
– Simplement prendre le contrôle du serveur VOIP pour installer des malwares

On notera que la majorité des requêtes sont faites par l’intermédiaire de l’outil SIPVicious ( il est facile de reconnaître SIPVicious via les traces qu’il laisse).

Le port 53413 est scanné à cause d’une backdoor sur les routeurs Netis.

Enfin le trafic des ports restant du top 10 est principalement composé de vieux worms tentant d’exploiter des vulnérabilités sur:
Les port 1434 (MSSQL)
137 (SMB)
111 (RPC/NFS)

Quid du reste des ports

La grande majorité des ports restants sont des ports alternatifs pour le protocole SIP.

On retrouve aussi certains services de routeurs vulnérables, comme le port 9999 exploité pour une vulnérabilité des routeurs ASUS

Les services LDAP ne sont pas épargnés.

On retrouve enfin de manière assez surprenante des probes pour des réseaux P2P DHT, et d’autres paquets liés à des services de jeux vidéo en ligne comme Garry’s mod…

QUEL PORT MONITORER?

Cette analyse fait ressortir 2 types d’attaques:

  • Des attaques automatisées (SSH, Telnet, Mysql, ELK…)
    -Le service est scanné et brute forcé
    -Un malware est installé automatiquement
  • Des attaques semi-automatisées:
    -Le service est scanné et brute-forcé
    -Un attaquant se connecte manuellement à la machine attaquée et interagit avec elle.

Les attaques automatisées de bout en bout sont déjà très bien surveillées par des honeypots tel que Cowrie ou ElasticHoney.
Commencer par monitorer ces services n’apporterait pas de plus value pour notre étude.
Nous allons donc nous concentrer sur un honeypot permettant de capturer des attaques lancées par des humains.

Le protocole RDP semble parfait pour cela.

  • Il arrive très haut dans le top 10 des ports TCP les plus attaqués
  • Il est utilisé pour faire de nombreuses choses différentes
  • L’addition de tous les différents ports scannés à la recherche de RDP ouvert nous offre un large champ d’exposition sur Internet.
  • Une fois le système mis en place pour monitorer du RDP, il est simple d’ajouter d’autres protocoles similaires, comme le VNC ou le SMB par exemple.
  • C’est un protocole techniquement intéressant à monitorer.

Le premier service que nous avons choisi de monitorer sera donc le RDP.

PREMIÈRES RECOMMANDATIONS

Comme nous le rappellent par la preuve ces quelques premiers chiffres, il est indispensable de prendre ses précautions quant à l’ouverture de ports sur Internet.
Les services SSH et Telnet sont particulièrement attaqués.

En 4 jours nous avons été scannés 29765 fois sur le port 22.
– Cela fait une moyenne de 5 scans par minutes
– Idem pour le Telnet

Il suffit d’ouvrir un SSH avec un compte de test et des credentials faibles pendant quelques minutes pour être infecté par un malware.

Dans un premier temps, changer le port par défaut du service SSH ou Telnet réduit drastiquement le nombre d’attaques.
Ensuite, la majorité des attaques sur SSH ne sont en fait que du brute force de mot de passe, donc en utilisant une authentification par certificats vous mettez en échec toute tentative de brute force de mot de passe.
Une autre solution consiste à utiliser des outils comme fail2ban permettant de bannir une IP après un certain nombre de tentatives de connections en échec.

On remarque également que les logiciels de prise en main à distance (VNC, RDP, rAdmin) sont aussi très attaqués. Certains outils permettent de mettre de la double authentification OTP sur VNC ou RDP : nous recommandons de n’ouvrir le port qu’en cas de besoin ou de mettre un mot de passe complexe.
Ci dessous pour illustration une liste de mot de passe utilisée par les brute-forcer VNC : https://pastebin.com/aKy2W0Gc

Pour tous les services de base de données, il en va de même:

  • Utilisez des mots de passes forts
  • N’exposez pas inutilement des SGBD sur Internet
  • Faites attention à la gestion de vos droits utilisateurs
  • Si un SGBD doit être exposé sur Internet, mettez en place un système de liste blanches d’IP autorisées à se connecter.

 

Ces quelques règles élémentaires sont souvent suffisantes pour éliminer a minima toutes les attaques lancées automatiquement. Depuis quelques années, il est devenu banal de faire du scan de masse sur Internet. À des fins “légitimes” mais aussi à des fins malveillantes. Il est important d’écouter le réseau régulièrement pour suivre les tendances et comprendre comment se protéger de ce genre d’évènements de sécurité.

LA SUITE

Nous arrivons à la fin de cette première partie. Nous avons essayé d’avoir une vue globale sur quels services monitorer en priorité et choisi le protocole RDP.
La prochaine partie de cette aventure détaillera l’architecture déployée pour monitorer le RDP et présentera nos premiers résultats.
Stay Tuned !

Arnaud Zobec & Benoît Ancel & Lamine Sow