Hacking applications mobiles et IoT

1. Architecture d’une application Android

Une application Android repose sur un modèle modulaire articulé autour de composants fondamentaux. Ces derniers communiquent entre eux selon un cycle de vie bien défini. Les quatre composants principaux sont les activités (Activities), qui représentent les interfaces utilisateurs ; les services (Services), qui permettent d’exécuter des traitements en arrière-plan ; les récepteurs de diffusion (BroadcastReceivers), utilisés pour réagir à des événements système ou applicatifs ; et les fournisseurs de contenu (ContentProviders), qui facilitent l’échange de données structurées entre applications.

Autre point central d’une application Android, le fichier AndroidManifest.xml. Il déclare les composants de l’application, les permissions requises, les activités exportées, et les intentions (intents) qu’elle est capable de traiter. Mal configuré, ce fichier peut exposer des points d’entrée...

1. Identifier les secrets codés en dur dans le code

Lorsqu’une application mobile contient des clés d’API, des tokens d’authentification ou même des identifiants de base de données directement écrits dans le code source, elle devient vulnérable dès que ce code est accessible. Or, un fichier APK peut être facilement décompilé à l’aide d’outils comme jadx ou MobSF. En analysant les classes Java reconstituées, il est possible d’identifier des chaînes de caractères sensibles qui n’auraient jamais dû y figurer. Cela permet à un attaquant d’interagir avec des services tiers (API cloud, bases de données distantes, services de paiement) comme s’il était l’application elle-même, avec tous les privilèges associés.

2. Comprendre les dangers d’une logique de sécurité côté client

Une erreur fréquente dans le développement mobile consiste à implémenter des contrôles de sécurité directement dans l’application, sans vérification serveur. Par exemple, si le client décide seul qu’un utilisateur est « admin » en se basant sur une variable locale, il est très facile de modifier cette valeur lors de l’exécution....

1. Comprendre l’analyse dynamique dans un contexte mobile

L’analyse dynamique consiste à observer le comportement réel d’une application mobile lorsqu’elle s’exécute, en particulier ses communications avec les serveurs distants. Contrairement à l’analyse statique, qui se concentre sur le code source ou compilé, l’analyse dynamique permet de détecter des interactions réseau inattendues, de suivre les données transmises et d’identifier les failles de logique dans les échanges entre client et serveur.

Cette approche est d’autant plus pertinente dans les tests de sécurité que de nombreuses vulnérabilités ne sont visibles qu’en situation réelle : transmission d’identifiants sans chiffrement, absence de contrôle côté serveur, fuite de données sensibles dans les requêtes ou réponses HTTP, ou encore absence de jetons de session valides.

2. Interception du trafic HTTPS avec Burp Suite

Pour rappel, Burp Suite est un proxy HTTPS qui intercepte, modifie et rejoue les requêtes générées par une application. Pour qu’il puisse analyser les échanges d’une application mobile, il doit être configuré comme proxy intermédiaire sur l’appareil, qu’il s’agisse d’un smartphone réel ou d’un émulateur.

Supposons qu’une application mobile réalise une connexion vers une API à l’adresse https://api.exemple.com/login en envoyant les identifiants de l’utilisateur. En configurant Burp Suite comme proxy, il devient possible de visualiser la requête...

1. Jetons d’authentification faibles ou réutilisables (JWT, tokens)

De nombreuses applications mobiles s’appuient sur des jetons d’authentification temporaires pour identifier l’utilisateur une fois connecté. Ces jetons, souvent au format JWT (JSON Web Token), sont stockés localement sur l’appareil et transmis dans les en-têtes HTTP (Authorization: Bearer <token>) pour chaque requête. Leur sécurité dépend entièrement de deux facteurs : leur robustesse (signature, durée de validité) et le bon contrôle de leur usage côté serveur.

Un problème fréquent est la réutilisation illimitée d’un jeton : une fois intercepté ou récupéré, il permet d’accéder à l’API même après...

1. Exposition fréquente des services : Telnet, FTP, HTTP non protégés

De nombreux équipements connectés exposent, dès leur mise en route, des services réseau en écoute sans aucune mesure de sécurisation. Parmi les plus fréquemment rencontrés, Telnet, FTP ou encore un serveur HTTP simplifié sont accessibles depuis le réseau local, parfois même exposés directement sur Internet via une redirection UPnP (Universal Plug and Play) automatique. Ces services sont généralement configurés sans chiffrement et utilisent des identifiants par défaut laissés actifs, comme les classiques admin/admin ou root/root, qu’un attaquant peut exploiter sans compétence particulière. Un simple scan Nmap suffit à les détecter, et une tentative de connexion manuelle permet souvent un accès total à l’équipement. Ce constat révèle une faiblesse systémique : l’absence de durcissement de la configuration réseau dès la phase de fabrication.

2. Accès à l’interface d’administration ou au shell sans authentification

Lorsqu’un service HTTP est présent, il expose le plus souvent une interface d’administration à laquelle il est possible d’accéder avec peu ou pas de contrôle. Dans les cas les plus critiques, la page de login peut être contournée par un paramètre d’URL mal filtré ou via un cookie falsifié. D’autres appareils présentent une console directe sans même exiger d’authentification, accessible soit par le réseau via Telnet, soit physiquement via un port série (UART) encore actif sur la carte mère. Cette console, une fois reliée à un adaptateur USB-série, donne souvent un accès direct au système embarqué, généralement...

1. Sur les applications mobiles

Une application mobile n’est jamais isolée : elle fonctionne toujours en interaction avec un backend, des API distantes et parfois des services tiers. Cette architecture en couches nécessite une attention particulière à chaque niveau pour prévenir les abus.

La première ligne de défense repose sur l’obfuscation du code, qui constitue un durcissement complémentaire mais ne suffit pas à assurer la sécurité complète. En effet, une application Android peut être décompilée très facilement à l’aide d’outils comme JADX ou apktool. Pour éviter que les chaînes sensibles, la logique d’authentification ou les clés d’API ne soient lisibles en clair dans le code, il est indispensable d’utiliser un obfuscateur comme ProGuard ou R8, qui complexifie la lecture du bytecode et renforce la résistance à l’analyse...