Telega Client: Sicherheitsanalyse, GPL-Verstöße & MitM-Risiken

Kritische Sicherheitsanalyse des Telegram-Clients 'Telega': Lizenzverstöße und versteckte MitM-Angriffsgefahren

'Telega', als 'jugendorientierter' Telegram-Client mit angeblicher Offenheit und Zensurumgehungsfunktionen vermarktet, deckte bei einer detaillierten Reverse-Engineering-Analyse kritische Sicherheitslücken, schwerwiegende GPL v2-Lizenzverstöße und potenzielle Mechanismen zur unerlaubten Datenverkehrsabfangung auf. Eine Schlüsselerkenntnis war die Integration des Root-Zertifikats des russischen Ministeriums für digitale Entwicklung, das in Kombination mit deaktivierter Zertifikatsvalidierung Bedingungen für vollwertige Man-in-the-Middle (MitM)-Angriffe schafft. Dies birgt erhebliche Risiken für die Vertraulichkeit und Integrität der Nutzerdaten.

Behauptete Offenheit vs. Verborgene Risiken

Die Entwickler des 'Telega'-Clients bewerben ihn aktiv als Open-Source-Lösung, die Blockaden umgehen und einen stabilen Betrieb gewährleisten kann. Versuche, auf den angeblich offenen Quellcode zuzugreifen, stießen jedoch auf Hindernisse: Auf der offiziellen Website fehlen Links zu Repositories, und Supportanfragen sowie Chat-Nachrichten werden entweder gelöscht oder ignoriert. Dies allein wirft Zweifel an der Aufrichtigkeit ihrer Behauptungen über Offenheit auf.

Eine weitere Analyse des Endbenutzer-Lizenzvertrags (EULA) zeigte direkte Widersprüche zu den Prinzipien freier Software auf. Insbesondere beansprucht die EULA 'exklusive Rechte am Messenger' für den Lizenzgeber, obwohl der Client, wie entdeckt, ein Fork von Telegram für Android ist, der unter der GPL v2-Lizenz vertrieben wird. Dies bedeutet, dass die 'Telega'-Entwickler verpflichtet sind, den Quellcode bereitzustellen und kein Recht haben, dessen Kopieren oder Verbreitung einzuschränken. Stattdessen enthält die EULA Klauseln, die explizit 'den Verkauf, die Reproduktion, das Kopieren des Messengers' verbieten, was ein eklatanter Verstoß gegen GPL v2 ist. Des Weiteren wird die Boost Software License 1.0 für TDLib als Referenz für 'Open Source Code' zitiert, die jedoch nur eine der verwendeten Bibliotheken, nicht aber den Hauptclient, regelt. Es wurden auch Klauseln gefunden, die eine einseitige Änderung der Funktionalität ohne Vorankündigung und die erzwungene Abonnement von Nutzern für Kanäle erlauben, während die Haftung der Entwickler auf eine symbolische Summe von 500 Rubel (ca. 5-6 USD) begrenzt ist.

Technische Schwachstellen und Architekturmängel

Das Reverse-Engineering der 'Telega'-APK-Datei enthüllte mehrere besorgniserregende technische Entscheidungen. So werden beispielsweise Benutzeranrufe über die Server des russischen sozialen Netzwerks 'Odnoklassniki' (calls.okcdn.ru) geleitet, was Fragen zur Vertraulichkeit des Datenverkehrs und zur Angemessenheit einer solchen Wahl für einen 'jugendorientierten' Client aufwirft. Eine weitere Besonderheit ist, dass das Management von Perfect Forward Secrecy (PFS) serverseitig gehandhabt wird. Dies bedeutet, dass der Serverbetreiber PFS potenziell deaktivieren könnte, wodurch das Sicherheitsniveau vergangener Sitzungen reduziert würde, falls Langzeitschlüssel kompromittiert werden.

Der Zensurumgehungsmechanismus, der als einer seiner Hauptvorteile angepriesen wird, ist ebenfalls mit kritischen Mängeln implementiert. Der Client fordert aktuelle Rechenzentrums- (DC) Adressen über eine HTTP-Anfrage an https://api.telega.info/v1/dc-proxy an. Der Code verfügt jedoch über keine Mechanismen zur Überprüfung der Antwortsignatur dieses Servers, und der TrustManager ist deaktiviert (durch einen Stub ersetzt), was eine vollständige Abwesenheit der Zertifikatsvalidierung bedeutet.

// Example code demonstrating the lack of certificate validation
// (TrustManager is stubbed out)
public class InsecureTrustManager implements X509TrustManager {
    @Override
    public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException {
        // Always trust, without validation
    }

    @Override
    public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException {
        // Always trust, without validation
    }

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

Dies ermöglicht einem Angreifer, der einen Man-in-the-Middle (MitM)-Angriff auf dem Weg zu api.telega.info durchführt, die Antwort zu fälschen und den gesamten Benutzerdatenverkehr auf seinen kontrollierten Server umzuleiten. In der Standard-Telegram-Architektur hat ein Proxy (MTProto Proxy) keinen Zugriff auf Verschlüsselungsschlüssel und kann den Nachrichteninhalt nicht einsehen, während die Architektur von 'Telega' potenziell erlaubt, den Datenverkehr überallhin umzuleiten, was sie anfällig macht.

Kritische Bedrohung: Zertifikat des Ministeriums für digitale Entwicklung und MitM-Angriffe

Die alarmierendste Entdeckung war das Vorhandensein des Root-Zertifikats resources/res/raw/rootca_ssl_rsa2022.cer in den Ressourcen der 'Telega'-APK-Datei. Dabei handelt es sich um das russische Trusted Root CA-Zertifikat, ausgestellt vom russischen Ministerium für digitale Entwicklung. Die Aufnahme eines staatlich ausgestellten Root-Zertifikats in eine Client-Anwendung ist an sich schon eine ungewöhnliche und potenziell gefährliche Praxis. In Kombination mit der bereits erwähnten fehlenden Zertifikatsvalidierung (der TrustManager ist deaktiviert) und der Entfernung des Certificate Pinning-Mechanismus, der im ursprünglichen Telegram-Client vorhanden ist, schafft dies ideale Bedingungen für einen vollwertigen MitM-Angriff.

Certificate Pinning ist ein Mechanismus, der es einer Anwendung ermöglicht, erwartete Zertifikate für bestimmte Domains 'anzuheften' und alle anderen abzulehnen, selbst wenn sie von einer vertrauenswürdigen Root-Autorität signiert sind. Seine Abwesenheit in 'Telega', kombiniert mit dem Vertrauen in das Root-Zertifikat des Ministeriums für digitale Entwicklung, bedeutet, dass jeder, der den privaten Schlüssel für dieses Zertifikat besitzt (z.B. staatliche Behörden oder Angreifer, die ihn erlangt haben), den gesamten 'Telega'-Benutzerdatenverkehr in Echtzeit abfangen und entschlüsseln kann. Dies stellt eine direkte Bedrohung für die Vertraulichkeit und Sicherheit der Kommunikation dar und verwandelt den Client von einem 'Blockadeumgehungstool' in ein potenzielles Überwachungsinstrument.

Datenlecks und unvollständiger Quellcode

Die Analyse der Netzwerkaktivität ergab, dass der 'Telega'-Client die folgenden Daten an seine Server (telega.info) sendet:

phone (Telefonnummer)
ip (IP-Adresse)
deviceModel (Gerätemodell)
systemVersion (Betriebssystemversion)
authKeyId (Telegram-Autorisierungsschlüssel-Identifikator)

Die Übertragung von authKeyId an Drittanbieter-Server ist besonders sensible Information, da sie direkt mit der Benutzerautorisierung innerhalb des Telegram-Netzwerks verknüpft ist und zur Identifizierung verwendet werden kann. Die behauptete Open-Source-Natur erwies sich auch als Fassade, nicht nur aufgrund ihrer anfänglichen Nichtverfügbarkeit, sondern auch, weil später auf GitHub gefundene Repositories unvollständig waren und nicht den gesamten in der APK-Datei vorhandenen Code enthielten. Dies untergräbt das Vertrauen in die Entwickler und ihre Sicherheitsaussagen zusätzlich.

Wichtigste Erkenntnisse aus der Analyse des 'Telega' Telegram-Clients:

GPL v2 Lizenzverstoß: Der Client, basierend auf dem Telegram für Android-Code, verstößt gegen die Open-Source-Lizenzbedingungen, indem er das Kopieren verbietet und den Quellcode nicht bereitstellt.
Unsichere Anrufweiterleitung: Die Nutzung von Odnoklassniki-Servern für Sprachanrufe wirft Datenschutzbedenken auf.
Anfälliger Proxy-Mechanismus: Das Fehlen von Signatur- und Zertifikatsvalidierung bei der Anforderung neuer DCs öffnet die Tür für MitM-Angriffe.
Integration des Root-Zertifikats des Ministeriums für digitale Entwicklung: Die in der Anwendung eingebettete russische Trusted Root CA, kombiniert mit deaktiviertem Certificate Pinning, ermöglicht das Abfangen und Entschlüsseln von Datenverkehr.
Umfangreiche Datenlecks: Senden von Telefonnummern, IP-Adressen, Gerätedaten und authKeyId an Drittanbieter-Server von telega.info ohne ausreichende Sicherheitsgarantien.
Fiktive Offenheit: Behauptungen über Open Source erwiesen sich als falsch, was das Vertrauen in das Projekt und seine Entwickler untergräbt.

Was wichtig ist:

Der 'Telega'-Client enthält schwerwiegende Schwachstellen, die die Vertraulichkeit und Sicherheit von Benutzerdaten gefährden können.
Die Integration des Root-Zertifikats des Ministeriums für digitale Entwicklung und die Deaktivierung grundlegender Sicherheitsprüfungen schaffen Bedingungen für staatlich geförderte oder anderweitig kontrollierte Datenverkehrsabfangung.
Die Nutzung dieses Clients birgt erhebliche Risiken für Benutzer, insbesondere angesichts der Übertragung kritischer Identifikatoren an Drittanbieter-Server.
Behauptungen über Open Source erwiesen sich als falsch, was das Vertrauen in das Projekt und seine Entwickler untergräbt.
Entwickler sollten die GPL v2-Bedingungen strikt einhalten und Standard-Sicherheitspraktiken implementieren, einschließlich Certificate Pinning und rigoroser Zertifikatsvalidierung.

— Editorial Team