Analyse de sécurité Telega : GPL v2, MitM, certificat russe

Analyse de sécurité critique du client Telegram 'Telega' : Violations de licence et menaces cachées d'attaques MitM

'Telega', présenté comme un client Telegram 'orienté jeunesse' vantant son ouverture et ses capacités de contournement de la censure, a révélé, suite à une analyse approfondie par rétro-ingénierie, des vulnérabilités de sécurité critiques, de graves violations de la licence GPL v2 et des mécanismes potentiels d'interception de trafic non autorisée. Une découverte clé a été l'intégration du certificat racine du Ministère du Développement Numérique de Russie, qui, combinée à une validation de certificat désactivée, crée les conditions idéales pour des attaques de type 'Man-in-the-Middle' (MitM) à grande échelle. Cela pose des risques importants pour la confidentialité et l'intégrité des données des utilisateurs.

Ouverture revendiquée contre risques cachés

Les développeurs du client 'Telega' le promeuvent activement comme une solution Open Source capable de contourner les blocages et d'assurer un fonctionnement stable. Cependant, les tentatives d'accès au code source, prétendument ouvert, se sont heurtées à des obstacles : le site officiel ne contient aucun lien vers les dépôts, et les demandes de support ou les messages de chat sont soit supprimés, soit ignorés. Cela seul jette un doute sur la sincérité de leurs affirmations d'ouverture.

Une analyse plus poussée du Contrat de Licence Utilisateur Final (CLUF) a révélé des contradictions directes avec les principes du logiciel libre. Plus précisément, le CLUF affirme des 'droits exclusifs sur le Messager' pour le concédant, alors même que le client, comme découvert, est un fork de Telegram pour Android, distribué sous la licence GPL v2. Cela signifie que les développeurs de 'Telega' sont tenus de fournir le code source et n'ont pas le droit d'en restreindre la copie ou la distribution. Au lieu de cela, le CLUF contient des clauses interdisant explicitement de 'vendre, reproduire, copier le Messager', ce qui constitue une violation flagrante de la GPL v2. De plus, la Boost Software License 1.0 pour TDLib est citée comme référence pour le 'code source ouvert', alors qu'elle ne régit qu'une des bibliothèques utilisées, et non le client principal. Des clauses ont également été trouvées permettant la modification unilatérale des fonctionnalités sans préavis et l'abonnement forcé des utilisateurs à des chaînes, tandis que la responsabilité du développeur est limitée à une somme symbolique de 500 roubles (environ 5-6 USD).

Vulnérabilités techniques et défauts architecturaux

La rétro-ingénierie du fichier APK de 'Telega' a révélé plusieurs décisions techniques préoccupantes. Par exemple, les appels des utilisateurs sont acheminés via les serveurs du réseau social russe 'Odnoklassniki' (calls.okcdn.ru), ce qui soulève des questions sur la confidentialité du trafic et la pertinence d'un tel choix pour un client 'orienté jeunesse'. Une autre particularité est que la gestion de la Perfect Forward Secrecy (PFS) est gérée côté serveur. Cela signifie que le propriétaire du serveur pourrait potentiellement désactiver la PFS, réduisant ainsi le niveau de sécurité des sessions passées si des clés à long terme sont compromises.

Le mécanisme de contournement de la censure, présenté comme l'un de ses principaux avantages, est également mis en œuvre avec des failles critiques. Le client demande les adresses des centres de données (DC) actuels via une requête HTTP à https://api.telega.info/v1/dc-proxy. Cependant, le code ne dispose pas de mécanismes pour vérifier la signature de la réponse de ce serveur, et le TrustManager est désactivé (simulé), ce qui signifie une absence totale de validation de certificat.

// Exemple de code démontrant l'absence de validation de certificat
// (TrustManager est simulé)
public class InsecureTrustManager implements X509TrustManager {
    @Override
    public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException {
        // Toujours faire confiance, sans validation
    }

    @Override
    public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException {
        // Toujours faire confiance, sans validation
    }

    @Override
    public X509Certificate[] getAcceptedIssuers() {
        return new X509Certificate[0];
    }
}

Cela permet à un attaquant effectuant une attaque de type 'Man-in-the-Middle' (MitM) sur le chemin vers api.telega.info de falsifier la réponse et de rediriger tout le trafic utilisateur vers son serveur contrôlé. Dans l'architecture standard de Telegram, un proxy (MTProto Proxy) n'a pas accès aux clés de chiffrement et ne peut pas voir le contenu des messages, tandis que l'architecture de 'Telega' permet potentiellement de router le trafic n'importe où, le rendant vulnérable.

Menace critique : Certificat du Ministère du Développement Numérique et attaques MitM

La découverte la plus alarmante a été la présence du certificat racine resources/res/raw/rootca_ssl_rsa2022.cer dans les ressources du fichier APK de 'Telega'. Il s'agit ni plus ni moins du certificat racine de l'Autorité de Certification Russe de Confiance (Russian Trusted Root CA), émis par le Ministère du Développement Numérique de Russie. L'inclusion d'un certificat racine émis par l'État dans une application cliente est, en soi, une pratique inhabituelle et potentiellement dangereuse. Combinée à l'absence susmentionnée de validation de certificat (le TrustManager est désactivé) et à la suppression du mécanisme de 'Certificate Pinning', présent dans le client Telegram original, cela crée des conditions idéales pour une attaque MitM à grande échelle.

Le 'Certificate Pinning' est un mécanisme qui permet à une application d'épingler les certificats attendus pour des domaines spécifiques, rejetant tout autre certificat, même s'il est signé par une autorité racine de confiance. Son absence dans 'Telega', combinée à la confiance accordée au certificat racine du Ministère du Développement Numérique, signifie que toute personne possédant la clé privée de ce certificat (par exemple, les autorités étatiques ou des attaquants l'ayant obtenue) peut intercepter et déchiffrer tout le trafic des utilisateurs de 'Telega' en temps réel. Cela représente une menace directe pour la confidentialité et la sécurité des communications, transformant le client d'un 'outil de contournement de blocage' en un potentiel instrument de surveillance.

Fuite de données et code source incomplet

L'analyse de l'activité réseau a révélé que le client 'Telega' envoie les données suivantes à ses serveurs (telega.info) :

phone (numéro de téléphone)
ip (adresse IP)
deviceModel (modèle de l'appareil)
systemVersion (version du système d'exploitation)
authKeyId (identifiant de la clé d'autorisation Telegram)

La transmission de l'authKeyId à des serveurs tiers est une information particulièrement sensible, car elle est directement liée à l'autorisation de l'utilisateur au sein du réseau Telegram et peut être utilisée pour l'identification. La nature prétendument open source s'est également avérée être une façade, non seulement en raison de son indisponibilité initiale, mais aussi parce que les dépôts trouvés plus tard sur GitHub étaient incomplets et ne contenaient pas tout le code présent dans le fichier APK. Cela érode davantage la confiance envers les développeurs et leurs affirmations en matière de sécurité.

Principales conclusions de l'analyse du client Telegram 'Telega' :

Violation de la licence GPL v2 : Le client, basé sur le code de Telegram pour Android, ne respecte pas les termes de la licence open source en interdisant la copie et en ne fournissant pas le code source.
Routage d'appels non sécurisé : L'utilisation des serveurs d'Odnoklassniki pour les appels vocaux soulève des préoccupations en matière de confidentialité.
Mécanisme de proxy vulnérable : L'absence de validation de signature et de certificat lors de la demande de nouveaux DC ouvre la porte aux attaques MitM.
Intégration du certificat racine du Ministère du Développement Numérique : Le certificat racine de l'Autorité de Certification Russe de Confiance (Russian Trusted Root CA) intégré dans l'application, combiné à la désactivation du 'Certificate Pinning', permet l'interception et le déchiffrement du trafic.
Fuite de données étendue : Envoi de numéros de téléphone, d'adresses IP, de données d'appareil et de l'authKeyId à des serveurs tiers telega.info sans garanties de sécurité adéquates.
Ouverture fictive : Les affirmations d'Open Source se sont avérées fausses, sapant la confiance dans le projet et ses développeurs.

Ce qu'il faut retenir :

Le client 'Telega' contient de graves vulnérabilités qui peuvent compromettre la confidentialité et la sécurité des données des utilisateurs.
L'intégration du certificat racine du Ministère du Développement Numérique et la désactivation des contrôles de sécurité de base créent les conditions pour une interception du trafic parrainée par l'État ou d'autres entités contrôlées.
L'utilisation de ce client comporte des risques importants pour les utilisateurs, notamment en raison de la transmission d'identifiants critiques à des serveurs tiers.
Les affirmations d'Open Source se sont avérées fausses, sapant la confiance dans le projet et ses développeurs.
Les développeurs devraient adhérer strictement aux termes de la GPL v2 et mettre en œuvre des pratiques de sécurité standard, y compris le 'Certificate Pinning' et une validation rigoureuse des certificats.

— Editorial Team