Archives de catégorie : Attaques

CSRF

Les attaques de type CSRF, ou Cross Sites Request Forgery, font partie du top ten de l’OWASP, c’est-à-dire font partie des attaques les plus courantes et donc contre lesquelles on se protège peu (ou mal) en général.

En français ça signifie quelque chose comme falsification des requêtes (http) inter-sites. Le principe est qu’un utilisateur d’un site A, sur lequel il a les droits d’accès, fasse une requête sur ce site A à son insu lors d’une visite sur un site B.

Ainsi, le site B contiendrait une requête spécialement préparée qui n’attendrait plus qu’à être déclenchée par l’utilisateur.

Quel intérêt ?

Pas toujours évident de le voir à l’œil nu 😉 ! Imaginons que le site A est important mais vulnérable aux attaques CSRF. Le méchant pirate n’y a pas accès (il n’a pas le mot de passe, voire même le site A n’est pas accessible depuis l’extérieur).

Par contre, le site B est facile d’accès pour le pirate, lequel sait (ou espère) qu’il est visité régulièrement par l’utilisateur ayant accès au site A. Le pirate va alors placer sa requête sur le site B, en attendant que l’utilisateur du site A aille visiter le site B… tout en s’étant par ailleurs connecté sur le site A.

L’intérêt est ici : l’utilisateur du site A s’est auparavant authentifié. Il a donc accès aux fonctions qui intéressent le pirate, qui lui n’y a pas accès.

Or en allant sur le site B, l’utilisateur va sans le savoir lancer une requête sur un autre site (le site A) tout en étant déjà authentifié (au niveau de son navigateur).

Résultat : la requête, pourtant lancée à partir du site B, ira sur le site A en conservant (via le navigateur) la session authentifiée du site A, et elle sera donc exécutée !

Conclusion de l’affaire

Sans même avoir physiquement accès au site A, le pirate fera faire à l’utilisateur la requête qui lui, le pirate, souhaite voir s’exécuter sur le site A.

Paradons

Pour empêcher cela, on peut agir soit au niveau du navigateur, soit au niveau de l’application ou du serveur web.

Navigons

En 2018, seuls Chrome et Opera implémentaient un mécanisme de protection qui consiste à ne pas autoriser un cookie (servant à l’authentification) de servir une requête venant d’un autre endroit (same-site cookies).

Les soucis sont qu’on ne peut pas toujours faire confiance au navigateur et que seuls certains d’entre eux appliquent cette parade. La tendance semble toutefois meilleure en 2019, mais il faut avoir un navigateur à jour.

Plus d’infos : https://caniuse.com/#feat=same-site-cookie-attribute.

Niveau serveur

Il faut dans ce cas ne répondre qu’aux requêtes légitimes, c’est-à-dire envoyées par le serveur web lui-même. Pour cela, on ajoute un token (à usage unique) à la requête, qui doit être renvoyé dans la réponse.

Pour être efficace, il faut que ce token ne puisse pas être déterminé par l’attaquant ! Plusieurs frameworks de développement proposent des tokens robustes avec suffisamment d’aléas.

Et si la requête est légitime mais qu’elle ne contient pas de token, alors l’utilisateur doit se ré-authentifier ! Tout simplement.

Sources

Attaques XML

XML, comme toute technologie informatique, est potentiellement utilisable de façon détournée par de méchants pirates. Autrement dit, XML est attaquable. Certaines attaques sont relativement communes, d’autres sont plus spécifiques à la technologie elle-même.

Attaques XXE

Une attaque XXE consiste à utiliser le mécanisme XML External Entities qui permet de charger, dans un document XML, des données externes.

Principe

Il suffit donc ensuite que le serveur qui traite le fichier XML ait les droits sur la ressource demandées pour qu’il la récupère. Imaginons que le serveur soit installé sur une instance AWS : on peut très bien mettre, dans l’entité externe à charger, une URL du type //169.254.169.254/latest/meta-data/iam/security-credentials/role/ qui contient les informations d’authentification pour le rôle concerné.

<!DOCTYPE doctype [
<!ENTITY myentity SYSTEM "https://169.254.169.254/latest/meta-data/iam/security-credentials/role/"> ]>
<sell>
  ...
 <product>
  <name>Product Name</name>
  <price>100.00</price>
  <description>&myentity;</description>
 </product>
  ...
</sell>

On récupère alors une réponse :

{  "Code" : "Success",
  "LastUpdated" : "2018-02-06T15:12:30Z",
  "Type" : "AWS-HMAC",
  "AccessKeyId" : "ASIAJQAPNMGMDOUJ5LGQ",
  "SecretAccessKey" : "/jOIiFX...............eNBe0SigqvngXkXsMP",
  "Token" : "FQoDYXdzEKj//////////wEaDNzLiriTguzdpCK9A1/LsuWyHIqk...............7LLNrtnR2Sdy/VdfFjuLjzGw...............",
  "Expiration" : "2018-02-06T21:29:09Z" }

Contre-mesure

Ce risque est inhérent à l’utilisation de ce mécanisme, et le seul moyen efficace de s’en prémunir est… de l’interdire ! Hélas, chaque parseur XML a son propre paramétrage et il va falloir chercher dans la doc correspondante comment procéder. Pour Python/Django, cela peut donner :

from lxml import etree
parser = etree.XMLParser(resolve_entities=False)

Attaques XPath

L’attaque XPath est plus classique car elle est liée à l’éternel problème du contrôle des données entrées dans un système informatique.

Le principe est le même que celui d’une injection SQL, où on force, via des caractères spéciaux, une modification de la logique de la requête SQL générée avec l’entrée saisie par l’utilisateur. Ici, on modifie la logique du code ou de la requête SQL grâce à des caractères spéciaux introduits dans un champ XML.

Exemple : //coupon[code='ABCD' or '*']

Rien de bien nouveau, à part qu’il faut aussi penser à vérifier systématiquement ses documents XML, comme toute entrée (saisie) d’un utilisateur, notamment en échappant les caractères.

Attaques XSS

Les attaques XSS sur XML sont classiques et le principe est celui des XSS : on force un utilisateur à exécuter un script contenu dans le document XML.

Contre-mesures

Il y a deux façons de contrer ces attaques, qu’on peut combiner :

  • Filtrer les données du document XML, en échappant les caractères et/ou interdisant certains motifs (patterns) suspects ;
  • Empêcher l’exécution du script en modifiant le header de la réponse au niveau du serveur, en forçant le téléchargement du fichier.

Attaques XSS via un fichier SVG

SVG est un format d’image basé sur XML. Il est possible d’y inclure des scripts, ce qui le rend vulnérable aux attaques XSS comme vu juste au-dessus. Le principe est donc identique, à part que le script est désormais caché dans une image SVG qu’un attaquant cherchera à placer dans le site de sa cible.

Contre-mesures

Là où c’est un peu plus sioux, c’est qu’on peut effectivement faire la même chose que pour les attaques XSS. Mais si le fichier SVG doit être affiché sur une page web, il va être difficile (du point de vue ergonomie) de forcer l’image à être téléchargée ! Cela veut donc dire qu’il va falloir traiter très consciencieusement tout ficher SVG destiné à être affiché…

Voir aussi

Big data

Les grosses données sont des données nombreuses et volumineuses. Concept fumeux et marketing comme toujours, il n’en est pas moins vrai que l’augmentation des performances de stockage et de calcul posent de nouveaux problèmes de sécurité.

Technologie

D’où ça vient ?

Nous produisons de l’information depuis longtemps, bien avant le temps de l’informatique, mais la mémorisation (stockage) des informations (données) était limitée, tout comme leur analyse : il a fallu longtemps se contenter d’un support papier et de son cerveau !

Avec l’avènement de l’informatique, tout change : on peut à la fois stocker l’information et déléguer son traitement à une machine. Or plus on avance dans le temps, plus les capacités de stockage et d’analyse progressent, au point que certains usages qui nous paraissaient impossibles aux premiers temps de l’informatique sont maintenant à la porté d’un très grand nombre de personnes et d’entreprises.

Alors qu’autrefois, il fallait du matériel spécialisé, l’analyse de données est désormais possible avec du matériel standard. Ce qui relevait des capacités d’une organisation spécialisée est désormais possible à presque tout le monde, y compris des particuliers. Devenant grand public, le marketing inventa comme toujours un concept pour matérialiser cette évolution : le big data. L’analyse rapide de données en masse

Définition informatique formelle

Il n’y en a pas. Il y a plutôt certains critères qui font penser qu’on est dans une implémentation de big data :

  • Beaucoup de données, généralement non structurée ;
  • On utilise hadoop !
  • L’architecture est distribuée et parallélisée ;
  • On n’arrive pas à traiter les données avec une base de données classique ;
  • Règle des 3V : Volume, Variété, Vélocité des données et de leur analyse.

En résumé : en cherchant bien, n’importe quoi peut être big data.

Domaines

Pour n’en citer que quelques uns où l’analyse rapide de données en masse le big data est utilisé :

  • Ciblage publicitaire, suivi des consommateurs
  • Analyse comportementale
  • Lutte contre la fraude
  • Recherche (santé par exemple)
  • Détection et prévention des pannes de composants ou de systèmes failures

Les technologies en elles-mêmes

MapReduce

MapReduce est une technologie initiée par Google pour le traitement des données en masse. Les deux principales étapes sont :

  • Map : On transforme la donnée brute en format exploitable (genre clé-valeur), et on les prépare au traitement.
  • Reduce : On les traite effectivement, de façon statistique.

Hadoop

Hadoop est l’implémentation open source de MapReduce couplé à un système de fichiers distribué, HDFS. HDFS permet notamment de répliquer les données sur plusieurs noeuds pour éviter la perte de données, et la mise-à-jour est également interdite : elle s’effectue par la création d’un nouveau fichier.

D’autres technologies sont adossées à l’écosystème Hadoop :

  • Des bases de données spécialisées sont également employées, comme Hbase ou Cassandra, opérant un système de fichier HDFS (ou compatible) ;
  • Les requêtes sont générées en langage HiveQL ou Pig Latin ;
  • L’import/export de données vers des bases classiques se fait via Sqoop (Sql-to-hadoop) ;
  • Des composants de haut ou bas niveau, comme pour le machine learning (Mahout) ou l’intégration de logs (Flume).

Hive

Hive n’est ni plus ni moins qu’une infrastructure d’entrepôt de données (comme on disait dans le temps), mais basé sur les outils de type big data, comme HiveQL, HDFS, HBase, etc. Il est interopérable avec de nombreux outils de BI (Business Intelligence).

Autres technologies liées

  • Massively Parallel Processing (MPP), basé sur des appliances, permettant des requêtes SQL distribuées ;
  • NoSQL, bases non structurées privilégiant la disponibilité à la consistance (au sens SGBD), stockant sous les formes de clés/valeurs, documents, graphes, etc.
  • CAP Theorem : ?
  • NewSQL : ?

La liste ne saurait être limitative, surtout que l’hybridation des architectures est souvent pratiquée dans les entreprises.

En ai-je besoin ?

La plupart du temps : non. Mais ça fait chouette sur sa carte de visite (au niveau personnel ou entreprise). Mais s’il fallait réfléchir avant de mettre en oeuvre une technologie informatique, ça se saurait. S’il y a de nombreux cas d’usage où les technologies big data se justifient, de trop nombreuses organisations ne le font que pour être à la mode. Une des conséquences de cet engouement irréfléchi est la pénurie de statisticiens, appelés data scientists dans le domaine du big data, capables de tirer parti des données.

Comment rester anonyme ?

Big data et respect de la vie privée sont deux notions contradictoires : dans ce monde de données abondantes et déferlantes, il devient bien difficile de rester anonyme, pour deux grandes raisons :

  • D’abord parce que nous produisons de la donnée à ne plus savoir qu’en faire, en laissant partout un infinité de traces de nos activités (informatiques, ou non-informatiques mais mesurées ou reliées à des outils informatiques) ;
  • Parallèlement à cette production, les moyens de traitement sont désormais capables d’effectuer des rapprochements ou des corrélations dont on était incapable il y a peu.

Un exemple (théorique) de désanonymisation par corrélation

Cet exemple a été donné par une juriste de ma société, et il est très parlant. Imaginons qu’on dispose d’une vue partielle de l’ensemble des logs d’activité des bornes téléphoniques. Par partiel, j’entends qu’on dispose de données sur l’ensemble des bornes, sur une période suffisamment grande, mais anonymes a priori : on ne disposerait que de l’identité (l’emplacement) de la borne, la date précise (au moins à la minute) et l’identifiant des téléphones (genre IMEI). Un exemple simple de ligne pourrait être :

numéro de ligne ; identité/localisation borne ; date et heure ; IMEI

A prori rien de personnel. Ou plutôt rien que des données anonymes, car les identifiants techniques comme l’adresse IP, l’adresse MAC ou l’IMEI sont indirectement personnelles : les opérateurs disposent d’une base faisant le lien entre ces identifiants techniques et leurs clients. De ces informations brutes, on ne peut tirer aucune information personnelle. On suppose aussi qu’on ne dispose pas d’une base faisant un lien entre IMEI et les clients, bien sûr.

En premier lieu, on isolera toutes les données d’un IMEI, en supposant qu’il n’y ait qu’un seul utilisateur principal. On tracera vite une cartographie de la géographie de ses déplacements, et on trouvera vite l’adresse de son travail (les lieux où le téléphone se trouve durant les heures de travail) et celle de son domicile (aux autres heures), de façon statistique. Puis, à partir d’une annuaire classique, on cherchera sur les adresses proches de la localisation du domicile un premier ensemble de candidats potentiels.

Ensuite, on identifiera les entreprises présentes sur le lieu de travail. Là aussi des données facilement accessibles. Pour continuer, on cherchera sur les réseaux sociaux toutes les personnes de notre première liste de candidats travaillant pour une des sociétés de notre 2e liste, si possible en affinant par localisation.

Dans mon cas, je travaille sur un site de 5000 personnes et j’habite Paris ; or je n’ai jamais rencontré de collègue ou très peu près de mon domicile. Dans le pire des cas, une petite dizaine de personnes doivent à la fois travailler à proximité du lieu de travail et du domiciles identifiés par les logs bruts.

En continuant une corrélation un peu plus ciblée, on finit par donner une identité quasi-certaines à l’IMEI a priori anonyme. Et en repartant sur les logs, on finit par tracer une grande partie des activités de la personne. Merci à nos smartphones !

Après y avoir pensé en théorie, voici l’application pratique, rapportée par le New York Times !

Inférence

On peut déterminer des caractéristiques d’une personne sans rien lui demander. Il faut souvent un niveau un peu plus élevé d’informations, mais à peine. Imaginons qu’en plus des données précédentes, on dispose du niveau de signal (assez précis, quand même). Dans les toilettes hommes, je mets une borne wifi. Une autre est placée dans les toilettes femmes. Les téléphones vont interroger les bornes lorsqu’ils sont à proximité. On en déduit facilement le sexe du propriétaire d’un téléphone quand il se rend aux toilettes : le meilleur signal sera du côté où se trouve la personne !

On a donc ainsi déterminé le sexe d’une personne sans rien lui demander : c’est un mécanisme d’inférence.

Ok mais ça marche pas à tous les coups

Oui. Mais rapportons ça à l’échelle du temps, du volume exponentiel de données et de signaux que nous produisons.

Cherchons bien

Comme prévu, et comme prouvé, l’anonymisation est un art délicat !

Articles liés

Sources d’information

Voici mes différentes sources d’information, en ce qui concerne l’actualité.

Dans le registre des newsletters :

Côté sites d’informations informatiques, ayant souvent de bons articles sur la SSI :

Côté blogs, voici :

Chaînes d’infos, webinars, etc. :

Pour ce qui est des sources de formation, voici ce que j’ai en stock :

D’autres bons sites, payants :

  • PluralSight ;

Pour tout casser (et expérimenter des techniques d’attaque) :

De nombreux éditeurs et fournisseurs ont des rubriques sécurité (Microsoft, Intel, AWS…)

Les éditeurs de solutions de sécurité ont aussi souvent des pages intéressantes (base des virus, études, livres blancs, etc.)

Intel, des failles (ter)

Non, il ne faut pas croire que cela m’amuse de recenser les failles matérielles sur les processeurs (Intel ou autre). Au contraire : cela m’inquiète au plus haut point, sans m’étonner outre mesure, car la complexité des processeurs est devenue telle qu’il devient quasi-impossible de maîtriser l’ensemble de sa conception. En sécurité informatique, plus c’est complexe, plus c’est dur à sécuriser.

Nouvelle faille : Foreshadow

Traduisons ce qu’on trouve sur le site dédié (rappel : un site dédié avec un joli nom de faille et un beau logo sont les minimum syndicaux pour toute faille qui se vend respecte).

Foreshadow is a speculative execution attack on Intel processors which allows an attacker to steal sensitive information stored inside personal computers or third party clouds. Foreshadow has two versions, the original attack designed to extract data from SGX enclaves and a Next-Generation version which affects Virtual Machines (VMs), hypervisors (VMM), operating system (OS) kernel memory, and System Management Mode (SMM) memory.

Foreshadow est une attaque de type exécution spéculative (comme Spectre et Meltdown) touchant les processeurs Intel (les pauvres !) permettant à un attaquant de dérober des informations sensibles stockés sur des ordinateurs personnels ou dans le cloud (il est écrit third party, mais en vérité cela touche toute infrastructure, interne ou externe, cloud ou pas, qui compte sur un [[Évasion de machine virtuelle|hyperviseur]] de virtualisation pour isoler des environnements et des machines, cf juste en dessous).

Foreshadow a deux versions : l’attaque originale, conçue pour extraire des données des enclaves SGX (censées justement éviter cela…) et une nouvelle génération « NG » (de l’attaque) qui affecte les machines virtuelles, les hyperviseurs VMM (Virtual Machine Manager, hyperviseur utilisé dans le cloud Azure), la mémoire du noyau du système d’exploitation et la mémoire utilisée par le mode « management de système » (SMM).

Encore du Meltdown ?

Foreshadow est une variante de Meltdown1, de type exécution spéculative, dont la source a fini par être identifiée par Intel dans le cache L1 (L1TF, L1 Terminal Fault). Hélas, une fois ce constat réalisé, Intel a remarqué que cela avait d’autres conséquences2, d’où la création de deux variantes appelées « NG ».

Composants impactés

Virtual Machines Manager

Les bulletins ne sont pas très clairs sur ce point, car ils parlent de VMM sans trop de précision. D’après ce qu’en dit OVH3, les failles touchent bien les hyperviseurs en général, et non uniquement le VMM d’Azure.

Système d’exploitation

Idem pour l’OS, quasiment jamais mentionné dans les publications. Toutefois Linux est bel est bien touché lui aussi, cf les publications des différents éditeurs. Il n’y a pas que Windows…

System Management Mode

Il s’agit d’un mode spécial d’exécution du processeur, dont les caractéristiques sont :

  • Se situe dans une mémoire spéciale et séparée (SMRAM) ;
  • Peut accéder à l’ensemble du système et des entres/sorties, y compris la mémoire de l’OS et d’un hyperviseur ;
  • Est appelé par une interruption spécifique (SMI, System Management Interrupt) ;
  • Possède un gestionnaire logiciel (SMI handler) pour exécuter des opérations basées sur différentes SMI.

C’est un peu technique mais en gros ça signifie qu’il s’agit d’un mode qui a accès à tout, et qu’on l’imagine réservé pour un usage spécifique et bien délimité.

SGX

SGX est une enclave sécurisée, présente dans certains processeurs Intel, et conçue pour que personne ne puisse venir y lire le contenu : cela permet de cacher des informations très sensibles, comme des clés de chiffrements, dans une infrastructure tierce.

Conditions d’exploitation

Maigre consolation : la faille se situe au niveau core, c’est-à-dire qu’un processus ne peut utiliser cette vulnérabilité que contre un autre processus s’exécutant sur le même cœur du processeur4. Cela concerne les processeurs récents (ce qui est le cas de tous les processeurs SGX), de génération Sandy Bridge ou suivantes, car Intel assigne un cache L1 dédié pour chaque cœur5.

Logiquement, avec un processeur 4 cœurs, il n’y a qu’une chance sur 4 de subir l’attaque, et il est peu probable (impossible ?) pour un processus, qui plus est lancé dans une machine virtuelle, de choisir le processeur sur lequel il s’exécute.

Multiplié par le nombre de cœurs et de machines virtuelles, la probabilité baisse encore, surtout que la difficulté sera surtout de réussir à exécuter le programme d’attaque sur le même cœur de processeur que la cible. Après, une machine virtuelle peut demander à s’exécuter sur plusieurs processeurs virtuels, donc sur plusieurs cores, mais ça se paye. Et dans un environnement mutualisant des milliers de processeurs, ça peut devenir coûteux.

Correctifs

On peut renforcer l’isolation par les mesures suivantes :

  • En s’assurant qu’un core n’est pas partagé entre plusieurs machines virtuelles en même temps ;
  • Lorsque deux machines se suivent séquentiellement sur un core, alors on s’assure que le cache L1 est bien effacé ;
  • En ayant un environnement dédié (hyperviseur dédié chez AWS) pour empêcher le partage des CPU.

En ce qui concerne SMM, une mise-à-jour de microcode et de firmware semble nécessaire6.

Sinon désactiver l’hyperthreading est un moyen (coûteux à mon avis) d’empêcher l’exploitation de la faille ; on ne le réactivera qu’avec précautions, mais tout cela est bien expliqué sur le site de Xen.

Liens utiles

Sur Linux

  • Ubuntu : https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/L1TF et https://people.canonical.com/~ubuntu-security/cve/2018/CVE-2018-3646.html
  • Red Hat : https://access.redhat.com/security/vulnerabilities/L1TF
  • Suse : https://www.suse.com/support/kb/doc/?id=7023077

RedHat propose une présentation rapide de Foreshadow, assez bien faite.

Liens internes

  • [[Évasion de machine virtuelle|Evasion de machine virtuelle]]
  • Intel, des failles ([[Intel, des failles|première vague]], [[Intel, des failles (bis)|deuxième vague]])

Site officiel

  • https://foreshadowattack.eu/
sans_cadre

Intel, des failles (bis)

Je me répète, non ? La plaie Spectre & Meltdown n’est pas encore fermée (et l’hémorragie n’est même pas encore arrêtée) que voilà poindre de nouvelles variantes, De l’avis d’Intel, quatre des huit vulnérabilités mises au jour sont plus critiques que la vulnérabilité Spectre initiale. Gloups.

Voici, par ordre d’apparition

Nouvelles variantes

Variante 3a

CVE-2018-3540. Impact sur des hyperviseurs.

Variante 4

Les principaux intéressés travaillent d’arrache-pied pour atténuer les impacts de la faille, mais comme les variantes précédentes, cela peut affecter les performances12 des processeurs. Elle reçoit le doux nom de Speculative Store Bypass.

Toutefois, les correctifs de versions précédentes ont l’air d’atténuer3 la portée de cette variante.

Variantes 1.1 et 1.2

Des chercheurs4 ont trouvé de nouvelles variantes de Spectre ; ils ont été récompensé dans le cadre d’un Bug Bounty d’Intel.

NetSpectre

Passée relativement inaperçue5, cette variante a été découverte en mars 20186, et corrigée selon le protocole informel de la divulgation responsable, ou responsible disclosure, en juillet 2018 par Intel7.

Sources

Pour les variantes 3a et 4

  • Communication officielle de Microsoft (ADV180012)
  • Page Google Zero (Issue 1528)
  • Communication ARM, avec un intéressant tableau de vulnérabilité selon les familles de processeurs
  • Communication Intel
  • Communication AMD
  • Communication RedHat
  • Communication VMWare
  • Communication Xen (advisory 263)
  • CVE-2018-3639
Autres sources web
  • http://www.guru3d.com/news-story/eight-new-spectre-variant-vulnerabilities-for-intel-discovered-four-of-them-critical.html
  • https://www.developpez.com/actu/205147/Spectre-Meltdown-de-nouvelles-failles-dans-les-processeurs-elles-permettent-de-lire-les-registres-internes-la-memoire-kernel-et-celle-de-l-hote/
  • https://www.heise.de/ct/artikel/Super-GAU-fuer-Intel-Weitere-Spectre-Luecken-im-Anflug-4039134.html
  • https://www.cnet.com/news/intel-microsoft-reveal-new-variant-on-spectre-meltdown-chip-security-flaws/
  • https://www.us-cert.gov/ncas/alerts/TA18-141A
  • https://www.techrepublic.com/article/spectre-isnt-dead-here-are-2-new-variants-it-should-patch-against/

Pour les variantes 1.1 et 1.2

  • https://www.developpez.com/actu/214640/Encore-deux-nouvelles-vulnerabilites-de-classe-Spectre-decouvertes-elles-affectent-des-processeurs-Intel-ARM-et-probablement-AMD/

Voir aussi