Sécurité des terminaux mobiles

Magazine
Marque
MISC
Numéro
91
|
Mois de parution
mai 2017
|
Domaines


Résumé
La sécurité des mobiles et des communications est un enjeu à la fois pour la vie privée, la liberté, mais aussi pour la sécurité des personnes et des pays. Comment résistent les applications de messageries instantanées aux attaques sur les systèmes et/ou les réseaux ?

Body


Une des principales préoccupations depuis les révélations de Snowden est le respect de la vie privée et des libertés et par conséquent la confidentialité des échanges. Les écoutes massives mises au jour ont effrayé de nombreux utilisateurs de téléphones mobiles. Pour les reconquérir, les fabricants et les éditeurs d'applications sécurisent de plus en plus les données stockées ainsi que celles échangées sur les réseaux.

Cette sécurité ne doit pas compromettre l'expérience utilisateur et donc la rapidité des échanges et la fluidité de traitement. Quelle sécurité est implémentée et à quel point est-elle fiable ?

1. Sécurité des systèmes

La première des protections réside dans le système lui-même, du firmware au système d'exploitation. Comment est garantie cette sécurité ? Comment la compromettre et quels sont les risques ?

1.1 Chaîne de confiance

Le code exécuté par le processeur du terminal est un des garants du fait que les opérations effectuées sont uniquement celles qui sont prévues par l'éditeur du système d'exploitation ou des applications s'exécutant. Afin de garantir que ce code est intègre, une chaîne de confiance est implémentée au démarrage des terminaux. Apple, par exemple, intègre un certificat dans la mémoire ROM (inaltérable) de ses processeurs. Exemple :

Certificate:

    Data:

        Version: 3 (0x2)

        Serial Number: 2 (0x2)

    Signature Algorithm: sha1WithRSAEncryption

        Issuer: C=US, O=Apple Inc., OU=Apple Certification Authority, CN=Apple Root CA

        Validity

            Not Before: Apr 25 21:40:36 2006 GMT

            Not After : Feb  9 21:40:36 2035 GMT

        Subject: C=US, O=Apple Inc., OU=Apple Certification Authority, CN=Apple Root CA

        Subject Public Key Info:

            Public Key Algorithm: rsaEncryption

                Public-Key: (2048 bit)

                Modulus:

                    00:e4:91:a9:09:1f:91:db:1e:47:50:eb:05:ed:5e:

                  [...]

                    ff:67:5e:65:bc:49:d8:76:9f:33:14:65:a1:77:94:

                   c9:2d

                Exponent: 65537 (0x10001)

        X509v3 extensions:

            X509v3 Key Usage: critical

                Certificate Sign, CRL Sign

            X509v3 Basic Constraints: critical

                CA:TRUE

            X509v3 Subject Key Identifier:

                2B:D0:69:47:94:76:09:FE:F4:6B:8D:2E:40:A6:F7:47:4D:7F:08:5E

            X509v3 Authority Key Identifier:

                keyid:2B:D0:69:47:94:76:09:FE:F4:6B:8D:2E:40:A6:F7:47:4D:7F:08:5E

            X509v3 Certificate Policies:

                Policy: 1.2.840.113635.100.5.1

                  CPS: https://www.apple.com/appleca/

                  User Notice:

                    Explicit Text: Reliance on this certificate by any party assumes acceptance of the then applicable standard terms and conditions of use, certificate policy and certification practice statements.

    Signature Algorithm: sha1WithRSAEncryption

         5c:36:99:4c:2d:78:b7:ed:8c:9b:dc:f3:77:9b:f2:76:d2:77:

        [...]

b0:75:75:21

Ce certificat racine permet de vérifier l'intégralité de la chaîne de confiance pour tous les éléments de code signés avec des certificats eux-mêmes signés par celui-ci avant d'être exécutés. Ainsi Apple garantit que le code exécuté est le sien. La plupart des systèmes Android (Google, Samsung, LG, HTC…) ont également intégré une chaîne de confiance garantissant l'intégrité du code exécuté. Ces équipements peuvent néanmoins être facilement personnalisés, mais dès lors, un fusible de garantie anti-compromission est déclenché. Certaines applications sécurisées refusent alors de s'exécuter. C'est le cas par exemple de KNOX (Samsung).

Les mises à jour sont également signées et vérifiées afin qu'elles ne soient pas un vecteur de compromission. Enfin, iOS ou les dernières moutures du système Android (6.0.1 mise à jour postérieure à novembre 2016) empêchent les downgrade de système et par conséquent les attaques sur des vulnérabilités antérieures.

Enfin, les applications disponibles sur les magasins sont elles aussi signées, mais pas par l'éditeur du système d'exploitation. Les développeurs restent responsables des applications diffusées, et malgré les vérifications opérées par Google ou Apple, certaines sont malveillantes. Ce système garantit néanmoins que des applications très grand public comme Facebook, Twitter… ne sont pas compromises.

1.2 Vérification d’intégrité du système

Une fois le code vérifié, il est nécessaire de s'assurer que celui-ci n'est pas altéré au cours de l'exécution. Apple utilise plusieurs mesures de protection. La première, Kernel Patch Protection, vérifie périodiquement l'intégrité du kernel (certaines parties exécutées seulement) et empêche tout kernel modifié de s’exécuter. La deuxième est la signature et la vérification systématique des mises à jour qui empêchent un attaquant de modifier le système par ce biais.

Samsung a déployé un système similaire, TrustZone Integrity Measurement Architecture. Celui-ci réside dans la partie TrustZone, Trusted Execution Environment, permettant une exécution sécurisée au niveau matériel.

1.3 Chiffrement des données

Apple a chiffré son système jusqu'à la version 10 d'iOS. Ceci ralentissait la découverte de vulnérabilités en empêchant les chercheurs d'accéder au code. Le chiffrement garantissait également l'authenticité des données, celles-ci ne pouvant être déchiffrées que par un co-processeur cryptographique spécifique dans lequel la clé a été codée au niveau du silicium. Plusieurs contournements ont été trouvés permettant d'accéder au code déchiffré, en utilisant la fonction cryptographique sur un appareil compromis. Cependant, Apple a choisi de ne plus chiffrer complètement les mises à jour de son système d'exploitation, considérant sa chaîne de vérification suffisamment sûre.

La confidentialité des données utilisateur est également souvent assurée par le chiffrement. Sur les plateformes haut de gamme (Apple, Google ou Samsung), une clé spécifique à chaque appareil, combinée au mot de passe utilisateur permet de chiffrer les données. Pour attaquer le mot de passe, il est par conséquent nécessaire d'utiliser le terminal. Ceci implique un nombre d'essais illimités.

Cependant, sur bon nombre de plateformes Android, le chiffrement des données utilisateurs avec une clé dérivée du mot de passe n'est pas fait par défaut. Si Android Marshmallow impose le chiffrement par défaut, celui-ci est réalisé avec le mot de passe « default_password ». Le pin, pattern ou de mot de passe ne servant qu'à accéder à l'interface graphique. Samsung propose une option « Secure boot » permettant d'activer la fonctionnalité de chiffrement par dérivation du mot de passe.

Évidemment, sur les plateformes sécurisées, un accès système à l'insu de l'utilisateur permet d'accéder à l'ensemble des données lorsque le terminal est déverrouillé.

De même, certains mécanismes implémentés pour l'expérience utilisateur permettent de récupérer certaines données même si le terminal est verrouillé. C'est le cas des sauvegardes pour les iPhones par exemple si l'ordinateur sur lequel a été connecté le terminal est récupéré.

Enfin, beaucoup de données sont également sauvegardées dans le cloud. Il est alors uniquement nécessaire d'obtenir les identifiants de connexion afin d'y accéder. Ceci relève d'autres stratégies de pénétration.

1.4 Compromission

Malgré les mesures de protection décrites auparavant, des hackers ou des chercheurs ont réussi à compromettre les systèmes qui les implémentent.

Sur Apple, les jailbreaks permettent d'en contourner un certain nombre. La plupart des solutions publiques requièrent des actions explicites de la part de l'utilisateur, ce qui limite le risque de compromission de type Evil Maid.

Les applications sont exécutées dans des sandboxes, permettant d'isoler leurs données d'exécution et de stockage. Ainsi, une application ne peut en théorie pas agir sur les données d'une autre ou compromettre le système. Néanmoins certaines vulnérabilités ont permis de s'échapper de cette sandbox.

Certains éditeurs de solutions ont implémenté des attaques utilisant des remote exploits. Des traces de tels programmes ont par exemple été trouvées dans la fuite de données de Hacking Team en juillet 2015.

Une fois le système compromis, beaucoup d'attaques deviennent possibles, notamment l'exfiltration des données personnelles stockées sur l'appareil. Néanmoins, selon le niveau de compromission, les données exposées ne sont pas les mêmes. Un accès complet au système permet la modification d'applications ou leur remplacement ainsi que l'interception complète des flux réseaux. Dans ce cas, plus aucune donnée ne peut être considérée comme sûre, notamment les échanges sur les messageries dites sécurisées, comme expliqué ci-dessous.

2. Sécurité des communications de données

Les différentes messageries sécurisées dépendent à la fois de la sécurité du système sur lequel elles sont installées, mais également de la chaîne de confiance qu'elles implémentent. Nous allons voir que cette chaîne est souvent de bonne qualité, mais certaines applications sont plus paranoïaques que d'autres.

2.1 Chiffrement et authentification des communications

2.1.1 Public Key Infrastructure

L'infrastructure à clé publique est la base de la chaîne de confiance des communications sécurisées. Pour rappel, une telle infrastructure fonctionne de la manière suivante :

pki

Fig 1 : Schéma simplifié d'une infrastructure à clé publique.

Une autorité racine émet un certificat qu'elle signe elle-même. Elle peut ensuite signer des certificats pour des entités subordonnées ou authentifier des données. La vérification s'effectue en vérifiant les signatures à chaque échelon. La sécurité repose par conséquent sur la confiance accordée à l'autorité racine et à la confidentialité de sa clé privée. En cas de fuite ou de vol, une autorité peut répudier les certificats qu'elle a signés, à condition que cette information puisse être diffusée et les certificats remplacés ou supprimés. Si c'est le certificat racine qui est compromis, alors c'est à l'utilisateur ou à l'éditeur qui l'embarque de le supprimer.

L'exemple le plus parlant d'une telle infrastructure est le magasin de certificats embarqué dans les navigateurs internet. Celui-ci contient les certificats des autorités racines qui permettent d'authentifier les sites web et sécuriser les échanges.

Cette infrastructure est appliquée de la même manière dans la sécurité mobile à la différence qu'elle s'étend à l'ensemble de la plateforme. En effet, chacune embarque également un magasin de certificats permettant l'authentification des échanges. L'authentification de code reste vérifiée par les seuls certificats des éditeurs de système d'exploitation.

Chaque application s'appuyant sur le protocole HTTPS et les communications standards fournies par les frameworks iOS ou Android utilise le magasin de certificat de la plateforme.

Un magasin de certificat est livré avec le système d'exploitation (exemple https://support.apple.com/en-us/HT204132). Cependant, des certificats peuvent également y être ajoutés. Certaines plateformes permettent également à l'utilisateur de ne plus faire confiance à un certificat livré par défaut.

2.1.2 Protocoles utilisés par les applications mobiles

Au-delà des protocoles de chiffrement spécifiques à chaque application, le transport est quasi-exclusivement assuré par HTTPS.

Les applications comme Facebook Messenger, Snapchat, WhatsApp ou Viber utilisent cette couche de transport. Elles utilisent le framework commun de la plateforme qui est régulièrement mis à jour. Les attaques par downgrade de connexion par imposture de serveur ne sont par conséquent plus possibles. Facebook lèvera par exemple une exception « Certificate Unknown » et Snapchat ne répondra qu'un « Close notify » sans détailler l'erreur.

Deux autres protocoles de communication sécurisés on fait leur apparition MTProto pour Telegram et Double Ratchet pour Signal. Ces deux protocoles utilisent des clés éphémères pour le chiffrement des messages et garantissent ainsi la Perfect Forward Secrecy. L'échange des clés est basé sur un échange Diffie-Hellman qui permet d'éliminer les attaques de l'homme du milieu.

2.2 Compromissions

2.2.1 Attaques sur les échanges

Afin de tester la réelle résistance des applications de messagerie, nous montons un système d'interception des communications sécurisées. Celui-ci est composé d'un point d’accès permettant à notre plateforme cible de se connecter, d'un serveur DHCP, d'un serveur DNS (dnsmasq) et d'un proxy HTTPS (mitmproxy).

mitm

Fig. 2 : Schéma du dispositif utilisé pour les attaques HTTPS.

Le serveur DHCP envoie l'adresse du serveur DNS lors de la connexion au point d'accès. Les règles de routage permettent d'orienter tout le trafic sur le proxy HTTPS. Selon les besoins, le serveur DNS redirige la requête vers un serveur qui nous appartient.

Grâce à ce dispositif, nous pouvons tester trois attaques :

- le man-in-the-middle SSL/TLS  : cette attaque consiste à établir une connexion avec le client puis une connexion sécurisée avec le serveur et passer les données de l'un à l'autre en les espionnant ou les modifiant. Le serveur n'utilisant en général aucune authentification du client, cette connexion ne pose aucun problème. Le client cependant, authentifie le serveur. Il est donc nécessaire de générer un certificat au nom du serveur demandé. Ce certificat est donc signé par une autorité elle aussi générée.

- l'imposture de serveur : l'attaque consiste à rediriger le trafic vers un serveur web nous appartenant. Ce site présente un certificat valide et certifié par une autorité racine reconnue, mais le domaine ne correspond pas à celui demandé. Ce montage permet de savoir si l'application vérifie la bonne adéquation entre le domaine demandé et celui présent sur le certificat présenté.

- downgrade de connexion : l'attaque redirige le trafic vers un serveur non sécurisé (HTTP) en utilisant la fonction rewrite_url d'Apache. Nous testons ici si l'application requiert bien une connexion sécurisée.

Les deux dernières attaques s'avèrent négatives sur toutes les applications testées. En effet, celles-ci s'appuyant sur le framework commun, elles délèguent la sécurité HTTPS.

La première attaque peut être réalisée avec succès dans certains cas que nous allons détailler.

2.2.2 Compromission par ajout de certificat

Nous ajoutons notre certificat racine dans le magasin de certificat (Android et iOS). Nous notons qu'Android 6.0.1 affiche une alerte permanente qui prévient l'utilisateur que le réseau peut être surveillé.

L'insertion d'un certificat est relativement aisée. Il suffit de le télécharger puis de l'accepter lorsque reçu par mail par exemple. MITMProxy embarque même une interface ergonomique permettant de le faire rapidement et simplement en se connectant sur mitm.it lorsque le proxy est actif.

Même si notre certificat racine est considéré comme fiable, plusieurs applications comme Facebook Messenger ou Snapchat refusent la connexion.

Elles embarquent en effet leur propre magasin de certificats afin de ne pas dépendre du magasin de la plateforme et peuvent donc être plus restrictives.

2.2.3 Compromission de l’application

Pour espionner le trafic, il est donc nécessaire d'ajouter notre certificat aux stores d'applications. Le fichier CACertlist.plist contient par exemple les autorités de confiance de Facebook sur iOS. Signal-Android  embarque des fichiers .store contenant des certificats. L'accès à ce fichier nécessite néanmoins des droits privilégiés et par conséquent une compromission du système ou de l'application elle-même.

Telegram n'accepte toujours pas les connexions. En inspectant les sources, nous trouvons que celles-ci contiennent les clés publiques des serveurs codées en dur.

telegram_key

 Fig 3 : Clé publique Telegram : https://github.com/DrKLO/Telegram/blob/master/TmessagesProj/jni/tgnet/Datacenter.cpp.

2.2.4 Compromission de certificats racines

Les applications Telegram ou Signal n'embarquent que quelques certificats de confiance. A contrario, Facebook embarque une bonne centaine de certificats. On peut y retrouver des certificats racines gouvernementaux :

<X509Name object '/C=TW/O=Government Root Certification Authority'>

<X509Name object '/C=FR/ST=France/L=Paris/O=PM/SGDN/OU=DCSSI/CN=IGC/A/emailAddress=igca@sgdn.pm.gouv.fr'>

<X509Name object '/C=JP/O=Japanese Government/OU=ApplicationCA'>

<X509Name object '/C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden Root CA – G2'>

<X509Name object '/C=CN/O=China Internet Network Information Center/CN=China Internet Network Information Center EV Certificates Root'>

Ces certificats étant considérés comme de confiance, tous les certificats signés par eux seront également considérés comme sûrs. Il devient donc possible de signer un domaine *.google.com, *.facebook.com ou *.whatsapp.com. Ainsi, un proxy SSL disposant d'un tel certificat est capable d'intercepter le trafic sans alerter les parties.

Nous ajoutons dans le magasin de l'application Facebook notre certificat d'autorité racine MITM. L'application accepte désormais les connexions à notre MITMProxy et nous pouvons espionner tout le trafic. Aucune alerte n'est remontée par l'application qui se comporte normalement.

2.2.5 Récupération des tokens d'authentification

Afin de préserver l'expérience utilisateur, les applications ne demandent pas une authentification systématique de l'utilisateur. Le terminal stocke des identifiants de connexion ou plus précisément des tokens d'authentification pour obtenir une reconnexion automatique au service chaque fois que l'utilisateur ouvre l'application.

Ces tokens sont souvent stockés par les applications elle-mêmes, mais de plus en plus de terminaux fournissent des solutions plus sécurisées pour ces données, des keystores. Ces containers sont dans le meilleur des cas chiffrés avec le code utilisateur et avec une clé matérielle afin de prévenir toute récupération sans le passcode. Dans le pire des cas, les tokens voire les identifiants sont stockés en clair dans les keystores ou dans les bases de fonctionnement des applications.

Une fois ces tokens récupérés, il est possible de les utiliser via les API fournies par les services d'application soit directement, soit en se faisant passer pour l'application.

3. Interceptions

Les interceptions sont au cœur des polémiques de protection de la vie privée et de sécurité. Sont-elles possibles sur des applications de messagerie chiffrant de bout en bout ?

3.1 Groupes

Une première forme d'interception possible sur ce type de messagerie est les groupes. En effet, Telegram, Whatsapp ou Signal proposent de créer des groupes de conversations en invitant des contacts. Il suffit qu'un membre soit compromis pour que l'ensemble des conversations le soit, car même si le chiffrement est sécurisé, le message sera in fine déchiffré sur le terminal compromis.

3.2 Clone de SIM

La plupart des applications de messagerie demandent un numéro de téléphone comme identifiant principal lors de l'enrôlement. Ceci permet à un utilisateur de pouvoir reconfigurer sa messagerie lorsqu'il change de terminal, ceci sans interruption de service. Cependant, comme le démontre l'attaque de Positive Technologies dans Forbes [1], en usurpant le numéro de téléphone d'une cible, il est possible de configurer l'application pour utiliser le même identifiant et recevoir les messages qui lui sont destinés. Une simple vérification d'un code temporaire par message texte fait office d'authentification.

Le numéro de téléphone est considéré comme sûr, car lié à la carte SIM, elle-même élément de sécurité de l'opérateur. Cette carte, très bien protégée contient des clés secrètes permettant son identification sur le réseau et le chiffrement des échanges avec celui-ci. Son clonage intégral ne peut donc être réalisé que par le fondeur ou l'opérateur. Des attaques permettant l'accès et donc la copie des informations existent, mais elles sont extrêmement coûteuses en temps et en matériel.

Un autre moyen d'accéder à ces informations est de récupérer les clés de chiffrement chez les fondeurs. Une attaque de la NSA et du GCHQ ayant conduit au vol de millions de clés chez Gemalto a été révélée en 2015 [2].

3.3 Attaques sur SS7

Dans l'attaque de Positive Technologies [1], un élément essentiel du réseau est vulnérable. En exploitant cette vulnérabilité, ou en bénéficiant de complicités de personnes y ayant accès, il est possible de rediriger les échanges avec un numéro vers un autre terminal. Une fois cet accès établi, le deuxième terminal peut accéder aux conversations archivées.

3.4 Démo

Faisons un test simple basé sur l'attaque précédente. Prenons un téléphone A (captures supérieures sur la figure 4) sur lequel nous avons configuré notre messagerie Telegram grâce à notre numéro de téléphone et notre carte SIM. Prenons un deuxième terminal B, sur lequel nous installons l'application Telegram (captures supérieures sur la figure 4).

Pour la configuration, il est nécessaire d'entrer le numéro de téléphone de l'utilisateur. Ensuite, le mécanisme d'authentification est lancé. Dans notre cas, un code est envoyé sur l'application Telegram de l'appareil déjà connecté. Si cet appareil n'est pas connecté à Internet, un SMS est envoyé ou un appel est effectué.

Si le code temporaire entré est correct, l'application se connecte et a accès à toutes les conversations disponibles sur l'autre appareil.

Plus encore, tous les messages écrits ou reçus sur appareils sont mis à jour en temps réel sur l'autre appareil connecté, de manière transparente. La faille de sécurité repose donc ici sur la possibilité d'un accès physique ou à distance au terminal original en vue d'intercepter le code temporaire.

telegram

Fig. 4 : Exemple de configuration de l'application Telegram.

Conclusion

La sécurité des terminaux mobiles repose à la fois sur la sécurité du système embarqué et sur celle des applications. La cryptographie est largement utilisée pour contrôler l'authenticité et l'intégrité du code ou des serveurs ou pour garantir la confidentialité des données. Une infrastructure à clé publique est embarquée et est largement utilisée par le firmware, le système d'exploitation ou les applications.

Sur les plateformes haut de gamme Apple ou Android, les systèmes sont bien protégés et difficiles à compromettre. Néanmoins, il existe toujours des failles susceptibles de donner un accès super-utilisateur à un attaquant. Une fois le système compromis, il devient possible de compromettre les échanges, même sur des messageries sécurisées.

L'infrastructure à clé publique peut elle-même être une faille, car une autorité de certification racine bénéficie de la confiance pour signer tout certificat. Elle peut ainsi falsifier le certificat d'un domaine particulier et mettre en œuvre une attaque de type man-in-the-middle.

Enfin, les applications de messagerie stockent très souvent les données en ligne et il suffit de s'y connecter avec les bons identifiants pour récupérer voire écouter les conversations. Ces identifiants se résument dans la plupart des cas au numéro de téléphone et à un code temporaire envoyé par SMS. Par conséquent, un accès physique au téléphone de la cible permet de récupérer ce code et connecter un autre appareil sur le compte qui pourra récupérer les archives et recevoir les messages.

Références

[1] http://www.forbes.com/sites/thomasbrewster/2016/06/01/whatsapp-telegram-ss7-hacks/#65c4d43a745e

[2] http://bgr.com/2015/02/20/nsa-sim-card-hacking/


Sur le même sujet

Gérez, protégez et partagez vos mots de passe avec KeePassXC

Magazine
Marque
Linux Pratique
Numéro
117
|
Mois de parution
janvier 2020
|
Domaines
Résumé

Nous stockons de nombreuses informations, pour beaucoup sensibles, et dans des formats différents. Cela fait autant de mots de passe à créer, à retenir et à utiliser. À utiliser pour souvent quotidiennement, il faut donc que leur utilisation soit la plus transparente possible et s’adapte aux différents services clients : données sur une partition chiffrée, site internet, client d’une application bancaire, application en ligne de commandes. Vous utilisez peut-être déjà une extension web pour les sites web : c’est bien, mais cela ne gère pas tous vos besoins en mots de passe, mots de passe qui sont peut-être gérés par une société tierce sur leurs serveurs lorsque vous les rentrez dans l’extension. Dans cet article, nous allons découvrir KeePassXC, un gestionnaire de mots de passe libre qui vous permettra de répondre à tous types de besoins et de ne pas partager vos mots de passe avec une société tierce.

Désinstaller toutes vos applications Android indésirables sans « rooter » votre appareil

Magazine
Marque
Linux Pratique
Numéro
117
|
Mois de parution
janvier 2020
|
Domaines
Résumé

Lorsque vous faites l'acquisition d'un appareil, smartphone ou tablette, fonctionnant sous Android, ce dernier est généralement livré avec de nombreuses applications par défaut dont vous n'avez pas nécessairement l'utilité. Bien souvent il vous est impossible de les désinstaller de façon traditionnelle. Afin d'y parvenir, nombre de sites Internet vous préconisent de « rooter » votre appareil. En réalité, il n'en est rien et vous allez découvrir dans cet article comment faire avec des outils officiels.

Introduction au dossier : Ransomwares : état de la menace

Magazine
Marque
MISC
Numéro
107
|
Mois de parution
janvier 2020
|
Domaines
Résumé

Il ne se passe plus un mois sans qu’un ransomware ne touche une entreprise ou administration publique et que cette dernière se retrouve dans une situation délicate, au point que cela atterrisse invariablement dans les colonnes de nos quotidiens (oui bon, dans les bandeaux des chaînes d’information continue). On pourrait simplement dire que l’histoire se répète, qu’il s’agit d’un énième malware qui touche des infrastructures qui ne sont pas à jour, mal configurées, et que tout cela était inéluctable.

Utilisation de services en ligne légitimes par les malwares

Magazine
Marque
MISC
Numéro
107
|
Mois de parution
janvier 2020
|
Domaines
Résumé

Les fraudes sur Internet, qu’elles suivent une motivation financière ou autre, nécessitent généralement de l’ingénierie sociale, ou l’utilisation de malwares. Ces derniers sont plus ou moins furtifs au niveau de leur comportement sur le poste de travail infecté, mais aussi lors de leurs communications sur le réseau avec leur contrôleur, ou serveur de « command and control » (C2). Voulant rendre leur trafic moins détectable, certains cybercriminels ont misé sur l’utilisation de plateformes et services légitimes en ligne. Bien que cette méthode ne soit pas nouvelle en soi, elle tend à être de plus en plus utilisée depuis quelques années.

Programmation UEFI

Magazine
Marque
MISC
Numéro
107
|
Mois de parution
janvier 2020
|
Domaines
Résumé

La deuxième étape de la compréhension du système UEFI va s’articuler autour de l’implémentation en C avec l’optique de fabriquer sa propre brique UEFI. Le développement va permettre d’illustrer le processus de la chaîne de boot avec pour objectif de mieux appréhender les différentes problématiques de sécurité.

Par le même auteur

Sécurité des terminaux mobiles

Magazine
Marque
MISC
Numéro
91
|
Mois de parution
mai 2017
|
Domaines
Résumé
La sécurité des mobiles et des communications est un enjeu à la fois pour la vie privée, la liberté, mais aussi pour la sécurité des personnes et des pays. Comment résistent les applications de messageries instantanées aux attaques sur les systèmes et/ou les réseaux ?

Fraude aux mouchards bancaires (« skimming ») et analyse forensique

Magazine
Marque
MISC
Numéro
77
|
Mois de parution
janvier 2015
|
Domaines
Résumé
La fraude aux moyens de paiement s’élève à plus de 450 millions d’euros par an en France [1]. Nous présenterons dans cet article les dispositifs qu’utilisent les fraudeurs pour capter les données des cartes de paiement puis nous dévoilerons, sans outrepasser la confidentialité liée à ces techniques sensibles, quelques procédés d’analyse de ces systèmes.