iTrue: 84 luki w rdzeniach 4G i 5G przez ukryte zaufanie

Zespół z Nanyang Technological University opisał 84 wcześniej nieznane podatności w otwartych implementacjach rdzeni LTE i 5G. Osiemdziesiąt trzy błędy zostały potwierdzone, a 81 otrzymało identyfikatory CVE. Najpoważniejszy wynik — przejęcie sesji użytkownika — badacze potwierdzili również w komercyjnych sieciach 5G.

Wspólna przyczyna nie jest pojedynczym błędem pamięci. To implicit trust error, nazwany iTrue: jedna funkcja rdzenia przyjmuje komunikat innego komponentu jako wiarygodny bez wystarczającej autoryzacji, powiązania ze stanem i walidacji kontekstu.

Zakres badania

Praca „Understanding Implicit Trust Errors in Core Carrier Networks” ma ukazać się na USENIX Security 2026. Badacze przeanalizowali siedem popularnych projektów:

• LTE: Open5GS i OpenAirInterface;
• 5G: Open5GS, free5GC, OpenAirInterface, SD-Core i eUPF.

Skupili się na dwóch protokołach sterujących:

• GTP-C, który w LTE obsługuje między innymi tworzenie, zmianę i usuwanie tuneli sesji;
• PFCP, którym w architekturze 5G płaszczyzna sterowania programuje płaszczyznę użytkownika.

Projekty open source są używane w laboratoriach, prywatnych sieciach i rozwiązaniach komercyjnych. Wynik nie oznacza jednak, że każda publiczna sieć operatora używa podatnej konfiguracji ani że 84 błędy są osiągalne z internetu.

Jak zmienił się model zaufania

Tradycyjny rdzeń telekomunikacyjny działał w silnie kontrolowanym środowisku. Komponenty były fizycznie i logicznie oddzielone od sieci publicznej, więc wiele implementacji zakładało, że komunikat przychodzący z wewnętrznego interfejsu pochodzi od właściwej funkcji.

Cloud-native 5G zmienia ten kontekst:

• funkcje są usługami i kontenerami;
• skaluje je orkiestrator;
• komunikują się przez sieć współdzieloną;
• mają dynamiczne adresy;
• integrują się z wieloma dostawcami;
• mogą działać w chmurze lub środowisku brzegowym.

Jeżeli dawny warunek „ten interfejs jest wewnętrzny” pozostaje jedynym zabezpieczeniem, przejęty mikroserwis, błąd segmentacji albo nieprawidłowo wystawiony port może otworzyć drogę do innych funkcji rdzenia.

Czym jest implicit trust error

iTrue powstaje, gdy odbiorca sprawdza poprawność składni komunikatu, ale nie weryfikuje wystarczająco:

• czy nadawca ma prawo zmieniać tę konkretną sesję;
• czy identyfikator należy do tego abonenta i tunelu;
• czy żądanie pasuje do aktualnego stanu;
• czy kolejność komunikatów jest możliwa;
• czy parametry powstały w uwierzytelnionym kontekście;
• czy wiadomość nie pochodzi z powtórzenia lub innej sesji.

To różnica między „pakiet jest zgodny z protokołem” a „ta funkcja może wykonać tę operację teraz”.

Od DoS do przejęcia sesji

Skutki opisane w pracy obejmują denial of service i session hijacking. DoS może zerwać sesję, wyczerpać stan albo zmusić komponent do kosztownego przetwarzania. Przejęcie sesji jest groźniejsze: napastnik może skierować ruch lub stan tunelu w sposób, który narusza izolację użytkownika.

Autorzy potwierdzili jeden błąd przejęcia sesji na komercyjnych rdzeniach 5G. Nie należy z tego wnioskować, że mogą przejmować sesje w dowolnej sieci. Warunki dostępu do interfejsu sygnalizacyjnego, topologia, implementacja i zabezpieczenia operatora mają kluczowe znaczenie.

iFinder i rola modeli językowych

Badacze zbudowali system iFinder. Najpierw analizował przepływy między funkcjami rdzenia i szukał miejsc, w których zaufanie nie jest jawnie weryfikowane. Następnie modele językowe generowały kandydatów testów, wykonywały je w kontrolowanych implementacjach i iteracyjnie poprawiały na podstawie wyniku.

To ważny przykład defensywnego użycia AI:

• model nie zastępował potwierdzenia;
• hipotezy były wykonywane w laboratorium;
• wynik wymagał odtworzenia;
• podatności zgłoszono projektom;
• liczby rozdzielają kandydatów, potwierdzenia i nadane CVE.

Automatyzacja zwiększyła pokrycie stanów protokołu, których ręczny audyt mógłby nie połączyć.

Kogo dotyczy ryzyko

Najwyższy priorytet mają:

• operatorzy używający wskazanych implementacji;
• dostawcy prywatnych sieci 4G/5G;
• uczelnie i laboratoria z publicznie osiągalnym core;
• integratorzy chmurowych funkcji sieciowych;
• organizacje przemysłowe budujące lokalne sieci 5G;
• dostawcy hostujący control plane i user plane w oddzielnych domenach.

Sama obecność Open5GS lub free5GC nie potwierdza ekspozycji. Potrzebne są dokładna wersja, konfiguracja, dostępność GTP-C/PFCP i mapa poprawek od maintainera.

Co zrobić teraz

1. zinwentaryzuj wszystkie funkcje rdzenia i ich wersje;
2. sprawdź advisory każdego projektu oraz przypisane CVE;
3. zmapuj, które podmioty mogą wysyłać GTP-C i PFCP;
4. usuń dostęp publiczny oraz zbędne trasy pomiędzy domenami;
5. uwierzytelniaj funkcje sieciowe wzajemnie;
6. stosuj polityki sieciowe do konkretnej roli i kierunku;
7. waliduj identyfikator sesji, abonenta, stan i kolejność;
8. alarmuj na nietypowe tworzenie, zmianę i usuwanie tuneli;
9. testuj błędne komunikaty w odizolowanym środowisku;
10. zachowuj ślady sterowania potrzebne do rekonstrukcji sesji.

Warto stosować zasadę zero trust również wewnątrz rdzenia: tożsamość usługi i kontekst operacji powinny być sprawdzane przy każdym żądaniu. Ogólny model opisujemy w przewodniku zero trust i mikrosegmentacja.

Fakty a wnioski Breachroad

Autorzy potwierdzają 84 odkrycia, 83 potwierdzone luki, 81 CVE i walidację jednego błędu przejęcia sesji w komercyjnych rdzeniach. Publikacja nie dokumentuje aktywnej kampanii wykorzystującej te błędy przeciw abonentom.

Wniosek Breachroad: migracja do cloud-native usuwa część fizycznych granic, na których opierały się stare założenia protokołów. Modernizacja rdzenia musi więc obejmować nie tylko kontenery i automatyzację, ale także jawne uwierzytelnianie funkcji, segmentację i walidację stanu.

Audyt bezpieczeństwa chmury i infrastruktury może zweryfikować architekturę prywatnej sieci, polityki komunikacji i telemetrię. Szkolenia dla zespołów technicznych pomagają przełożyć wyniki badań protokołów na konkretne priorytety aktualizacji i hardeningu.