2013 02-12-owasp top10 mobile - attaques et solutions sur windows phone (sec309)

The OWASP Foundation
http://www.owasp.org

OWASP Top10 Mobile
Risks
Sébastien Gioria
OWASP France Leader
OWASP Global Education Committee

Microsoft TechDays 2013 - 12 Février 2013 - Paris

Copyright © The OWASP Foundation
Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License.

Friday, February 15, 13

http://www.google.fr/#q=sebastien gioria
‣Consultant Indépendant en Sécurité des
Systèmes, spécialisé en Sécurité des Applications

‣OWASP France Leader & Founder - Evangéliste
‣OWASP Global Education Comittee Member
(sebastien.gioria@owasp.org)

‣Responsable du Groupe Sécurité des
Applications Web au CLUSIF
Twitter :@SPoint

CISA && ISO 27005 Risk Manager

‣ +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é
2
2

Top 10 Risques


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

4

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

5


• Les données sensibles ne sont pas Impact
protégées
• Perte de
• S’applique aux données locales, tout confidentialité sur
comme celles disponibles dans le cloud
les données
• Généralement du à :
• Divulgation
• Défaut de chiffrement des données
d’authentifiants
• Cache de données qui n’est pas
généralement prévu • Violation de vie
• Permissions globales ou faibles privée
• Non suivi des bonnes pratiques de la • Non-compliance
plateforme

7


8

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
9

M2- Contrôles serveur défaillants

• S’applique uniquement aux Impact
services de backend.
• Perte de
• Non spécifique aux mobiles. confidentialité
sur des
• Il n’est pas plus facile de
données
faire confiance au client.
• Il est nécessaire de revoir les • Perte
d’intégrité sur
contrôles actuels classiques.
des données

11

M2 - Contrôles serveur défaillants

OWASP Top 10 OWASP Cloud Top 10

• https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project • https://www.owasp.org/images/4/47/Cloud-
Top10-Security-Risks.pdf

12

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
13

M3 - Protection insuffisante lors du
transport de données
• Perte complète de chiffrement Impact
des données transmises.
• Attacks MITM
• Faible chiffrement des
données transmises.
• Modification
des données
• Fort chiffrement, mais oubli transmises
des alertes sécurité
• Perte de
• Ignorer les erreurs de validation de certificats
confidentialité
• Retour en mode non chiffré après erreurs

15

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

16

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

17

M4- Injection Client
• Utilisation des fonctions de Impact
navigateurs dans les applications
• Apps pure Web
• Compromission
• Apps hybrides
de l’appareil
• On retrouve les vulnérabilités
connues • Fraude à l’appel
• Injection XSS et HTML

• SQL Injection
• Augmentation
de privilèges
• Des nouveautés interessantes
• Abus d’appels et de SMS

• Abus de paiements ?

20

M4 - Injection client

Facilité d’envoi de SMS
SmsComposeTask
smsComposeTask
=
new
SmsComposeTask();

smsComposeTask.To
=
"2065550123";
smsComposeTask.Body
=
"Try
this
new
application.
It's
great!";

smsComposeTask.Show();

Erreur, classique....

21

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.

22

M5- Authentification et habilitation
defaillante
• 50% du a des problèmes d’architecture, Impact
50% du à des problèmes du mobile
• Certaines applications se reposent • Elevation de
uniquement sur des éléments Privileges
théoriquement inchangeables, mais
pouvant être compromis (IMEI, IMSI,
UUID)
• Accès non
autorisé.
• 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.
24

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.

25

M6 - Mauvaise gestion des sessions
• Les sessions applicatives mobiles sont Impact
généralement plus longues que sur une
application normale.
• Dans un but de facilité d’utilisation • Elévation de
• Parceque le réseau est plus “lent” et moins
privilèges.
“sur”
• Accès non
• Le maintien de session applicative se fait via autorisé.
• HTTP cookies
• OAuth tokens
• Contournement
des licenses et
• SSO authentication services
des éléments de
• Très mauvaise idée d’utiliser l’ID matériel
paiements
comme identification de session.

27

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

28

M7- Utilisation de données d’entrée pour
effectuer des décisions sécurité.
• Peut être exploité pour passer Impact
outre les permissions et les
modèles de sécurité. • Utilisation de
ressources
• Globalement similaires sur les
payantes.
différentes plateformes
• Des vecteurs d’attaques • Exfiltration de
importants données
• Applications malveillantes • Elevation de
• Injection client privilèges.
29

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/

30

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

M8- Perte de données via des canaux
cachés
• Mélange de fonctionnalités de la Impact
plateforme et de failles de programmation.
• Les données sensibles se trouvent un peu
partout. ou l’on ne s’attend pas.... • Perte
• Web caches définitive de
• Logs de clavier... données.
• Screenshots
• Logs (system, crash)
• Violation de la
• Répertoires temporaires.
vie privée.
• Faire attention a ce que font les librairies
tierces avec les données
utilisateurs( publicité, analyse, ...)

33

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

34

M9- Chiffrement défectueux
• 2 catégories importantes
Impact
• Implémentations défectueuses via
l’utilisation de librairies de • Perte de
chiffrement.
confidentialité.
• Implementations personnelles de
chiffrement.... • Elevation de
• Bien se rappeler les bases !!! privilèges
• Codage (Base64) != chiffrement
• Contournemen
• Obfuscation != chiffrement t de la logique
• Serialization != chiffrement métier.
• Vous vous appelez Bruce ?
36

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

37

Dark side ?

40

M10- Perte d’information sensible
• M10(enfoui dans le matériel) est Impact
différent de M1 (stocké)
• Il est assez simple de faire du reverse- • Perte
engineer sur des applications mobiles...
d’authentifiants
• L’obfuscation de code ne supprime pas
le risque. • Exposition de
propriété
• Quelques informations classiques
trouvées : intellectuelle ?
• clefs d’API
• Passwords
• Logique métier sensible.
41

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

42

Conclusion


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 !

44

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

Vous pouvez donc vous
protéger de lui maintenant...

@SPoint

sebastien.gioria@owasp.org

46


Vous pouvez donc vous
protéger de lui maintenant...

@SPoint

sebastien.gioria@owasp.org

Il n'y a qu'une façon d'échouer, c'est d'abandonner avant
d'avoir réussi [Olivier Lockert]
46


2013 02-12-owasp top10 mobile - attaques et solutions sur windows phone (sec309)

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (20)

Similar a 2013 02-12-owasp top10 mobile - attaques et solutions sur windows phone (sec309)

Similar a 2013 02-12-owasp top10 mobile - attaques et solutions sur windows phone (sec309) (20)

Más de Sébastien GIORIA

Más de Sébastien GIORIA (20)

2013 02-12-owasp top10 mobile - attaques et solutions sur windows phone (sec309)