E D I T O

2017, une année noire…

…pour de nombreuses entreprises victimes d’attaques destructrices (#NotPetya) et de fuites de données massives mettant en cause plus ou moins directement les fournisseurs Cloud (#Yahoo, #Deloitte, #Equifax, #Uber, #USArmy, #NSA, #AWS et tant d’autres…).

La fin d’année et l’explosion du cours du bitcoin aura même permis de revoir des attaques sur les wallets bitcoin et les javascripts mineurs de bitcoin, comme nous avons pu le voir récemment lors d’une affaire traitée par notre

équipe CERT-W.

Outre ces affaires, nous vous proposons ci-dessous un rapide aperçu de quelques interventions effectuées par notre équipe ces trois derniers mois :

/ Des victimes des bruteforces sur Office 365 ayant abouti à des compromissions de compte. Quelques impacts :

• Détournement de virements bancaires.

• Blocage de plus 800 comptes utilisateurs.

/ Deux victimes de ransomwares se propageant par RDP (famille DHARMA/CRYSIS).

/ Une suspicion de compromission après la découverte d’un nom d’utilisateur en sinogrammes (retour d’expérience dans la suite de cette lettre).

/ Une tentative de déstabilisation d’un grand groupe au travers d’une campagne de diffamation.

/ Un poste de travail compromis par plusieurs malwares… de +10 ans d’âge (2001 : Magistr.a@MM, 2004 : Netsky – par le créateur de Sasser, 2009 : Kakworm…).

/ Une suspicion de compromission sur des terminaux iOS.

Si aucune tendance particulière ne se dégage réellement, nous sommes prêts à parier nos wallets bitcoin que les attaques sur les fournisseurs Cloud vont continuer à se généraliser… enfin, sauf si Meltdown et Spectre nous apportent la fin du monde !

Vincent Nguyen, manager, responsable du CERT-WAVESTONE

L E T T R E D U C E R T- W a v E s T o n En ° 9

CERT-wLA LETTRE DES

EXPERTS SÉCURITÉ

sommaiRE

Nicolas DAUBRESSE

UTILISATION DES MÉTADONNÉES DE RÉPLICATION, QUAND LES jOURNAUX fONT DÉfAUT......................................................... 2

François LELIEVRE

HOUSTON, WE’vE gOT A CHINESE ACCOUNT ON OUR SYSTEM ........................... 5

Madhi BRAIK

HITB2017 - WHEN TWO-fACTOR AUTHENTICATION IS A fOE: BREAKINg APPLE’S ICLOUD KEYCHAIN ........................... 7

Cyprien OGER

CvE-2017-11776 : OUTLOOK vS S/MIME .. 10

Thomas DEBIZE

CE QUI A CHANgÉ POUR L’ÉPINgLEMENT DE CERTIfICAT à PARTIR D’ANDROID 7 NOUgAT .....................................................................11

2

UTIl IsaTIOn DEs méTaDOnnéEs DE réplIcaTIOn, QUanD lEs jOUrnaUx fOnT DéfaUT

i n T R o d u C T i o n a u x d o n n é E s d E R é p l i C aT i o n d E l’a C T i v E d i R E C T o R yAu sein d’un domaine Active Directory se trouvent généralement plusieurs contrôleurs de domaine qui nécessitent de disposer des mêmes informations. Pour parvenir à cela, l’Active Directory dispose d’un mécanisme de réplication qui permet, entre autres, de propager un changement depuis un con-

trôleur de domaine vers les autres.

Dans son processus de réplication, l’Active Directory utilise des USN (Update Sequence Number) pour déterminer l’état des con-trôleurs de domaines. Ces USN représentent un compteur stocké dans la base de données de l’Active Directory, qui est incrémenté à chaque changement de cette base au niveau d’un contrôleur de domaine. Chaque con-trôleur de domaine dispose alors d’un USN qui lui est propre.

Lorsqu’un changement d’une information de l’Active Directory intervient sur un contrôleur

de domaine, deux cas peuvent se présenter :

/ L’information modifiée n’est pas une information répliquée entre les différents contrôleurs de do-maines. C’est le cas de l’ensemble des attributs de l’Active Directory qui disposent du flag fLAg_ATTR_NOT_REPLICATED[1] comme par exemple l’attribut « BadPwdCount » qui tient compte du nombre de ten-tatives de connexion échouées :

/ Dans ce cas, le contrôleur de do-maine effectue la modification dans sa propre base de données, mais ne transmet rien aux autres contrô-leurs de domaine. Il est donc à no-ter qu’il est possible de multiplier le nombre maximum de tentatives de connexions erronées avant blocage d’un compte en réalisant les tenta-tives d’authentification auprès de contrôleurs de domaines distincts.

/ L’information modifiée nécessite une réplication entre les différents contrôleurs de domaines. Dans ce cas, le contrôleur de domaine qui a reçu le changement utilise le modèle de réplication de l’Active Directory pour transmettre le changement aux autres contrôleurs du domaine. Ce modèle de réplication ne sera pas dé-taillé dans cet article, mais permet la diffusion des évolutions à l’ensemble des contrôleurs d’un domaine en li-mitant le trafic nécessaire et en assu-rant la gestion des collisions (en cas de changement d’un même attribut sur différents contrôleurs sur une fe-nêtre de temps réduite).

Le processus de réplication utilise des métadonnées qui sont conservées sous la forme de deux attributs distincts : msDS-ReplAttributeMetaData[2] et msDS-Replval-ueMetaData[3]. msDS-ReplAttributeMeta-Data est utilisé pour les changements effectués sur les attributs non linkés de l’Active Directory alors que msDS-Replval-ueMetaData est réservé aux attributs linkés.

Les attributs linkés ont été introduits dans l ’Act ive Directory à partir du niveau fonc-tionnel Windows Server 2003. Ce sont en fait des paires d’attributs dont la valeur de l’un est basée sur celle de l’autre. C’est par exemple le cas des attributs member d’un groupe et memberof de l’utilisateur.

Q u E l i n T é R ê T p o u R l’ i n v E s T i g aT i o n   ?En tant qu’analyste forensic qui intervient

suite à un incident de sécurité, le premier

réflexe pour permettre d’identifier les

actions malveillantes ayant eu lieu au sein

d’un Active Directory est l’utilisation des

journaux d’événements. Mais que faire si

ceux-ci n’étaient pas activés au moment

de l’attaque ? Ou si l’attaquant est parvenu

à supprimer les journaux générés par ses

actions, comme le permet un outil comme

mimikatz[4] ?

Dans de telles situations, il est possible

d’utiliser les données de réplication pour

obtenir une vision partielle des actions

des attaquants. En effet, d’après le fonc-

tionnement des données de réplication,

toute modification d’un attribut de l’Active

Directory aboutit à la création d’une don-

née de réplication contenant différentes

informations pouvant être utile pour une

investigation.

Dans le cas d’un attribut non linké, et donc

d’une métadonnée de type msDS-ReplAt-

tributeMetaData, les informations stockées

sont la version, qui correspond au nombre de

changements de l’attribut depuis sa création,

la date à laquelle a été effectuée la modifica-

tion, l’USN correspondant au changement

pour le contrôleur de domaine qui a initié la

réplication, l’USN correspondant au change-

ment pour le contrôleur de domaine sur

lequel est récupéré la métadonnée, ainsi que

l’UUID et le DN du contrôleur de domaine

ayant initié le changement :

Pour les attributs linkés, les métadonnées de

réplication, cette fois de type msDS-Replval-

ueMetaData, vont également stocker des

informations sur les attributs liés à l’attribut

en question. Les métadonnées de réplica-

tion vont alors conserver des informations

sur chacune des propriétés de l’attribut lié, y

compris pour les valeurs précédentes. Dans

l’exemple de l’attribut member, les données

de réplication conserveront donc à la fois

des informations sur les membres actuels du

groupe, mais également sur les utilisateurs

ayant été membres mais ne l’étant plus :

3

A un instant donné, il est alors possible grâce à ces données de déterminer la date de dernière modification d’un attribut, ainsi que le nombre de fois où il a été modifié depuis sa création. Ces données, bien que semblant très limitées, peuvent alors servir à identifier différents scénarios d’attaque.

E l é v aT i o n d E p R i v i l è g E s pa R a j o u T d a n s u n g R o u p EL’un des cas où les données de réplica-tion offrent les meilleurs résultats est l’identification d’un scénario où l’attaquant s’est ajouté, puis supprimé d’un groupe, comme par exemple le groupe « Admins du domaine ».

En effet, au sein d’un Active Directory, les groupes possèdent une propriété « mem-ber » qui liste les utilisateurs appartenant au groupe. L’ajout d’un utilisateur dans un groupe va alors incrémenter l’USN de son attribut « member » de 1, celui-ci ayant été modifié. De même, le retrait de l’utilisateur

incrémentera également cet USN de 1.

Etant donné ces propriétés, deux conclu-

sions sont possibles :

/ Les utilisateurs ayant un USN impair sont membres du groupe (chose qu’il est directement possible de voir dans la valeur de l’attribut « member »), et la date de dernier ajout de l’utilisa-teur au sein du groupe est celle de l’USN ;

/ Les utilisateurs ayant un USN pair ont appartenu au groupe, mais n’en font plus parti depuis la date de l’USN.

C’est donc dans le second cas que se retrou-verait le compte d’un attaquant s’étant ajouté au groupe « Admins de domaine » pour réaliser des actions malveillantes, puis supprimé du groupe. Il est alors possible de créer un script récupérant les utilisateurs ayant été ajoutés ou supprimés d’un groupe après une date donnée (seule la date de premier et de dernier changement étant

conservés, il ne serait pas fiable de limiter la recherche à une date maximale) :

Ta R g E T E d K E R b E R o a s T i n gLe kerberoasting est une technique qui exploite le processus d’authentification Kerberos pour permettre à un attaquant de récupérer le mot de passe d’un compte de service (comprendre « compte disposant d’un Service Principal Name »). Le principe de cette attaque est que, comme le mon-tre le schéma suivant, lors d’une demande d’authentification à un service par un utilisa-teur, le KDC utilise le hash NTLM du compte de service pour chiffrer le TgS renvoyé à l’utilisateur. Dans ce processus, la légitimité de l’utilisateur à accéder au service n’est pas vérifiée, et n’importe quel utilisateur peut donc obtenir le TgS.

Il est alors possible pour l’attaquant d’effectuer une tentative de cassage du hash NTLM du compte de service en tentant de déchiffrer le TgS à partir de hashs successifs.

Supposons maintenant qu’un attaquant soit parvenu à récupérer des privilèges maxi-mums sur un objet utilisateur, à savoir des privilèges de type genericAll[5], qui donne notamment le droit de modifier le mot de passe du compte, ou encore de modifier les propriétés de l’objet Active Directory associé au compte. Pour usurper l’identité du compte en question, l’attaquant pourrait donc réini-tialiser le mot de passe du compte avec une valeur qu’il choisit, et se connecter à l’aide de ce nouveau mot de passe. Néanmoins, une telle attaque serait rapidement détectée

par l’utilisateur légitime du compte, qui ne parviendrait plus à se connecter avec son mot de passe habituel.

Une possibilité plus intéressante pour l’attaquant serait alors d’ajouter un Service Principal Name (SPN) au compte de ciblé, puis d’exécuter une attaque de type ker-beroasting. C’est ce qu’on appelle le targeted kerberoasting.

La majorité des utilisateurs d’un domaine

n’étant jamais supposée avoir de SPN, une

telle attaque peut assez simplement être

détectée si ce SPN n’est pas supprimé. Si par

contre ce SPN est supprimé par l’attaquant

une fois l’attaque effectuée, il reste toujours

possible d’utiliser les données de réplication !

uTil isaTion dEs méTadonnéEs dE RépliCaTion, Quand lEs jouRnaux fonT défauT

4

En effet, l’ajout ou la suppression d’un SPN sont des événements répliqués au sein de l’Active Directory, et génèrent donc des métadonnées de réplication de type msDS-ReplAttributeMetaData :

Il est alors possible de créer un script récu-pérant les comptes du domaine dont l’attribut SPN a été modifié depuis une date donnée, comptes qui sont donc des victimes potentielles d’une attaque de type targeted kerberoasting.

b R u T E f o R C E d ’ u n Co m p T E pa R b lo C a g E s u CC E s s i fUn scénario d’attaque par bruteforce pou-vant être utilisé par un attaquant au sein d’un Active Directory ne disposant d’aucune alerte est la réalisation de tentatives de con-nexion en dehors des heures d’utilisation du compte, et ce jusqu’au blocage du compte.

Lors du blocage d’un compte, un flag LOCKOUT[6] est positionné sur l’attribut userAccountControl d’un utilisateur. Cet attribué étant répliqué entre les différents

contrôleurs de domaine, des données de réplication de type msDS-ReplAttribute-MetaData sont alors générées. Il est alors possible de créer un script permettant d’identifier les comptes du domaine ayant

un numéro de version important dans les don-nées de répli-

cation de cet attribut, ce qui pourrait annon-cer un tel bruteforce :

Il est cependant à noter que l’attribut userAccountControl dispose de plusieurs autres flags dont la modification entrain-erait également la génération de données de réplication, indissociable des précé-dentes, comme par exemple pour le flag PASSWORD_EXPIRED. Cependant, cet attribut n’est généralement pas amené à évoluer grandement, et un très grand nom-bre de changements reste un indicateur rela-tivement fiable d’un bruteforce.

Un autre point à noter est qu’en limitant les tentatives de connexion pour éviter le blocage du compte, un attaquant serait

invisible à cette méthode d’investigation.

Co n C l u s i o nBien que n’apportant pas une vision aussi complète que les journaux d’événements, les données de réplication peuvent donc être une source d’information non néglige-able pour une investigation forensic dans un Active Directory.

Il est cependant à noter que des techniques permettant la modification des données de réplication pourraient exister[7], la confiance accordée aux informations obtenues grâce à celles-ci ne doit donc pas être aveugle.

Nicolas DAUBRESSE, Consultant

Sources

[1] http://www.securityinsider-solucom.fr/2017/04/cert-w-actualite-10-14-avril-2017.html

[2] https://github.com/x0rz/EQGRP_Lost_in_Translation

[3] https://docs.google.com/spreadsheets/d/1sD4rebofrkO9Rectt5S3Bzw6RnPpbJrMV-L1mS10HQc/

[4] https://technet.microsoft.com/fr-fr/library/security/ms17-010.aspx

[5] https://github.com/rapid7/metasploit-framework/blob/master/modules/auxiliary/scanner/smb/smb_ms17_010.rb

[6] http://www.pwn3d.org/

[7] https://zerosum0x0.blogspot.fr/2017/04/doublepulsar-initial-smb-backdoor-ring.html?m=1

[8] https://nmap.org/nsedoc/scripts/smb-double-pulsar-backdoor.html

5

HOUsTOn, wE’vE gOT a cHInEsE accOUnT On OUr sysTEm

Le CERT-W a été contacté afin d’investiguer sur l’origine d’un dossier utilisateur chinois

sur un système windows :

L’origine de la création de dossier util-isateur au sein du dossier « C:\Users » est engendrée à la suite de la première authen-tification d’un utilisateur, et non lors de sa création.

Ainsi, la présence de ce dossier révèle que l’utilisateur nommé « 整瑳 » s’est authentifié sur la machine analysée.

La création d’un utilisateur au sein d’un sys-tème Windows est enregistrée au sein du fichier journal « Security » sous l’identifiant « 4720 – Un compte d’utilisateur a été créé ».

Lors des investigations conduites, l’étude du fichier jour-nal «  Security  » sur la ressource a n a l y s é e n ’ a cependant révélé aucune informa-tion concernant la création du compte utilisateur « 整瑳 ».

En effet, une taille maximale est attribuée aux journaux Windows ; une rotation est ainsi appliquée en cas de dépassement ( les anciens journaux sont donc écrasés au fur et à mesure de façon automatique). Le jour-nal « Security » étant

très sollicité, il semble donc légitime que l’événement ne soit plus présent.

Néanmoins, l’étude du journa l sys -tème «  Microsoft-Windows-User Profile Operational » a révélé que la ruche utilisateur «  NTUSER.DAT   »

présente au sein du dos-sier de l’utilisateur « C:\Users\整瑳\ » est chargée en mémoire à intervalles réguliers sur la ressource analysée : l’utilisateur se

connecte donc régulièrement sur le système.

Par ailleurs, cet évènement révèle le SID

(« Security IDentifier ») associé à l’utilisateur

« 整瑳 » :

/ S-1-5-21-2165619761-3865691470-1251770841-1001

L’analyse de la base SAM du système révèle

que cet SID est associé à l’utilisateur nommé

« test ». Par ailleurs, aucun utilisateur nommé

« 整瑳 » ne semble être configuré sur le

système :

Or, la documentation Microsoft décrit le fonc-

tionnement suivant concernant l’attribution

des SID sur une ressource Windows :

« for every local account and group, the SID

is unique for the computer where it was cre-

ated; no two accounts or groups on the com-

puter ever share the same SID  » (https://

technet.microsoft.com/enus/ library/

cc778824(v=ws.10).aspx).

Ces différentes informations laissent donc

présager que les utilisateurs « test » et « 整

瑳 » sont donc un unique utilisateur.

L’analyse du registre dévoile que le chemin de profil associé à l’utilisateur disposant du SID précédemment identifié est le dossier

«  C:\Users\整瑳 » :

Le compte utilisateur nommé « test » dis-

pose donc du dossier « C:\Users\整瑳 » pour

dossier personnel.

présence d’un dossier chinois au sein du dossier « c:\Users »

analyse de la génération d’un dossier utilisateur « test »

Données de la valeur « profileImagepath »

Exemple d’évènement généré lors de la création d’un utilisateur sur une ressource windows

analyse des journaux microsoft-windows-User profile Operational

Extrait de la base sam

HousTon, WE’vE goT a CHinEsE aCCounT on ouR sysTEm

6

L’analyse de la valeur binaire de la clé « ProfileImagePath » révèle la présence de la chaîne de caractères « test ». Cependant, cette dernière dévoile que les caractères « test » n’ont pas correctement été encodée en unicode (selon lequel un caractère est défini sur deux octets).

Ainsi, les octets « te » et « st » représentent les deux caractères en unicode : 整瑳.

En effet, cette valeur devrait être définie à « .t.e.s.t.. » (soit « 00 74 00 65 00 73 00 74 00 00 ») pour que la chaîne de caractères « test » soit correctement affichée par le système :

Ainsi, cela confirme que :

/ L’utilisateur « 整瑳 » et « test » sont un seul et même utilisateur ;

/ Le dossier « C:\Users\整瑳 » est le dossier personnel de l’utilisateur « test ».

à la suite d’un entretien avec les personnes en charge de l’administration de la ressource analysée, les investigateurs ont été informés que le compte « test » est exploité en tant que compte de service par un logiciel tiers.

Ainsi, il est fort probable qu’une erreur d’implémentation au sein de la fonction générant le dossier personnel du compte de service créé lors de l’installation de ce logiciel soit à l’origine de ce bogue.

En effet, la timeline des évènements sys-tèmes s’étant produits sur la ressource, générée à l’aide de l’outil plaso, a permis d’illustrer que l’enregistrement dans la base

SAM du compte « test » et la création du dossier utilisateur « C:\Users\整瑳 » étaient liés : ces deux évènements se sont produits simul-tanément. Néanmoins, a u c u n e t r a c e d e l’installation du logiciel en question n’a pu être récupérée.

Enfin, il a été possible de reproduire ce bogue en modifiant légèrement

le code source disponible via le lien suiv-ant : https://support.microsoft.com/en-us/help/196070/how-to-programmatically-cause-the-cre ation-of-a-users-profile.

En effet, un com-portement similaire (création d’un util-isateur disposant d’un dossier non encodé au format unicode) a pu être

obtenu en remplaçant l’appel à la fonc-tion LoadUserProfileA() par la fonction LoadUserProfileW() :

Ainsi, il est très probable qu’une erreur d’implémentation se soit glissée au sein du logiciel tiers déployé sur la ressource analysée.

En effet, une erreur lors de l’appel à la fonc-tion LoadUserProfile a été réalisée : la fonc-tion LoadUserProfileW a été appelée au détriment de la fonction LoadUserProfileA. Or, le programme devait probablement manipuler des chaînes de caractères ANSI, générant ainsi une erreur d’encodage lors de la création du dossier utilisateur associé au

compte de service configuré par le logiciel.

Co n C l u s i o nLa présence d’un dossier chinois sur un système n’induit pas forcément la com-promission de ce dernier ; néanmoins, des investigations doivent systématiquement être conduites. En effet, cette dernière peut être liée à la mauvaise implémentation d’un logiciel déployé sur le système.

Par ailleurs, une attention particulière doit être portée lors de l’utilisation de fonc-tions sensibles à l’encodage, afin d’éviter l’introduction de tout bogues et potentiels effets de bord lors de l’exécution de tels programmes. De tels comportements peu-vent être éviter en exploitant les dernières fonctions offertes par les API windows ; notamment, la fonction CreateUserProfile peut être employée pour créer des profils utilisateurs sur les systèmes Windows supéri-eur à Windows vista. Cette dernière ne dif-fère pas selon l’encodage souhaitée (ANSI ou unicode).

Enfin, il convient de centraliser les jour-naux systèmes en temps réel vers une ressource dédiée, et d’externaliser par la suite ces derniers afin d’éviter toute perte d’enregistrements ; facilitant ainsi les inves-tigations en cas d’incident.

François LELIEVRE,Consultant CERT-W

mauvais encodage de la chaîne de caractères « test » au sein de la valeur « profileImagepath »

correction de la valeur « profileImagepath » en unicode

Extrait de la documentation de la fonction loadUserprofile

7

HiTb2017 - WHEn TWo-faCToR auTHEnTiCaTion is a foE: bREaKing applE’s iCloud KEyCHain

HITB2017 - wHEn TwO-facTOr aUTHEnTIcaTIOn Is a fOE: BrEakIng applE’s IclOUD kEycHaIn

C e t t e p r é s e n t a t i o n c o u r t e ( 3 0 m i n u t e s ) , d e l a c o n f é r e n c e H a c k I n T h e B o x 2 0 1 7 à A m s t e r d a m , é t a i t a s s u r é e p a r  V l a d i m i r KATA LOV, C E O d e l ’e n t re p r i s e  E l co m S o f t  b a s é e à M o s co u ( R u s s i e ) e t s p é c i a l i s é e d a n s l a r é c u -p é ra t i o n d e m o t s d e p a s s e a i n s i q u e d e l ’a n a l y s e e t d e l a re s t a u ra t i o n d e sy s t è m e s p ro t é g é s p a r c h i f f re m e n t . L a s o c i é t é E l co m S o f t t rava i l l e n o t a m m e n t p o u r l e s e n t i t é s s u i va n t e s :

• NSA (National Security Agency);

• EUROPOL ;

• INTERPOL ;

• . . .  

D u r a n t c e t t e d e m i - h e u r e , V l a d i m i r K A T A L O V a p r é s e n t é l e m o d è l e d e c h i f f re m e n t i m p l é m e n t é s u r l e s é q u i -p e m e n t s A p p l e e n e f fe c t u a n t u n fo c u s p a r t i c u l i e r s u r l a   r é c u p é r a t i o n d e s s e c re t s  v i a l e s  m é c a n i s m e s i C l o u d .

i n T R o d u C T i o nAlors que de nombreuses données sont présentes sur les smartphones (contacts, calendrier, historiques des appels…), il est parfois nécessaire de pouvoir les récupérer, notamment en cas d’investigation. 

Pour cela, l’acquisition de données (chiffrées ou non) est systématiquement la première étape avant l’extraction des secrets. Pour cela, différentes méthodes peuvent être utilisées :

/ Acquisition via JTAG / Chip-Off / Hex dump :  ces procédures per-mettent d’extraire la mémoire des équipements via un accès physique ; elles ne s’avèrent pas exploitable lorsque les données sont chiffrées. Par ailleurs, des erreurs peuvent sur-venir lors la capture et provoquer la récupération d’une image corrompue

voir causer des dommages sur la mé-moire à extraire.

/ Acquisition logicielle :  ces procé-dures visent à utiliser un outil logi-ciel permettant d’extraire la mémoire d’un équipement. En plus d’offrir des possibilités plus limitées que l’ex-traction physique, les compatibilités logicielles sont souvent limitées. Par ailleurs, l’utilisation d’un logiciel im-plique le contournement de la mire de verrouillage de l’écran.

/ Utilisation des fonctionnalités « Cloud » : cette méthode permet de récupérer les données sans néces-sité d’accès physique à l’équipement via la récupération des données sauvegardées sur les interfaces de type «  cloud » (ex. : iCloud, google Drive…).

d o n n é E s s a u v E g a R d é E s d a n s l E s C lo u dDe plus en plus de données présentes sur les smartphones et autres équipements mobiles sont synchronisées sur des plate-formes Cloud (proposées par les éditeurs leader tels que google, Apple et Microsoft). Les données transmises peuvent être de différentes natures :

/ Les données de sauvegardes (« backups ») : ces données corres-pondent aux éléments sauvegardés pour la restauration d’un système complet. Ainsi, pour ce type de sau-vegarde, la quasi-totalité des don-nées sont transmises vers plateforme Cloud.

/ Les données de synchronisation :  ces données correspondent à cer-taines informations partagées entre les différents appareils synchronisés sur le compte Cloud. Elles peuvent être de différentes natures (détaillées dans les sections suivantes).

/ Les données partagées :  ces don-nées correspondent aux fichiers par-tagés sur le Cloud ; seuls les fichiers définis par l’utilisateur sont sauve-gardés (type google Drive…).

d o n n é E s d E s a u v E g a R d E s ( b a C K u p )Les données de sau-vegardes contiennent principalement les images systèmes com-plètes des équipements (notamment sur Apple). En revanche, les don-nées suivantes ne sont

pas communément accessibles :

/ Données des applications tierces ;

/ Mots de passe (ou alors sur des par-ties additionnelles chiffrées).

Cependant, dans la majorité des cas, aucune fonctionnalité native ne permet la récupéra-tion des images sauvegardées (notamment via les interfaces Web de type iCloud) ; des outils tiers (comme celui développé par la société

ElcomSoft) peuvent alors être nécessaires.

d o n n é E s s y n C H R o n i s é E sEn dehors des sauvegardes, d’autres don-nées sont automatiquement sauvegardées sur les systèmes de type Cloud via les fonc-tions de synchronisation, notamment :

/ Les contacts ;

/ L’historique des appels ;

/ Les messages (SMS, iMessage, Han-gout…) ;

/ Les mails ;

/ Les activités Internet (historique de navigation…) ;

/ Les mots de passe ;

/ …

Bien que les données sauvegardées par cette méthode soient plus restreintes que celles rel-atives aux backups complets, de nombreuses données sensibles et potentiellement intéres-santes peuvent être récupérées. Par ailleurs, ces données sont bien souvent répliquées sur les autres équipements qui peuvent alors con-stituer un autre vecteur d’attaque.

p R o T E C T i o n d u « p o R T E - C l é s » a p p l ELa fonctionnalité de porte-clés Apple (ou Keychain) permet la  conservation des secrets de l’utilisateur de manière sécurisée ; elle permet en particulier de limiter la saisie des mots de passe applicatifs (Safari, Wi-fi…). Les mots de passe et secrets sont alors con-servés dans le porte-clés et accessibles à la demande de l’utilisateur. Les méthodes de gestion des porte-clés diffèrent légèrement

entre les OS :

protection du porte-clés apple en fonction des plateformes

8

p o R T E - C l é s i o sSur la plateforme iOS, le porte-clés est un fichier de type XML et il possède la structure suivante :

Différentes classes de protection peuvent être implémentées. La liste exhaustive de ces dernières peut être consultée en ligne à l’adresse suivante : https://devel-oper.apple.com/documentation/secu-rity/keychain_services/keychain_items/item_attribute_keys_and_values#1679100

Note : L’attribut _ThisDeviceOnly permet de chif-frer les données à l’aide d’une clé matérielle spécifique à l’équipement. Celle-ci peut être extraite sur les périphériques 32 bits uniquement.

f i C H i E R s d E s a u v E g a R d E s i T u n E sL’outil iTunes développé par Apple per-met d’effectuer des sauvegardes locales (sur un poste) des données présentes sur les équipements mobiles de type iPhone, iPod et iPad. De nombreuses données sont ainsi sauvegardées, notamment les certains secrets des utilisateurs (keychain).

Afin de limiter les risques de récupération des données, les secrets sont sauvegardés de façon chiffrée (via le mécanisme de chif-frement AES) et conservés dans les fichiers nommés « manifest.plist » ; la clé de chiffre-ment est quant à elle présente dans l’attribut « BackupKeyBag » lui-même protégé par une clé dérivée du mot de passe mis en place par l’utilisateur.

La génération de la clé de chiffrement / déchiffrement du « keyBag » est générée de la manière suivante :

Note : Une faiblesse introduite sur iOS 10.0 permettait le stockage du condensat cryp-tographique (sha256) du mot de passe de chif-frement dans une base de données non protégée.

p R o T E C T i o n d E s d o n n é E s i C lo u d La majorité des données transmises vers

la plateforme iCloud sont protégées via le mécanisme de chiffrement AES utilisant une clé de 128 bits. Le trousseau iCloud uti-lise quant à lui une clé de 256 bits afin de

conserver les informations plus sensibles (données de bancaires, mots de passe…). La clé de chiffrement est con-servée non chiffrée dans le bloc contenant les données

sauvegardées. 

Afin de sécuriser les données conservées, certaines mesures de sécurité sont mises en place, notamment :

/ Des notifications par email  sont en-voyées lors d’un accès aux données (à l’exception d’un accès via un jeton d’authentification) ;

/ Un mécanisme de verrouillage des comptes est mis en place afin de limi-ter les accès frauduleux (blocage en cas d’activités suspectes) ;

/ Un  mode d’authentification à deux facteurs est proposé ;

/ …

Note : Le jeton d’authentification peut notam-ment être récupéré sur un autre équipement sur lequel le même compte a été utilisé.

p R o T E C T i o n d E s d o n n é E s s a n s a C T i v aT i o n d E l’a u T H E n T i f i C aT i o n d E u x fa C T E u R sApple propose le mode d’authentification deux facteurs mais il est possible de le désactiver ; un mot de passe d’accès au compte peut alors être défini. Le code de sécurité est en effet facultatif, cependant, si aucun code n’est défini l’utilisateur doit con-firmer chaque ajout de nouvel équipement via un équipement déjà enrôlé.

L’avantage prin-cipal d’utiliser un code de sécurité réside essentiel-lement de  l’envoi du porte-clés vers le service « Apple Escrow » (détaillé dans la section suivante), permet-

tant la récupération des données en cas de perte des équipements (voir des numéros de téléphone associés…) avec l’aide du service Apple. 

Note : Bien qu’aucune vulnérabilité n’impacte directement ce mode de fonctionnement, cette

méthode n’est pas recommandée par Vladimir KATALOV en raison des erreurs fréquentes lors de la phase de paramétrage.

p R o T E C T i o n d E s d o n n é E s a v E C a C T i v aT i o n d E l’a u T H E n T i f i C aT i o n d E u x fa C T E u R sLa mise en place du mode d’authentification deux facteurs est plus aisée que la méthode précédente, il est simplement nécessaire de choisir un numéro de téléphone sur lequel l’utilisateur recevra les notifications de con-firmation. Cette manipulation ne peut pas être effectuée depuis l’interface Web du service iCloud mais uniquement depuis un équipement Apple.

Par ailleurs, afin d’ajouter un équipement sur un même compte iCloud, il est néces-saire d’entrer le code de déverrouillage de l’un des équipements précédemment enrôlés.

f o n C T i o n n E m E n T d u p o R T E - C l é s i C lo u dLe porte-clés iCloud offre la possibilité aux utilisateurs de synchroniser de manière sécurisée leurs mots de passe entre plusieurs appareils iOS et ordinateurs Mac (sans divul-guer ces informations à Apple). Le protocole a été conçu afin de permettre une protection vis-à-vis des scénarios suivants :

/ Compromission du compte iCloud de l’utilisateur ;

/ Compromission du service iCloud (par un employé ou une attaque externe) ;

/ Accès d’un tiers aux comptes de l’uti-lisateur.

C E R C l E d E Co n f i a n C EAfin de permettre le partage des données entre les différents équipements, un cercle de confiance est établit entre les différents équipements (lorsque l’authentification deux facteurs est activée). Pour cela, le mécanisme suivant est utilisé :

/ Initialisation du cercle de confiance :

• Le premier appareil établit un cercle de confiance ;

• Le premier appareil crée une iden-tité de synchronisation (couple clé publique / privée) ;

• La clé publique de l’identité de synchronisation est placée dans le cercle et signée par :

- La clé privée de l’autorisation de synchronisation elle-même ;

mécanismes cryptographiques implémentés en fonction des Os

9

- Une clé asymétrique sur courbe elliptique (via P256) générée à partir du mot de passe du compte iCloud (les paramètres utilisés pour la génération sont également stockés dans le cercle).

• Le cercle signé est placé dans une zone de stockage (KvS) sur iCloud.

/ Activation du cercle sur un autre ap-pareil :

• L’appareil crée sa paire de clé d’identification de synchronisation ;

• L’appareil crée un ticket de candi-dature (constitué de la clé publique de l’identité de synchronisation de l’appareil) ;

• L’utilisateur s’authentifie via la sou-mission de son mot de passe iCloud ;

• En cas de succès de l’authentification, le ticket est placé dans iCloud.

• Lorsque le premier appareil constate la présence du ticket, il affiche un mes-sage à l’utilisateur afin de confirmer qu’une demande a été effectuée ;

• Suite à la confirmation, l’utilisateur doit entrer sont mot de passe iCloud afin d’effectuer la vérification du ticket de candidature ;

• En cas de succès de l’étape précé-dent, le premier équipement ajoute la clé du nouveau membre au cercle de confiance en la signant avec :

- Sa clé de synchronisation 

- La clé secrète générée à partir du mot de passe iCloud.

/ Ajout d’un n-ième membre :

• La même procédure que pour l’ajout du deuxième équipement est rejouée (la validation peut être effectuée sur l’ensemble des équi-pements précédemment enrôlés).

En revanche, seuls les éléments possédant l’attribut kSecAttrSyncronizable sont syn-chronisés par ce mécanisme afin de limiter la réplication de certaines informations possé-dant un besoin de confidentialité plus élevé. La mise en place de ce protocole permet ensuite le transfert des secrets entre appar-eils sans possibilité pour Apple de récupérer les données (au moins d’une façon directe).

s E R v i C E « E s C R o W p R o x y »Le service « Escrow proxy » permet la récu-pération des mots de passe par l’utilisateur, il n’est cependant disponible que suite à de la mise en place d’un code de sécurité (par

défaut une série de quatre chiffres). La clé de chiffrement du trousseau est trans-mise vers le service « escrow » chiffrée avec le code de sécurité définit :

L’API du service « escrow » permet ensuite d’effectuer différ-entes actions telles que :

/ Ajouter un enregistrement ;

/ Récupérer un enregistrement ;

/ Récupérer la liste des numéros de téléphone de confiance ;

/ Récupérer les données (en cas de perte) ;

/ ...

Lorsqu’un utilisateur souhaite récupérer les données sauvegardées, la procédure suiv-ante est mise en place :

/ L’utilisateur (authentifié) récupère un jeton via l’appel getAccountSet-tings ;

/ L’utilisateur utilise le jeton récupéré afin d’effectuer une synchronisation avec le service (afin de ne récupérer que les données nécessaires) ;

/ L’utilisateur s’authentifie via le proto-cole SRP : cette étape est complexe mais ne provoque pas de notification et ne requière pas les éléments sui-vants :

• Un équipement enrôlé (le code de sécurité d’un des équipements enrôlés est cependant nécessaire) ;

• Le code de sécurité iCloud ;

/ L’utilisateur récupère les données et effectue les étapes de déchiffrement nécessaires.

Ainsi, un attaquant en capacité de récupérer un jeton d’accès au service iCloud peut récu-pérer les données stockées sans provoquer de notification chez l’utilisateur légitime.

Co n C l u s i o nActuellement différentes méthodes peuvent être utilisées afin de récupérer les données conservées :

/ Ajouter un nouvel équipement au « cercle de confiance »  ; il est alors nécessaire de contourner ou valider l’étape d‘authentification à deux fac-

teurs provoquant ainsi des notifica-tions sur les autres équipements.

/ Récupérer les sauvegardes iCloud (sous réserve d’existence), il est alors nécessaire de :

• Passer l’authentification deux facteurs (comme ci-dessus) ;

• Récupérer la clé de chiffrement d’un équipement (récupérable unique-ment sur les mobiles 32 bits).

/ Accéder à une sauvegarde locale, cependant, il alors nécessaire de :

• Posséder un accès physique à un équipement (PC / Mac) ;

• Posséder la clé de déchiffrement (si la sauvegarde est protégée).

/ Trouver une vulnérabilité dans le protocole de gestion du cercle de confiance  ; la façon dont était pré-senté ce dernier point laisse à pen-ser que le protocole pourrait être vulnérable mais aucune information supplémentaire n’a été divulguée durant la conférence. Il se peut que la vulnérabilité en question soit d’ordre cryptographique et liée au choix des paramètres de la courbe elliptique NIST P-256.

Mahdi BRAIK, Consultant

Sources

http://conference.hitb.org/hitbsecconf2017ams/materials/D1T4%20-%20Vladamir%20Katalov%20-%20Breaking%20Apple%e2%80%99s%20iCloud%20Keychain.pdf

https://images.apple.com/fr/business/docs/iOS_Security_Guide.pdf

http://ogryb.blogspot.fr/2014/11/why-i-dont-trust-nist-p-256.html

http://safecurves.cr.yp.to/rigid.html

Vous pouvez retrouver l’intégralité de ces articles sur notre blog Security Insider : http://securityinsider-wavestone.com

Vous pouvez également suivre l’actualité via le compte Twitter @SecuInsider

Transmission de la clé de chiffrement vers le service « escrow »

HiTb2017 - WHEn TWo-faCToR auTHEnTiCaTion is a foE: bREaKing applE’s iCloud KEyCHain

10

cvE-2017-11776 : OUTlOOk vs s/mImE

C e t a r t i c l e a b o rd e l e s u j e t d e l a C V E 2 0 1 7-1 1 7 76 , u n e v u l n é r a b i l i t é c i b l a n t M i c ro s o f t O u t l o o k , d e s e s i m p a c t s , e t d e s a c t i o n s à r é a l i s e r p o s t- co r re c t i o n .

u n E v u l n é R a b i l i T é R E l aT i v E a u C H i f f R E m E n T s / m i m E d a n s o u T lo o KUne faille de sécurité dans Outlook relative au chiffrement S/MIME des e-mails a été identifiée (CvE-2017-11776). Elle concerne les mails chiffrés envoyés par Outlook au format « texte brut » :

Depuis environ 6 mois, les mails chiffrés envoyés rédigés au format « texte brut » sont envoyés à la fois chiffrés et en clair par Outlook dans le corps du mail envoyé. Les mails au format « HTML » ont, eux, été cor-rectement chiffrés intégralement.

é T E n d u E d E l a v u l n é R a b i l i T é

La vulnérabil ité ne s’applique que

lorsqu’Outlook a envoyé un mail chiffré avec

S/MIME au format brut. Si un autre client

mail (Thunderbird, Webmail, etc.) a envoyé

un mail chiffré, celui-ci sera correctement

chiffré.

La transmission du message en clair est vari-

able :

/ Dans le cas d’Outlook avec Exchange : 

• Lorsque le destinataire n’est pas

dans le même domaine de mails,

le message en clair est envoyé au

premier relai (MTA) puis supprimé

par la suite

• Lorsque le destinataire est dans le

même domaine de mails, le mes-

sage en clair est envoyé au pre-

mier relai (MTA) puis acheminé

jusqu’à la boîte de réception du

correspondant

Dans le cas d’Outlook avec SMTP, le message en clair est envoyé tout le long de la chaîne de transmission du mail jusqu’à la boîte de réception du correspondant

Un script PowerShell a été développé par Wavestone afin de permettre la recherche parmi une boîte aux lettres Outlook de mails chiffrés avec S/MIME au format « texte brut ». Il est disponible à cette adresse et est

à exécuter lorsqu’Outlook est ouvert.

Co R R E C T i f sCette vulnérabilité est corrigée dans les mises à jour Outlook suivantes : 

/ Deferred Channel: version 1705 (Build 8201.2200) – publiée le 10 oc-tobre 2017

/ Monthly Channel: version 1708 (Build 8431.2107) – publiée le 10 octobre 2017

Cyprien OGER, Sénior Consultant

Sources

https://www.sec-consult.com/en/blog/2017/10/fake-crypto-microsoft-outlook-smime-cleartext-disclosure-cve-2017-11776/index.html

11

CE Qui a CHangé pouR l’épinglEmEnT dE CERTif iCaT à paRTiR d’andRoid 7 nougaT

cE QUI a cHangé pOUr l’épInglEmEnT DE cErTIfIcaT à parTIr D’anDrOID 7 nOUgaT

La septième mouture d’Android, nommée « Nougat », estampillée « API level 24 », et publiée en août 2016, a introduit des change-ments importants en matière de sécurité des flux de communication SSL/TLS et plus particulièrement autour de l’épinglement de certificat (certificate-pinning en anglais).

Pour rappel, l’épinglement de certificat est une mesure de sécurisation visant à limiter l’impact de la compromission d’une Autorité de Certification (AC) en définissant préci-sément côté client quel certificat, ou quelle chaine de certification, est attendu (https://www.riskinsight-wavestone.com/2013/04/epinglez-vos-certificats).

C E Q u i C H a n g E p o u R l E s d é v E lo p p E u R s De manière simple, jusqu’à présent toute application Android faisait aveuglément confiance aux certificats présents dans les deux magasins disponibles sur un terminal, à savoir la base « système », provenant du projet AOSP (https://android.googlesource.com/platform/system/ca-certificates/), et la base « utilisateur », contenant des certificats personnalisés, modifiable par un utilisateur du terminal.

Un développeur devait ainsi appliquer une section de code spécifique dans son appli-cation pour effectuer un épinglement : sans expérience dans ce domaine, un dével-oppement spécifique pouvait s’avérer être totalement ineffectif (https://www.synopsys.com/blogs/software-security/ineffective-certificate-pinning-implementations/). Nous conseillons d’ailleurs aux développeurs de se baser sur les exemples fournis par l’OWASP s’ils souhaitent mettre en œuvre une telle mesure (https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning).

Désormais, une application compilée avec à minima Android 7 comme version cible ne fera plus confiance par défaut au magasin « utilisateur » et devra explicitement définir les AC reconnues comme valides selon plusieurs possibilités :

/ Pour les phases de débogage uni-quement : l’application doit dans ce cas être compilée avec l’instruction « debuggable=true » dans le Manifest

/ Par domaine

/ Pour une liste de domaine

/ Pour tous les domaines sauf exception

L’exemple suivant, tiré de ce blog post (https://android-developers.googleblog.com/2016/07/changes-to-trusted-certifi-cate.html), illustre comment déclarer un AC valide pour le domaine « internal.example.com » :

C E Q u i C H a n g E p o u R l E s a u d i T E u R s /p E n T E s T E R sHistoriquement toute per-sonne souhaitant analyser/auditer les flux Web d’une application et qui n’était pas en mesure de compiler l’application cible devait :

1. Utiliser un proxy Web, par exemple Burp Suite 

2. Ajouter l’AC de ce proxy dans le maga-sin « utilisateur » pour pouvoir inter-cepter les flux chiffrés SSL/TLS

3. Désactiver la fonction d’épinglement de certificat au sein de l’application, notamment en patchant et recom-pilant l’application (https://medium.com/@felipecsl/bypassing-certifi-cate-pinning-on-android-for-fun-and-profit-1b0d14beab2b)

4. Rediriger les flux du terminal vers le proxy, par exemple via les paramètres de connectivité Wi-fi

L’étape 2 étant désormais ineffective à partir d’Android 7, plusieurs possibilités s’offrent à un auditeur :

/ La plus simple : continuer à utiliser l’ancienne méthode, en utilisant un terminal disposant d’Android 6, à la condition que l’application mobile cible autorise cette version

/ Celle un peu complexe : ajouter l’AC du proxy Web dans le magasin de certificat « système » : cette méthode est explicitée ici (https://nvisium.com/blog/2017/07/12/advantages-and-disadvantages-of-android-n-network-security-configuration/) et là (https://blog.jeroenhd.nl/article/android-7-nougat-and-certificate-authorities) et consiste à modifier le fichier contenu dans « /system/etc/

security/cacerts/ » de la partition système. Le prérequis notable étant de disposer des droits root sur le ter-minal cible pour pouvoir remonter la partition en lecture et écriture.

/ Celle encore plus complexe mais la plus avancée techniquement : utiliser le framework d’instrumentation dy-namique « frida » (https://www.frida.re/) avec un script générique de dé-sactivation de l’épinglement (https://techblog.mediaservice.net/2017/07/universal-android-ssl-pinning-by-pass-with-frida/).

www.wavestone.com

Wavestone est un cabinet de conseil, issu du rapprochement de Solucom et des activités européennes de Kurt Salmon (hors consulting dans les secteurs retail & consumer goods en dehors de france).

La mission de Wavestone est d’éclairer et guider ses clients dans leurs décisions les plus stratégiques en s’appuyant sur une triple expertise fonctionnelle, sectorielle et technologique.

fort de 2 500 collaborateurs présents sur 4 continents, le cabinet figure parmi les leaders indépendants du conseil en Europe et constitue le 1er cabinet de conseil indépendant en france.

2018 I © WAvESTONE

Un exemple détaillé d’application de cette méthode est disponible ici (https://blog.it-securityguard.com/the-stony-path-of-android-%f0%9f%A4%96-bug-bounty-bypassing-certificate-pinning/) 

En complexifiant la procédure d’interception des flux par des auditeurs bien intention-nés, ces modifications dans la gestion des

certificats introduites à partir d’Android 7 permettent également de complexifier les possibilités d’interception par des per-sonnes mal intentionnées tout en facilitant le travail des développeurs, dans l’objectif global de renforcer la confiance au sein de la plateforme mobile la plus utilisée au monde (https://www.idc.com/promo/smartphone-market-share/os).

Thomas DEBIZE, Sénior Consultant

CERTLe CERT-Wavestone associe un ensemble d’expertises techniques et métiers afin d’apporter une réponse globale aux incidents de sécurité. Plus de 45 profils expérimentés sont mobilisables au sein du CERT-Wavestone .

Retrouvez les publications de nos experts sur www.securityinsider-wavestone.com twitter@secuinsider

RéaCTion suR aTTaQuEou suspiCion

• i n v e s t i g a t i o n n u m é r i q u e / f o r e n s i c s

• g e s t i o n d e c r i s e s i e t m é t i e r

• C o n s t r u c t i o n d e s p l a n s d e r e m é d i a t i o n

THREaT inTElligEnCE

• E v a l u a t i o n d e l ’ a t t r a c t i v i t é d e l ’e n t r e p r i s e

• a n a l y s e e t d é c r y p t a g e d ’ a t t a q u e s

• W a t c h & l e a r n : v e i l l e c y b e r c r i m i n a l i t é

pRépaRaTion à la défEnsE & à la gEsTion dE CRisE

• d é f i n i t i o n e t a n i m a t i o n d e s p r o c e s s u s C E R T e t s o C

• R e d t e a m & p u r p l e t e a m

• E x e r c i c e s d e c r i s e