Wprowadzenie do problemu / definicja
Belgijski ekosystem elektronicznej tożsamości eID znalazł się pod lupą po ujawnieniu poważnych podatności w rozwiązaniu Connective Signing, wykorzystywanym do uwierzytelniania obywateli w usługach publicznych i finansowych. Problem nie dotyczył samej koncepcji silnego uwierzytelniania opartego na karcie identyfikacyjnej, lecz komponentów pośredniczących: rozszerzenia przeglądarkowego oraz natywnej aplikacji działającej na komputerze użytkownika.
To właśnie ta warstwa integracyjna okazała się najsłabszym ogniwem całego łańcucha zaufania. W efekcie potencjalny atakujący mógł wykorzystać błędy do przejęcia sesji uwierzytelnienia, wyłudzenia kodu PIN, nadużycia podpisu elektronicznego, a nawet uruchomienia własnego kodu na urządzeniu ofiary.
W skrócie
Badacz bezpieczeństwa ujawnił zestaw krytycznych luk w Connective Signing, rozwiązaniu szeroko stosowanym w belgijskim modelu logowania eID. Błędy miały umożliwiać podszywanie się pod zaufane serwisy, odczyt danych z karty, pozyskanie PIN-u oraz przejęcie kontroli nad procesem podpisu elektronicznego.
Najpoważniejszy scenariusz obejmował zdalne wykonanie kodu na stacji roboczej użytkownika poprzez nadużycie natywnego hosta. Według publicznie przekazanych informacji poprawki wdrożono 22 lipca 2026 roku, a producent wskazał, że nie zaobserwowano oznak aktywnego wykorzystania tych podatności w środowisku produkcyjnym.
Kontekst / historia
Belgijski model eID opiera się na kilku współpracujących ze sobą elementach: fizycznej karcie tożsamości, czytniku kart, lokalnym oprogramowaniu oraz rozszerzeniu przeglądarkowym, które pośredniczy między stroną internetową a komponentem systemowym. Taki mechanizm ma zwiększać poziom bezpieczeństwa, ponieważ poza dostępem do usługi wymaga również fizycznego dokumentu i znajomości przypisanego do niego kodu PIN.
Jak pokazuje ten przypadek, bezpieczeństwo całej architektury zależy nie tylko od kryptografii czy samego dokumentu tożsamości, lecz również od jakości implementacji warstwy integracyjnej. Rozwiązanie Connective było szeroko wykorzystywane zarówno przez podmioty publiczne, jak i sektor finansowy, dlatego skala potencjalnych konsekwencji była szczególnie duża.
Ujawnienie podatności nastąpiło publicznie podczas konferencji DEF CON 34 w sierpniu 2026 roku, choć same błędy zostały załatane wcześniej. To oznacza, że incydent stał się ważnym przykładem zagrożeń związanych z rozszerzeniami przeglądarkowymi i mechanizmami native messaging w systemach tożsamości cyfrowej.
Analiza techniczna
Kluczowy problem dotyczył modelu zaufania między witryną internetową, rozszerzeniem przeglądarkowym i natywnym hostem. Z opisu badania wynika, że rozszerzenie nie wiązało operacji w sposób jednoznaczny z konkretną domeną. Zamiast tego wykorzystywano ogólny token aktywacyjny, który mógł zostać pozyskany z legalnego serwisu i użyty ponownie w kontekście strony kontrolowanej przez atakującego.
W praktyce otwierało to drogę do stworzenia fałszywej witryny, która zachowywałaby się jak zaufany portal i uzyskiwała dostęp do funkcji logiki aplikacji Connective. Taki scenariusz umożliwiał ingerencję w proces uwierzytelnienia eID nawet wtedy, gdy użytkownik nie znajdował się na autoryzowanej stronie docelowej.
Kolejna istotna podatność dotyczyła obsługi kodu PIN. Choć PIN miał być przesyłany w formie zaszyfrowanej, równolegle dostępne były dane pozwalające na jego odszyfrowanie. Dodatkowo treść okna dialogowego do wprowadzania PIN-u była definiowana przez stronę internetową, a nie przez zaufany komponent lokalny, co tworzyło bardzo dobre warunki do phishingu wewnątrz samego procesu logowania.
Badacz wskazał również na możliwość przejęcia podpisu elektronicznego użytkownika. W określonym scenariuszu napastnik mógł pozyskać ważny podpis i wykorzystać go do obejścia zabezpieczeń w innych usługach, zwłaszcza tam, gdzie pojedynczy podpis stanowi podstawę do potwierdzenia tożsamości, rejestracji lub odzyskania dostępu.
Najbardziej krytyczne technicznie ustalenie dotyczyło jednak natywnej aplikacji hosta. Według ujawnionych informacji dowolna strona internetowa mogła nakazać programowi załadowanie arbitralnej biblioteki DLL z systemu ofiary. Jeśli napastnik wcześniej doprowadziłby do pobrania spreparowanego pliku DLL, lokalny komponent mógłby go uruchomić, co prowadziłoby bezpośrednio do zdalnego wykonania kodu i pełnego przejęcia stacji roboczej.
Konsekwencje / ryzyko
Skutki tych podatności wykraczają daleko poza pojedynczy błąd w dodatku przeglądarkowym. Mowa o naruszeniu zaufania do systemu elektronicznej tożsamości używanego w kontaktach z administracją i instytucjami finansowymi. Potencjalny atak mógł prowadzić do kradzieży tożsamości, przejęcia procesu logowania, nadużycia podpisu elektronicznego oraz kompromitacji samego urządzenia użytkownika.
Z perspektywy obywatela ryzyko obejmuje nieautoryzowany dostęp do kont administracyjnych, danych osobowych i usług bankowych. Dla organizacji oraz operatorów usług oznacza to z kolei zagrożenie oszustwami finansowymi, obejściem procedur uwierzytelniania, stratami reputacyjnymi oraz możliwymi konsekwencjami regulacyjnymi.
Incydent pokazuje także szerszy problem architektoniczny. Rozszerzenia przeglądarkowe i mechanizmy komunikacji z aplikacjami natywnymi są wyjątkowo wrażliwym punktem całego ekosystemu bezpieczeństwa. Jeśli walidacja źródła, kontekstu sesji i komunikatów jest niewystarczająca, pojedyncza luka może doprowadzić do eskalacji od phishingu po pełną kompromitację hosta.
Rekomendacje
Organizacje korzystające z podobnych rozwiązań powinny w pierwszej kolejności zweryfikować, czy wszystkie stacje robocze i profile użytkowników działają na aktualnych wersjach rozszerzenia oraz natywnego hosta. Aktualizacja oprogramowania powinna być jednak tylko początkiem działań ograniczających ryzyko.
- Wdrożyć ścisły whitelisting witryn, na których rozszerzenie może działać.
- Powiązać operacje uwierzytelniające i kryptograficzne z jednoznacznie zweryfikowaną domeną oraz kontekstem sesji.
- Uniemożliwić ponowne użycie tokenów aktywacyjnych między różnymi serwisami.
- Renderować okna PIN-u, zgody i podpisu wyłącznie przez zaufany komponent lokalny.
- Monitorować ładowanie nietypowych bibliotek DLL przez procesy hosta.
- Wzmocnić polityki EDR pod kątem nadużyć przeglądarek, rozszerzeń i komponentów podpisujących.
- Regularnie testować bezpieczeństwo całego łańcucha eID, a nie tylko backendu usług.
Po stronie producentów kluczowe jest pełne egzekwowanie zasady najmniejszego zaufania. Każde żądanie pochodzące z przeglądarki powinno być walidowane pod kątem źródła, integralności oraz zgodności z autoryzowanym scenariuszem użycia. Równie ważne jest odseparowanie interfejsu kontrolowanego przez stronę internetową od komunikatów prezentowanych przez zaufane oprogramowanie lokalne.
Podsumowanie
Przypadek belgijskiego eID pokazuje, że nawet silne metody uwierzytelniania mogą zostać podważone przez błędy w warstwie integracyjnej. W tym incydencie podatności w Connective Signing stworzyły możliwość przejęcia tożsamości, nadużycia podpisu elektronicznego oraz osiągnięcia zdalnego wykonania kodu na urządzeniu użytkownika.
To ważna lekcja dla wszystkich organizacji budujących procesy IAM na dodatkach przeglądarkowych i komponentach lokalnych. Zaufanie nie może być zakładane domyślnie — musi być konsekwentnie wymuszane i technicznie weryfikowane na każdym etapie łańcucha uwierzytelniania.