Ominięcie uwierzytelniania w ZUS-ie i systemach e-Zdrowia, czyli o krok od cyberchaosu – [CVE-2026-9058] [Badanie e-podpisów, cz. 3] | Zaufana Trzecia Strona

szukaj

szukaj<br>zamknij wyszukiwanie

25.05.2026 | 15:29

Michał Leszczyński

1 komentarz

Udostępnij:

wykop

tw

fb

li

Ominięcie uwierzytelniania w ZUS-ie i systemach e-Zdrowia, czyli o krok od cyberchaosu – [CVE-2026-9058] [Badanie e-podpisów, cz. 3]

błąd<br>certyfikat<br>dane wrażliwe<br>e-Gate<br>e-podpis<br>e-sąd<br>e-Zdrowie<br>podatność<br>podpis kwalifikowany<br>ZUS

Podatność umożliwiająca zalogowanie się na konto dowolnego użytkownika występowała w kilkunastu systemach administracji publicznej, w tym ZUS i CEZ. Wymagania? Dostęp do internetu, znajomość PESEL-u ofiary i posiadanie odpowiednich narzędzi. Przeprowadzenie ataku zajmowało mniej niż minutę, a sam atak omijał również dwuskładnikowe uwierzytelnianie. Nie, to nie jest clickbait. To ostatnia i najbardziej druzgocąca część mojego badania w obszarze e-podpisów, w którym najwidoczniej nie testuje się krytycznych integracji oprogramowania.

Przypomnijmy, w poprzednim artykule z tej serii próbowałem uzyskać nieautoryzowany dostęp do serwisów administracji publicznej przez funkcję logowania “certyfikatem kwalifikowanym”, używając do tego niepoprawnego podpisu cyfrowego, złożonego w oparciu o autentyczny certyfikat.

Ku wielkiemu zaskoczeniu, zastosowanie tej techniki dawało możliwość zalogowania się w niektórych systemach administracji publicznej, w tym niemal we wszystkich publicznych usługach Ministerstwa Sprawiedliwości.

Zdecydowana większość systemów innych urzędów obroniła się przed testowanym atakiem. Tym razem rozważymy więc alternatywny pomysł.

Seria “Badanie e-podpisów”

Artykuł stanowi część cyklu opisującego mój hobbystyczny projekt badania bezpieczeństwa oprogramowania związanego z obsługą podpisów kwalifikowanych.

Zdalne wykonanie kodu w SzafirHost – [CVE-2026-26928] [Badanie e-podpisów, cz. 1]

Hakowanie e-Sądu YubiKeyem – [Badanie e-podpisów, cz. 2]

Ominięcie uwierzytelniania w ZUS-ie i systemach e-Zdrowia, czyli o krok od cyberchaosu – [CVE-2026-9058] [Badanie e-podpisów, cz. 3]

Streszczenie całej serii w postaci niewymagającej od czytelnika posiadania rozległej wiedzy technicznej znajduje się w odrębnym artykule: “Krytyczna podatność umożliwiająca całkowite ominięcie logowania w ZUSie, e-Sądzie i systemach e-Zdrowia” .

Rozwinięcie ataku: tym razem fałszywy certyfikat, prawdziwy podpis

Jednym z tych, którzy obronili się przed poprzednią próbą ataku, był system “e-Gate – Obsługa Podpisów Elektronicznych w Ochronie Zdrowia”. Szybko stał się on moim ulubionym obiektem testowym, ponieważ jako jedyny wyświetlał komunikaty błędów informujące o dokładnym powodzie, dla którego podpisany plik został odrzucony.

Efekt przeprowadzenia pierwszego ataku na e-Gate – bez sukcesu

Ten komunikat dosłownie prowadzi mnie za rękę w procesie decydowania o dalszych krokach. Skoro przypadek niepoprawnego podpisu cyfrowego jest wykrywany, to postaramy się zaadresować ten konkretny problem. Zróbmy tak, aby podpis był poprawny i zgodny z pozostałymi danymi.

Tutaj powstaje istotne ograniczenie – poprawny podpis cyfrowy uzyskam jedynie w dwóch przypadkach:

używając czyjejś karty do podpisu kwalifikowanego – odpada, naturalnie nie posiadam dostępu do cudzych kart,

używając certyfikatu wraz z kluczem, które wydałem sam sobie – podpis cyfrowy będzie wtedy kryptograficznie poprawny, ale i tak powinien zostać odrzucony jako niezaufany, jako że nie jestem podmiotem uprawnionym do wydawania takich certyfikatów.

Czy tym razem teoria zgodzi się z praktyką? Spróbujemy to ustalić.

Alternatywne PKI

Na początek potrzebujemy stworzyć własną, alternatywną infrastrukturę klucza publicznego (ang. Public Key Infrastructure, PKI). Brzmi bardzo groźnie, ale sprowadza się do poprawnego użycia kilku komend linuksowych, które w efekcie wygenerują niezbędne klucze i certyfikaty, a finalnie zapiszą to wszystko w plikach na dysku.

Wygenerowałem swoje własne certyfikaty “root CA” oraz “intermediate CA” (tzn. głównego i pośredniego urzędu certyfikacji), dla pewności ostrożnie dostrajając konfigurację tak, aby była jak najbliżej prawdziwych certyfikatów. Użyłem identycznych nazw, poustawiałem atrybuty na takie same wartości i dołączyłem te same rozszerzenia X.509. Zasada była prosta – im bardziej wiarygodnie to wszystko wygląda, tym większa szansa na to, że nic mnie nie zablokuje i atak zakończy się sukcesem.

Po kilku godzinach walki z OpenSSL-em moje dzieło było gotowe, a certyfikaty rzeczywiście wyglądały niemal jak te prawdziwe. Jedyny szkopuł w tym, że nie znajdowały się na jakiejkolwiek liście zaufanych certyfikatów.

Niezaufany łańcuch certyfikatów użyty do testów podatności

W międzyczasie rozwinąłem również koncepcję “fałszywej karty”. Tym razem zamiast YubiKeya tę rolę będzie pełnił SoftHSM2 – program, który symuluje fizyczny klucz kryptograficzny, ale tak naprawdę wszystkie operacje wykonuje na lokalnym komputerze. Po takiej...