Analyse des vulnérabilités des Apps Android

Selon « OWASP Mobile Security Testing » les phases pour réaliser un pentest d'une application mobile sont les suivantes :

• Collecte : Cette étape collecte les informations de l'application à analyser. Type d'application, fabricant, versions précédentes, ressources utilisées, etc.
  

• Analyse statique : un travail de rétro-ingénierie est effectué sur le binaire lui-même, où nous pouvons obtenir des informations sur les autorisations, les activités principales, les ressources, les erreurs de configuration, les points d'entrée du système, les informations codées en dur (APIkeys ou informations d'identification), etc.
  

• Analyse dynamique : un travail de rétro-ingénierie est effectué sur le processus binaire en cours d'exécution, où nous pouvons étudier et obtenir des informations en temps réel sur le comportement de l'application, telles que la connaissance des fichiers qu'elle crée/modifie/accède dans le système, des données sans chiffrer et informations sensibles, analyse des logs, sniffage du trafic réseau généré par l'application, fuzzing pour vérifier d'éventuelles vulnérabilités telles que "Buffer OverFlow" (BoF), "SQL Injection" (SQLi), "Cross-site scripting" (XSS), "Inclusion de fichier local" (LFI), "Exécution de code à distance" (RCE), etc.

En surfant sur le net, nous pouvons trouver de nombreux outils d'analyse des applications Android, et tous sont concentrés sous la même machine virtuelle (MV) appelée "Androl4b". Il s'agit d'une machine virtuelle basée sur le système d'exploitation Ubuntu, et elle est purement axée sur les fonctionnalités de sécurité du système d'exploitation Android. À cette fin, il comprend une collection d'outils de sécurité pour l'ingénierie inverse et l'analyse des logiciels malveillants dans les applications Android, parmi lesquels les plus remarquables sont "Mobile Security Framework" (MobSF), "ByteCodeViewer", "Drozer", "APKtool", "AndroidStudio", "BurpSuite", "MARA", "Wireshark", "FindBugs-IDEA" et "AndroBugs Framework", entre autres. De cette machine virtuelle, il faut noter qu'elle fonctionne parfaitement dans VirtualBox mais pose certains problèmes dans Vmware.

Androlab intègre un ensemble de laboratoires très intéressants pour apprendre à effectuer des analyses de vulnérabilité dans des applications Android telles que Damn Insecure et Vulnérable App for Android (DIVA), InsecureBank v2, DroidBench et GoatDroid. Par exemple, DIVA est composé d'un ensemble d'applications Android intentionnellement programmées pour être vulnérables, et pour sensibiliser les développeurs et les professionnels de la sécurité aux vulnérabilités les plus courantes dans les applications, dues à des pratiques de codage pauvres ou non sécurisées.

À bientôt!!

F5 APM - Microsoft Exchange 2019

J'ai récemment participé à un projet où le client devait migrer les appliances MS Storefront vers F5 APM. Ils avaient déjà un BIG-IP LTM pour équilibrer la charge des services MS Exchange et ils voulaient déployer un nouveau BIG-IP APM devant le BIG-IP LTM pour sécuriser les services de messagerie tels que OWA, EWS, OAB, ActiveSync et Autodiscover. De plus, ils avaient besoin de SSO pour le service OWA.

 

Exchange Proxy

Au début, le client pensait que le déploiement et la configuration seraient faciles avec une iApp. Cependant, bien qu'il s'agisse d'une configuration facile, les iApps qu'ils connaissaient étaient obsolètes. Nous leur montrons les nouveaux modèles AS3 et FAST mais cette architecture ne correspondait pas à leurs besoins. Par conséquent, nous nous sommes retrouvés dans la configuration guidée de BIG-IP APM où nous avons déployé les services MS Exchange avec SSO sur le site web OWA.

 

F5 APM - Guided Configuration

Nous pouvons regarder dans la vidéo suivante les options de configuration de la configuration guidée mais je n'avais pas de serveur MS Exchange pour les tests. Je suis tellement désolé parce que je ne peux pas montrer que toute la plate-forme fonctionne correctement. Je voudrais souligner que cela fonctionne pour Exchange 2019 mais nous avons dû supprimer certaines iRule du serveur virtuel. Si nous ne supprimons pas ces iRule, la session TCP se réinitialise encore et encore. Par conséquent, la configuration guidée est prête pour Exchange 2013 et Exchange 2016, mais elle peut également fonctionner dans Exchange 2019 avec peu de modifications.

 

D'autre part, nous pouvons également utiliser le modèle AS3 et FAST pour déployer MS Exchange 2019. Cependant, c'est une bonne idée lorsque nous avons LTM et APM dans le même BIG-IP. Peut-être que cela peut aussi fonctionner avec quelques changements mais je n'ai pas essayé de cette façon.

 

F5 Application Services Templates

Passez une bonne journée!!

OWASP Mobile App Security (MAS)

J'ai écrit sur OWASP Mobile Top 10 Vulnerabilities et OWASP MSGT UnCrackable Level 1 il y a un an lorsque j'ai étudié comment sécuriser les appareils mobiles pour un cours de sécurité. Cette année, j'étudie à nouveau ces questions et je voulais écrire sur le projet OWASP Mobile App Security (MAS), qui a récemment été renommé. Actuellement, le projet OWASP MAS comprend la norme de vérification MAS (MASVS), le guide de test MAS (MASTG), les listes de contrôle MAS et les crackmes MAS. C'est donc un projet avec beaucoup de ressources intéressantes pour sécuriser les applications mobiles.

D’une part, le guide de test de sécurité mobile OWASP (MASTG) est un manuel complet pour tester la sécurité des applications mobiles. Décrit les processus et les techniques de vérification des exigences répertoriées dans la norme de vérification de la sécurité des applications mobiles (MASVS) et fournit une base de référence pour des tests de sécurité complets et cohérents. D'autre part, le MASVS est un projet communautaire visant à établir un cadre d'exigences de sécurité pour la conception, le développement et le test de la sécurité des applications mobiles iOS et Android.

Le guide de test général de MASTG contient une méthodologie de test de sécurité des applications mobiles et des techniques générales d'analyse des vulnérabilités telles qu'elles s'appliquent à la sécurité des applications mobiles. Il contient également des cas de test techniques supplémentaires indépendants du système d'exploitation, tels que l'authentification et la gestion de session, les communications réseau et la cryptographie. Par exemple, il y a des tests sur le processus d'authentification et le processus de cryptage.

Le guide de test Android de MASTG couvre les tests de sécurité mobile pour la plate-forme Android, y compris les bases de la sécurité, les cas de test de sécurité, les techniques d'ingénierie inverse et la prévention, ainsi que les techniques et la prévention de la falsification. Par exemple, il y a des tests sur les API de stockage d'Android pour vérifier si les meilleures pratiques ont été utilisées. Il y a également des tests de vérification de certificat SSL fiables pour voir si l'application mobile accepte les certificats SSL non valides ou malveillants.

Le guide de test iOS de MASTG couvre les tests de sécurité mobile pour la plate-forme iOS, y compris un aperçu du système d'exploitation iOS, les tests de sécurité, les techniques d'ingénierie inverse et la prévention, ainsi que les techniques et la prévention de la falsification. Par exemple, il y des tests sur l'architecture de sécurité iOS, la structure des applications, la communication inter-processus et la publication des applications.

Le MASVS peut être utilisé pour établir un niveau de confiance dans la sécurité des applications mobiles. Cette norme définit deux niveaux de vérification de sécurité (MASVS-L1 et MASVS-L2), ainsi qu'un ensemble d'exigences de résistance à la rétro-ingénierie (MASVS-R). Le niveau MASVS-L1 contient des exigences de sécurité génériques recommandées pour toutes les applications mobiles, tandis que MASVS-L2 doit être appliqué aux applications qui traitent des données hautement sensibles.

Comment testez-vous les applications mobiles ?

F5 APM - OAuth JWT Token

J'ai déjà écrit sur Fédération OAuth et OAuth Access Token. Cependant, je n'ai pas encore écrit sur le système de jetons le plus largement utilisé. Jetons JWT. JSON Web Token (JWT, RFC 7519) est un moyen d'encoder les revendications dans un document JSON qui est ensuite signé. Les JWT peuvent être utilisés comme jetons porteurs OAuth 2.0 pour coder toutes les parties pertinentes d'un jeton d'accès dans le jeton d'accès lui-même au lieu de devoir les stocker dans une base de données.

Les avantages offerts par l'utilisation de JWT sont les suivants : Permet la signature et le cryptage des données. Le format est facile à comprendre. Il permet de se déployer comme mécanisme d'authentification dans les appels entre services. La validation des jetons peut être effectuée hors ligne, contrairement aux jetons opaques qui nécessitent une connexion au service qui a émis le jeton pour les valider. Les jetons JWT n'ont pas besoin d'être validés en contactant l'émetteur, il suffit d'avoir la clé publique qui a signé le jeton. Cependant, JWT présente également des inconvénients dont il faut être conscient. Par exemple, ils ne sont pas faciles à révoquer car leur validation, étant hors ligne, ne dépend pas d'un seul point.

 

JWT Token

La représentation d'un jeton JWT est composée de trois parties distinctes séparées par un point (.). Chaque partie a un encodage en base 64 qui, une fois décodé, nous donne un JSON pour les deux premières parties et les données cryptographiques pour la troisième partie. L'en-tête contient le type de jeton et les algorithmes cryptographiques pour sa vérification et/ou son déchiffrement. La charge utile est constituée des données de l'utilisateur (revendications) et le tiers contient la signature ou le cryptage des données qui en assure l'intégrité et/ou la confidentialité.

 

Ci-dessous, vous pouvez voir la génération du jeton JWT, signé par RSA, avec le type d'octroi ROPC approprié dans les cas où le propriétaire de la ressource a une relation de confiance avec le client (par exemple, le client mobile d'un service) et dans les situations où le client peut obtenir les informations d'identification du propriétaire de la ressource. Dans cette méthode d'octroi, au lieu de rediriger l'utilisateur vers le serveur d'autorisation, le client lui-même demandera à l'utilisateur le nom d'utilisateur et le mot de passe du propriétaire de la ressource. Le client enverra ensuite ces informations d'identification au serveur d'autorisation avec les propres informations d'identification du client.

 

A bientôt mes amis ! Avez-vous déjà configuré le jeton JWT dans F5 APM ?