Wprowadzenie do problemu / definicja
Krytyczna podatność wykryta w middleware SConnect pokazuje, że nawet środowiska korzystające ze sprzętowego MFA nie są automatycznie odporne na zdalne przejęcie. Problem dotyczy warstwy pośredniczącej między przeglądarką, lokalną aplikacją i tokenem uwierzytelniającym, co w praktyce może prowadzić do zdalnego wykonania kodu na stacji roboczej użytkownika.
To szczególnie niebezpieczny scenariusz w organizacjach, które wykorzystują SConnect do obsługi dostępu do systemów finansowych, usług tożsamości lub środowisk administracji publicznej. Naruszenie takiego komponentu może oznaczać nie tylko utratę bezpieczeństwa pojedynczego urządzenia, ale również zagrożenie dla całego procesu uwierzytelniania.
W skrócie
Badacze opisali krytyczną lukę oznaczoną jako CVE-2026-18397 w oprogramowaniu SConnect rozwijanym przez Thales. Podatność umożliwiała atak typu drive-by RCE po odwiedzeniu złośliwej strony internetowej lub osadzonego iframe, bez konieczności wykonywania przez ofiarę skomplikowanych działań.
- Luka dotyczy middleware używanego w sektorze bankowym, rządowym i w środowiskach powiązanych z dostępem do infrastruktury SWIFT.
- Atak wykorzystywał zbyt szeroki model zaufania w rozszerzeniu przeglądarkowym oraz błędy w walidacji podpisu RSA.
- Efektem mogło być zdalne wykonanie kodu na urządzeniu użytkownika.
- Choć produkt znajduje się w fazie końca życia, część organizacji mogła nadal utrzymywać go jako rozwiązanie podstawowe lub awaryjne.
Kontekst / historia
SConnect pełnił funkcję oprogramowania pośredniczącego dla uwierzytelniania opartego na tokenach sprzętowych. Tego typu rozwiązania są powszechnie stosowane tam, gdzie klasyczne logowanie i standardowe MFA nie zapewniają wystarczającego poziomu ochrony, zwłaszcza w bankowości, administracji oraz systemach o wysokiej wrażliwości operacyjnej.
W części środowisk oprogramowanie wspierało obsługę tokenów używanych przez pracowników o podwyższonych uprawnieniach, między innymi w scenariuszach związanych z infrastrukturą SWIFT. Nawet jeśli organizacje rozpoczęły migrację do nowszych platform, starszy komponent mógł nadal funkcjonować jako narzędzie zapasowe lub pozostałość po wcześniejszych wdrożeniach.
To typowy problem bezpieczeństwa w systemach krytycznych: formalne wycofanie produktu nie oznacza jego natychmiastowego zniknięcia z praktyki operacyjnej. Właśnie takie zalegające komponenty często stają się atrakcyjnym celem dla atakujących.
Analiza techniczna
Mechanizm działania SConnect opierał się na współpracy rozszerzenia przeglądarkowego z natywnym hostem uruchamianym lokalnie w systemie operacyjnym. Rozszerzenie przekazywało komunikaty z aplikacji webowej do lokalnego komponentu odpowiedzialnego za interakcję z tokenem i obsługę procesu zaufania.
Podstawowy problem polegał na tym, że rozszerzenie akceptowało komunikaty pochodzące z dowolnej strony internetowej lub osadzonego iframe, zamiast ograniczać je do jasno zdefiniowanych, zaufanych źródeł. W praktyce oznaczało to, że atakujący mógł uruchomić przepływ uwierzytelnienia z poziomu kontrolowanej przez siebie strony.
Drugi istotny element podatności dotyczył walidacji podpisu cyfrowego RSA. Z opisu wynika, że implementacja kontroli kryptograficznej została przygotowana w sposób własny i nie radziła sobie prawidłowo z sytuacjami granicznymi. Gdy dochodziło do błędu podczas obliczenia dla niepoprawnego podpisu, aplikacja nadal odczytywała bufor pamięci, który nie powinien być dalej wykorzystywany.
To otwierało drogę do manipulacji pamięcią procesu. Przy użyciu techniki heap spray możliwe było przygotowanie środowiska w taki sposób, aby odczytany bufor przypominał prawidłowy wynik walidacji podpisu. W efekcie złośliwa strona mogła zostać błędnie uznana za zaufaną, a kolejnym etapem było doprowadzenie do załadowania złośliwej biblioteki DLL przez natywny host.
Cały łańcuch ataku łączył więc kilka słabości jednocześnie:
- brak rygorystycznej walidacji źródła komunikatów,
- niebezpieczną własną implementację mechanizmów kryptograficznych,
- błędną obsługę pamięci,
- wysokie uprawnienia lokalnego komponentu dostępnego z poziomu przeglądarki.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem podatności jest kompromitacja stacji roboczej użytkownika posiadającego dostęp do systemów o wysokiej wartości. W sektorze bankowym może to oznaczać przejęcie sesji operatora, manipulację środowiskiem pracy, kradzież danych uwierzytelniających lub przygotowanie dalszego ruchu bocznego w sieci organizacji.
W przypadku administracji publicznej i usług tożsamości ryzyko obejmuje uzyskanie dostępu do szczególnie wrażliwych danych, przejęcie kontekstu zalogowanego użytkownika, a nawet nieautoryzowane wykonywanie działań w zaufanych systemach. Skala zagrożenia rośnie, jeśli urządzenie końcowe nie jest odpowiednio odseparowane od zwykłego dostępu do Internetu.
Istotne jest także to, że sprzętowy token MFA nie usuwał problemu. Jeżeli podatna była sama warstwa pośrednia łącząca przeglądarkę z tokenem, napastnik mógł ominąć część założeń bezpieczeństwa bez konieczności fizycznego przejęcia urządzenia uwierzytelniającego.
Rekomendacje
Organizacje powinny w pierwszej kolejności ustalić, czy SConnect nadal występuje w środowisku produkcyjnym, na stacjach administratorów, operatorów płatności, użytkowników SWIFT lub pracowników obsługujących usługi tożsamości. Sama deklarowana migracja do nowego rozwiązania nie oznacza, że starszy komponent został faktycznie usunięty.
- zaktualizować lub całkowicie wycofać wszystkie instancje podatnego middleware;
- sprawdzić, czy rozszerzenia przeglądarkowe i natywne hosty nie pozostały jako komponenty osierocone;
- ograniczyć możliwość ładowania nieautoryzowanych bibliotek DLL i monitorować takie próby;
- wdrożyć ścisłe allowlisty dla rozszerzeń przeglądarkowych oraz komunikacji z hostami natywnymi;
- wzmocnić telemetrię EDR lub XDR na stacjach uprzywilejowanych użytkowników;
- przeanalizować logi pod kątem nietypowych uruchomień procesów potomnych i anomalii sesyjnych;
- odseparować urządzenia używane do operacji finansowych i administracyjnych od standardowego przeglądania Internetu;
- traktować middleware łączące przeglądarkę z zasobami lokalnymi jako powierzchnię ataku o podwyższonym priorytecie.
Z perspektywy długofalowej to również wyraźny sygnał, że komponenty kryptograficzne nie powinny opierać się na autorskich mechanizmach walidacji, jeśli istnieją sprawdzone biblioteki i bezpieczne wzorce implementacyjne. Równie ważne jest rygorystyczne egzekwowanie modelu origin trust we wszystkich kanałach komunikacji między aplikacją webową, rozszerzeniem i komponentem natywnym.
Podsumowanie
Przypadek SConnect pokazuje, że bezpieczeństwo środowisk krytycznych zależy nie tylko od siły uwierzytelniania, ale również od jakości i architektury oprogramowania pośredniczącego. Połączenie błędnej walidacji kryptograficznej, nadmiernego zaufania do źródeł komunikacji i możliwości ładowania kodu natywnego stworzyło realną ścieżkę do zdalnego wykonania kodu.
Dla sektora bankowego, administracji i organizacji korzystających ze sprzętowych tokenów to ważne ostrzeżenie: ochroną trzeba obejmować cały łańcuch uwierzytelnienia, a nie jedynie jego najbardziej widoczny element. Nawet pojedynczy, zalegający komponent może stać się punktem wejścia do znacznie poważniejszego incydentu.
Źródła
- Dark Reading – SWIFT Banking & Government Middleware Enables RCE – https://www.darkreading.com/cybersecurity-operations/swift-banking-govt-middleware-rce
- CVE Record – CVE-2026-18397 – https://www.cve.org/CVERecord?id=CVE-2026-18397
- SWIFT – Customer Security and Access Information – https://www2.swift.com