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]

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.

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:

1. używając czyjejś karty do podpisu kwalifikowanego – odpada, naturalnie nie posiadam dostępu do cudzych kart,
2. 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.

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 modyfikacji, cała infrastruktura do przeprowadzenia ataku mieści się w ramach zwykłej maszyny wirtualnej z systemem Windows 11, nie wymagając jakiegokolwiek dodatkowego zewnętrznego sprzętu.

Moje fałszywe centrum certyfikacji już za chwilę wystawi pierwszy certyfikat “kwalifikowany”. Nie chcę jednak moimi testami wywołać zbyt dużego zamieszania ani tym bardziej naruszyć bezpieczeństwa informacji. Fałszywy certyfikat będzie więc wystawiony na moje prawdziwe dane osobowe. Jeśli atak się powiedzie, to zaloguję się na swoje własne konto, do którego i tak miałbym prawowity dostęp.

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.

Co na to system e-Gate?

Początkowo był nieporuszony, bo oprogramowanie w ogólne “nie widziało” mojego fałszywego certyfikatu i nie pozwalało go wybrać.

Pomogła zmiana dynamicznej konfiguracji, która była ładowana po stronie klienta:

1. dopisanie moich fałszywych certyfikatów do listy zaufanych CA,
2. ustawienie, że dopuszczalne jest złożenie podpisu z użyciem dowolnego certyfikatu (niekoniecznie uznawanego za kwalifikowany).

Tym razem udało się podjąć próbę zalogowania, chociaż bezskuteczną, to już z innym komunikatem błędu niż wcześniej.

Wyświetlany komunikat był dosyć specyficzny, więc zacząłem szukać, czy to nie jest przypadkiem rezultat weryfikacji z jakiegoś konkretnego programu. Nie myliłem się, desktopowy program Szafir 2.0.0 na identyczny plik XML reaguje błędem o identycznej treści.

Software zachował się bezpiecznie, ale to jeszcze nie jest moje ostatnie słowo.

Skupmy się na rozwiązaniu konkretnego problemu. Oprogramowanie do weryfikacji podpisów twierdzi, że mojego fałszywego certyfikatu “intermediate CA” nie ma w swojej wewnętrznej bazie danych, przez co nie może go przeanalizować i rozstrzygnąć o poprawności podpisu.

Pomoc w rozwiązaniu tego problemu zapewnia oficjalna specyfikacja “Electronic Signatures and Infrastructures (ESI); XAdES Baseline Profile”:

a) The generator shall include the signing certificate as content of ds:KeyInfo/X509Data/X509Certificate element.

b) In order to facilitate path-building, generators should include in the same ds:KeyInfo/X509Data element as in note a) all certificates not available to verifiers that can be used during path building. (…)

Zwyczajowo, podpisany plik zawiera jedynie certyfikat osoby składającej podpis (tzw. leaf certificate), ale specyfikacja twierdzi, że nic nie stoi na przeszkodzie, aby załączyć tam cały łańcuch certyfikatów, uwzględniając nasze “intermediate CA” oraz “root CA”.

Otwieram podpisany dokument XML w notatniku i ordynarnie doklejam do niego tagi <ds:X509Certificate/> z dodatkowymi certyfikatami CA. Ponowna weryfikacja i…

Ups. Co prawda, doklejenie do pliku dodatkowych certyfikatów jest zgodne ze specyfikacją, ale ma to służyć jedynie jako pomoc czy też podpowiedź dla oprogramowania sprawdzającego podpis. Szafir wziął jednak temat zbyt dosłownie i… automatycznie zaimportował te certyfikaty do swojej bazy danych zaufania.

No dobrze, a dlaczego otrzymaliśmy informację, że jest to podpis niekwalifikowany? W bardzo dużym skrócie, weryfikacja techniczna została pomyślnie zaliczona, ale moich podrobionych certyfikatów CA nie ma na unijnej liście dostawców usług zaufania. Tego mechanizmu nie udało mi się nijak ominąć, ale być może wystarczą dotychczasowe osiągnięcia?

Sprawdźmy, co tym razem powie e-Gate…

Wygląda jakby faktycznie zadziałało! System powiedział, że mój podpis jest poprawny, potwierdził moją tożsamość i przekierował mnie dalej, a widoczny na zrzucie ekranu błąd to już jedynie kwestia tego, że nie jestem lekarzem.

Automatyzacja ataku

Atak działa, ale ma jeden zasadniczy minus: tym razem trzeba się bardzo dużo naklikać, aby w odpowiednim momencie przechwycić niektóre zapytania HTTP z/do serwera atakowanej aplikacji i przeprowadzić “w locie” niezbędne modyfikacje, chociażby dokleić dodatkowe certyfikaty do podpisanego pliku XML. Do ręcznego manipulowania zapytaniami HTTP używałem Burp Suite, którego jednak nie jestem zbyt zaawansowanym użytkownikiem, bo skomplikowane ataki zazwyczaj implementuję bezpośrednio w jakimś języku skryptowym.

Na całe szczęście, istnieje jeden komponent, przez który przepływają wszystkie niezbędne informacje, w dodatku nie trzeba go dekompilować, bo jest napisany w JavaScripcie, a kod nie jest zaciemniony i bardzo łatwo go zmodyfikować. Tym komponentem jest oczywiście wtyczka do przeglądarki “Szafir SDK Web”. Spora część portali administracji publicznej oferujących logowanie podpisem kwalifikowanym żąda instalacji właśnie tej wtyczki, a za jej pośrednictwem wywołuje proces podpisywania dokumentów (więcej kontekstu na ten temat znajduje się w poprzednich artykułach z tej serii).

We wtyczce wprowadziłem relatywnie proste modyfikacje – za każdym razem, gdy strona internetowa próbuje za pośrednictwem wtyczki komunikować się z aplikacją do składania podpisów, wysyłam żądanie do mojego serwera w Pythonie, który może zdecydować o zmodyfikowaniu w locie przesyłanych danych. Analogicznie, gdy komunikacja odbywa się w drugą stronę (z “podpisywarki” do aplikacji internetowej).

Będąc tak przygotowanym, mogę wygodnie eksperymentować, modyfikując chociażby parametry wywołania, konfigurację “podpisywarki”, a także zawartość wynikowego pliku XAdES po złożeniu podpisu – bez manualnej interwencji.

Finalne starcie

Pora na ostateczne starcie, a cel będzie niebagatelny: system Zakładu Ubezpieczeń Społecznych. Dlaczego akurat ZUS? Bo to system przechowujący bardzo ważne dane, a podczas wcześniejszych analiz i eksperymentów znalazłem w nim dosyć osobliwą rzecz.

Co prawda, ścieżka ukazana na zrzucie ekranu stanowi jedynie komentarz i w żaden sposób nie wpływa na działanie mechanizmu składania podpisów kwalifikowanych, ale myślę, że sam fakt istnienia tego komentarza w produkcyjnym kodzie wyraża więcej niż tysiąc słów. Heurystyka jest prosta, jeżeli coś wygląda na zrobione “po łebkach” albo niezgodnie z branżowymi standardami, to tym bardziej warto się temu przyjrzeć.

Nie przedłużajmy już więcej, pora przełknąć tę pigułkę…

Co tu się stało?!

Bazując na moich obserwacjach, przypuszczam, że zarówno aplikacje ZUS-u, jak i CEZ-u weryfikują podpisy kwalifikowane, używając do tego programu Szafir, ale pod postacią biblioteki programistycznej (“headless”).

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.

Ten przypadek pokazuje nam, jak ważna jest precyzyjna dokumentacja, a przede wszystkim intuicyjne projektowanie komponentów bezpieczeństwa. Samego zamysłu istnienia “weryfikacji niekwalifikowanej” w Szafirze działającej w taki sposób, mimo najszczerszych chęci, nie jestem w stanie zrozumieć. W domyślnych ustawieniach zawsze da się utworzyć XML, który zweryfikuje się poprawnie, choćby w oparciu o samodzielnie wystawione certyfikaty typu “self-signed”. To dlaczego w ogóle istnieje taka funkcja i co ona weryfikuje? Czy jej istnienie zostało opisane w dokumentacji dla integratorów? Na te pytania niestety nie znam odpowiedzi, chociaż się jej domyślam.

Ba, nawet standard RFC 2459 (specyfikujący infrastrukturę klucza publicznego) wspomina o tym, że od użytkowników końcowych PKI nie można wymagać zwracania szczególnej uwagi ani wykonywania więcej niż minimalnej koniecznej konfiguracji. Nie oszukujmy się, większość ludzi (w tym programistów) nie interesuje się różnego rodzaju infrastrukturami klucza publicznego, nie zna niskopoziomowych detali i słusznie oczekuje, że jest to intuicyjny “black box”, który mogą łatwo wdrożyć, zapewniając sobie i innym bezpieczeństwo. W każdym innym przypadku to bezpieczeństwo nie jest zapewniane systemowo, a przez to ostatecznie pojawiają się błędy o drastycznych skutkach.

Potencjalne skutki

Przypomnijmy, atak w ulepszonej formule pozwolił na zaatakowanie centralnego systemu logowania e-Gate autorstwa Centrum e-Zdrowia, a także systemu eZUS. Ponadto, opisany tutaj atak działa przeciwko wszystkim serwisom, które były wymienione w poprzednim artykule z serii “Badanie e-podpisów”.

Jedynym wymaganiem do przeprowadzenia tego ulepszonego wariantu ataku była znajomość imienia, nazwiska i numeru PESEL ofiary, a ten ostatni można zdobyć niesamowicie łatwo, używając całego wachlarza sposobów, których opis znajduje się poza zakresem tego artykułu. Posiadając zaledwie te trzy informacje, można było wystawić fałszywy certyfikat na tożsamość ofiary, a następnie zalogować się do systemów w jej imieniu.

Co to oznacza w praktyce? 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.

Dopisanie kogoś do Rejestru Asystentów Medycznych wymaga, co prawda, złożenia podpisanej dyspozycji, ale autoryzację można przeprowadzić Profilem Zaufanym albo… przez system e-Gate, który też udało mi się zhakować w ten sam sposób.

Jeszcze gorzej sprawa wygląda z systemem eZUS. Dostęp do czyjegoś konta oznacza dostęp do szerokiego zakresu jego danych osobowych, w tym jego pełnej historii zatrudnienia, a także umożliwia obliczenie jego pensji – aktualnej i historycznych.

Gdybyśmy natomiast zalogowali się na konto osoby upoważnionej do reprezentacji firmy przed ZUS-em (zapewne księgowego albo prezesa), moglibyśmy w całej firmie wprowadzić nieoczekiwaną jawność wynagrodzeń – pobierając dane i pensje wszystkich pracowników. Istotne jest też, że pracodawca w tym systemie widzi dosyć szeroki zakres danych, bo jest tam chociażby adres zamieszkania, zameldowania, numer PESEL i numer dowodu osobistego każdej osoby zgłoszonej do ubezpieczeń, w tym dane osób wyrejestrowanych nawet na kilka lat wstecz.

No i jeszcze pora na łyżkę miodu w beczce dziegciu – żaden z opisanych ataków nie był skuteczny przeciwko Krajowemu Systemowi e-Faktur (KSeF). Ale to nie jest jedyny system, który przetwarza duże ilości wrażliwych danych, w tym danych przedsiębiorców.

Czy podpisy kwalifikowane są bezpieczne?

Sama w sobie koncepcja podpisów kwalifikowanych stanowi fundament bardzo bezpiecznych rozwiązań, jeżeli mielibyśmy to oceniać pod względem kryptograficznym i faktycznym. Opisane podatności powstały, ponieważ zawiodły konkretne implementacje i integracje.

Prawowici użytkownicy podpisów kwalifikowanych wydanych przez uprawniony podmiot nie muszą podejmować żadnych działań, ponieważ bezpieczeństwo ich podpisów nie zostało naruszone. W szczególności, nie ma konieczności wymiany istniejących urządzeń do podpisu.

Obsługa podatności

Wszystkie odkryte podatności zostały załatane po tym, jak zgłosiłem je do producenta oprogramowania – KIR S.A., a także do zespołu CERT Polska.

Przez mnogość zaangażowanych komponentów i niestandardowość technik, zrozumiałe wytłumaczenie podatności na warstwie technicznej nie było trywialne. W sumie wysłałem w tej sprawie 4 raporty techniczne o łącznej długości 45 stron, nie licząc późniejszych uzupełnień w trakcie komunikacji mailowej.

Incydent był obsługiwany przez CERT Polska, CSIRT GOV oraz Ministerstwo Cyfryzacji. Jako zgłaszający przekazywałem wszystkie informacje bezpośrednio do CERT Polska, który dystrybuował je dalej do pozostałych zaangażowanych organów.

2026-01-23 – Odkrycie pierwszego wariantu podatności (“YubiKey”).

2026-01-24 – Raport do KIR S.A. i CVD CERT.PL.

2026-01-24 – Potwierdzenie otrzymania przez KIR S.A.

2026-01-25 – Odkrycie drugiego wariantu podatności (niezaufane certyfikaty).

2026-01-26 – Raport do KIR S.A. i CVD CERT.PL.

2026-01-26 – Potwierdzenie otrzymania przez KIR S.A. i CVD CERT.PL.

2026-01-27 – Spotkanie osobiste w siedzibie KIR S.A. – techniczne objaśnienie podatności w obu wariantach.

Obsługa podatności – praca.gov.pl

2026-02-19 [T+24 dni] – Logowanie podpisem kwalifikowanym wyłączone, komunikat o tymczasowym wyłączeniu logowania podpisem kwalifikowanym.

2026-03-09 [T+42 dni] – Komunikat o permanentnym wyłączeniu logowania podpisem kwalifikowanym “z przyczyn niezależnych od Ministerstwa”.

Obsługa podatności – ZUS

2026-03-17 [T+50 dni] – Ogłoszenie ZUS o wyłączeniu logowania podpisem od 30 marca 2026 r.

2026-03-31 [T+64 dni] – Usunięcie przycisku do logowania podpisem kwalifikowanym na frontendzie, przy czym API do logowania podpisem kwalifikowanym nadal było dostępne i podatne.

2026-04-01 [T+65 dni] – Wzmianka do CVD CERT.PL o tym, że API w ZUS nadal jest dostępne i podatne (przekazane do CSIRT GOV).

2026-04-15 [T+79 dni] – Kontakt bezpośredni z COT ZUS i przekazanie zgłoszenia, że API nadal jest dostępne i podatne.

2026-04-17 [T+81 dni] – Dostęp do API zablokowany, podatność załatana.

Obsługa podatności – Ministerstwo Sprawiedliwości

2026-03-26 [T+59 dni] – Aktualizacja serwisu obsługującego podpisy kwalifikowane, nadal podatny w pełnym zakresie.

2026-04-15 [T+79 dni] – Kontakt bezpośredni z MS, przekazanie materiałów na temat podatności oraz kodu exploita na Usługę Centralnego Podpisu Elektronicznego Ministerstwa Sprawiedliwości (UCPE MS).

2026-04-24 [T+88 dni] – Załatanie podatności po pracach serwisowych.

Obsługa podatności – Urząd Dozoru Technicznego

2026-04-15 [T+79 dni] – Kontakt bezpośredni z UDT, przekazanie informacji o podatności.

2026-04-20 [T+84 dni] – Załatanie podatności.

Obsługa podatności – Centrum e-Zdrowia

2026-04-14 [T+78 dni] – Kontakt bezpośredni z CeZ, przekazanie materiałów na temat podatności oraz kodu exploita na system e-Gate Centrum e-Zdrowia.

2026-04-29 [T+93 dni] – Wprowadzenie przez CeZ mitygacji, która częściowo załatała podatność.

2026-05-20 [T+113 dni] – Naprawienie podatności po aktualizacji.

Patch do Szafir 2.0 Desktop

Na kilka dni przed publikacją tego artykułu Krajowa Izba Rozliczeniowa wydała aktualizację do oprogramowania Szafir 2.0 Desktop (build 705, data kompilacji 2026-05-18). Po tej poprawce dokumenty z “oszukanymi” certyfikatami nie przechodzą już poprawnie weryfikacji.

Analogiczna aktualizacja została również wprowadzona w bibliotekach Szafir SDK, których systemy administracji publicznej używają do weryfikacji podpisanych dokumentów. Nie jestem w stanie podać konkretnej daty, ale według moich szacunków taka łatka adresująca problem w sposób systemowy została wydana nie wcześniej niż 3 miesiące od mojego zgłoszenia.

CVE-2026-9058

Zespół CERT Polska uznał że konieczność osobnego sprawdzania statusu weryfikacji dokumentu oraz statusu certyfikatu (tj. czy został uznany za autentyczny) stanowi niepotrzebną złożoność mechanizmu zabezpieczeń.

W związku z tym opublikowano wpis o podatności: CVE-2026-9058: Improper Certificate Verification in Szafir SDK (wpis na stronie CERT Polska).

Podsumowanie

To już ostatni artykuł o moim badaniu w obszarze e-podpisów.

Na koniec warto wspomnieć, że opisałem jedynie techniki i pomysły, które okazały się w jakimkolwiek stopniu skuteczne przy atakowaniu rzeczywistych serwisów. Nie opisałem natomiast wielu ślepych uliczek, w które wpadłem podczas procesu odkrywania nowych technik ataku.

Cały projekt można bezpiecznie szacować na co najmniej 100-120 godzin roboczych. Zdecydowaną większość czasu poświęciłem na opracowanie części trzeciej, gdy już wiedziałem, że obrany kierunek jest perspektywiczny. Opisane badanie było finansowane z moich środków prywatnych i nie było realizowane pod niczyim kierunkiem ani zleceniem.

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.

Podatne usługi administracji

Luka bezpieczeństwa umożliwiająca zalogowanie się na dowolną osobę występowała w:

1. systemie eZUS Zakładu Ubezpieczeń Społecznych (zus.pl);
2. wszystkich systemach Ministerstwa Sprawiedliwości, które umożliwiały logowanie przez tzw. “Moduł Tożsamość”, w tym:
   1. e-Sąd w Lublinie,
   2. Portal Rejestrów Sądowych,
   3. Krajowy Rejestr Zadłużonych,
   4. Repozytorium Tytułów Wykonawczych;
3. wszystkich systemach umożliwiających logowanie przez platformę Usług Elektronicznych Ochrony Zdrowia (UEOZ), w tym:
   1. Rejestr Asystentów Medycznych,
   2. System Obsługi Importu Docelowego,
   3. System Informatyczny Rezydentur;
   4. Rejestr Podmiotów Wykonujących Działalność Leczniczą;
   5. System Monitorowania Zagrożeń;
   6. Zintegrowany System Monitorowania Obrotu Produktami Leczniczymi;
4. e-Serwisie Urzędu Dozoru Technicznego (eudt.gov.pl);
5. portalu usług elektronicznych Publicznych Służb Zatrudnienia (praca.gov.pl);
6. portalu e-dokumenty – Centrum Informatycznych Usług Wspólnych Olsztyna (edokumenty.olsztyn.eu).

Opisana podatność nie występowała w systemie KSeF. Nie jest to jednak jedyny system państwowy, który zawiera wrażliwe dane, w tym informacje gospodarcze.

Potencjalne skutki dla obywatela

Wykorzystanie luk bezpieczeństwa umożliwiało między innymi:

1. sprawdzenie czyichś danych osobowych, w tym numeru dowodu osobistego, adresu zamieszkania i zameldowania,
2. sprawdzenie, gdzie dana osoba pracowała i ile zarabiała – włącznie z danymi za co najmniej kilka lat wstecz,
3. uzyskanie listy osób pracujących w danej firmie na umowę o pracę i umowę zlecenie wraz z danymi takimi, jak adres zamieszkania i zameldowania każdego pracownika, numer PESEL, numer dowodu osobistego oraz wysokość wynagrodzenia,
4. przeglądanie spraw w e-Sądzie w Lublinie, w których dana osoba była pozywającym lub pozwanym, wraz z treścią i statusami pozwów,
5. przeglądanie informacji o dłużnikach, wobec których został wystawiony elektroniczny tytuł wykonawczy, wraz z informacją o wierzycielach i wysokości długu,
6. przeglądanie wniosków danej osoby o rejestrację lub wyrejestrowanie jako bezrobotny (o ile zostały złożone elektronicznie),
7. przeglądanie zgłoszeń składanych przez firmy, związanych z zatrudnianiem cudzoziemców na terenie Polski.

Warto nadmienić, że zastrzeżenie przez ofiarę PESEL-u nie blokowało możliwości przeprowadzenia ataku – system zastrzeżeń powstał w celu ochrony przed innymi profilami zagrożeń i nie ma tutaj zastosowania.

Atak pomijał również dwuskładnikowe uwierzytelnianie.

Przyczyna występowania podatności

Na skutek niedopatrzenia wymienione systemy w niedostatecznym stopniu sprawdzały, czy karta do podpisu kwalifikowanego została wydana przez uprawniony do tego podmiot. W efekcie możliwe było wystawianie fałszywych kart do podpisu kwalifikowanego na dane dowolnej osoby fizycznej, co umożliwiało zalogowanie się w imieniu tej osoby.

Co do zasady systemy oparte na podpisach kwalifikowanych są systemami bardzo bezpiecznymi, ale tylko jeżeli zostały wykonane w pełni zgodnie ze sztuką techniczną i rozporządzeniem eIDAS. Odkryty błąd nie oznacza konieczności rezygnacji z używania e-podpisów, ale administracja publiczna powinna zwiększyć liczbę i zakres audytów bezpieczeństwa swoich systemów.

W mojej ocenie, ze względu na techniczne detale błędów, niemal na pewno powstały one przez przypadek. Jednocześnie odkrywca błędu apeluje o powstrzymanie się od krytyki, a tym bardziej od wyciągania konsekwencji wobec konkretnych osób, które programowały wspomniane systemy – zawiodły procedury (niedostateczny nadzór nad systemami, niedostateczna liczba i zakres audytów), czyli przede wszystkim osoby decyzyjne.

Prawowici właściciele kart do podpisu kwalifikowanego nie muszą podejmować żadnego działania, w szczególności nie muszą wymieniać swoich kart na nowe – bezpieczeństwo takich kart nie zostało naruszone. Błąd umożliwiał wyłącznie tworzenie fałszywych kart i korzystanie z takowych, nie miał on natomiast żadnego wpływu na prawdziwe karty, wydane przez uprawnione do tego podmioty.

Zgłoszenie podatności

Podatność została odkryta w styczniu 2026 r. podczas hobbystycznie prowadzonego badania bezpieczeństwa w zakresie obsługi podpisów elektronicznych w polskiej administracji publicznej. W ramach badania autor odkrycia, specjalista i audytor bezpieczeństwa, uzyskiwał dostęp wyłącznie do własnych kont, aby uniknąć ujawnienia wrażliwych informacji.

Znalezione błędy bezpieczeństwa niezwłocznie po ich wykryciu zostały zgłoszone zespołowi CERT Polska oraz producentowi oprogramowania do weryfikacji podpisów – KIR S.A.

Obsługa incydentu

Na ten moment nic nie wskazuje na to, aby podatności były wcześniej znane komukolwiek innemu lub używane do uzyskiwania nieautoryzowanego dostępu do cudzych kont. Wszystkie podmioty wymienione w sekcji “Podatne usługi administracji” wdrożyły aktualizacje naprawiające błędy bezpieczeństwa.

Szczegóły techniczne

Dokładne szczegóły techniczne można znaleźć w artykułach z serii “Badanie e-podpisów”:

• 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]

Wcześniejsza część mojego badania dotyczyła dodatku do przeglądarki ułatwiającego składanie podpisów kwalifikowanych pod dokumentami i logowanie się do różnych usług. Analizowaliśmy więc maszynerię działającą prawie wyłącznie po stronie klienta. Zaintrygowany wynikami z poprzedniej części stwierdziłem, że skoro tam zdarzyło się “trafienie krytyczne”, to koniecznie trzeba się również przyjrzeć algorytmom po stronie serwera. Tym razem spróbujemy zaatakować serwisy administracji publicznej obsługujące logowanie podpisem kwalifikowanym.

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]

Co to jest logowanie podpisem kwalifikowanym?

W uproszczeniu:

1. Strona internetowa generuje plik XML, który można rozumieć jako “oświadczenie o chęci zalogowania się”.
2. Użytkownik podpisuje podpisem kwalifikowanym plik XML, używając do tego specjalnego oprogramowania.
3. Złożenie podpisu powoduje, że do oryginalnego pliku XML zostaną doklejone dodatkowe parametry (zgodnie ze standardem podpisów XAdES):
   1. certyfikat zawierający nasze imię, nazwisko i PESEL – wystawiony przez uprawniony podmiot;
   2. podpis cyfrowy złożony przez nasze urządzenie do generowania podpisów;
   3. informacje o upoważnionym podmiocie, który wydał nasz certyfikat kwalifikowany;
4. Podpisany plik jest wysyłany do backendu określonej aplikacji internetowej.
5. Serwer weryfikuje podpis pod plikiem XML. Zostajemy uwierzytelnieni na stronie internetowej z jednoczesnym potwierdzeniem naszej fizycznej tożsamości obywatela.

Dzięki takim specyficznym właściwościom, ta metoda logowania jest chętnie wykorzystywana przez serwisy administracji publicznej.

Koncepcja wózka sklepowego

Wytłumaczę pomysł na atak przez nieco przyziemną analogię. Niegdyś duże wózki sklepowe były zabezpieczone w taki sposób, że do niewielkiego urządzenia z tyłu wózka trzeba było włożyć monetę, na przykład dwuzłotówkę, aby zwolnić blokadę i zyskać możliwość jeżdżenia wózkiem po sklepie. Oczywiście ten oficjalny sposób nie był jedynym, wszak zamiast monety można było włożyć kawałek plastiku o zbliżonych wymiarach. Istniały również specjalne metalowe klucze, które pozwalały oszukać blokadę.

Dlaczego to działało? Oficjalna specyfikacja, co prawda, nakazywała włożenie dwóch złotych, ale urządzenie w praktyce nie weryfikowało, czy użyliśmy prawdziwej monety, czy też włożyliśmy do slotu cokolwiek dostatecznie podobnego.

“Podrobiona” karta do podpisu

Spróbujmy dosłownie przenieść tę banalną koncepcję na grunt podpisów elektronicznych i stworzyć “wytrych”. W tym przypadku będzie nim fałszywa karta do podpisu kwalifikowanego, która:

1. rozmawia identycznym protokołem, co prawdziwa karta od któregoś z uprawnionych wystawców, oraz
2. przedstawia mój prawdziwy certyfikat podpisu kwalifikowanego, ale
3. składany przez kartę podpis cyfrowy będzie losowym bezsensownym ciągiem bajtów.

Gdyby udało się pójść taką ścieżką, moglibyśmy takiej karty spróbować użyć niemal wszędzie, w dodatku działałoby z nią oryginalne oprogramowanie.

Pliki XML podpisane z użyciem takiej fałszywej karty będą miały prawidłową strukturę, ale oczywiście nie mają prawa przejść weryfikacji zgodnej ze standardem XAdES. W teorii ten atak nie ma prawa działać, oczywiście, o ile mechanizmy weryfikacji wszystkich aplikacji operujących na e-podpisach są zaimplementowane tak, jak należy.

Stworzenie takiego narzędzia chaosu wymaga kupienia niezaprogramowanej karty typu “JavaCard”, a później napisania dla niej firmware w sposób zgodny z powyższym pomysłem, wgrania go na kartę, skonfigurowania jej i… gotowe.

No prawie. Nie trzeba było długich chwil refleksji, aby dojść do wniosku, że opracowanie takiego narzędzia od podstaw generuje zbyt duży nakład czasowy, biorąc pod uwagę znikome szanse na zadziałanie ataku. Od tej pory poszedłem ścieżką przerabiania gotowych rozwiązań.

Po kilku godzinach młócenia kodu z GitHuba zrezygnowałem również z tego pomysłu, okazało się bowiem, że idealne rozwiązanie cały czas leżało przede mną na biurku, a był nim YubiKey 5.

Atak z użyciem YubiKeya

YubiKey posiada moduł PIV (Personal Identity Verification), który działa prawie tak samo jak karta do podpisu kwalifikowanego i można się z nim komunikować przez interfejs PKCS#11, dokładnie tak jak z prawdziwą kartą. Dzięki temu nie będzie trzeba zbyt wiele ingerencji, aby “przestawić” oryginalne oprogramowanie do współpracy z YubiKeyem.

W dodatku istnieje wygodny interfejs graficzny, który umożliwi nam przeprowadzenie całej operacji.

Najpierw użyjemy funkcji “Generate” i wygenerujemy na YubiKeyu klucz prywatny RSA 2048 wraz z pasującym do niego samodzielnie wygenerowanym i podpisanym certyfikatem (ang. self-signed). Następnie zaimportujemy na ten slot mój 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. Z kolei sam podpisany plik wraz z całą swoją strukturą zostanie faktycznie wygenerowany. Dokładnie o to nam tutaj chodzi.

Jedyne, co musimy zrobić, to wejść na jakąś stronę obsługującą logowanie podpisami kwalifikowanymi i spróbować użyć naszego klucza USB. Co prawda, na początku oprogramowanie do składania podpisów twierdzi, że nie było w stanie znaleźć żadnych certyfikatów, ale wystarczy wskazać w ustawieniach, że nasza “karta kwalifikowana” do działania potrzebuje dodatkowej biblioteki, po czym wskazać plik DLL z modułem PKCS#11 dla YubiKeya.

Pora na testy. Pierwszym obiektem eksperymentalnym był Moduł Tożsamość Ministerstwa Sprawiedliwości, przez który chciałem zalogować się do Portalu Rejestrów Sądowych. I ku mojemu ogromnemu zdziwieniu, udało się…

Podatne podmioty

Mając gotowe narzędzie, zgodnie z założeniami, mogłem szybko i wygodnie przetestować wszystko, co się nawinęło. Opisaną techniką byłem w stanie włamać się do:

1. wszystkich serwisów obsługujących logowanie przez Moduł Tożsamość Ministerstwa Sprawiedliwości, między innymi:
   1. Portalu Rejestrów Sądowych,
   2. e-Sądu w Lublinie,
   3. Krajowego Rejestru Zadłużonych,
   4. Repozytorium Tytułów Wykonawczych;
2. e-Serwisu Urzędu Dozoru Technicznego (eudt.gov.pl);
3. usług elektronicznych Publicznych Służb Zatrudnienia (praca.gov.pl);
4. portalu e-dokumenty – Centrum Informatycznych Usług Wspólnych Olsztyna (edokumenty.olsztyn.eu).

Jedynym warunkiem do przeprowadzenia ataku było posiadanie pliku z certyfikatem kwalifikowanym ofiary, który jeszcze nie wygasł i nie został odwołany. Skąd go pozyskać?

Kwestia certyfikatu

Wystarczy, że będziemy w posiadaniu dowolnego dokumentu opatrzonego przez tę osobę podpisem kwalifikowanym. Certyfikat podpisującego będzie tam załączony i można go trywialnie wyeksportować, również za pomocą konwencjonalnych narzędzi.

Dodatkowo źródłowy dokument powinien być wystawiony przez ofiarę na przestrzeni ostatnich kilku miesięcy, tak aby certyfikat użyty do podpisu był jeszcze w granicach terminu ważności.

W tym miejscu należy koniecznie wspomnieć, że możliwość uzyskania czyjegoś pliku z certyfikatem nie jest podatnością bezpieczeństwa. Taka możliwość wynika ze sposobu działania całego systemu podpisów. Gdyby wszystko było zaimplementowane poprawnie, posiadanie takiego pliku nadal nie umożliwiłoby nam przeprowadzenia jakiegokolwiek ataku.

Możliwość złożenia podpisu w czyimś imieniu zależy od możliwości uzyskania dostępu do jego klucza prywatnego, a ten w przypadku podpisów kwalifikowanych zawsze znajduje się na fizycznym urządzeniu albo w chmurze wystawcy podpisów – to są komponenty odpowiedzialne za zabezpieczenie całego procesu. Tym samym dostępność pliku z certyfikatem nie niesie żadnych implikacji w tym kontekście.

Co dokładnie zawiodło?

O ile sama koncepcja podpisów kwalifikowanych jest bezpieczna pod względem kryptograficznym i faktycznym, o tyle tutaj zaszło coś wysoce niepokojącego na gruncie systemowym. Aplikacje w ogóle nie sprawdzały poprawności złożonych podpisów po stronie serwera. Wystarczył więc sam fakt przejścia procesu od początku do końca i przesłania komunikatu o określonej strukturze.

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.

Co więcej, przez co najmniej kilka lat nie wykrył tego żaden test penetracyjny, pomimo że podatność jest możliwa do odnalezienia w formule “black-box”. Czy nastąpiło tu dogmatyczne założenie, że jest to bezpieczny komponent i nie ma konieczności testowania bezpieczeństwa? A może był to element zakresu testów, ale pomijano go ze względu na brak rozpowszechnionych technik i standardów testowania tego typu mechanizmów? Te i wiele innych refleksji pozostawiam zainteresowanym.

Dodatkowo czarę goryczy przelewa fakt, że przeprowadzenie ataku nie wymagało użycia żadnego specjalistycznego “narzędzia hakerskiego”. Nie było też konieczności napisania chociaż jednej linijki kodu czy nawet komendy wiersza poleceń. Cały atak, jak zaprezentowałem, da się wykonać przez GUI, używając standardowych programów.

To jeszcze nie koniec…

Zainspirowany osiągniętymi rezultatami postanowiłem zainwestować w moje badanie dodatkowe kilkadziesiąt godzin i rozwinąć odkrytą technikę ataku, a to pozwoliło zhakować kolejne podmioty – te, które były odporne na sztuczki opisane w tym artykule.

Co jeszcze i w jaki sposób udało się zhakować, a także jak wyglądała obsługa tych podatności na osi czasu – o tym w kolejnej, ostatniej już części.

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

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 – [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 – [Badanie e-podpisów, cz. 3]

Prolog

Jako osoba prowadząca jednoosobową działalność gospodarczą jestem zobowiązany do podpisywania i składania różnego rodzaju raportów, takich jak chociażby JPK_VAT. Do generowania niezbędnych dokumentów księgowych używam popularnej, komercyjnej aplikacji internetowej.

Raporty VAT są raczej tematem przyziemnym i mało fascynującym, natomiast pod względem technicznym interesujący jest sam proces ich podpisywania – mogę to zrobić bezpośrednio z przeglądarki. Podłączam czytnik kart do komputera, wkładam moją kartę z podpisem kwalifikowanym i klikam “Podpisz” w aplikacji internetowej.

Dalej następuje skomplikowana reakcja łańcuchowa: aplikacja internetowa wywołuje dodatek do przeglądarki, który uruchamia program w Javie, który z kolei pobiera z internetu jakieś komponenty o groźnie brzmiących nazwach. Wreszcie, cały ten moloch uruchamia się, prosi mnie o PIN, składa podpis na deklaracji i… gotowe.

To, co od dłuższego czasu zwracało moją uwagę, ale nigdy nie miałem czasu się temu przyjrzeć, to fakt, że oprogramowanie do składania podpisów pobiera aktualizacje niemal za każdym razem, kiedy potrzebuję go użyć. W monotonii comiesięcznego podpisywania raportów dałbym sobie rękę uciąć, że od lat patrzę na ten sam pasek postępu, pobierający w kółko te same biblioteki… Zaraz…

Zacząłem faktycznie notować wyświetlane nazwy i wersje pobieranych bibliotek, a później wyszukałem je w repozytorium paczek do Javy (Maven Repository).

Nie myliłem się. Co miesiąc pustym wzrokiem patrzę na pasek postępu, obserwując, jak oprogramowanie do podpisu ściąga bibliotekę wydaną w 2007 roku w ramach “aktualizacji oprogramowania”.

Naturalnie, postanowiłem zajrzeć do środka i spróbować naprawić irytujące zachowanie. I tutaj rozpoczyna się nasza przygoda…

Dlaczego ciągle mam aktualizacje?

Możliwość składania podpisów kwalifikowanych w aplikacji internetowej zapewnia dodatek do przeglądarki “Szafir SDK Web”, który do poprawnego działania wymaga natywnej aplikacji “SzafirHost” napisanej w Javie. Cały ten stos technologiczny opracowała Krajowa Izba Rozliczeniowa S.A. (KIR) – najbardziej znana z systemu przelewów ELIXIR oraz BLIK-a.

Sama wtyczka do przeglądarki jest dosyć minimalistyczna – wystawia pewne funkcje w JavaScripcie, które pozwalają na wywołanie aplikacji “SzafirHost” i komunikację z nią. Funkcjonalnie wtyczka praktycznie ogranicza się do roli pośrednika pomiędzy stroną internetową a natywnym programem.

Natomiast, jak się okazuje, sama natywna część również nie zawiera właściwej funkcjonalności. Jedyną rolą “SzafirHosta” jest pobranie faktycznych komponentów z internetu, zweryfikowanie ich integralności i wreszcie uruchomienie docelowego oprogramowania, które będę roboczo nazywał “podpisywarką”.

W tym miejscu warto dodać, że to aplikacja internetowa wskazuje miejsce, z którego SzafirHost będzie pobierał faktyczne pliki “podpisywarki”. U mnie będą to serwery programu księgowego. Brzmi to w miarę racjonalnie: skoro twórcy aplikacji chcą używać takiego rozwiązania, to jednocześnie są odpowiedzialni za hostowanie wszystkich “binarek” na swoim serwerze, płacenie za transfer i zapewnienie dostępności oraz satysfakcjonującej prędkości pobierania. Integralność ściągniętych plików i tak zostanie sprawdzona przez SzafirHosta, tym samym pobieranie ich z potencjalnie niezaufanego źródła nie jest problemem.

Krótka dygresja: analogicznie działają aktualizacje w systemach opartych na Debianie. Same pliki możemy pobierać chociażby przez HTTP z osiedlowego serwera pana Zdziśka – na koniec system operacyjny i tak upewni się, czy wszystkie pliki są autentyczne i nie zostały w locie podmienione czy też zmodyfikowane.

Przejdźmy do sedna. Dlaczego co miesiąc widzę aktualizację? Wyjaśnienie jest bardzo proste, pliki “podpisywarki” pobierane są do katalogu tymczasowego (dokładnie do %TEMP%). Nowy Windows posiada natomiast funkcję “Storage Sense”, która co jakiś czas ten katalog opróżnia. Błąd powstał organicznie w następstwie dodania nowej funkcji w Windowsie. Wyłączenie tej funkcji rozwiąże mój problem “wiecznej aktualizacji”. Zagadka rozwiązana.

Analiza zabezpieczeń

Skoro znalazłem już odpowiedź na moje pytanie, byłem o krok od zakończenia mojego śledztwa i wzięcia się za prawdziwą pracę. No prawie, gdyby nie to, że minutę później, w tym samym pliku znalazłem kod pętli weryfikującej pobrane komponenty, który można streścić mniej więcej w ten sposób:

// Pseudokod (~Java), opracowanie własne

// executed for each downloaded file:

void verifyFile(DownloadedFile downloadedFile) {

  if (downloadedFile.isJAR()) {

      if (isTrustedFileHash(downloadedFile)) {

          print(downloadedFile.getName() + " - HASH OK");

      } else if (checkDigitalSignature(downloadedFile)) {

          print(downloadedFile.getName() + " - SIGNATURE OK");

      } else {

          throw new IntegrityException("JAR is not properly signed.");

      }

  } else if (downloadedFile.isNativeLib() && isTrustedFileHash(downloadedFile)) {

    print(downloadedFile.getName() + " - HASH OK");

  } else {

    print();

  }

}

Co tu jest nie tak? Przeanalizujmy po kolei.

Pliki JAR są weryfikowane z użyciem kaskady dwóch bezpiecznych mechanizmów – jeżeli weryfikacja któregokolwiek pliku nie powiedzie się, to program zgłosi wyjątek i cały proces pobierania zostanie przerwany w wyniku błędu. Świetnie.

A pozostałe pliki? Aplikacja obliczy sumę kontrolną każdego z nich, używając bezpiecznego algorytmu SHA-256 i porówna z listą zaufanych plików. Natomiast jeśli pliku nie ma na liście zaufanych, to… nie zrobi absolutnie nic i przejdzie dalej. Tutaj już mniej świetnie, ale to samo w sobie jeszcze niczego złego nie oznacza. Dlaczego? Już wyjaśniam.

Paczka oprogramowania z “podpisywarką” może zawierać dowolne komponenty o rozszerzeniach: JAR, DLL, SO, JNILIB oraz DYLIB. SzafirHost ściąga wszystkie pliki wchodzące w skład paczki na dysk, a później weryfikuje integralność wszystkich pobranych plików JAR i ładuje kod maszynowy – również wyłącznie z plików JAR.

Tym samym pliki o pozostałych rozszerzeniach, co prawda, zostaną pobrane na dysk użytkownika bez żadnej weryfikacji, ale też nie zostaną uruchomione. No prawie…

Po uruchomieniu się “podpisywarki” strona internetowa może poprosić ją o załadowanie dowolnej biblioteki DLL/SO/DYLIB z dysku twardego. W normalnej sytuacji ten mechanizm umożliwia doczytanie bibliotek niezbędnych do obsługi określonego modelu karty/urządzenia USB służącego do podpisu. Dzięki temu “podpisywarka” jest uniwersalna i obsługuje urządzenia od różnych wystawców podpisów kwalifikowanych.

Piszemy exploit

Co się stanie dalej, tego zapewne niejeden się już domyśla.

1. Odtwarzamy paczkę z oprogramowaniem, między innymi na podstawie plików, które są w moim %TEMP%, oraz paru innych elementów.
2. Dorzucamy do paczki własną bibliotekę DLL. Celem jest jedynie demonstracja koncepcji, więc DLL-ka nie będzie robiła nic złego. Wyświetli tylko komunikat z napisem “Hello from RCE!”.
3. Pożyczamy fragmenty kodu JavaScript wywołującego proces podpisywania dokumentu ze źródła strony mojej aplikacji księgowej.
4. Składamy z tego wszystkiego prostą stronę internetową i testujemy.

Po wejściu na stronę moim oczom ukazał się taki dialog:

Okazuje się, że zanim SzafirHost zacznie działać, zapyta użytkownika o zgodę na uruchomienie w kontekście określonej strony internetowej. Jeżeli użytkownik kliknie “Uruchom” i odczeka kilka sekund, to exploit faktycznie zadziała i złośliwy plik DLL zostanie uruchomiony w systemie (z uprawnieniami aktualnie zalogowanego użytkownika).

W tym miejscu moglibyśmy stwierdzić, że jeszcze nie jest tragicznie, albowiem żaden świadomy użytkownik przecież nie zatwierdzi “w ciemno” żądania o odpalenie Szafira z jakiejś losowej strony internetowej.

Ku wielkiemu zdziwieniu, adres wyświetlany jako “lokalizacja wywołania” jest… zwykłym parametrem w JavaScripcie, przekazywanym przez aplikację webową, która chce zainicjować proces podpisu.

const _szafirConfig = {

    document_base_url: window.location.origin,  // ?!

    sdk_location_url: "/szafir_build_directory/",

    // ...

}

EXT_postMsg({command: "load", config: _szafirConfig});

Pomysł? Ustawiamy “document_base_url” na “https://podatki.gov.pl” – bo taki adres chciałbym wyświetlić w okienku z pytaniem o zgodę, natomiast w “sdk_location_url” podamy pełny URL do mojego serwera, bo to stamtąd chcemy pobrać złośliwą paczkę z oprogramowaniem.

Absurdalne? Tak. Niemniej jednak to faktycznie działa, a nasze dzieło zniszczenia jest gotowe.

Dialog z pytaniem o zgodę

Powróćmy jeszcze na chwilę do kwestii dialogu, w którym wyrażamy zgodę na uruchomienie SzafirHosta. Znajduje się tam opcja “zapamiętaj zgodę na uruchomienie” i jeżeli użytkownik ją zaznaczy, to kolejnym razem pytanie się już w ogóle nie pojawi. Ponownie, nie chodzi o prawdziwą lokalizację na pasku przeglądarki, tylko o lokalizację definiowaną parametrem “document_base_url” przez wywołującą stronę internetową.

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.

Mechanizm udzielania zgody nie istniał w aplikacji od zawsze, lecz został dodany w nowszych wersjach SzafirHosta. Starsza wersja (chociażby 1.0.7) zawsze uruchomi się automatycznie.

Skutki

Istnieją dwa zasadnicze kierunki wykorzystania podatności. Naturalnie w obu przypadkach zakładamy, że ofiara ma zainstalowany zarówno dodatek do przeglądarki Szafir Web SDK, jak i SzafirHosta.

Wariant #1: Kampania phishingowa

Atakujący celuje w konkretną grupę osób, która często używa “podpisywarki” i robi to w ramach konkretnej aplikacji internetowej, więc najprawdopodobniej ma już zapamiętaną zgodę na automatyczne uruchamianie pod tym adresem. To otwiera możliwość stworzenia złośliwego linku, który bez pytania wgra wirusa w formacie DLL na komputer ofiary, a jedynym warunkiem jest kliknięcie w złośliwy link w mailu.

Wariant #2: Eskalacja z ataku Stored XSS

Atakujący dysponujący podatnością typu stored XSS (zwykle kojarzoną z niskim ryzykiem) w dowolnej aplikacji używającej SzafirHosta może uruchamiać exploit, w momencie gdy następowałoby normalne uruchomienie aplikacji. Użytkownik na pewno udzieli zgody na uruchomienie, bo jest to dokładnie ta akcja, którą w tym momencie chce wykonać.

Zasięg podatności

Według Chrome Web Store w lutym 2026 r. wtyczka Szafir SDK Web posiadała 900 tysięcy użytkowników. Konkretniej, jest to liczba unikalnych instalacji przeglądarek, które załadowały rozszerzenie w ciągu ostatniego tygodnia .

Wszystko wskazuje więc na to, że w środowiskach profesjonalnych oprogramowanie jest raczej szeroko rozpowszechnione, a potencjalne skutki wykorzystania podatności byłyby bardzo poważne.

Dalsze losy tej podatności

Odkrytą podatność zgłosiłem do zespołu CERT Polska w ramach procesu Coordinated Vulnerability Disclosure i została ona już załatana.

Zespół CVD CERT.PL w związku ze zgłoszeniem opublikował CVE:

1. CVE-2026-26927 – URL (HTTP Origin) call location spoofing in Szafir SDK Web;
2. CVE-2026-26928 – Lack of Dynamic Library Validation in SzafirHost;

Oś czasu obsługi incydentu:

Podsumowanie

Na tym kończy się pierwsza część mojej analizy, ale to definitywnie nie jest koniec całej sprawy. Przypadek opisany dzisiaj to najłagodniejsza spośród trzech podatności, jakie udało mi się znaleźć w obszarze implementacji podpisów kwalifikowanych.

Dalsza część tej historii znajduje się w kolejnych częściach artykułu, a im dalej w las, tym gorzej…

Następna część: Hakowanie e-Sądu YubiKeyem – [Badanie e-podpisów, cz. 2]

Hashe SHA-256 analizowanych plików

04554ebc55e07c146c5ca27a282d92ec4cf416a33332d0ae8544d626ac3aaf14 *szafir_sdk_web_chrome_ext_0_0_17_2.crx

0d44272747f9b56af46953b930c95bda5d19b767bc598375b6022d63b42a8eae *szafir_sdk_web_chrome_ext_0_0_17_2.zip

a8d8e0b92eaee62071caff5e5a0a15105b2bcdd946896949f0e3e2b41ce21b2c *szafir_sdk_web-0_0_17_2.xpi

ff4c89405d51b41df09dd22179e45a1838c69cc59942adb953194f9b20214ce6 *SzafirHost.jar [version 1.0.15]

fca67396c5edd28c20061584523efe1edf412b5615a9bba7a354bc5bf7dd63ae *SzafirHost.jar [version 1.0.7]

W dzisiejszym wydaniu szczególnie polecamy w części fabularnej raport pokazujący, kto, do czego i jak korzysta z AI w instytucjach publicznych (pkt 4), poczytajcie też o przypadkowej publikacji exploita dla niezałatanej luki w Chromium (pkt 12). W części technicznej sprawdźcie, jak Microsoft przejął domenę usługi do podpisywania złośliwego oprogramowania (pkt 9), jak ransomware WantToCry szyfruje pliki zdalnie przez SMB (pkt 18) oraz jak grupa Webworm rozwija nowe tylne furtki i przenosi ataki do Europy (pkt 20). Życzymy udanej lektury.

Wersja anglojęzyczna

IT Security Weekend Catch Up – May 23, 2026

Część bardziej fabularna

1. [PL] E-Karta Szczepień budzi kontrowersje. Czy to „infrastruktura przymusu”?
2. [PL] Raport ws. Pegasusa przed wakacjami. Służby blokują odtajnienie danych
3. [PL][WIDEO] Raport ABW: Czy jesteśmy bezpieczni?
4. [PL] Kto, do czego i jak korzysta z AI w instytucjach publicznych?
5. [PL] Wojsko stawia na sztuczną inteligencję. Tworzy własny model językowy
6. [PL] W Warszawie powstanie Centrum Cyberbezpieczeństwa NASK
7. [PL] Za oszustwami stoją najczęściej cyberprzestępcze korporacje
8. [PL] Estoński inspektorat finansowy zawiesza licencję Zondacrypto
9. [PL] Prezes serwisu Cinkciarz.pl zatrzymany. Wiódł wygodne życie w USA
10. Skradziony token GitHuba umożliwił kradzież kodu firmy Grafana Labs
11. Atak na 3800 repozytoriów GitHuba poprzez złośliwe rozszerzenie VSCode
12. Badacze z Google przypadkiem opublikowali exploit dla luki w Chromium
13. Mozilla skrytykowała brytyjskie władze za próbę zakazania VPN-ów
14. Niezależny audyt potwierdził krytyczną lukę w protokole Telegrama
15. Discord wprowadza szyfrowanie E2EE połączeń głosowych i wideo

Część bardziej techniczna

1. [PL] CERT Polska: Raport miesięczny za kwiecień 2026
2. [PL] FlyHack obiecuje tanie loty, dostarcza złośliwą aplikację na Androida
3. [PL] Fragnesia (CVE-2026-46300) i DirtyDecrypt (CVE-2026-31635)
4. Luka 1-click w Open WebUI prowadzi do zdalnego wykonania kodu
5. MiniPlasma – luka 0-day w Windowsie umożliwiająca eskalację uprawnień
6. Opublikowano eksploit PoC dla luki DirtyCBC w systemie Linux
7. Claw Chain – łańcuch czterech podatności zagrażających platformie OpenClaw
8. Anthropic naprawił lukę umożliwiającą ucieczkę z sandboxa w Claude Code
9. Przejęto domenę usługi do podpisywania złośliwego oprogramowania
10. Wiarygodne usługi w służbie oszustów przejmujących konta na Facebooku
11. TamperedChef łączy złośliwe reklamy i strojanizowane aplikacje użytkowe
12. SEO poisoning kieruje ofiary na fałszywe strony Gemini i Claude Code
13. Kampania Premium Deception zapisuje ofiary na płatne usługi operatora
14. Mini Shai-Hulud w natarciu: Ponad 600 zainfekowanych pakietów npm
15. Nowa wersja stealera Gremlin z naciskiem na unikanie wykrycia
16. Fałszywe strony Microsoft Teams rozprowadzają ValleyRAT-a
17. Brazylijskie banki i ich klienci na celowniku trojana Banana RAT
18. Ransomware WantToCry szyfruje pliki zdalnie przy użyciu SMB
19. CypherLoc skłania ofiary, by zadzwoniły na fałszywą infolinię
20. Webworm rozwija nowe tylne furtki i przenosi ataki do Europy
21. BadIIS – usługa do nadużyć SEO wykorzystywana przez chińskie grupy
22. Operacja Dragon Whistle celuje w chińskie środowisko akademickie
23. Kampania TAX#TRIDENT z wykorzystaniem fałszywych pism podatkowych
24. Storm-2949 przejął jedno konto, otwierając sobie drogę do chmury Microsoftu
25. Kampania UAC-0184 z Ukrainą w tle kończy się infekcją systemu Windows

Dziękujemy wszystkim, którzy dzielą się z nami znalezionymi w sieci ciekawymi artykułami. Linki możecie przesyłać na adres biuro (at) zaufanatrzeciastrona.pl – są szanse, że trafią do kolejnego wydania Weekendowej Lektury. Możecie też dołączyć do naszego serwera na Discordzie i zostawiać swoje znaleziska na kanale „newsy”: discord.gg/zaufana

W dzisiejszym wydaniu szczególnie polecamy w części fabularnej raport „Demokracja na podsłuchu” o Pegasusie i braku kontroli nad inwigilacją, opracowany przez Panoptykon (pkt 1) oraz artykuł pokazujący, jak spółka BitBay – poprzedniczka ZondaCrypto – zniknęła na oczach wszystkich (pkt 8). W części technicznej spójrzcie na przebieg i wyniki konkursu hakerskiego Pwn2Own Berlin 2026 (pkt 11), poczytajcie też o robaku PCPJack, który kradnie poufne dane i usuwa złośliwe oprogramowanie grupy TeamPCP (pkt 17). Życzymy udanej lektury.

Wersja anglojęzyczna

IT Security Weekend Catch Up – May 16, 2026

Część bardziej fabularna

1. [PL] Demokracja na podsłuchu – najnowszy raport Fundacji Panoptykon
2. [PL][WIDEO] Polska wobec Pegasusa i oprogramowania szpiegującego
3. [PL][WIDEO] Jak się chronić przed cyberatakami i oszustwami internetowymi
4. [PL] Mandat do zapłaty? Uważaj na fałszywe SMS-y od mObywatela
5. [PL] Czy „goły” numer telefonu to dane osobowe?
6. [PL] Weryfikacja wieku dzieci w social mediach? Nie ma dobrego sposobu
7. [PL][WDEO] Stalkerware. Aplikacja za 30 dolarów, która niszczy życie
8. [PL] BitBay / ZondaCrypto. Jak spółka zniknęła na oczach wszystkich
9. [PL][WIDEO] ZondaCrypto – co mogą zrobić poszkodowani klienci?
10. [PL][WIDEO] Zdarzyło się w CERT – na styku zbrodni online i offline
11. [PL] Jakie kary grożą za naruszenie obowiązków wynikających z NIS2
12. [PL] Raporty służb pokazują, jak w Europie rośnie zagrożenie wojną
13. [PL] Sztuczna inteligencja made in Poland w czołgach
14. [PL][WIDEO] Turecki pośrednik. Jak technologia z Polski trafia do Rosji
15. [PL] Dostawcy wysokiego ryzyka. Europa na wojnie z chińskimi big techami
16. [PL] 4D, czyli podstawowe taktyki rosyjskiej propagandy
17. Operacja wpływu wymierzona w Meksyk, czyli afera Hondurasgate
18. Złośliwe oprogramowanie Fast16 fałszowało testy jądrowe w Iranie
19. Grupa ransomware Nitrogen zaatakowała Foxconn i wykradła dane
20. Atak na platformę Canvas zdezorganizował pracę placówek edukacyjnych

Część bardziej techniczna

1. [PL] Dirty Frag: eskalacja uprawnień w jądrze Linuksa za pomocą ESP i RxRPC
2. [PL] Platforma biletowa używana przez ponad 50 obiektów w Polsce i poważne ryzyka na przykładzie Orientarium Zoo Łódź
3. [PL] Złośliwe wersje bibliotek TanStack w oficjalnym repozytorium npm
4. W ramach comiesięcznego cyklu wydawania poprawek Microsoft usunął 130 luk
5. YellowKey i GreenPlasma – dwa nowe exploity na luki 0-day w Windowsie
6. Fragnesia – luka umożliwiająca dostęp do uprawnień roota na Linuksie
7. Niewykryta od 18 lat luka w Nginx pozwala na zdalne wykonywanie kodu
8. Dead.Letter – krytyczna podatność w serwerze pocztowym Exim
9. Podatność CursorJacking ujawnia słabą ochronę danych uwierzytelniających
10. Badacz odkrył tylną furtkę i liczne luki w automatycznych kosiarkach do trawy
11. Przebieg i wyniki konkursu Pwn2Own Berlin 2026 – dzień 1, dzień 2, dzień 3
12. Dlaczego 0.1 + 0.2 to nie 0.3, czyli o liczbach zmiennoprzecinkowych
13. Wtyczki do pobierania filmów z TikToka wykradały dane użytkowników
14. Fałszywe repozytorium OpenAI na Hugging Face zawierało infostealera
15. Od początku kwietnia strona DAEMON Tools dystrybuowała backdoora
16. Kod źródłowy robaka Shai-Hulud został opublikowany na GitHubie
17. Robak PCPJack usuwa złośliwe oprogramowanie grupy TeamPCP
18. AI w atakach – od eksperymentów do zastosowań na większą skalę
19. Fałszywe wsparcie IT w Microsoft Teams otwiera drogę dla ModeloRAT-a
20. FrostyNeighbor wrócił z nową kampanią przeciw ukraińskim instytucjom

Dziękujemy wszystkim, którzy dzielą się z nami znalezionymi w sieci ciekawymi artykułami. Linki możecie przesyłać na adres biuro (at) zaufanatrzeciastrona.pl – są szanse, że trafią do kolejnego wydania Weekendowej Lektury. Możecie też dołączyć do naszego serwera na Discordzie i zostawiać swoje znaleziska na kanale „newsy”: discord.gg/zaufana

W dzisiejszym wydaniu szczególnie polecamy w części fabularnej artykuł o operacji Hellfire, w ramach której CBZC zatrzymało 123 podejrzanych o przestępczość pedofilską (pkt 1) oraz materiał pokazujący, jak rosyjskie służby wykorzystały mafijną przykrywkę, by przejąć Zondacrypto (pkt 3-4). W części technicznej spójrzcie na analizę wieloetapowej kampanii złośliwego oprogramowania z wykorzystaniem techniki SEO poisoning i infrastruktury serverless (pkt 1), poczytajcie też o atakach na łańcuch dostaw z użyciem robaka Mini Shai-Hulud (pkt 10-13). Życzymy udanej lektury.

Wersja anglojęzyczna

IT Security Weekend Catch Up – May 8, 2026

Część bardziej fabularna

1. [PL] Operacja Hellfire: Zatrzymano 123 podejrzanych o przestępczość pedofilską
2. [PL] Poza horyzont peryskopu: strategiczne oblicze cyberwojny APT
3. [PL] Czy rosyjskie służby użyły mafijnej przykrywki, by przejąć Zondacrypto?
4. [PL] Zondacrypto, kremlowskie służby i polska afera podsłuchowa
5. [PL] Tajny wydział prestiżowej uczelni szkoli nowe pokolenie oficerów dla GRU
6. [PL] Narzędzia dezinformacji. Trzy zestawy do mieszania w głowach
7. [PL] Jak masowa inwigilacja nie chroni dzieci
8. [PL] UOKiK może nakładać kary na podstawie podsłuchów
9. [PL] NIS2: Wymogi w zakresie reakcji na podatności
10. [PL] Uwaga na sprytne próby podszycia się pod mObywatela
11. [PL][WIDEO] Atak z użyciem kodu Morse’a, który umożliwił kradzież środków
12. [PL][WIDEO] Gdy wektorami ataku stają się ci, którzy mieli nas przed nimi bronić
13. Sprzedawca exploitów odda byłym pracodawcom mniej, niż chciała prokuratura
14. Analiza rosyjsko-irańskich powiązań cybernetycznych w sektorze prywatnym
15. Jak Rosja pomaga USA promować separatystyczne narracje w Kanadzie
16. Chatbot AI firmy Anthropic powiela rosyjską i irańską propagandę
17. Chrome po cichu instaluje model AI na urządzeniach użytkowników

Część bardziej techniczna

1. [PL] Wieloetapowa kampania złośliwego oprogramowania z użyciem SEO poisoning i infrastruktury serverless
2. Dirty Frag, czyli lokalne podniesienie uprawnień do roota na Linuksie
3. Krytyczna luka w zaporach Palo Alto grozi zdalnym przejęciem roota
4. Cisco łata błąd, przez który urządzenia trzeba ręcznie restartować
5. Błąd w Apache HTTP/2 otwiera drogę do awarii i zdalnego wykonania kodu
6. ConsentFix v3 automatyzuje przejęcia kont Azure bez kradzieży haseł
7. Wieloetapowy atak phishingowy prowadzący do przejęcia kont Microsoftu
8. Kampania phishingowa Venomous#Helper z użyciem dwóch narzędzi RMM
9. Ewolucja kampanii ClickFix wymierzonej w użytkowników macOS-a
10. Mini Shai-Hulud: atak za pośrednictwem 4 oficjalnych pakietów SAP w npm
11. Mini Shai-Hulud w pakietach intercom-client w npm oraz lightning w PyPI
12. Mini Shai-Hulud rozszerzył kampanię na nowe środowisko, czyli Packagist
13. Ataki na łańcuch dostaw z użyciem Mini Shai-Huluda przypisane TeamPCP
14. W jaki sposób CallPhantom oszukuje użytkowników Androida
15. TCLBanker rozprzestrzenia się za pośrednictwem WhatsAppa i Outlooka
16. Złośliwa wtyczka do frameworka OpenClaw dystrybuowała Remcos RAT-a
17. Kampania InstallFix z wykorzystaniem fałszywych stron Claude Code
18. Quasar Linux (QLNX) po cichu okrada deweloperów i środowiska DevOps
19. Ukryty skrypt i legalne narzędzia wspierają wdrażanie stealera Vidar
20. Nowy sposób dystrybucji NWHStealera utrudnia jego wykrycie
21. Północnokoreańska grupa ScarCruft szpieguje za pośrednictwem gier
22. Jak UAT-8302 zapewniał sobie trwały dostęp do sieci instytucji publicznych
23. Kampania GriefLure z użyciem cudzych materiałów, by podnieść wiarygodność

Dziękujemy wszystkim, którzy dzielą się z nami znalezionymi w sieci ciekawymi artykułami. Linki możecie przesyłać na adres biuro (at) zaufanatrzeciastrona.pl – są szanse, że trafią do kolejnego wydania Weekendowej Lektury. Możecie też dołączyć do naszego serwera na Discordzie i zostawiać swoje znaleziska na kanale „newsy”: discord.gg/zaufana

W dzisiejszym wydaniu szczególnie polecamy w części fabularnej artykuł o tym, jak agent AI, pracując nad poprawką, usunął produkcyjną bazę danych PocketOS (pkt 10) oraz materiał o brazylijskiej firmie mającej chronić przed DDoS, która sama realizowała takie ataki (pkt 16). W części technicznej spójrzcie na Copy Fail, świeżo ujawnioną lukę w jądrze Linuksa, która umożliwia lokalną eskalację uprawnień do roota (pkt 3-4), rzućcie też okiem na fast16, złośliwy framework do sabotażu przemysłowego, prawdopodobnie starszy od Stuxnetu (pkt 20). Życzymy udanej lektury.

Wersja anglojęzyczna

IT Security Weekend Catch Up – May 1, 2026

Część bardziej fabularna

1. [PL] Fałszywe wiadomości od „kuriera DPD”. Sprawdź, jak nie dać się oszukać
2. [PL] Jak oszuści wykorzystują AI do tworzenia fałszywych sklepów w internecie
3. [PL] mSzyfr nie jest polskim rozwiązaniem. Rządowy komunikator od środka
4. [PL] Unijna aplikacja do weryfikacji wieku. Czemu wzbudza kontrowersje?
5. [PL][WIDEO] Kreml kontra internet: blokada Telegrama i wojna z VPN-ami
6. [PL][WIDEO] Czy CIA stoi za darknetem? Kulisy łączności wywiadów
7. [PL] Bzdury, siatki kont i fałszywe flagi. Wnioski z Węgier dla wyborów w Polsce
8. [PL] Czy naruszenia „sprzed RODO” należy oceniać zgodnie z RODO?
9. [PL] Jak według NIS2 powinny wyglądać zgłaszanie i obsługa incydentów
10. Agent AI, pracując nad poprawką, usunął produkcyjną bazę danych PocketOS
11. Popularne rozszerzenia do Chrome legalnie handlują danymi milionów osób
12. Wyciek danych z Vimeo po incydencie u partnera analitycznego Anodot
13. Kary za naruszenie prywatności w USA przekroczyły 3,4 mld dolarów
14. Turcja kolejnym krajem z zakazem używania social mediów przez dzieci
15. Dziesiątki pirackich serwisów przestały działać wskutek tajemniczej awarii
16. Brazylijska firma mająca chronić przed DDoS sama realizowała takie ataki
17. Albańskie organy ścigania zlikwidowały siatkę oszustw inwestycyjnych
18. Nalot na centra oszustw w Dubaju, zatrzymano co najmniej 276 osób

Część bardziej techniczna

1. [PL][WIDEO] Nie/banalne C2: gdy zwykłe protokoły robią niezwykłe rzeczy
2. [PL] Jak Snake Keylogger kradnie hasła i dane kart płatniczych z przeglądarek
3. [PL] Copy Fail (CVE-2026-31431): 732 bajty do przejęcia kontroli nad systemem
4. Więcej szczegółów technicznych dot. podatności Copy Fail w jądrze Linuksa
5. Pack2TheRoot (CVE-2026-41651), czyli jeszcze jedna warta uwagi luka w Linuksie
6. Podatność w Firefoksie umożliwiała śledzenie użytkowników Tora
7. Złośliwe aktualizacje pakietu pgserve z npm rozpowszechniały infostealera
8. MSBuild jako narzędzie LOLBins – ułatwia wykonanie kodu i omijanie detekcji
9. Badacze udostępnili darmowy dekryptor do ransomware’u The Gentlemen
10. Ransomware VECT 2.0 bezpowrotnie kasuje pliki większe niż 128 KB
11. Nowy Vidar działa etapami i uruchamia kod bez zapisywania go na dysku
12. Vidar nowym królem rynku infostealerów – droga na szczyt (PDF)
13. Honeypot postawiony na Jenkinsie ujawnił botnet atakujący serwery gier online
14. Przestępcy łączą stare techniki ataku z narzędziami do kradzieży kryptowalut
15. Fałszywa CAPTCHA i weryfikacja za pomocą SMS-a używane w jednym oszustwie
16. Morpheus – nowa, tańsza alternatywa dla kosztownych narzędzi do inwigilacji
17. Rzut oka na Saiga 2FA – mało znany, ale wyrafinowany zestaw do phishingu
18. Kompleksowa analiza tylnej furtki Deep#Door napisanej w Pythonie
19. Zapora Cisco w amerykańskiej agencji zainfekowana backdoorem Firestarter
20. fast16 – złośliwy framework do sabotażu przemysłowego starszy od Stuxnetu
21. BlueNoroff używa fałszywych spotkań na Zoomie w atakach na sektor Web3
22. Glitter Carp i Sequin Carp, czyli jak Chiny atakują dziennikarzy i aktywistów

Dziękujemy wszystkim, którzy dzielą się z nami znalezionymi w sieci ciekawymi artykułami. Linki możecie przesyłać na adres biuro (at) zaufanatrzeciastrona.pl – są szanse, że trafią do kolejnego wydania Weekendowej Lektury. Możecie też dołączyć do naszego serwera na Discordzie i zostawiać swoje znaleziska na kanale „newsy”: discord.gg/zaufana

W dzisiejszym wydaniu szczególnie polecamy w części fabularnej artykuł o wroku NSA, z którego wynika, że sam numer telefonu – bez dodatkowych informacji – nie jest daną osobową (pkt 3), sprawdźcie też, dlaczego państwa UE porzucają usługi Microsoftu i czy Polska zamierza do nich dołączyć (pkt 6). W części technicznej poczytajcie o dystrybucji strojanizowanego oprogramowania RMM z użyciem modeli AI (pkt 1), spójrzcie na analizę dwóch kampanii inwigilacyjnych z użyciem infrastruktury operatorów komórkowych (pkt 20) i rzućcie okiem na ekosystem operacji wpływu powiązany z irańskim MOIS (pkt 22). Życzymy udanej lektury.

Wersja anglojęzyczna

IT Security Weekend Catch Up – April 25, 2026

Część bardziej fabularna

1. [PL][WIDEO] Jak nie usuwać kont użytkowników
2. [PL] Podszywają się pod ZUS i okradają Polaków. Wystarczy jeden SMS
3. [PL] Według NSA numer telefonu bez innych danych nie podlega ochronie RODO
4. [PL] NIS2: Podstawowe obowiązki podmiotów kluczowych i ważnych
5. [PL] NIS2: Odpowiedzialność kierownika podmiotu kluczowego i ważnego
6. [PL] Państwa UE porzucają Microsoft. Mają sześć powodów. Czy Polska dołączy?
7. [PL][AUDIO] Mroczny lord Palantira. Peter Thiel i jego wpływy
8. [PL][WIDEO] OSINT kontra tajne źródła – co jest ważniejsze w pracy wywiadu?
9. Brytyjski wywiad: Ponad 100 krajów zakupiło oprogramowanie szpiegujące
10. Na Ukrainie zlikwidowano farmę botów tworzącą fałszywe konta na Telegramie
11. W Hiszpanii zamknięto piracką stronę TuMangaOnline i aresztowano 4 osoby
12. Atakujący podmienili stronę Seiko i twierdzą, że ukradli dane klientów
13. Nieznani sprawcy uzyskali dostęp do zamkniętego modelu Claude Mythos
14. Meta rozbudowuje nadzór nad pracownikami w celu trenowania AI
15. NIST nie będzie oceniał luk niekrytycznych ze względu na ich rosnącą liczbę

Część bardziej techniczna

1. [PL] Dystrybucja strojanizowanego oprogramowania RMM z użyciem modeli AI
2. Kwartalne aktualizacje zabezpieczeń Oracle naprawiają 481 podatności
3. Botnet Mirai atakuje stare, wycofane z użytku routery D-Linka
4. Phishing z użyciem kodów QR ewoluuje w kierunku form utrudniających analizę
5. Fałszywa strona TradingClaw rozpowszechnia infostealera Needle
6. Narzędzia Nightmare-Eclipse wykorzystane w realnym włamaniu
7. Złośliwy kod z fałszywych zadań rekrutacyjnych uderza w łańcuch dostaw
8. Bitwarden CLI objęty atakiem na łańcuch dostaw powiązanym z Checkmarx
9. Skaner Bissa łączy exploitację na dużą skalę z selekcją wartych uwagi ofiar
10. Nowa wersja NGate ukryta w fałszywej aplikacji do płatności NFC
11. Przejęte instancje Bomgar RMM służą do wdrożeń ransomware’u
12. Analiza aktywności The Gentlemen, nowej grupy ransomware-as-a-service
13. W ataku na wenezuelską spółkę z branży energetycznej użyto wipera Lotus
14. Adware CloverPlus i Gh0st RAT w jednej kampanii złośliwego oprogramowania
15. PureRAT – wieloetapowy, bezplikowy trojan zdalnego dostępu
16. Kampania ClickFix na macOS porzuca Terminal i przechodzi na AppleScript
17. Natywne funkcje macOS-a stają się cichym kanałem ruchu bocznego
18. Fałszywy instalator Foxita wdraża ukryty dostęp VNC do systemu
19. Grupa UNC1069 atakuje za pośrednictwem fałszywych spotkań online
20. Kampanie inwigilacyjne z użyciem infrastruktury operatorów komórkowych
21. Jak UNC6692 wdraża niestandardowy pakiet złośliwego oprogramowania SNOW
22. Rzut oka na ekosystem operacji wpływu powiązany z irańskim MOIS
23. Mustang Panda rozszerza działania na banki w Indiach i dyplomatów z Korei
24. Cursor i ChatGPT pomagają grupie Lazarus zautomatyzować ataki
25. Chińska grupa GopherWhisper używa legalnych usług do szpiegostwa

Dziękujemy wszystkim, którzy dzielą się z nami znalezionymi w sieci ciekawymi artykułami. Linki możecie przesyłać na adres biuro (at) zaufanatrzeciastrona.pl – są szanse, że trafią do kolejnego wydania Weekendowej Lektury. Możecie też dołączyć do naszego serwera na Discordzie i zostawiać swoje znaleziska na kanale „newsy”: discord.gg/zaufana

W dzisiejszym wydaniu szczególnie polecamy w części fabularnej drugi odcinek retro-podcastu Informatyka Zakładowego (pkt 1) oraz opowieść o grupie Conti, która zmieniła cyberataki w wielki biznes online (pkt 8). W części technicznej spójrzcie na nowy mechanizm bezpieczeństwa w Chrome, który wiąże sesję z komputerem, by skradzione ciasteczka nie działały (pkt 7), sprawdźcie też raport Citizen Lab dotyczący systemu Webloc, który mapuje ruch ludzi na całym świecie (pkt 14). Życzymy udanej lektury.

Wersja anglojęzyczna

IT Security Weekend Catch Up – April 17, 2026

Część bardziej fabularna

1. [PL][AUDIO] Drugi odcinek retro-podcastu Informatyka Zakładowego
2. [PL][AUDIO] Raport o sztucznej inteligencji: Jak użyto głosu znanego lektora
3. [PL] Prawo do bycia zapomnianym w erze AI to iluzja czy realna ochrona?
4. [PL][AUDIO] Ban Telegrama w Rosji, cyfrowa suwerenność i MAXimum kontroli
5. [PL] Spowiedź platform społecznościowych. Czy na pewno szczera?
6. [PL] Fałszywe reklamy na Facebooku dają oszustom coraz większe zyski
7. [PL] Muły, wybieraki i fałszywi policjanci – CBZC zatrzymało grupę oszustów
8. [WIDEO] Kulisy grupy Conti, która zmieniła cyberataki w wielki biznes online
9. Grupa ShinyHunters upubliczniła dane wykradzione z Rockstar Games
10. Booking.com ostrzega klientów o możliwym wycieku danych rezerwacji
11. FBI i indonezyjska policja unieszkodliwiły usługę phishingową W3LL
12. Organy ścigania zajęły 53 domeny powiązane z usługami DDoS na zlecenie
13. Rosyjscy hakerzy włamali się do skrzynek mailowych ukraińskich prokuratorów
14. Jak Kreml wykorzystał wyjazd zachodnich influencerów w operacji wpływu
15. Pushpaganda używała AI i 113 domen do zatruwania kanałów Google Discover
16. Redakcje blokują Internet Archive, nie chcą trenowania AI na ich treściach

Część bardziej techniczna

1. [PL][WIDEO] Jak pliki MAP mogą ujawnić kod źródłowy
2. [PL] Podsumowanie CERT Polska dot. zagrożeń w marcu 2026
3. W kwietniu Microsoft załatał 164 luki, w tym dwie typu 0-day
4. Analiza krytycznej podatności w telnetd, obecnej w kodzie od 32 lat
5. Stara luka w Apache ActiveMQ pozwalała na zdalne wykonanie kodu
6. MCPwn – krytyczna luka w Nginx otwierająca drogę do przejęcia serwera
7. Google wiąże sesję z komputerem, by skradzione ciasteczka nie działały
8. Ponad 100 rozszerzeń z Chrome Web Store kradło dane uwierzytelniające
9. Kupiono 30 wtyczek do WordPressa i po cichu ukryto w nich tylną furtkę
10. Końcówki domen najczęściej wykorzystywane do oszustw w 2025 r.
11. Oszuści podszywają się pod Claude i wdrażają złośliwy kod
12. HasAIbeenPwned – baza danych o atakach na różne modele AI
13. Jak Predator przejmuje iPhone’a dzięki dostępowi do jądra systemu
14. Penlink sprzedaje system Webloc, który mapuje ruch ludzi na całym świecie
15. Węgierskie służby po cichu wdrożyły Webloc do masowego śledzenia ludzi
16. APT37 atakuje przez Messengera i Telegrama, kusząc fałszywymi dokumentami
17. Botnet Masjesu infekuje routery i kamery, stawiając na działanie w ukryciu
18. Ponad 1250 serwerów C2 działających u 165 rosyjskich dostawców
19. ZionSiphon celuje w systemy uzdatniania i odsalania wody w Izraelu
20. Północnokoreańska grupa Sapphire Sleet atakuje systemy macOS

Dziękujemy wszystkim, którzy dzielą się z nami znalezionymi w sieci ciekawymi artykułami. Linki możecie przesyłać na adres biuro (at) zaufanatrzeciastrona.pl – są szanse, że trafią do kolejnego wydania Weekendowej Lektury. Możecie też dołączyć do naszego serwera na Discordzie i zostawiać swoje znaleziska na kanale „newsy”: discord.gg/zaufana