La Lettre du CERT-Solucom

Transcription

1 n 4 - janvier 2015 La Lettre du CERT-Solucom Dossier La gestion d une crise APT : retours d expérience terrain En perpétuelles évolutions, nous sommes aujourd hui tous concernés par les cyber-menaces. De l hacktivisme à la déstabilisation organisée par des États, en passant par les gains financiers ou les vols de données, les motivations des cybercriminels varient et se multiplient. Aucun secteur d activité n est aujourd hui épargné. Les techniques d attaque évoluent en conséquence ; des attaques diffuses visant le grand public, contrées par les mécanismes traditionnels de sécurité, aux attaques opportunistes d un niveau technique plus avancé, elles se diversifient et se complexifient chaque année un peu plus. Désormais, ce sont les attaques ciblées APT pour Advanced Persistent Threat qui apparaissent au premier plan comme la menace la plus sévère pour les organisations. La question de la sécurisation du SI se pose donc en premier lieu. En revanche, la menace est telle qu il serait utopique de se sentir entièrement à l abri. Et vous, êtes-vous prêt à maîtriser la situation engendrée par la découverte d une telle attaque sur votre système d information? Les expériences passées montrent qu il est souvent difficile de mener correctement une gestion de crise APT sans l avoir vécue une première fois ; constat regrettable au vu des dégâts qu elle peut faire subir. Tentons de revivre étape par étape une telle situation grâce aux retours d expérience du CERT-Solucom. Vous pourrez y trouver de bonnes pratiques à adopter et de bons conseils pour mener à bien votre gestion de crise APT. A lire également P6 Dossier : CERTitude - Simplifier les campagnes de recherche d IOC P13 Dossier : Best-Of Black Hat Europe / NSC / Botconf 2014 P19 Focus sur PyKEK et MS

2 De la détection d un incident de sécurité au déclenchement d une cellule de crise APT Malgré leur savoir-faire et leur outillage, les cybercriminels génèrent, comme tout utilisateur, des événements et des traces, souvent intitulés «artefacts». Ces derniers résultent des diverses actions réalisées sur les équipements du système d information au cours de l attaque. Un bon attaquant saura être discret, voire parfois indétectable. Les traces générées, pourvu qu il y en ait, paraîtront alors tout à fait légitimes ; elles ne seront que difficilement perceptibles dans le «bruit de fond» permanent des flux et des actions produits par les collaborateurs. Aucun attaquant n est en revanche parfait ; ils restent avant tout des êtres humains qui pourront tôt ou tard commettre une erreur. Le premier levier d une bonne gestion d une APT tient par conséquent à la capacité de détection d un incident de sécurité et à la qualité de sa qualification (faux-positif, mineur, majeur, critique, etc.). Figure 1 : Exemple de processus de qualification d un incident de sécurité La détection s appuie sur de multiples sources, incluant notamment : Les outils de sécurité du SI : serveur mandataire («proxy»), IDS/ IPS, pare-feu, DLP, anti-apt, etc. Les mécanismes de traçabilité, d agrégation et de corrélation des actions réalisées (SIEM). Les outils de recherche à froid : recherches ponctuelles sur l ensemble des journaux d événements, recherches de présence de signaux faibles / IOC (Indicator Of Compromise) sur les équipements du SI, etc. L alerte d un utilisateur ou d un administrateur du SI qui, de par sa sensibilisation, remonte spontanément les événements lui semblant suspicieux. L alerte d un partenaire ou d un fournisseur. L alerte d un professionnel de la sécurité des SI, prestataire mais connaisseur du contexte client, menant une veille permanente sur internet. Une fois détecté, l incident doit être qualifié de manière à s assurer qu il relève bien d un incident de sécurité du SI. Dans l affirmative, l incident est enregistré et analysé. À ce stade, hors cas évidents, la présomption de la présence d une APT est difficile à établir ; débute alors une phase d analyses préliminaires. Pour ce faire, un processus préétabli vous permettra un gain d efficacité notable. Toujours dans le cas d un incident de sécurité, une réponse préliminaire peut être mise en place en parallèle des analyses approfondies. Cette réponse regroupe les actions à entreprendre immédiatement afin de notamment limiter les dommages occasionnés par l incident de sécurité, maintenir le contrôle sur le SI infecté, et enfin accroître les capacités d observation en vue des investigations futures. Si ces premières analyses démontrent la présence de signes avant-coureurs d une APT et que le niveau de criticité induit est maximal, vous devez alors déclencher en urgence une cellule de crise afin d approfondir les recherches permettant d écarter d éventuels faux-positifs, de construire la temporalité de la compromission, d identifier son origine et de rechercher la présence d autres artefacts. Si cette présomption d APT ne présente aucune divulgation avérée sur Internet ou n est accompagnée d aucune revendication, nous préconisons d adopter un principe de discrétion. Elle permet alors de prévenir le risque que l attaquant (éventuellement interne) ne découvre qu il ait été repéré ; il pourrait alors déclencher précipitamment la phase finale de son attaque ou encore modifier son mode opératoire au profit d un mode plus silencieux, furtif. Ne vous précipitez pas, élaborez votre plan d intervention! Même si aucune conclusion certaine ne peut être établie, les signes caractéristiques d une APT sont présents, le passage «en crise» est dorénavant officiel. Il faut maintenant mettre en œuvre les moyens nécessaires pour mener une gouvernance efficace. Il ne faut pas pour autant agir sans réfléchir, même si l urgence de la situation et le stress vous y incitent. Une première étape primordiale est alors l élaboration d un plan d intervention. Sur la base des informations déjà collectées lors des analyses préliminaires, il faut déterminer : Les ressources humaines à mobiliser : les acteurs opérationnels et métiers disposant d une connaissance des environnements affectés, les acteurs internes pouvant jouer un rôle important dans la gestion de crise, les prestataires spécialisés et dotés d une expertise SSI poussée afin de constituer ou de consolider les équipes d investigation technique et enfin, si besoin est, les autorités (ANSSI, DGSI, Haut Fonctionnaire de Défense et de Sécurité, Autorité des Marchés Financiers, CNIL, etc.). Les moyens techniques à déployer afin d être en mesure de communiquer de manière sécurisée et d opérer les investigations techniques. En cas de dépôt de plainte envisagé, il est nécessaire de prendre des précautions particulières dans la collecte, l analyse et le stockage des preuves ; n oubliez donc pas l aspect juridique de vos actes. L identification de ces ressources et de ces moyens vous permettra alors : 2 La Lettre CERT-Solucom N 4 janvier 2015

3 De collecter des éléments de contexte supplémentaires et pertinents : afin de renforcer vos connaissances de l attaque pour mieux diriger vos futures investigations (e.g. identification des actifs compromis et exposés, évaluation des impacts, etc.). De déclencher les dispositifs de gestion de crise généraux : si besoin, il faut initier les dispositifs de continuité d activité, anticiper le risque de saturation de vos équipes d intervention, prévoir les astreintes nécessaires, sensibiliser tous les acteurs aux premiers réflexes à adopter, s assurer que chaque personne de votre cellule connaisse son rôle et ses objectifs et enfin, planifier des points d avancement récurrents. De mettre en place un ensemble de services de communication sains et sécurisés : les membres de votre cellule de crise doivent pouvoir continuer à communiquer ainsi qu à échanger et stocker de l information et ce, de manière totalement sécurisée. Pour ce faire, un système d information simplifié 1, déployé pour l occasion et totalement indépendant du SI infecté est à envisager. D informer les autorités et l ANSSI de la situation (si vous êtes un Organisme d Importance Vitale, vous êtes dans l obligation de le faire). De mettre en place les moyens logistiques nécessaires à une gestion de crise efficace (salles 24/7 isolées et à accès restreint, etc.). De permettre de traiter efficacement des actions sur des sites géographiques lointains. D identifier une «zone d arrêt d urgence» en listant les actifs critiques ne pouvant être compromis et nécessitant le déclenchement immédiat et inconditionnel d un plan de défense, même partiel et perfectible («procédure bouton rouge»). D élaborer et communiquer un plan d investigation technique : pour ce faire, commencez par répondre aux questions suivantes et agissez en conséquence : - Quels seront les membres de votre équipe d investigation technique? Avez-vous suffisamment d expertise interne ou devez-vous faire appel à un prestataire externe spécialisé? Qui sera en charge de cette équipe et d assurer la bonne concordance de vos recherches? - Savez-vous quelle stratégie adopter pour débuter les recherches approfondies? Avez-vous des pistes intéressantes à creuser suite aux premières constatations tirées des analyses préliminaires? - Avez-vous accès à l ensemble des données et équipements nécessaires aux investigations techniques (captures et analyses des mémoires, disques durs, journaux d évènements, outils et expertise de reverse engineering, etc.)? - Êtes-vous suffisamment outillé 2 pour réaliser efficacement les investigations numériques (forensique)? - Pouvez-vous prévoir de nouveaux comptes spécifiques pour les investigateurs avec changement de mot de passe régulier? - Avez-vous anticipé les contraintes légales (selon le pays concerné, en cas de dépôt de plainte) liées aux matériels à emporter et aux collectes possibles? - Avez-vous les moyens d assurer une capacité d intervention 24/7? Tout en restant efficace, prenez donc le temps nécessaire pour réaliser ces tâches et répondre à ces questions. Le temps que vous pensez perdre, vous le gagnerez par la suite. Déroulez votre stratégie : investiguez, comprenez et préparez votre défense! Vous avez pris le temps court mais crucial! de réfléchir. Vous pouvez dorénavant dérouler votre plan d intervention. Il est primordial d avancer efficacement sur les investigations techniques qui donneront au fur et à mesure une matière indispensable pour la pertinence de votre défense. Leur pilotage doit donc être une priorité. Par ailleurs, il est également conseillé que certains membres de votre équipe aient le temps de prendre régulièrement le recul nécessaire sur le déroulement de l attaque ; qu ils puissent réfléchir au déroulement global de cette dernière et ainsi tenter d anticiper l évolution qu elle pourrait prendre par la suite. Ces «cyber-stratèges» pourraient ainsi vous permettre d avoir un pas d avance sur l attaquant. Afin de mener à bien ces investigations, il est difficile de proposer une stratégie unique, qui fonctionnerait à coup sûr, tant elles dépendent de votre SI et du contexte de l attaque. En revanche, voici une liste non exhaustive des actions et conseils «types» valables dans une majorité des cas : Collectez les données sur les composants infectés du SI (rapatriement de journaux, copies de systèmes, etc.) ; Recherchez les indicateurs de compromission (IOC) dans les données collectées (revues des services et processus actifs, analyses réseaux, analyses mémoires, analyses de disques) permettant de construire les signatures de leur reconnaissance ; Lancez une recherche à large échelle de ces IOC au sein du SI (n.b. des outils d automatisation des recherches vous seront nécessaires pour plus d efficacité) ; Menez les investigations avec des «comptes jetables» (n.b. comptes qui pourront aisément être supprimés pour laisser place à de nouveaux et ainsi éviter la diffusion de l attaque) ; 1 Le CERT-Solucom développe l outil «MI6» (pour Micro Système d Information Sain) : un système d information autonome, à déployer à la demande et tenant dans une simple valise ; il propose les services primordiaux pour gérer une cellule de crise : DHCP, DNS, LDAP, pare-feu, webmail, chiffrement, ftp, sftp, wiki, etc. La Lettre CERT-Solucom N 4 janvier

4 Procédez à des changements fréquents des mots de passe ; Centralisez et conservez les informations sur l attaque et les éléments d investigation dans un endroit sûr (n.b. évitez donc à tout prix votre système d information!) : hypothèses prises, faits observés, actions réalisées, logiciel malveillant, MD5, listes de comptes, adresses d exfiltration, adresses de serveurs Command and Control (C&C), etc. ; Contactez les réseaux d experts externes pour avis, compréhension de l étendue et sollicitation sur la menace identifiée (ANSSI, réseaux de CERT, etc.) ; Conduisez une analyse des logiciels malveillants et envisagez la sollicitation de prestations externes pour la mener ; Enfin, respectez au maximum le principe de discrétion absolue dans vos actes ; rappelez-vous qu une fois l attaquant alerté, il vous sera très difficile d être pertinent dans votre plan de défense et dans votre compréhension de l attaque. Tout au long de cette période d investigation, vous devez vous réunir régulièrement en salle de crise afin de valider, infirmer ou encore modifier tous les faits récoltés : l incident de sécurité est-il définitivement confirmé? S agit-il bien d une APT? Le périmètre que l on pensait infecté est-il le seul à l être? etc. Pour autant, ne vous réunissez pas inutilement ; si aucune avancée significative n a été préalablement constatée, mieux vaut se laisser du temps. Ces points réguliers vous permettent également de réaliser, sur la base des connaissances apportées par les investigateurs, deux tâches cruciales : La construction d une timeline de l attaque : elle illustre la compréhension du cheminement de l attaque, de sa cinématique, de sa propagation et de sa finalité (cible potentielle). On devra alors y trouver, par ordre chronologique, les informations sur l attaquant (adresses IP, serveurs C&C, etc.), les vecteurs d infection, les périmètres touchés, les vecteurs de propagation, etc. Réaliser votre timeline sur papier ou sur tableau blanc n est pas suffisant. Il est important d avoir également une version numérique à sauvegarder régulièrement qui vous permettra d y inclure tous les détails sur votre compréhension de l attaque. Par ailleurs, posséder des squelettes de timeline prêts à être remplis vous fera gagner en efficacité. La construction d un plan de défense : il rassemble notamment l ensemble des contremesures à mettre en place pour éradiquer l attaque sur les périmètres infectés. Ce dernier devra a minima préciser les actions d endiguement et d éradication à mener à court terme, moyen terme et idéalement long terme, énumérer les ressources qui devront mener ces actions et enfin permettre de connaître à tout moment la chronologie d exécution et l état d avancement de ces actions. Pour atteindre cet objectif, vous devez notamment prévoir : La définition de points de contrôle pour mesurer l efficacité des actions de défense ; L évaluation de l impact de chaque mesure du plan de défense ; L éventualité de mettre en œuvre des mesures de fonctionnement en mode dégradé (si besoin est) ; La réalisation de points de situation avec les responsables des périmètres infectés afin : - D arbitrer la conduite d actions d endiguement immédiates (exécution partielle du plan de défense) si la criticité de la ressource le permet, - De valider la pertinence des actions liées aux périmètres en question. Par ailleurs, vous devez continuellement rester vigilant. Chaque actif critique doit être mis sous surveillance renforcée afin d être certain qu il ne soit pas impacté par l attaque ; auquel cas, le «bouton rouge» devra être enfoncé sans délai Le moment capital : la «bascule»! Exécutez votre plan de défense La décision de «basculer» est certainement la plus complexe à prendre dans une gestion de crise APT. En effet, quand devez-vous ralentir vos investigations pour déclencher votre plan de défense? À quel moment autorisez-vous le fait d être détecté par l attaquant? Il n y a malheureusement pas de réponse universelle à ces questions. En revanche, deux autres interrogations doivent être étudiées : Avez-vous reçu la confirmation qu un ou plusieurs de vos actifs critiques semblent avoir été impactés d une manière ou d une autre (i.e. présence d IOC, activité illégitime, source d exfiltration avérée, présence de logiciels malveillants ou fichiers suspicieux, etc.)? Les résultats de vos investigations vous ont-ils permis d accumuler assez de connaissances sur l attaque pour pouvoir compléter la timeline explicative de manière la plus exhaustive possible, et ainsi construire un plan de défense en adéquation? Les retours d expérience montrent alors que si vous répondez positivement à l une de ces deux questions, vous devez alors être prêt à basculer dans les plus brefs délais. Une fois la décision prise, vous devez exécuter votre plan de défense. Toutes les actions doivent donc être lancées, chacune possédant : Une priorité d exécution : - «Immédiate et court terme» : ces actions sont urgentes et/ou rapides à exécuter. Souvent efficaces, elles doivent être exécutées dès le lancement du plan de défense (e.g. fermeture de ports ou de flux, désactivation des comptes illégitimes ou compromis, suppression de fichiers, d exécutables ou de services, etc.). - «Moyen terme» : ces actions forment le cœur du plan de défense. En effet, là où les actions immédiates corrigent brutalement et temporairement, les actions «moyen terme» vont s intéresser au fond du problème. Elles restent urgentes 4 La Lettre CERT-Solucom N 4 janvier 2015

5 mais nécessitent plus d investissement pour être menées à bien (e.g. désinfection des actifs contaminés, révision des privilèges, modification d une politique de sécurité, mises à jour et application de correctifs, etc.). - «Long terme» : dans la lignée des actions moyen terme, les actions long terme ne peuvent pas être exécutées immédiatement. Elles nécessitent effectivement une réflexion non négligeable, peut-être même le lancement d un projet. Elles peuvent avoir un lien direct avec l attaque mais également faire suite à une mauvaise pratique discernée au cours de la gestion de crise (profils administrateurs trop laxistes, réseaux trop peu segmentés, etc.). Un impact : qu il soit «faible», «modéré» ou «significatif», il devra être cadré. Pour ce faire, vous ne devez pas négliger la communication auprès des populations touchées. Le périmètre de cette communication dépendra notamment des décisions que vous prendrez quant à la communication interne de l incident.vous devez notamment les prévenir pour coordonner l activation des solutions de fonctionnement en mode dégradé. Vous pouvez également envisager l ouverture d un «numéro support 24/7» pendant une période fixée. Afin que votre plan puisse se dérouler dans de bonnes conditions, veillez à la disponibilité de chaque porteur d action et, éventuellement, associez-leur un suppléant. Ils devront être choisis en adéquation avec leur domaine de compétences et des périmètres qu ils traitent au quotidien. Afin d assurer une exécution du plan sans interruption, une disponibilité 24/7 peut également être envisagée à l image de la période d investigation. Surveillez les points de contrôle des actions de votre plan de défense ; Réitérez encore les recherches «à froid» d indicateurs de compromission sur les derniers journaux d évènements en date et sur les périmètres que vous n aurez pas encore pu traiter. Restez donc à l écoute encore quelques temps mais n oubliez pas, vous ne serez potentiellement jamais en mesure de vous assurer de l éradication totale et certaine de l attaque. Votre méfiance «postcrise» doit donc subsister, mais rester mesurée et ne pas devenir une perte de temps. Qui plus est, une nouvelle intrusion est peut-être déjà en cours ailleurs sur votre SI Par ailleurs, les périmètres à assainir doivent recevoir une attention particulière mise sous surveillance renforcée afin de s assurer de l efficacité des actions. Plus globalement, des indicateurs (points de contrôle) doivent être définis et mis en place pour être en mesure de confirmer chaque mesure réalisée et vérifier par la suite leur maintien : un retour négatif sur un point de contrôle peut laisser présager que l attaquant a réussi à reprendre des positions dans le SI. Suivez de près les échéances de vos actions immédiates, court et moyen terme afin de valider la fin de votre plan de défense. Retrouvez une situation nominale Excepté les inévitables imprévus vous empêchant d appliquer l ensemble des mesures, votre plan de défense semble avoir été exécuté avec succès. Avant de pouvoir prendre le recul nécessaire et tirer de cette expérience l ensemble des axes d amélioration envisageables, il est temps pour vous de débuter votre retour à la normale. En coordination avec les Métiers, vous pouvez alors organiser la réouverture, étape par étape, des services interrompus ou dégradés durant la crise. N oubliez également pas de communiquer auprès de l ensemble des acteurs sollicités (internes ou externes). La cellule de crise peut alors progressivement être dissoute, pour autant, restez sur vos gardes ; notamment : Dès la fin de votre plan de défense, n annoncez pas précipitamment la fin de crise à tout le monde ; chacun pourra ainsi garder un niveau de vigilance accru ; Continuez à surveiller les périmètres affectés et/ou reconstruits ; Gardez un œil sur l extérieur grâce à vos veilles externes ; La Lettre CERT-Solucom N 4 janvier

6 Dossier CERTitude - Simplifier les campagnes de recherche d IOC Lors de ses interventions, le CERT-Solucom est fréquemment confronté au besoin d évaluer le périmètre de compromission du système d information victime. L enjeu est d évaluer de la manière la plus précise possible l étendue de l attaque sur le SI. De plus, au travers de sa stratégie de diffusion de marqueurs / indicateurs de compromission (IOC), l ANSSI peut demander la réalisation de campagnes de recherche aux entreprises. Cependant, aujourd hui peu d outils permettent de mener ce type de campagnes, et l ANSSI ne propose pas encore de méthodologie pour les réaliser. Malgré de nombreuses contraintes à traiter (de la compatibilité avec tous les systèmes Windows aux impacts sur les performances, en passant par la non-divulgation des IOC recherchés sur les périmètres a minima Diffusion Restreinte), CERTitude acquiert petit à petit la capacité de rechercher de plus en plus de types d IOC différents, le tout sans nécessiter d agent à déployer sur les postes et serveurs à scanner. Aujourd hui, l outil CERTitude a pu être testé avec succès à l échelle d une centaine de postes sur le SI interne de Solucom. Face à ces constats, le CERT-Solucom a alors entrepris la conception d un outil permettant de mener des campagnes de recherche et d évaluer le périmètre de compromission d un SI. Cet outil, baptisé CERTitude, s appuie sur des IOC fournis en entrée pour effectuer un scan de l ensemble du parc serveurs et postes de travail à la recherche de ces IOC. 6 La Lettre CERT-Solucom N 3 janvier 2015

7 Fonctionnement général CERTitude est un programme écrit en Python dont le but est de rechercher des marqueurs comportementaux sur un ensemble de postes de travails et serveurs : Les scripts de collecte sont donc déployés sous l une des trois formes suivantes : Un script Batch, reposant sur les exécutables Windows présents sur tous les systèmes pris en compte. Un script Bash, interprété par une version portée de Bash depuis Linux, reposant sur les exécutables Windows du système ainsi que des utilitaires portés depuis Linux (grep, cut, find, etc.). Un exécutable compilé sous Windows XP 32-bits (afin de profiter de la rétrocompatibilité) reposant sur des appels à l API Windows. Figure 1 : Vue d ensemble sur le fonctionnement de CERTitude Détails des technologies utilisées Format OpenIOC Les IOC sont fournis au format OpenIOC. Créé par MANDIANT sur la base du XML, ce format propose deux avantages quant à la gestion des indicateurs : Les IOC sont divisés en catégories 1 de marqueurs comportementaux, permettant alors rapidement de différencier quel type d élément est à rechercher : services, processus, fichiers, etc. Les IOC sont positionnés dans un arbre logique afin de décrire le plus finement possible le comportement observé. SMB et RemCom service Le choix du travail sans agent a entraîné la nécessité d exécuter des commandes sur un poste distant. De plus, seules les applications déjà présentes sur le poste cible et en écoute peuvent être utilisées. La solution adoptée a donc été de reposer sur le protocole SMB pour le transfert de fichiers. L utilisation de PSExec 2 a été considérée dans un premier temps puis abandonnée. En effet, PSExec déploie un service sur la machine distante avec lequel il communique pour envoyer les commandes à exécuter et en récupérer le résultat. Cependant, tout le processus de mise en place du service, de communication avec ce dernier puis de sa suppression est mis en œuvre à chaque commande effectuée. Une version Python de PSExec, psexec.py, a été développée et est présente dans le module Python impacket. Cette version repose sur un équivalent open-source du service déployé par PSExec, mais possède le même défaut de multiples connexions. Partant de cette version, le module RemoteCmd a été écrit en Python, reprenant les mêmes bases que psexec.py, mais avec quelques améliorations de performance, notamment pour permettre d effectuer une série de commandes sans redéployer le service à chaque fois. Détails du fonctionnement Figure 2 : Exemple d arbre logique décrit par OpenIOC Langage Python CERTitude est écrit en Python. Ce langage a été choisi pour sa modularité, sa facilité de compréhension, et son aspect multiplateformes. Chaque module de traitement (collecte et analyse) est donc en réalité un module Python dérivé d une interface, et chargé par CERTitude. Scripts de collecte Des scripts de collecte sont déployés sur les cibles à analyser afin de récupérer la liste exhaustive des éléments (e.g. «ProcessName») d une certaine catégorie (e.g. «ProcessItem»). Afin de répondre à la contrainte de fonctionnement sur une majorité de systèmes d exploitation Windows, des technologies adaptées ont dû être sélectionnées. 1 Liste complète disponible à l adresse suivante : Analyse des IOC en entrée Les indicateurs de compromission sont fournis à CERTitude au format OpenIOC. La première étape consiste à traduire ces indicateurs en une structure Python, IOCTree, plus adaptée à la gestion de l arbre logique véhiculé par OpenIOC. La traduction est effectuée par un dérivé de XML Etree, un module Python servant à passer les fichiers au format XML. CERTitude parcourt ensuite les différents éléments de type IOCTree afin de récupérer les catégories d éléments recherchés : ArpEntryItem, ServiceItem, PrefetchItem Pour chacune de ces catégories, deux cas se présentent : Soit CERTitude possède un module permettant de collecter les entités de cette catégorie. Soit cette catégorie ne peut pas être traitée par CERTitude, et le marqueur correspondant se voit attribuer à l avance le résultat Undefined pour toutes les cibles. 2 Développé par SysInternals, désormais appartenant à Microsoft iocterms La Lettre CERT-Solucom N 4 janvier

8 Dans la plupart des cas, CERTitude est instancié avec une liste d IOC construits manuellement : En prévention : par le retraitement des marqueurs communiqués par l ANSSI ou par l établissement d IOC à partir d une veille sécurité. En réaction : dans le cadre d une intervention de réaction sur incident, la première étape est d effectuer une analyse forensics sur un poste compromis afin d en identifier des IOC à rechercher sur l ensemble du SI. Établissement de la connexion vers les différentes cibles Le programme lit ensuite la liste des cibles à analyser, et construit un pool de cibles à traiter en parallèle. La taille de ce pool est réglable via les arguments fournis à CERTitude et permet de réaliser un compromis entre vitesse de l analyse et surcharge des ressources réseau. Chaque cible possède l un des statuts suivants : «à traiter», «en traitement» ou «traitement terminé». Pour chacune des cibles «à traiter», un répertoire de travail est choisi de la manière suivante : Le programme tente de se connecter via le protocole SMB sur le port 445 de la machine distante avec les identifiants fournis. Si la cible ne peut être contactée ou que les identifiants fournis sont invalides, elle acquiert le statut «traitement terminé» et une erreur est remontée. La liste des partages réseaux est récupérée via l interface SRVSVC et pour chaque partage : CERTitude tente de créer un dossier dans le répertoire partagé. - Si la tentative d écriture se conclut par un échec, l opération est répétée sur le partage réseau suivant. - Dans le cas contraire, ce partage réseau est sélectionné comme répertoire de travail. Si aucun partage réseau n a pu être sélectionné, la cible passe au statut «traitement terminé» et une erreur est remontée. Collecte des données Pour chacune des catégories de marqueur identifiées que CERTitude est en mesure de rechercher, un script de collecte 3 est copié dans le répertoire de travail de la cible. La commande permettant de lancer la collecte est ensuite envoyée au service RemCom et les résultats sont stockés par les scripts dans un fichier TSV 4. Ce fichier est ensuite importé dans une base de données SQLite distante à l aide d une simple requête SQL. Analyse des données 1) Analyse en mode «plat» Lors d une analyse en mode «plat», les marqueurs de l arbre logique sont considérés comme étant totalement indépendants les uns des autres. Pour chacun des marqueurs : La catégorie de marqueurs à laquelle il appartient est identifiée. Une requête SQL correspondant à ce marqueur est exécutée sur la base de données des éléments de cette catégorie. Le résultat de la présence du marqueur est renvoyé au poste de l investigateur. Le rapport est alors présenté à l investigateur sous la forme d un arbre dont les feuilles se voient assigner le nom du marqueur recherché et l une des valeurs suivantes : True : le marqueur est présent sur la cible. False : le marqueur est absent de la cible. Undefined : le marqueur n a pas pu être recherché sur la cible. 2) Analyse en mode «logique» Lors d une analyse en mode «logique», l indicateur de compromission est complètement évalué et les résultats de présence des marqueurs reliés entre eux. Pour ce faire, la première étape consiste à supprimer les marqueurs marqués Undefined. Déploiement du service de commande à distance Une fois le répertoire de travail choisi, l exécutable RemCom compris dans PSExec est copié (via SMB) dans ce répertoire. CERTitude contacte ensuite le Service Control Manager de la machine distante par le biais de l interface SVCCTL afin d enregistrer l exécutable déposé en tant que service. Ce dernier est ensuite lancé avec les autorisations du compte «Système» et trois canaux nommés (stdin, stdout et stderr) sont créés sur la cible pour communiquer avec le service. La seconde phase consiste à effectuer des opérations logiques sur l arbre (sans en changer la signification) de telle manière à n avoir qu une seule catégorie d éléments à rechercher sous un nœud de l arbre. Pour chacun de ces groupes de marqueurs : Une requête SQL combinant la recherche des différents marqueurs y appartenant est exécutée sur la base de données de la catégorie correspondante. Le résultat de la requête est remonté au poste de l investigateur. La structure logique de l arbre est ensuite utilisée pour combiner tous les résultats de présence. Le rapport présenté à l investigateur est une simple valeur booléenne : True : l IOC est présent sur la cible. False : l IOC n est pas présent sur la cible. 3 Voir la partie suivante sur les modules de collecte 4 Tabulation Separated Value 8 La Lettre CERT-Solucom N 4 janvier 2015

9 Fin de la campagne de recherche Lorsqu une cible acquiert le statut «traitement terminé», toute trace de CERTitude y est supprimée (i.e. les fichiers déposés par CERTitude sont supprimés, de même que le service créé : néanmoins les informations permettant de tracer les évènements sont conservées : les logs, les prefetchs, etc.). Elle est retirée du pool des cibles, et la cible suivante prend sa place. 2) Collecte La collecte de ces données se fait via un script Batch et un appel à la commande Windows arp : Dès lors qu il ne reste plus de cible à rajouter dans le pool, la campagne de recherche est terminée, et les résultats sont remontés à l investigateur, sous l un des formats suivants : Directement dans la console, Dans un fichier texte dans le dossier de sortie des résultats. Dans ce cas, les cibles n ayant pu être contactées possèdent un underscore «_» au début du nom de fichier. Les modules de collecte à la loupe Structure générale Chacun des modules de collecte est constitué : D un script réalisant la collecte des données. D un ensemble de requêtes SQL permettant de réaliser l import dans la base de données SQLite. Figure 4 : Collecte des entrées du cache ARP DnsEntryItem Entrées du cache DNS Cette catégorie rassemble les entrées du cache DNS, à savoir la base locale qui établit la correspondance entre un nom de domaine et une adresse IP. Cette base évolue au fur et à mesure des réponses aux requêtes DNS. 1) Paramètres recherchés Le script réalisant l import est classiquement sous le format suivant Tableau 2 : Paramètres recherchés pour DnsEntryItem 2) Collecte La collecte de ces données se fait via un script Batch et un appel à la commande Windows ipconfig /displaydns : Figure 3 : Exemple de script réalisant l import Rappel : les scripts de collecte sont écrits en Batch, Bash ou C. Liste des modules de collecte (ordre alphabétique) ArpEntryItem Entrées du cache ARP Cette catégorie rassemble les entrées du cache ARP, à savoir la base locale qui établit la correspondance entre une adresse IP et une adresse physique (MAC). Cette base évolue au fur et à mesure des réponses aux requêtes ARP. Il est également possible de rajouter une entrée statique au cache ARP. 1) Paramètres recherchés Figure 5 : Liste des enregistrements DNS FileItem Fichiers présents sur le disque 5 Les marqueurs de cette catégorie concernent les attributs des fichiers présents sur le disque. A l heure actuelle, CERTitude n est pas encore en mesure de filtrer les fichiers sur tous les attributs proposés par le format OpenIOC. 5 Liste des correspondances à cette adresse : List_of_DNS_record_types Tableau 1 : Paramètres recherchés pour ArpEntryItem La Lettre CERT-Solucom N 4 janvier

10 1) Paramètres recherchés 2) Collecte La collecte de ces données se fait via un script Batch et un appel à la commande Windows netstat : Tableau 3 : Paramètres recherchés pour FileItem 2) Collecte La collecte des attributs des fichiers doit être faite sur tous les disques de l utilisateur. Pour cela, le script de collecte écrit en Batch récupère dans un premier temps la liste des partitions de l utilisateur : Figure 6 : Liste des partitions Ensuite, sur chaque partition, le programme récupère la liste des fichiers qui y sont présents grâce à la commande Windows dir : Figure 9 : Collecte des connexions réseau PrefetchItem Données du prefetch Dans le contexte d un système d exploitation Windows, lorsqu un programme est exécuté, une trace de cette exécution est gardée sur le disque afin d accélérer une exécution future du même programme. Ces données sont présentes dans le dossier C:\WINDOWS\Prefetch sous un format propriétaire 6 et permettent de découvrir certaines informations concernant les dernières exécutions du programme. 1) Paramètres recherchés Figure 7 : Liste récursive des fichiers d une partition À la fin de cette étape, seuls les chemins d accès complets aux fichiers sont récupérés. Cependant, les autres paramètres recherchés par CERTitude peuvent être directement dérivés de ce dernier, et ne sont donc calculés qu à l insertion dans la base de données : Tableau 5 : Paramètres recherchés pour PrefetchItem 2) Collecte Aucun exécutable Windows ne permettant de réaliser l analyse du fichier Prefetch, un programme en C a été écrit pour accomplir cette tâche. Ce dernier est capable de récupérer tous les paramètres recherchés par CERTitude à l exception du paramètre FullPath : Figure 8 : Calcul des paramètres manquants en SQL PortItem Connexions réseau Cette catégorie de marqueurs concerne les connexions réseau, établies ou non, de la cible. Cela peut être utile pour détecter des ports anormalement ouverts ou des connexions en cours vers des adresses IP connues pour être utilisées à des fins malveillantes. 1) Paramètres recherchés Figure 10 : Analyse du fichier Prefetch Ce dernier est récupéré grâce à la liste des chaînes de caractères Unicode présente dans le fichier Prefetch : Figure 11 : Récupération du chemin d accès au programme La collecte de tous les paramètres est donc conduite par un script Batch qui repose sur le programme écrit en C. 6 6 Analysé et décrit à cette adresse : Windows_Prefetch_File_Format Tableau 4 : Paramètres recherchés pour PortItem 10 La Lettre CERT-Solucom N 4 janvier 2015

11 RegistryItem Données du registre Cette catégorie rassemble les données présentes dans la base de registre de la cible. Celles-ci sont réparties entre cinq ruches (HKCU, HKLM, HKCR, HKU, HKCC), et ordonnées en dossiers (appelés «clés») et fichiers (appelés «valeurs»). Le contenu de ces «valeurs» est appelé «données». 2) Collecte La majorité de ces informations peuvent être récupérées grâce à la commande Windows sc : CERTitude n est pas encore capable d effectuer une recherche dans les «données» de la base de registre. 1) Paramètres recherchés Figure 13 : Détails d un service Windows Tableau 6 : Paramètres recherchés pour RegistryItem 2) Collecte La collecte n a pu être réalisée à l aide d un script Batch ou Bash. En effet, les exécutables Windows permettant de communiquer avec la base de registre ne fournissaient pas une sortie exploitable par un tel script. Un programme a donc été développé en C pour extraire les paramètres recherchés de la base de registre : Le hash MD5 du binaire associé au service a été récupéré grâce à une version portée sous Windows de md5sum. Le script de collecte n a cependant pas pu être écrit en Batch en raison des nombreuses erreurs que provoquent les guillemets doubles dans ce langage. Il a donc été développé en Bash. Roadmap CERTitude CERTitude est un outil open-source distribué sous licence GPL. Le projet continue d être amélioré et renforcé au gré des besoins rencontrés par le CERT-Solucom. Une priorisation des besoins a été réalisée afin de définir une roadmap du projet. Lors de la rédaction de cet article, la roadmap se présente comme suit : Figure 12 : Export des clés et valeurs du registre ServiceItem Liste des services Les marqueurs de cette catégorie concernent les services, en exécution ou non, présents sur la cible. L intérêt d une telle catégorie réside dans le fait que la majorité des services sont automatiquement lancés avec les droits de l utilisateur «Système», c est-à-dire sans aucune limitation. 1) Paramètres recherchés Figure 14 : Roadmap CERTitude Tableau 7 : Paramètres recherchés pour ArpEntryItem CERTitude est un outil opensource publié par le CERT-Solucom sur son github : github.com/cert-solucom/certitude. N hésitez pas à contacter le cert@solucom.fr pour échanger sur cet outil (bug, suggestion d amélioration, etc.) La Lettre CERT-Solucom N 4 janvier

12 Annexe : CERTitude en images Lancement de CERTitude CERTitude accepte différents arguments en entrée à l exécution dont la liste est fournie par la commande python certitude. py --help : Figure 17 : Exemple de résultats présentés par CERTitude Figure 15 : Commande «usage» de CERTitude CERTitude en action La capture d écran ci-dessous montre un extrait de la sortie de CERTitude : Version IHM (bêta) Une interface graphique est en cours de développement. Elle présentera les résultats sous une forme proche de la suivante : Figure 18 : Exemple de résultats avec une version bêta de l IHM Figure 16 : Extrait de la sortie standard en verbosité maximale CERTitude Cette recherche a ciblé trois postes, dont deux éteints ou non joignable. Un seul IOC a été recherché. La recherche s est effectuée via un pool de trois postes. Exemple de résultats Version actuelle La capture d écran ci-après montre un exemple de sortie de CERTitude correspondant à l exemple de la sous-partie précédente : 12 La Lettre CERT-Solucom N 4 janvier 2015

13 Dossier Best-of des conférences Black Hat Europe, NoSuchCon et Botconf 2014 BLACK HAT EUROPE 2014 Lights off! The darkness of the Smart Meters Cette conférence avait pour sujet la sécurité des systèmes embarqués et plus particulièrement des compteurs intelligents (smart meters). Ceux-ci facilitent les opérations à distance et permettent d adapter la production électrique à la demande en temps réel. Ce type de compteur est en cours de déploiement dans la plupart des pays européens ; en France, le compteur intelligent Linky devrait équiper 35 millions de foyers d ici Ces compteurs intelligents peuvent être accessibles à distance en utilisant les lignes électriques (PLC : Power Line Communication) et recevoir des commandes, ou servir de relai pour transmettre des commandes à d autres compteurs environnants. L analyse d un compteur intelligent déployé en Espagne a permis d identifier l utilisation de composants standards, dont la plupart des données les concernant sont disponibles sur Internet. Dans ces compteurs intelligents, de nombreux mécanismes de sécurité sont absents. Par exemple, la fonctionnalité de débogage SWD (Serial Wire Debug) est activée, permettant ainsi de modifier le firmware et de déboguer en temps réel simplement en se connectant physiquement sur un port série présent à l intérieur du compteur. Plusieurs attaques ont pu être réalisées par les chercheurs Alberto Garcia Illera et Javier Vazquez Vidal. Une démonstration a montré qu il était possible de modifier le contenu d une puce mémoire permettant ainsi de désactiver une alarme qui se déclenche en cas d ouverture du compteur. De même, la valeur de la clé AES permettant l échange de données sur le réseau peut aussi être lue. Cette clé est identique pour l ensemble des compteurs. Sa connaissance permet l envoi de commandes arbitraires aux compteurs. Un scénario d attaque présenté consistait en la reprogrammation distante des compteurs et la propagation de ce code tel un ver sur le réseau électrique, par exemple pour couper le courant à l ensemble de la population. Cette conférence souligne les problèmes liés aux objets connectés en général, et les compteurs intelligents ne font pas exception. Des vulnérabilités classiques, connues depuis des années sont trivialement exploitables. Espérons que les travaux présentés ici aient été pris en compte et que les futures générations de compteurs soient plus robustes! Hack your ATM with friend s Raspberry Pi Les intervenants ont voulu savoir à quel point il était difficile d accéder à l intérieur d un distributeur automatique de billets. Ils ont commencé par en acheter un (apparemment, il suffit de connaitre les bonnes personnes). Un ATM a deux zones principales : une zone de service où est installé l ordinateur et où les opérations de maintenance sont faites et une zone «safe» qui contient le coffre où est stocké l argent. Habituellement, la zone de service est protégée par une couverture plastique et une simple serrure. Le coffre est lui en acier et comporte deux types de serrure. Il est possible de crocheter la serrure facilement et d introduire un Raspberry Pi directement dans le distributeur de billets. Le Raspberry Pi est connecté à l ordinateur et est accessible à distance. Dans le cas étudié, l ordinateur qui gère le distributeur est un PC standard sous Windows XP, sur lequel aucune mise à jour n est installée. Il est possible d exploiter des failles connues s il existe un accès réseau. Grâce à des informations recueillies sur Internet, Alexey Osipov et Olga Lochetova ont réussi à comprendre le protocole utilisé pour dialoguer avec le coffre-fort et ainsi à déclencher la distribution d argent. Pour résumer, l attaque est moins alambiquée qu elle ne le laisse penser et peut rapporter gros. En effet, cette dernière est plutôt difficile à réaliser pour les distributeurs encastrés mais certains, notamment à l étranger, sont isolés dans des cafés ou des boutiques et sont alors facilement attaquables. D autre part, Windows XP n est pas prêt de disparaitre. Certaines banques ont contracté des supports étendus pour encore plusieurs La Lettre CERT-Solucom N 4 janvier

14 années. Désormais, il s agit de continuer à mettre à jour régulièrement ces systèmes car les vulnérabilités exploitées sont très souvent celles issues de systèmes non mis à jour. Firmware.re : unpacking, analysis, and vulnerability discovery as a service La dernière conférence de la journée a été l une des plus intéressantes : «Firmware.re: unpacking, analysis, and vulnerability discovery as a service». La troisième partie était dédiée aux exercices : Un premier exercice sur Wireshark pour lire et comprendre les paquets Modbus Un deuxième exercice sur un simulateur d automate : lire et écrire dans des registres avec le script mbtget et le framework Metasploit Des exercices directement sur les automates de la maquette : reconnaissance avec nmap et plcscan, lecture et écriture dans des registres, connexion au serveur ftp et au serveur web, arrêt et redémarrage de l automate. Les systèmes embarqués sont partout et contrôlent de nombreux aspects de notre vie quotidienne (télévisions, GPS des voitures, portails automatiques, etc.). Le problème majeur est que l analyse de ces systèmes requiert beaucoup de temps et ne peut pas être faite manuellement à grande échelle. L idée de la recherche est de faire une analyse à grande échelle afin de voir si les systèmes embarqués possèdent les mêmes vulnérabilités. Cette analyse grande échelle n est pas facile car les systèmes embarqués ont des systèmes d exploitation et des architectures différentes et les enjeux de sécurité sont différents. La solution proposée par Jonas Zaddach et Andrei Costin est d automatiser les actions suivantes : Télécharger le firmware Faire une analyse statique basique Faire une corrélation avec les autres firmwares L avantage de cette analyse réside dans son caractère non intrusif. Elle peut être effectuée sur Internet et à grande échelle. Cependant, plusieurs challenges n ont pas encore été résolus. Le premier : comment obtenir le firmware? Tous les firmwares ne sont pas accessibles. Le second : comment les identifier? Comment détecter un firmware parmi des milliers de fichiers? Sur leur site web il est possible de soumettre un firmware qui sera extrait puis analysé. Un cracker de mot de passe est aussi disponible fichiers ont déjà été collectés et 1,7 million ont été extraits. Pour résumer, il s agit d un très beau projet, plutôt ambitieux. Une première étape a été franchie avec la possibilité d extraire de façon automatisée un firmware et d analyser ses différents fichiers. L objectif est de pouvoir détecter de nombreuses vulnérabilités ainsi que des backdoors. Nous avons hâte de voir la suite! Pentesting PLCs 101 La journée du vendredi s est achevée par le workshop d Arnaud Soullié, consultant sécurité de Solucom, sur les tests d intrusions sur automates : «Pentesting PLCs 101». Arnaud a commencé par présenter une introduction aux systèmes industriels: le réseau de production et de supervision, le vocabulaire, les différents composants. Il a présenté les différentes fonctionnalités des automates ainsi que la façon de les programmer. Il a également introduit Shodan, un outil permettant de trouver tous les objets connectés sur Internet. Dans une seconde partie, il est également revenu en détail sur le protocole Modbus, utilisé dans les automates Schneider. Bien que la sécurité des systèmes industriels fasse souvent la une des sites spécialisés, de nombreuses personnes ont du mal à appréhender la spécificité de ces systèmes et leurs vulnérabilités. Nous espérons avoir pu démystifier le sujet, et inciter les personnes présentes à lancer des actions de sécurisation! Les outils utilisés durant le workshop ainsi que les slides sont accessibles à l adresse suivante : introduction-to-industrial-control-systems-icsv11 No Such Con 2014 Surprise Talk, Unreal mode: Breaking the protected processs Cette conférence était détenue secrète pour la simple et bonne raison que l orateur a dû attendre le dernier moment pour recevoir le feu vert de Microsoft concernant la faille non patchée qu il a trouvée. Depuis Windows Vista de nouvelles protections ont été introduites au niveau noyau. Dans Windows 8.1, ces protections sont étendues pour protéger des processus clés intouchables par les administrateurs afin d éviter les attaques de type pass-the-hash. Ainsi un administrateur n a plus un accès total au système. L orateur a expliqué le fonctionnement des signatures numériques avec les nouvelles versions du système d exploitation. En effet cela dépend fortement de l appareil et des droits accordés. Sur des tablettes Surface de Windows, seuls les programmes signés par Microsoft peuvent être exécutés alors que sur un bureau classique de Windows on peut exécuter n importe quel programme. Cette configuration peut être modifiée directement en mettant en place un niveau de signature pour les droits d exécution (signature quelconque, signature Windows, signature WinTcb, etc.). L auteur a ensuite présenté les différents mécanismes de protection de services Windows, rendant par exemple impossible le dump en clair du processus LSASS. Ce processus est très convoité par les auditeurs car il contient les authentifiants en clair des utilisateurs courants sur la machine ciblée. Pour un processus protégé, le dump n est pas en clair mais chiffré. Néanmoins sur Windows, tout processus peut crasher : le gestionnaire de crash a pour rôle d écrire les informations de crash au sein d un fichier appelé MiniDump. Pour les processus protégés (par ex. LSASS), le gestionnaire de crash doit lancer une version de lui-même également protégée afin de pouvoir accéder en clair aux informations de crash : l idée est ainsi de forcer le crash de LSASS et d exploiter une faille qui permet de contrôler l écriture du MiniDump en clair afin de récupérer les authentifiants. 14 La Lettre CERT-Solucom N 4 janvier 2015

15 Le détail précis de la vulnérabilité permettant le contrôle de l écriture du fichier de crash n a pas été dévoilé et celle-ci va être corrigée en début d année L auteur a néanmoins développé un outil, pas encore diffusé publiquement, tirant parti de cette vulnérabilité. Detecting BGP hijacks in 2014 Cet exposé présentait les hijacks de routes BGP. Le protocole BGP est utilisé pour échanger des informations entre les différents réseaux AS (Autonomous Systems). Les AS utilisent ce protocole pour informer les réseaux IPs gérés. Il est donc important de faire confiance aux annonces reçues. De plus, le détournement de trafic à destination de réseaux est possible. On parle hijack pour décrire un conflit d annonce BGP, cela veut dire que les paquets sont volontairement ou non envoyés sur des réseaux non légitimes. Guillaume Valadon a effectué des analyses durant 1 an sur un trafic BGP pour détecter les usurpations de préfixes à l aide d une méthodologie et d outils open-source, dont Luigi ( qui est un ordonnanceur logiciel pour chainer des actions séquentielles. Le nombre d évènements suspicieux sur un trafic BGP est considérable, mais il est possible de le réduire afin d obtenir un nombre pertinent et traitable manuellement. Sur toute une année, 10 tentatives d usurpations contre des opérateurs français ont été détectées. Nicolas Vivet a présenté les modifications effectuées sur cette méthodologie et ces outils afin d effectuer des détections en temps réels. Une suspicion d usurpation d un préfixe IPv6 d opérateur français par un opérateur ukrainien s est révélée après être l inverse. En fait, l opérateur français avait oublié un zéro dans l adresse IPv6 qu il annonçait et était ainsi en train d hijacker l AS ukrainien. Tout trafic transitant sur Internet étant potentiellement redirigeable, les auteurs ont insisté sur l importance du chiffrement et de l authentification des flux. Les opérateurs doivent surveiller le trafic BGP portant sur leurs préfixes et être prêts à riposter. Des bonnes pratiques énoncées par l IETF sont disponibles et doivent être implémentées par les opérateurs pour palier ces risques. Enfin et suite à la séance de questions/réponses, les auteurs ont indiqué que le code de leur outil ne sera pas rendu open-source. Google Apps Engine security Cette conférence aborde le Google Apps Engine, une offre cloud de Google permettant la conception et l hébergement d applications Web (PaaS : Platform as a Service). Les défauts de sécurité liés à l utilisation de cette plateforme ont pu être présentés : Vulnérabilités Web (SQLI, XSS, CSRF, etc) liées aux erreurs effectuées par les développeurs. Il est à noter que certaines API comme urlfetch et socket ne sont pas sécurisées par défaut ; Infrastructure GAE. Les tests ne pouvant être faits en local, les développeurs ont des identifiants non distincts pour les produits en test et en production. Ainsi la compromission d une instance de test donne généralement accès à la production. En outre, une erreur classique consiste à stocker des identifiants de connexion (vers d autres applications) en dur dans le code des applications ; Des vulnérabilités liées à la sandbox utilisée par Google ont été dévoilées durant les démonstrations. Mimikatz Ce talk vient présenter les nouveautés de mimikatz, un outil favori pour les tests d intrusion sur les environnements Windows. La première partie rappelle les méthodes d authentification Windows ainsi que les attaques associées : Pass-The-Hash (NTLM) ; Pass-The-Ticket (Kerberos). La seconde partie a permis d introduire les notions de Golden Ticket et Silver Ticket et notamment leur génération : Golden Ticket : ticket d administration du domaine généré grâce au mot de passe du compte krbtgt; Silver Ticket : ticket spécifique à un service. La génération de ces tickets se fonde sur des clés symétriques en environnement Windows, qui ne sont autres que les condensats NTLM des mots de passe, notamment du compte krbtgt. Une fois générées, ces clefs ne changent jamais pour des années (modification unique lors de la mise à jour du domaine fonctionnel : NT5 ==> NT6). Benjamin a re-présenté ses dernières découvertes concernant la gestion des PAC (Privilege Attribute Certificate). Ces PAC contiennent les informations d autorisation (notamment les groupes auxquels appartient l utilisateur) et font partie du ticket Kerberos. Ces informations sont signées avec la clé du compte krbtgt. C est donc le contrôleur de domaine qui doit valider cette information. Cependant, pour des raisons de performances, cette vérification sera souvent ignorée. On peut donc créer un ticket de service (TGS, Ticket Granting Service) uniquement à partir du mot de passe de la machine cible. Ce mot de passe restant valable 30 jours, et le mot de passe n-1 étant également accepté, on peut créer un ticket valable 60 jours sur un serveur cible. Les informations présentes dans le ticket étant modifiables arbitrairement, on peut se connecter avec n importe quel compte, même un compte qui n existe pas! Enfin, une nouvelle attaque a été présentée, Pass-The-Cache. Elle consiste à extraire et réutiliser les tickets Kerberos de systèmes Ubuntu ou Mac OS X accédant au domaine Windows afin d usurper l identité des utilisateurs de ces systèmes. La Lettre CERT-Solucom N 4 janvier

16 Botconf 2014 Keynote UK National Crime Agency on botnet takedowns : Our GameOver Zeus Experience Après une courte introduction d Eric FREYSSINET, responsable de la lutte contre la cybercriminalité au pôle judiciaire de la gendarmerie nationale et organisateur de la Botconf, les deux conférenciers ont présenté ce qu un agent des forces de l ordre lambda connait d un botnet : «De l argent va de ma banque vers le compte d un cybercriminel». Stewart GARRICK a expliqué que cette méconnaissance vient du fait que les cybercrimes évoluent dans un environnement 2D alors qu un meurtre classique se passe en 3D. Communiquer sur le sujet est donc un facteur clef. Stewart a alors présenté les actions entreprises par le NCA en termes de communication : Transmission d une note auprès de tous les agents de la police britannique expliquant ce qu est un botnet. Multiples interventions dans des shows TV. Présence importante dans les journaux nationaux (les tabloïds britanniques affichaient des titres comme «Two weeks to save your computer»). Création de la page getsafeonline.org/nca, initiative visant à conseiller le public dans la protection de leur ordinateur contre Cryptolocker et GameOver ZeuS. Le public a montré des réponses très positives suite à ces actions : Réduction notable du nombre d adresses IP britanniques faisant partie des botnets derrière Cryptolocker et GameOver ZeuS. Téléchargement massif d antivirus. Victime de son succès, getsafeonline.org/nca est indisponible quelques minutes après sa mise en ligne. Les orateurs ont ensuite présenté quelques faits sur Cryptolocker : c est une menace visible, l utilisateur sait quand il est infecté. Le Domain Generation Algorithm (DGA) utilisé est connu et prévisible : 1000 domaines sont générés par jour et distribués sur sept Top Level Domains (TLD). Quant à GameOver ZeuS, il s agit d un cheval de Troie silencieux et le DGA utilisé génère 1000 domaines par semaine et sont distribués sur six TLD. Le démantèlement des botnet derrière ces deux logiciels malveillants a été mené en une fois mais différentes approches ont été prises selon les juridictions des TLDs :.com,.net,.org.biz &.info : décision de justice aux États-Unis obligeant 4 registres de noms de domaine à mettre en place des sinkhole..co.uk : Nominet a décidé de faire une revue manuelle..ru : le NCA a réservé plus de domaines en.ru (pour environ ) qui allaient être générés par le DGA et ainsi «paralyser» le botnet de cryptolocker pendant environ deux semaines. Des décisions de justice aux États-Unis ont aussi obligé vingt FAI à bloquer les domaines générés par les DGA. Certains fournisseurs de services DNS ont pris des mesures pour bloquer les domaines malveillants. Particularité cependant pour traiter le botnet en P2P de GameOver ZeuS : Dell SecureWorks est intervenu pour lancer une attaque par rejeu en diffusant un broadcast sur le réseau P2P pour rediriger tous les nœuds vers un sinkhole. C est donc via une action coordonnée avec l industrie et des acteurs inter-états qu il a été possible de démanteler de tels botnets. Les conclusions : Il est nécessaire de comprendre comment fonctionne le business model derrière les botnets, de réaliser une cartographie de leur infrastructure, partager et se coordonner entre acteurs de la lutte contre la cybercriminalité. Les médias ont une grande emprise sur les utilisateurs finaux. Il faut pouvoir exploiter ces canaux de communication pour sensibiliser le public. Faire passer un message fort : «We need each other (security researchers & law enforcement)». Et pour le futur, mis à part une meilleure coopération entre acteurs, les conférenciers ont introduit le concept intéressant de «Registrar of Last-Resort» qui consiste essentiellement en un registrar mutualisé et de confiance pour y neutraliser les domaines malveillants et en garder le contrôle. VirusTracker : Challenges of running a large scale sinkhole operation Peter Kleissner a présenté l outil VirusTracker développé par son entreprise Kleissner&Associates. C est un outil de surveillance pour botnet. Le confériencier a expliqué les challenges d une opération de sinkhole à grande échelle. Depuis septembre 2012, l entreprise de Peter fait du sinkholing en récupérant les noms de domaines utilisés dans les communications C&C de divers botnets. Le but est de : Générer des statistiques comme la taille du botnet ou la distribution géographique sur le long terme. Détecter les changements / évolutions des botnets. Alerter les organisations infectées. Peter a ensuite donné quelques chiffres sur les statistiques actuelles : Le système détecte aujourd hui près de 3,3 M de machines uniques infectées par jour (ils disposent de plus d un milliard de logs d infection dans leur base de données). Le système présente plus de 7000 domaines neutralisés par sinkhole. Quant aux challenges d un tel dispositif, le conférencier a mis en avant les points suivants : La saisie des domaines malveillants par les autorités. Les plaintes formulées à l encontre des serveurs et des domaines de l entreprise considérés comme malveillants. Le coût des domaines (en moyenne 7,3 USD par domaine) et peu de budget derrière. Autres problématiques techniques : la volumétrie des données à traiter, l hétérogénéité des botnets qui utilisent différents protocoles, les difficultés pour déduire des statistiques avec les botnets mobiles et ceux derrière des NAT. 16 La Lettre CERT-Solucom N 4 janvier 2015

17 Pour réduire les coûts, l entreprise a opté pour l automatisation du processus suivant : enregistrement des nouveaux domaines, classification des données et distribution des données. Un élément clé est de créer un réseau de distribution impliquant les CERT et les chercheurs en sécurité. Le conférencier a ensuite traité de la détection des faux positifs, les difficultés pour superviser les communications en P2P, des techniques d anti-sinkholing utilisées par certains logiciels malveillants et des botnets mobiles. How to dismantle a botnet : the legal behind the scenes Karine Silva est une chercheuse en droit et s intéresse aux aspects légaux du démantèlement de botnets. Il s agissait donc d une présentation non technique présentant les difficultés légales et les bonnes pratiques dans le démantèlement de botnets. Exemple avec GameOver ZeuS. Après avoir collecté des données sur le botnet pendant 2 ans, le FBI a réussi à le démanteler. Pourtant, la grande taille du botnet et le nombre important de pays impactés ne présentaient pas cela comme une tâche aisée. Quels ont été les facteurs clés de succès d une telle opération? Tout d abord l arsenal législatif et la flexibilité du mandat du FBI facilitent la collecte d informations qui sont donc rapidement disponibles pour l analyse et l identification des cybercriminels. Le choix de l État dans lequel la plainte est déposée influe sur la capacité des forces de l ordre à poursuivre un cybercriminel en dehors des frontières de l État ou des États-Unis. Il faut aussi notifier le cybercriminel qu une plainte a été déposée à son encontre, lui permettant de se défendre. Le contact à une adresse physique est parfois complexe, et certains juges choisissent d innover en utilisant des contacts par ou d autres moyens électroniques comme notification. Karine conclue sur cet exemple en expliquant que la coopération internationale est la clé pour la suite. Au travers de traités internationaux, il est possible de coordonner la saisie simultanée sur plusieurs pays de serveurs C&C. La conférencière donne les exemples des Mutual Legal Assistance Treaties pour la coopération entre pays dans l obtention de preuves dans le cadre d investigations. Le démantèlement des serveurs C&C de GameOver ZeuS a été réalisé avec la saisie simultanée des serveurs au Canada, en France, en Allemagne, au Luxembourg, aux Pays-Bas, en Ukraine et en Grande-Bretagne. Karine a ensuite parlé du cas de Bredolab, où les forces de l ordre ont affiché un message d information sur le poste des victimes. Le fait d utiliser des techniques intrusives pour la notification est discutable et celui-ci a été perçu comme étant une atteinte à la vie privée par les victimes. La conférencière a ensuite ouvert le dossier néerlandais : la police néerlandaise a le droit de consulter toutes les données se trouvant sur le territoire national et les forces de l ordre pourront bientôt être dotées de capacités de sécurité offensive pour attaquer les cybercriminels. La présentation s est terminée sur un débat entre speakers et participants sur le même sujet. Des questions et des remarques intéressantes ont été échangées (mais non diffusées sur internet) : Le manque de lois internationales pousse vers la création d un véritable socle législatif international, mais il faut faire attention à la création potentielle de «paradis des botnets», à l image des paradis fiscaux. En effet, que pourrait-il se passer si un pays décide de ne pas appliquer les lois internationales? A timeline of mobile botnets Ruchna Nigam a passé en revue de nombreux logiciels malveillants ciblant les appareils mobiles. L histoire des botnets mobiles commence en 2009 avec : «Yxes», un botnet mobile sous Symbian qui pouvait accéder à internet et se propager par SMS mais qui ne pouvait pas exécuter de commandes. «Eeki.B», ciblait les appareils ios jailbreakés et pouvait lancer des scans ssh en utilisant le mot de passe classique par défaut : «alpine». La conférencière a ensuite présenté quelques chiffres sur les sur les systèmes d exploitation affectés : Android (93%). Symbian (4%). ios (1%). BlackBerry (1%). WinCE (1%). Ruchna a ensuite continué avec l histoire des botnets mobiles : 2010 : Symbian Zitmo (Zeus in the mobile) devenu multi-plateformes par la suite. 2011: Android DroidKungFu (root exploits et propagation) : Android Banking malware (Spitmo, Hesperbot, Perkel, Korean Banking Malware) : BadNews (plus de 2 millions de téléchargement depuis Google Play Store), AndroRat (spyware), Claco (PC infector) : Ransomware (Pletor.A,.onion C&C). Les données les plus volées : numéro IMEI, numéro IMSI, numéro de téléphone, build info et localisation. Quant aux communications C&C, elles utilisent le protocole HTTP(S) ou SMS voire une combinaison des deux. Ce dernier est particulièrement malicieux : un «health check» est effectué et si le C&C devient indisponible, une nouvelle configuration est poussée via SMS. Les motivations des cybercriminels sont financières (SMS premium, cheval de Troie bancaire) ou à des fins d espionnage (AndroRAT, Dendroid, NickiSpy, TigerBot) ou encore simplement de propagation. Ruchna a ensuite passé en revue les cas de : Android/SmsHowU : à la réception d un SMS «how are you?», l appareil répond avec le lien Google Maps de la localisation de l appareil. Android/Tascudap : lancé à l ouverture de Google Play ce logiciel malveillant a une fonctionnalité de déni de service. Android/Twikabot : botnet communiquant via Twitter. Android/NotCompatible : convertit l appareil infecté en un proxy. Concernant le chiffrement du trafic, on retrouve du classique (XOR, DES, obfuscation algorithmique, etc.). La Lettre CERT-Solucom N 4 janvier

18 Ruchna a ensuite présenté les vecteurs d attaques mobiles : Via le Google Play Store officiel (e.g. Android/FakePlay.B, Android/BadNews.A). Drive-by downloads Android/FakePlay.C se camoufle en tant que Google Play Store pour usurper l application Play Store officielle de Google. Il infecte le PC qui est connecté à l appareil en exploitant l autorun. Android/Chuli, un logiciel espion qui a fait l objet d une attaque ciblée vers les participants de la conférence WUC. Android/Xsser a infecté les manifestants de «Occupy Central» à Hong Kong via Whatsapp (une variante ios a été découverte mais celle-ci n a pas été déployée). En conclusion, la conférencière a souhaité mettre fortement en avant que les botnets mobiles sont désormais un fait avéré et non plus une fiction. Ceci est exacerbé par le fait que la persistance sur les appareils mobiles est plus facile à maintenir à distance et que les utilisateurs finaux considèrent pour un grand nombre qu un smartphone n est pas un ordinateur. Pour le futur, Ruchna a mis en garde contre les attaques multi-plateformes avec l avènement de l Internet Of Things et de la difficulté de la détection qui ne fait que croître. 18 La Lettre CERT-Solucom N 4 janvier 2015

19 Focus CERT-Solucom PyKEK : Outil d élévation de privilèges dans un domaine Windows par l exploitation de la vulnérabilité MS Cette année, le protocole d authentification Kerberos aura été à l honneur. Déjà en août, le français Benjamin Delpy présentait à la BlackHat US les terrifiantes techniques de post-exploitation permises par Kerberos sur un domaine Microsoft Windows (over-pass-the-hash, pass-the-ticket, golden et silver tickets ). A quelques semaines de Noël, c est la correction par Microsoft d une vulnérabilité critique présente dans la couche Kerberos des contrôleurs de domaine qui fait parler d elle. Retour sur cette vulnérabilité et les techniques employées pour son exploitation avec l outil PyKEK développé par Sylvain Monné de Solucom. 1. Annonce officielle Le 18 novembre dernier, Microsoft publie le bulletin de sécurité MS [1] qui dévoile l existence d une vulnérabilité critique dans le composant Kerberos Key Distribution Center (KDC) des contrôleurs de domaine Windows. La firme indique dans son communiqué que l exploitation de cette vulnérabilité peut permettre à un attaquant d élever les privilèges associés à un compte utilisateur de domaine standard pour ceux d un administrateur du domaine. Le bulletin de sécurité précise qu un accès distant au contrôleur de domaine est suffisant pour permettre une attaque et que l ensemble des versions supportées de la gamme Windows Server sont affectées (de WS2003 à WS2012R2). 2. La faille : le hachage en guise de signature Microsoft ont eux-mêmes fourni via leur bulletin de sécurité les premiers indices sur la nature de la vulnérabilité. La formulation est volontairement laissée vague, mais on y apprend que l implémentation du KDC sur les contrôleurs de domaine vulnérables peut échouer à valider correctement une signature numérique permettant la contrefaçon par un attaquant de «certains aspects» des tickets Kerberos. Cette information peut être confirmée et complétée par une analyse statique du correctif de Microsoft. La synthèse d une telle analyse a d ailleurs été publiée par l équipe de chercheurs BeyondTrust [3] deux jours à peine après le bulletin de Microsoft. Elle révèle qu il est possible de falsifier la signature des données d autorisation du ticket en remplaçant l algorithme HMAC utilisé par un algorithme de hachage sans clé comme MD5 ou CRC Principe d exploitation d MS et d MS11-013, sa grande sœur méconnue En soumettant simplement de fausses données d autorisation lors d une demande de ticket de service Kerberos, on obtient une attaque exploitant la vulnérabilité MS11-013! En effet, la signature falsifiée est alors incluse dans le ticket. L attaque implique donc une faiblesse dans sa validation par le service cible (et non par le contrôleur de domaine). Il s avère que cette faille était bien présente dans le système Windows jusqu en 2011 mais que celle-ci a été corrigée suite à la sortie du bulletin de sécurité MS [4]. On remarquera que cette première attaque reste utilisable contre un serveur ou poste qui n aurait reçu aucune mise à jour depuis 2011, et qu elle réussira même si les contrôleurs du domaine sont eux bien à jour. Pour exploiter MS14-068, il faut affiner l attaque en effectuant une demande de ticket de délégation sur un contrôleur de domaine nonpatché. Cette demande aura pour conséquence la re-signature des données d autorisation falsifiées. Le ticket ainsi obtenu devient donc valide auprès des services du domaine. 4. De la théorie à la pratique : Python Kerberos Exploitation Kit Un premier script d exploitation de cette faille a pu être publié le vendredi 5 décembre par Sylvain Monné, consultant sécurité de Solucom. Le choix qui a été fait est celui de ré-implémenter le protocole Kerberos et les formats liés dans le langage de programmation Python à travers une nouvelle bibliothèque baptisée Python Kerberos Exploitation Kit (PyKEK). La bibliothèque a été développée pour les besoins de ce script d exploitation mais sera amenée à être étoffée pour permettre d autres usages. La bibliothèque PyKEK et le script d exploitation de la faille MS sont publiquement disponibles sur le github personnel de son auteur [5]. [1] [2] [3] [4] [5] La Lettre CERT-Solucom N 4 janvier

20 Le CERT-Solucom Le CERT-Solucom a pour objectif de répondre aux attentes de nos clients en matière de gestion des incidents et des crises sécurité. Evaluation des risques cybercriminalité et sensibilitation Veille menaces, évaluation d attractivité, cartographie des risques, veille innovations, lien avec la cyber-assurance... Audit & tests d intrusion Simulation d attaque cybercriminelle, social engineering, tests d intrusion physiques... Investigation numérique / Forensics Détection de comprimissions avérées ou suspectées, identification des données ciblées, des méthodes d attaque... Gestion de crise - cybercriminalité Organisation de crise et tests préalables, pilotage de crises réelles, coordination d intervenants, reporting vers la Direction Générale... Accompagnement à la remédiation / continuité d activité Construction des plans d actions, correction de failles, sécurisation du SI, reconstruction ex nihilo de périmètres sécurisés... Le CERT-Solucom associe un ensemble d expertises techniques et métiers afin d apporter une réponse globale aux incidents de sécurité. Plus de 45 profils expérimentés sont mobilisables au sein du CERT-Solucom. Directeur de la publication : Pascal Imbert Responsable de la rédaction : Frédéric Goux Contributeurs : Yassine Bezza, Gérôme Billois, Baptistin Buchet, Thomas Debize, Simon Declerck, Matthieu Garin, Ary Paul Kokos, Jean Marsault, Sylvain Monné, Vincent Nguyen, Arnaud Soullié, Alexandrine Torrents, Dominique Yang. Photographies : Getty images Fotolia Graphiques : Solucom Conception graphique : les enfants gâtés Impression : Axiom Graphics CERT-Solucom Responsable CERT : Matthieu Garin cert@solucom.fr Tour Franklin, terrasse Boieldieu La Défense Paris - La Défense solucom@solucom.fr abonnement : cert@solucom.fr