CVE-2024-23700 - Serveur C2 : Serveur de commande et de collecte d'informations

Projet illustrant la conception et la construction d'un serveur de commande et de collecte d'informations (Command & Control - Serveur C2) destiné au scénario expérimental d'exploitation de la vulnérabilité d'élévation de privilèges CVE-2024-23700. Ce serveur joue le rôle de réception, de traitement, de classification et d'affichage des données sensibles dérobées depuis l'appareil Android cible.

La documentation et le code source de ce dépôt servent uniquement à des fins d'apprentissage, d'analyse de sécurité et de tests dans un environnement autorisé. Ne pas utiliser sur des appareils, comptes ou données hors du cadre de tests légitimes.

Informations sur le projet

Projet rattaché au cours : Sécurité sur les appareils mobiles

Équipe de réalisation : Projet réalisé par une équipe de 4 membres.

Au cours de la recherche et de la finalisation du projet de conception de ce serveur C2, l'équipe a pris en charge les tâches suivantes :

• Construction du composant Backend en Python (framework Flask) pour fournir les API de communication, déchiffrer les données et les stocker.
• Développement de l'interface d'administration Frontend visuelle (Dashboard) en ReactJS pour surveiller les cibles.
• Conception du système de stockage sous forme de base de données à fichiers plats (flat-file database) data.json afin d'optimiser un PoC rapide et léger.
• Empaquetage de l'ensemble de l'architecture (Backend et Frontend) en conteneurs indépendants et exploitation via Docker.

Vue d'ensemble

Le système de serveur C2 applique le modèle Client-Serveur, dans lequel l'application Android malveillante (PoC) joue le rôle de Client qui envoie continuellement des données. L'architecture C2 est divisée en deux composants de traitement indépendants pour garantir une vitesse élevée et une grande flexibilité.

Flux de fonctionnement principal du serveur C2 :

1. Camouflage et réception (Backend) : Le point de réception racine / est conçu avec un mécanisme de traitement double. S'il est accédé par la méthode GET (scan de navigateur), le serveur renvoie une fausse erreur 404 pour se dissimuler. S'il reçoit une méthode POST contenant un format JSON provenant du code malveillant, le serveur accepte et extrait l'identifiant de l'appareil.
2. Classification intelligente (Smart Classification) : Le serveur vérifie automatiquement les mots-clés (keys) à l'intérieur du paquet pour attribuer des étiquettes de données (par exemple : s_cache, gps_cache).
3. Stockage et empaquetage : Le payload d'origine est empaqueté avec l'horodatage réel et l'ID de l'appareil, puis poussé en tête de la liste de stockage dans data.json.
4. Synchronisation Frontend : Le Dashboard utilise un React Hook pour envoyer des requêtes GET vers /api/data afin de lire la base de données.
5. Regroupement et affichage : Le Frontend regroupe automatiquement les paquets partageant le même identifiant (device_id), scanne en profondeur la structure pour extraire les paramètres matériels (RAM, Batterie, OS) et les affiche visuellement sur le radar.

Informations sur la CVE

Code de la vulnérabilité : CVE-2024-23700
Niveau de gravité Android : Critique
Composant concerné : Android Companion Device Manager
Correctif de référence : Android Wear Security Bulletin 2024-05-01

Ce serveur C2 est conçu comme partie d'un réseau expérimental, recevant le flux de données de renseignement provenant des appareils Android ayant été exploités avec succès via la vulnérabilité ci-dessus.

Structure des répertoires

CVE-2024-23700-C2-Server/
├── backend/
│   ├── app.py - Initialisation des Endpoints API, traitement du camouflage et classification JSON
│   └── requirements.txt
├── frontend/
│   ├── src/
│   │   ├── pages/
│   │   │   ├── Dashboard.jsx - Écran radar de vue d'ensemble des appareils
│   │   │   └── DeviceDetails.jsx - Boîte de dialogue d'analyse approfondie des payloads
│   │   ├── App.jsx
│   │   └── App.css
│   ├── package.json
│   └── nginx.conf - Personnalisation du Reverse Proxy pour le frontend
├── data.json - Base de données à fichiers plats stockant les enregistrements (montée en volume)
├── docker-compose.yml - Gestion des conteneurs et du réseau interne
├── .gitignore
└── README.md

Composants principaux

Mécanisme de classification et d'interprétation des données

Plutôt que d'utiliser une logique alambiquée, le serveur identifie et étiquette automatiquement en fonction des blocs de données (cache) renvoyés, tandis que l'interface Frontend intègre un dictionnaire intelligent (MODULE_MAP et COLUMN_TRANSLATIONS) pour normaliser et « franciser » les résultats :

• SMS_INTERCEPT : Données dérobées depuis les messages SMS (s_cache).
• CONTACTS_DUMP : Données extraites du répertoire de contacts (c_cache).
• CALENDAR_SPY : Données de surveillance des événements d'agenda (cal_cache).
• NOTIFICATIONS_SPY : Données d'écoute des notifications (n_cache).
• LOCATION_TRACKING : Données de suivi de localisation (gps_cache).
• GENERAL_TELEMETRY : Étiquette par défaut pour les données de mesure système générales.

En outre, le système convertit automatiquement l'horodatage brut en heure locale lisible et interprète les codes numériques en états réels (ex. : Type d'appel 1 = « ↙️ Appel entrant »).

Déploiement et exploitation

L'ensemble de l'infrastructure C2 est exploitée via docker compose pour garantir la cohérence et éliminer les écarts d'environnement. La structure exécute 2 services principaux :

• c2_backend (Port 5000) : Applique la technique de Volume Mapping pour monter le fichier physique data.json dans la zone mémoire /app/data.json à l'intérieur du conteneur. Cela permet aux données de renseignement d'être conservées en permanence même si le conteneur est supprimé ou redémarré. Le service applique la politique restart: always.
• c2_frontend (Port 80) : S'exécute sur le serveur web Nginx, jouant le rôle de Reverse Proxy. Toute requête API avec le préfixe /api/ est automatiquement transférée (proxy_pass) au Backend pour renforcer la sécurité. Ce conteneur doit démarrer après le Backend (depends_on) pour éviter les erreurs de perte de connexion initiale.

Notes

• Il faut s'assurer que le fichier data.json dispose des droits de lecture/écriture appropriés sur le serveur physique avant de lancer Docker.
• Si le fichier de données n'a pas encore été créé, le Backend renverra automatiquement un tableau vide pour ne pas faire planter l'interface.
• Accéder directement à l'adresse IP du serveur déclenchera le mécanisme de camouflage d'erreur HTTP 404. L'administrateur doit accéder au chemin et au port correctement configurés sur Nginx.