SSTIC 2020 - JOUR 1

Comme tous les ans, XMCO vous propose une revue de certaines conférences du SSTIC.

Introduction

Le SSTIC, Symposium sur la Sécurité des Technologies de l’Information et des Communications, est une conférence francophone réputée pour la qualité technique des sujets présentés.

L’édition du SSTIC a pris cette année une tournure très spéciale. En raison de la crise COVID-19, les conférences ont été enregistrées en amont et sont diffusées en direct et gratuitement en ligne.

Pour maintenir une interactivité malgré tout, les organisateurs ont également mis en place un chat IRC permettant de poser des questions aux conférenciers au cours de l’évènement.

Comme tous les ans, XMCO a suivi cette conférence et vous propose un résumé tous les jours de quelques conférences choisies parmi celles diffusées dans la journée. Ces dernières seront également regroupées au sein de notre prochain numéro d’ActuSecu.

Références SSTIC :

• Site officiel : https://www.sstic.org
• Programme de Conférence : https://www.sstic.org/2020/programme
• Direct : https://streaming.sstic.org
• Actes : https://actes.sstic.org/SSTIC20/sstic-2020-actes.pdf

Pursuing Durable Safety for Systems Software, Matt Miller

Quelles sont les meilleures pratiques à suivre pour parvenir à garantir la sécurité d’un composant logiciel tout au long de son cycle de développement ?
C’est à cette vaste question qu’a tenté de répondre Matt Miller, membre de l’équipe Microsoft Security Response Center lors de la première conférence du SSTIC 2020.

Fort de son expérience au sein des équipes de Microsoft, Matt Miller a d’abord rappelé les grands principes d’un système logiciel sûr :

• il doit être difficile d’implémenter du code à risque sur ce système ;
• il doit être facile de vérifier l’implémentation sécurisée du code ;
• il doit permettre une productivité maximale pour les développeurs ;
• il doit être fiable (stable) et assurer des performances standards ;

Le conférencier a constaté que les vulnérabilités étaient toujours aussi nombreuses de nos jours, et qu’elles concernaient proportionnellement de plus en plus des défauts de gestion de mémoire. Il constate que les vulnérabilités publiques sont de moins en moins exploitées, durant les 30 jours suivants leur publication CVE. De son analyse, ces vulnérabilités sont majoritairement exploitées en amont de leur publication (vulnérabilité 0day).

Dans un second temps, Matt Miller a présenté à quel point il pouvait être difficile d’implémenter du code “non vulnérable” via des langages comme le C ou le C++. Ces langages ne permettent pas d’assurer de manière automatique une analyse statique ou dynamique du programme d’un point de vue de la sécurité. L’analyse par Fuzzing d’une solution nécessite également une étape manuelle de configuration. L’audit de code statique nécessite une intervention humaine d’analyse. Par ailleurs, les logiciels s’appuient sur des dépendances ne présentant aucune garantie absolue sur le niveau de sécurité de code ou sur son intégrité.

Le conférencier a ensuite énuméré quelques méthodes pour assurer un niveau de sécurité standard, et éliminer les vulnérabilités les plus communes.

Tout d’abord, il recommande d’utiliser des langages considérés comme sécurisés par conception, comme le RUST ou le C#.
Si cela n’est pas envisageable, il a proposé des méthodes de sécurisation contre les vulnérabilités les plus communes de type :

• dépassement de tampon dans le tas (heap out of bounds)
• utilisation de mémoire après sa libération (use after free)
• confusion de type (type confusion)
• erreurs arithmétiques comme dépassement d’entier (arithmetic errors)

Enfin, Matt Miller est revenu sur les méthodes de sécurisation indirectes, par deux biais :

Les extensions sécurité niveau hardware :

• l’extension Memory Tagging d’abord, est implémentée depuis ARMv8.5. Chaque allocation de mémoire est référencée. Lorsqu’une tentative d’accès est effectuée par pointeur, le tag du pointeur est vérifié avec le tag de référence.
• l’extension CHERI (Capability Hardware Enhanced RISK Instruction), en cours de développement, permet notamment de se prémunir des vulnérabilités de type dépassement de mémoire. Cette extension est compatible avec les implémentations en C/C++.

La sécurisation de la chaîne de développement :

• ceci concerne les étapes du développement initial et la pull request associée, jusqu’à la vérification du code soumis. Il souligne l’importance de s’assurer que les auteurs de code soient correctement authentifiés sur les dépôts de code (authentification multifacteur).

Matt Miller a conclu sur l’importance d’intégrer au sein des équipes des méthodes d’implémentation sécurisée de manière durable, et espère voir les solutions logicielles évoluer sous les dix prochaines années.

Pivoter tel Bernard, ou comment monitorer des attaquants négligents, Daniel Lunghi

Daniel Lunghi, chercheur spécialisé dans l’analyse des APT chez TrendMicro, a profité de son intervention pour expliquer les méthodes employées dans la surveillance des groupes d’attaquants. Cette intervention a pour buts d’aider à la réponse à incident, d’analyser les TTP (Tactics, Techniques and Procedures) des attaquants et de permettre d’attribuer l’apparition d’un nouveau malware à son groupe d’origine.

En fil conducteur de sa présentation, le chercheur illustre son raisonnement en suivant une investigation débutée en juillet 2019 suite à une attaque visant un opérateur philippin de paris en ligne.

Cette investigation débute lorsque les équipes de TrendMicro sont chargées d’analyser des échantillons de 4 programmes malveillants inconnus, identifiés chez l’opérateur attaqué.

La première étape consiste à classifier les malwares afin de déterminer leur provenance. Pour ce faire, différents indicateurs de compromission (ou IOC) sont extraits des échantillons analysés. Ceux-ci peuvent être des noms de domaine, des adresses IP, des noms de fichiers ou encore des marqueurs présents au sein du code.

Ces IOC ont permis de révéler des informations sur l’activité du groupe père de cette campagne et ses méthodes de développement:

• l’un de ces malwares comporte des identifiants de sa version au sein de ses métadonnées. Ces versions révèlent l’existence de 9 versions développées en 5 mois, preuve de la capacité importante de développement du groupe ;
• l’un des malwares embarque un algorithme de chiffrement basé sur une S-Box (fonction de substitution utilisée pour mélanger les bits d’un message chiffré). Une recherche au sein du moteur RetroHunt permet de remonter à un dépôt de code présentant cette même S-Box, publié en 2015. Les attaquants ont donc simplement procédé en recopiant le code de cet algorithme pour l’intégrer dans leur malware ;
• l’un des programmes comporte des identifiants de Mutex sous forme de constantes. Ces identifiants ont pu être retrouvés sur un ancien malware dénommé BbsRAT, qui communiquait avec un domaine attribué au groupe Winnti.

L’analyse des serveurs de contrôle utilisés par un malware est également un moyen permettant de remonter jusqu’au groupe originaire. En effet, certains domaines sont utilisés dans plusieurs campagnes d’attaques et peuvent trahir la paternité d’une attaque.

Cependant, Daniel Lunghi présente un point pouvant induire en erreur lors de cette phase de corrélation IP/domaines : les domaines utilisés par les attaquants peuvent être hébergés sur une plateforme mutualisée, rendant caduque l’identification des serveurs par adresse IP.

Daniel Lunghi se penche alors sur une approche différente permettant d’associer d’autres domaines à un groupe donné : partant de l’hypothèse que les attaquants créent leurs différents domaines de manière groupée à un instant précis, une analyse temporelle des journaux des registrars peut aider à révéler les différents noms déposés par un groupe, enregistrés à quelques secondes d’intervalle.

Il souligne alors l’importance pour les clients d’antivirus d’activer les fonctionnalités de télémétrie des antivirus. C’est par ce biais que des IOC identifiés sur les malwares analysés ont pu être retrouvés dans des emails de phishing envoyés à un autre opérateur du secteur des paris en ligne, confirmant l’intérêt du groupe pour les acteurs de ce secteur.

En conclusion de l’analyse de ces différents IOC, il s’avère que cette attaque a pu être liée à deux groupes d’attaquants asiatiques, Winnti et Emissary Panda.

En complément de son analyse, Daniel Lunghi illustre comment les fonctionnalités embarquées dans un malware peuvent se retourner contre ses créateurs. L’un des malwares utilisait en effet la plateforme Dropbox comme support de stockage pour les charges malveillantes. En extrayant la clé d’API Dropbox présente dans ce malware, les chercheurs ont pu s’authentifier auprès de l’instance utilisée. Une analyse des fichiers présents a pu leur apporter des informations utiles à l’analyse et à la réponse à incident:

• plusieurs charges ont été identifiées au sein de l’instance, révélant l’existence d’une nouvelle famille de malware utilisant Dropbox comme support ;
• plus de 50 outils d’exploitation étaient présents au sein de l’instance, permettant d’identifier les outils utilisés par le groupe et de comprendre leur méthodologie d’attaque.

L’agent qui parlait trop, Yvan Genuer

Enfin, Yvan Genuer a présenté une exploitation d’une série de vulnérabilités sur SAP Solman (SAP Solution Manager). Cette solution permet d’administrer et de superviser des équipements au sein d’une infrastructure SAP. Chacun des composants administrés de l’infrastructure SAP est interfacé par un agent dénommé SMD Agent.

Sur chaque composant administré, les premiers constats relatifs à l’agent SMD réalisés par le conférencier sont :

• la présence de fichiers de configuration chiffrés et de binaires sous un répertoire local spécifique SMDAgent ;
• l’exécution de l’agent sous forme de service (compte daaadm) ;
• l’exposition de 3 services en écoute, dont un service non identifié exposé sur un port aléatoire.

L’auditeur constate également que le fichier habituellement protégé SAP Secure Storage n’est pas chiffré, mais simplement encodé en BASE64. Ce fichier contient deux paramètres (algorithme et clef) permettant de déchiffrer les fichiers de configuration de l’agent SMD. Des identifiants de comptes du SAP Solution Manager ont ainsi pu être récupérés au sein de ces fichiers de configuration.

Yvan Genuer a par ailleurs attribué le service initialement non identifié (exposé sur un port aléatoire) comme le service SAP P4. C’est au travers de ce service que la communication entre le manager et l’agent est réalisée.

Le protocole associé à ce service SAP P4 a été analysé par le conférencier. Il se base sur des secrets identifiables en temps raisonnable par du fuzzing (< 2 min) sur les champs observés.

L’un des champs des messages P4 est à un secret d’authentification. Cependant, l’analyse de ce champ a révélé qu’il ne s’agissait que d’un marqueur temporel dépendant de l’instant de démarrage de l’agent. Cette information, accessible publiquement auprès du composant SAP Management Console, permet alors à l’attaquant de forger un message P4 valide.

En manipulant le champ d’un identifiant d’objet (remoteos), un attaquant est en mesure d’exécuter du code arbitraire sur le système au travers du SMD Agent.

SAP introduit le protocole SAP P4S pour éviter toute manipulation/lecture du protocole. Cependant, bien que la version sécurisée du protocole P4 soit activée, la version non chiffrée du protocole P4 demeure accessible et joignable par un attaquant.

Enfin, le conférencier a abordé les contre-mesures associées à ces vulnérabilités. Il recommande :

• de mettre à jour la solution SAP Solman et les agents associés
• d’interdire l’accès réseau au service P4 (seulement P4S si nécessaire)
• et de modifier la liste blanche des commandes système autorisées via l’agent, soit par une liste vide, soit par une liste blanche restrictive sans ajout de paramètre de commande possible.