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

Post on 21-Jun-2015

805 Views

Category:

Technology

0 Downloads

Preview:

Click to see full reader

DESCRIPTION

Présentation effectuée aux TechDays 2013 sur Windows Phone 8 et le top10 OWASP

Transcript

The OWASP Foundationhttp://www.owasp.org

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

OWASP Top10 Mobile Risks

Sébastien GioriaOWASP 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

Friday, February 15, 13

Top 10 Risques

Friday, February 15, 13

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

Les 10 risquesRisque

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

6Friday, February 15, 13

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

M1 - Stockage de données non sécurisé

Friday, February 15, 13

8

M1 - Stockage de données non sécurisé

Friday, February 15, 13

8

M1 - Stockage de données non sécurisé

Friday, February 15, 13

9

M1 - Prévention

Friday, February 15, 13

9

M1 - Prévention

1. Ne stocker que ce qui est réellement nécessaire

Friday, February 15, 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

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

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

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

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

10Friday, February 15, 13

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

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

13

M2- Prévention

Friday, February 15, 13

13

M2- Prévention

1. Comprendre les nouveaux risques induits par les applications mobiles sur les architectures existantes :

Friday, February 15, 13

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

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

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

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

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

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

14Friday, February 15, 13

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

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

17

M3 - Prévention

Friday, February 15, 13

17

M3 - Prévention1. Vérifier que les données sensibles quittent

l’appareil chiffrées.

Friday, February 15, 13

17

M3 - Prévention1. 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

17

M3 - Prévention1. 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

17

M3 - Prévention1. 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

18Friday, February 15, 13

18Friday, February 15, 13

19Friday, February 15, 13

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

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

22

M4 - Prévention

Friday, February 15, 13

22

M4 - Prévention

1. Valider les données d’entrée avant utilisation

Friday, February 15, 13

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

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

23Friday, February 15, 13

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

25

M5 - Prevention

Friday, February 15, 13

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

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

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

26Friday, February 15, 13

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

28

M6- Prévention

Friday, February 15, 13

28

M6- Prévention

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

Friday, February 15, 13

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

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

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

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

31

M7- Prévention

Friday, February 15, 13

31

M7- Prévention

1. Vérifier les permissions lors de l’utilisation de données d’entrée.

Friday, February 15, 13

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

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

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

32Friday, February 15, 13

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

34

M8- Prévention

Friday, February 15, 13

34

M8- Prévention1. Ne jamais stocker des authentifiants/passwds ou d’autres

informations sensibles dans les logs.

Friday, February 15, 13

34

M8- Prévention1. 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

34

M8- Prévention1. 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

34

M8- Prévention1. 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

34

M8- Prévention1. 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

35Friday, February 15, 13

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

• Contournement de la logique métier.

Friday, February 15, 13

37

M9- Prévention

Friday, February 15, 13

37

M9- Prévention

1. Stocker la clef et les données chiffrées n’est pas correct.

Friday, February 15, 13

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

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

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

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

38Friday, February 15, 13

39Friday, February 15, 13

Dark side ?

40Friday, February 15, 13

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

42

M10- Prévention

Friday, February 15, 13

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

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

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

Conclusion

Friday, February 15, 13

44

Conclusion

Friday, February 15, 13

44

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

Friday, February 15, 13

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

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

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

@SPoint

sebastien.gioria@owasp.org

46

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

Friday, February 15, 13

@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

top related