Les smartphones sont aujourdhui partie prenante de toutes les entreprises , avec le BYOD la menace augmente Malheureusement ces outils sont actuellement la cible de toutes les attaques pour entrer dans l'entreprise. Nous détaillerons dans cette présentation les dix risques les plus courants s'appliquant aux smartphones ainsi que les remédiations possibles dans un environnement Windows Phone
2. CISA && ISO 27005 Risk Manager
2
http://www.google.fr/#q=sebastien gioria
‣OWASP France Leader & Founder - Evangéliste
‣OWASP Global Education Comittee Member
(sebastien.gioria@owasp.org)
‣Consultant Indépendant en Sécurité des
Systèmes, spécialisé en Sécurité des Applications
Twitter :@SPoint
‣+13 ans d’expérience en Sécurité des Systèmes d’Information
‣Différents postes de manager SSI dans la banque, l’assurance et les télécoms
‣Expertise Technique
- PenTesting,
- Secure-SDLC
- Gestion du risque, Architectures fonctionnelles, Audits
- Consulting et Formation en Réseaux et Sécurité
‣Responsable du Groupe Sécurité des
Applications Web au CLUSIF
2
Friday, February 15, 13
4. 4
Top 10 Risques
• Vision multi-plateforme :
• Windows Phone, Android, IOS, Nokia, ...
• Focus sur les risques plutôt que les
vulnérabilités.
• Utilisation de l’OWASP Risk Rating
Methodology pour le classement
• https://www.owasp.org/index.php/
OWASP_Risk_Rating_Methodology
Friday, February 15, 13
5. 5
Les 10 risques
Risque
M1 - Stockage de données non sécurisé
M2 - Contrôles serveur défaillants
M3 - Protection insuffisante lors du transport de données
M4 - Injection client
M5 - Authentification et habilitation defaillante
M6 - Mauvaise gestion des sessions
M7- Utilisation de données d’entrée pour effectuer des décisions sécurité.
M8 - Perte de données via des canaux cachés
M9 - Chiffrement défectueux
M10 - Perte d’information sensible
Friday, February 15, 13
7. 7
M1 - Stockage de données non sécurisé
• Les données sensibles ne sont pas
protégées
• S’applique aux données locales, tout
comme celles disponibles dans le cloud
• Généralement du à :
• Défaut de chiffrement des données
• Cache de données qui n’est pas
généralement prévu
• Permissions globales ou faibles
• Non suivi des bonnes pratiques de la
plateforme
Impact
• Perte de
confidentialité sur
les données
• Divulgation
d’authentifiants
• Violation de vie
privée
• Non-compliance
Friday, February 15, 13
8. 8
M1 - Stockage de données non sécurisé
Friday, February 15, 13
9. 8
M1 - Stockage de données non sécurisé
Friday, February 15, 13
10. 8
M1 - Stockage de données non sécurisé
Friday, February 15, 13
12. 9
M1 - Prévention
1. Ne stocker que ce qui est réellement nécessaire
Friday, February 15, 13
13. 9
M1 - Prévention
1. Ne stocker que ce qui est réellement nécessaire
2. Ne jamais stocker de données sur des éléments
publics (SD-Card...)
Friday, February 15, 13
14. 9
M1 - Prévention
1. Ne stocker que ce qui est réellement nécessaire
2. Ne jamais stocker de données sur des éléments
publics (SD-Card...)
3. Utiliser les APIs de chiffrement et les conteneurs
sécurisés fournis par la plateforme:
Friday, February 15, 13
15. 9
M1 - Prévention
1. Ne stocker que ce qui est réellement nécessaire
2. Ne jamais stocker de données sur des éléments
publics (SD-Card...)
3. Utiliser les APIs de chiffrement et les conteneurs
sécurisés fournis par la plateforme:
4. Utilisation d’InTune
Friday, February 15, 13
16. 9
M1 - Prévention
1. Ne stocker que ce qui est réellement nécessaire
2. Ne jamais stocker de données sur des éléments
publics (SD-Card...)
3. Utiliser les APIs de chiffrement et les conteneurs
sécurisés fournis par la plateforme:
4. Utilisation d’InTune
5. Utilisation de DPAPI pour une réelle protection et pas
juste le stockage :
Friday, February 15, 13
17. 9
M1 - Prévention
1. Ne stocker que ce qui est réellement nécessaire
2. Ne jamais stocker de données sur des éléments
publics (SD-Card...)
3. Utiliser les APIs de chiffrement et les conteneurs
sécurisés fournis par la plateforme:
4. Utilisation d’InTune
5. Utilisation de DPAPI pour une réelle protection et pas
juste le stockage :
• System.Security.Cryptography.ProtectedData
Friday, February 15, 13
19. 11
M2- Contrôles serveur défaillants
• S’applique uniquement aux
services de backend.
• Non spécifique aux mobiles.
• Il n’est pas plus facile de
faire confiance au client.
• Il est nécessaire de revoir les
contrôles actuels classiques.
Impact
• Perte de
confidentialité
sur des
données
• Perte
d’intégrité sur
des données
Friday, February 15, 13
20. 12
M2 - Contrôles serveur défaillants
OWASP Top 10
• https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
OWASP Cloud Top 10
• https://www.owasp.org/images/4/47/Cloud-
Top10-Security-Risks.pdf
Friday, February 15, 13
22. 13
M2- Prévention
1. Comprendre les nouveaux risques induits par les
applications mobiles sur les architectures existantes :
Friday, February 15, 13
23. 13
M2- Prévention
1. Comprendre les nouveaux risques induits par les
applications mobiles sur les architectures existantes :
• exemple : JSON, ...REST, ....
Friday, February 15, 13
24. 13
M2- Prévention
1. Comprendre les nouveaux risques induits par les
applications mobiles sur les architectures existantes :
• exemple : JSON, ...REST, ....
2. OWASP Top 10, Cloud Top 10, Web Services Top 10
Friday, February 15, 13
25. 13
M2- Prévention
1. Comprendre les nouveaux risques induits par les
applications mobiles sur les architectures existantes :
• exemple : JSON, ...REST, ....
2. OWASP Top 10, Cloud Top 10, Web Services Top 10
• https://www.owasp.org/index.php/
Category:OWASP_Top_Ten_Project
Friday, February 15, 13
26. 13
M2- Prévention
1. Comprendre les nouveaux risques induits par les
applications mobiles sur les architectures existantes :
• exemple : JSON, ...REST, ....
2. OWASP Top 10, Cloud Top 10, Web Services Top 10
• https://www.owasp.org/index.php/
Category:OWASP_Top_Ten_Project
• https://www.owasp.org/index.php/Category:OWASP_Cloud_
%E2%80%90_10_Project
Friday, February 15, 13
27. 13
M2- Prévention
1. Comprendre les nouveaux risques induits par les
applications mobiles sur les architectures existantes :
• exemple : JSON, ...REST, ....
2. OWASP Top 10, Cloud Top 10, Web Services Top 10
• https://www.owasp.org/index.php/
Category:OWASP_Top_Ten_Project
• https://www.owasp.org/index.php/Category:OWASP_Cloud_
%E2%80%90_10_Project
3. Voir les Cheat sheets, guides de développement, l’ESAPI
Friday, February 15, 13
28. 13
M2- Prévention
1. Comprendre les nouveaux risques induits par les
applications mobiles sur les architectures existantes :
• exemple : JSON, ...REST, ....
2. OWASP Top 10, Cloud Top 10, Web Services Top 10
• https://www.owasp.org/index.php/
Category:OWASP_Top_Ten_Project
• https://www.owasp.org/index.php/Category:OWASP_Cloud_
%E2%80%90_10_Project
3. Voir les Cheat sheets, guides de développement, l’ESAPI
• https://www.owasp.org/index.php/Cheat_Sheets
Friday, February 15, 13
30. 15
M3 - Protection insuffisante lors du
transport de données
• Perte complète de chiffrement
des données transmises.
• Faible chiffrement des
données transmises.
• Fort chiffrement, mais oubli
des alertes sécurité
• Ignorer les erreurs de validation de certificats
• Retour en mode non chiffré après erreurs
Impact
• Attacks MITM
• Modification
des données
transmises
• Perte de
confidentialité
Friday, February 15, 13
31. 16
M3 - Protection insuffisante lors du
transport de données
Exemple : Protocole d’authentification des clients
Google
• L’entete d’authentification est envoyé sur HTTP
• Lorsqu’un utilisateur se connecte via un WIFI,
l’application automatiquement envoie le jeton dans
le but de synchroniser les données depuis le serveur.
• Il suffit d’écouter le réseau et de voler cet élément
pour usurper l’identité
• http://www.uni-ulm.de/in/mi/mitarbeiter/koenings/catching-authtokens.html
Friday, February 15, 13
33. 17
M3 - Prévention
1. Vérifier que les données sensibles quittent
l’appareil chiffrées.
Friday, February 15, 13
34. 17
M3 - Prévention
1. Vérifier que les données sensibles quittent
l’appareil chiffrées.
2. Quelque soit les données et les réseaux : Wifi,
NFC( coucou Renaud :) ), GSM, ....
Friday, February 15, 13
35. 17
M3 - Prévention
1. Vérifier que les données sensibles quittent
l’appareil chiffrées.
2. Quelque soit les données et les réseaux : Wifi,
NFC( coucou Renaud :) ), GSM, ....
• http://2012.hackitoergosum.org/blog/wp-
content/uploads/2012/04/HES-2012-rlifchitz-
contactless-payments-insecurity.pdf
Friday, February 15, 13
36. 17
M3 - Prévention
1. Vérifier que les données sensibles quittent
l’appareil chiffrées.
2. Quelque soit les données et les réseaux : Wifi,
NFC( coucou Renaud :) ), GSM, ....
• http://2012.hackitoergosum.org/blog/wp-
content/uploads/2012/04/HES-2012-rlifchitz-
contactless-payments-insecurity.pdf
3. Ne pas ignorer les erreurs de sécurité !
Friday, February 15, 13
40. 20
M4- Injection Client
• Utilisation des fonctions de
navigateurs dans les applications
• Apps pure Web
• Apps hybrides
• On retrouve les vulnérabilités
connues
• Injection XSS et HTML
• SQL Injection
• Des nouveautés interessantes
• Abus d’appels et de SMS
• Abus de paiements ?
Impact
• Compromission
de l’appareil
• Fraude à l’appel
• Augmentation
de privilèges
Friday, February 15, 13
41. 21
M4 - Injection client
SmsComposeTask
smsComposeTask
=
new
SmsComposeTask();
smsComposeTask.To
=
"2065550123";
smsComposeTask.Body
=
"Try
this
new
application.
It's
great!";
smsComposeTask.Show();
Facilité d’envoi de SMS
Erreur, classique....
Friday, February 15, 13
43. 22
M4 - Prévention
1. Valider les données d’entrée avant utilisation
Friday, February 15, 13
44. 22
M4 - Prévention
1. Valider les données d’entrée avant utilisation
2. Nettoyer les données en sortie avant
affichage.
Friday, February 15, 13
45. 22
M4 - Prévention
1. Valider les données d’entrée avant utilisation
2. Nettoyer les données en sortie avant
affichage.
3. Minimiser les capacités/privilèges des
applications hybrides Web.
Friday, February 15, 13
47. 24
M5- Authentification et habilitation
defaillante
• 50% du a des problèmes d’architecture,
50% du à des problèmes du mobile
• Certaines applications se reposent
uniquement sur des éléments
théoriquement inchangeables, mais
pouvant être compromis (IMEI, IMSI,
UUID)
• Les identifiants matériels persistent
apres les resets ou les nettoyages de
données.
• De l’information contextuelle ajoutée,
est utile, mais pas infaillible.
Impact
• Elevation de
Privileges
• Accès non
autorisé.
Friday, February 15, 13
49. 25
M5 - Prevention
1. De l’information contextuelle peut améliorer
les choses, mais uniquement en cas
d’implementation d’authentification multi-
facteur.
Friday, February 15, 13
50. 25
M5 - Prevention
1. De l’information contextuelle peut améliorer
les choses, mais uniquement en cas
d’implementation d’authentification multi-
facteur.
2. Impossible de faire du “Out-of-band” sur le
même matériel (eg SMS...)
Friday, February 15, 13
51. 25
M5 - Prevention
1. De l’information contextuelle peut améliorer
les choses, mais uniquement en cas
d’implementation d’authentification multi-
facteur.
2. Impossible de faire du “Out-of-band” sur le
même matériel (eg SMS...)
3. Ne jamais utiliser l’ID machine ou l’ID
opérateur (subscriber ID), comme élément
unique d’authentification.
Friday, February 15, 13
53. 27
M6 - Mauvaise gestion des sessions
• Les sessions applicatives mobiles sont
généralement plus longues que sur une
application normale.
• Dans un but de facilité d’utilisation
• Parceque le réseau est plus “lent” et moins
“sur”
• Le maintien de session applicative se fait via
• HTTP cookies
• OAuth tokens
• SSO authentication services
• Très mauvaise idée d’utiliser l’ID matériel
comme identification de session.
Impact
• Elévation de
privilèges.
• Accès non
autorisé.
• Contournement
des licenses et
des éléments de
paiements
Friday, February 15, 13
55. 28
M6- Prévention
1. Ne pas avoir peur de redemander aux utilisateurs
de se ré-authentifier plus souvent.
Friday, February 15, 13
56. 28
M6- Prévention
1. Ne pas avoir peur de redemander aux utilisateurs
de se ré-authentifier plus souvent.
2. S’assurer que les ID/token peuvent rapidement
être révoqués en cas de perte.
Friday, February 15, 13
57. 28
M6- Prévention
1. Ne pas avoir peur de redemander aux utilisateurs
de se ré-authentifier plus souvent.
2. S’assurer que les ID/token peuvent rapidement
être révoqués en cas de perte.
3. Utiliser des outils de gestion des sessions
éprouvés
Friday, February 15, 13
58. 29
M7- Utilisation de données d’entrée pour
effectuer des décisions sécurité.
• Peut être exploité pour passer
outre les permissions et les
modèles de sécurité.
• Globalement similaires sur les
différentes plateformes
• Des vecteurs d’attaques
importants
• Applications malveillantes
• Injection client
Impact
• Utilisation de
ressources
payantes.
• Exfiltration de
données
• Elevation de
privilèges.
Friday, February 15, 13
59. 30
M7- Utilisation de données d’entrée pour effectuer
des décisions sécurité.
Exemple : gestion de skype dans l’URL sur
IOS...
• http://software-security.sans.org/blog/2010/11/08/
insecure-handling-url-schemes-apples-ios/
Friday, February 15, 13
62. 31
M7- Prévention
1. Vérifier les permissions lors de l’utilisation de
données d’entrée.
2. Demander à l’utilisateur une confirmation avant
l’utilisation de fonctions sensibles ou de données
personnelles.
Friday, February 15, 13
63. 31
M7- Prévention
1. Vérifier les permissions lors de l’utilisation de
données d’entrée.
2. Demander à l’utilisateur une confirmation avant
l’utilisation de fonctions sensibles ou de données
personnelles.
• Meme si l’application est propre à l’entreprise !
Friday, February 15, 13
64. 31
M7- Prévention
1. Vérifier les permissions lors de l’utilisation de
données d’entrée.
2. Demander à l’utilisateur une confirmation avant
l’utilisation de fonctions sensibles ou de données
personnelles.
• Meme si l’application est propre à l’entreprise !
3. Lorsqu’il n’est pas possible de vérifier les
permissions, s’assurer via une étape additionnelle
du lancement de la fonction sensible.
Friday, February 15, 13
66. 33
M8- Perte de données via des canaux
cachés
• Mélange de fonctionnalités de la
plateforme et de failles de programmation.
• Les données sensibles se trouvent un peu
partout. ou l’on ne s’attend pas....
• Web caches
• Logs de clavier...
• Screenshots
• Logs (system, crash)
• Répertoires temporaires.
• Faire attention a ce que font les librairies
tierces avec les données
utilisateurs( publicité, analyse, ...)
Impact
• Perte
définitive de
données.
• Violation de la
vie privée.
Friday, February 15, 13
68. 34
M8- Prévention
1. Ne jamais stocker des authentifiants/passwds ou d’autres
informations sensibles dans les logs.
Friday, February 15, 13
69. 34
M8- Prévention
1. Ne jamais stocker des authentifiants/passwds ou d’autres
informations sensibles dans les logs.
2. Supprimer les données sensibles avant les screenshots,
utiliser les capacités des caches pour les contenu des
applications Web, ...
Friday, February 15, 13
70. 34
M8- Prévention
1. Ne jamais stocker des authentifiants/passwds ou d’autres
informations sensibles dans les logs.
2. Supprimer les données sensibles avant les screenshots,
utiliser les capacités des caches pour les contenu des
applications Web, ...
3. Debugger avec attention les applications avant mise en
production pour vérifier les fichiers produits, modifiés, lus, ....
Friday, February 15, 13
71. 34
M8- Prévention
1. Ne jamais stocker des authentifiants/passwds ou d’autres
informations sensibles dans les logs.
2. Supprimer les données sensibles avant les screenshots,
utiliser les capacités des caches pour les contenu des
applications Web, ...
3. Debugger avec attention les applications avant mise en
production pour vérifier les fichiers produits, modifiés, lus, ....
4. Porter une attention particulière aux librairies tierces.
Friday, February 15, 13
72. 34
M8- Prévention
1. Ne jamais stocker des authentifiants/passwds ou d’autres
informations sensibles dans les logs.
2. Supprimer les données sensibles avant les screenshots,
utiliser les capacités des caches pour les contenu des
applications Web, ...
3. Debugger avec attention les applications avant mise en
production pour vérifier les fichiers produits, modifiés, lus, ....
4. Porter une attention particulière aux librairies tierces.
5. Tester les applications sur différentes versions de la
plateforme....
Friday, February 15, 13
74. 36
M9- Chiffrement défectueux
• 2 catégories importantes
• Implémentations défectueuses via
l’utilisation de librairies de
chiffrement.
• Implementations personnelles de
chiffrement....
• Bien se rappeler les bases !!!
• Codage (Base64) != chiffrement
• Obfuscation != chiffrement
• Serialization != chiffrement
• Vous vous appelez Bruce ?
Impact
• Perte de
confidentialité.
• Elevation de
privilèges
• Contournemen
t de la logique
métier.
Friday, February 15, 13
77. 37
M9- Prévention
1. Stocker la clef et les données chiffrées n’est
pas correct.
2. Il vaut mieux utiliser des librairies connues de
chiffrement que sa propre librairie....
Friday, February 15, 13
78. 37
M9- Prévention
1. Stocker la clef et les données chiffrées n’est
pas correct.
2. Il vaut mieux utiliser des librairies connues de
chiffrement que sa propre librairie....
3. Utiliser les avantages éventuels de la
plateforme !
Friday, February 15, 13
79. 37
M9- Prévention
1. Stocker la clef et les données chiffrées n’est
pas correct.
2. Il vaut mieux utiliser des librairies connues de
chiffrement que sa propre librairie....
3. Utiliser les avantages éventuels de la
plateforme !
• System.Security.Cryptography
Friday, February 15, 13
80. 37
M9- Prévention
1. Stocker la clef et les données chiffrées n’est
pas correct.
2. Il vaut mieux utiliser des librairies connues de
chiffrement que sa propre librairie....
3. Utiliser les avantages éventuels de la
plateforme !
• System.Security.Cryptography
Friday, February 15, 13
84. 41
M10- Perte d’information sensible
• M10(enfoui dans le matériel) est
différent de M1 (stocké)
• Il est assez simple de faire du reverse-
engineer sur des applications mobiles...
• L’obfuscation de code ne supprime pas
le risque.
• Quelques informations classiques
trouvées :
• clefs d’API
• Passwords
• Logique métier sensible.
Impact
• Perte
d’authentifiants
• Exposition de
propriété
intellectuelle ?
Friday, February 15, 13
86. 42
M10- Prévention
1. Les clefs d’API privées portent bien leur nom.
Il ne faut pas les stocker sur le client.
Friday, February 15, 13
87. 42
M10- Prévention
1. Les clefs d’API privées portent bien leur nom.
Il ne faut pas les stocker sur le client.
2. Si il existe une logique métier propriétaire, il
convient de la faire executée par le serveur !
Friday, February 15, 13
88. 42
M10- Prévention
1. Les clefs d’API privées portent bien leur nom.
Il ne faut pas les stocker sur le client.
2. Si il existe une logique métier propriétaire, il
convient de la faire executée par le serveur !
3. Il n’y a jamais ou presque de réelle raison de
stocker des mots de passes en dur (si vous le
pensez, vous avez d’autres problèmes à
venir...)
Friday, February 15, 13
92. 44
Conclusion
• La sécurité mobile en est au début.
• Nous venons d’identifier quelques problèmes,
il est nécessaire de les corriger !
Friday, February 15, 13
93. 44
Conclusion
• La sécurité mobile en est au début.
• Nous venons d’identifier quelques problèmes,
il est nécessaire de les corriger !
• Les plateformes deviennent plus matures, les
applications le doivent aussi...
Friday, February 15, 13
94. 44
Conclusion
• La sécurité mobile en est au début.
• Nous venons d’identifier quelques problèmes,
il est nécessaire de les corriger !
• Les plateformes deviennent plus matures, les
applications le doivent aussi...
• Ne pas oublier que la sécurité mobile
comporte une partie application
serveur !
Friday, February 15, 13
95. Liens
•OWASP Mobile Project : https://www.owasp.org/index.php/
OWASP_Mobile_Security_Project
•OWASP Top10 : https://www.owasp.org/index.php/
Category:OWASP_Top_Ten_Project
•http://www.windowsphone.com/en-US/business/security
•http://windowsphonehacker.com/articles/
the_complete_guide_to_jailbreaking_windows_phone_7_an
d_7.5-09-24-11
45
Friday, February 15, 13
97. @SPoint
sebastien.gioria@owasp.org
46
Il n'y a qu'une façon d'échouer, c'est d'abandonner avant
d'avoir réussi [Olivier Lockert]
Vous pouvez donc vous
protéger de lui maintenant...
Friday, February 15, 13