Laboratorium 5

Zadanie opiera się na treściach Wykładu 2 (Podstawy ochrony, warunki poufności i integralności), Wykładu 3 (Podpisy cyfrowe i funkcje skrótu) oraz Wykładu 6 (Trendy rozwoju i zabezpieczenia sprzętowe). Ćwiczenie weryfikuje kierunkowe efekty uczenia się: W1 (dogłębna znajomość kryptoanalizy boczno-kanałowej, ataków czasowych oraz anomalii mikroarchitektonicznych), W4 (architektura sprzętowych modułów bezpieczeństwa HSM oraz specyfikacja interfejsu PKCS#11), U1 (implementacja statystycznego exploita w języku Python z wykorzystaniem testu t-Studenta Welcha), U2 (konfiguracja magazynu SoftHSM2 oraz integracja silnika OpenSSL PKCS#11), U3 (analiza ryzyka CVSS v4.0 z uwzględnieniem podatności implementacyjnych), U4 (inżynieria reguł detekcyjnych Sigma w systemach SIEM) oraz K2 (krytyczna ocena podatności kodu kryptograficznego na wycieki informacji). Wymagania normatywne obejmują standardy NIST FIPS 198-1 (The Keyed-Hash Message Authentication Code), OASIS PKCS #11 Cryptographic Token Interface v2.40, klasyfikację CWE-208 (Observable Timing Discrepancy) oraz techniki matrycy MITRE ATT&CK: T1110.002 i T1190.

Nadrzędnym celem zadania jest zbadanie mechanizmów boczno-kanałowych ataków czasowych (Side-Channel Timing Attacks) na procedury weryfikacji podpisów HMAC w systemach powiadomień transakcyjnych Webhook. Zespół studentów analizuje statystyczne odchylenia czasu odpowiedzi serwera wynikające z zastosowania niestawoczasowych funkcji porównywania buforów pamięci. W fazie ofensywnej studenci konstruują w języku Python wielowątkowy exploit statystyczny odzyskujący kolejne bajty podpisu kryptograficznego na podstawie testu t-Studenta Welcha. Ćwiczenie pozwala zrozumieć, że nawet ułamek mikrosekundy różnicy w czasie wykonania instrukcji może doprowadzić do całkowitego przełamania autentyczności transakcji.

W części defensywnej celem jest wdrożenie stałoczasowego algorytmu porównywania skrótów kryptograficznych oraz izolacja klucza symetrycznego wewnątrz modułu SoftHSM2 z interfejsem PKCS#11. Studenci konfigurują bezpieczny token z atrybutem uniemożliwiającym ekstrakcję materiału kluczowego z pamięci RAM serwera. Końcowym etapem jest opracowanie reguły Sigma dla systemu SIEM wykrywającej zmasowane serie zapytań o charakterystycznym rozkładzie czasowym.

Krajowy Integrator Płatności „PolPay Enterprise” obsługuje powiadomienia transakcyjne (Webhooki) przesyłane pomiędzy bramkami płatności a sklepami internetowymi. Każde żądanie HTTP zawiera nagłówek X-Signature-HMAC wyliczany z treści komunikatu przy użyciu tajnego klucza symetrycznego. W trakcie audytu bezpieczeństwa stwierdzono, że mikrousługa weryfikacji podpisów korzysta ze standardowej bibliotecznej funkcji porównującej ciągi znaków znak po znaku i przerywającej działanie przy pierwszym błędnym bajcie.

Taki sposób implementacji wprowadza mierzalny wyciek informacji w kanale bocznym: czas odpowiedzi serwera rośnie proporcjonalnie do liczby poprawnie odgadniętych bajtów początkowych sygnatury. Wykorzystując dużą liczbę zapytań sondujących oraz aparat statystyczny (Welch's t-test), atakujący jest w stanie odfiltrować szum sieciowy i odtworzyć prawidłowy podpis bez znajomości tajnego klucza HMAC. Sfałszowany komunikat pozwala na nieautoryzowaną zmianę statusu zamówienia na opłacone.

Zespół studentów wciela się w rolę inżynierów Purple Team. W pierwszej fazie studenci uruchamiają demonstracyjny exploit mierzący opóźnienia z dokładnością nanosekundową i demonstrują odgadnięcie prefiksu podpisu HMAC-SHA256. W fazie obronnej usuwają lukę w kodzie serwera, zastępując podatne porównanie bezpieczną funkcją stałoczasową hmac.compare_digest, której czas wykonania jest całkowicie niezależny od zawartości danych wejściowych.

Aby zabezpieczyć sam klucz symetryczny przed kradzieżą w przypadku przejęcia serwera aplikacyjnego, studenci integrują mechanizm podpisu z tokenem SoftHSM2. Klucz zostaje utworzony bezpośrednio wewnątrz kryptograficznego magazynu PKCS#11 z flagami CKA_EXTRACTABLE=FALSE oraz CKA_SENSITIVE=TRUE, dzięki czemu nie pojawia się w zrzutach pamięci RAM. Na koniec zespół Blue Team tworzy regułę Sigma korelującą anomalny wzrost liczby żądań z jednego adresu IP w oknie 5 sekund.

• Python 3 (moduły numpy, scipy, cryptography): środowisko obliczeniowe do analizy statystycznej i estymacji opóźnień czasowych.
• SoftHSM2: programowy emulator sprzętowego modułu bezpieczeństwa zgodny ze standardem PKCS#11.
• OpenSC (pkcs11-tool): pakiet narzędziowy do zarządzania obiektami kryptograficznymi w tokenach PKCS#11.
• GDB / Valgrind: narzędzia diagnostyczne do inspekcji pamięci RAM procesu weryfikującego podpisy.
• Nginx / Apache HTTP Server: serwer WWW pośredniczący w przekazywaniu webhooków z rejestracją logów dostępu.
• Rsyslog i Auditd: demony telemetrii systemowej do przesyłania zdarzeń do reguł korelacyjnych Sigma.

1. Zbuduj środowisko badawcze w systemie Linux z pakietami python3-numpy, python3-scipy, softhsm2 i opensc.
2. Zaimplementuj podatną mikrousługę weryfikacji powiadomień Webhook porównującą sygnatury pętlą znak po znaku.
3. Napisz skrypt w języku Python wysyłający serię zapytań sondujących z precyzyjnym pomiarem czasu odpowiedzi.
4. Zastosuj test statystyczny Welcha (Welch's t-test) do porównania rozkładów czasowych dla różnych kandydatów na pierwszy bajt.
5. Wskaż statystycznie istotny przyrost średniego czasu odpowiedzi dla prawidłowej wartości pierwszego bajtu podpisu.
6. Zautomatyzuj proces iteracyjnego odgadywania kolejnych bajtów pełnego skrótu HMAC-SHA256 bez znajomości klucza.
7. Przeprowadź refaktoryzację kodu serwera: wdróż funkcję stałoczasową hmac.compare_digest.
8. Powtórz pomiary statystyczne dla utwardzonego kodu i wykaż całkowity zanik korelacji czasowej.
9. Zainicjalizuj nowy slot tokenu SoftHSM2 z etykietą Webhook-HMAC-Token za pomocą narzędzia softhsm2-util.
10. Zdefiniuj bezpieczne kody SO-PIN oraz User-PIN zabezpieczające magazyn kryptograficzny.
11. Wygeneruj 256-bitowy klucz symetryczny wewnątrz tokenu z atrybutami CKA_EXTRACTABLE=FALSE i CKA_SENSITIVE=TRUE.
12. Zweryfikuj listę obiektów w tokenie poleceniem pkcs11-tool --list-objects i potwierdź brak możliwości eksportu klucza.
13. Skonfiguruj usługę podpisującą do wykonywania operacji HMAC za pośrednictwem biblioteki PKCS#11.
14. Wykonaj zrzut pamięci RAM procesu podpisującego za pomocą narzędzia gcore i potwierdź brak obecności surowego klucza.
15. Opracuj regułę detekcji Sigma monitorującą logi serwera WWW pod kątem zmasowanych zapytań sondujących sygnaturę.
16. Wykonaj analizę wektora ryzyka CVSS v4.0 uwzględniającą spadek punktacji po wdrożeniu porównań stałoczasowych.
17. Sporządź kompleksowy raport techniczny dokumentujący matematyczny model ataku oraz konfigurację modułu HSM.

Ataki czasowe na weryfikację skrótów kryptograficznych (HMAC Timing Attacks) wynikają ze sposobu działania standardowych funkcji porównujących łańcuchy bajtów (np. memcmp w C lub operator == w wielu językach wyższego poziomu). Funkcje te optymalizują wykonanie, przerywając porównanie przy pierwszym napotkanym znaku różniącym oba ciągi. W rezultacie zapytanie z poprawnym pierwszym bajtem wykonuje się o kilkadziesiąt do kilkuset nanosekund dłużej niż zapytanie z błędnym pierwszym bajtem.

W warunkach sieciowych opóźnienia podlegają zakłóceniom losowym (jitter). Aby wyekstrahować sygnał z szumu, konieczne jest zastosowanie metod statystycznych, takich jak test t-Studenta dla dwóch niezależnych prób o różnych wariancjach (Welch's t-test). Analiza rozkładu median lub średnich z kilkunastu tysięcy pomiarów dla każdego kandydata pozwala bezbłędnie wytypować właściwy bajt.

Skuteczną obroną przed atakiem czasowym jest zastosowanie algorytmów stałoczasowych (Constant-Time). W języku Python służy do tego funkcja hmac.compare_digest, która zawsze przetwarza wszystkie bajty wejściowe, sumując różnice bitowe operatorem bitowym OR. Dodatkowo klucze kryptograficzne powinny być izolowane sprzętowo w modułach HSM (lub emulatorze SoftHSM2) z restrykcją CKA_EXTRACTABLE=FALSE.

Poniżej przedstawiono implementację exploita statystycznego w Pythonie, poprawkę defensywną, polecenia SoftHSM2 oraz regułę Sigma.

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Matematyczne i statystyczne podstawy ataków czasowych: wykorzystanie wczesnego wyjścia w naiwnych porównaniach łańcuchów.
2. Statystyczna weryfikacja hipotez (test t-Studenta) do odgadywania kolejnych bajtów sygnatury HMAC-SHA256 w warunkach szumu sieciowego.
3. Implementacja operacji w stałym czasie (Constant-Time String Comparison) w celu eliminacji wycieków czasowych kanału bocznego.
4. Izolacja symetrycznego klucza podpisującego w sprzętowym module bezpieczeństwa HSM (SoftHSM2 / PKCS#11).
5. Opracowanie reguł Sigma dla serwerów WWW: korelacja tysięcy żądań z identycznym początkiem sygnatury i kodem błędu HTTP 401.
6. Zgodność ze standardami bezpiecznych webhooków rekomendowanymi przez PCI DSS v4.0 oraz OWASP API Security.

Przykładowe wnioski (wzór do sprawozdania): Praktyczna konstrukcja statystycznego exploita czasowego wykazała, że naiwne porównanie sygnatury HMAC operatorem podwójnego znaku równości pozwala na odzyskanie pełnego 32-bajtowego skrótu webhooka bez znajomości klucza tajnego. Zastosowanie testu t-Studenta umożliwiło wyodrębnienie różnic czasowych rzędu kilkunastu nanosekund pomiędzy błędnymi a trafnymi bajtami na poszczególnych pozycjach podpisu. Zastąpienie podatnego kodu funkcją porównującą ciągi w ściśle stałym czasie definitywnie zneutralizowało ten wektor ataku, eliminując wszelkie korelacje czasowe. Dodatkowe zabezpieczenie symetrycznego sekretu integracyjnego wewnątrz modułu SoftHSM2 uniemożliwiło jego bezpośrednią kradzież w przypadku kompromitacji pamięci procesu. Wdrożona reguła detekcyjna Sigma pozwala analitykom SOC na natychmiastowe wykrycie anomalnych serii żądań sondujących nagłówek X-Signature-HMAC.

Zadanie opiera się na treściach Wykładu 3 (Algorytmy asymetryczne i łańcuchy PKI) oraz Wykładu 4 (Autoryzacja, uwierzytelnianie dwuskładnikowe i standardy FIDO). Ćwiczenie weryfikuje efekty uczenia się: W4 (dogłębna znajomość łańcuchów certyfikacji X.509, formatu CBOR oraz specyfikacji FIDO Metadata Service MDS3), U1 (implementacja weryfikatora atestacji w języku Python), U2 (parsowanie struktur kryptograficznych WebAuthn), U3 (analiza ryzyka podszycia pod sprzęt transakcyjny wg CVSS v4.0), U4 (inżynieria reguł detekcyjnych w systemie Suricata NIDS) oraz K1 (odpowiedzialność inżynierska za bezpieczeństwo tożsamości cyfrowej w bankowości). Zagadnienia normatywne obejmują specyfikację FIDO Alliance Metadata Service v3.0, standard W3C Web Authentication Level 2, Rekomendację KNF dotyczącą zarządzania ryzykiem technologicznym w bankach, klasyfikację CWE-295 oraz techniki matrycy MITRE ATT&CK: T1556 i T1588.004.

Głównym celem zadania jest zbadanie kryptograficznej procedury atestacji sprzętowej w protokole FIDO2 / WebAuthn oraz kryptoanaliza wektora fałszowania certyfikacji przez programowe emulatory tokenów. Zespół studentów analizuje strukturę formatu CBOR oraz zawartość oświadczeń atestacyjnych (Attestation Statements) przekazywanych podczas rejestracji klucza bezpieczeństwa. W części ofensywnej studenci implementują w języku Python skrypt generujący sfałszowany pakiet atestacji udający certyfikowane urządzenie FIPS Level 3. Ćwiczenie uświadamia krytyczną różnicę pomiędzy deklaratywnym identyfikatorem AAGUID a matematycznie zweryfikowanym łańcuchem zaufania.

W części defensywnej celem jest zaprojektowanie i wdrożenie weryfikatora atestacji sprzętowej zintegrowanego z oficjalną bazą FIDO Alliance Metadata Service (MDS3 BLOB). Studenci implementują algorytm sprawdzający certyfikat pośredni X.509 tokena względem certyfikatów nadrzędnych akredytowanych producentów. Końcowym etapem jest opracowanie dedykowanej sygnatury sieciowej dla systemu NIDS Suricata monitorującej anomalie w strukturze komunikatów rejestracyjnych.

Polski Bank Rozwoju Cyfrowego wdraża obsługę fizycznych kluczy FIDO2 / WebAuthn do autoryzacji transakcji o wysokim wolumenie finansowym. Zgodnie z wytycznymi regulatora rynku finansowego oraz rekomendacjami KNF, do systemu mogą być dołączane wyłącznie certyfikowane tokeny sprzętowe posiadające odporność na ataki fizyczne (poziom FIDO Level 2+ / FIPS 140-2 Level 3). Pierwotna wersja oprogramowania serwerowego weryfikowała jedynie poprawność podpisu asymetrycznego, ignorując weryfikację łańcucha atestacji X.509.

Taka luka pozwala cyberprzestępcom na użycie programowego emulatora klucza FIDO2 uruchomionego na zainfekowanej stacji roboczej klienta. Emulator generuje standardową parę kluczy kryptograficznych i wstawia do nagłówka fałszywy identyfikator AAGUID odpowiadający renomowanemu tokenowi sprzętowemu. Bez weryfikacji podpisu oświadczenia atestacyjnego serwer bankowy błędnie klasyfikuje klucz programowy jako bezpieczny moduł sprzętowy, co umożliwia malware kradzież materiału klucza prywatnego.

Zespół inżynierów Purple Team przygotowuje środowisko weryfikacyjne. Studenci tworzą skrypt Rogue Authenticator, który generuje samopodpisany certyfikat atestacyjny i symuluje rejestrację nieautoryzowanego urządzenia. Następnie analizują strukturę danych weryfikacyjnych i wskazują błędy w logice walidacji bankowego interfejsu API.

W fazie obronnej studenci implementują moduł weryfikacyjny odpytujący kryptograficznie podpisany rejestr FIDO MDS3. Weryfikator sprawdza, czy certyfikat atestacyjny urządzenia wywodzi się bezpośrednio z certyfikatu Root CA producenta wskazanego w bazie metadanych. Równolegle inżynierowie konfigurują sensor Suricata NIDS, który analizuje ruch HTTP i natychmiast generuje alert w przypadku wykrycia nieznanych lub podrobionych wartości AAGUID.

• Python 3 (moduły cryptography, cbor2, requests): biblioteki do dekodowania formatu CBOR i weryfikacji łańcuchów X.509.
• Suricata NIDS 7.0+: system inspekcji ruchu sieciowego analizujący nagłówki i treści komunikatów HTTP.
• OpenSSL CLI: narzędzie do parsowania i walidacji certyfikatów atestacyjnych oraz sprawdzania rozszerzeń OID.
• Wireshark / TShark: analizator protokołów z dekoderem komunikatów uwierzytelniania WebAuthn.
• Curl / Postman: narzędzia do wysyłania spreparowanych żądań rejestracyjnych do interfejsu API.
• Rsyslog: usługa systemowa do gromadzenia logów serwera weryfikacji tożsamości.

1. Zbuduj środowisko robocze z pakietami python3-cryptography, python3-cbor2 oraz demonem Suricata NIDS.
2. Przeanalizuj specyfikację standardu W3C WebAuthn Level 2 dotyczącą struktury oświadczenia atestacyjnego attStmt.
3. Napisz skrypt w języku Python generujący samopodpisany certyfikat CA udający akredytowanego producenta tokenów.
4. Spreparuj fałszywy pakiet rejestracyjny WebAuthn zawierający identyfikator AAGUID renomowanego klucza sprzętowego.
5. Przetestuj podatną funkcję rejestracji w bankowym API i wykaż, że bez weryfikacji MDS3 pakiet zostaje zaakceptowany.
6. Pobierz i zbadaj strukturę podpisanego kryptograficznie pliku metadanych FIDO Alliance Metadata Service v3 (MDS3 BLOB).
7. Wyodrębnij certyfikat Root CA FIDO Alliance i zweryfikuj podpis cyfrowy całego rejestru metadanych.
8. Zaimplementuj w języku Python weryfikator atestacji sprawdzający zgodność zgłoszonego AAGUID z wpisem w bazie MDS3.
9. Zaimplementuj procedurę budowy i weryfikacji ścieżki certyfikacji od certyfikatu tokena do zaufanego Root CA producenta.
10. Uruchom test weryfikatora dla sfałszowanego pakietu i potwierdź jego natychmiastowe odrzucenie z kodem błędu.
11. Przetestuj działanie weryfikatora z poprawnym certyfikatem atestacyjnym pobranym z fizycznego klucza laboratoryjnego.
12. Zbadaj rozszerzenia X.509 specyficzne dla FIDO (np. OID 1.3.6.1.4.1.45724.1.1.4 kodujący AAGUID).
13. Opracuj sygnaturę sieciową Suricata NIDS wykrywającą obecność podejrzanych identyfikatorów AAGUID w żądaniach rejestracji.
14. Skonfiguruj regułę Suricata do inspekcji zdeszyfrowanego ruchu HTTPS przekazywanego przez lokalny reverse proxy.
15. Wywołaj rejestrację sfałszowanego urządzenia i zweryfikuj wygenerowanie alertu w pliku fast.log sensora Suricata.
16. Oceń wektor podatności zgodnie z metodyką CVSS v4.0 z uwzględnieniem skutków dla bankowości internetowej.
17. Przygotuj raport inżynierski prezentujący schemat łańcucha zaufania MDS3 oraz listingi weryfikatora.

Standard FIDO2/WebAuthn wprowadza silne uwierzytelnianie oparte na kryptografii asymetrycznej. Podczas rejestracji token generuje nową parę kluczy dla danej domeny (Relying Party), a klucz publiczny przesyła w strukturze attestationObject zakodowanej w formacie CBOR (Concise Binary Object Representation). W strukturze tej zawarte jest oświadczenie atestacyjne (attStmt), które zawiera certyfikat X.509 podpisany kluczem wstrzykniętym w fabryce producenta (Attestation Root of Trust).

Deklaratywne pole AAGUID (Authenticator Attestation Globally Unique Identifier) ma postać 16-bajtowego identyfikatora modelu urządzenia. Pole to może zostać sfałszowane przez jakikolwiek programowy emulator klucza. Z tego względu aplikacje bankowe nie mogą polegać na samym identyfikatorze AAGUID, lecz muszą dokonać pełnej walidacji kryptograficznej dołączonego certyfikatu atestacyjnego.

Organizacja FIDO Alliance prowadzi centralną usługę metadanych FIDO Metadata Service (MDS3). Udostępnia ona kryptograficznie podpisany plik JSON (MDS3 BLOB), zawierający listę certyfikowanych modeli urządzeń wraz z ich certyfikatami Root CA, poziomami certyfikacji FIPS oraz ewentualnymi ostrzeżeniami o kompromitacji (Revocation/Compromise Status). Prawidłowa weryfikacja polega na sprawdzeniu, czy certyfikat z pakietu rejestracyjnego tworzy poprawny łańcuch do Root CA wskazanego w MDS3.

Poniżej przedstawiono listing generowania sfałszowanego pakietu atestacji, implementację weryfikatora MDS3 w Pythonie oraz sygnaturę sieciową Suricata NIDS.

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Architektura atestacji FIDO2/WebAuthn: certyfikaty atestacyjne X.509 i formaty packed, tpm oraz android-key.
2. Zagrożenie ze strony emulowanych w oprogramowaniu fałszywych tokenów USB przy braku rygorystycznej weryfikacji łańcucha atestacji.
3. Integracja z usługą FIDO Metadata Service (MDS3): pobieranie bazy BLOB zaufanych modeli kluczy sprzętowych i ich statusów.
4. Weryfikacja poziomu bezpieczeństwa tokena (FIDO Level 2+ / FIPS 140-3) dla bankowych transakcji wysokiego ryzyka.
5. Inżynieria sygnatur Suricata: inspekcja ładunków JSON protokołu WebAuthn pod kątem formatów attestationObject typu none.
6. Spełnienie wytycznych Komisji Nadzoru Finansowego w zakresie uwierzytelniania transakcji o wysokim wolumenie finansowym.

Przykładowe wnioski (wzór do sprawozdania): Kryptoanaliza procedury rejestracji tokenów WebAuthn w portalu bankowym ujawniła, że brak weryfikacji oświadczenia atestacyjnego pozwala na zarejestrowanie podatnego, programowego emulatora klucza udającego bezpieczny token sprzętowy. Zbudowanie dedykowanego weryfikatora certyfikatów atestacyjnych powiązanego z bazą FIDO MDS3 umożliwiło wymuszenie wyłącznie certyfikowanych urządzeń o poziomie bezpieczeństwa FIDO Level 2+. System weryfikuje pełen łańcuch X.509 wystawcy tokena i odrzuca klucze o nieznanym identyfikatorze AAGUID lub ze statusem unieważnienia w rejestrze MDS. W warstwie sieciowej zaimplementowano sygnaturę Suricata, która alarmuje o próbach przesłania pustej atestacji typu none w transakcjach korporacyjnych. Opracowany mechanizm stanowi wzorcowe zabezpieczenie bankowości elektronicznej przed atakami z użyciem skompromitowanych lub podrobionych kluczy uwierzytelniających.

Zadanie opiera się na treściach Wykładu 1 (Zagrożenia dla systemów teleinformatycznych i mechanizmy wyścigu) oraz Wykładu 4 (Autoryzacja transakcji i sieciowe systemy bazodanowe). Ćwiczenie weryfikuje efekty uczenia się: W1 (podatności współbieżności, zjawisko split-brain i wyścigi TOCTOU w architekturach mikrousługowych), U1 (implementacja algorytmu rozproszonej blokady Redlock w języku Python), U2 (konstrukcja wielowątkowego exploita gniazdowego z synchronizacją mikrosekundową), U3 (analiza ryzyka strat płynnościowych wg CVSS v4.0), U4 (inżynieria reguł detekcyjnych Sigma w systemach monitoringu) oraz K2 (krytyczne podejście do pozornych gwarancji poziomów izolacji baz danych). Zagadnienia teoretyczne i normatywne obejmują twierdzenie CAP, model ACID, zalecenia NIST SP 800-95, klasyfikację CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization), CWE-367 (Time-of-Check to Time-of-Use) oraz techniki matrycy MITRE ATT&CK: T1190 i T1059.

Głównym celem zadania jest zbadanie mechanizmów ataków wyścigowych (Race Conditions) oraz podwójnego wydatkowania (Double Spending) w wielowątkowych architekturach mikrousług finansowych. Zespół studentów analizuje błędy typu TOCTOU (Time-of-Check to Time-of-Use) występujące pomiędzy sprawdzeniem dostępnego salda a zapisem operacji debetowej. W fazie ofensywnej studenci implementują wielowątkowy exploit gniazdowy w języku Python, który synchronizuje pakiety z dokładnością do mikrosekund w celu wielokrotnego pobrania środków z pojedynczego salda. Ćwiczenie uświadamia ograniczenia standardowych transakcji SQL w środowiskach wielokontenerowych.

W części defensywnej celem jest zaprojektowanie i wdrożenie odpornego na błędy klastrowe algorytmu rozproszonej blokady wzajemnej Redlock w środowisku Redis. Studenci implementują mechanizm kworum większościowego, kompensację dryfu zegara oraz losowe tokeny walidacyjne zwalniające blokadę. Końcowym etapem jest konstrukcja reguły Sigma dla systemu SIEM wykrywającej nienaturalne zagęszczenie transakcji debetowych dla pojedynczego rachunku.

Giełda Kryptowalut i Złota Cyfrowego „KryptoVistula” przetwarza natychmiastowe wypłaty środków fiat i kryptowalut za pośrednictwem klastra skalowalnych mikrousług w chmurze. W trakcie audytu bezpieczeństwa zidentyfikowano lukę architektoniczną w procedurze zatwierdzania wypłat: mikrousługa odczytywała saldo konta z relacyjnej bazy danych na poziomie izolacji Read Committed, po czym zlecała transfer zewnętrzny przed fizycznym zaktualizowaniem rekordu.

Taka konstrukcja tworzy okno wyścigu (Race Window) o szerokości kilkunastu milisekund. Atakujący, wysyłając w tym samym momencie dziesiątki równoległych żądań HTTP za pośrednictwem zsynchronizowanych wątków gniazdowych, doprowadza do sytuacji, w której wszystkie żądania widzą początkowe dodatnie saldo. W rezultacie serwer zatwierdza wielokrotne wypłaty, doprowadzając do powstania ujemnego salda i wielotysięcznych strat finansowych giełdy.

Zespół Purple Team przeprowadza kontrolowaną demonstrację podatności. Studenci budują skrypt exploita w Pythonie, który przy użyciu bariery wątkowej (threading.Barrier) uwalnia jednocześnie 10 żądań wypłaty na kwotę równą całemu saldu, doprowadzając do zrealizowania wielokrotnego wydatkowania. W kolejnym kroku zespół analizuje dlaczego lokalne blokady procesowe nie chronią przed wyścigiem w środowisku rozproszonym.

Faza defensywna polega na wdrożeniu rozproszonego algorytmu Redlock opartego na klastrze węzłów Redis. Algorytm wymusza uzyskanie blokady w większości instancji w czasie krótszym niż ważność klucza (TTL), co zapobiega rozbieżnościom w przypadku awarii węzła. Następnie inżynierowie Blue Team konfigurują regułę Sigma, która analizuje strumień zdarzeń i alarmuje zespół SOC w przypadku wykrycia więcej niż 3 transakcji debetowych dla danego konta w czasie poniżej 50 milisekund.

• Python 3 (moduły threading, socket, redis): środowisko do implementacji exploita wyścigowego i algorytmu blokad.
• Redis Server / Cluster: baza danych in-memory używana jako rozproszony magazyn blokad wzajemnych.
• Wireshark / TShark: analizator sieciowy do inspekcji mikrosekundowych różnic w dostarczaniu pakietów TCP.
• Postman / Curl: narzędzia do generowania równoległych żądań transakcyjnych HTTP REST.
• Rsyslog i Fluentd: demony telemetrii logów przesyłające rekordy transakcyjne do silnika detekcji.
• Hping3: generator pakietów do testowania zachowania stosu sieciowego pod obciążeniem impulsowym.

1. Zbuduj środowisko badawcze z serwerem Redis oraz aplikacją symulującą portfel finansowy.
2. Zaimplementuj w języku Python podatną procedurę wypłaty środków z celowo wprowadzonym opóźnieniem TOCTOU.
3. Napisz skrypt exploita wielowątkowego wykorzystujący obiekt threading.Barrier do idealnej synchronizacji żądań.
4. Uruchom atak wyścigowy z 10 wątkami na konto o saldzie 1000 PLN z kwotą wypłaty 1000 PLN.
5. Zarejestruj liczbę zatwierdzonych wypłat i wykaż powstanie błędu podwójnego wydatkowania (Double Spending).
6. Przeanalizuj w zrzucie sieciowym Wiresharka moment dotarcia poszczególnych pakietów do gniazda serwera.
7. Zbadaj, dlaczego lokalne mechanizmy blokowania (threading.Lock) zawodzą w architekturze wieloprocesowej.
8. Zaimplementuj klasę rozproszonej blokady Redlock z obsługą losowych unikalnych tokenów wartości blokady.
9. Skonfiguruj parametry czasowe blokady: czas ważności TTL, dryf zegara oraz maksymalny czas akwizycji.
10. Zaimplementuj bezpieczne zwalnianie blokady z wykorzystaniem skryptu Lua porównującego token atomowo.
11. Zintegruj mechanizm Redlock z funkcją wypłaty portfela i powtórz atak wyścigowy z 10 wątkami.
12. Potwierdź, że tylko dokładnie jeden wątek uzyskał blokadę, a pozostałe otrzymały odmowę wykonania operacji.
13. Zweryfikuj końcowe saldo portfela, dowodząc stuprocentowej ochrony integralności finansowej.
14. Opracuj regułę detekcji Sigma monitorującą logi pod kątem nienaturalnej serii transakcji dla tego samego konta.
15. Przetestuj regułę Sigma na logach wygenerowanych podczas ataku exploita wyścigowego.
16. Dokonaj formalnej kalkulacji wektora podatności CVSS v4.0 uwzględniającej ryzyko utraty płynności.
17. Sformułuj techniczne wnioski dotyczące wyboru algorytmów konsensusu w rozproszonych systemach płatniczych.

Ataki wyścigowe (Race Conditions) polegają na wykorzystaniu odstępu czasu pomiędzy sprawdzeniem warunku a wykonaniem powiązanej z nim operacji (podatność TOCTOU - Time-of-Check to Time-of-Use). W systemach finansowych typowy scenariusz obejmuje zapytanie: Czy saldo >= kwota? oraz następujące po nim polecenie: Zmniejsz saldo o kwotę. Gdy dwa lub więcej żądań sprawdzi stan salda zanim którekolwiek zdąży je zaktualizować, system zatwierdzi wielokrotną wypłatę tych samych środków.

Tradycyjne blokady relacyjnych baz danych (np. transakcje z klauzulą SELECT FOR UPDATE) wprowadzają znaczny narzut wydajnościowy i mogą prowadzić do zakleszczeń (Deadlocks) w architekturze mikrousług. W środowiskach rozproszonych standardem stały się blokady rozproszone oparte na pamięciowych bazach klucz-wartość, takich jak Redis.

Algorytm Redlock, zaproponowany przez twórcę systemu Redis, rozwiązuje problem pojedynczego punktu awarii instancji blokującej. Klient próbuje uzyskać blokadę sekwencyjnie w N niezależnych węzłach Redis za pomocą operacji SET resource_name my_random_value NX PX 10000. Blokada jest uznana za ważną tylko wtedy, gdy klient uzyskał ją w większości węzłów (kworum N/2 + 1) w czasie krótszym niż czas ważności blokady (TTL). Zwolnienie blokady musi być realizowane atomowym skryptem Lua, aby proces nie usunął omyłkowo blokady należącej do innego procesu, który przejął zasób po wygaśnięciu TTL.

Poniżej przedstawiono implementację exploita wyścigowego w języku Python, algorytm rozproszonej blokady Redlock oraz regułę Sigma.

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Anatomia podatności wyścigu (Race Condition / TOCTOU) w asynchronicznych mikroserwisach portfeli finansowych.
2. Konstrukcja wielowątkowego exploita generującego zbieżne żądania wypłaty (Double-Spending) w oknie mikrosekundowym.
3. Niewystarczalność izolacji transakcji bazodanowej Read Committed w systemach rozproszonych bez blokad pesymistycznych.
4. Implementacja rozproszonego algorytmu blokowania Redlock na klastrze Redis z gwarancją odporności na awarie węzłów i split-brain.
5. Zastosowanie kryptograficznych tokenów unikalności (Idempotency Keys) dla wszystkich operacji modyfikujących saldo portfela.
6. Opracowanie reguł Sigma wykrywających nienaturalną zbieżność czasową żądań autoryzacyjnych pochodzących z jednego konta użytkownika.

Przykładowe wnioski (wzór do sprawozdania): Symulacja zmasowanego ataku wyścigowego na interfejs wypłat giełdy KryptoVistula wykazała, że równoległe wysłanie dwudziestu żądań w oknie 5 milisekund pozwalało na czterokrotne podwójne wydanie tych samych środków. Przyczyną podatności był brak atomowej blokady stanu salda w architekturze mikroserwisowej operującej na poziomie izolacji Read Committed. Zaimplementowanie rozproszonego algorytmu blokowania Redlock na klastrze Redis z wymuszeniem wyłączności dostępu przed sprawdzeniem salda całkowicie wyeliminowało ten wektor nadużycia. Wprowadzenie kryptograficznych kluczy idempotencji uniemożliwiło powtórne przetworzenie zduplikowanych transakcji w kolejce komunikatów. Zespół detekcji wdrożył regułę Sigma, która w czasie rzeczywistym identyfikuje i zawiesza konta generujące mikrosekundowe serie żądań wypłaty.

Zadanie opiera się na treściach Wykładu 1 (Zagrożenia dla systemów teleinformatycznych - malware transakcyjne) oraz Wykładu 4 (Sieciowe systemy i protokoły autoryzacji). Ćwiczenie weryfikuje efekty uczenia się: W1 (dogłębna znajomość anatomii złośliwego oprogramowania typu POS RAM Scraper na wzór BlackPOS i Dexter), U1 (implementacja demonstracyjnego skanera pamięci wirtualnej w języku Python), U2 (hardening jądra Linux z wykorzystaniem modułów LSM Landlock i Yama oraz segmentacji VRF w systemie MikroTik RouterOS), U3 (analiza ryzyka wycieku danych posiadaczy kart wg CVSS v4.0), U4 (inżynieria sygnatur detekcyjnych Suricata NIDS) oraz K3 (odpowiedzialność inżynierska za zgodność ze standardami Payment Card Industry Data Security Standard PCI DSS v4.0). Normy prawne i techniczne obejmują PCI DSS v4.0 (Req. 3 i Req. 4), klasyfikację CWE-200 (Exposure of Sensitive Information) oraz techniki matrycy MITRE ATT&CK: T1005 i T1056.

Nadrzędnym celem zadania jest zbadanie mechanizmów ataku POS RAM Scraping polegającego na nieautoryzowanym odczytywaniu niezaszyfrowanych danych kart płatniczych z przestrzeni adresowej procesów kasowych. Zespół studentów analizuje strukturę danych ścieżek magnetycznych Track 1 i Track 2 oraz działanie algorytmu sprawdzającego Luhna. W fazie ofensywnej studenci implementują w języku Python demonstracyjny moduł inspekcji pamięci wirtualnej (/proc/pid/mem) ekstrahujący numery PAN w momencie przetwarzania płatności. Ćwiczenie pozwala zrozumieć zagrożenia wynikające z obecności danych w tekście jawnym w pamięci operacyjnej stacji roboczych.

W części defensywnej celem jest wdrożenie wielowarstwowej izolacji procesów w systemie Linux za pomocą modułów bezpieczeństwa jądra Landlock LSM oraz ograniczeń ptrace_scope w Yama LSM. Zespół konfiguruje reguły firewall RAW i segmentację VRF w systemie MikroTik RouterOS w celu zablokowania nieautoryzowanych kanałów eksfiltracji danych. Zadanie wieńczy opracowanie sygnatury Suricata NIDS analizującej ruch wychodzący pod kątem obecności wzorców numerów kart płatniczych.

Ogólnopolska sieć handlowa „PolskaDystrybucja” zarządza infrastrukturą kilkuset hipermarketów wyposażonych w tysiące terminali kasowych POS z systemem Linux. Podczas operacji audytowej klasy Red Team specjaliści uzyskali dostęp do stacji kasowej i zasymulowali działanie znanego złośliwego oprogramowania (np. BlackPOS, Alina, Dexter), które przeszukuje pamięć RAM procesów kasowych w celu przechwycenia danych kart zanim zostaną one zaszyfrowane i wysłane do centrum autoryzacyjnego.

Proces kasowy podczas odczytu karty z czytnika przechowuje w pamięci bufor zawierający pełny numer PAN oraz datę ważności. Skaner pamięci pracujący w tle otwiera deskryptor /proc/pid/mem docelowego procesu, skanuje mapowane segmenty sterty wyrażeniami regularnymi dopasowującymi 16-cyfrowe ciągi, weryfikuje sumę kontrolną algorytmem Luhna i natychmiast przesyła przechwycone rekordy do serwera dowodzenia C2.

Studenci wcielają się w rolę inżynierów Purple Team. Najpierw uruchamiają demonstracyjny proces symulatora kasy POS oraz skrypt scrapera w Pythonie, potwierdzając możliwość wyciągnięcia numeru karty bezpośrednio z pamięci operacyjnej. Następnie przystępują do twardego zabezpieczenia stacji roboczej: konfigurują restrykcję jądra kernel.yama.ptrace_scope = 3, co całkowicie uniemożliwia podglądanie pamięci innych procesów nawet przez użytkowników uprzywilejowanych.

W kolejnym kroku inżynierowie zabezpieczają warstwę sieciową. Na routerze brzegowym MikroTik RouterOS izolują podsieć terminali kasowych w dedykowanej wirtualnej tablicy routingu VRF oraz wdrażają reguły w tabeli RAW odrzucające jakikolwiek bezpośredni ruch do niezaufanych domen. Na styku sieci uruchamiają sensor Suricata NIDS z sygnaturą inspekcji wzorców PAN, która natychmiast alarmuje o próbie nieszyfrowanej transmisji danych posiadaczy kart, zapewniając pełną zgodność z normą PCI DSS v4.0.

• Python 3 (moduły re, os, sys): środowisko do budowy symulatora kasy i skanera pamięci wirtualnej RAM.
• Moduł jądra Linux Yama LSM / Landlock: mechanizmy kontroli dostępu ograniczające uprawnienia debugowania ptrace.
• MikroTik RouterOS v7.x: system routera brzegowego do konfiguracji segmentacji VRF i reguł RAW firewall.
• Suricata NIDS 7.0+: system detekcji intruzów analizujący ruch wychodzący pod kątem wycieku numerów kart.
• GDB / Valgrind: narzędzia diagnostyczne do inspekcji map pamięci procesu (/proc/pid/maps).
• Auditd: demon audytu jądra rejestrujący próby odwołania do procedur ptrace i odczytu pamięci.

1. Zbuduj środowisko badawcze składające się ze stacji roboczej Linux oraz routera MikroTik RouterOS v7.x.
2. Zaimplementuj w języku Python proces symulatora kasy POS alokujący bufor z danymi karty płatniczej.
3. Uruchom proces kasy w tle i pobierz jego unikalny identyfikator procesu PID.
4. Przeanalizuj mapę pamięci wirtualnej procesu w pliku /proc/pid/maps, identyfikując segmenty czytelne sterty.
5. Zaimplementuj w języku Python funkcję sprawdzającą sumę kontrolną algorytmem Luhna (mod-10).
6. Napisz moduł skanujący pamięć procesu poprzez deskryptor /proc/pid/mem z filtrem wyrażeń regularnych dla kart Visa i Mastercard.
7. Uruchom skrypt scrapera pamięci i potwierdź skuteczną ekstrakcję pełnego 16-cyfrowego numeru PAN.
8. Przeanalizuj zagrożenia wynikające z ataku w świetle wymogów standardu PCI DSS v4.0 (Req. 3.4).
9. Wdróż twarde ograniczenie jądra Linux poprzez dyrektywę sysctl: kernel.yama.ptrace_scope = 3.
10. Powtórz próbę odczytu pamięci scraperem i potwierdź zgłoszenie błędu odmowy dostępu PermissionError.
11. Zabezpiecz proces kasowy z wykorzystaniem mechanizmu jądra Landlock LSM, ograniczając dostęp do systemu plików.
12. Skonfiguruj na routerze MikroTik RouterOS izolowaną tablicę routingu VRF o nazwie CDE-POS-VRF.
13. Wdróż reguły zapory w tabeli /ip firewall raw blokujące nieszyfrowaną komunikację wychodzącą ze strefy kas.
14. Opracuj sygnaturę sieciową Suricata NIDS wykrywającą obecność 16-cyfrowych numerów kart w protokołach tekstowych.
15. Przetestuj działanie sensora Suricata, symulując próbę wysłania numeru karty otwartym kanałem TCP.
16. Oceń wektor ryzyka zgodnie z metodyką CVSS v4.0 uwzględniając wymogi ochrony środowiska CDE.
17. Sporządź sprawozdanie inżynierskie podsumowujące mechanizmy ochrony pamięci RAM oraz segmentacji sieciowej.

Ataki typu POS RAM Scraping (rozsławione przez incydenty w sieciach Target i Home Depot) polegają na przeszukiwaniu przestrzeni adresowej procesów kasowych w poszukiwaniu danych kart płatniczych w momencie ich przetwarzania w tekście jawnym. Nawet jeśli transmisja sieciowa i bazy danych są w pełni zaszyfrowane, czytnik kart przekazuje dane do pamięci RAM aplikacji kasowej w celu przygotowania żądania autoryzacyjnego. Złośliwe oprogramowanie skanuje segmenty pamięci sterty (/proc/pid/mem), dopasowując wzorce ścieżek magnetycznych Track 1 i Track 2.

Wzorce ścieżek magnetycznych zawierają numer PAN (Primary Account Number), datę ważności oraz kody usługowe. Aby uniknąć przesyłania fałszywych trafień, malware stosuje algorytm sumy kontrolnej Luhna (mod-10), który weryfikuje poprawność cyfry kontrolnej numeru karty. Wykrycie prawidłowego numeru PAN skutkuje natychmiastowym zapisaniem rekordu i próbą jego eksfiltracji.

Obrona przed atakiem wymaga podejścia wielowarstwowego (Defense-in-Depth). Na poziomie systemu operacyjnego Linux kluczowe jest włączenie modułu bezpieczeństwa Yama LSM poprzez parametr jądra kernel.yama.ptrace_scope = 3. Wartość ta całkowicie blokuje możliwość dołączania debuggerów (ptrace) oraz odczytu /proc/pid/mem przez jakikolwiek proces inny niż rodzic, unieszkodliwiając scrapery pamięci. Na poziomie sieciowym standard PCI DSS v4.0 wymaga ścisłej izolacji środowiska danych posiadaczy kart (Cardholder Data Environment - CDE) za pomocą technologii VRF oraz filtracji pakietowej.

Poniżej przedstawiono implementację symulatora kasy, skanera pamięci w Pythonie, konfigurację jądra Yama LSM, reguły RouterOS VRF oraz sygnaturę Suricata.

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Wektory działania złośliwego oprogramowania typu RAM Scraper: odczyt przestrzeni pamięci procesów kasowych przez interfejsy systemowe.
2. Ekstrakcja danych paska magnetycznego (Track 1 / Track 2) oraz numerów PAN za pomocą wyrażeń regularnych algorytmu Luhna.
3. Wdrożenie modułu bezpieczeństwa jądra Linux Landlock LSM do nałożenia bezwzględnego piaskowania na proces aplikacji kasowej POS.
4. Wykorzystanie sond eBPF LSM do blokowania wywołań systemowych ptrace i odczytu pamięci dla procesów spoza białej listy.
5. Konfiguracja sygnatur IDS Suricata do inspekcji niezaszyfrowanego ruchu sieciowego terminala kasowego pod kątem wzorców kart.
6. Spełnienie wymogu 3.3 i 5.2 normy PCI DSS v4.0 w zakresie aktywnej ochrony danych posiadaczy kart w pamięci operacyjnej stacji kasowych.

Przykładowe wnioski (wzór do sprawozdania): Symulacja działania malware'u klasy RAM Scraper na terminalu kasowym Linux dowiodła, że niechroniony proces kasy pozwala na bezproblemowe przechwycenie pełnych danych Track 2 kart płatniczych w momencie ich przetwarzania w pamięci RAM. Napastnik wykorzystujący uprawnienia lokalnego użytkownika wyekstrahował numery PAN bezpośrednio z pliku wirtualnego w katalogu proc za pomocą skryptu przeszukującego pamięć wyrażeniem regularnym Luhna. Zastosowanie modułu jądra Landlock LSM całkowicie odcięło aplikację kasową od możliwości interakcji z innymi procesami oraz zablokowało dostęp do wrażliwych struktur systemu plików. Równolegle wdrożono filtr eBPF blokujący próby dołączania debuggera do procesu kasy, co natychmiast udaremniło próby zrzutu pamięci operacyjnej. W warstwie sieciowej skonfigurowano regułę Suricata, która natychmiast alarmuje o próbach eksfiltracji nieszyfrowanych ciągów kartowych, zapewniając pełną zgodność z normą PCI DSS v4.0.

Zadanie opiera się na treściach Wykładu 3 (Architektura PKI i protokoły bezpieczne), Wykładu 4 (Uwierzytelnianie w bankowości elektronicznej i dyrektywa PSD2) oraz Wykładu 6 (Standardy protokołów TLS 1.3 i DANE). Ćwiczenie weryfikuje efekty uczenia się: W4 (dogłębna znajomość specyfikacji certyfikatów QWAC i QSEAL pod dyrektywą PSD2, protokołu DANE RFC 6698 oraz standardu DNSSEC), U1 (konfiguracja dwukierunkowego uwierzytelniania mTLS w serwerze Nginx i bibliotece OpenSSL), U2 (zarządzanie strefami DNSSEC i generowanie rekordów TLSA), U3 (analiza wektora ryzyka ataku Rogue Intermediate CA wg CVSS v4.0), U4 (konstrukcja sygnatur sieciowych Suricata NIDS) oraz K1 (odpowiedzialność inżynierska za zaufanie w międzybankowych interfejsach API). Zagadnienia normatywne obejmują dyrektywę PSD2 / RTS, standard ETSI TS 119 495, specyfikację RFC 8446 (TLS 1.3), RFC 6698 (DANE), klasyfikację CWE-295 oraz techniki matrycy MITRE ATT&CK: T1557 i T1588.004.

Nadrzędnym celem zadania jest zbadanie podatności interfejsów bankowości otwartej (Open Banking API) na ataki pośrednika Man-in-the-Middle wykorzystujące sfałszowane certyfikaty TPP pochodzące ze skompromitowanych podrzędnych urzędów certyfikacji (Rogue Intermediate CA). Zespół studentów analizuje proces wzajemnego uwierzytelniania kryptograficznego w standardzie mTLS (Mutual TLS) narzucanym przez dyrektywę PSD2. W fazie ofensywnej studenci symulują podszycie się pod licencjonowanego dostawcę usług płatniczych za pomocą certyfikatu podpisanego przez nieautoryzowany urząd CA. Ćwiczenie ugruntowuje wiedzę o ograniczeniach tradycyjnego modelu weryfikacji opartego wyłącznie na magazynie certyfikatów X.509.

W części defensywnej celem jest wdrożenie mechanizmu twardego powiązania tożsamości kryptograficznej z domeną za pomocą protokołu DANE (RFC 6698) z walidacją w łańcuchu DNSSEC. Studenci konfigurują serwer API do sprawdzania skrótu klucza publicznego SPKI przed zatwierdzeniem uścisku dłoni TLS 1.3. Zadanie kończy się opracowaniem sygnatury Suricata NIDS wykrywającej próby użycia nieautoryzowanych wystawców w nagłówkach certyfikatów klienckich.

Bank Spółdzielczy „VistulaBank” udostępnia interfejsy API Open Banking umożliwiające autoryzowanym podmiotom trzecim (Third Party Providers - TPP) inicjowanie płatności w imieniu klientów. Komunikacja wymaga zestawienia kanału mTLS zabezpieczonego kwalifikowanymi certyfikatami stron internetowych QWAC zgodnymi z normą ETSI TS 119 495. Zgodnie z analizą ryzyka, kompromitacja jednego z wielu komercyjnych urzędów CA w Europie mogłaby pozwolić na wystawienie fałszywego certyfikatu QWAC dla dowolnego TPP.

Dysponując certyfikatem wystawionym przez Rogue Intermediate CA, adwersarz zajmujący pozycję pośrednika w sieci telekomunikacyjnej mógłby skutecznie uwierzytelnić się w bramie API banku jako legalny dostawca płatności i zainicjować nieautoryzowany transfer środków. Aby całkowicie uniezależnić się od ryzyka błędów ludzkich i kompromitacji zagranicznych urzędów CA, bank decyduje się na wdrożenie standardu DANE powiązanego z kryptograficznym podpisem strefy DNSSEC.

Studenci wcielają się w rolę inżynierów Purple Team. W pierwszej fazie generują certyfikat podszywający się pod TPP za pośrednictwem lokalnego sfałszowanego urzędu CA i wykazują, że brama API akceptuje połączenie, jeśli Root CA znajduje się w magazynie zaufania. W fazie obronnej zespół konfiguruje strefę DNSSEC i publikuje rekord TLSA wskazujący jednoznaczny hash SPKI prawdziwego klucza publicznego certyfikowanego dostawcy.

Wdrożony mechanizm walidacji DANE powoduje, że klient posługujący się certyfikatem z obcego CA zostaje natychmiast odrzucony na etapie negocjacji TLS, pomimo ważnego podpisu matematycznego. Dodatkowo inżynierowie Blue Team wdrażają regułę Suricata NIDS, która inspectuje pakiety Certificate w uścisku dłoni TLS i natychmiast alarmuje SOC o pojawieniu się nieznanych wystawców, gwarantując pełną zgodność z normami bankowymi.

• Bind9 / Unbound: serwer DNS z obsługą podpisywania stref DNSSEC oraz publikacji rekordów TLSA.
• Nginx / OpenSSL 3.x: serwer WWW skonfigurowany pod kątem dwukierunkowej weryfikacji mTLS w protokole TLS 1.3.
• Delv / Dig: narzędzia diagnostyczne do inspekcji rekordów DNSSEC oraz walidacji łańcucha kryptograficznego.
• Suricata NIDS 7.0+: system wykrywania intruzów analizujący nagłówki uścisku dłoni TLS w czasie rzeczywistym.
• Python 3 (moduł cryptography): środowisko do generowania certyfikatów X.509 z dedykowanymi rozszerzeniami PSD2.
• Wireshark / TShark: analizator sieciowy do weryfikacji wymiany certyfikatów w warstwie transportowej.

1. Zbuduj środowisko badawcze z serwerem Nginx, demonem DNS Bind9 oraz stacją roboczą TPP.
2. Wygeneruj oficjalny certyfikat QWAC dla legalnego dostawcy TPP za pomocą biblioteki OpenSSL.
3. Skonfiguruj dwukierunkowe uwierzytelnianie mTLS w serwerze Nginx z dyrektywą ssl_verify_client on.
4. Nawiąż połączenie testowe narzędziem curl z poprawnym certyfikatem i potwierdź dostęp do API.
5. Zasymuluj kompromitację: utwórz sfałszowany urząd Rogue CA i wystaw fałszywy certyfikat dla tej samej domeny TPP.
6. Dodaj Rogue CA do systemowego magazynu zaufania i wykaż pomyślne nawiązanie sesji przez adwersarza (udany atak).
7. Skonfiguruj podpisanie strefy domenowej tpp.local mechanizmami DNSSEC z kluczami KSK i ZSK.
8. Wyodrębnij klucz publiczny w formacie SPKI z autoryzowanego certyfikatu TPP za pomocą polecenia openssl pkey.
9. Oblicz skrót SHA-256 klucza SPKI i utwórz rekord TLSA 3 1 1 w pliku strefy DNS serwera Bind9.
10. Przeładuj konfigurację serwera DNS i zweryfikuj poprawność rekordu TLSA poleceniem delv.
11. Zintegruj w bramie API procedurę walidacji DANE sprawdzającą hash SPKI przed autoryzacją żądania.
12. Ponów próbę połączenia z certyfikatem Rogue CA i potwierdź jego natychmiastowe zablokowanie błędem weryfikacji DANE.
13. Opracuj sygnaturę Suricata NIDS wykrywającą niezatwierdzone certyfikaty klienckie w ruchu TLS.
14. Skonfiguruj sensor Suricata do monitorowania ruchu sieciowego na porcie interfejsu Open Banking.
15. Przetestuj działanie sygnatury Suricata, wywołując alert o próbie podszycia się pod certyfikowanego partnera.
16. Oceń wektor podatności według standardu CVSS v4.0 z uwzględnieniem krytycznych skutków dla sektora bankowego.
17. Sporządź raport inżynierski dokumentujący architekturę obrony DANE/DNSSEC oraz listingi konfiguracyjne.

Wzajemne uwierzytelnianie TLS (Mutual TLS - mTLS) stanowi fundament bezpieczeństwa interfejsów bankowości otwartej w ramach unijnej dyrektywy PSD2. W odróżnieniu od standardowego HTTPS, w mTLS obie strony uścisku dłoni wymieniają się i weryfikują certyfikaty X.509. Certyfikaty QWAC (Qualified Website Authentication Certificates) zawierają rozszerzenia ETSI określające numer rejestracyjny instytucji finansowej, rolę TPP (np. PSP_AI, PSP_PI) oraz nazwę właściwego organu nadzoru (np. KNF).

Podstawową słabością modelu PKI jest zależność od globalnego ekosystemu zaufania. Jeśli brama bankowa ufa wszystkim akredytowanym w UE urzędom certyfikacji, kompromitacja dowolnego z nich umożliwia wygenerowanie fałszywego certyfikatu QWAC z poprawnym podpisem kryptograficznym. Taki certyfikat bez problemu przeszedłby standardową weryfikację łańcucha X.509.

Standard DANE (DNS-based Authentication of Named Entities, RFC 6698) eliminuje ten problem poprzez powiązanie certyfikatu ze strefą DNSSEC domeny. Rekord TLSA publikowany w strefie DNS TPP ma format _443._tcp.tpp.local IN TLSA 3 1 1 <sha256_spki>. Parametry 3 1 1 oznaczają: przypięcie do konkretnego podmiotu (Usage 3), ekstrakcję klucza publicznego SPKI (Selector 1) oraz porównanie skrótu SHA-256 (Matching Type 1). Bank weryfikuje, czy odcisk klucza w certyfikacie klienta odpowiada podpisanej kryptograficznie wartości w rekordzie TLSA, neutralizując ataki Rogue CA.

Poniżej przedstawiono procedurę ekstrakcji SPKI, wpis w strefie Bind9, walidację delv oraz sygnaturę Suricata NIDS.

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Analiza podatności kanałów Open Banking na ataki Man-in-the-Middle w przypadku błędów walidacji kwalifikowanych certyfikatów QWAC.
2. Weryfikacja unikalnych rozszerzeń certyfikatów PSD2: identyfikator autoryzacji TPP oraz role podmiotu (AISP, PISP, CBPII).
3. Wymuszenie protokołu TLS 1.3 z kryptografią na krzywych eliptycznych w celu eliminacji podatności na ataki renegocjacji.
4. Integracja protokołu DANE z rekordami TLSA w strefie DNS zabezpieczonej DNSSEC w celu związania certyfikatu banku z domeną.
5. Opracowanie reguł Suricata analizujących certyfikaty przesyłane w trakcie handshake mTLS pod kątem obecności nieautoryzowanych wystawców CA.
6. Spełnienie wymogów dyrektywy PSD2 oraz standardu PolishAPI w zakresie bezpiecznej autoryzacji podmiotów trzecich w bankowości otwartej.

Przykładowe wnioski (wzór do sprawozdania): Eksperymentalny atak Man-in-the-Middle na interfejs Open Banking wykazał, że niedokładna weryfikacja certyfikatów QWAC pozwala fałszywemu dostawcy TPP na zainicjowanie nieautoryzowanego przelewu w imieniu klienta banku. Napastnik posługujący się certyfikatem z komercyjnego urzędu CA ominął wstępne filtry proxy, które nie sprawdzały obecności dedykowanych rozszerzeń ról PSD2 zdefiniowanych w normie ETSI TS 119 495. Zaimplementowanie ścisłej weryfikacji atrybutów organizacji w certyfikacie oraz wymuszenie protokołu TLS 1.3 natychmiast udaremniło ten wektor podszywania się. Dodatkowo opublikowanie rekordu TLSA w strefie chronionej podpisem DNSSEC całkowicie zabezpieczyło węzeł bankowy przed atakami podmiany certyfikatów przez wrogie proxy. Wdrożona sygnatura sieciowa w systemie Suricata gwarantuje natychmiastowe wykrycie prób nawiązania sesji mTLS z certyfikatami niespełniającymi specyfikacji PolishAPI.

Zadanie opiera się na treściach Wykładu 3 (Podpisy cyfrowe, standard XML-DSig i funkcje skrótu) oraz Wykładu 4 (Autoryzacja i integralność komunikatów bankowych). Ćwiczenie weryfikuje efekty uczenia się: W1 (dogłębna znajomość anatomii ataków XML Signature Wrapping na dokumenty finansowe ISO 20022), W3 (kanonizacja XML C14N, transformacje enwaluowane i referencje URI), U1 (implementacja exploita XSW w języku Python z użyciem biblioteki lxml), U2 (konstrukcja defensywnego walidatora schematu XSD z bezwzględnymi ścieżkami XPath), U3 (analiza ryzyka fałszowania płatności masowych wg CVSS v4.0), U4 (inżynieria reguł detekcyjnych Sigma dla filtrów WAF) oraz K1 (odpowiedzialność inżynierska za integralność rozliczeń międzybankowych). Standardy techniczne i normatywne obejmują W3C XML Signature Syntax and Processing, ISO 20022 (pain.001 Customer Credit Transfer Initiation), klasyfikację CWE-347 oraz techniki matrycy MITRE ATT&CK: T1565.001.

Nadrzędnym celem zadania jest zbadanie podatności XML Signature Wrapping (XSW) występującej w bankowych systemach przetwarzania komunikatów transakcyjnych standardu ISO 20022 (format pain.001). Zespół studentów analizuje architekturę standardu XML-DSig, ze szczególnym uwzględnieniem rozbieżności pomiędzy weryfikacją podpisu kryptograficznego a logiką biznesową parsera XML. W części ofensywnej studenci implementują w języku Python exploit manipulujący drzewem DOM dokumentu XML, który zachowuje poprawność podpisu cyfrowego przy jednoczesnej modyfikacji rachunku odbiorcy i kwoty przelewu. Ćwiczenie uświadamia konieczność ścisłego powiązania kontekstu kryptograficznego z semantyką przetwarzania danych biznesowych.

W części defensywnej celem jest zaprojektowanie i wdrożenie odpornego modułu walidacji schematu XSD oraz bezpiecznej procedury sprawdzania podpisów wykorzystującej bezwzględne ścieżki XPath i kanonizację C14N. Studenci eliminują możliwość wstrzykiwania zduplikowanych węzłów i fałszywych wrapperów wewnątrz struktury dokumentu. Końcowym etapem jest konstrukcja reguły detekcyjnej Sigma identyfikującej anomalie strukturalne w plikach przesyłanych do bramki transakcyjnej.

Korporacyjny Węzeł Rozliczeń Masowych „ElixirGateway” przetwarza pliki zleceń płatniczych przesyłane przez systemy ERP przedsiębiorstw w formacie ISO 20022 XML (pain.001.001.09). Każdy plik zawiera podpisaną cyfrowo paczkę przelewów pracowniczych i kontrahenckich. W trakcie audytu bezpieczeństwa stwierdzono, że moduł kryptograficzny weryfikuje podpis na podstawie atrybutu Id węzła wskazanego w elemencie Reference URI, natomiast silnik księgowy pobiera dane przelewu z pierwszego napotkanego węzła w głównym drzewie dokumentu.

Taki rozdźwięk logiczny umożliwia realizację ataku XML Signature Wrapping. Cyberprzestępca przechwytuje poprawnie podpisany dokument, klonuje oryginalny węzeł transakcji o identyfikatorze id=original do nieszkodliwego elementu opakowującego Wrapper, a w pierwotnym miejscu wstrzykuje sfałszowany węzeł transakcji o identyfikatorze id=fake z własnym numerem konta bankowego i zawyżoną kwotą przelewu.

Zespół Purple Team przygotowuje środowisko badawcze. Studenci piszą skrypt exploita w Pythonie z biblioteką lxml, który automatycznie modyfikuje drzewo XML i generuje zmanipulowany plik pain.001. Weryfikator kryptograficzny potwierdza, że podpis jest w pełni prawidłowy, po czym silnik biznesowy wykonuje sfałszowany przelew na konto atakującego.

W fazie defensywnej inżynierowie Blue Team wdrażają twardą politykę walidacji: wymuszają jednoznaczne schematy XSD zabraniające obecności nieznanych elementów nadrzędnych oraz modyfikują kod aplikacji, aby podpis był weryfikowany wyłącznie dla bezwzględnej ścieżki /Document/CstmrCdtTrfInitn. Całość zabezpieczenia uzupełnia reguła Sigma monitorująca logi WAF pod kątem obecności nieautoryzowanych wrapperów i powielonych identyfikatorów węzłów.

• Python 3 (moduły lxml, xmlsec, cryptography): narzędzia programistyczne do parsowania i manipulacji strukturami XML-DSig.
• XMLSec1 CLI: uniksowe narzędzie konsolowe do weryfikacji podpisów cyfrowych XML i operacji kanonizacji.
• ModSecurity / WAF: zapora aplikacji webowych do inspekcji przesyłanych ładunków XML.
• Wireshark / TShark: analizator sieciowy do inspekcji przesyłanych plików transakcyjnych ISO 20022.
• OpenSSL CLI: pakiet narzędziowy do generowania kluczy RSA i certyfikatów podpisujących XML.
• Rsyslog: demon zbierania logów systemowych i zdarzeń walidacji transakcji finansowych.

1. Zbuduj środowisko badawcze z pakietami python3-lxml, libxmlsec1-dev oraz narzędziem xmlsec1.
2. Utwórz prawidłowy plik zlecenia płatniczego ISO 20022 pain.001 zawierający dane autoryzowanego przelewu.
3. Podpisz plik XML cyfrowo za pomocą narzędzia xmlsec1 z wykorzystaniem klucza prywatnego RSA i certyfikatu X.509.
4. Zweryfikuj poprawność podpisu wygenerowanego pliku poleceniem xmlsec1 --verify.
5. Napisz skrypt w języku Python analizujący drzewo DOM podpisanego dokumentu XML.
6. Zaimplementuj w skrypcie procedurę ataku XSW: sklonuj oryginalny węzeł transakcji do elementu pomocniczego Wrapper.
7. Wstrzyknij w pierwotnej lokalizacji w drzewie DOM nowy węzeł transakcji ze sfałszowaną kwotą i numerem rachunku.
8. Zapisz zmanipulowany dokument i zweryfikuj go narzędziem xmlsec1, obserwując raport potwierdzający ważność podpisu.
9. Zasymuluj działanie podatnego procesora biznesowego i wykaż, że przetworzył on sfałszowane dane przelewu.
10. Przeanalizuj mechanizm kanonizacji C14N i zbadaj, dlaczego modyfikacja nadrzędnego drzewa nie naruszyła skrótu referencji.
11. Zaprojektuj bezpieczny schemat XSD zabraniający wprowadzania nieznanych węzłów i wielokrotnych elementów głównych.
12. Zaimplementuj bezpieczny weryfikator w języku Python sprawdzający zgodność referencji URI z bezwzględną ścieżką XPath.
13. Przetestuj zmanipulowany plik nowym weryfikatorem i potwierdź jego odrzucenie z alarmem naruszenia struktury.
14. Opracuj regułę Sigma dla systemu WAF wykrywającą obecność zduplikowanych identyfikatorów Id w plikach XML.
15. Przetestuj skuteczność reguły Sigma na próbkach zmanipulowanych i oryginalnych plików płatniczych.
16. Dokonaj kalkulacji wektora podatności CVSS v4.0 z uwzględnieniem krytycznego wpływu na integralność transakcji.
17. Sporządź raport inżynierski dokumentujący mechanizm ataku XSW oraz kod bezpiecznego weryfikatora.

Standard XML-DSig (XML Digital Signature) definiuje reguły cyfrowego podpisywania fragmentów lub całych dokumentów XML. Podpis może być otaczający (Enveloping), otoczony (Enveloped) lub odłączony (Detached). W elemencie Reference definiuje się atrybut URI (np. URI="#original"), wskazujący identyfikator podpisanego węzła. Podczas weryfikacji moduł kryptograficzny odszukuje węzeł o danym Id, dokonuje jego kanonizacji (C14N) i porównuje obliczony skrót SHA-256 z wartością w DigestValue.

Podatność XML Signature Wrapping (XSW) wynika z faktu, że standard XML-DSig weryfikuje jedynie nienaruszalność wskazanego węzła, ale nie weryfikuje jego położenia w drzewie dokumentu. Jeśli parser biznesowy aplikacji nie używa bezwzględnych zapytań XPath do lokalizacji przetwarzanych danych, lecz pobiera np. pierwszy węzeł <CstmrCdtTrfInitn>, atakujący może przemieścić podpisany węzeł w inne miejsce dokumentu (np. do spreparowanego elementu opakowującego), a w oryginalnym miejscu umieścić dane sfałszowane.

Skuteczna obrona wymaga jednoczesnego zastosowania dwóch mechanizmów: rygorystycznej walidacji schematu XSD, która odrzuca dokumenty zawierające nieprzewidziane elementy opakowujące lub zduplikowane węzły, oraz twardego powiązania weryfikatora kryptograficznego z logiką aplikacji. Aplikacja musi jawnie przekazywać do modułu biznesowego dokładnie ten sam węzeł DOM, który został pozytywnie zweryfikowany pod kątem podpisu cyfrowego.

Poniżej przedstawiono implementację exploita XSW w języku Python, procedurę weryfikacji xmlsec1 oraz regułę Sigma.

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Mechanizm ataku XML Signature Wrapping: manipulacja strukturą dokumentu XML poprzez rozdzielenie elementu podpisanego od przetwarzanego.
2. Analiza podatności parserów DOM w obsłudze komunikatów płatniczych ISO 20022 XML i podmiana docelowych rachunków bankowych.
3. Rola kanonizacji XML (C14N) w zapewnieniu powtarzalności obliczeń skrótu kryptograficznego przed weryfikacją podpisu.
4. Wdrożenie bezpiecznych wzorców weryfikacji XML: ścisłe powiązanie identyfikatora URI podpisu z węzłem dokumentu za pomocą wyrażeń XPath.
5. Opracowanie reguły Sigma dla dzienników bramy rozliczeniowej: detekcja zduplikowanych znaczników XML w pojedynczym komunikacie płatniczym.
6. Zgodność z wytycznymi bezpieczeństwa systemów rozliczeń masowych w zakresie nienaruszalności transakcji finansowych.

Przykładowe wnioski (wzór do sprawozdania): Kryptoanaliza procedury weryfikacji podpisów XML w węźle rozliczeniowym ElixirGateway ujawniła podatność parsera na zaawansowany atak XML Signature Wrapping. Napastnik sklonował podpisany blok przelewów pracowniczych i ukrył go w strukturze dokumentu, podstawiając na pierwszym miejscu sfałszowaną paczkę transakcji z własnym numerem konta. Moduł weryfikujący potwierdził matematyczną poprawność podpisu cyfrowego oryginalnego węzła, podczas gdy silnik księgowy zrealizował wypłatę na podstawie spreparowanego elementu nadrzędnego. Zaimplementowanie ścisłego wiązania identyfikatorów URI podpisu za pomocą deterministycznych wyrażeń XPath oraz rygorystycznej kanonizacji C14N całkowicie wyeliminowało ten groźny błąd logiczny. Opracowana reguła Sigma w systemie SIEM natychmiast flaguje komunikaty płatnicze zawierające zduplikowane identyfikatory transakcji, zapewniając pełną integralność rozliczeń korporacyjnych.

Zadanie opiera się na treściach Wykładu 3 (Kryptografia asymetryczna i krzywe eliptyczne) oraz Wykładu 4 (Uwierzytelnianie, podpisy cyfrowe i generatory losowe w systemach rozproszonych). Ćwiczenie weryfikuje efekty uczenia się: W2 (dogłębna znajomość arytmetyki krzywych eliptycznych NIST P-256 i secp256k1 nad ciałami skończonymi), W3 (matematyczna konstrukcja podpisu ECDSA i rola jednorazowej liczby losowej Nonce), U1 (implementacja exploita kryptoanalitycznego w języku Python), U3 (analiza ryzyka kompromitacji portfeli finansowych wg CVSS v4.0), U4 (wdrożenie standardu deterministycznego RFC 6979 oraz inżynieria reguł detekcyjnych Sigma) oraz K2 (krytyczna ocena generatorów pseudolosowych w modułach transakcyjnych). Standardy i zalecenia normatywne obejmują ANSI X9.62, RFC 6979, NIST FIPS 186-5, klasyfikację CWE-347 oraz techniki matrycy MITRE ATT&CK: T1552.004 i T1556.

Nadrzędnym celem zadania jest zbadanie matematycznych skutków kompromitacji generatora liczb pseudolosowych w operacjach podpisu cyfrowego ECDSA zabezpieczającego transakcje finansowe. Zespół studentów analizuje zjawisko powtórzenia jednorazowej wartości losowej Nonce (k) oraz jego natychmiastowe konsekwencje kryptoanalityczne. W części ofensywnej studenci implementują w języku Python skrypt matematycznego exploita, który na podstawie dwóch przechwyconych podpisów transakcyjnych o identycznej wartości składowej r odzyskuje klucz prywatny podpisującego w czasie ułamka sekundy. Ćwiczenie dowodzi, że w kryptografii na krzywych eliptycznych bezpieczeństwo klucza prywatnego zależy bezpośrednio od absolutnej entropii parametrów efemerycznych.

W części defensywnej celem jest wdrożenie specyfikacji RFC 6979 wprowadzającej deterministyczny algorytm wyliczania parametru k z użyciem funkcji HMAC-SHA256 bez odwoływania się do zewnętrznych źródeł losowości. Studenci weryfikują brak możliwości wygenerowania powtórzonego r dla różnych komunikatów oraz przeprowadzają audyt bazy danych podpisów. Zadanie kończy się opracowaniem reguły Sigma dla systemów SIEM wykrywającej duplikaty parametru r w logach transakcyjnych.

Węzeł Rozliczeń Międzybankowych „PaySwitch Central” autoryzuje przelewy natychmiastowe za pomocą podpisów cyfrowych ECDSA na krzywej secp256k1. W wyniku usterki wielowątkowego koprocesora kryptograficznego generator PRNG został zainicjalizowany identycznym stanem początkowym dla dwóch równoległych wątków podpisujących. Doprowadziło to do użycia tej samej liczby k do zatwierdzenia dwóch odrębnych komunikatów płatniczych.

Taka luka jest bezpośrednim odpowiednikiem historycznej podatności konsoli PlayStation 3 oraz błędów w wczesnych implementacjach portfeli Bitcoin. Ponieważ punkt R = k * G zależy wyłącznie od wartości k, oba podpisy otrzymują identyczną współrzędną r = R.x mod n. Każdy obserwator transmisji sieciowej widzący dwa podpisy z tym samym parametrem r zyskuje układ dwóch równań liniowych z dwoma niewiadomymi w ciele liczb pierwszych Z_n.

Zespół Purple Team przeprowadza kryptoanalizę matematyczną. Studenci budują skrypt w Pythonie, który pobiera oba podpisy, odejmuje równania stronami i oblicza wartość k z relacji k = (z1 - z2) * (s1 - s2)^(-1) mod n. Następnie podstawiają odzyskane k do wzoru i natychmiast obliczają klucz prywatny serwera d = (s1 * k - z1) * r^(-1) mod n, uzyskując pełną kontrolę nad tożsamością bankową.

W fazie obronnej inżynierowie eliminują podatność poprzez zaktualizowanie biblioteki kryptograficznej i wymuszenie standardu RFC 6979. Wartość k jest teraz derywowana deterministycznie z klucza prywatnego i hasha wiadomości, co wyklucza powtórzenie parametru k dla różnych danych. Całość zabezpieczenia dopełnia reguła Sigma przeszukująca dzienniki aplikacji i alarmująca w przypadku wykrycia jakichkolwiek zduplikowanych wartości r.

• Python 3 (moduły ecdsa, gmpy2, cryptography): środowisko obliczeniowe do arytmetyki modularnej i analizy krzywych eliptycznych.
• OpenSSL CLI: pakiet narzędziowy do weryfikacji parametrów krzywej secp256k1 i generowania par kluczy EC.
• SQLite / PostgreSQL: silnik relacyjnej bazy danych do składowania i przeszukiwania sygnatur transakcyjnych.
• Wireshark / TShark: analizator sieciowy do inspekcji nagłówków podpisów przesyłanych w protokole JSON-RPC.
• Rsyslog i Logstash: komponenty telemetrii systemowej do przesyłania zdarzeń podpisu do reguł Sigma.
• GDB: debugger procesów do inspekcji rejestrów procesora podczas generowania wartości losowej Nonce.

1. Zbuduj środowisko obliczeniowe w systemie Linux z pakietami python3-ecdsa oraz python3-gmpy2.
2. Zaimplementuj procedurę generowania kluczy na krzywej eliptycznej secp256k1 i pobierz rząd podgrupy n.
3. Przygotuj dwa odrębne komunikaty transakcyjne ISO 20022 reprezentujące zlecenia przelewu.
4. Oblicz skróty kryptograficzne SHA-256 obu wiadomości i przekształć je na liczby całkowite z1 i z2.
5. Zasymuluj usterkę generatora PRNG, przypisując stałą wartość liczby losowej k_fixed dla obu operacji podpisu.
6. Wygeneruj dwa podpisy ECDSA (r, s1) oraz (r, s2) i potwierdź, że wartość parametru r jest identyczna.
7. Napisz funkcję obliczającą odwrotność modularną przy użyciu rozszerzonego algorytmu Euklidesa.
8. Wyznacz wartość liczby losowej k z relacji k = (z1 - z2) * (s1 - s2)^(-1) mod n.
9. Odzyskaj klucz prywatny d z relacji d = (s1 * k - z1) * r^(-1) mod n.
10. Porównaj odzyskany klucz d z kluczem rzeczywistym ofiary i potwierdź stuprocentową zgodność bitową.
11. Przetestuj przypadek częściowego wycieku bitów Nonce (atak kratowy Hidden Number Problem z redukcją LLL).
12. Zaimplementuj generator deterministyczny zgodny z RFC 6979 oparty na konstrukcji HMAC-SHA256.
13. Wygeneruj serię 1000 podpisów przy użyciu RFC 6979 i potwierdź brak jakichkolwiek duplikatów parametru r.
14. Opracuj skrypt audytorski przeszukujący bazę transakcji pod kątem zduplikowanych wartości r.
15. Zdefiniuj regułę detekcji Sigma monitorującą zdarzenia weryfikacji podpisów w dziennikach aplikacji.
16. Wykonaj analizę wektora CVSS v4.0 uwzględniającą krytyczny wpływ na integralność i poufność kluczy.
17. Sformułuj techniczne wnioski dotyczące wyższości deterministycznych podpisów nad generatorami sprzętowymi PRNG.

Algorytm ECDSA (Elliptic Curve Digital Signature Algorithm) opiera się na trudności problemu logarytmu dyskretnego na krzywych eliptycznych (ECDLP). Dla danego punktu publicznego Q = d * G znalezienie klucza prywatnego d jest obliczeniowo niewykonalne. Jednak podpisanie każdej wiadomości wymaga wygenerowania ściśle tajnej, kryptograficznie losowej liczby k (Nonce). Wartość k musi być unikalna dla każdego podpisu – powtórzenie jej chociażby raz prowadzi do natychmiastowego ujawnienia klucza prywatnego.

Zjawisko to stało się przyczyną wielu historycznych incydentów bezpieczeństwa, w tym głośnego złamania zabezpieczeń konsoli Sony PlayStation 3 w 2010 roku (CVE-2011-0695). Programiści zastosowali wówczas stałą liczbę wybraną przez rzut kością zamiast prawdziwego generatora liczb pseudolosowych, co pozwoliło badaczom na wyznaczenie prywatnego klucza głównego producenta i podpisywanie dowolnego kodu nieautoryzowanego.

Odpowiedzią inżynierską na ten problem jest standard RFC 6979 (Deterministic Usage of the Digital Signature Algorithm and Elliptic Curve Digital Signature Algorithm). W standardzie tym liczba k nie jest pobierana z generatora losowego, lecz wyliczana deterministycznie z klucza prywatnego i hasha wiadomości. Gwarantuje to, że dla tej samej wiadomości powstaje ten sam podpis, a dla różnych wiadomości wartości k są całkowicie różne i nieprzewidywalne dla osób nieznających klucza prywatnego.

Poniżej przedstawiono implementację exploita kryptoanalitycznego w języku Python, porównanie z RFC 6979 oraz regułę detekcji Sigma.

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Matematyczne równania algorytmu podpisu ECDSA i relacja pomiędzy dwoma podpisami wygenerowanymi z tym samym parametrem nonce.
2. Algebraiczne odzyskanie klucza prywatnego z dwóch podpisów o identycznej wartości r za pomocą skryptu napisanego w języku Python.
3. Analiza usterki wielowątkowego generatora PRNG w węźle rozliczeń międzybankowych prowadzącej do kolizji stanu początkowego.
4. Wdrożenie deterministycznego algorytmu generowania nonce zgodnie ze standardem RFC 6979 w oparciu o funkcję HMAC.
5. Opracowanie reguły Sigma dla węzła autoryzacyjnego: monitorowanie i detekcja identycznych wartości parametru r w strumieniu transakcji.
6. Spełnienie wymogów niezaprzeczalności i poufności kluczy podpisywania transakcji finansowych zgodnie z normami ISO/IEC 14888-3.

Przykładowe wnioski (wzór do sprawozdania): Praktyczna kryptoanaliza podpisów transakcyjnych wyemitowanych przez węzeł PaySwitch potwierdziła katastrofalną podatność algorytmu ECDSA w przypadku ponownego użycia wartości nonce. Zidentyfikowanie w logach rozliczeniowych dwóch odmiennych przelewów o identycznym parametrze 'r' pozwoliło na natychmiastowe obliczenie klucza prywatnego węzła bankowego w krótkim skrypcie napisanym w języku Python. Posiadanie odzyskanego klucza tajnego umożliwiło nieautoryzowane generowanie ważnych podpisów cyfrowych dla dowolnych dyspozycji transferu środków. Wdrożenie standardu deterministycznego podpisu RFC 6979 całkowicie wyeliminowało zależność bezpieczeństwa systemu od losowości sprzętowego generatora PRNG. Równolegle zaimplementowano regułę Sigma, która w czasie rzeczywistym blokuje węzeł i alarmuje administratorów w razie wykrycia jakiejkolwiek kolizji parametru 'r' w strumieniu transakcji.

Zadanie opiera się na treściach Wykładu 2 (Szyfry blokowe, sieci Feistela i modele pseudolosowe), Wykładu 3 (Zarządzanie kluczami i sprzętowe moduły bezpieczeństwa HSM) oraz Wykładu 6 (Standardy szyfrowania zachowującego format Format-Preserving Encryption). Ćwiczenie weryfikuje efekty uczenia się: W2 (dogłębna znajomość budowy zbalansowanej sieci Feistela w algorytmach FPE wg normy NIST SP 800-38G FF1), W4 (architektura modułów HSM / PKCS#11 w ochronie kluczy nadrzędnych KEK przed zrzutami pamięci RAM), U1 (implementacja ataku słownikowego Codebook Attack na małą domenę FPE w języku Python), U2 (konfiguracja SoftHSM2 z flagą CKA_EXTRACTABLE=FALSE), U3 (analiza ryzyka PCI DSS wg CVSS v4.0), U4 (inżynieria reguł detekcyjnych Sigma dla demona auditd) oraz K3 (odpowiedzialność inżynierska za zgodność z normami tokenizacji danych kartowych). Wymagania normatywne obejmują NIST SP 800-38G, standard PCI DSS v4.0 (Req. 3.5), klasyfikację CWE-327 oraz techniki matrycy MITRE ATT&CK: T1110 i T1003.

Nadrzędnym celem zadania jest zbadanie matematycznych i architektonicznych aspektów algorytmu szyfrowania zachowującego format FPE FF1 (Format-Preserving Encryption) w środowisku przetwarzania danych kart płatniczych. Zespół studentów analizuje konstrukcję zbalansowanej sieci Feistela z funkcją rundy opartą na szyfrze AES oraz bada podatność małych domen (np. 4-cyfrowe kody PIN, przestrzeń 10^4) na ataki słownikowe (Codebook Attacks). W fazie ofensywnej studenci demonstrują możliwość stabelaryzowania przestrzeni szyfrogramów przy braku odpowiedniego wektora solenia (Tweak). Ćwiczenie uświadamia krytyczne znaczenie prawidłowego doboru parametrów kryptograficznych przy szyfrowaniu danych o stałej strukturze.

W części defensywnej celem jest wdrożenie pełnego standardu NIST SP 800-38G z unikalnym wektorem Tweak oraz zabezpieczenie klucza nadrzędnego KEK (Key Encryption Key) wewnątrz modułu SoftHSM2 z atrybutem uniemożliwiającym odczyt z pamięci RAM. Studenci przeprowadzają test odporności na zrzut pamięci RAM za pomocą narzędzia gcore. Końcowym etapem jest konstrukcja reguły Sigma dla demona auditd wykrywającej nieautoryzowane próby odczytu pamięci procesów skarbcowych.

Bankowy Skarbiec Kartowy „SecureVault S.A.” realizuje tokenizację numerów PAN oraz szyfrowanie kodów autoryzacyjnych za pomocą algorytmu FPE FF1. Zgodnie z normą PCI DSS v4.0, dane kartowe muszą być szyfrowane w spoczynku, przy czym format danych (długość 16 cyfr i prefiks bankowy BIN) musi pozostać zachowany na potrzeby systemów analitycznych. W trakcie audytu stwierdzono, że podsystem szyfrowania krótkich kodów transakcyjnych korzystał ze stałego wektora Tweak i zredukowanej liczby rund Feistela.

Taka luka pozwala adwersarzowi dysponującemu dostępem do bazy danych na przeprowadzenie ataku słownikowego (Codebook Attack). Przy małej domenie (np. 10 000 kombinacji) atakujący generuje kompletną tabelę przyporządkowania szyfrogramów do tekstów jawnych bez znajomości klucza tajnego. Dodatkowo w przypadku uzyskania uprawnień roota na serwerze skarbca, tradycyjnie przechowywany klucz KEK mógłby zostać wyekstrahowany bezpośrednio z pamięci procesu.

Zespół Purple Team przeprowadza symulację ataku. Studenci piszą skrypt w Pythonie, który tablicuje zredukowany wariant FPE na przestrzeni 10 000 wartości, udowadniając natychmiastowe odzyskanie kodów transakcyjnych. Następnie audytorzy wykonują zrzut pamięci RAM procesu szyfrującego narzędziem gcore i badają obecność kluczy w stercie.

W fazie Blue Team studenci wdrażają twarde środki zaradcze. Zwiększają liczbę rund Feistela do 10 oraz wymuszają dynamiczny, kryptograficznie losowy wektor Tweak powiązany z identyfikatorem konta klienta. Klucz KEK przenoszą do wyizolowanego slotu SoftHSM2 z flagami CKA_EXTRACTABLE=FALSE i CKA_SENSITIVE=TRUE, dzięki czemu zrzut pamięci gcore zawiera jedynie uchwyty sesyjne PKCS#11. Całość zabezpieczenia uzupełnia reguła Sigma monitorująca nieautoryzowane wywołania ptrace i gcore skierowane przeciwko procesom skarbcowym.

• Python 3 (moduły cryptography, pykcs11): biblioteki do symulacji sieci Feistela FPE oraz integracji z HSM.
• SoftHSM2: programowy emulator sprzętowego modułu bezpieczeństwa HSM zgodny ze standardem PKCS#11.
• OpenSC (pkcs11-tool): pakiet narzędziowy do zarządzania kluczami KEK i DEK w tokenach PKCS#11.
• GDB / gcore: debuggery uniksowe do wykonywania zrzutów pamięci RAM badanych procesów skarbcowych.
• Auditd i Rsyslog: demony audytu jądra rejestrujące próby dołączania ptrace i odczytu sterty.
• Strings i Hexdump: narzędzia diagnostyczne do inspekcji binarnej zrzutów pamięci operacyjnej.

1. Zbuduj środowisko robocze w systemie Linux z pakietami softhsm2, opensc, gdb oraz python3-cryptography.
2. Zaimplementuj w języku Python zredukowany model szyfrowania FPE ze stałym wektorem Tweak dla domeny 4-cyfrowej.
3. Wygeneruj bazę 10 000 zaszyfrowanych kodów transakcyjnych przy użyciu stałego klucza.
4. Napisz skrypt ataku słownikowego (Codebook Attack) tablicujący całą przestrzeń wejść i wyjść szyfru.
5. Wykaż natychmiastowe odszyfrowanie dowolnego szyfrogramu bez konieczności łamania klucza symetrycznego.
6. Przebuduj implementację FPE zgodnie ze specyfikacją NIST SP 800-38G FF1 z 10 rundami Feistela.
7. Zastosuj unikalny dla każdej karty wektor Tweak derywowany z numeru rachunku i potwierdź zniwelowanie ataku słownikowego.
8. Zainicjalizuj nowy slot SoftHSM2 z etykietą FPE-KEK-Token za pomocą narzędzia softhsm2-util.
9. Zdefiniuj kody SO-PIN oraz User-PIN zabezpieczające magazyn klucza głównego KEK.
10. Wygeneruj 256-bitowy klucz AES wewnątrz tokenu z atrybutem uniemożliwiającym ekstrakcję CKA_EXTRACTABLE=FALSE.
11. Zweryfikuj atrybuty wygenerowanego obiektu w poleceniu pkcs11-tool --list-objects.
12. Zintegruj proces szyfrowania ze slotem PKCS#11, delegując operacje szyfrowania kluczy roboczych DEK do tokenu.
13. Uruchom proces szyfrujący pod nadzorem debuggera i wykonaj zrzut pamięci RAM narzędziem gcore.
14. Przeszukaj zrzut pamięci binarnej pod kątem obecności materiału klucza KEK i potwierdź jego brak w RAM.
15. Opracuj regułę detekcji Sigma monitorującą zdarzenia audytowe auditd dotyczące użycia narzędzi ptrace i gcore.
16. Przeprowadź ocenę ryzyka według metodyki CVSS v4.0 z uwzględnieniem wymogów PCI DSS v4.0.
17. Sporządź raport inżynierski dokumentujący kryptoanalizę FPE oraz procedurę zabezpieczenia kluczy w HSM.

Szyfrowanie zachowujące format (Format-Preserving Encryption - FPE, NIST SP 800-38G) przekształca tekst jawny z określonej domeny na szyfrogram należący do dokładnie tej samej domeny. Przykładowo 16-cyfrowy numer karty płatniczej po zaszyfrowaniu pozostaje 16-cyfrowym ciągiem spełniającym reguły formatu PAN. Algorytm FF1 wykorzystuje 10-rundową sieć Feistela, w której funkcja rundy F korzysta z szyfru blokowego AES-256 oraz dodatkowego wektora solenia Tweak.

Podstawowym zagrożeniem przy stosowaniu FPE dla małych domen (np. 4-cyfrowe kody PIN, przestrzeń zaledwie 10 000 wartości) jest atak słownikowy (Codebook Attack). Jeżeli szyfr nie wykorzystuje zmiennego wektora Tweak, relacja pomiędzy tekstem jawnym a szyfrogramem jest deterministyczna. Atakujący może zaszyfrować wszystkie 10 000 kombinacji i natychmiast odczytywać dowolne zaszyfrowane dane bez znajomości klucza.

Klucz nadrzędny KEK (Key Encryption Key) chroniący klucze robocze DEK w myśl normy PCI DSS v4.0 nie może być przechowywany w postaci jawnej w systemie plików ani w pamięci operacyjnej serwera. Wykorzystanie modułu HSM (lub programowego emulatora SoftHSM2) z restrykcją CKA_EXTRACTABLE=FALSE gwarantuje, że proces aplikacji operuje wyłącznie na uchwycie do sesji PKCS#11, a sam klucz nigdy nie trafia do sterty pamięci RAM.

Poniżej przedstawiono implementację demonstracji ataku słownikowego w języku Python, konfigurację SoftHSM2 oraz regułę Sigma.

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Architektura szyfrowania zachowującego format opartego na uogólnionej sieci Feistela w standardzie NIST SP 800-38G (algorytm FF1).
2. Podatność małych domen: ryzyko ataków słownikowych i kryptoanalizy statystycznej przy szyfrowaniu krótkich danych o niskiej entropii.
3. Znaczenie kryptograficznego parametru Tweak w algorytmie FF1 jako mechanizmu różnicującego szyfrogramy dla identycznych danych wejściowych.
4. Izolacja i zarządzanie kluczem szyfrowania kluczy (KEK) wewnątrz programowego modułu bezpieczeństwa HSM (SoftHSM2 / PKCS#11).
5. Monitorowanie dostępu do modułu kryptograficznego za pomocą podsystemu auditd pod kątem prób nieautoryzowanego użycia klucza.
6. Zapewnienie pełnej zgodności z wymogami normy PCI DSS v4.0 w zakresie bezpiecznej tokenizacji numerów kart płatniczych PAN.

Przykładowe wnioski (wzór do sprawozdania): Kryptoanaliza implementacji szyfrowania zachowującego format FF1 w skarbcu kart SecureVault wykazała, że szyfrowanie danych o małej przestrzeni wejściowej bez unikalnego parametru Tweak pozwala na przeprowadzenie skutecznego ataku słownikowego. Zastosowanie stałego klucza do ochrony krótkich kodów autoryzacyjnych umożliwiało napastnikowi odtworzenie tekstu jawnego poprzez prostą analizę częstości występowania szyfrogramów. Wdrożenie dynamicznego parametru Tweak powiązanego z identyfikatorem konta klienta skutecznie ukryło wzorce statystyczne i zapewniło pełną pseudolosowość generowanych tokenów. Nadrzędny klucz szyfrujący KEK został trwale zdeponowany w module SoftHSM2 z bezwzględnym zakazem jego ekstrakcji do pamięci operacyjnej. Konfiguracja reguł podsystemu auditd zapewniła pełną rozliczalność każdego wywołania biblioteki kryptograficznej, spełniając restrykcyjne wymagania audytu PCI DSS v4.0.

Zadanie opiera się na treściach Wykładu 1 (Zagrożenia dla aplikacji webowych i ataki po stronie klienta), Wykładu 4 (Uwierzytelnianie i autoryzacja transakcji e-commerce) oraz Wykładu 6 (Trendy w architekturze przeglądarek i politykach bezpieczeństwa). Ćwiczenie weryfikuje efekty uczenia się: W1 (dogłębna znajomość anatomii cyberataków typu Magecart i Web Skimming z wykorzystaniem wątków Web Workers), W4 (specyfikacja Content Security Policy CSP Level 3, dyrektywy Strict-Dynamic, Trusted Types oraz mechanizm Subresource Integrity SRI), U1 (implementacja demonstracyjnego skimmera w językach JavaScript i Python), U2 (konfiguracja nagłówków bezpieczeństwa serwera WWW), U3 (analiza ryzyka kradzieży danych kartowych wg CVSS v4.0), U4 (inżynieria sygnatur Suricata NIDS wykrywających eksfiltrację kart) oraz K3 (odpowiedzialność inżynierska za ochronę integralności kodu zewnętrznego zgodnie z PCI DSS v4.0 Req. 6.4.3). Zagadnienia normatywne obejmują standardy W3C CSP Level 3, W3C Subresource Integrity, PCI DSS v4.0 (Req. 6.4.3 i Req. 11.6.1), klasyfikację CWE-79 oraz techniki matrycy MITRE ATT&CK: T1059.007 i T1048.

Nadrzędnym celem zadania jest zbadanie mechanizmów ataków typu Magecart (Web Skimming) polegających na wstrzykiwaniu złośliwego kodu JavaScript do procesów płatności w sklepach internetowych w celu przechwytywania danych kartowych. Zespół studentów analizuje nowoczesne techniki omijania tradycyjnych polityk bezpieczeństwa, w tym wykorzystanie wątków działających w tle (Web Workers) oraz eksfiltrację danych przez ukryte kanały WebSocket i DNS. W fazie ofensywnej studenci implementują demonstracyjny moduł skimmera odczytujący formularz płatności w momencie wprowadzania numeru PAN. Ćwiczenie pozwala zrozumieć, że nawet w pełni zaszyfrowane połączenie HTTPS nie chroni transakcji przed manipulacją kodem wykonywanym po stronie przeglądarki klienta.

W części defensywnej celem jest zaprojektowanie i wdrożenie wielowarstwowej architektury obronnej zgodnej z nowymi wymogami normy PCI DSS v4.0. Studenci konfigurują rygorystyczny nagłówek Content Security Policy (CSP Level 3) z dyrektywami Trusted Types i Strict-Dynamic oraz wdrażają skróty kryptograficzne Subresource Integrity (SRI) dla wszystkich bibliotek zewnętrznych. Zadanie kończy się opracowaniem sygnatury Suricata NIDS wykrywającej próby eksfiltracji danych kartowych na poziomie sieciowym.

Ogólnopolska platforma handlowa „SuperKoszyk.pl” przetwarza tysiące transakcji kartowych dziennie. W ramach operacji audytowej Purple Team specjaliści badają odporność modułu koszyka zakupowego na ataki łańcucha dostaw oprogramowania (Supply Chain Attacks). W tego typu scenariuszach przestępcy infekują zewnętrzną bibliotekę analityczną lub widget czatu, wstrzykując złośliwy skrypt wykradający numery kart, kody CVV oraz dane osobowe klientów.

Aby ominąć statyczne reguły CSP dopuszczające domenę analityczną, złośliwy skrypt uruchamia proces potomny w wątku Web Worker i próbuje nawiązać połączenie WebSocket (WSS) do serwera C2 lub przesłać dane w zapytaniach DNS. W ten sposób złośliwy kod omija podstawowe blokady formularza i wykrada dane transakcyjne w locie.

Zespół studentów przygotowuje demonstrator podatności. W kontrolowanym środowisku laboratoryjnym uruchamiają makietę formularza płatności ze wstrzykniętym skimmerem, demonstrując przechwycenie danych w konsoli atakującego. Następnie przystępują do wdrożenia defensywy Blue Team: wyliczają skróty kryptograficzne SHA-384 dla wszystkich skryptów i dodają atrybuty integrity (SRI) do znaczników script.

W kolejnym kroku inżynierowie rekonfigurują serwer WWW Nginx, wdrażając rygorystyczną politykę CSP Level 3: default-src 'none', script-src 'strict-dynamic' z unikalnym tokenem Nonce, connect-src 'self' https://api.superkoszyk.pl oraz blokadę nieautoryzowanych workerów (worker-src 'none'). Dodatkowo na styku sieci sensor Suricata NIDS zostaje wyposażony w sygnaturę wykrywającą próby transferu numerów kart w nietypowych protokołach, co definitywnie unieszkodliwia wektor ataku Magecart.

• Nginx / Apache HTTP Server: serwer WWW do konfiguracji nagłówków bezpieczeństwa CSP Level 3.
• Python 3 (http.server, websockets): środowisko do uruchomienia makiety sklepu oraz serwera zbierającego dane C2.
• Przeglądarka internetowa (Google Chrome / Firefox): narzędzia deweloperskie DevTools do audytu CSP i naruszeń skryptów.
• Suricata NIDS 7.0+: system inspekcji ruchu sieciowego analizujący pakiety pod kątem wycieku numerów PAN.
• OpenSSL CLI: pakiet narzędziowy do generowania skrótów kryptograficznych Subresource Integrity (SRI).
• Wireshark / TShark: analizator sieciowy do dekodowania ramek protokołu WebSocket.

1. Zbuduj środowisko robocze z serwerem WWW Nginx oraz stacją kliencką wyposażoną w nowoczesną przeglądarkę.
2. Przygotuj stronę formularza płatności e-commerce z polami numeru karty, daty ważności i kodu CVV.
3. Zaimplementuj demonstracyjny skrypt skimmera JavaScript przechwytujący zdarzenia input i submit formularza.
4. Skonfiguruj skimmer do uruchamiania procesu potomnego w wątku Web Worker w celu ominięcia filtrów DOM.
5. Nawiąż połączenie eksfiltracyjne do lokalnego serwera nasłuchującego C2 za pomocą protokołu WebSocket.
6. Wprowadź testowe dane karty płatniczej w formularzu i potwierdź odebranie rekordu przez serwer atakującego.
7. Oblicz skrót kryptograficzny SHA-384 legalnego skryptu bibliotecznego za pomocą polecenia openssl dgst.
8. Wdróż atrybut integrity w znaczniku script i potwierdź zablokowanie ładowania skryptu po wprowadzeniu modyfikacji bitowej.
9. Zaprojektuj nagłówek Content Security Policy (CSP Level 3) z dyrektywą require-trusted-types-for.
10. Skonfiguruj dyrektywę script-src z losowym jednorazowym tokenem Nonce generowanym dynamicznie dla każdej sesji HTTP.
11. Zablokuj możliwość tworzenia niezaufanych wątków potomnych za pomocą dyrektywy worker-src 'none'.
12. Ogranicz dopuszczalne cele połączeń asynchronicznych za pomocą dyrektywy connect-src 'self'.
13. Przetestuj zaktualizowaną konfigurację w przeglądarce i przeanalizuj komunikaty o odmowie wykonania w konsoli DevTools.
14. Opracuj sygnaturę Suricata NIDS wykrywającą obecność 16-cyfrowych numerów kart w ruchu wychodzącym WebSocket.
15. Zweryfikuj wygenerowanie alertu w sensorze Suricata podczas próby symulacji eksfiltracji danych.
16. Oceń wektor podatności według standardu CVSS v4.0 uwzględniając wymogi PCI DSS v4.0 Req. 6.4.3.
17. Sporządź raport inżynierski podsumowujący operację Purple Team oraz konfigurację mechanizmów obronnych.

Ataki typu Magecart (znane również jako Web Skimming lub Digital Skimming) polegają na nieautoryzowanym wstrzyknięciu złośliwego kodu JavaScript do stron płatności internetowych. Adwersarze infekują zewnętrzne biblioteki (analizy ruchu, czaty wsparcia) lub wykorzystują luki w systemach CMS. Złośliwy skrypt nasłuchuje zdarzeń wprowadzania znaków z klawiatury w polach formularza płatności (form grabbing) i wysyła przechwycone dane na serwer kontrolowany przez przestępców.

Nowa wersja normy PCI DSS v4.0 (Req. 6.4.3 oraz Req. 11.6.1) nakłada bezwzględny obowiązek zarządzania wszystkimi skryptami wykonywanymi w przeglądarce klienta w procesie płatności. Wymagane jest uzasadnienie biznesowe dla każdego skryptu, potwierdzenie jego integralności oraz wdrożenie mechanizmów wykrywających modyfikacje nagłówków i zawartości stron.

Mechanizm Subresource Integrity (SRI) pozwala przeglądarce upewnić się, że pobierany zasób (np. z zewnętrznego CDN) nie został zmanipulowany. W znaczniku <script> umieszcza się atrybut integrity="sha384-..." z zakodowanym w Base64 skrótem SHA-384. Jeśli plik na serwerze CDN ulegnie zmianie, przeglądarka odmawia jego wykonania. Z kolei rygorystyczny nagłówek Content Security Policy (CSP Level 3) z dyrektywą strict-dynamic i losowym tokenem Nonce gwarantuje, że wykonają się wyłącznie skrypty jawnie zatwierdzone przez serwer.

Poniżej przedstawiono listing skimmera Web Worker, wyznaczanie skrótu SRI, konfigurację nagłówka CSP w Nginx oraz sygnaturę Suricata.

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Anatomia ataków typu Web Skimming / Magecart: wstrzykiwanie złośliwego kodu JavaScript do procesów transakcyjnych koszyka zakupowego.
2. Zaawansowane techniki eksfiltracji danych: wykorzystanie procesów Web Workers oraz protokołu WebSocket w celu ominięcia polityk CSP.
3. Wdrożenie integralności zasobów podrzędnych (SRI) z kryptograficznymi skrótami SHA-384 w obronie przed atakami łańcucha dostaw.
4. Konfiguracja restrykcyjnej polityki CSP Level 3 z kryptograficznymi wartościami jednorazowymi oraz blokadą nieautoryzowanych workerów.
5. Inżynieria sygnatur Suricata: detekcja w ruchu wychodzącym wzorców numerów kart kredytowych eksfiltrowanych do nieznanych domen.
6. Spełnienie wymogu 6.4.3 oraz 11.6.1 nowej wersji standardu PCI DSS v4.0 dotyczącego ciągłego monitorowania skryptów na stronach płatności.

Przykładowe wnioski (wzór do sprawozdania): Operacja Purple Team na platformie SuperKoszyk.pl wykazała, że złośliwy skrypt Magecart ukryty w bibliotece analitycznej był w stanie odczytać numery kart wprowadzane w formularzu płatności i wyeksfiltrować je za pośrednictwem ukrytego procesu Web Worker. Domyślna polityka CSP okazała się nieskuteczna, ponieważ nie definiowała restrykcji dla dyrektywy worker-src, co pozwoliło skimmerowi na ominięcie reguł filtrowania połączeń. Skuteczną obronę zapewniło wdrożenie mechanizmu Subresource Integrity dla wszystkich zewnętrznych zasobów oraz zaostrzenie polityki CSP Level 3 o kryptograficzne tokeny jednorazowe. Równolegle zaimplementowano sygnaturę sieciową w systemie Suricata, która natychmiast przechwytuje i blokuje pakiety zawierające ciągi cyfr spełniające algorytm Luhna wysyłane poza dozwolone adresy bramek płatniczych. Przeprowadzone ćwiczenie pozwoliło platformie na spełnienie nowych, bezwzględnych wymagań punktów 6.4.3 i 11.6.1 standardu PCI DSS v4.0.

Zadanie opiera się na treściach Wykładu 3 (Funkcje skrótu, struktury Merkle Tree i integralność ksiąg rozliczeniowych) oraz Wykładu 6 (Kryptografia postkwantowa i algorytmy oparte na kratach). Ćwiczenie weryfikuje efekty uczenia się: W2 (matematyka krat algebraicznych w algorytmach postkwantowych FIPS 204 ML-DSA / Dilithium), W3 (anatomia struktur Drzewa Merkle'a, ataki kolizyjne i zasada separacji domenowej wg RFC 6962), U1 (implementacja ataku Second Preimage Attack w języku Python), U2 (integracja biblioteki oqsprovider z OpenSSL 3.x), U3 (analiza ryzyka fałszowania ksiąg rozliczeniowych wg CVSS v4.0), U4 (inżynieria reguł detekcyjnych Sigma w systemach rejestracji transakcji) oraz K1 (odpowiedzialność inżynierska za strategiczne bezpieczeństwo państwowych ksiąg rozrachunkowych). Standardy normatywne obejmują RFC 6962 (Certificate Transparency), NIST FIPS 204 (Module-Lattice-Based Digital Signature Standard ML-DSA), klasyfikację CWE-327 oraz techniki matrycy MITRE ATT&CK: T1565.001.

Nadrzędnym celem zadania jest zbadanie podatności drugiego przeciwobrazu (Second Preimage Attack) na niesymetryczne binarne Drzewa Merkle'a (Merkle Trees) oraz zabezpieczenie międzybankowego rejestru transakcyjnego za pomocą podpisów kryptografii postkwantowej NIST FIPS 204 (ML-DSA / Dilithium). Zespół studentów analizuje konstrukcję dowodów przynależności (Merkle Inclusion Proofs) w strukturach pozbawionych separacji domenowej dla węzłów liści i węzłów wewnętrznych. W części ofensywnej studenci implementują w języku Python exploit generujący sfałszowany dowód obecności transakcji w księdze głównej poprzez podstawienie 64-bajtowego skrótu węzła jako fałszywego liścia. Ćwiczenie ugruntowuje wiedzę o konieczności stosowania ścisłych reguł konstrukcji kryptograficznych struktur danych.

W części defensywnej celem jest wdrożenie ustandaryzowanego schematu haszowania RFC 6962 z prefiksami domenowymi 0x00 dla liści oraz 0x01 dla węzłów pośrednich, co matematycznie uniemożliwia ataki drugiego przeciwobrazu. Ponadto studenci wdrażają postkwantowy podpis cyfrowy korzenia Merkle Root z wykorzystaniem algorytmu ML-DSA-65 w środowisku OpenSSL 3.x OQS Provider. Zadanie kończy się opracowaniem reguły Sigma alarmującej o anomaliach weryfikacji dowodów kryptograficznych.

Krajowa Izba Rozliczeniowa wdraża nienaruszalny rejestr audytowy (Audit Ledger) transakcji międzybankowych o 30-letnim horyzoncie ważności prawnej. W rejestrze tym każda paczka przelewów jest organizowana w binarne Drzewo Merkle'a, a korzeń drzewa (Merkle Root) jest cyfrowo podpisywany w celu zagwarantowania dowodowości. W trakcie audytu bezpieczeństwa stwierdzono, że pierwotna implementacja drzewa nie stosowała separacji domenowej i haszowała liście oraz węzły tą samą funkcją SHA-256(L || R).

Taka luka pozwala na przeprowadzenie ataku drugiego przeciwobrazu. Ponieważ węzeł pośredni drzewa ma postać 64 bajtów (dwa 32-bajtowe skróty potomków), atakujący może zgłosić ten 64-bajtowy ciąg jako nową, nieistniejącą transakcję-liść w zredukowanym poddrzewie. Weryfikator, obliczając skrót z tego ciągu, otrzyma dokładnie ten sam wynik, co hash węzła pośredniego w oryginalnym drzewie, co pozwala na wygenerowanie matematycznie poprawnego, sfałszowanego dowodu przynależności (Fake Inclusion Proof) dla wymyślonego przelewu.

Zespół Purple Team przygotowuje demonstrację luki. Studenci tworzą skrypt w Pythonie budujący podatne drzewo Merkle'a i generują matematycznie poprawny dowód dla sfałszowanej transakcji, która nigdy nie została zatwierdzona przez strony. Weryfikator zgłasza pełną poprawność kryptograficzną, dowodząc kompromitacji rejestru rozliczeniowego.

W fazie obronnej inżynierowie przebudowują strukturę drzewa zgodnie ze standardem RFC 6962: każdy liść otrzymuje prefiks jednobajtowy 0x00 (SHA-256(0x00 || data)), a każdy węzeł wewnętrzny prefiks 0x01 (SHA-256(0x01 || L || R)), co uniemożliwia interpretację węzła jako liścia. Równolegle, w celu zabezpieczenia rejestru przed przyszłymi komputerami kwantowymi, zespół podpisuje korzeń drzewa algorytmem ML-DSA-65 (Dilithium3). Końcowym elementem jest reguła Sigma monitorująca nieudane próby walidacji dowodów w węźle audytowym.

• Python 3 (moduły hashlib, cryptography): środowisko do implementacji struktur Merkle Tree i algorytmów haszowania.
• OpenSSL 3.x z oqsprovider: biblioteka kryptograficzna wspierająca postkwantowe algorytmy podpisów FIPS 204.
• SQLite: lokalny silnik bazy danych do składowania liści i skrótów węzłów księgi transakcyjnej.
• Wireshark / TShark: analizator protokołów do inspekcji przesyłanych dowodów przynależności Merkle Proof.
• Rsyslog: usługa systemowa do agregacji logów weryfikacji integralności rejestru audytowego.
• Sha256sum: uniksowe narzędzie konsolowe do weryfikacji skrótów bloków binarnych.

1. Zbuduj środowisko robocze z pakietami python3-cryptography oraz biblioteką OpenSSL 3.x z modułem oqsprovider.
2. Zaimplementuj podatną strukturę binarnego Drzewa Merkle'a bez prefiksów separacji domenowej.
3. Wprowadź do drzewa 4 testowe transakcje bankowe i oblicz wartość korzenia głównego Merkle Root.
4. Wyznacz węzeł pośredni będący skrótem dwóch pierwszych transakcji (blok 64-bajtowy).
5. Zaimplementuj procedurę ataku Second Preimage: przedstaw blok 64-bajtowy jako pojedynczą transakcję w zredukowanym drzewie.
6. Wygeneruj fałszywy dowód przynależności (Fake Inclusion Proof) dla spreparowanego liścia.
7. Przeprowadź weryfikację dowodu za pomocą standardowego algorytmu i wykaż, że dowód został zaakceptowany jako poprawny.
8. Zaimplementuj bezpieczną strukturę Drzewa Merkle'a zgodną ze standardem RFC 6962 z separacją domenową 0x00 i 0x01.
9. Ponów próbę ataku drugiego przeciwobrazu na utwardzonym drzewie i potwierdź jego odrzucenie z błędem weryfikacji skrótu.
10. Sprawdź dostępność postkwantowego algorytmu podpisów ML-DSA-65 w narzędziu openssl list.
11. Wygeneruj parę kluczy postkwantowych ML-DSA-65 dla nadrzędnego urzędu certyfikacji rejestru audytowego.
12. Zaimplementuj procedurę cyfrowego podpisywania korzenia Merkle Root za pomocą algorytmu ML-DSA-65.
13. Zweryfikuj poprawność podpisu postkwantowego narzędziem openssl pkeyutl z dostawcą oqsprovider.
14. Porównaj rozmiar podpisu ML-DSA (kilkaset bajtów) z klasycznym podpisem ECDSA (64 bajty).
15. Opracuj regułę detekcji Sigma monitorującą zdarzenia odrzucenia dowodów przynależności w węźle audytowym.
16. Dokonaj kalkulacji wektora podatności CVSS v4.0 uwzględniającej ryzyko podrobienia księgi transakcyjnej.
17. Sporządź raport inżynierski dokumentujący dowód matematyczny ataku oraz implementację algorytmu FIPS 204.

Drzewo Merkle'a (Merkle Tree) to kryptograficzna struktura danych powszechnie stosowana w systemach rozproszonych (np. Certificate Transparency, Git, łańcuchy bloków) do efektywnego i bezpiecznego dowodzenia przynależności elementów w złożoności czasowej O(log N). Każdy liść jest skrótem pojedynczej transakcji, a każdy węzeł nadrzędny jest skrótem z konkatenacji swoich dzieci. Korzeń drzewa (Merkle Root) stanowi kryptograficzny odcisk całego zbioru danych.

Podatność drugiego przeciwobrazu (Second Preimage Attack) pojawia się w drzewach, w których funkcja haszująca liście i węzły wewnętrzne nie stosuje separacji domenowej (np. H(x) = SHA256(x) dla wszystkiego). Ponieważ węzeł wewnętrzny składa się z dwóch 32-bajtowych skrótów (razem 64 bajty), podanie tego ciągu jako liścia w płytszym drzewie skutkuje identycznym skrótem H(L || R). Atakujący może sfabrykować nieistniejącą transakcję i przedstawić poprawny matematycznie dowód jej istnienia.

Rozwiązaniem jest standard RFC 6962, który nakazuje bezwzględne stosowanie jednobajtowego prefiksu domenowego: liście są haszowane jako SHA256(0x00 || data), a węzły wewnętrzne jako SHA256(0x01 || left_hash || right_hash). Ponieważ prefiksy 0x00 i 0x01 są różne, żaden węzeł wewnętrzny nie może być zinterpretowany jako liść.

W celu długoterminowej ochrony integralności rejestru przed komputerami kwantowymi, korzeń drzewa podpisuje się algorytmem postkwantowym FIPS 204 (ML-DSA / Dilithium). Algorytm ten bazuje na trudności problemu Module Learning With Errors (M-LWE) w sieciach algebraicznych, na który nie jest znany żaden skuteczny algorytm kwantowy.

Poniżej przedstawiono implementację ataku drugiego przeciwobrazu w języku Python, poprawkę RFC 6962, podpis ML-DSA w OpenSSL oraz regułę Sigma.

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Podatność drugiego przeciwobrazu w niezrównoważonych drzewach Merkle'a: traktowanie węzła pośredniego jako liścia w przypadku braku separacji domen.
2. Matematyczna demonstracja ataku: sfałszowanie dowodu Merkle Proof poprzez manipulację poziomami drzewa bez zmiany korzenia Merkle Root.
3. Wdrożenie bezpiecznego haszowania z separacją domenową (prefiks 0x00 dla liści, prefiks 0x01 dla węzłów wewnętrznych zgodnie z RFC 6962).
4. Podpisywanie korzenia drzewa za pomocą postkwantowego algorytmu podpisów cyfrowych NIST FIPS 204 (ML-DSA) dla wieloletniej ważności prawnej.
5. Opracowanie reguł detekcji Sigma monitorujących błędy parsowania dowodów spójności w rejestrze transakcji międzybankowych.
6. Spełnienie wymogów rozporządzenia eIDAS w zakresie długoterminowej archiwizacji i niezaprzeczalności elektronicznych operacji finansowych.

Przykładowe wnioski (wzór do sprawozdania): Kryptoanaliza struktury rejestru audytowego transakcji międzybankowych wykazała podatność niesymetrycznego Drzewa Merkle'a na atak drugiego przeciwobrazu z powodu braku separacji domenowej pomiędzy liśćmi a węzłami pośrednimi. Zespół audytorski skonstruował alternatywną, sfałszowaną paczkę transakcji, która generowała identyczny korzeń Merkle Root poprzez podstawienie skrótu węzła wewnętrznego w miejsce danych transakcyjnych. Wdrożenie jednoznacznych prefiksów bajtowych (0x00 dla danych transakcji oraz 0x01 dla węzłów nadrzędnych) całkowicie udaremniło ten wektor manipulacji strukturą drzewa. Korzeń nienaruszalnego rejestru zabezpieczono postkwantowym podpisem cyfrowym w standardzie FIPS 204 ML-DSA-87, gwarantując niezaprzeczalność dowodową w perspektywie kolejnych trzech dekad. Opracowana reguła Sigma w systemie SIEM natychmiast alarmuje o próbach przedłożenia nieprawidłowo sformatowanych dowodów audytowych w węźle rozliczeniowym.