Analyser la géolocalisation sur iPhone grâce à un proxy de déchiffrement SSL

Magazine
Marque
MISC
Numéro
59
Mois de parution
janvier 2012
Domaines


Résumé
Pendant votre sommeil, votre iPhone raconte parfois à Apple où vous avez passé votre journée. C'est l'intéressante découverte que nous avons faite en étudiant les mécanismes de géolocalisation de ce smartphone. Mais pour en arriver là, il a d'abord fallu déchiffrer les communications SSL de notre téléphone cobaye et en analyser le contenu. Une enquête détaillée pas à pas dans cet article.

Body

1. Les mystères de la géolocalisation sur iPhone

La plupart des smartphones ont une puce GPS, mais cette technologie est lente à démarrer et ne marche pas toujours bien en ville où à l'intérieur de bâtiments. C'est une tout autre approche qui est donc souvent utilisée pour fournir un service de géolocalisation sur ces dispositifs mobiles : la détection de points d'accès Wi-Fi (ou d'antennes GSM). Contrairement au GPS, cette approche nécessite une communication entre le téléphone et un serveur de géolocalisation spécialisé qui détient une base de données recensant la position géographique des points d'accès Wi-Fi. Ceci est possible, car chaque point d'accès Wi-Fi peut être identifié par un numéro unique : son adresse MAC ou « BSSID ».

Cette fonction de géolocalisation offerte par les smartphones entraîne des sentiments ambivalents. Pour beaucoup au quotidien, c'est à la fois un outil fantastique et potentiellement un dispositif de surveillance des déplacements qui inquiète.

Pour en témoigner, il suffit de se rappeler l'énorme buzz qu'avaient créé, fin avril 2011, deux universitaires britanniques [1] en mettant en lumière une base de données de géolocalisation utilisée par les iPhones d’Apple et sauvegardée sur le PC de l’utilisateur. Étrangement, la découverte initiale de ce fichier, attribuée à Sean Morrissey et Alex Levinson [2], datait de 2010 et était passée inaperçue à l’époque.

Cette base de données, appelée consolidated.db, recensait, rappelons-le, plus d'un an d'historique, plus ou moins précis, des déplacements des propriétaires d'iPhone. Apple a depuis corrigé le problème tout en affirmant que le contenu de ce fichier n'était jamais envoyé vers ses propres serveurs.

Une question demeurerait donc : quelles données de géolocalisation sont envoyées vers les serveurs d'Apple et comment ce mystérieux fichier a-t-il été constitué ? Pour tenter de répondre à ces questions, plongeons au cœur des communications de l'iPhone.

2. Déchiffrer des communications SSL/TLS

La première étape de cette expérience consiste à créer un point d'interception des communications entre un iPhone et Internet. Il y a plusieurs canaux pour y parvenir : l'OS de l'iPhone, la 3G/GSM ou le Wi-Fi. L'interception de communications 3G/GSM nécessite un matériel assez lourd, quant à l'installation d'un logiciel d'interception directement sur l'iPhone, cela implique des développements complexes et un « jailbreaking », ce que nous voulions éviter. L'option la plus simple est donc d'exploiter le canal Wi-Fi. Un point d'accès Wi-Fi ordinaire a donc été connecté à une machine Linux, elle-même équipée d'une deuxième carte réseau connectée à Internet par ADSL, comme illustré sur la figure 1.

Schema-dispositif

Fig. 1 : Dispositif d'interception

Sur cette machine Linux, un proxy HTTP à été mis en place pour pouvoir intercepter les communications de l'iPhone. Premier constat : les requêtes de géolocalisation sont sécurisées par SSL/TLS. Ce proxy a donc dû être modifié pour intercepter ce type de communications. Il existait déjà des proxies qui étaient susceptibles de jouer ce rôle, par exemple mitmproxy [3] ou encore tcpcatcher [4]. Néanmoins, à l'époque de nos premières investigations, ils souffraient tous de certaines limitations qui nous ont amenés à développer notre propre outil dont le code source est disponible [5] sous licence GPL pour les lecteurs qui souhaiteraient répéter les expériences décrites dans cet article.

2.1. Le modèle d'authentification de SSL en question

Dans son utilisation la plus répandue, le protocole SSL/TLS est utilisé pour sécuriser des communications HTTP entre un client et un serveur. Il existe deux grandes familles d'attaques sur SSL/TLS : les attaques qui ciblent les mécanismes assurant la confidentialité des communications et celles qui s'attachent aux problématiques d’authentification des échanges.

Les attaques portant directement sur les mécanismes de confidentialité des communications sont rares, car le protocole SSL/TLS s'appuie sur des primitives cryptographiques éprouvées, même si l'on découvre parfois encore des failles dans la manière dont elles sont mises en œuvre [6]. C'est en jouant avec le modèle d’authentification de SSL/TLS que nous avons mis en place un outil susceptible d'intercepter des communications chiffrées entre un iPhone et les serveurs d'Apple.

Rappelons de manière simplifiée les principes d'authentification utilisés par SSL/TLS. Lorsqu'un client se connecte à un serveur www.serveur.com en SSL, le serveur lui présente sa clé publique, qui sert alors à initier une communication sécurisée. En effet, si une donnée envoyée par le client est chiffrée avec la clé publique du serveur, seul celui-ci pourra la déchiffrer. Bien sûr, ceci ne fonctionne que si le client est certain que la clé publique appartient bien au serveur www.serveur.com et non à un usurpateur. Cette assurance est fournie par un certificat envoyé également par le serveur. Ce certificat contient un lien entre la clé publique du serveur et son identité « www.serveur.com », le tout signé par une autorité de certification. Si le navigateur du client possède lui-même la clé publique de l'autorité de certification, il pourra vérifier la validité de la signature du certificat et par conséquent valider la clé publique du serveur.

Dans ce modèle, la confiance est donc déportée intégralement sur une autorité de certification. Si celle-ci est défaillante, la sécurité des communications n'est plus garantie. Ce fut le cas très récemment lorsque des hackers iraniens ont réussi à obtenir des certificats pour de nombreux sites, dont Google, auprès de l'autorité de certification Diginotar [7]. En effet, si l'on peut fabriquer un vrai-faux certificat, alors il est possible de réaliser une interception de type Man In The Middle. Nous reprenons ici cette idée : notre proxy intercepte les communications entre le client et le serveur, faisant croire d'une part au client qu'il est le serveur et d'autre part au serveur qu'il est le client. Le client et le serveur n'y verront que du feu !

2.2. Un « Man In The Middle »

Dans notre expérience, nous avons donc créé notre propre autorité de certification appelée « Proxy Certs Master » à l'aide d'OpenSSL[8] et nous avons installé son certificat racine dans le gestionnaire de profil de l'iPhone, comme le montre la figure 2. Nous avons également créé une bi-clé RSA serveur distincte pour le proxy lui-même, destinée à sécuriser ses échanges avec l'iPhone.

Copie-ecran-iphone

Fig. 2 : Notre certificat racine installé dans l'iPhone

Ensuite, nous avons modifié notre proxy pour intercepter les demandes de connexion SSL entre clients et serveurs [9]. Typiquement, si un client souhaite se connecter à l'adresse https://www.serveur.com/, sa demande sera traitée selon les étapes suivantes par notre proxy :

- Étape 1 : Le client se connecte au proxy – on appellera cette connexion « CONNECTION A ». Le client transmet au proxy une demande de connexion au serveur SSL distant, à l'aide de la requête HTTP CONNECT www.serveur.com:443 HTTP/1.1. Le proxy répond à cette requête avec un code HTTP/1.1 200 Connection established, après avoir vérifié qu'une connexion TCP/IP avec le serveur distant était possible sur le port 443 (pas de SSL à ce stade).

- Étape 2 : Le proxy crée une seconde connexion SSL indépendante vers le serveur comme s'il était lui-même un navigateur : on appellera cette connexion « CONNECTION B ». Le proxy récupère et modifie alors le certificat X509 de www.serveur.com pour en créer un nouveau en réalisant les manipulations suivantes :

 1) Le descripteur de l'autorité de certification est remplacé par celui de « Proxy Certs Master ».

 2) La clé publique du serveur est remplacée par la clé publique du proxy.

 3) Certaines extensions X509 V3 sont supprimées ou modifiées par souci de cohérence si nécessaire.

 4) Le certificat est reconstruit et signé par la clé privée de l'autorité « Proxy Certs Master ».

- Étape 3 : Le client envoie alors une séquence d'initialisation SSL sur la CONNECTION A. Le proxy y répond en présentant sa propre clé publique et le certificat modifié créé à l'étape précédente. Le client peut vérifier la chaîne de certification à l'aide du certificat racine de notre autorité « Proxy Certs Master » et croit donc dialoguer avec le serveur authentique (et non le proxy).

- Étape 4 : Le client envoie sa requête HTTPS sur la CONNECTION A : GET / HTTP/1.1. Le proxy la lit et la renvoie sur la CONNECTION B.

- Étape 5 : Le serveur reçoit la requête HTTPS sur la CONNECTION B et renvoie sa réponse HTTP/1.1 200 OK avec le contenu de la page demandée. Le proxy lit cette réponse et la renvoie vers la CONNECTION Aà destination du client.

Les CONNECTION A et B sont alors fermées : l'interception Man-In-The-Middle a été un succès.

2.3. Exemple de modification de certificat

À titre d'illustration, examinons les transformations qui sont réalisées sur un certificat lors d'une requête vers https://www.facebook.com, en comparant le certificat original avec celui obtenu après transformation. Tout d'abord, examinons le certificat présenté par www.facebook.com :

~$ openssl x509 -text -in certificat-original.pem

Certificate:

    Data:

        Version: 3 (0x2)

        Serial Number:

            0c:6f:c8:59:57:fa:1f:5f:c9:67:2c:9f:e6:5c:db:e6

        Signature Algorithm: sha1WithRSAEncryption

        Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert High Assurance CA-3

        Validity

            Not Before: Nov 15 00:00:00 2010 GMT

            Not After : Dec 2 23:59:59 2013 GMT

        Subject: C=US, ST=California, L=Palo Alto, O=Facebook, Inc., CN=www.facebook.com

        Subject Public Key Info:

            Public Key Algorithm: rsaEncryption

            RSA Public Key: (1024 bit)

                Modulus (1024 bit):

                    00:c1:df:7d:63:41:bd:c4:e4:fa:65:33:13:78:d5:

                    62:37:96:a7:61:f3:b1:96:bf:23:8e:ba:87:a7:ed:

                    07:f9:de:2d:eb:a8:c7:bc:ad:77:a6:5e:8d:03:03:

                   [… ici le reste de la clé publique de www.facebook.com …]

                Exponent: 65537 (0x10001)

        X509v3 extensions:

[…]

Puis examinons le certificat obtenu après transformation :

~$ openssl x509 -text -in certificat-modifie.pem

Certificate:

    Data:

        Version: 3 (0x2)

        Serial Number:

            0c:6f:c8:59:57:fa:1f:5f:c9:67:2c:9f:e6:5c:db:e6

        Signature Algorithm: sha1WithRSAEncryption

        Issuer: C=FR, ST=France, O=Proxy Certs, CN=Proxy Certs Master

        Validity

            Not Before: Nov 15 00:00:00 2010 GMT

            Not After : Dec 2 23:59:59 2013 GMT

        Subject: C=US, ST=California, L=Palo Alto, O=Facebook, Inc., CN=www.facebook.com

        Subject Public Key Info:

            Public Key Algorithm: rsaEncryption

            RSA Public Key: (1024 bit)

                Modulus (1024 bit):

                    00:a9:2f:47:fc:00:99:83:dc:4e:4a:59:55:50:f5:

                    5a:ca:1c:54:fa:0a:cd:cc:40:fe:7a:34:b3:6c:92:

                    b5:c3:8a:98:da:48:d8:da:6f:54:af:a4:50:2b:7b:

                    [… ici le reste de la clé publique du proxy …]

                Exponent: 65537 (0x10001)

        X509v3 extensions:

[…]

On voit clairement le changement d'autorité de certification et de clé publique. Dans les deux cas, les résultats ont été tronqués par souci de simplicité, sinon on pourrait également voir certains changements opérés dans les extensions de ce certificat X509 V3.

3. Analyse des résultats

À l'aide de notre dispositif, nous avons placé un iPhone 3GS sous surveillance. Premier test : nous utilisons une application nécessitant un appel aux services de géolocalisation d'Apple (exemple : la Boussole ou Maps). Le téléphone contacte immédiatement le serveur de géolocalisation d'Apple en SSL à l'adresse gs-loc.apple.com. Voici une présentation « brute » de ce premier message :

POST /clls/wloc HTTP/1.1

User-Agent: locationd (unknown version) CFNetwork/485.13.9 Darwin/11.0.0

X-Apple-Bundleid: com.apple.Maps

Accept: */*

Accept-Language: en-us

Accept-Encoding: gzip, deflate

Content-Type: application/x-www-form-urlencoded

Content-Length: 148

000000: 00 01 00 05 65 6e 5f 55 53 00 00 00 09 34 2e 33 | ....en_US....4.3

000010: 2e 32 2e 38 48 37 00 00 00 01 00 00 00 76 12 11 | .2.8H7.......v..

000020: 0a 0f 63 3a 36 30 3a 37 36 3a 65 3a 62 38 3a 63 | ..c:60:76:e:b8:c

000030: 33 12 12 0a 10 30 3a 31 66 3a 39 66 3a 66 62 3a | 3....0:1f:9f:fb:

000040: 38 37 3a 31 39 12 12 0a 10 30 3a 31 39 3a 37 30 | 87:19....0:19:70

000050: 3a 34 31 3a 33 61 3a 62 36 12 12 0a 10 32 3a 31 | :41:3a:b6....2:1

000060: 37 3a 33 33 3a 61 61 3a 37 65 3a 62 61 12 11 0a | 7:33:aa:7e:ba...

000070: 0f 30 3a 31 61 3a 32 62 3a 65 3a 36 66 3a 61 63 | .0:1a:2b:e:6f:ac

000080: 18 00 20 00 2a 0e 63 6f 6d 2e 61 70 70 6c 65 2e | .. .*.com.apple.

000090: 4d 61 70 73 | Maps

Une analyse visuelle rapide fait apparaître la version de l'OS de notre iPhone cobaye (4.3.2.8H7) et ce qui semble être des adresses MAC (BSSID), par exemple : c:60:76:e:b8:c3. La réponse fournie par le serveur d'Apple est beaucoup plus longue et nous ne la reproduirons pas ici. Elle semble avoir un format similaire, mais elle contient en revanche pas moins de 405 occurrences d'adresses MAC (ce nombre peut varier selon les cas). Reste donc à décoder plus précisément le format de ces échanges.

3.1. Jouer aux devinettes avec le format « protocol buffer »

Lors d'une de nos enquêtes précédentes, nous avions été confrontés à des données encodées dans un format ouvert inventé par Google : les « protocol buffers ». Sans trop croire qu'Apple utiliserait ce type de format, nous faisons tout de même des tests. Bonne pioche : à notre surprise, les requêtes de géolocalisation d'Apple sont presque intégralement encodées dans ce format.

Le format « protocol buffers » (ou simplement « protobuf ») est un mécanisme de sérialisation de données, comme peut l'être ASN.1 [10] ou même JSON [11]. La meilleure manière de comprendre ce format est de lire la documentation de Google [12]. Brièvement, son principe est le suivant :

- Chaque donnée est définie par deux composantes : une clé et une valeur.

- La clé est elle-même composée de deux parties :

 1) un descripteur générique de format (seulement 6 valeurs possibles) ;

 2) un identifiant unique de la donnée.

- La donnée elle-même est encodée de manière variable selon son usage.

Contrairement à un format comme XML qui contient des « tags » textuels normalement destinés à permettre à un humain de deviner le sens des données encodées, le format protobuf nécessite de jouer aux devinettes. En premier lieu, le descripteur générique de format est très vague : par exemple, s'il indique une valeur 32 bits, il reste à savoir s'il s'agit d'un entier signé, d'un entier non signé ou d'un nombre à virgule flottante. De plus, l'identifiant unique de la donnée dépend totalement du contexte.

C'est finalement en recoupant les données collectées avec le contenu de la base de données consolidated.db [1] dont nous parlions en introduction que nous avons construit une interprétation plausible des requêtes de géolocalisation envoyées vers les serveurs d'Apple, à l'aide d'outils supplémentaires que nous avons également développés.

3.2. Les demandes de géolocalisation

Nous sommes donc en mesure de revisiter la requête de géolocalisation précédente :

POST /clls/wloc HTTP/1.1

User-Agent: locationd (unknown version) CFNetwork/485.13.9 Darwin/11.0.0

X-Apple-Bundleid: com.apple.Maps

Accept: */*

Accept-Language: en-us

Accept-Encoding: gzip, deflate

Content-Type: application/x-www-form-urlencoded

Content-Length: 148

000000: 00 01 00 05 65 6e 5f 55 53 00 00 00 09 34 2e 33 | ....en_US....4.3

000010: 2e 32 2e 38 48 37 00 00 00 01 00 00 00 76 | .2.8H7.......v

Block: {

WifiDetected: {

BSSID: "c:60:76:e:b8:c3"

}

WifiDetected: {

BSSID: "0:1f:9f:fb:87:19"

}

WifiDetected: {

BSSID: "0:19:70:41:3a:b6"

}

WifiDetected: {

BSSID: "2:17:33:aa:7e:ba"

}

WifiDetected: {

BSSID: "0:1a:2b:e:6f:ac"

}

unknown3: 0

unknown4: 0

Service: "com.apple.Maps"

}

Cette requête est très simple : elle contient uniquement les adresses MAC de 5 points d'accès Wi-Fi détectés à proximité du téléphone. On notera deux choses intéressantes. Tout d'abord, la requête ne contient aucun numéro identifiant le téléphone de manière unique (comme l'IMEI ou l'UDID). Certes, le serveur d'Apple collecte l'adresse IP de notre connexion ADSL, mais c'est une information plus difficile à exploiter dans ce contexte pour identifier un dispositif mobile comme l'iPhone, car il est susceptible de varier ses méthodes de connexion à Internet pendant une même journée, cela contrairement à un PC fixe. Ensuite, on remarquera que les BSSID sont transmis sans information relative à la force des signaux des points d'accès détectés. Apple ne reçoit donc pas d'information très précise pour géolocaliser le téléphone. On va vite comprendre pourquoi : en effet, ce n'est pas Apple qui géolocalise le téléphone, mais le téléphone qui se géolocalise lui-même...

En effet, voici maintenant la réponse du serveur d'Apple, que nous avons tronquée par souci de simplicité :

HTTP/1.1 200 OK

Date: Mon, 02 May 2011 18:06:18 GMT

Content-Length: 14225

000000: 00 01 00 00 00 01 00 00 37 87 12 20 0a 0f 63 3a | ........7.. ..c:

000010: 36 30 3a 37 36 3a 65 3a 62 38 3a 63 33 12 0d 08 | 60:76:e:b8:c3...

Block: {

WifiInformation: {

BSSID: "c:60:76:e:b8:c3"

Location: {

latitude: 48.86065822

longitude: 2.38659417

confidence: 108

}

}

WifiInformation: {

BSSID: "0:1f:9f:f6:e8:b7"

Location: {

latitude: 48.86067944

longitude: 2.38658750

confidence: 98

}

}

WifiInformation: {

BSSID: "0:1a:6b:ca:d1:a1"

Location: {

latitude: 48.86068940

longitude: 2.38657420

confidence: 72

}

}

[...]

La réponse contient en tout une liste de 405 points d'accès Wi-Fi. Chacun de ces points est associé à une position géographique précise et ce que nous pensons être une estimation du niveau de confiance que l'on peut accorder à cette information. Si on place ces points sur une carte à l'aide d'un fichier KML [13], on obtient le résultat présenté à la figure 3.

Projection-des-resultats

Fig. 3 : Position des points d'accès Wi-Fi dans un quartier de Paris

Avec ces informations et avec la force du signal qu'il a mesuré en provenance des points d'accès environnants, l'iPhone est alors en mesure de calculer lui-même sa position par triangulation. Mieux encore, si le téléphone se déplace dans la même zone géographique, il n'a pas besoin de refaire une requête vers les serveurs d'Apple : il peut puiser dans les informations précédemment reçues pour se géolocaliser. Ces informations peuvent alors être stockées dans une base de données et resservir en cas de connexion défaillante, c'est sans doute le rôle du fameux fichier consolidate.db qui avait tant suscité de questions au printemps dernier.

3.3. Des messages nocturnes

Lorsqu'un iPhone est laissé allumé pendant la nuit et connecté à un point d'accès Wi-Fi, il arrive qu'il se connecte à un autre serveur d'Apple : iphone-services.apple.com, et cela, sans la moindre intervention de l'utilisateur. Un travail d'analyse nous a permis de déchiffrer en grande partie cet échange, et de découvrir une autre source d'échanges de données de géolocalisation entre l'iPhone et Apple, comme le montre l'exemple suivant :

POST /hcy/pbcwloc HTTP/1.1

User-Agent: locationd (unknown version) CFNetwork/485.13.9 Darwin/11.0.0

Connection: close

Accept: */*

Accept-Language: en-us

Accept-Encoding: gzip, deflate

Content-Type: application/x-www-form-urlencoded

Content-Length: 3387

000000: 00 01 00 05 65 6e 5f 55 53 00 00 00 09 34 2e 33 | ....en_US....4.3

000010: 2e 31 2e 38 47 34 00 00 00 64 00 00 0d 1d 0a 1b | .1.8G4...d....

Block: {

Header: {

hardware_version: "N88AP"

software_version: "iPhone OS4.3.1/8G4"

}

WifiMeasurement: {

BSSID: "0:1a:2b:49:d5:e5"

channel: 6

hidden: 0

signal_strength: -97

Location: {

latitude: 48.8356584333

longitude: 2.38246455

__32BIT_3: 0x4322f53c

timestamp: 324742217.051

__32BIT_5: 0x41ea8bd6

__32BIT_6: 0x436457fb

}

}

WifiMeasurement: {

BSSID: "0:11:50:24:6f:9c"

channel: 6

hidden: 0

signal_strength: -96

Location: {

latitude: 48.8356584333

longitude: 2.38246455

__32BIT_3: 0x4322f53c

timestamp: 324742217.051

__32BIT_5: 0x41ea8bd6

__32BIT_6: 0x436457fb

}

}

[...]

Cet exemple montre cette fois-ci des données très précises sur des points d'accès Wi-Fi qui ont été vus pendant la journée par le téléphone : latitude, longitude, canal, force du signal et même un horodatage (en secondes écoulées depuis début 2001). Naturellement, la latitude et la longitude correspondent à la position du téléphone au moment de la mesure et pas à la position des points d'accès. Ici encore, cependant, aucune information ne permet d'identifier le téléphone (à part éventuellement l'adresse IP).

La collecte de ces informations permet certainement à Apple d'enrichir sa base de géolocalisation, notamment pour y ajouter de nouveaux points d'accès Wi-Fi détectés. En recoupant les informations fournies tous les jours par des millions de téléphones, Apple est capable petit à petit de faire évoluer sa base cartographique avec une assez grande précision. C'est ce qu'on appelle le « crowdsourcing » : chaque téléphone travaille donc un peu pour Apple.

Conclusion

Cet article a rappelé qu'il est possible d'intercepter une communication SSL à condition de déposer un certificat racine sur les postes informatiques que l'on souhaite surveiller.

Notre analyse montre qu'Apple a utilisé une approche originale pour construire son mécanisme de géolocalisation : ce n'est pas le serveur d'Apple qui géolocalise le téléphone, mais le téléphone qui se géolocalise lui-même à partir des données envoyées par Apple. Ponctuellement, l'iPhone envoie néanmoins des informations détaillées sur les points d'accès Wi-Fi qu'il a vu pendant les heures passées. Une pratique qui mériterait sans doute une meilleure information d'Apple envers ses utilisateurs.

La méthode retenue par Apple semble être plutôt bonne en termes de protection de la vie privée : les données sont sécurisées par SSL/TLS et aucun numéro d'identification n'est présent dans les requêtes, même s'il reste naturellement une possibilité de traçage à partir de l'adresse IP dans certains cas. N'oublions pas cependant que les applications qui utilisent l'API de géolocalisation de l'iPhone peuvent elles-mêmes tracer les individus, même si Apple ne le fait pas.

Si un même téléphone fait une requête de géolocalisation le matin et le soir à partir de deux endroits différents, les serveurs d'Apple ne sont vraisemblablement pas en mesure de savoir qu'elles viennent du même téléphone. Le risque de pistage des personnes par Apple est donc très réduit. Peut-on en dire autant de leurs concurrents ? Vous avez maintenant tous les outils pour mener l'enquête !

Références

[1] http://radar.oreilly.com/2011/04/apple-location-tracking.html

[2] Sean Morrissey et Alex Levinson, « iOS Forensic Analysis: for iPhone, iPad, and iPod touch », APress, 2010

[3] http://mitmproxy.org/ : un proxy HTTP/SSL

[4] http://www.tcpcatcher.org/ : un proxy HTTP/SSL

[5] http://code.google.com/p/sslmeat/ : un proxy SSL en C++, GPL V3

[6] http://www.schneier.com/blog/archives/2011/09/man-in-the-midd_4.html

[7] http://en.wikipedia.org/wiki/DigiNotar

[8] http://www.openssl.org/

[9] http://tools.ietf.org/id/draft-luotonen-web-proxy-tunneling-01.txt : la requête HTTP CONNECT

[10] http://fr.wikipedia.org/wiki/ASN.1: le format ASN.1

[11] http://www.json.org/: le format JSON

[12] http://code.google.com/intl/fr-FR/apis/protocolbuffers/docs/encoding.html : Google protocol buffers

[13] http://code.google.com/intl/fr-FR/apis/kml/documentation/kmlreference.html : le format KML




Articles qui pourraient vous intéresser...

Sécurisez votre réseau

Magazine
Marque
Linux Pratique
HS n°
Numéro
49
Mois de parution
novembre 2020
Domaines
Résumé

Maintenant que notre serveur principal est déployé et que nous y avons appliqué un premier niveau de sécurisation système, occupons-nous de sa sécurisation réseau. Nous allons détailler en quoi les attaques réseau sont primordiales dans notre modèle de menace. Comme nous le verrons, l’accès distant est le risque principal qui guette nos serveurs. Nous allons mettre en œuvre une sécurité en profondeur et les mesures de protection réseau en seront une de ses dimensions importantes.

CVE-2020-3433 : élévation de privilèges sur le client VPN Cisco AnyConnect

Magazine
Marque
MISC
Numéro
112
Mois de parution
novembre 2020
Domaines
Résumé

Cet article explique comment trois vulnérabilités supplémentaires ont été découvertes dans le client VPN Cisco AnyConnect pour Windows. Elles ont été trouvées suite au développement d’un exploit pour la CVE-2020-3153 (une élévation de privilèges, étudiée dans MISC n°111). Après un rappel du fonctionnement de ce logiciel, nous étudierons chacune de ces nouvelles vulnérabilités.

Introduction au dossier : Sécurisez vos serveurs et votre réseau local

Magazine
Marque
Linux Pratique
HS n°
Numéro
49
Mois de parution
novembre 2020
Domaines
Résumé

2020 aura été une année marquante pour nos vies et nos sociétés. Il aura fallu se réinventer, trouver des solutions à des situations exceptionnelles. Dans les entreprises, l'Éducation ou la Santé, la mobilisation des ressources informatiques aura été maximale. Nos infrastructures auront ployé, tangué, parfois presque craqué, mais au final, cela aura tenu.