Badacz mógł logować się na konta w ZUS i wystawiać recepty

25 maja na Zaufanej Trzeciej Stronie pojawiło się trzyczęściowe omówienie podatności w Szafirze – oprogramowaniu służącym do obsługi podpisów kwalifikowanych oferowanych przez Krajową Izbę Rozliczeniową. Michał Leszczyński w artykule podsumowującym swoje odkrycia, stwierdził:

Co najmniej kilkanaście systemów administracji publicznej dostępnych z poziomu internetu było podatnych na atak umożliwiający całkowite pominięcie uwierzytelniania i zalogowanie się na konto dowolnej osoby fizycznej przy założeniu znajomości imienia, nazwiska i numeru PESEL ofiary
Michał Leszczyński, Z3S

Zdalne wykonanie kodu w SzafirHost

Leszczyński zauważył, że oprogramowanie Szafir SDK, którego używa do podpisywania raportów VAT, praktycznie przy każdym użyciu pobiera aktualizację. Zaintrygowała go jednak nazwa biblioteki, która pokazywała się podczas ładowania programu: „commons-discovery-0.2.jar”. Co najgorsze – biblioteka pochodziła z… 2007 roku i była ściągana na komputer co miesiąc. Badacz postanowił kontynuować swoje poszukiwania.

Ekspert ustalił, że docelowe oprogramowanie do podpisywania dokumentów może wywołać bibliotekę DLL wskazaną przez atakującego, zaś strona docelowa jest zapisana w jednym z parametrów JavaScripta bez koniecznej walidacji pod kątem prawdziwości. Warto przy tym dodać, że wtyczka Szafir SDK Web ma 900 tys. użytkowników według Chrome’a

Leszczyński wskazał, że wspomniane podatności (opisane 2 kwietnia w komunikacie CERT Polska) pozwalały na zdalne wykonanie kodu (RCE) na komputerze ofiary. Było to możliwe przez:

• brak walidacji plików DLL, które mogą zostać dostarczone np. w ramach phishingu;
• możliwość uruchomienia aplikacji SzafirHost w oparciu o wtyczkę Szafir SDK Web z dowolnymi parametrami – np. wskazaniem uprzednio pobranej DLL-ki do uruchomienia oraz podstawieniem adresu.

Finalnie skutkuje to możliwością zdalnego wykonania kodu (RCE) z uprawnieniami zalogowanego użytkownika w sytuacji, gdzie aplikacja do podpisów wyświetli URL wskazany przez atakującego. Aby stało się to podczas samego wejścia na stronę internetową, wymaga to wcześniejszego zaakceptowania zgody na uruchomienie na danej witrynie.

„Atakujący może tam ustawić dowolną wartość, na przykład adres jakiejś prawdziwej, popularnej aplikacji używającej SzafirHosta, a większość użytkowników zapewne będzie miała już zapamiętaną zgodę na uruchamianie pod tym adresem, tym samym exploit uruchomi się w pełni automatycznie” – kwituje Leszczyński. Sam proces wykorzystania podatności dostępny jest na nagraniu poniżej.

„Hakowanie" sądu

Michał Leszczyński opisał kolejne podatności porównując je do wózka sklepowego. W teorii do zwolnienia blokady wózka konieczne jest włożenie monety (np. dwuzłotówki), lecz w praktyce wystarczył do tego wyłącznie kawałek plastiku o podobnych wymiarach. Wózek nie weryfikował tego, czy faktycznie dostał monetę, skoro blokada się zwolniła.

Badacz uznał, że stworzy „fałszywą kartę” do podpisów elektronicznych, która:

• wykorzystuje identyczny protokół co prawdziwa karta;
• przedstawia prawdziwy certyfikat podpisu kwalifikowanego;
• sam podpis będzie bezsensownym ciągiem znaków.

Leszczyński wykorzystał w tym celu Yubikeya, na którym wygenerował klucz prywatny z pasującym certyfikatem, a następnie podmienił go na certyfikat kwalifikowany.

„Oczywiście, spowoduje to absurdalną konfigurację YubiKeya – na jednym slocie będzie prawdziwy certyfikat kwalifikowany oraz kompletnie niepasujący do niego klucz prywatny. Gdy będziemy chcieli coś takim narzędziem podpisać, to wygenerowany podpis zawsze będzie technicznie błędny” – zaznacza.

Niemniej badaczowi… po prostu udało się zalogować w oparciu o pozornie bezsensowny podpis, ponieważ aplikacja nie sprawdzała poprawności dostarczonych danych. Podatne na atak były m.in. poniższe portale:

• Portal Rejestrów Sądowych;
• e-Sąd w Lublinie;
• Krajowy Rejestr Zadłużonych;
• usługi elektroniczne Publicznych Służb Zatrudnienia (praca.gov.pl).

Do wykorzystania podatności konieczne jest posiadanie certyfikatu danej osoby, co jest bardzo proste – wystarczy być w posiadaniu dokumentu opatrzonego podpisem kwalifikowanym. Takie pisma są bardzo łatwo dostępne w Internecie w przypadku osób, które pełnią funkcje publiczne i podpisują dokumenty elektronicznie.

Należy dodać, że błąd leży po stronie aplikacji – same urządzenia czy architektura klucza publicznego jest wciąż bezpieczna pod kątem kryptograficznym.

Mając to na uwadze, ciężko oprzeć się wrażeniu, że integratorzy po stronie podmiotów nie zrozumieli zasady działania całego ekosystemu. Dlaczego tak się stało? Trudno gdybać, ale masowy charakter podatności wskazuje na to, że użyte komponenty do weryfikacji podpisów mogły być niedostatecznie udokumentowane albo dokumentacja nie omawiała zagadnienia architektury procesu weryfikacji w wyczerpujący sposób.
Michał Leszczyński, Z3S

ZUS - crème de la crème

Leszczyński postanowił spróbować wykorzystać certyfikat z kluczem, który sam sobie wydał. Oznaczałoby to, że w ramach architektury klucza publicznego (PKI) klucz i certyfikat są zgodne, lecz nie powinno to dawać jakichkolwiek uprawnień w systemie, ponieważ… sam sobie je wygenerował.

Można to porównać do wystawienia sobie samemu prawa jazdy, które wygląda identycznie do wydawanego przez starostwa, a systemy podczas kontroli policji uznają je za poprawne. Tak – to jest podatność tego kalibru.

Badacz wystawił certyfikat na swoje dane osobowe, co pokazuje rozsądne podejście do testów bezpieczeństwa aplikacji webowch – nie uzyskuje dostępu do danych innych osób. Co jednak najgroźniejsze – podatność umożliwiała zalogowanie się na konto dowolnej osoby przy znajomości jej imienia, nazwiska i PESEL-u.

Warto tutaj wspomnieć, że jako atakujący mogłem oczywiście wystawić taki certyfikat na dane dowolnej osoby – potrzebowałem jedynie znać jej imię, nazwisko i numer PESEL. Przy okazji dodam, że mechanizm "zastrzeżenia PESEL-u" nie ma tutaj żadnego zastosowania – powstał on w innym celu, a dokumenty można podpisywać elektronicznie, nawet mając aktywne zastrzeżenie.
Michał Leszczyński, Z3S

Początkowo system informował, że jednego z certyfikatów urzędu certyfikacji nie ma w bazie, przez co nie mógł go uznać za poprawny. Badacz postanowił dodać certyfikaty własnego urzędy certyfikacji i… zadziałało. Udało się mu tak zalogować do Rejestru Asystentów Medycznych oraz ZUS-u. Proces został uwieczony na nagraniu poniżej.

Pomimo że programiści tych systemów zadbali o walidację podpisów, to wpadli w pułapkę wynikającą z istnienia w Szafirze bardzo dziwnej funkcji "certyfikatów niekwalifikowanych". Aplikacje zwracały uwagę jedynie na to, czy weryfikacja podpisu zakończyła się sukcesem. Okazało się, że to nie wystarczy, bo powinny również osobno sprawdzać, czy była to "weryfikacja kwalifikowana". Można zatem było system oszukać podpisem technicznie prawidłowym, choć fikcyjnym.
Michał Leszczyński, Z3S

W kontekście Centrum e-Zdrowia, jeśli znałbym numer PESEL jakiegoś lekarza posiadającego dostęp do Rejestru Asystentów Medycznych, mógłbym zalogować się w jego imieniu, następnie mianować samego siebie Asystentem Medycznym i... wypisywać recepty, skierowania i zwolnienia lekarskie na odpowiedzialność tego lekarza, bez jego wiedzy.
Michał Leszyczyński, Z3S

Należy odnotować, że KSeF nie był podatny na ww. możliwość ominięcia uwierzytelnienia.

Wiceminister o podatności

Michał Leszczyński apeluje o powstrzymanie się z krytyką czy ewentualnym wyciąganiem konsekwencji od osób odpowiedzialnych za systemy. „(…) zawiodły procedury (niedostateczny nadzór nad systemami, niedostateczna liczba i zakres audytów), czyli przede wszystkim osoby decyzyjne” – zaznacza.

Dodaje, że same karty do podpisu kwalifikowanego pozostają bezpieczne.

W trakcie konferencji prasowej poświęconej mObywatelowi wiceminister Dariusz Standerski został zapytany o sprawę podatności opisanych na łamach Z3S. „Dziękujemy wszystkim, którzy alarmują, bo dzięki temu możemy budować jeszcze silniejszą sieć w zakresie potwierdzenia swojej tożsamości” – stwierdził.

Co to oznacza?

Szereg tak poważnych podatności pokazuje, że wciąż potrzebujemy szerokiego myślenia o cyberbezpieczeństwa. Widzimy, że z założenia bezpieczną technologię (architekturę klucza publicznego) można zaimplementować w sposób, który będzie łatwy do ominięcia.

Michałowi Leszczyńskiego należą się ogromne gratulacje i szacunek za znalezienie podatności oraz odpowiedzialne i etyczne zgłoszenie luk w oprogramowaniu.

Zadajmy sobie pytanie: ile jeszcze usług ma podobne podatności?

Mam nadzieję, że przekazana tu wiedza pomoże w opracowaniu lepszych procesów w organizacjach, a także lepszych technik testów penetracyjnych, niezwykle potrzebnych w tych skomplikowanych czasach.
Michał Leszczyński, Z3S

Podatności opisywane przez badacza są załatane – proces został szczegółowo opisany w trzeciej części opracowania.

Na początku 2025 roku ofiarą ataku ransomware padł Eurocert – dostawca kwalifikowanych usług zaufania.

CVE ID opisywanych podatności: CVE-2026-26927, CVE-2026-26928, CVE-2026-9058.