OWASP Top10 Mobile - Attaques et solutions sur Windows Phone

The OWASP Foundation
http://www.owasp.org
Copyright © The OWASP Foundation
Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License.
OWASP Top10 Mobile
Risks
Sébastien Gioria
OWASP France Leader
OWASP Global Education Committee
Microsoft TechDays 2013 - 12 Février 2013 - Paris
Friday, February 15, 13

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

Top 10 Risques

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

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

7
• 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

8

9
M1 - Prévention

9
M1 - Prévention
1. Ne stocker que ce qui est réellement nécessaire

9
M1 - Prévention
2. Ne jamais stocker de données sur des éléments
publics (SD-Card...)

9
M1 - Prévention
3. Utiliser les APIs de chiffrement et les conteneurs
sécurisés fournis par la plateforme:

9
M1 - Prévention
4. Utilisation d’InTune

9
M1 - Prévention
5. Utilisation de DPAPI pour une réelle protection et pas
juste le stockage :

9
M1 - Prévention
5. Utilisation de DPAPI pour une réelle protection et pas
juste le stockage :
• System.Security.Cryptography.ProtectedData

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

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

13
M2- Prévention

13
M2- Prévention
1. Comprendre les nouveaux risques induits par les
applications mobiles sur les architectures existantes :

13
M2- Prévention
• exemple : JSON, ...REST, ....

13
M2- Prévention
2. OWASP Top 10, Cloud Top 10, Web Services Top 10

13
M2- Prévention
Category:OWASP_Top_Ten_Project

13
M2- Prévention
• https://www.owasp.org/index.php/Category:OWASP_Cloud_
%E2%80%90_10_Project

13
M2- Prévention
3. Voir les Cheat sheets, guides de développement, l’ESAPI

13
M2- Prévention
3. Voir les Cheat sheets, guides de développement, l’ESAPI
• https://www.owasp.org/index.php/Cheat_Sheets

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é

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

17
M3 - Prévention

17
M3 - Prévention
1. Vérifier que les données sensibles quittent
l’appareil chiffrées.

17
M3 - Prévention
2. Quelque soit les données et les réseaux : Wifi,
NFC( coucou Renaud :) ), GSM, ....

17
M3 - Prévention
• http://2012.hackitoergosum.org/blog/wp-
content/uploads/2012/04/HES-2012-rlifchitz-
contactless-payments-insecurity.pdf

17
M3 - Prévention
• 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é !

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

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....

22
M4 - Prévention

22
M4 - Prévention
1. Valider les données d’entrée avant utilisation

22
M4 - Prévention
2. Nettoyer les données en sortie avant
affichage.

22
M4 - Prévention
2. Nettoyer les données en sortie avant
affichage.
3. Minimiser les capacités/privilèges des
applications hybrides Web.

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é.

25
M5 - Prevention

25
M5 - Prevention
1. De l’information contextuelle peut améliorer
les choses, mais uniquement en cas
d’implementation d’authentification multi-
facteur.

25
M5 - Prevention
facteur.
2. Impossible de faire du “Out-of-band” sur le
même matériel (eg SMS...)

25
M5 - Prevention
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.

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

28
M6- Prévention

28
M6- Prévention
1. Ne pas avoir peur de redemander aux utilisateurs
de se ré-authentifier plus souvent.

28
M6- Prévention
2. S’assurer que les ID/token peuvent rapidement
être révoqués en cas de perte.

28
M6- Prévention
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

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.

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/

31
M7- Prévention

31
M7- Prévention
1. Vérifier les permissions lors de l’utilisation de
données d’entrée.

31
M7- Prévention
2. Demander à l’utilisateur une confirmation avant
l’utilisation de fonctions sensibles ou de données
personnelles.

31
M7- Prévention
personnelles.
• Meme si l’application est propre à l’entreprise !

31
M7- Prévention
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.

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.

34
M8- Prévention

34
M8- Prévention
1. Ne jamais stocker des authentifiants/passwds ou d’autres
informations sensibles dans les logs.

34
M8- Prévention
2. Supprimer les données sensibles avant les screenshots,
utiliser les capacités des caches pour les contenu des
applications Web, ...

34
M8- Prévention
3. Debugger avec attention les applications avant mise en
production pour vérifier les fichiers produits, modifiés, lus, ....

34
M8- Prévention
4. Porter une attention particulière aux librairies tierces.

34
M8- Prévention
4. Porter une attention particulière aux librairies tierces.
5. Tester les applications sur différentes versions de la
plateforme....

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.

37
M9- Prévention

37
M9- Prévention
1. Stocker la clef et les données chiffrées n’est
pas correct.

37
M9- Prévention
pas correct.
2. Il vaut mieux utiliser des librairies connues de
chiffrement que sa propre librairie....

37
M9- Prévention
pas correct.
3. Utiliser les avantages éventuels de la
plateforme !

37
M9- Prévention
pas correct.
3. Utiliser les avantages éventuels de la
plateforme !
• System.Security.Cryptography

Dark side ?
40

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 ?

42
M10- Prévention

42
M10- Prévention
1. Les clefs d’API privées portent bien leur nom.
Il ne faut pas les stocker sur le client.

42
M10- Prévention
2. Si il existe une logique métier propriétaire, il
convient de la faire executée par le serveur !

42
M10- Prévention
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...)

Conclusion

44
Conclusion

44
Conclusion
• La sécurité mobile en est au début.

44
Conclusion
• Nous venons d’identifier quelques problèmes,
il est nécessaire de les corriger !

44
Conclusion
• Les plateformes deviennent plus matures, les
applications le doivent aussi...

44
Conclusion
• Les plateformes deviennent plus matures, les
applications le doivent aussi...
• Ne pas oublier que la sécurité mobile
comporte une partie application
serveur !

Liens
•OWASP Mobile Project : https://www.owasp.org/index.php/
OWASP_Mobile_Security_Project
•OWASP Top10 : https://www.owasp.org/index.php/
•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

@SPoint
sebastien.gioria@owasp.org
46
Vous pouvez donc vous
protéger de lui maintenant...

@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...

OWASP Top10 Mobile - Attaques et solutions sur Windows Phone

Contenu connexe

Tendances

Similaire à OWASP Top10 Mobile - Attaques et solutions sur Windows Phone

Plus de Microsoft

OWASP Top10 Mobile - Attaques et solutions sur Windows Phone