Bezpieczeństwo Telega: Luki, licencje, MitM i certyfikat Mincifry

Klient Telegram „Telega” pod lupą: Krytyczna analiza bezpieczeństwa, naruszenia licencji i ukryte zagrożenia MitM

„Telega”, pozycjonowany jako „młodzieżowy” klient Telegrama, reklamowany jako otwarty i omijający blokady, po szczegółowej analizie inżynierii wstecznej ujawnił krytyczne luki bezpieczeństwa, poważne naruszenia licencji GPL v2 oraz potencjalne mechanizmy nieautoryzowanego przechwytywania ruchu. Kluczowym odkryciem była integracja certyfikatu głównego rosyjskiego Ministerstwa Rozwoju Cyfrowego (Mincifry RF), co w połączeniu z wyłączonymi weryfikacjami certyfikatów stwarza warunki do pełnoprawnych ataków typu MitM (Man-in-the-Middle). Stanowi to poważne ryzyko dla poufności i integralności danych użytkowników.

Deklarowana otwartość kontra ukryte ryzyka

Twórcy klienta „Telega” aktywnie promują go jako rozwiązanie Open Source, zdolne do omijania blokad i zapewniające stabilne działanie. Jednak próby uzyskania dostępu do kodu źródłowego, deklarowanego jako otwarty, napotkały przeszkody: na oficjalnej stronie brak jest linków do repozytoriów, a zapytania do wsparcia technicznego i na czatach są usuwane lub ignorowane. Już to podważa szczerość deklaracji o otwartości.

Dalsza analiza umowy licencyjnej użytkownika końcowego (EULA) ujawniła bezpośrednie sprzeczności z zasadami wolnego oprogramowania. W szczególności EULA zastrzega „wyłączne prawo do Komunikatora” dla licencjodawcy, mimo że klient, jak się okazało, jest forkiem Telegram for Android, rozpowszechnianego na licencji GPL v2. Oznacza to, że twórcy „Telegi” są zobowiązani do udostępnienia kodu źródłowego i nie mają prawa ograniczać jego kopiowania ani rozpowszechniania. Zamiast tego, EULA zawiera punkty wyraźnie zabraniające „sprzedawania, powielania, kopiowania Komunikatora”, co stanowi rażące naruszenie GPL v2. Co więcej, jako odniesienie do „otwartego kodu źródłowego” podana jest licencja TDLib (Boost Software License 1.0), która reguluje jedynie jedną z używanych bibliotek, a nie głównego klienta. Odkryto również punkty pozwalające na jednostronną modyfikację funkcjonalności bez powiadomienia oraz przymusowe subskrybowanie kanałów przez użytkowników, a odpowiedzialność twórców jest ograniczona do symbolicznej kwoty 500 rubli.

Luki techniczne i błędy architektoniczne

Inżynieria wsteczna pliku APK „Telegi” ujawniła szereg niepokojących rozwiązań technicznych. Na przykład, połączenia użytkowników są kierowane przez serwery rosyjskiego portalu społecznościowego „Odnoklassniki” (calls.okcdn.ru), co budzi pytania o poufność ruchu i zasadność takiego wyboru dla „młodzieżowego” klienta. Kolejną cechą jest zarządzanie Perfect Forward Secrecy (PFS) z poziomu serwera. Oznacza to, że właściciel serwera potencjalnie może wyłączyć PFS, co obniża poziom bezpieczeństwa poprzednich sesji w przypadku kompromitacji długoterminowych kluczy.

Mechanizm omijania blokad, deklarowany jako jedna z kluczowych zalet, również został zaimplementowany z krytycznymi niedociągnięciami. Klient żąda aktualnych adresów centrów danych (DC) poprzez zapytanie HTTP do https://api.telega.info/v1/dc-proxy. Jednak w kodzie brakuje mechanizmów weryfikacji podpisu odpowiedzi z tego serwera, a także wyciszono TrustManagera, co oznacza całkowity brak weryfikacji certyfikatów.

// Przykład kodu demonstrującego brak weryfikacji certyfikatu
// (TrustManager wyciszony)
public class InsecureTrustManager implements X509TrustManager {
    @Override
    public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException {
        // Zawsze ufamy, bez weryfikacji
    }

    @Override
    public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException {
        // Zawsze ufamy, bez weryfikacji
    }

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

Pozwala to atakującemu, który przeprowadził atak „człowiek pośrodku” (MitM) na drodze do api.telega.info, podmienić odpowiedź i przekierować cały ruch użytkownika na swój kontrolowany serwer. W standardowej architekturze Telegrama proxy (MTProto Proxy) nie ma dostępu do kluczy szyfrujących i nie może widzieć treści wiadomości, podczas gdy architektura „Telegi” potencjalnie pozwala na skierowanie ruchu w dowolne miejsce, czyniąc go podatnym na ataki.

Krytyczne zagrożenie: Certyfikat Mincifry i ataki MitM

Najbardziej niepokojącym odkryciem było znalezienie w zasobach pliku APK „Telegi” certyfikatu głównego resources/res/raw/rootca_ssl_rsa2022.cer. Nie jest to nic innego jak certyfikat główny Russian Trusted Root CA, wydany przez rosyjskie Ministerstwo Rozwoju Cyfrowego (Mincifry RF). Wdrożenie państwowego certyfikatu głównego do aplikacji klienckiej samo w sobie jest nietypową i potencjalnie niebezpieczną praktyką. W połączeniu z już wspomnianym brakiem weryfikacji certyfikatów (TrustManager wyciszony) oraz usunięciem mechanizmu Certificate Pinning, który jest obecny w oryginalnym kliencie Telegrama, stwarza to idealne warunki do pełnoprawnego ataku MitM.

Certificate Pinning to mechanizm, który pozwala aplikacji „przypiąć” oczekiwane certyfikaty dla określonych domen, odrzucając wszelkie inne, nawet jeśli są podpisane przez zaufany urząd certyfikacji. Jego brak w „Teledze” w połączeniu z zaufaniem do certyfikatu głównego Mincifry oznacza, że każdy, kto posiada klucz prywatny tego certyfikatu (np. organy państwowe lub atakujący, którzy go uzyskali), może przechwytywać i deszyfrować cały ruch użytkowników „Telegi” w czasie rzeczywistym. Stanowi to bezpośrednie zagrożenie dla poufności i bezpieczeństwa komunikacji, przekształcając klienta z „narzędzia do omijania blokad” w potencjalne narzędzie do inwigilacji.

Wyciek danych i niekompletne kody źródłowe

Analiza aktywności sieciowej wykazała, że klient „Telega” wysyła na swoje serwery (telega.info) następujące dane:

phone (numer telefonu)
ip (adres IP)
deviceModel (model urządzenia)
systemVersion (wersja systemu operacyjnego)
authKeyId (identyfikator klucza autoryzacji Telegrama)

Przesyłanie authKeyId na zewnętrzne serwery jest szczególnie wrażliwą informacją, ponieważ jest bezpośrednio związane z autoryzacją użytkownika w sieci Telegram i może być wykorzystane do identyfikacji. Deklarowana otwartość kodu źródłowego okazała się fikcją nie tylko z powodu jego początkowej niedostępności, ale także dlatego, że później znalezione na GitHubie repozytoria okazały się niekompletne i nie zawierały całego kodu obecnego w pliku APK. To jeszcze bardziej podważa zaufanie do twórców i ich deklaracji dotyczących bezpieczeństwa.

Główne wnioski z analizy klienta Telegram „Telega”:

Naruszenie licencji GPL v2: Klient, oparty na kodzie Telegram for Android, nie przestrzega warunków otwartej licencji, zabraniając kopiowania i nie udostępniając kodu źródłowego.
Niebezpieczne routowanie połączeń: Wykorzystanie serwerów „Odnoklassniki” do połączeń głosowych budzi pytania o poufność.
Podatny mechanizm proxy: Brak weryfikacji podpisu i certyfikatów podczas żądania nowych DC otwiera drogę do ataków MitM.
Integracja certyfikatu głównego Mincifry: Wbudowany w aplikację Russian Trusted Root CA w połączeniu z wyłączonym Certificate Pinning pozwala na przechwytywanie i deszyfrowanie ruchu.
Masowy wyciek danych: Przesyłanie numeru telefonu, adresu IP, danych urządzenia i authKeyId na zewnętrzne serwery telega.info bez adekwatnych gwarancji bezpieczeństwa.
Fikcyjna otwartość: Deklaracje o Open Source nie są potwierdzone dostępnością pełnego i aktualnego kodu źródłowego.

Co ważne:

Klient „Telega” zawiera poważne luki, które mogą zagrozić poufności i bezpieczeństwu danych użytkowników.
Integracja certyfikatu głównego Mincifry i wyłączenie podstawowych kontroli bezpieczeństwa stwarzają warunki do państwowego lub innego kontrolowanego przechwytywania ruchu.
Korzystanie z tego klienta wiąże się ze znacznym ryzykiem dla użytkowników, zwłaszcza biorąc pod uwagę przesyłanie krytycznych identyfikatorów na zewnętrzne serwery.
Deklaracje o Open Source okazały się fałszywe, co podważa zaufanie do projektu i jego twórców.
Twórcy powinni ściśle przestrzegać warunków GPL v2 i wdrożyć standardowe praktyki bezpieczeństwa, w tym Certificate Pinning oraz rygorystyczną weryfikację certyfikatów.

— Editorial Team