Chiffrement des données utilisateurs sous Android

Magazine
Marque
MISC
Numéro
58
|
Mois de parution
novembre 2011
|
Domaines


Résumé
Depuis quelques mois, on voit fleurir sur Internet des alertes de sécurité concernant des malwares, vulnérabilités et fuites d'informations personnelles touchant le système d'exploitation mobile de Google : Android. Il est donc légitime de se demander s'il est possible de sécuriser les données personnelles manipulées par ce système. L'objectif de cet article est de vous présenter la mise en place d'un mécanisme de chiffrement de vos données sur votre terminal Android.

Body

1. Introduction

1.1. Intérêt du chiffrement sur les terminaux mobiles

Bien qu'il ne protège pas contre toutes les formes de fuites de données (transmissions d'identifiants en clair ou de la position de l'utilisateur par des applications), le chiffrement des données stockées sur un terminal mobile se révèle une solution adaptée en cas de perte ou de vol de l'appareil. Il peut, en effet, être problématique pour une entreprise de voir disparaître dans la nature des informations sensibles via ces terminaux pas ou peu sécurisés.

Android a par ailleurs un retard à combler dans ce domaine. L'iPhone d'Apple propose un chiffrement matériel AES 256-bits ainsi que la possibilité de chiffrer les e-mails et les pièces jointes [APPL], tandis que RIM Blackberry chiffre la totalité des données émises par ses appareils à l'aide d'un triple chiffrement DES ou AES 256-bits.

Il est tout de même à noter que concernant l'iPhone, le chiffrement matériel a déjà été partiellement contourné, permettant ainsi de récupérer sur un appareil a priori chiffré des données telles que des clés d'authentification Wi-Fi et des identifiants VPN [IPHO].

La société Whisper Systems, qui a dans un premier temps mis en œuvre une solution de chiffrement des appels, propose à présent un chiffrement de l'intégralité du contenu pour les terminaux Android.

Il s'agit d'un système Android modifié pour intégrer un chiffrement bas niveau des données stockées en utilisant une version modifiée du système de fichiers YAFFS [WHS]. Ce système Android clés en main n'est malheureusement disponible que pour le Nexus S et le Nexus One pour l'instant.

Pour sa part, Google fournit depuis Android 3.0, alias Honeycomb, un système similaire de chiffrement des données utilisateurs. Malheureusement, cette version se limite aux tablettes tactiles et l'entreprise de Mountain View semble réticente à rendre publics le type de chiffrement pratiqué ainsi que le code source de cette dernière mouture de leur système d'exploitation mobile [HONE].

Au cours de la dernière Google I/O, il a pourtant été annoncé que la prochaine version d'Android censée unifier tablettes et smartphones, nommée Ice Cream Sandwich, inclurait de nombreuses fonctionnalités issues de Honeycomb [IO11]. Au moment où nous rédigeons cet article, rien n'a encore été révélé concernant un éventuel chiffrement des données internes...

Les possibilités sont donc pour l'instant limitées à quelques terminaux et il nous a paru intéressant de mettre en œuvre une modification pouvant être réalisée sur tout type d'appareil Android.

1.2. Pré-requis

La mise en place d'un système de chiffrement avec authentification pre-boot pour Android étant une modification intervenant en profondeur sur le système d'exploitation, certains pré-requis sont nécessaires.

1.2.1. SDK, sources et accès root

La présence du SDK Android est indispensable afin de disposer des outils d'interaction avec le terminal mobile (adb notamment) et si nous optons pour la création d'une version modifiée d'Android, il faudra se procurer les sources nécessaires[AOSP].

Néanmoins, en fonction du matériel utilisé, l'utilisation des sources fournies par l'Android Open Source Project ne sera pas forcément suffisante. Certains composants du firmware sont en effet propriétaires et il sera nécessaire d'extraire au préalable ceux-ci du terminal.

De plus, un accès total au système est nécessaire, il faudra donc disposer d'un terminal débloqué disposant des droits d'accès root.

La solution la plus simple à mettre en place sera de modifier le système déjà existant (au risque de perdre en stabilité du système, voir partie 3 Chiffrement de l'intégralité des données utilisateurs) ou de modifier un firmware non officiel.

Nos tests ont été effectués sur un firmware modifié CyanogenMod 7.0.3 [CYAN] sans problème de stabilité.

1.2.2. Portage de cryptsetup

Afin de chiffrer nos données, nous allons tirer parti du fait que le noyau Android supporte le module dm-crypt[DMC]. Pour cela, il faudra disposer d'un exécutable compilé pour l'architecture des terminaux Android (architecture ARM), fort heureusement quelques acharnés du système d'exploitation mobile se sont déjà donnés la peine de cross-compiler cryptsetup [CRYP].

2. Création d'un conteneur sécurisé

En guise d'introduction, nous allons créer un conteneur chiffré situé sur la carte SD du terminal afin d'y stocker nos données privées.

La manipulation est relativement simple à effectuer, particulièrement pour les utilisateurs réguliers de LUKS sous Linux, et se résume ainsi :

1. création d'un fichier de la taille souhaitée qui servira de conteneur ;

2. montage du fichier sur un loopback device ;

3. création d'un système de fichiers valide ;

4. chiffrement à l'aide de cryptsetup ;

5. déchiffrement et montage pour l'utilisation.

2.1. Préparation du conteneur sur la carte SD

En premier lieu, il faut pousser l’exécutable cryptsetup récupéré plus haut (voir partie 1.2.2 Portage de cryptsetup) sur le système Android :

# adb remount

remount succeeded

# adb push cryptsetup /system/bin

[...]

# adb shell

# chmod 755 /system/bin/cryptsetup

Nous créons à présent un fichier de 1Go sur la carte et nous le montons sur un loopback device.

Nous l'avons nommé .tmp. Bien sûr, ce nommage ne trompera pas un attaquant déterminé, mais il est toujours bon de ne pas attirer l'attention et préfixer le nom d'un point dupera les explorateurs de fichiers de mauvaise qualité ou mal configurés.

# dd if=/dev/zero of=/mnt/sdcard/.tmp bs=1024 count=100000

# mknod /dev/loop0 b 7 0

100000+0 records in

100000+0 records out

102400000 bytes transferred in 18.133 secs (5647162 bytes/sec)

# losetup /dev/loop0 /mnt/sdcard/.tmp

Utilisons à présent cryptsetup pour préparer le conteneur :

# cryptsetup luksFormat -c aes-plain /dev/loop0

WARNING!

========

This will overwrite data on /dev/loop0 irrevocably.

Are you sure? (Type uppercase yes): YES

Enter LUKS passphrase: **************

Verify passphrase:

# cryptsetup luksOpen /dev/loop0 vault

Enter passphrase for /dev/loop0: **************

# cryptsetup status vault

/dev/mapper/vault is active.

  type: LUKS1

  cipher: aes-cbc-plain

  keysize: 256 bits

  device: /dev/loop0

  offset: 4096 sectors

  size:    195904 sectors

  mode:    read/write

Le chiffrement est en place, il ne reste plus qu'à créer le système de fichiers :

#mke2fs -O uninit_bg,resize_inode,extent,dir_index -L Vault0 -FF /dev/mapper/vault

mke2fs 1.41.10 (10-Feb-2009)

Filesystem label=Vault0

OS type: Linux

Block size=1024 (log=0)

Fragment size=1024 (log=0)

Stride=0 blocks, Stripe width=0 blocks

[...]

Writing inode tables: done                            

Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 25 mounts or

180 days, whichever comes first. Use tune2fs -c or -i to override.

et à le monter :

# mkdir /mnt/sdcard/vault

# mount /dev/mapper/vault /mnt/sdcard/vault

2.2. Création des scripts d'utilisation

Afin de faciliter l'utilisation de notre conteneur, nous écrivons un jeu de scripts pour l'ouvrir et le fermer.

Voici le script permettant de monter et d'ouvrir le conteneur :

#!/system/bin/sh
mknod /dev/loop0 b 7 0

losetup /dev/loop0 /mnt/sdcard/.tmp

cryptsetup luksOpen /dev/loop0 vault

mount /dev/mapper/vault /mnt/sdcard/vault

ainsi que le script permettant de démonter la partition et fermer le conteneur :

#!/system/bin/sh
umount /mnt/sdcard/vault

cryptsetup luksClose vault

Nous disposons à présent d'un répertoire sur la carte SD activable et désactivable à volonté, où les données déposées sont chiffrées et protégées par un mot de passe.

3. Chiffrement de l'intégralité des données utilisateurs

Android répartit ses données dans quatre partitions :

- /system : contient les applications système, les bibliothèques, les fichiers de configuration et le framework Android, elle est montée en lecture seule.

- /cache : stocke le cache des applications Android.

- /sdcard ou /mnt/sdcard selon les appareils : comme son nom l'indique, c'est le point de montage de la carte micro SD.

- /data : c'est là que sont stockées les applications installées par l'utilisateur ; y sont également stockés les paramètres et les préférences pour ces applications dans des bases de données SQLite.

C'est cette dernière partition que nous souhaitons chiffrer afin de protéger les données sensibles (applications installées, mots de passe et réglages dans les bases de données, etc.).

La démarche de chiffrement des données utilisateurs demandant la migration de toutes les données de la partition /data dans un conteneur, il est préférable d'appliquer ces modifications au système Android avant de l'installer sur le terminal.

En effet, la copie du contenu de /data pendant l’exécution du système peut poser problème (permissions, fichiers temporaires, liens symboliques, etc.) ; il ne s'agit pas d'une méthode fiable, et au cours de nos tests, certaines applications se sont révélées instables et ont dû être réinstallées pour fonctionner à nouveau normalement.

3.1. Préparation de la partition chiffrée

Disposant d'une partition /data d'environ 210 Mo, nous reprenons donc les manipulations de la partie précédente pour créer un nouveau conteneur. Il est légèrement plus petit que la taille de la partition afin de pouvoir loger sur cette même partition /data, 10 Mo de marge sont plus que suffisants :

# dd if=/dev/zero of=/tmp/data.encrypted bs=1M count=200

# mknod /dev/loop0 b 7 0

# losetup /dev/loop42 /tmp/data.encrypted

# cryptsetup luksFormat -c aes-plain /dev/loop0

# cryptsetup luksOpen /dev/loop42 data

# mke2fs -O uninit_bg,resize_inode,extent,dir_index -L Data0 -FF /dev/mapper/data

# mount /dev/mapper/data /mnt

Nous déposons ensuite le fichier sur /data afin de pouvoir y accéder durant la phase de boot du terminal.

3.2. Modification des scripts de démarrage d'Android

Le processus de démarrage d'Android de résume en deux phases principales :

1. Le lancement du processus init et l’exécution d'un script init.rc qui se charge de créer l'arborescence du système, de monter les partitions, puis de lancer les différents services.

2. L'appel par init.rc du processus zygote,une base pour les applications Android qui sont des forks de ce processus.

3.2.1. Écriture d'un programme de déblocage pre-boot

Afin de pouvoir déchiffrer et monter la partition /data avant son utilisation par le processus de démarrage ou par zygote, il est nécessaire de disposer d'un programme pouvant s'insérer au début d'init.rc afin de procéder à l'authentification.

Pour l'exemple, nous avons écrit un programme en C volontairement simpliste donnant le mot de passe à cryptsetup :

int main(int argc, char **argv, char **envp)

{

  char buffer[2048];

  char passphrase[1024] = "ma passphrase";

  bzero(buffer, sizeof(buffer));

  snprintf(buffer, sizeof(buffer) – 1,

 "echo %s | /system/bin/cryptsetup luksOpen /dev/block/loop0 data", passphrase);

  system(buffer);

  return (0);

}

Le binaire devra être compilé pour la plate-forme ARM et de préférence sous forme statique afin de ne dépendre d'aucune bibliothèque qui pourrait ne pas être accessible à cette étape du processus de démarrage.

Évidemment, l'utilisation d'un programme contenant le mot de passe en dur dans le code annule la sécurité apportée par le chiffrement...

Une solution plus pertinente serait l'écriture d'un programme nous permettant de demander un mot de passe à l'utilisateur au tout début de la séquence de démarrage afin de déchiffrer les données contenues sur le smartphone. Cette opération se déroulant avant le chargement complet du système Android (qui dépend des données chiffrées), il faudra donc écrire un programme utilisant par exemple la libminui, habituellement utilisée pour la création de programmes pour la partition de recovery. Cette tâche relativement complexe pourrait faire à elle seule l'objet d'un article.

Certains développeurs de firmwares alternatifs intégrant le chiffrement dans leur version modifiée d'Android ont par ailleurs déjà développé de tels programmes d'authentification, proposant ainsi des systèmes d'authentification allant de la simple entrée texte jusqu'à la génération de mot de passe complexe en utilisant des motifs graphiques [XDA].

menu

Fig. 1 : Exemple de programme d'authentification pre-boot pour Android

Des alternatives telles que la présence de certificats sur support amovible ou l'identification biométrique sont également à envisager sur ces terminaux dont le matériel évolue très rapidement. Il existe par ailleurs des cartes micro SD intégrant une puce RFID, pouvant permettre, par exemple, le démarrage du terminal et le déchiffrement de ses partitions tout en servant de support de données amovible. Certaines solutions de conteneurs chiffrés à authentification biométrique existent [BIO], mais à notre connaissance, aucune solution de ce type n'autorise le déchiffrement avant le chargement du système d'exploitation Android.

3.2.2. Édition de init.rc

Avec notre programme d'authentification sous la main, il nous faut à présent modifier le script de démarrage d'Android.

Durant son démarrage, Android interagit de manière répétée avec la partition data (création de cache, lecture des bases SQLite, etc.). Il nous faut donc intervenir le plus tôt possible dans le processus de démarrage.

Il faut identifier les lignes qui correspondent au montage des partitions et y insérer nos instructions :

[...]
on fs

# mount mtd partitions

# Mount /system rw first to give the filesystem a chance to save a checkpoint

mount yaffs2 mtd@system /system

mount yaffs2 mtd@system /system ro remount

# création d'un point de montage pour la partition data (qui ne contient plus qu'un fichier chiffré)
 mkdir /encrypted-data 0771 system system
 mount yaffs2 mtd@userdata /encrypted-data nosuid nodev

# mount yaffs2 mtd@userdata /data nosuid nodev

mount yaffs2 mtd@cache /cache nosuid nodev
# montage du fichier chiffré sur un loopback device

exec /system/bin/losetup /dev/block/loop0 /encrypted-data/data.encrypted

# lancement de notre programme d'authentification

exec /system/bin/unlock

# montage de notre partition déchiffrée sur /data

mount ext2 /dev/mapper/data /data

[...]

Pour les manipulations décrites ici, tous les programmes utilisés ont été placés dans /system/bin/ avec les permissions d’exécution.

Bien que les manipulations décrites ici s'inscrivent dans le cadre de la création d'une version modifiée d'Android, il peut également être intéressant d'appliquer ce chiffrement sur un système déjà existant, auquel cas modifier le script init.rc peut se révéler plus difficile.

En effet, la partition /system contenant l'arborescence de base d'Android est un ramdisk accessible uniquement en lecture seule, il faut donc l'extraire du système pour le modifier.

Première étape, identifier la partition boot :

# cat /proc/mtd | grep boot

mtd0: 00300000 00020000 "boot"

Nous pouvons ensuite effectuer un dump de la partition sur la carte SD :

# cat /dev/mtd/mtd0 > /mnt/sdcard/boot.img

# exit

# adb pull /mnt/sdcard/boot.img

Nous récupérons donc une image contenant un en-tête de 2Ko, le kernel (compressé avec gzip) et le ramdisk. La méthode la plus simple pour manipuler cette image est d'utiliser deux scripts Perl (unpack-bootimg.pl et repack-bootimg.pl) dont l'utilisation est largement répandue parmi les développeurs de firmwares alternatifs [BOOT].

Le premier se charge simplement de supprimer l’en-tête puis d'extraire le kernel et le ramdisk :

# ,/unpack-bootimg.pl boot.img

kernel written to boot.img-kernel.gz

ramdisk written to boot.img-ramdisk.cpio.gz

gzip: ../boot.img-ramdisk.cpio.gz: decompression OK, trailing garbage ignored

713 blocks

extracted ramdisk contents to directory boot.img-ramdisk/

# ls -l

total 6148

-rw-r--r-- 1 root root 3145728 2011-05-20 07:38 boot.img

-rw-r--r-- 1 root root 2168832 2011-05-20 07:39 boot.img-kernel.gz

drwxr-xr-x 8 root root    4096 2011-05-20 07:39 boot.img-ramdisk

-rw-r--r-- 1 root root 974848 2011-05-20 07:39 boot.img-ramdisk.cpio.gz

Nous retrouvons dans boot.img-ramdisk l'arborescence de base du système et le fichier init.rc.

Une fois les modifications apportées à init.rc, nous pouvons rassembler le tout avec le script repack-bootimg.pl :

# ./repack-bootimg.pl boot.img-kernel.gz boot.img-ramdisk new-boot.img

[...]

repacked boot image written at boot.img-ramdisk-repack.img

Il ne reste plus qu'à écraser l'ancienne partition boot du terminal avec notre nouvelle image :

# adb push new-boot.img /sdcard/

# adb shell

# flash_image boot /sdcard/new-boot.img

# reboot

Conclusion

Nous disposons donc à présent d'un conteneur chiffré qu'il est possible d'étendre à toute la carte SD. Avec quelques manipulations supplémentaires, un chiffrement complet de toutes les données contenues sur la partition userdata(/data) est également possible, nous permettant ainsi de protéger l'intégralité des données utilisateurs contre les attaques off-line.

L'utilisation du terminal et des applications stockées sur cette partition chiffrée ne semble pas être impactée en termes de performances. Nous n'avons noté aucun ralentissement ou dysfonctionnement majeur de l'environnement Android et nous n'avons pas perçu d’éventuelle perte d'autonomie de la batterie.

On peut toutefois noter que le niveau de sécurité dépendra du système d'authentification utilisé et l'emploi d'un mot de passe fort est recommandé (plus de 14 caractères, avec majuscules, chiffres et caractères spéciaux).

La partition /boot ne pouvant être chiffrée de la manière décrite ici, une personne ayant un accès physique au terminal pourra en effet assez rapidement analyser le fonctionnement du système déployé et tenter de décompiler le programme d'authentification pre-boot pour analyser son fonctionnement.

Les données étant stockées sous forme de fichier conteneur, l'extraction de celui-ci afin de tenter un cassage hors-ligne est possible. De plus, comme quasiment tous les systèmes de chiffrement de disques, LUKS garde en RAM la passphrase et est donc vulnérable à des attaques de type cold-boot.

D'une manière générale, il s'agit plus d'une forme de dissuasion, puisqu'à partir du moment où il obtient un accès physique au terminal, il est fort probable qu'un attaquant déterminé parvienne à en extraire des données. Ce n'est qu'une question de temps et de moyens.

Références

[APP] http://images.apple.com/iphone/business/docs/iPhone_Security.

[BLACK] http://docs.blackberry.com/en/admin/deliverables/7325/How_BESolution_uses_TDES_to_encrypt_data_834425_11.jsp

[IPHO] http://www.sit.fraunhofer.de/forschungsbereiche/projekte/Lost_iPhone.jsp

[WHS] http://www.whispersys.com/whispercore.html

[HONE] http://www.engadget.com/2011/02/02/android-3-0-honeycomb-can-encrypt-all-your-data-needs-a-full/

[IO11] http://www.talkandroid.com/40365-chief-announcements-from-google-io-keynote-ice-cream-sandwich-updates-to-honeycomb-usb-host-support-movie-rentals-music-and-a-commitment-to-updates/

[AOSP] http://source.android.com/

[CYAN] http://www.cyanogenmod.com/

[DMC] http://www.saout.de/misc/dm-crypt/

[CRYP] https://androidvoid.wordpress.com/2009/09/30/android-encryption-using-cryptsetup-and-luks/

[XDA] http://forum.xda-developers.com/showthread.php?t=881850

[BIO] http://www.mobbeel.com/products/biowallet/overview/

[BOOT] http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images


Sur le même sujet

L’intégration du « Privacy by Design » et de la SSI dans la gestion de projets en mode V ou Agile

Magazine
Marque
MISC
Numéro
106
|
Mois de parution
novembre 2019
|
Domaines
Résumé

L’analyse de l’actualité ne cesse de nous alerter sur la très faible prise en compte de la sécurité native dans un grand nombre de projets et plus particulièrement sur la sous-estimation de l’intégration des exigences de protection de la vie privée.Les articles 25 du RGPD « Protection des données dès la conception et protection des données par défaut » et 32 « Sécurité du traitement », formalisent l’obligation pour le responsable du traitement de prendre en compte les exigences juridiques et techniques pendant toutes les phases des projets de la conception jusqu’à la fin de vie du système cible.Nous nous attacherons à identifier les principaux acteurs concernés et leurs modes de concertation dans les gestions de projets en V ou Agile.Nous chercherons à souligner les points d’attention et d’amélioration dans les deux méthodes.

F-Droid - Votre catalogue d’applications libres et open source

Magazine
Marque
Linux Pratique
Numéro
116
|
Mois de parution
novembre 2019
|
Domaines
Résumé

Si vous utilisez un terminal Android, vous avez sans doute pour habitude de lancer par défaut le Play Store de Google pour trouver de nouvelles applications à installer sur votre appareil. Saviez-vous cependant qu’il existait un autre catalogue dont la particularité est de recenser toutes les applications mobiles libres et open source développées pour la plateforme Android ? Il se nomme F-Droid et pourra être installé rapidement sur votre mobile/tablette. 

Richelieu : solution du challenge de la DGSE

Magazine
Marque
MISC
Numéro
106
|
Mois de parution
novembre 2019
|
Domaines
Résumé

En mai 2019, la DGSE (Direction Générale de la Sécurité Extérieure) a organisé pour la première fois un challenge de sécurité informatique ouvert au public, qu’elle a baptisé Challenge Richelieu. Je vous invite à écouter la bande originale du Bureau des Légendes en fond sonore. Imprégnez-vous de cette atmosphère pleine de tension où les secrets sont rois, puis regardons ensemble ce que nous réservait ce challenge.

Auditer la sécurité d'une application iOS

Magazine
Marque
MISC
Numéro
106
|
Mois de parution
novembre 2019
|
Domaines
Résumé

Auditer la sécurité d'une application iOS n'est toujours pas une tâche aisée. Force est de constater que la plupart des auditeurs, amateurs de bug bounty ou autres curieux préfèrent travailler sur les applications Android malgré les récentes protections ajoutées au système d'exploitation de Google. Nous allons malgré tout essayer de présenter une méthodologie qui rend possible l'analyse orientée sécurité d'une application iOS, même sans jailbreak. Un bref rappel sera effectué pour ensuite introduire quelques outils et documentations apparues ces derniers mois.

Sondes de détection : performances, évaluations et biais

Magazine
Marque
MISC
Numéro
106
|
Mois de parution
novembre 2019
|
Domaines
Résumé

En avril 2019, l’ANSSI a qualifié les premières sondes pour assurer la supervision de sécurité de réseaux. Les opérateurs d’importance vitale (OIV), les opérateurs de services essentiels (OSE) et, d’une manière générale, les organismes opérant des fonctions sensibles disposent ainsi de produits français de confiance : Cybels Sensor de Thales et Trackwatch Full Edition de Gatewatcher.La méthodologie d’évaluation des sondes n’est, hélas, pas publique. Les ingénieurs sécurité et réseau devant intégrer ces sondes ne disposent donc pas de guides pour effectuer la recette de leur efficacité en production. Cet article propose un retour d’expérience sur l’évaluation des sondes, notamment sous l’angle de la performance. Cet aspect est, en effet, particulièrement significatif puisque le taux de détection d’une sonde diminue si elle est submergée, quand bien même elle serait équipée des meilleurs signatures et moteurs d’analyse.

Par le même auteur

Contournement de l'API Google Play Billing

Magazine
Marque
MISC
Numéro
106
|
Mois de parution
novembre 2019
|
Domaines
Résumé

D'après le blog [INVESP], le montant global des paiements dits « in-app » représentait environ 37 milliards de dollars (USD) en 2017 pour les applications mobiles (Android et Apple). Ce montant représente quasiment la moitié des revenus générés par les applications mobiles (48,2%), dépassant les revenus générés par les régies publicitaires (14%), ainsi que l'achat d'applications (37,8%). Il est donc important que la sécurité de ces paiements soit correctement implémentée afin d'éviter un manque à gagner pour les développeurs des applications. Dans le cadre de cet article, nous avons passé en revue 50 applications Android afin d'étudier le fonctionnement de l'API Google Play Billing et d'identifier les vulnérabilités liées à une mauvaise implémentation. Nous détaillerons en exemple des applications vulnérables.

Attaques sur SMB

Magazine
Marque
MISC
HS n°
Numéro
20
|
Mois de parution
octobre 2019
|
Domaines
Résumé

Le service SMB est un point d’entrée privilégié et incontournable sur les systèmes Windows. Easy mode du pentest, en somme. Petit tour d’horizon des vulnérabilités qui l’affectent.

Retour sur les faiblesses de l’authentification Windows

Magazine
Marque
MISC
Numéro
103
|
Mois de parution
mai 2019
|
Domaines
Résumé
Nous faisions dans MISC n°68 un état des lieux des traces d’authentification laissées par les protocoles d’administration les plus répandus en environnement Windows. Celles-ci restent un « must », récupéré et réutilisé par les attaquants et les pentesters afin de rebondir et d’élever ses privilèges sur les réseaux. Faisons le point 5 ans après.

Metasploit is not an exploit framework

Magazine
Marque
MISC
HS n°
Numéro
14
|
Mois de parution
octobre 2016
|
Domaines
Résumé

Pour tout pentesteur, Metasploit est incontournable. Grâce à ce framework, les professionnels comme les script-kiddies ont accès à une large base de données de codes d’exploitation relativement fiables, clef en main. Il suffit de quelques lignes de commandes, voire de quelques clics si on utilise Armitage, pour exploiter des vulnérabilités parfois critiques. Même pas besoin de comprendre ! Cet article ne se concentrera absolument pas sur cet aspect et tentera plutôt de vous démontrer qu’il s’agit surtout d’un merveilleux outil de gestion, bien plus efficace qu’Excel en test d’intrusion.

Cinq façons de devenir administrateur de domaine avec Metasploit

Magazine
Marque
MISC
HS n°
Numéro
14
|
Mois de parution
octobre 2016
|
Domaines
Résumé

En test d'intrusion interne, la compromission d'un domaine Windows est quasi-systématique. Les différentes protections mises en place ne font que ralentir la progression de l'attaquant ou l'auditeur. Dans cet article, nous n'allons pas vous apprendre à effectuer un test d'intrusion, mais vous présenter 5 scénarios d'attaques qui vous permettront de compromettre un domaine Windows rapidement et quasiment à coup sûr à l'aide de Metasploit.