16 juin 2018

Retours sur le SSTIC – 16e édition – Jour 3

SSTIC

Starve for Erlang cookies to gain Remote Code Execution

(Par Guillaume Teissier)

Guillaume a exposé les travaux qu’il a mené sur le langage et l’environnement d’exécution Erlang qui a été créé par Ericsson pour les systèmes Télécom. Ce stack est encore utilisé aujourd’hui dans les équipements réseau et spécialement dans les équipements de type cœur de réseau.

L’idée dernière de cette présentation est d’identifier les potentielles faiblesses de ce stack et de proposer un guide de durcissement des systèmes Erlang. Pour mener à bien son étude l’auteur a étudié deux brokers basés sur Erlang, à savoir RabbitMQ et ejabberd.

L’environnement d’exécution même d’Erlang est pensé pour faciliter la communication entre des nœuds et permettre facilement d’envoyer des messages entre deux machines distantes. En théorie, cela permet l’exécution de tout type d’opération y compris les commandes système.

De ce fait, le focus a été mis sur le cookie Erlang qui est une sorte de secret partagé composé de 20 lettres majuscules. Ce dernier permet d’authentifier les machines entre elles. Ce cookie est généré automatiquement par la machine virtuelle Erlang puis est copié par un administrateur vers les machines qui doivent communiquer avec elle. La connaissance d’un cookie valide sur un système entraîne donc l’accès à celui-ci.

Afin d’attaquer un service Erlang, le Guillaume a commencé par identifier les ports ouverts à exploiter. Une fois que cette opération réalisée, l’étape suivante a été d’étudier le mécanisme de génération des cookies Erlang.

À première vue, il faut 2^94 tentatives pour deviner un cookie valide ce qui est techniquement impossible. L’analyse poussée des mécanismes de génération interne du cookie a révélé plusieurs anomalies notamment le fait que l’état interne du générateur de nombre aléatoire est limité sur 36 bits.

En se basant sur ces constats, Guillaume a créé un script de bruteforce capable de trouver le cookie Erlang en 1min30.

À la fin de la présentation, le présentateur a mentionné le fait qu’il a contacté Ericsson qui a indiqué être en train d’améliorer le mécanisme de gestion des cookies.

Ça sent le SAPin !

(Par Yvan Genuer et Alexandre Bollet Reddat)

Yvan et Alexandre ont présenté les résultats de leurs recherches sur la sécurité de SAP, la méthode d’analyse suivie, leur contribution à la communauté sécurité de SAP, ainsi que quelques vulnérabilités découvertes à l’issue de leurs tests.

SAP est un ERP utilisé par plusieurs entreprises pour des fins de gestion financière, maintenance, gestion des ressources humaines, comptabilité et marketing, etc.

Yvan a commencé par présenter l’architecture de cette solution « SAP Netwear » ainsi que les rôles des services SAP.

Ensuite, il a présenté quelques concepts autour de la sécurité de ce système :

  • Les services SAP tournent avec les droits <sid> adm (utilisateur ayant plusieurs droits d’administration)
  • Le noyau SAP est un ensemble de binaires sur le système d’exploitation
  • Le code source ABAP (langage propriétaire de SAP) est stocké dans la base de données et est donc accessible à tout le monde
  • Tout système SAP possède un environnement de développement

Dans un second temps, les orateurs ont présenté l’architecture des services SAP Internet Graphic Server (IGS) ainsi que la méthodologie suivie lors de l’analyse de ces services. Cela leur a permis de découvrir qu’il était possible d’envoyer des paquets SAP IGS sans être authentifié.

Cette phase de découverte a permis aux deux conférenciers de contribuer à des projets d’audit SAP, à savoir :

  • PYSAP: une librairie python pour l’écriture et l’envoi des paquets SAP
  • SAP Dissection: un plugin Wireshark supportant le protocole SAP

Les orateurs ont également conduit des recherches autour de la fonction « ADM:INSTALL ». Cela leur a permis de découvrir qu’il était possible de créer des fichiers avec ladite fonction et de les envoyer sur SAP sans authentification, moyennant le debugger ABAP.

Ensuite, ils ont décrit deux vulnérabilités parmi les 25 remontées à l’issue de leurs recherches :

  • La possibilité d’écrire des fichiers dans les répertoires SAP sans authentification
  • La taille du nom du fichier envoyé n’est pas vérifiée chose qui peut conduire à un déni de service si la taille est très grande.

Finalement, les orateurs ont rappelé qu’un langage propriétaire n’est pas équivalent à un langage sécurisé et que la recherche en sécurité SAP n’est pas compliquée comme beaucoup peuvent le penser.

Dans les coulisses de l’équipe sécurité Debian

(Par Yves-Alexis Perez)

Au cours de sa présentation Yves-Alexis, aussi connu dans la communauté Debian sous le pseudo Corsac nous a fait un rapide retour sur l’équipe sécurité de Debian.

Effectivement, beaucoup de personnes utilisent ce système d’exploitation et connaissent les Debian Security Advisories (DSA). Néanmoins, l’équipe sécurité de Debian ne compte que 10 personnes dont 5 de vraiment actives.

Ainsi, Yves-Alexis nous a présenté les activités de l’équipe sécurité, les activités sur lesquelles ils ne sont pas engagés ainsi que les moyens de communication dont ils disposent.

Enfin, le conférencier a fait un rapide retour sur la façon dont les vulnérabilités KRACK et Meltdown ont été prises en compte, de la découverte jusqu’à la communication suite à l’application des correctifs de sécurité.

Hacking Harness Open-Source

(Ivan Kwiatkowski)

Ivan a brièvement présenté une problématique rencontrée lors de tests d’intrusion (red team) et plus particulièrement lors de la phase de post-exploitation. Cette conférence fait un peu suite à la conférence HITB (édition 2007) de The Grugq.

Lors de la compromission d’un serveur Web, il est fréquent de déployer des agents basiques, afin de pouvoir, par la suite, réaliser des commandes plus avancées. Ces tâches sont répétitives et peuvent être automatisées simplement tout en restant le plus furtives possible (anti-forensics : “No logs, no crime”). Les attaquants avancés s’efforcent de plus en plus à limiter les traces qu’ils laissent (IP dans les fichiers de journalisation, code d’exploit (0 day ?) utilisé, voire même de simples actions réalisées sur le serveur), afin de passer totalement inaperçus.

Le problème présenté repose sur plusieurs points. Tout d’abord, l’anti-forensics est une méthode hautement faillible. En effet, il suffit d’une petite erreur pour alerter les équipes de sécurité. Ensuite, il y a un manque d’outils de type post-exploitation et il existe trop souvent des contraintes techniques (Shell sans TTY, latence ou coupure réseau, etc.).

Pour résoudre cette problématique, il existe deux approches :

  • Effacer les preuves
  • Ne jamais créer de preuves

En réponse à cela, Ivan a développé et mis à disposition l’outil Freedom Fighting Mode (FFM). Celui-ci est développé en Python3 et peut être assimilé à un terminal amélioré (Shell augmenté). Il permet, de plus, d’automatiser les tâches ordinaires telles que le téléchargement ou le dépôt de fichiers, ainsi que l’exécution en mémoire (éviter les traces d’écriture sur le serveur).

Pour finir, il émule un TTY basique (fonctionnalité de TAB, etc.) et peut être facilement adapté suivant les besoins grâce à des extensions de scripts.

Point de défaillance unique DNS en utilisant l’analyse de disponibilité transitive des dépendances

(Par Florian Maury)

Pour cette présentation, Florian commence par nous expliquer les grands principes du DNS. Il a ensuite présenté les causes possibles d’une indisponibilité des serveurs gérant les noms de domaines. Il en existe un certain nombre, mais cette étude s’est basée sur les problèmes liés aux dépendances entre les serveurs DNS (causées par une délégation sans glue ou un alias DNS).

Le problème est le suivant. Les serveurs DNS, ou leurs alias peuvent dépendre de serveurs parents uniques et présentent ainsi un point de défaillance unique. Ceci se traduit par le schéma suivant :

BSSI-SSTIC-DNS1

Ensuite, il existe des serveurs qui ont une relation de dépendance dite circulaire. Le schéma ci-dessous illustre ce problème :

BSSI-SSTIC-DNS2

Afin d’étudier ces problèmes, Florian a développé un script permettant de collecter et d’analyser les dépendances DNS. Il s’est ensuite aperçu que plus de 83% des 4 millions de domaines étudié dépendent d’une IP unique.

Les domaines issus du top 1 million d’Alexa, eux, s’en sortent mieux. En effet, seulement 5% de ces domaines présentent des points de défaillance uniques.

Ainsi, il recommande aux administrateurs de domaines à diversifier leurs topologies réseau, d’adopter une stratégie de nommage, et de vérifier leur graphe de dépendance de manière régulière.

Régis Senet

Régis Senet :
Consultant BSSI

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *