Cette année encore, Intrinsec était présent ce vendredi 24 mars dernier, pour la 10ème édition de la conférence Insomni’hack organisée par SCRT.

Plusieurs présentations se sont tenues sur 3 salles différentes et le planning correspondant était le suivant:

Bridging the gap between ICS (IoT?) and corporate IT security

Stefan Lüders, RSSI de l’Organisation européenne pour la recherche nucléaire (CERN), nous a présenté ces problématiques rencontrées pour la défense de l’écosystème du CERN.

Dans un système aussi hétérogène, la problématique du BYOD prend tout son sens. Outre la complexité de la mise en place de correctifs de mise à jour, la réalisation de tests de sécurité est encore plus compliquée à mettre en œuvre sur des systèmes aussi sensibles que ceux supervisant les réacteurs nucléaires, et pour lesquels aucune perturbation n’est tolérable.

En attendant la vidéo officielle, une ancienne version de cette présentation est disponible ici:
https://www.blackhat.com/docs/us-14/materials/us-14-Luders-Why-Control-System-Cyber-Security-Sucks.pdf

DevOops Redux

Cette conférence présentée par Ken Johnson (@cktricky) et Chris Gates (@Carnal0wnage), portait sur l’importance de la sécurité des machines des développeurs et des différents outils souvent mal maîtrisés. D’après Ken, une machine de développement est en général une mine d’or pour un attaquant puisqu’elle contient des clés API, des mots de passe d’accès à des services sensibles, et éventuellement des clés SSH pour l’authentification à des serveurs de préproduction ou de production.

Le but premier de cette présentation était de sensibiliser l’assemblée autour de 3 domaines : la sensibilisation des développeurs, la protection des serveurs de développement et les services de gestion de déploiement. Chris et Ken ont donc présenté plusieurs outils, tels que Slack auditor, gitrob, TruffleHog ou encore GitMonitor, permettant d’exploiter le facteur humain (oubli de fichiers de configuration) et de récupérer ce type d’information sensible.
Pour la partie protection des serveurs de développement, différents outils ont été cités tels qu’Osquery permettant d’interroger son système d’exploitation, Doorman ou encore BlockBlock, configuré pour avertir lorsque des logiciels souhaitent persister sur le système et demander une confirmation à l’utilisateur. Des solutions de type SIEM ont ensuite été présentées : ELK, StreamAlert ou encore Splunk.

Enfin, pour la dernière partie de la présentation, Ken et Chris se sont concentrés sur les outils utilisés par la chaîne d’intégration, en présentant des défauts configuration souvent rencontrés avec les services Jenkins, Redis, Docker ou encore AWS.

Les slides de la présentation sont disponibles sur SlideShare à l’adresse suivante :
https://www.slideshare.net/chrisgates/devoops-attacks-and-defenses-for-devops-toolchains

Modern reconnaissance phase on APT – protection layer

Paul Rascagnères a présenté 5 cas d’étude de la phase de reconnaissance effectuée par les attaquants « modernes » avant l’infection de la cible. Le vecteur de compromission était pour l’ensemble des cas exposés, un document Office contenant une macro malveillante. L’analyse des différentes techniques utilisées par les attaquants a permis d’identifier un processus générique découpé en 4 étapes :

• Étape 1: Exécution de la première charge (ici la macro du document Office) qui effectue un scan de l’environnement d’exécution
• Étape 2: Envoi des résultats de l’analyse à l’attaquant
• Étape 3: Validation de l’environnement par l’attaquant ; il s’assure que l’exécution ne se fait pas dans un environnement d’analyse de type sandbox, en s’appuyant sur les informations reçues.
• Étape 4: Dépôt de la charge finale (RAT, agent c&c, etc.), si l’environnement correspond aux attentes de l’attaquant.

De cette étude en ressort l’importance portée par les attaquants à leurs outils de compromission et d’exploitation.

Enfin, une question a été posée à la fin de la présentation :
« Et si l’on faisait croire à tous les programmes qu’ils s’exécutent dans une sandbox ? »
Paul a répondu que dans tous les cas étudiés, l’attaquant n’aurait pas envoyé sa charge utile finale.

A new Source of trouble – Remote exploitation of the Valve Source game engine

Amat Cama a porté son étude sur les moteurs de jeu utilisés par l’éditeur Valve.

Il a donc décrit ce que l’on appelle les « Game engine », donnant accès aux API utilisées par les jeux vidéo. Ceux-ci proposent plusieurs fonctionnalités génériques qui permettent d’accélérer le développement des jeux vidéo.

Amat a donc décidé de s’attaquer au moteur de jeu Valve puisque celui-ci est un des plus utilisé et permet donc d’impacter le plus de « jeux » possible.

Lors de sa démonstration, il a créé un serveur malveillant pour exploiter une vulnérabilité permettant la prise de contrôle des postes des joueurs connectés à celui-ci.

CTF

Cette année, c’est plus de 450 personnes qui se sont affrontées autour de ce mémorable CTF. Outre les challenges habituels de forensics ou d’exploitation système et web, un défi spécial a été développé via Unity sous la forme d’un jeu en 3D de type FPS (First Person Shooter). Pour le réussir, les joueurs devaient tricher pour accéder à certaines zones du jeu et ainsi récupérer les flags.

Une autre nouveauté de cette édition était le défi de type « Escape Room » pour lequel les participants devaient assembler un puzzle QR-Code, crocheter des cadenas et se connecter sur un ordinateur à l’aide d’un scanner de codes-barres, le tout le plus rapidement possible. Pour ce challenge, Intrinsec a terminé à la 1ere place en le complétant en 5 minutes et 6 secondes.

Et c’est encore une fois « Dragon Sector » qui remporte la première place avec un total de 97400 points en validant un challenge à la toute dernière minute.

L’ensemble des writeups peut être consulté via le lien suivant :
https://ctftime.org/event/383/tasks/

Nous souhaitons remercier SCRT pour l’organisation de cet événement et pour leur accueil.