Retour sur l'édition 2014 de la Hack.lu (Jour 2)

I hunt TR-069 admins – pwning ISPs like a boss, par Shahar Tal (@jifa)

SLIDES

Shahar Tal travaille en tant que chercheur au sein de la société CheckPoint. Il s’est intéressé au protocole TR-069 et plus particulièrement à son utilisation au sein des serveurs ACS (Auto Configuration Server).

Le protocole TR-069, aussi connu sous le nom de CWMP (CPE WAN Management Protocol) permet d’administrer des périphériques clients, tels que des routeurs situés au sein d’un LAN, depuis le WAN (Internet). Il est utilisé par de nombreuses sociétés telles que Bell, AT&T, Verizon, Tiscali, Comcast Company…. Malgré sa faible notoriété, le port du protocole CWMP (7547/TCP) est le second port le plus exposé sur internet. Peu d’informations sont donc disponibles sur Internet concernant le composant TR-069. Par exemple, aucun sujet sur Reddit n’est disponible, et seul un groupe de 19 personnes existe sur Twitter.

Les serveurs ACS peuvent être assimilés à des serveurs de supervision chargés de surveiller les CPE (Customer Premises Equipment). Les CPE sont des équipements qui sont raccordés à l’infrastructure d’un opérateur. Dans le modèle utilisé, les communications entre ces deux équipements se font au travers de flux XML où le serveur ACS initie toujours la connexion. Les serveurs ACS sont donc utilisés pour réaliser des opérations de support, des diagnostics de performance, déployer des mises à jour, etc. À qui faites-vous assez confiance pour donner un tel accès ? Avez-vous assez confiance en votre fournisseur Internet pour lui laisser exécuter de telles tâches d’administration, à n’importe quel moment, sans qu’aucune action soit requise de votre part, et ce, au travers d’un service exposé sur Internet ?

Le chercheur a donc réalisé une première analyse de ce type d’équipement sur son propre routeur Netgear fourni par son fournisseur d’accès à Internet. Malgré de longues recherches, Shahar n’a pas réussi à trouver la page permettant de configurer le composant TR-069 du routeur. En effet, cette dernière était masquée au sein de commentaires. Une fois la page identifiée, il a ainsi pu récupérer le mot de passe utilisé. Néanmoins, son fournisseur d’accès à Internet a identifié cet accès frauduleux et a changé cette page afin de l’empêcher de récupérer le mot de passe utilisé.

L’ACS commande de nombreux modules, et est donc une cible très intéressante de par les possibilités qu’il offre :

  • Obtenir des données privées (SSID, hostname et adresse MAC, nom d’utilisateur, VoIP) ;
  • Altérer la configuration des équipements (serveur de résolution DNS, paramètre du WiFi, mettre en place un tunnel WAN contrôlé par l’attaquant) ;
  • Installer un nouveau firmware ;
  • Ou encore, télécharger le firmware de l’équipement.

Pour identifier des équipements exposés sur Internet, il existe de nombreux moyens, notamment via l’utilisation de scanners de ports (MasScan, ZMap …) ou encore avec une simple requête sur Google (ou Shodan).

Le chercheur a ensuite réalisé une rapide analyse sur la configuration des produits exposés sur Internet. Très peu d’entre eux disposent d’une configuration durcie. En effet, seuls 19% des ACS identifiés utiliserait une connexion sécurisée reposant sur SSL…

Shahar Tal s’est ensuite intéressé aux vulnérabilités applicatives. Pour cela, il s’est concentré sur les équipements disposant d’un OS embarqué Open Source. Il a commencé par OpenACS. Au bout de 3 jours d’audit, il a réussi à identifier une vulnérabilité dont l’exploitation permettait l’exécution de commandes à distance (faille d’upload – CVE-2014-2840). Pour GeniesACS, 2 jours lui ont suffi pour identifier une nouvelle exécution de commandes à distance. Toutes ces vulnérabilités sont d’autant plus critiques que l’ACS s’exécute, pour des raisons fonctionnelles, dans le contexte de l’utilisateur root , qui dispose des privilèges les plus élevés sur le système.

Une fois ces vulnérabilités découvertes, le chercheur est parvenu à identifier plus de 500 000 composants vulnérables exposés sur Internet, et accessibles sans restriction particulière. De plus, 100% des produits audités se sont révélés être vulnérables. Néanmoins, pour des raisons évidentes de sécurité, le chercheur n’a pas publié de liste durant sa présentation.

Detecting bleeding edge malware: a practical report, par Fyodor Yarochkin (@fygrave) et Vladimir Kropotov (@vbkropotov)

SLIDES

Dans cette présentation, les deux spécialistes ont dressé un état de l’art des méthodes permettant de détecter les logiciels malveillants sur un système d’information. Fyodor Yarochkin et Vladimir Kropotov sont revenus sur de nombreux cas concrets de logiciels malveillants ayant pu être identifiés via une analyse comportementale. La principale technique exposée réside dans l’analyse des flux DNS et des requêtes HTTP. En corrélant toutes ces données, les deux conférenciers ont expliqué qu’ils parvenaient à identifier rapidement des malwares au sein d’un réseau. Notamment, une adresse IP communiquant avec de nombreux domaines était automatiquement marquée comme suspecte.

Les deux chercheurs ont également partagé quelques anecdotes intéressantes issues de leur expérience personnelle :

  • Un attaquant change en moyenne de domaine toutes les 3 minutes.
  • Certains malwares utilisent des ports non standard afin d’identifier des cibles faciles. De ce fait, seuls des réseaux peu sécurisés sont touchés. Ceci permet donc de réduire le risque d’être repéré et donc d’être analysé.
  • Les pirates utilisent Google pour piéger leurs victimes. En effet, Google permet aux pirates de les rediriger vers des sites malveillants au travers de nombreuses fonctionnalités.
  • La France est le pays européen hébergeant le plus de serveurs sur lesquels sont installés des kits d’exploitation. En effet, d’après les deux chercheurs, les équipes techniques d’OVH seraient les moins réactives aux plaintes concernant les comportements malveillants de leurs clients.

L’ensemble des outils (et notamment le framework ayant permis de réaliser l’étude passive des requêtes DNS) sera prochainement publié.

USB Fuzzing : approaches and tools, par Jordan Bouyat (@la_F0uin3)

SLIDES

Après une brève introduction décrivant les bases du protocole USB, des techniques de fuzzing existantes et des outils les plus appropriés pour la recherche de bug, Jordan, qui travaille pour Quarkslab a présenté son propre outil de fuzzing. Celui-ci est basé sur une carte Facedancer conçue par Travis Goodspeed et permet de jouer et de rejouer des trames USB modifiées, avec un système de surveillance permettant de détecter toute anomalie.

SherlockDroid, an Inspector for Android Marketplaces, par Axelle Apvrille (@cryptax) et Ludovic Apvrille

SLIDES

Chaque jour, c’est plus de 1000 applications Android malveillantes qui sont publiées sur Internet. Il apparait donc impossible de les analyser et de les étudier manuellement. Les deux chercheurs, Axelle et Ludovic Apvrille, ont donc créé un logiciel baptisé SherlockDroid pour catégoriser les malwares de manière automatique. Le but est donc d’identifier les nouveaux malwares qui méritent d’être analysés afin de ne pas gaspiller le temps des chercheurs.

Les malwares sont identifiés par un hash . Néanmoins, cette signature n’est pas un simple hash MD5 du fichier. Cette légende était vraie il y a 20 ans. Ainsi, afin de trier tous ces nouveaux malwares, un scan rapide est réalisé afin d’identifier toutes les souches de malwares connues ou les variantes pouvant s’en rapprocher. Afin d’augmenter la précision de cette analyse, une méthode dite Carbone 14 est utilisée pour dater la création du malwares (date de compilation, etc.). Afin de classifier les malwares, voici quelques points de contrôles qui sont réalisés :

  • Identification des applications demandant un accès à toutes les permissions ;
  • Identification de toutes les chaines de caractères (tous les objets sont mappés à des strings au sein de Dalvik) ;
  • Identification des ressources qui sont chargées par l’application.

Depuis début 2014, SherlockDroid a permis d’analyser près de 140 000 applications et a permis d’identifier avec succès de nouvelles souches de malwares, telles que Android/Odpa.A!tr.spy .

Voici, quelques cas concrets identifiés à l’aide de SherlockDroid :

  • un malware qui surveille les SMS et les envoie par mail à l’attaquant ;
  • un malware qui renvoie des coordonnées GPS envoyées en clair sur Internet.

Néanmoins, les chercheurs se sont heurtés aux contraintes imposées par les créateurs des différents marketplace alternatifs. En effet, ces derniers ne souhaitent pas que leurs magasins d’application soient totalement aspirés dans le but d’être scannés. De nombreux mécanismes de contournement ont donc été implémentés afin d’échapper aux filtres mis en place. Une autre difficulté est de différencier les programmes tiers (logiciel de publicité) des malwares qui ont, dans certains cas, un comportement similaire.

Les deux chercheurs n’ont pas prévu de divulguer la liste exhaustive des points de contrôle afin que les attaquants ne puissent pas adapter leurs malwares et ainsi échapper à SherlockDroid.

SENTER Sandman: Using Intel TXT to Attack BIOSes, par Xeno Kovah (@XenoKovah), Corey Kallenberg, John Butterworth et Sam Cornwell

Après avoir présenté Extreme Privilege Escalation On Windows 8/UEFI Systems, l’équipe du MITRE menée par Xeno Kovah est revenue pour nous présenter  Copernicus 2 , une solution technique permettant de scanner en temps réel l’espace mémoire manipulé par le SMM, afin d’identifier les attaques du même type que celle présentée la veille.

WiHawk – Router Vulnerability Scanner, par Anamika Singh (@_Anamikas_)

SLIDES

Anamika Singh est venue présenter WiHawk, un outil Open Source permettant de réaliser un audit de sécurité des points d’accès réseau. Parmi les tests réalisés, cet outil permet d’identifier :

  • les routeurs configurés avec des comptes d’utilisateurs par défaut ;
  • les routeurs vulnérables à des contournements d’authentification, Buffer Overflow, etc ;
  • les vulnérabilités web telles que des injections de code ou des attaques de type « Cross Site Request Forgery » (CSRF) ;
  • les portes dérobées bien connues pouvant être implémentées sur les routeurs.

Evasion of High-End IDPS Devices at the IPv6 Era, par Enno Rey (@Enno_Insinuator), Antonios Atlasis et Rafael

SLIDES

Pour conclure cette seconde journée de conférences, cette présentation a permis d’aborder le contournement des systèmes de détection d’intrusion (ou IDS) destinés à repérer des activités anormales ou suspectes sur un réseau. Les chercheurs se sont intéressés plus particulièrement à l’utilisation de l’IPv6 pour arriver à leur fin.

Les conférenciers ont commencé par revenir sur une présentation des mécanismes introduits avec IPv6 et plus particulièrement sur les en-têtes d’extension.

En effet, les options IPv6 sont placées dans des en-têtes d’extension situés, dans un paquet, entre l’en-tête IPv6 et l’en-tête de la couche transport. Ces en-têtes sont optionnels et très peu utilisés. Toutefois, toute pile réseau IPv6 doit être en mesure de les supporter.

Parmi les en-têtes d’extension IPv6 existants, on retrouve :

  • Hop-by-Hop
  • Routing
  • Fragment
  • Destination
  • Authentication
  • Encapsulating
  • MIPv6
  • HIP (Host Identity Protocol)
  • Shim6

D’après la RFC, même si cela n’est pas obligatoire, il est recommandé d’utiliser ces en-têtes dans cet ordre au sein du datagramme IPv6.

Toutefois, cette définition et la flexibilité protocolaire introduisent trois problèmes auxquels doivent faire face les IDS :

  1. L’utilisation des en-têtes d’extension influence les attributs d’un paquet IPv6 (type, taille, ordre, etc.) et complexifie leur traitement et leur analyse ;
  2. Les sections Fragmentable et Unfragmentable d’un paquet peuvent toutes les deux contenir des en-têtes d’extension ; ce qui accentue d’autant plus le problème numéro 1 ;
  3. Le chainage des en-têtes d’extension IPv6 est réalisé à l’aide du champ Next Header présent au sein de chaque extension de type Fragment .

La tolérance d’implémentation acceptée par le protocole IPv6 permet une utilisation abusive de ces en-têtes ; ce qui permet donc de contourner les IDS les plus courants. En effet, ceux-ci se basent généralement sur la détection de signatures ou de règles comportementales.

La suite de la présentation s’est ainsi attachée à démontrer les constats établis par ces trois chercheurs sur quatre des systèmes de détection d’intrusion les plus répandus : Suricata, TippingPoint, Sourcefire et enfin Snort.

Enfin, deux autres conférences ont été proposées au cours de la journée. N’y ayant pas assisté, nous ne pourrons pas vous proposer de résumé.

  • SCADA deep inside: protocols and security mechanisms, par Aleksandr Timorin (@atimorin)
  • We’re struggling to keep up (A brief history of Browser Security Features), par Frederik Braun (@freddyb) SLIDES

Adrien Guinault

Découvrir d'autres articles

  • Conférences

    Retour sur WestDataFestival 2024

    Lire l'article
  • Conférences

    DORA et la résilience opérationnelle des fournisseurs

    Lire l'article
  • Conférences

    Retour sur la Black Hat Europe 2023

    Lire l'article