Laboratorium 3

Zadanie bazuje na zagadnieniach poruszanych podczas Wykładu 1 oraz Wykładu 4, dotyczących podatności protokołów sieciowych warstwy aplikacji, architektur wielowarstwowych oraz desynchronizacji przetwarzania strumieni TCP w komunikacji HTTP/1.1. Ćwiczenie weryfikuje kierunkowe efekty uczenia się: W1 (dogłębna znajomość mechanizmów ataków desynchronizacyjnych na styku serwera proxy i aplikacji zaplecza), U1 (konstrukcja autorskich pakietów HTTP z nieprawidłowymi nagłówkami przy użyciu surowych gniazd TCP), U3 (analiza zrzutów buforów połączeń i kolejkowania zapytań), U4 (opracowanie sygnatur sieciowych Suricata i reguł detekcji Sigma) oraz K1 (odpowiedzialność za zapewnienie integralności przetwarzania danych w krytycznych platformach państwowych). Wymagania normatywne i techniczne obejmują standardy IETF RFC 7230 (Message Syntax and Routing), IETF RFC 9112 (HTTP/1.1), klasyfikację podatności CWE-444 (Inconsistent Interpretation of HTTP Requests) oraz techniki matrycy MITRE ATT&CK: T1190 (Exploit Public-Facing Application) i T1557 (Adversary-in-the-Middle).

Głównym celem inżynierskim zadania jest zbadanie podatności na desynchronizację żądań HTTP w architekturze brzegowego serwera pośredniczącego Nginx i serwera zaplecza Apache 2.4. Zespół studentów przeprowadza kontrolowaną symulację ataku typu CL.TE, wykazując mechanizm przemycania żądania wewnątrz wspólnego połączenia TCP Keep-Alive. Eksperyment dowodzi możliwości nieautoryzowanego przejęcia sesji innego użytkownika platformy poprzez zafałszowanie kolejki przetwarzania.

W części defensywnej celem jest zaprojektowanie rygorystycznych mechanizmów mitygacji na poziomie serwera Apache oraz implementacja reguł inspekcji ruchu. Zespół wdraża restrykcyjny parser nagłówków HTTP, tworzy sygnaturę dla systemu wykrywania intruzów Suricata oraz konstruuje regułę Sigma do analizy telemetrii w systemie SIEM. Wdrożone rozwiązanie ma w sposób definitywny wyeliminować ryzyko desynchronizacji strumieni bez zakłócania legalnego ruchu użytkowników.

Krajowa Platforma Usług Administracji Elektronicznej przetwarza miliony zapytań obywateli na dobę w ramach zintegrowanego węzła tożsamości. Ruch z sieci publicznej trafia na brzegowy klaster serwerów proxy Nginx, którego zadaniem jest terminacja szyfrowania TLS, kompresja oraz buforowanie odpowiedzi. Żądania są następnie przekazywane wewnętrznym kanałem Keep-Alive do klastra serwerów aplikacyjnych opartych na silniku Apache 2.4. Taka architektura zapewnia wysoką wydajność, lecz wprowadza zależność od spójności interpretacji granic poszczególnych komunikatów HTTP.

W ramach rutynowego monitoringu dyżurni zespołu operacyjnego SOC odnotowali sporadyczne anomalie polegające na przypisywaniu odpowiedzi serwera do nieprawidłowych sesji użytkowników w portalu podatkowym. Wstępna analiza incydentu wykazała podejrzenie występowania podatności HTTP Request Smuggling, wynikającej z rozbieżności interpretacji nagłówków Content-Length oraz Transfer-Encoding pomiędzy serwerem Nginx a backendem Apache. Luka ta stwarza bezpośrednie zagrożenie kradzieży ciasteczek sesyjnych zalogowanych obywateli oraz zatrucia pamięci podręcznej serwera brzegowego.

Zespół laboratoryjny wciela się w rolę grupy audytorów bezpieczeństwa Purple Team, działających w ściśle odizolowanym segmencie sieciowym. Zadaniem grupy jest laboratoryjne odtworzenie podatnej konfiguracji, opracowanie autorskiego skryptu weryfikacyjnego w języku Python wysyłającego zdesynchronizowane żądanie CL.TE oraz udokumentowanie faktu przejęcia nagłówków sesyjnych kolejnego użytkownika. Eksperyment musi zostać przeprowadzony z zachowaniem pełnej izolacji telemetrycznej i rejestracją wszystkich zdarzeń sieciowych.

Końcowym etapem scenariusza jest inżynieria zabezpieczeń i walidacja mechanizmów obronnych. Zespół rekonfiguruje serwer Apache, aktywując restrykcyjny parser zgodny z wytycznymi RFC 7230, oraz konfiguruje brzegowe usuwanie sprzecznych nagłówków w Nginx. Równolegle studenci tworzą i testują sygnatury NIDS Suricata wykrywające jednoczesne występowanie nagłówków długości i kodowania fragmentowego, weryfikując skuteczność wykrywania na zrekonstruowanym ruchu adwersarza.

• Python 3 (moduły socket, ssl, time): środowisko do budowy autorskiego skryptu PoC operującego na surowych gniazdach TCP, uniemożliwiające automatyczną normalizację nagłówków przez wysokopoziomowe biblioteki HTTP.
• Nginx (wersja 1.18 lub nowsza): serwer pośredniczący pełniący rolę brzegowego reverse proxy w podatnej i utwardzonej konfiguracji.
• Apache HTTP Server (wersja 2.4.41 lub nowsza): serwer aplikacji zaplecza podlegający badaniu pod kątem dyrektywy HttpProtocolOptions.
• Suricata NIDS (wersja 7.0+): silnik sieciowego wykrywania intruzów analizujący surowy strumień pakietów pod kątem anomalii nagłówków HTTP.
• Wireshark / TShark: analizator protokołów sieciowych do inspekcji ramek TCP, śledzenia strumieni TCP Stream i badania przesunięcia bufora.
• Sigma CLI (sigmac): narzędzie do kompilacji uniwersalnych reguł detekcji Sigma do zapytań formatu SIEM (Elasticsearch / Splunk).
• cURL / OpenSSL s_client: uniksowe narzędzia CLI do manualnego testowania odpowiedzi serwerów i badania zachowania parserów.

1. Zbuduj wyizolowane środowisko wirtualne składające się z maszyny reverse proxy (Nginx), serwera zaplecza (Apache 2.4) oraz stacji audytorskiej.
2. Skonfiguruj połączenie proxy_pass w serwerze Nginx z zachowaniem stałego połączenia HTTP/1.1 Keep-Alive do backendu Apache.
3. Zweryfikuj domyślną reakcję serwera Nginx na nagłówek Transfer-Encoding: chunked w zestawieniu z nagłówkiem Content-Length.
4. Przeanalizuj wytyczne specyfikacji IETF RFC 7230 rozdział 3.3.3 dotyczące priorytetu parsowania nagłówka Transfer-Encoding nad Content-Length.
5. Napisz autorski skrypt w języku Python zestawiający bezpośrednie połączenie z użyciem modułu socket i biblioteki ssl.
6. Skonstruuj ładunek CL.TE, w którym proxy przetwarza nagłówek Content-Length, a backend odczytuje Transfer-Encoding kończący się na zerowym chunku.
7. Umieść w przemyconej części ładunku prefiks niekompletnego żądania GET skierowanego do zasobu chronionego.
8. Wyślij spreparowany pakiet na port serwera proxy i zaobserwuj odpowiedź serwera na pierwsze zapytanie.
9. Zasymuluj zapytanie legalnego użytkownika wysyłającego formularz z poufnym ciasteczkiem sesyjnym bezpośrednio po żądaniu atakującym.
10. Zarejestruj odpowiedź serwera backendowego i wykaż, że żądanie legalnego użytkownika zostało dołączone do przemyconego prefiksu.
11. Przechwyć zrzut ruchu sieciowego za pomocą narzędzia tcpdump i przeanalizuj przesunięcie strumienia w programie Wireshark.
12. Opracuj sygnaturę sieciową NIDS Suricata wykrywającą jednoczesną obecność nagłówków Content-Length i Transfer-Encoding w jednym żądaniu.
13. Przetestuj działanie sygnatury Suricata, uruchamiając inspekcję w trybie czytania pliku pcap i weryfikując wygenerowanie alertu w logu fast.log.
14. Zdefiniuj regułę detekcji w formacie Sigma mapującą kody błędów HTTP 400 oraz komunikaty parsowania w dziennikach Apache.
15. Wprowadź dyrektywę HttpProtocolOptions Strict w konfiguracji Apache i zrestartuj usługę serwera WWW.
16. Wprowadź reguły sanityzacji nagłówków w konfiguracji Nginx, usuwając niejednoznaczne nagłówki przekazywane do backendu.
17. Wykonaj test re-testowy za pomocą przygotowanego skryptu PoC, potwierdzając natychmiastowe odrzucenie zdesynchronizowanego żądania kodem HTTP 400.

Podczas konstruowania ładunku ataku CL.TE kluczowe znaczenie ma precyzyjne wyliczenie wartości nagłówka Content-Length. Wartość ta musi obejmować dokładnie taką liczbę bajtów, która pozwoli serwerowi proxy na przesłanie całego komunikatu, podczas gdy serwer zaplecza uzna fragment za zakończony po napotkaniu sekwencji zerowego fragmentu chunked. Każdy znak końca linii musi bezwzględnie składać się z dwubajtowej sekwencji CRLF (znaki \r\n), a jakiekolwiek odstępstwo spowoduje błąd składniowy przed wystąpieniem desynchronizacji.

W serwerze Apache 2.4 kluczowym parametrem obronnym jest dyrektywa HttpProtocolOptions. W trybie Strict serwer rygorystycznie egzekwuje reguły RFC 7230, odrzucając zapytania zawierające jednocześnie nagłówki Content-Length i Transfer-Encoding lub zawierające niedozwolone znaki spacji w nazwach nagłówków. Dodatkowo warto rozważyć wdrożenie komunikacji HTTP/2 na styku proxy-backend, gdyż ramkowanie binarne z definicji uniemożliwia manipulacje granicami komunikatów.

W środowisku laboratoryjnym do testowania przepływu pakietów zaleca się wykorzystanie dedykowanego wirtualnego mostka sieciowego, na którym nasłuchuje sensor Suricata. Pozwala to na jednoczesną weryfikację zachowania aplikacji oraz skuteczności reguł NIDS w warunkach w 100% zbliżonych do rzeczywistego środowiska produkcyjnego.

Poniższe listingi prezentują przykładowe kody skryptu audytorskiego, konfigurację obronną serwerów WWW oraz reguły detekcji telemetrycznej, które należy zaadaptować i przetestować w sprawozdaniu laboratoryjnym.

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

1. Analiza różnic w interpretacji specyfikacji protokołu HTTP/1.1 pomiędzy serwerem proxy Nginx a zapleczem Apache.
2. Demonstracja eksploatacji wariantu CL.TE: przemycanie zapytań z zagnieżdżonymi nagłówkami administracyjnymi.
3. Mechanizm zatruwania kolejki połączeń wielokrotnego użytku (Keep-Alive) i kradzież tożsamości innych użytkowników portalu.
4. Wdrożenie rygorystycznej konfiguracji Nginx: dyrektywy blokujące niejednoznaczne deklaracje rozmiaru treści.
5. Konfiguracja modułów Apache: restrykcyjne przetwarzanie z opcją HttpProtocolOptions Strict w celu odrzucania zniekształconych pakietów.
6. Opracowanie reguł detekcji w systemach WAF i SIEM identyfikujących obecność podwójnych nagłówków w pojedynczym żądaniu.

Przykładowe wnioski (wzór do sprawozdania): Praktyczne odtworzenie ataku HTTP Request Smuggling na styku serwera proxy Nginx i zaplecza Apache unaoczniło krytyczne ryzyko wynikające z asymetrii parsowania nagłówków strumienia HTTP/1.1. Przekazanie spreparowanego pakietu z oboma nagłówkami Content-Length oraz Transfer-Encoding pozwoliło na przemycenie nieautoryzowanego żądania GET do chronionego panelu administratora. W rezultacie kolejny legalny użytkownik łączący się w ramach tej samej sesji Keep-Alive otrzymał odpowiedź zawierającą nie swoje dane, co doprowadziło do kradzieży jego ciasteczek sesyjnych. Zrekonfigurowanie serwera Nginx w celu natychmiastowego zrywania połączeń przy wykryciu podwójnych deklaracji rozmiaru oraz wymuszenie opcji HttpProtocolOptions Strict w Apache całkowicie usunęło lukę. Zaimplementowane reguły detekcyjne w zaporze WAF monitorujące anomalie w strukturze nagłówków gwarantują wczesne wykrywanie prób desynchronizacji w węźle tożsamości administracji publicznej.

Zadanie opiera się na treściach Wykładu 3, poświęconego architekturze Public Key Infrastructure (PKI), mechanizmom dystrybucji i unieważniania certyfikatów cyfrowych X.509 oraz protokołowi Online Certificate Status Protocol (OCSP). Ćwiczenie weryfikuje efekty uczenia się: W4 (dogłębna znajomość protokołów weryfikacji statusu certyfikatów oraz różnic pomiędzy trybami walidacji soft-fail i hard-fail), U1 (samodzielne uruchomienie i konfiguracja usługi OCSP Responder w środowisku OpenSSL), U2 (generowanie certyfikatów z rozszerzeniem TLS Feature status_request wg RFC 7633), U3 (empiryczna weryfikacja uścisku dłoni z zszytym biletem OCSP Stapling) oraz K2 (krytyczna ocena domyślnych mechanizmów bezpieczeństwa przeglądarek). Wymagania techniczne i prawne obejmują standardy IETF RFC 6960 (OCSP), IETF RFC 7633 (TLS Feature Extension), zalecenia rozporządzenia DORA (UE 2022/2554) oraz techniki MITRE ATT&CK: T1588.004 i T1557.

Celem zadania jest zaprojektowanie, wdrożenie i przetestowanie mechanizmu OCSP Stapling z rygorystycznym rozszerzeniem TLS Must-Staple na serwerze Apache. Zespół studentów bada słabości tradycyjnego sprawdzania unieważnień certyfikatów, w którym blokada komunikacji z serwerem CA OCSP powoduje łagodne zaakceptowanie potencjalnie skompromitowanego certyfikatu przez przeglądarkę. Poprzez wdrożenie rozszerzenia RFC 7633 studenci wymuszają bezwzględny tryb hard-fail weryfikacji.

W części wdrożeniowej studenci konfigurują lokalne centrum certyfikacji CA, uruchamiają niezależny serwer OCSP Responder oraz konfigurują buforowanie poświadczeń w module mod_ssl serwera Apache. Następnie przeprowadzają kontrolowany atak blokady portu OCSP, demonstrując natychmiastowe zablokowanie sesji przez przeglądarkę w przypadku braku zszytej odpowiedzi. Końcowym rezultatem jest odporna architektura weryfikacji statusu certyfikatu, eliminująca wycieki prywatności użytkowników oraz opóźnienia sieciowe.

Krajowa Instytucja Rozliczeń Finansowych przetwarza transakcje bankowe o znaczeniu systemowym za pośrednictwem dedykowanego portalu rozliczeniowego. Zgodnie z wymogami rozporządzenia DORA oraz normy ISO/IEC 27001, klucze kryptograficzne wykorzystywane do zabezpieczania sesji TLS podlegają rygorystycznemu cyklowi życia. W przypadku podejrzenia ujawnienia klucza prywatnego certyfikat serwera musi zostać natychmiast unieważniony w rejestrze urzędu certyfikacji, a systemy klienckie muszą bezwzględnie odmówić nawiązania połączenia.

W trakcie audytu bezpieczeństwa teleinformatycznego wykazano istotną podatność architektoniczną: większość popularnych przeglądarek i bibliotek klienckich stosuje weryfikację OCSP w trybie soft-fail. Oznacza to, że jeśli napastnik MitM na poziomie operatora sieci zablokuje ruch do serwera OCSP urzędu CA, klient uznaje brak odpowiedzi za sytuację dopuszczalną i kontynuuje połączenie z unieważnionym certyfikatem. Stanowi to krytyczną lukę w łańcuchu zaufania publicznego, umożliwiającą podsłuch transakcji przy użyciu wycofanego klucza.

Zespół laboratoryjny otrzymuje zadanie wyeliminowania podatności soft-fail poprzez wdrożenie mechanizmu OCSP Stapling sprzężonego z rozszerzeniem certyfikatu X.509 TLS Feature status_request (RFC 7633). Rozwiązanie to nakłada na serwer obowiązek pobierania podpisanego poświadczenia OCSP od urzędu CA i dołączania go bezpośrednio do uścisku dłoni TLS. Obecność rozszerzenia Must-Staple w certyfikacie informuje klienta, że brak zszytego biletu jest równoznaczny z kompromitacją serwera i wymaga natychmiastowego zerwania sesji.

W ramach realizacji ćwiczenia studenci konfigurują kompletne środowisko PKI: generują główny urząd Root CA, tworzą bazę unieważnień index.txt, uruchamiają demona OCSP na porcie 8888 oraz wydają certyfikat serwerowy z flagą status_request. Po skonfigurowaniu serwera Apache studenci testują zachowanie klientów przed i po unieważnieniu certyfikatu, a także badają odporność na symulowaną awarię serwera OCSP za pomocą reguł zapory ogniowej iptables.

• OpenSSL (wersja 3.0+): pakiet narzędziowy do zarządzania certyfikatami X.509, konfiguracji rozszerzeń w pliku openssl.cnf oraz uruchomienia demona openssl ocsp.
• Apache HTTP Server z modułem mod_ssl: serwer WWW realizujący pobieranie i zszywanie poświadczeń OCSP Stapling.
• iptables / nftables: zapora sieciowa w systemie Linux do kontrolowanego blokowania portu usługi OCSP w celach audytorskich.
• Wireshark / TShark: narzędzie do analizy pakietów TLS Handshake pod kątem obecności komunikatu CertificateStatus.
• Firefox ESR / cURL: przeglądarka i klient HTTP wspierający rygorystyczną obsługę rozszerzenia RFC 7633 Must-Staple.
• Python 3 (moduł cryptography): środowisko do budowy skryptów weryfikujących rozszerzenia X.509 w łańcuchu certyfikatów.

1. Zainstaluj środowisko OpenSSL oraz serwer Apache 2.4 z obsługą modułu mod_ssl na maszynie laboratoryjnej Linux.
2. Utwórz katalog urzędu certyfikacji /root/ca wraz z plikami serial oraz index.txt do ewidencji certyfikatów.
3. Wygeneruj klucz prywatny oraz samopodpisany certyfikat głównego urzędu Root CA o długości 4096 bitów.
4. Utwórz dedykowany klucz i certyfikat dla usługi OCSP Responder podpisany przez nadrzędny urząd Root CA.
5. Przygotuj plik konfiguracyjny openssl.cnf definiujący rozszerzenie TLS Feature status_request (identyfikator OID: 1.3.6.1.5.5.7.1.24).
6. Wygeneruj żądanie podpisania certyfikatu (CSR) dla serwera WWW rozliczenia.finanse.local.
7. Podpisz certyfikat serwera kluczem CA, dołączając rozszerzenie Must-Staple oraz adres URL punktu dostępowego OCSP (AIA).
8. Zweryfikuj obecność rozszerzenia TLS Feature w wygenerowanym certyfikacie poleceniem openssl x509 -text.
9. Uruchom usługę demona OCSP Responder poleceniem openssl ocsp nasłuchującą na porcie TCP 8888.
10. Przetestuj manualne zapytanie o status certyfikatu za pomocą klienta openssl ocsp i zweryfikuj odpowiedź cert status: good.
11. Skonfiguruj w serwerze Apache dyrektywy SSLUseStapling On, SSLStaplingCache oraz wskaż plik łańcucha SSLCertificateChainFile.
12. Zrestartuj serwer Apache i nawiąż testowe połączenie poleceniem openssl s_client -connect ... -status.
13. Wykaż w przechwyconym strumieniu obecność bloku OCSP Response dołączonego do uścisku dłoni TLS.
14. Opracuj autorski skrypt w języku Python parsujący odpowiedź CertificateStatus i weryfikujący podpis cyfrowy biletu.
15. Zablokuj komunikację z portem 8888 za pomocą reguły iptables i zaobserwuj zachowanie serwera po wygaśnięciu bufora pamięci podręcznej.
16. Unieważnij certyfikat serwera w urzędzie CA poleceniem openssl ca -revoke i wygeneruj nową odpowiedź OCSP revoked.
17. Wykaż w przeglądarce Firefox natychmiastowe zerwanie połączenia i wyświetlenie błędu krytycznego z kodem MOZILLA_PKIX_ERROR_REQUIRED_TLS_FEATURE_MISSING.

Kluczowym elementem zadania jest prawidłowe zdefiniowanie rozszerzenia Must-Staple w pliku konfiguracyjnym OpenSSL. Zgodnie ze standardem RFC 7633 rozszerzenie to nosi nazwę TLS Feature i zawiera flagę status_request (wartość numeryczna 5). W pliku konfiguracyjnym sekcja rozszerzeń certyfikatu serwera musi zawierać wpis 1.3.6.1.5.5.7.1.24 = DER:30:03:02:01:05. Bez tego wpisu certyfikat będzie korzystał z tradycyjnego zszywania OCSP, lecz przeglądarki w przypadku braku biletu przejdą do podatnego trybu soft-fail.

W konfiguracji serwera Apache należy zwrócić szczególną uwagę na dyrektywę SSLStaplingCache. Buforowanie odpowiedzi w pamięci podręcznej zapobiega przeciążeniu serwera OCSP Responder przy każdym nowym połączeniu klienckim. Standardowo stosuje się pamięć współdzieloną shmcb, na przykład SSLStaplingCache "shmcb:/var/run/apache2/stapling_cache(128000)". Dodatkowo zaleca się włączenie dyrektywy SSLStaplingReturnUntrusted On w przypadku korzystania z wewnętrznego, prywatnego urzędu CA.

Podczas weryfikacji połączenia za pomocą narzędzia openssl s_client niezbędne jest podanie flagi -status. W przeciwnym razie klient OpenSSL nie wyśle rozszerzenia status_request w pakiecie ClientHello, a serwer Apache nie dołączy zszytego biletu OCSP, co może prowadzić do błędnych wniosków audytorskich.

Poniżej przedstawiono listingi konfiguracyjne OpenSSL, polecenia uruchomienia usługi OCSP Responder oraz procedurę weryfikacji biletu OCSP w wierszu poleceń.

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

1. Architektura i mechanizm rozszerzenia TLS Must-Staple (RFC 7633) w nowoczesnych certyfikatach X.509.
2. Eliminacja podatności ataku blokowania połączeń OCSP (Revocation Bypass via Soft-Fail) w przeglądarkach internetowych.
3. Konfiguracja lokalnego respondera OCSP opartego na OpenSSL oraz generowanie podpisanych poświadczeń statusu unieważnienia.
4. Wdrożenie automatycznego zszywania OCSP (OCSP Stapling) w serwerze WWW z bezpiecznym buforowaniem odpowiedzi.
5. Zapewnienie wysokiej dostępności i redundancji dla procesu odświeżania staplingu w celu uniknięcia błędu unieważnienia.
6. Spełnienie wymogów rozporządzenia DORA i Rekomendacji D KNF w zakresie niezawodnej weryfikacji ważności certyfikatów bankowych.

Przykładowe wnioski (wzór do sprawozdania): Wdrożenie rozszerzenia TLS Must-Staple w certyfikacie portalu bankowego definitywnie rozwiązało problem podatności mechanizmu weryfikacji unieważnień w domyślnym trybie Soft-Fail. Zablokowanie ruchu do zewnętrznego serwera CA nie pozwala już napastnikowi na ukrycie faktu wycofania certyfikatu, gdyż brak dołączonej odpowiedzi OCSP skutkuje natychmiastowym przerwaniem sesji przez klienta. Serwer Apache z poprawnie skonfigurowanym mechanizmem OCSP Stapling okresowo odpytuje lokalny responder i buforuje kryptograficznie podpisane poświadczenie ze statusem Good. Zapobiega to jakimkolwiek opóźnieniom przy nawiązywaniu połączeń TLS oraz całkowicie chroni prywatność użytkowników portalu rozliczeniowego. Zastosowanie rozszerzenia Must-Staple podniosło poziom bezpieczeństwa bankowej warstwy kryptograficznej, spełniając restrykcyjne wymagania unijnego rozporządzenia DORA.

Zadanie opiera się na zagadnieniach Wykładu 4, dotyczących współczesnych wyzwań kryptografii asymetrycznej, algorytmu Shora łamiącego klasyczne schematy wymiany kluczy (RSA i ECC) oraz standardów kryptografii postkwantowej (PQC) opracowanych przez NIST. Ćwiczenie weryfikuje efekty uczenia się: W3 (znajomość matematycznych podstaw problemu Learning With Errors leżącego u podstaw algorytmu ML-KEM), W4 (zrozumienie architektury hybrydowej wymiany kluczy w protokole TLS 1.3), U1 (konfiguracja hybrydowych grup PQC w serwerze Apache i bibliotece OpenSSL 3.4), U3 (analiza rozszerzeń key_share w ramkach TLS za pomocą narzędzia TShark) oraz K1 (świadomość długofalowej odpowiedzialności za poufność danych strategicznych o znaczeniu państwowym). Wymagania techniczne i normatywne obejmują standardy NIST FIPS 203 (Module-Lattice-Based Key-Encapsulation Mechanism - ML-KEM), zalecenia NSA Commercial National Security Algorithm Suite 2.0 (CNSA 2.0), wytyczne ENISA dotyczące migracji postkwantowej oraz techniki MITRE ATT&CK: T1040 i T1557.

Celem zadania jest wdrożenie i empiryczne przetestowanie hybrydowego mechanizmu wymiany kluczy w protokole TLS 1.3, łączącego klasyczną krzywą eliptyczną X25519 z postkwantowym mechanizmem enkapsulacji klucza ML-KEM-768 (Kyber768). Studenci przeprowadzają audyt podatności serwera WWW na długoterminowe zagrożenie typu Harvest Now, Decrypt Later (HNDL). Wykazują, że ruch szyfrowany wyłącznie klasycznymi algorytmami może zostać bezpowrotnie skompromitowany w przyszłości.

W części defensywnej zespół konfiguruje środowisko serwerowe oparte o najnowszą bibliotekę kryptograficzną wspierającą hybrydowe grupy PQC oraz weryfikuje poprawność negocjacji parametrów uścisku dłoni. Studenci opracowują skrypt w języku Python badający strukturę pakietu ServerHello, mierzą narzut wydajnościowy na rozmiar pakietów oraz tworzą regułę NIDS Suricata wykrywającą sesje pozbawione ochrony postkwantowej. Wdrożona konfiguracja zapewnia pełną odporność zarówno na klasyczną kryptoanalizę, jak i komputery kwantowe.

Kancelaria Prezesa Rady Ministrów oraz Ministerstwo Obrony Narodowej wdrażają zintegrowany portal bezpiecznej wymiany analiz strategicznych i niejawnych raportów wywiadowczych. Zgodnie z wytycznymi Agencji Bezpieczeństwa Wewnętrznego oraz międzynarodowymi rekomendacjami CNSA 2.0, dane o najwyższym poziomie wrażliwości muszą zachować poufność przez co najmniej 30 lat od momentu transmisji. Wrogie służby specjalne prowadzą masowy podsłuch węzłów tranzytowych, składując pakiety na macierzach dyskowych w oczekiwaniu na skonstruowanie stabilnego komputera kwantowego.

Zagrożenie typu Harvest Now, Decrypt Later (Zbieraj teraz, odszyfruj później) unieważnia tradycyjny model zaufania oparty wyłącznie na krzywych eliptycznych ECDHE czy szyfrowaniu RSA. Choć komputery kwantowe zdolne do wykonania algorytmu Shora nie są jeszcze komercyjnie dostępne, zaszyfrowana korespondencja przechwycona dzisiaj zostanie natychmiast odszyfrowana w perspektywie kolejnych lat. Instytucje administracji publicznej są zobligowane do natychmiastowego wdrożenia zabezpieczeń kryptografii postkwantowej w kanałach HTTPS.

Zespół laboratoryjny wciela się w rolę inżynierów bezpieczeństwa teleinformatycznego odpowiedzialnych za modernizację infrastruktury węzła bezpiecznej łączności. Pierwszym etapem jest przeprowadzenie audytu obecnego serwera: przechwycenie ruchu uścisku dłoni TLS 1.3 i wykazanie, że serwer akceptuje wyłącznie grupy klasyczne (np. x25519, secp256r1). Audytorzy dokumentują brak odporności na przyszłe odszyfrowanie oraz kalkulują wektor podatności zgodnie z metodyką CVSS v3.1 uwzględniającą krytyczny wpływ na bezpieczeństwo państwa.

Drugim etapem jest rekonfiguracja serwera Apache z wykorzystaniem silnika OpenSSL wspierającego hybrydowy standard X25519 + ML-KEM-768. Zespół weryfikuje poprawność wymiany kluczy z kompatybilnymi przeglądarkami, analizuje wzrost narzutu nagłówków w rozszerzeniu key_share oraz konfiguruje sensor sieciowy Suricata monitorujący zgodność polityki kryptograficznej. Końcowym elementem jest test obciążeniowy porównujący czasy negocjacji sesji klasycznej i hybrydowej.

• OpenSSL 3.4+ / OQS (Open Quantum Safe): nowoczesna implementacja biblioteki kryptograficznej wspierająca algorytmy PQC zgodne ze standardem FIPS 203.
• Apache HTTP Server 2.4: serwer WWW z modułem mod_ssl skonfigurowany pod kątem specjalistycznych dyrektyw SSLOpenSSLConfCmd.
• TShark / Wireshark (wersja 4.2+): analizator ruchu z wbudowanym dekoderem rozszerzeń Post-Quantum NamedGroup w TLS 1.3.
• Google Chrome / Chromium (z flagą PQC): nowoczesna przeglądarka kliencka ze wsparciem dla hybrydowej wymiany kluczy X25519Kyber768.
• Python 3 (moduły subprocess, socket, ssl): środowisko do budowy autorskiego skryptu weryfikującego wynegocjowaną grupę TLS.
• Suricata NIDS 7.0+: system inspekcji ruchu sieciowego z regułami analizującymi protokół TLS i identyfikatory NamedGroup.

1. Zainstaluj lub skompiluj bibliotekę OpenSSL w wersji wspierającej hybrydowe grupy PQC (X25519Kyber768 / X25519MLKEM768).
2. Zweryfikuj listę obsługiwanych grup wymiany kluczy za pomocą polecenia openssl list -tls-groups.
3. Skonfiguruj serwer Apache do obsługi protokołu TLS 1.3 jako jedynego dozwolonego standardu szyfrowania transportowego.
4. Utwórz certyfikat serwerowy dla domeny mon.gov.local i zintegruj go z konfiguracją wirtualnego hosta Apache.
5. Zdefiniuj w konfiguracji Apache dyrektywę SSLOpenSSLConfCmd Groups wymuszającą priorytet grupy hybrydowej X25519Kyber768.
6. Uruchom przechwytywanie pakietów na interfejsie sieciowym serwera za pomocą narzędzia tshark z filtrem tls.
7. Nawiąż połączenie testowe z poziomu stacji audytorskiej, wymuszając klasyczną grupę x25519 i zarejestruj wynik.
8. Nawiąż połączenie testowe z wymuszeniem grupy hybrydowej X25519Kyber768 za pomocą narzędzia openssl s_client.
9. Przeanalizuj w przechwyconym pakiecie ClientHello obecność rozszerzenia supported_groups oraz identyfikator 0x6399 lub 0x11ec.
10. Zbadaj rozmiar klucza publicznego przesyłanego w rozszerzeniu key_share dla algorytmu ML-KEM-768 w porównaniu do standardowego X25519.
11. Opracuj autorski skrypt w języku Python weryfikujący automatycznie, czy serwer prawidłowo negocjuje grupę postkwantową.
12. Wykonaj test połączenia z przeglądarki Chrome z aktywną flagą experimental post-quantum key agreement i sprawdź panel DevTools Security.
13. Opracuj sygnaturę sieciową NIDS Suricata wykrywającą połączenia do portalu strategicznego pozbawione grupy postkwantowej.
14. Przetestuj działanie sygnatury Suricata, wywołując uścisk dłoni z klasycznym klientem i weryfikując wygenerowanie alertu w logu fast.log.
15. Przeprowadź serię pomiarów czasu trwania uścisku dłoni (Handshake Latency) dla 100 kolejnych sesji klasycznych oraz 100 sesji hybrydowych.
16. Opracuj zestawienie statystyczne prezentujące narzut obliczeniowy oraz przyrost wolumenu danych w warstwie transportowej.
17. Sformułuj techniczne i normatywne wnioski inżynierskie dotyczące gotowości infrastruktury do wymogów ery postkwantowej.

Koncepcja hybrydowej wymiany kluczy (Hybrid Key Exchange) polega na równoległym wykonaniu klasycznego uzgadniania klucza na krzywej eliptycznej (X25519) oraz postkwantowego mechanizmu enkapsulacji (ML-KEM / Kyber768). Obydwa uzyskane sekrety są następnie łączone w jeden klucz sesyjny za pomocą funkcji wyprowadzania klucza (KDF). Dzięki temu nawet w przypadku wykrycia nieznanej dotąd słabości w nowym algorytmie kratowym, bezpieczeństwo sesji jest gwarantowane przez sprawdzoną klasyczną kryptografię eliptyczną.

W serwerze Apache 2.4 konfiguracja grup TLS 1.3 realizowana jest poprzez polecenie SSLOpenSSLConfCmd Groups. Należy upewnić się, że zainstalowana w systemie wersja OpenSSL rozpoznaje nazwę grupy, np. X25519Kyber768Draft00 lub X25519MLKEM768. W przypadku starszych wersji OpenSSL 3.0 konieczne może być dołączenie dostawcy OQS (Open Quantum Safe Provider) w pliku openssl.cnf.

Istotnym zagadnieniem inżynierskim jest rozmiar pakietów sieciowych. O ile klucz publiczny X25519 zajmuje zaledwie 32 bajty, o tyle klucz publiczny Kyber768 wymaga 1184 bajtów, a szyfrogram 1088 bajtów. Powoduje to, że pakiet ClientHello oraz ServerHello mogą przekroczyć standardowy rozmiar jednostki MTU (1500 bajtów) i ulec fragmentacji IP, co należy zbadać i udokumentować w sprawozdaniu.

Poniżej zamieszczono przykładowe listingi konfiguracji serwera Apache, polecenia inspekcji TShark oraz strukturę sygnatury Suricata wykrywającej uściski dłoni bez PQC.

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

1. Analiza zagrożenia typu Harvest Now, Decrypt Later (HNDL): przechwytywanie zaszyfrowanego ruchu w celu późniejszego odszyfrowania.
2. Standardy kryptografii postkwantowej NIST: algorytm ML-KEM oparty na trudności problemu uczenia się z błędami w kratach.
3. Architektura hybrydowej wymiany kluczy: łączenie klasycznej krzywej eliptycznej z mechanizmem KEM w celu podwójnego bezpieczeństwa.
4. Wpływ większych kluczy publicznych i szyfrogramów postkwantowych na fragmentację pakietów TCP i czas zestawiania sesji TLS 1.3.
5. Zgodność z wytycznymi Commercial National Security Algorithm Suite (CNSA 2.0) oraz zaleceniami ABW w ochronie informacji niejawnych.
6. Metodyka weryfikacji wynegocjowanej grupy hybrydowej w ruchu sieciowym przy użyciu dedykowanych bibliotek kryptografii postkwantowej.

Przykładowe wnioski (wzór do sprawozdania): Zaimplementowanie hybrydowego schematu wymiany kluczy X25519 oraz ML-KEM-768 w protokole TLS 1.3 zapewniło natychmiastową ochronę strategicznych danych rządowych przed atakami typu Harvest Now, Decrypt Later. Połączenie klasycznej kryptografii na krzywych eliptycznych z algorytmem siatkowym Kyber gwarantuje, że bezpieczeństwo sesji zostanie zachowane nawet w przypadku hipotetycznego złamania jednego z mechanizmów. Inspekcja ruchu sieciowego w programie Wireshark potwierdziła poprawne uzgodnienie grupy hybrydowej w rozszerzeniu supported_groups w pakiecie ClientHello. Mimo wzrostu rozmiaru pakietu handshake narzut na opóźnienie zestawienia połączenia wyniósł zaledwie 4,2 ms, co jest wartością w pełni akceptowalną dla krytycznych łączy rządowych. Wdrożone rozwiązanie stanowi pionierską realizację międzynarodowych wytycznych CNSA 2.0 oraz rekomendacji ABW w obszarze odporności na kryptoanalizę kwantową.

Zadanie nawiązuje do Wykładu 3 oraz Wykładu 4, dotyczących ograniczeń architektury Web PKI, zagrożeń wynikających z istnienia setek globalnie zaufanych centrów certyfikacji oraz standardów DANE i DNSSEC. Ćwiczenie weryfikuje efekty uczenia się: W4 (dogłębne zrozumienie mechanizmu uwierzytelniania nazwanego obiektu za pomocą DNSSEC i standardu DANE), U1 (konfiguracja i kryptograficzne podpisywanie strefy DNS kluczami ZSK i KSK w oprogramowaniu BIND9), U2 (generowanie i publikacja rekordów TLSA za pomocą narzędzia danetool), U3 (weryfikacja łańcucha kryptograficznego DNSSEC za pomocą narzędzia delv) oraz K1 (uniezależnienie krajowej infrastruktury teleinformatycznej od podatności zagranicznych centrów certyfikacji). Wymagania normatywne obejmują standardy IETF RFC 6698 (DANE TLSA), IETF RFC 7671 (DANE Protocol Guidance), IETF RFC 4033-4035 (DNSSEC), wytyczne NIST SP 800-81-2 oraz techniki MITRE ATT&CK: T1588.004 i T1556.

Głównym celem zadania jest wdrożenie mechanizmu kryptograficznego powiązania certyfikatu serwera WWW ze strefą DNS za pomocą protokołu DANE (RFC 6698) i rekordów TLSA zabezpieczonych przez DNSSEC. Zespół studentów bada krytyczną słabość tradycyjnego ekosystemu Web PKI, w którym jakikolwiek skompromitowany urząd CA na świecie może wystawić ważny certyfikat dla dowolnej domeny. Studenci demonstrują scenariusz ataku podszycia się pod instytucję publiczną przy użyciu fałszywego certyfikatu z alternatywnego CA.

W części obronnej celem jest podpisanie strefy domenowej kluczami kryptograficznymi DNSSEC, wygenerowanie rekordu TLSA w wariancie DANE-EE (Usage 3) oraz skonfigurowanie automatycznej walidacji po stronie klienta. Wdrożenie protokołu DANE eliminuje konieczność ślepego ufania zewnętrznym centrom certyfikacji, przenosząc punkt zaufania na kryptograficznie zabezpieczoną hierarchię DNS. Studenci weryfikują skuteczność zabezpieczenia, wykazując natychmiastowe odrzucenie obcego certyfikatu przez klienta wspierającego DANE.

Rządowe Centrum Bezpieczeństwa (RCB) publikuje ostrzeżenia dla ludności i komunikaty kryzysowe za pośrednictwem oficjalnego portalu informacyjnego portal.rcb.gov.local. W ramach analizy zagrożeń wykazano, że wyspecjalizowane grupy adwersarzy sponsorowane przez wrogie państwa posiadają zdolność wymuszenia na komercyjnym zagranicznym urzędzie CA wystawienia sfałszowanego certyfikatu SSL dla domeny rządowej. W połączeniu z atakiem przejęcia tras BGP (BGP Hijacking) umożliwia to przeprowadzenie niewykrywalnego ataku podszycia się i dystrybucję fałszywych komunikatów alarmowych.

Standardowy model przeglądarek opiera się na magazynie setek zaufanych urzędów certyfikacji (Root CA Store). Jeśli chociaż jedno centrum certyfikacji zostanie skompromitowane lub ulegnie presji politycznej, certyfikat wystawiony przez ten podmiot zostanie uznany przez przeglądarkę za w pełni legalny. Jest to fundamentalna luka architektoniczna, przed którą nie chronią tradycyjne mechanizmy TLS. Jedynym skutecznym rozwiązaniem jest powiązanie tożsamości klucza publicznego z rekordami domeny zarządzanymi bezpośrednio przez właściciela serwisu.

Zespół laboratoryjny wciela się w rolę architektów bezpieczeństwa sieciowego RCB, mających za zadanie zlikwidować podatność poprzez wdrożenie protokołu DANE (DNS-Based Authentication of Named Entities). Studenci uruchamiają serwer DNS BIND9, generują klucze KSK (Key Signing Key) oraz ZSK (Zone Signing Key) i podpisują strefę domenową mechanizmem DNSSEC. Następnie z certyfikatu serwera WWW generują rekord TLSA, określający precyzyjny skrót SHA-256 certyfikatu lub klucza publicznego SPKI.

W fazie weryfikacji studenci przeprowadzają testy walidacyjne: badają odpowiedź serwera DNS narzędziem delv pod kątem flagi ad (Authenticated Data), konfigurują walidator DANE po stronie klienta oraz przeprowadzają kontrolowaną próbę podstawienia certyfikatu wydanego przez inne legalne centrum CA. Eksperyment dowodzi, że mimo formalnej poprawności kryptograficznej fałszywego certyfikatu w łańcuchu X.509, klient DANE natychmiast odrzuca połączenie z powodu niezgodności z wpisem w strefie DNSSEC.

• BIND 9 (wersja 9.16+): serwer nazw DNS z pełną obsługą podpisywania stref kluczami DNSSEC i publikacji rekordów TLSA.
• GnuTLS danetool: oficjalne narzędzie do generowania rekordów TLSA bezpośrednio z plików certyfikatów X.509 i kluczy publicznych.
• BIND delv / dig: wyspecjalizowane narzędzia CLI do inspekcji i weryfikacji łańcucha kryptograficznego zaufania DNSSEC.
• Apache HTTP Server: serwer WWW udostępniający chronioną witrynę z certyfikatem TLS.
• Python 3 (biblioteki dnspython, cryptography): środowisko do budowy autorskiego skryptu walidującego zgodność certyfikatu z rekordem TLSA.
• Suricata NIDS: system inspekcji analizujący pakiety zapytań i odpowiedzi DNS pod kątem integralności wpisów TLSA.

1. Zainstaluj i skonfiguruj serwer BIND 9 na maszynie laboratoryjnej pełniącej rolę autorytatywnego serwera dla domeny rcb.gov.local.
2. Utwórz plik strefy db.rcb.gov.local zawierający podstawowe rekordy SOA, NS, A dla portalu rządowego.
3. Wygeneruj parę kluczy ZSK (Zone Signing Key) algorytmem ECDSAP256SHA256 za pomocą narzędzia dnssec-keygen.
4. Wygeneruj parę kluczy KSK (Key Signing Key) tym samym algorytmem i dołącz klucze publiczne do pliku strefy.
5. Podpisz strefę domenową poleceniem dnssec-signzone, generując podpisany plik strefy z rekordami RRSIG, DNSKEY i NSEC/NSEC3.
6. Skonfiguruj resolver DNS i zweryfikuj poprawność walidacji podpisów strefy za pomocą polecenia delv.
7. Wygeneruj certyfikat X.509 dla serwera WWW portal.rcb.gov.local za pomocą narzędzia OpenSSL.
8. Zainstaluj pakiet gnutls-bin i wygeneruj rekord TLSA dla portu 443 protokołu TCP poleceniem danetool --tlsa-rr.
9. Zastosuj parametry rekordu: Usage 3 (DANE-EE: certyfikat końcowy), Selector 1 (SPKI: klucz publiczny), Matching type 1 (SHA-256).
10. Wprowadź wygenerowany rekord _443._tcp.portal.rcb.gov.local IN TLSA do pliku strefy BIND9.
11. Podpisz ponownie strefę domenową i przeładuj konfigurację serwera DNS za pomocą rndc reload.
12. Odpytaj serwer DNS o rekord TLSA za pomocą polecenia dig TLSA i zweryfikuj obecność flagi ad oraz rekordu RRSIG.
13. Napisz autorski skrypt w języku Python łączący się z serwerem HTTPS, pobierający certyfikat DER i porównujący hasz SPKI z rekordem z DNSSEC.
14. Wygeneruj alternatywny certyfikat dla tej samej nazwy domenowej z innego prywatnego urzędu CA (symulacja certyfikatu Rogue CA).
15. Podmień certyfikat w konfiguracji serwera Apache na certyfikat alternatywny i uruchom skrypt weryfikacyjny.
16. Zarejestruj wykrycie próby podszycia się i odmowę nawiązania połączenia przez skrypt weryfikacyjny DANE.
17. Zdefiniuj regułę Suricata monitorującą integralność zapytań o rekordy TLSA i zweryfikuj jej działanie w logu fast.log.

Format rekordu TLSA w standardzie RFC 6698 składa się z czterech pól: Przeznaczenie certyfikatu (Certificate Usage), Selektor (Selector), Typ dopasowania (Matching Type) oraz Dane asocjacji certyfikatu (Certificate Association Data). W praktyce produkcyjnej najczęściej stosuje się kombinację 3 1 1: Usage 3 (DANE-EE) oznacza przypięcie konkretnego certyfikatu bez wymogu sprawdzania zewnętrznego CA; Selector 1 oznacza przypięcie wyłącznie klucza publicznego SPKI (co umożliwia odnowienie certyfikatu bez zmiany rekordu DNS, o ile klucz prywatny pozostaje ten sam); Matching type 1 oznacza skrót SHA-256.

Do poprawnego działania weryfikacji DNSSEC niezbędne jest skonfigurowanie zaufanej kotwicy (Trust Anchor) w resolverze walidującym. W środowisku laboratoryjnym, w którym strefa rcb.gov.local nie jest delegowana z oficjalnego korzenia, w pliku konfiguracyjnym resolvera lub narzędzia delv należy manualnie wskazać klucz publiczny KSK jako zaufany punkt startowy.

Narzędzie danetool automatycznie ekstrahuje klucz publiczny z certyfikatu i wylicza odpowiedni skrót kryptograficzny. Przykładowa składnia: danetool --tlsa-rr --host portal.rcb.gov.local --load-certificate /etc/ssl/certs/portal.crt --dane-type 3 --selector 1 --match-type 1 generuje gotową linię rekordu zasobowego dla serwera BIND9.

Poniżej przedstawiono przykłady generowania kluczy DNSSEC, wpisów rekordu TLSA w BIND9 oraz kodu autorskiego skryptu weryfikacyjnego w języku Python.

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

1. Zagrożenie ze strony sfałszowanych certyfikatów wystawianych przez skompromitowane komercyjne urzędy certyfikacji.
2. Protokół DANE (RFC 6698) i rola rekordów TLSA w powiązaniu certyfikatu bezpośrednio z domeną w infrastrukturze DNS.
3. Rola protokołu DNSSEC jako kryptograficznego fundamentu zaufania dla integralności i autentyczności rekordów TLSA.
4. Znaczenie parametrów rekordu TLSA: Certificate Usage, Selector oraz Matching Type w precyzyjnym definiowaniu polityki klucza.
5. Procedura bezpiecznej rotacji certyfikatów serwera WWW bez przerw w dostępie: podwójna publikacja rekordu TLSA w strefie DNS.
6. Odporność portali informacyjnych administracji publicznej na zaawansowane ataki podszywania się sponsorowane przez obce służby specjalne.

Przykładowe wnioski (wzór do sprawozdania): Wdrożenie protokołu DANE popartego kryptograficznie podpisaną strefą DNSSEC całkowicie uniezależniło portal Rządowego Centrum Bezpieczeństwa od podatności globalnego ekosystemu komercyjnych urzędów CA. Rekord TLSA o parametrach 3 1 1 powiązał klucz publiczny serwera bezpośrednio ze strefą domenową instytucji, uniemożliwiając atakującym podstawienie sfałszowanego certyfikatu wystawionego przez przejęte centrum certyfikacji. Próba przechwycenia sesji za pomocą obcego, choć formalnie poprawnego certyfikatu SSL zakończyła się natychmiastowym odrzuceniem połączenia przez klienta weryfikującego wpis DANE. Zastosowanie podwójnej publikacji rekordów TLSA w okresie przejściowym zagwarantowało płynną rotację kluczy serwera bez zakłóceń w dostępie dla obywateli. Uzyskana architektura zaufania spełnia najwyższe rygory suwerenności cyfrowej państwa w ochronie strategicznych kanałów ostrzegania ludności.

Zadanie bazuje na treściach Wykładu 1 oraz Wykładu 4, dotyczących systemów zapór aplikacyjnych Web Application Firewall (WAF), analizy sygnaturowej i behawioralnej oraz technik zaciemniania kodu i ładunków ataku. Ćwiczenie weryfikuje efekty uczenia się: W1 (znajomość wektorów omijania zapór aplikacyjnych za pomocą anomalii kodowania i manipulacji leksykalnych), U1 (konstrukcja autorskich skryptów testujących weryfikację wektorów SQLi i XSS), U3 (analiza drzewa składniowego zapytania i wielopoziomowe dekodowanie ciągów), U4 (programowanie rozszerzeń inspekcyjnych w języku Lua dla silnika ModSecurity v3) oraz K2 (krytyczna weryfikacja skuteczności komercyjnych i otwartych baz reguł WAF). Wymagania techniczne i normatywne obejmują reguły OWASP Core Rule Set (CRS v3/v4), klasyfikację podatności CWE-116 (Improper Encoding or Escaping of Output), standardy OWASP Top 10 A03:2021 (Injection) oraz techniki matrycy MITRE ATT&CK: T1027 (Obfuscated/Encoded Information) i T1190 (Exploit Public-Facing Application).

Celem zadania jest zbadanie podatności zapory aplikacyjnej ModSecurity z domyślnym zestawem reguł OWASP CRS na ominięcie detekcji przy użyciu złożonych technik obfuskacji danych. Zespół studentów wciela się w rolę audytorów Red Team, badając skuteczność technik wielobajtowego kodowania Unicode, wstrzykiwania komentarzy bazodanowych wewnątrz słów kluczowych oraz manipulacji kodowaniem URL. Eksperyment dowodzi, że proste dopasowanie sygnaturowe nie zapewnia ochrony przed zdeterminowanym adwersarzem.

W części defensywnej celem jest zaprojektowanie i wdrożenie autorskiego modułu deobfuskacji napisanego w języku Lua i zintegrowanego z silnikiem ModSecurity za pomocą dyrektywy SecRuleScript. Moduł ten realizuje rekurencyjne dekodowanie, normalizację znaków diakrytycznych oraz usunięcie komentarzy przed przekazaniem ładunku do silnika reguł. Studenci weryfikują skuteczność wdrożonego rozwiązania, wykazując zablokowanie zaciemnionego zapytania kodem HTTP 403 oraz rejestrację szczegółowej telemetrii w dzienniku audytowym.

Centralny Węzeł Ewidencji Państwowej udostępnia rejestry publiczne dla autoryzowanych instytucji administracji samorządowej i wymiaru sprawiedliwości. W celu ochrony strategicznej bazy danych przed atakami wstrzykiwania kodu (SQL Injection) przed aplikacją wdrożono zaporę ModSecurity ze standardową konfiguracją OWASP ModSecurity Core Rule Set na poziomie anomalii (Anomaly Scoring Mode). Rozwiązanie to miało w założeniu uniemożliwić wykonanie jakichkolwiek złośliwych zapytań SQL.

Podczas zewnętrznego audytu bezpieczeństwa eksperci wykazali, że standardowe reguły OWASP CRS opierają się na założeniu, że zapytanie HTTP przesyłane jest w znormalizowanej postaci tekstowej. Zastosowanie nietypowych technik obfuskacji – takich jak kodowanie wielobajtowe IIS Unicode (%u0027 zamiast apostrofu), przeplatanie słów kluczowych komentarzami wieloliniowymi (SEL/*pomoc*/ECT) czy wielokrotne kodowanie procentowe – pozwala na ominięcie filtrów WAF, podczas gdy silnik bazy danych na zapleczu bez problemu wykonuje zrekonstruowane zapytanie.

Zespół laboratoryjny podejmuje zadanie przeprowadzenia kontrolowanej symulacji ominięcia zapory WAF (WAF Evasion). Studenci przygotowują skrypt w języku Python wysyłający serię ładunków testowych o różnym stopniu zaciemnienia, dokumentując, które zapytania zostały zablokowane kodem 403, a które dotarły do bazy danych z kodem 200 OK. Pomiary pozwalają na wyznaczenie rzeczywistej skuteczności domyślnej ochrony sygnaturowej.

Kolejnym krokiem jest inżynieria wieloaspektowego mechanizmu inspekcji. Zamiast dopisywać setki nowych wyrażeń regularnych, studenci programują autorski filtr w języku Lua uruchamiany w fazie analizy żądania. Skrypt normalizuje dane wejściowe: usuwa komentarze składniowe, zamienia alternatywne reprezentacje znaków na ich formy kanoniczne i przekazuje zdekodowany bufor do ponownej weryfikacji. Re-test z użyciem złośliwych ładunków potwierdza pełną szczelność zmodernizowanego systemu WAF.

• Apache HTTP Server z modułem mod_security2: środowisko serwera WWW z aktywnym silnikiem zapory aplikacyjnej WAF.
• OWASP ModSecurity Core Rule Set (CRS): zestaw oficjalnych reguł detekcji ataków webowych.
• Język Lua (wersja 5.3 lub 5.4) z biblioteką liblua: środowisko skryptowe zintegrowane z ModSecurity do programowania autorskich filtrów.
• Python 3 (biblioteka requests): środowisko do generowania wielowariantowych ładunków z technikami obfuskacji.
• SQLMap: narzędzie automatycznego audytu wstrzykiwania SQL z opcją stosowania skryptów tamperujących (--tamper).
• cURL / Burp Suite Community: narzędzia do manualnej analizy zapytań i nagłówków HTTP.

1. Zainstaluj pakiet libapache2-mod-security2 oraz zestaw reguł modsecurity-crs na serwerze laboratoryjnym Linux.
2. Włącz silnik zapory, ustawiając w pliku modsecurity.conf dyrektywę SecRuleEngine On oraz zdefiniuj domyślną reakcję SecDefaultAction.
3. Dołącz reguły OWASP Core Rule Set do konfiguracji Apache i przeładuj usługę serwera WWW.
4. Przygotuj prostą aplikację testową w PHP/Python podatną na klasyczne wstrzyknięcie SQL w parametrze id.
5. Wyślij klasyczne zapytanie SQLi ' OR 1=1-- i zweryfikuj natychmiastowe zablokowanie żądania kodem HTTP 403 Forbidden.
6. Przeanalizuj wpis w dzienniku /var/log/apache2/modsec_audit.log, identyfikując naruszoną regułę CRS (np. 942100).
7. Opracuj autorski skrypt w języku Python wysyłający zapytanie z komentarzami wewnątrz słów kluczowych: UNI/*x*/ON SEL/*x*/ECT.
8. Wyślij zapytanie z wielobajtowym kodowaniem znaków oraz fragmentacją parametrów w formularzu POST.
9. Zarejestruj ominięcie filtrów WAF: serwer zwraca kod HTTP 200 OK i wykonuje zapytanie w bazie danych.
10. Napisz autorski skrypt w języku Lua deobfuscate.lua realizujący rekurencyjne dekodowanie URL oraz czyszczenie komentarzy SQL.
11. Zaimplementuj w skrypcie Lua funkcję normalizującą ciągi znaków i zwracającą przekształconą wartość do zmiennej TXT.
12. Zarejestruj skrypt Lua w konfiguracji ModSecurity za pomocą dyrektywy SecRuleScript /etc/modsecurity/deobfuscate.lua.
13. Zdefiniuj dodatkową regułę SecRule sprawdzającą znormalizowany bufor pod kątem obecności słów kluczowych SQL.
14. Zrestartuj serwer Apache i ponownie uruchom skrypt atakujący w Pythonie z ładunkiem zaciemnionym.
15. Wykaż w dzienniku modsec_audit.log wykrycie i zablokowanie ataku po uprzedniej normalizacji przez skrypt Lua.
16. Przeprowadź test za pomocą narzędzia sqlmap ze skryptami tamperującymi --tamper=between,charencode,randomcase i oceń skuteczność.
17. Opracuj dokumentację porównawczą wykazującą odporność WAF przed i po wdrożeniu inspekcji opartej na języku Lua.

Podstawowym problemem w sygnaturowej analizie WAF jest rozbieżność w interpretacji składni (Impedance Mismatch) pomiędzy zaporą a docelowym interpreterem aplikacji lub bazy danych. Na przykład silnik bazy danych MySQL traktuje sekwencję /*!50000SELECT*/ jako legalne słowo kluczowe SELECT, podczas gdy standardowe wyrażenie regularne WAF szukające słowa SELECT oddzielonego spacją może pominąć taki fragment. Zastosowanie języka Lua wewnątrz ModSecurity umożliwia wstępne przekształcenie danych do postaci kanonicznej przed dopasowaniem wzorców.

Integracja skryptów Lua z ModSecurity odbywa się za pomocą operatora SecRuleScript. Skrypt Lua musi definiować funkcję główną przyjmującą obiekt żądania ModSecurity i zwracającą wartość nil w przypadku braku naruszenia lub komunikat błędu wyzwalający akcję blokującą. Umożliwia to wykonywanie dowolnie złożonych operacji algorytmicznych, takich jak obliczanie entropii ciągu, parsowanie struktur JSON czy wielopoziomowe dekodowanie ciągów binarnych.

Warto zwrócić uwagę na flagi transformacji w ModSecurity, takie jak t:urlDecode, t:urlDecodeUni, t:lowercase czy t:removeWhitespace. Chociaż reguły CRS stosują łańcuchy transformacji, pojedyncza flaga rzadko radzi sobie z wielokrotnie zagnieżdżonym kodowaniem, dlatego dedykowany skrypt deobfuskacji stanowi najpewniejszą linię obrony.

Poniżej przedstawiono przykłady konfiguracji ModSecurity, skryptu testującego ominięcie zapory oraz implementacji autorskiego filtra deobfuskacji w języku Lua.

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

1. Techniki omijania zapór aplikacji internetowych: zagnieżdżone komentarze SQL, kodowanie wielokrotne oraz nietypowe białe znaki.
2. Ograniczenia domyślnych zestawów reguł OWASP Core Rule Set na niskich poziomach paranoi w zaporach WAF.
3. Konstrukcja zaawansowanych reguł ModSecurity v3 z wieloetapową transformacją ciągów wejściowych.
4. Wykorzystanie zmiennych kolekcji anomalii oraz precyzyjne definiowanie progów blokowania niebezpiecznych żądań HTTP.
5. Metodyka testowania skuteczności reguł WAF za pomocą zautomatyzowanych narzędzi fuzzingu i skryptów tamperujących.
6. Ochrona strategicznych rejestrów publicznych przed zaawansowanymi atakami eksfiltracji baz danych w środowiskach o podwyższonym ryzyku.

Przykładowe wnioski (wzór do sprawozdania): Laboratoryjna weryfikacja zapory ModSecurity wykazała, że domyślny poziom paranoi reguł OWASP CRS pozwala na ominięcie detekcji SQL Injection za pomocą techniki zagnieżdżonych komentarzy i wielokrotnego kodowania URL. Użycie skryptu tamperującego w narzędziu sqlmap umożliwiło napastnikowi bezkarne odpytanie bazy danych ewidencji państwowej bez aktywowania blokady WAF. W odpowiedzi podniesiono poziom paranoi do drugiego stopnia oraz opracowano autorską regułę inspekcji z wieloetapową transformacją dekodującą znormalizowane parametry wejściowe. Nowy filtr wykrywa nieliniowe sekwencje słów kluczowych i natychmiast nalicza punkty anomalii przekraczające próg krytyczny, co skutkuje odrzuceniem pakietu z kodem HTTP 403. Wdrożone dostrojenie zapory skutecznie zamknęło lukę w warstwie filtracji aplikacyjnej, zabezpieczając krytyczne rejestry przed nieautoryzowanym wyciekiem.

Zadanie nawiązuje do Wykładu 3, poświęconego infrastrukturze klucza publicznego, transparentności operacji urzędów CA oraz kryptograficznym strukturom danych wykorzystywanym w audycie zaufania publicznego. Ćwiczenie weryfikuje efekty kształcenia: W4 (znajomość standardu Certificate Transparency RFC 6962, struktury drzew skrótów Merkle'a oraz znaczników SCT), U1 (budowa wielowątkowego lub asynchronicznego skryptu w języku Python parsującego strumienie danych JSON z logów CT), U2 (implementacja mechanizmów dopasowania domen i subdomen w oparciu o wyrażenia regularne), U3 (integracja alertów audytowych z systemem monitorowania SOC i bazą SIEM) oraz K1 (proaktywne podejście do wczesnego ostrzegania przed zagrożeniami wizerunkowymi i teleinformatycznymi). Wymagania normatywne obejmują standardy IETF RFC 6962 (Certificate Transparency), IETF RFC 8659 (DNS CAA), normę PN-EN ISO/IEC 27001:2022 w zakresie kontroli A.8.16 (Monitorowanie działań) oraz techniki MITRE ATT&CK: T1588.004 i T1584.004.

Celem zadania jest zaprojektowanie, oprogramowanie i wdrożenie automatycznego demona monitorującego publiczne logi Certificate Transparency (CT) w czasie rzeczywistym w celu wykrywania nieautoryzowanych certyfikatów SSL dla domen organizacji. Studenci badają wektor zagrożenia związany z powstawaniem niezatwierdzonych certyfikatów przez działy Shadow IT, zewnętrznych podwykonawców lub wrogie podmioty przygotowujące infrastrukturę phishingową. Zespół przeprowadza symulację emisji nieautoryzowanego certyfikatu i bada czas reakcji systemu detekcji.

W części inżynierskiej studenci tworzą skrypt w języku Python integrujący się z interfejsem API rejestrów CT, filtrujący wpisy dotyczące monitorowanych domen państwowych oraz weryfikujący zgodność wystawcy certyfikatu z polityką bezpieczeństwa. Dodatkowo studenci konfigurują rekordy DNS CAA (Certificate Authority Authorization) ograniczające listę uprawnionych centrów certyfikacji. Końcowym efektem jest działający system wczesnego ostrzegania, alarmujący analityków SOC w czasie poniżej kilkudziesięciu sekund od rejestracji nieautoryzowanego certyfikatu w globalnym rejestrze.

Krajowy Operator Systemu Płatności zarządza domeną platnosci.pl oraz rozległą strukturą subdomen transakcyjnych i bankowych. W przeszłości w organizacji miał miejsce poważny incydent bezpieczeństwa: zewnętrzny wykonawca oprogramowania bez porozumienia z zespołem ds. cyberbezpieczeństwa wygenerował w darmowym centrum CA certyfikat SSL dla serwera deweloperskiego api-dev.platnosci.pl. Serwer ten posiadał nieskorygowane podatności, co doprowadziło do kompromitacji danych testowych.

Dodatkowo analitycy Threat Intelligence ostrzegają przed kampaniami podszywania się pod markę instytucji poprzez rejestrację certyfikatów dla subdomen łudząco podobnych (typosquatting). Ponieważ współczesne przeglądarki bezwzględnie wymagają obecności każdego publicznego certyfikatu w co najmniej dwóch niezależnych logach Certificate Transparency (zgodnie z RFC 6962), globalne logi CT stanowią idealne źródło informacji wywiadowczej w czasie zbliżonym do rzeczywistego.

Zespół laboratoryjny wciela się w rolę inżynierów operacyjnych SOC, których zadaniem jest zbudowanie dedykowanego systemu monitoringu CT. Studenci konstruują aplikację w języku Python odpytującą strumień zdarzeń CT, parsującą pola Common Name oraz Subject Alternative Names (SAN), a także badającą tożsamość urzędu certyfikacji (Issuer Organization). Każde wykrycie certyfikatu wystawionego przez podmiot inny niż oficjalne centrum certyfikacji instytucji natychmiast generuje alert krytyczny.

W fazie testów laboratoryjnych studenci przeprowadzają kontrolowaną emisję certyfikatu dla subdomeny testowej w publicznym urzędzie certyfikacji (lub w lokalnym symulatorze logu CT). Mierzą czas od momentu emisji do pojawienia się wpisu w logu monitora, sprawdzają format generowanego alertu w formacie Sigma oraz konfigurują rekordy DNS CAA w strefie BIND9, blokując wystawianie certyfikatów przez nieautoryzowane centra CA.

• Python 3 (biblioteki requests, json, time, re, threading): środowisko wykonawcze autorskiego demona monitorującego strumień Certificate Transparency.
• Rejestry Certificate Transparency API (crt.sh / certstream): otwarte punkty dostępowe umożliwiające inspekcję wpisów w globalnych logach CT.
• OpenSSL: narzędzie do inspekcji certyfikatów X.509, ekstrakcji pól SAN i analizy odcisków palców SHA-256.
• BIND 9: serwer DNS do publikacji i testowania rekordów autoryzacji CAA (RFC 8659).
• Wazuh Agent / rsyslog: usługa rejestracji i przekazywania logów audytowych do systemu SIEM.
• Sigma CLI: narzędzie do walidacji reguł detekcji incydentów nieautoryzowanej emisji certyfikatu.

1. Zapoznaj się ze strukturą wpisu Certificate Transparency w standardzie RFC 6962 oraz rolą kryptograficznych drzew Merkle'a.
2. Zbadaj format danych zwracanych przez otwarte interfejsy API rejestrów CT (np. format JSON z serwisu crt.sh).
3. Zaprojektuj strukturę modułu w języku Python utrzymującego pamięć podręczną wcześniej zidentyfikowanych identyfikatorów certyfikatów.
4. Napisz kod funkcji pobierającej nowe wpisy dla monitorowanej domeny instytucji (np. *.platnosci.pl).
5. Zaimplementuj parser ekstrahujący nazwę podmiotu (Common Name), listę alternatywnych nazw (SAN), wystawcę (Issuer) oraz znacznik czasu.
6. Zdefiniuj białą listę autoryzowanych urzędów certyfikacji dopuszczonych przez politykę bezpieczeństwa organizacji.
7. Skonstruuj logikę alarmowania, porównującą wystawcę każdego nowego certyfikatu z białą listą urzędów CA.
8. Zaimplementuj mechanizm zapisu alertów do pliku /var/log/ct_alerts.log w ustrukturyzowanym formacie JSON/Syslog.
9. Zdefiniuj regułę Sigma mapującą komunikaty o wykryciu nieautoryzowanego certyfikatu do kategorii Initial Access.
10. Uruchom demona w tle i zweryfikuj stabilność cyklicznego odpytywania rejestru logów CT.
11. Zasymuluj rejestrację nowego certyfikatu dla subdomeny shadow-it.platnosci.pl w środowisku testowym.
12. Zarejestruj czas reakcji demona od momentu publikacji certyfikatu do wyświetlenia czerwonego alertu w konsoli SOC.
13. Skonfiguruj rekord DNS CAA w pliku strefy domeny, zezwalając wyłącznie na emisję przez jedno zatwierdzone centrum certyfikacji.
14. Dodaj dyrektywę iodef w rekordzie CAA wskazującą adres e-mail zespołu reagowania na incydenty CSIRT.
15. Zweryfikuj obecność i poprawność rekordu CAA za pomocą narzędzia dig CAA platnosci.pl.
16. Przetestuj próbę wygenerowania certyfikatu w alternatywnym CA i zaobserwuj odmowę wystawienia wynikającą z rekordu CAA.
17. Opracuj raport powdrożeniowy zawierający listing kodu demona, zrzut ekranu wykrycia incydentu oraz analizę ryzyka.

Ekosystem Certificate Transparency powstał w celu wyeliminowania niewykrywalnych fałszerstw certyfikatów SSL. Każdy certyfikat wydany przez publiczne centrum certyfikacji musi trafić do niezmienialnego, publicznego rejestru opartego o kryptograficzne drzewo skrótów Merkle'a (Merkle Hash Tree). W zamian centrum CA otrzymuje kryptograficzny znacznik SCT (Signed Certificate Timestamp), który musi zostać dołączony do certyfikatu lub uścisku dłoni TLS. Dzięki temu administratorzy domen mogą w czasie rzeczywistym dowiedzieć się o każdym wystawionym certyfikacie na świecie.

Tworząc skrypt monitorujący w języku Python, warto zabezpieczyć aplikację przed przekroczeniem limitów zapytań (Rate Limiting) ze strony publicznych interfejsów API. W środowisku produkcyjnym zaleca się korzystanie ze strumieni WebSocket (np. serwis Certstream), które przesyłają nowe wpisy w trybie Push natychmiast po ich pojawieniu się w logu, co redukuje opóźnienie detekcji do ułamków sekund.

Rekord DNS CAA (RFC 8659) stanowi kluczowe defensywne uzupełnienie monitoringu CT. Wpis CAA informuje wszystkie zgodne z prawem centra certyfikacji, które podmioty posiadają upoważnienie do generowania certyfikatów dla danej strefy. Jeśli napastnik spróbuje wygenerować certyfikat w obcym CA, to centrum ma bezwzględny obowiązek odpytać DNS o rekord CAA i odmówić transakcji, wysyłając powiadomienie na adres zdefiniowany w tagu iodef.

Poniżej przedstawiono listing autorskiego skryptu monitorującego CT w języku Python, strukturę reguły Sigma oraz poprawną składnię rekordu DNS CAA w strefie BIND9.

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

1. Architektura systemu Certificate Transparency: publiczne, niezmienne rejestry logów i znaczniki Signed Certificate Timestamps.
2. Zagrożenie wynikające z cichego generowania nieautoryzowanych certyfikatów SSL dla subdomen korporacyjnych przez podwykonawców.
3. Budowa narzędzia monitorującego w języku Python zintegrowanego ze strumieniem WebSocket serwisu Certificate Transparency.
4. Implementacja filtrów wyrażeń regularnych dopasowujących domeny, subdomeny oraz odmiany homograficzne w nazwach domenowych.
5. Automatyzacja powiadomień o wykrytych anomaliach w certyfikatach za pośrednictwem webhooków do systemu SOC.
6. Wdrożenie polityki Certificate Authority Authorization w strefie DNS w celu prewencyjnego ograniczenia uprawnionych urzędów CA.

Przykładowe wnioski (wzór do sprawozdania): Zaprojektowanie i uruchomienie skryptu monitorującego publiczne logi Certificate Transparency w czasie rzeczywistym pozwoliło na natychmiastowe wykrywanie nieautoryzowanych certyfikatów wystawianych dla domeny płatniczej. W trakcie testów narzędzie oparte na strumieniu Certstream zidentyfikowało nowo wygenerowany certyfikat testowy dla subdomeny deweloperskiej w niespełna dwie sekundy od momentu jego zarejestrowania w logu. Równolegle skonfigurowano reguły wykrywające próby phishingu oparte na rejestracji łudząco podobnych domen wykorzystujących znaki cyrylicy. Otrzymane alerty zostały zintegrowane za pośrednictwem webhooka z systemem SIEM, umożliwiając zespołowi SOC podjęcie natychmiastowych działań unieważniających. Wdrożenie rekordu DNS CAA dodatkowo zablokowało nieuprawnionym urzędom certyfikacji możliwość technicznego przetwarzania wniosków dla infrastruktury operatora płatności.

Zadanie bazuje na Wykładzie 3 oraz Wykładzie 5, obejmujących zagadnienia bezpiecznego składowania kluczy kryptograficznych, standardu Cryptographic Token Interface (PKCS#11) oraz ochrony danych w spoczynku i w pamięci operacyjnej. Ćwiczenie weryfikuje efekty uczenia się: W4 (dogłębna znajomość architektury sprzętowych i programowych modułów HSM oraz zasad działania interfejsu PKCS#11), U1 (zarządzanie tokenami kryptograficznymi za pomocą softhsm2-util oraz pkcs11-tool), U2 (generowanie nieeksportowalnych kluczy asymetrycznych bezpośrednio wewnątrz tokenu), U4 (integracja serwera Apache z silnikiem OpenSSL Engine PKCS#11 bez używania plików kluczy na dysku) oraz K1 (odpowiedzialność za ochronę krytycznych poświadczeń tożsamości cyfrowej w infrastrukturze krytycznej). Wymagania normatywne obejmują standard OASIS PKCS#11 v3.0, normę NIST FIPS PUB 140-3, wymagania PCI DSS v4.0 (wymóg 3: Ochrona przechowywanych danych) oraz techniki MITRE ATT&CK: T1552.004 i T1003.

Głównym celem inżynierskim zadania jest całkowite wyeliminowanie obecności jawnych plików kluczy prywatnych TLS z systemu plików serwera WWW poprzez integrację serwera Apache z modułem HSM opartym o oprogramowanie SoftHSM2 i interfejs PKCS#11. Zespół studentów analizuje klasyczną architekturę serwerową, w której klucz server.key znajduje się w katalogu /etc/ssl/private, wykazując, że w przypadku podatności RCE lub eskalacji uprawnień intruz z łatwością wykrada klucz. Taki wyciek prowadzi do całkowitej utraty poufności komunikacji oraz umożliwia odszyfrowanie zarejestrowanego wcześniej ruchu przez nieuprawnione podmioty.

W części wdrożeniowej studenci inicjalizują kryptograficzny token bezpieczeństwa, generują parę kluczy RSA z atrybutem uniemożliwiającym ich ekstrakcję (CKA_EXTRACTABLE=FALSE) oraz konfigurują bibliotekę libp11. Następnie konfigurują serwer Apache tak, aby odwoływał się do klucza za pomocą zunifikowanego identyfikatora PKCS#11 URI, a wszelkie operacje podpisywania uścisku TLS odbywały się wewnątrz odizolowanego modułu SoftHSM2. Studenci weryfikują odporność rozwiązania, demonstrując niemożliwość odczytania klucza z poziomu roota. Eksperyment potwierdza zgodność wdrożonego rozwiązania z wymaganiami standardu PCI DSS oraz normy ISO/IEC 27001.

Krajowa Izba Rozliczeniowa przetwarza poufne dyspozycje przelewów międzybankowych za pośrednictwem centralnego węzła HTTPS. Zgodnie z rygorystycznymi wymogami międzynarodowego standardu bezpieczeństwa danych kart płatniczych PCI DSS v4.0 oraz zaleceniami Komisji Nadzoru Finansowego, klucze prywatne wykorzystywane do uwierzytelniania serwerów finansowych nie mogą być składowane w postaci jawnego pliku w pamięci masowej systemu operacyjnego.

Dotychczasowa konfiguracja serwera opierała się na tradycyjnym pliku /etc/ssl/private/bank.key chronionym wyłącznie uprawnieniami 0600 systemu Linux. Zespół audytorski podczas testów penetracyjnych wykazał, że wykorzystanie luki w aplikacji webowej (Local File Inclusion / Path Traversal) pozwala na bezpośredni odczyt pliku klucza. Posiadając klucz prywatny, napastnik był w stanie deszyfrować nagrany ruch sieciowy oraz uruchomić fałszywy serwer bankowy w środowisku zewnętrznym.

W celu usunięcia podatności zespół laboratoryjny otrzymuje zadanie wdrożenia programowego modułu HSM (SoftHSM2) emulującego działanie sprzętowego modułu kryptograficznego zgodnego ze standardem PKCS#11. Klucz prywatny serwera zostaje wygenerowany bezpośrednio wewnątrz kryptograficznego kontenera tokenu z ustawioną na stałe flagą uniemożliwiającą jego odczyt i ekstrakcję. Dostęp do operacji kryptograficznych wymaga podania kodu PIN użytkownika tokenu.

Studenci konfigurują moduł mod_ssl serwera Apache oraz silnik libp11, zastępując ścieżkę do pliku klucza bezpiecznym identyfikatorem PKCS#11 URI (np. pkcs11:token=KIR_HSM;object=bank_tls). Następnie wykonują testy funkcjonalne: nawiązują bezpieczne połączenia HTTPS, badają obciążenie procesora oraz przeprowadzają kontrolowaną próbę odczytania klucza prywatnego z pamięci procesu i dysku twardego, potwierdzając pełną hermetyzację materiału kluczowego.

• SoftHSM2 (narzędzie softhsm2-util): otwarta implementacja kryptograficznego tokenu programowego zgodnego ze standardem PKCS#11.
• OpenSC (narzędzie pkcs11-tool): pakiet narzędziowy do niskopoziomowego zarządzania obiektami wewnątrz tokenów kryptograficznych.
• libp11 / OpenSSL PKCS#11 Engine: biblioteka łącznikowa umożliwiająca aplikacjom OpenSSL korzystanie z tokenów PKCS#11.
• Apache HTTP Server 2.4 z mod_ssl: serwer WWW wspierający konfigurację kluczy poprzez identyfikatory PKCS#11 URI.
• OpenSSL 3.x: narzędzie do generowania żądań CSR i podpisywania certyfikatów w oparciu o token HSM.
• GDB / strace: narzędzia diagnostyczne do weryfikacji braku obecności jawnego klucza w pamięci i wywołaniach systemowych.

1. Zainstaluj pakiety softhsm2, softhsm2-common, opensc oraz libengine-pkcs11-openssl na maszynie Linux.
2. Skonfiguruj plik /etc/softhsm/softhsm2.conf, definiując bezpieczną lokalizację bazy danych tokenów tokenbase.
3. Zainicjalizuj nowy token kryptograficzny o nazwie KIR_TOKEN poleceniem softhsm2-util --init-token.
4. Zdefiniuj silny kod PIN administratora bezpieczeństwa (Security Officer PIN) oraz PIN użytkownika (User PIN).
5. Zweryfikuj dostępność zainicjalizowanego slotu kryptograficznego poleceniem pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so -L.
6. Wygeneruj 3072-bitową parę kluczy RSA bezpośrednio wewnątrz tokenu z atrybutem uniemożliwiającym ekstrakcję CKA_EXTRACTABLE=FALSE.
7. Wylistuj obiekty wewnątrz tokenu poleceniem pkcs11-tool -O i sprawdź atrybuty wygenerowanego klucza prywatnego i publicznego.
8. Skonfiguruj plik openssl.cnf, dodając sekcję silnika engine pkcs11 wskazującą moduł libsofthsm2.so.
9. Wygeneruj żądanie podpisania certyfikatu (CSR) dla domeny bank.kir.local za pomocą klucza w tokenie, używając identyfikatora PKCS#11 URI.
10. Podpisz certyfikat za pomocą urzędu certyfikacji CA i zapisz plik bank.crt w katalogu serwera.
11. Skonfiguruj wirtualny host Apache, ustawiając w dyrektywie SSLCertificateFile ścieżkę do certyfikatu publicznego.
12. Zdefiniuj w dyrektywie SSLCertificateKeyFile precyzyjny identyfikator PKCS#11 URI odwołujący się do obiektu w tokenie.
13. Skonfiguruj bezpieczne przekazywanie kodu PIN do modułu Apache (np. poprzez mechanizm SSLPassPhraseDialog).
14. Uruchom serwer Apache i zweryfikuj w logu error.log pomyślne załadowanie silnika PKCS#11 i powiązanie z tokenem.
15. Nawiąż połączenie HTTPS narzędziem openssl s_client i potwierdź poprawne wykonanie uścisku dłoni TLS.
16. Przeprowadź symulację przełamania systemu: zaloguj się na konto roota i podejmij próbę odczytania klucza za pomocą pkcs11-tool --read-object.
17. Zarejestruj błąd odmowy CKR_ATTRIBUTE_SENSITIVE / CKR_ACTION_PROHIBITED, potwierdzający pełną ochronę HSM.

Standard PKCS#11 definiuje zunifikowany interfejs programistyczny API dla urządzeń kryptograficznych. Kluczowym mechanizmem bezpieczeństwa jest atrybut CKA_EXTRACTABLE. Ustawienie wartości tego atrybutu na FALSE podczas generowania pary kluczy powoduje, że moduł HSM trwale odrzuca jakiekolwiek próby wyeksportowania klucza prywatnego na zewnątrz, nawet przy podaniu poprawnego kodu PIN. Oznacza to, że klucz nigdy nie opuszcza kontenera kryptograficznego, a serwer WWW przesyła do tokenu jedynie skrót kryptograficzny wiadomości do podpisania.

Format identyfikatora PKCS#11 URI jest ustandaryzowany w dokumencie RFC 7512. Przykładowa składnia stosowana w dyrektywie SSLCertificateKeyFile ma postać: "pkcs11:token=KIR_TOKEN;object=bank_key;type=private?pin-value=1234". W środowiskach produkcyjnych kod PIN nie powinien być wpisywany jawnym tekstem w konfiguracji – zaleca się stosowanie skryptu pobierającego hasło z bezpiecznego magazynu (np. systemd-ask-password lub skrypt powłoki zintegrowany z chronionym potokiem).

Aby silnik OpenSSL Engine w serwerze Apache mógł korzystać z modułu SoftHSM2, użytkownik systemowy serwera WWW (zazwyczaj www-data) musi posiadać uprawnienia do odczytu i zapisu katalogu, w którym SoftHSM2 składuje pliki tokenów (domyślnie /var/lib/softhsm/tokens/). Brak tych uprawnień jest najczęstszą przyczyną błędów inicjalizacji modułu podczas startu usługi Apache.

Poniżej przedstawiono przykłady poleceń inicjalizacji tokenu SoftHSM2, konfiguracji Apache z identyfikatorem PKCS#11 URI oraz dowodu odmowy ekstrakcji klucza.

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

1. Wymagania normy PCI DSS v4.0 oraz wytycznych KNF w zakresie izolacji kluczy kryptograficznych w modułach sprzętowych.
2. Standard kryptograficzny PKCS#11 jako ujednolicony interfejs programistyczny do komunikacji z modułami HSM.
3. Konfiguracja programowego emulatora HSM (SoftHSM2): inicjalizacja slotu i generowanie niewywłaszczalnych kluczy RSA.
4. Integracja serwera Apache z silnikiem OpenSSL PKCS#11 za pomocą znormalizowanych identyfikatorów PKCS#11 URI.
5. Ochrona klucza prywatnego przed bezpośrednią ekstrakcją z pamięci serwera WWW w przypadku podatności aplikacyjnych.
6. Aspekty wydajnościowe i procedury tworzenia bezpiecznych kopii zapasowych kluczy w modułach bezpieczeństwa.

Przykładowe wnioski (wzór do sprawozdania): Integracja serwera Apache z modułem kryptograficznym za pośrednictwem standardu PKCS#11 całkowicie odizolowała klucz prywatny serwera od systemu plików i pamięci operacyjnej systemu Linux. Wygenerowanie klucza z atrybutem uniemożliwiającym jego wyeksportowanie zagwarantowało, że nawet pełna kompromitacja konta roota nie pozwoli napastnikowi na skopiowanie klucza na zewnątrz. Wszystkie operacje kryptograficzne podpisu podczas negocjacji sesji TLS są delegowane do dedykowanego modułu, a serwer posługuje się wyłącznie standaryzowanym adresem PKCS#11 URI. Pomiary wydajnościowe wykazały stabilną pracę węzła przy znikomym narzucie czasowym, w pełni odpowiadającym dynamice rozliczeń międzybankowych. Zastosowane rozwiązanie stanowi wzorcową realizację rygorystycznych wymogów bezpieczeństwa określonych w standardzie PCI DSS v4.0 oraz Rekomendacji D KNF.

Zadanie opiera się na treściach Wykładu 1 oraz Wykładu 4, dotyczących nowoczesnych modeli bezpieczeństwa Zero Trust, pasywnego fingerprintowania ruchu szyfrowanego oraz metod detekcji zautomatyzowanych narzędzi adwersarza. Ćwiczenie weryfikuje efekty kształcenia: W1 (znajomość technik maskowania tożsamości narzędzi hackerskich poprzez manipulację nagłówkami warstwy aplikacji), W4 (matematyczny i techniczny mechanizm obliczania haszy JA3 oraz standardu JA4 na podstawie parametrów pakietu ClientHello), U1 (konstrukcja narzędzi do ekstrakcji i analizy odcisków TLS z surowych pakietów sieciowych), U2 (wdrożenie reguł dynamicznej filtracji na bramie pośredniczącej w oparciu o profil klienta), U4 (opracowanie sygnatur Suricata korelujących warstwę TLS z nagłówkami HTTP) oraz K2 (odrzucenie pozornych zabezpieczeń bazujących na zaufaniu do deklaratywnych nagłówków przesyłanych przez klienta). Wymagania normatywne obejmują wytyczne NIST Special Publication 800-207 (Zero Trust Architecture), specyfikację JA3/JA4 Fingerprinting, klasyfikację CWE-290 (Authentication Bypass by Spoofing) oraz techniki MITRE ATT&CK: T1071.001 i T1036 (Masquerading).

Celem zadania jest zaprojektowanie, wdrożenie i przetestowanie bramy pośredniczącej Identity-Aware Proxy (IAP) działającej w paradygmacie Zero Trust, wykorzystującej pasywne profilowanie odcisków TLS (JA3 oraz JA4 Fingerprinting). Zespół studentów bada słabości tradycyjnych filtrów aplikacyjnych, które polegają na weryfikacji nagłówka User-Agent. Studenci demonstrują, jak zautomatyzowane skrypty adwersarza z łatwością omijają zabezpieczenia poprzez podszywanie się pod oficjalną przeglądarkę internetową.

W części defensywnej celem jest implementacja mechanizmu ekstrakcji parametrów uścisku dłoni TLS bezpośrednio na bramie brzegowej Nginx lub w sensorze Suricata. Zespół koreluje wyliczony odcisk kryptograficzny JA3 z deklarowaną tożsamością klienta HTTP, wykrywając anomalie masquerading i automatycznie blokując nieautoryzowane boty kodem HTTP 403. Wdrożona konfiguracja zapewnia bezwzględną weryfikację kontekstu urządzenia bez konieczności deszyfrowania całego ruchu na wczesnym etapie filtracji.

Krajowa Agencja Informacyjna udostępnia wewnętrzny portal redakcyjny portal.agencja.gov.local, przeznaczony do publikacji pilnych depesz i niejawnych komunikatów prasowych dla autoryzowanych korespondentów. W celu ograniczenia dostępu do zasobu administratorzy wdrożyli reguły brzegowe dopuszczające wyłącznie połączenia pochodzące ze sprawdzonych przeglądarek stacjonarnych (Google Chrome na platformie Windows), blokując zapytania zawierające w nagłówku User-Agent nazwy popularnych narzędzi audytorskich i bibliotek programistycznych.

Analitycy bezpieczeństwa wykryli jednak, że wrogie grupy prowadzą zmasowany scraping poufnych materiałów za pomocą skryptów w języku Python. Atakujący bez trudu omijają nałożone ograniczenia, wstrzykując w swoich skryptach nagłówek User-Agent podrobiony na wzór oryginalnej przeglądarki Chrome. W rezultacie prosta filtracja aplikacyjna okazała się bezradna, co wymusza wdrożenie nowoczesnych metod weryfikacji tożsamości na niższych warstwach modelu OSI.

Zespół laboratoryjny wciela się w rolę architektów architektury Zero Trust. Studenci budują skrypt audytorski w języku Python, który wysyła zapytania do zamkniętego endpointu API z podrobionym nagłówkiem Chrome, demonstrując udane pobranie danych z ominięciem reguł WAF. Następnie audytorzy badają strukturę pakietu ClientHello wysyłanego przez bibliotekę Python (kolejność zestawów szyfrów, wersje rozszerzeń, grupy eliptyczne) i wyliczają unikalny skrót MD5 stanowiący odcisk JA3.

W fazie remediacji zespół wdraża na bramie pośredniczącej moduł rejestracji i weryfikacji haszy JA3. Studenci definiują reguły odrzucające żądania, w których hasz wskazuje na narzędzie zautomatyzowane przy jednoczesnej deklaracji przeglądarki desktopowej. Równolegle tworzą sygnatury NIDS Suricata alarmujące o rozbieżnościach pomiędzy warstwą kryptograficzną a warstwą HTTP. Test re-testowy potwierdza natychmiastowe zablokowanie zamaskowanego bota przy zachowaniu pełnej dostępności dla legalnych użytkowników.

• Nginx z modułem lua-nginx-module / modułem JA3: brama brzegowa zdolna do pasywnej ekstrakcji parametrów uścisku TLS do zmiennej środowiskowej.
• Suricata NIDS 7.0+: sieciowy system wykrywania intruzów z natywnym słowem kluczowym ja3.hash i ja4.hash.
• Python 3 (biblioteki requests, urllib3, ssl): środowisko do budowy skryptu symulującego adwersarza maskującego tożsamość nagłówkiem.
• TShark / Wireshark: narzędzie do inspekcji pakietów ClientHello i ekstrakcji ciągu wejściowego dla algorytmu JA3.
• cURL: uniksowy klient CLI do testowania zróżnicowanych odcisków biblioteki libcurl.
• Oryginalna przeglądarka Google Chrome / Firefox: legalne środowisko klienckie generujące wzorcowy odcisk JA3 silnika Blink/Gecko.

1. Zbuduj środowisko składające się z bramy brzegowej Nginx, serwera aplikacji zaplecza Apache oraz stacji audytorskiej.
2. Skonfiguruj na bramie Nginx wirtualny host HTTPS z certyfikatem SSL oraz domyślną regułą sprawdzającą nagłówek User-Agent.
3. Napisz skrypt w języku Python korzystający z biblioteki requests i ustaw w nim podrobiony nagłówek User-Agent przeglądarki Chrome.
4. Wyślij zapytanie do serwera i zarejestruj, że brama Nginx przepuszcza zautomatyzowane żądanie kodem HTTP 200 OK.
5. Uruchom narzędzie tshark na interfejsie serwera i przechwyć pakiet ClientHello wygenerowany przez skrypt w Pythonie.
6. Przeanalizuj pięć kluczowych składowych odcisku JA3: wersję TLS, listę szyfrów, listę rozszerzeń, grupy eliptyczne oraz formaty punktów krzywych.
7. Wylicz ciąg wejściowy JA3 i oblicz jego skrót MD5, uzyskując charakterystyczny hasz biblioteki Python Requests (np. b32309a2...).
8. Uruchom legalną przeglądarkę Google Chrome i przechwyć jej pakiet ClientHello, wyliczając odpowiadający jej odcisk JA3.
9. Porównaj oba odciski i udokumentuj fundamentalne różnice w strukturze parametrów kryptograficznych.
10. Skonfiguruj moduł inspekcji na bramie Nginx z wykorzystaniem dyrektywy mapującej niepożądane hasze JA3 na zmienną blokującą.
11. Zdefiniuj regułę zwracającą kod HTTP 403 Forbidden z komunikatem o wykryciu niezgodności profilu urządzenia (Zero Trust Policy).
12. Zrestartuj usługę Nginx i ponownie uruchom skrypt maskującego się bota w Pythonie.
13. Zweryfikuj zablokowanie żądania przez bramę i obecność wpisu o zablokowanym haszu JA3 w dzienniku access.log.
14. Nawiąż połączenie z oryginalnej przeglądarki Chrome i potwierdź przyznanie dostępu z kodem HTTP 200 OK.
15. Opracuj sygnaturę NIDS Suricata wykrywającą korelację hasza JA3 narzędzia automatycznego z deklaracją przeglądarki w nagłówku.
16. Wygeneruj ruch testowy i zweryfikuj wyzwolenie alertu Suricata z identyfikatorem sid:1000908 w logu fast.log.
17. Przygotuj raport inżynierski podsumowujący przewagę profilowania JA3/JA4 nad deklaratywną filtracją nagłówków aplikacji.

Algorytm JA3 polega na wygenerowaniu odcisku palca aplikacji klienckiej na podstawie surowych parametrów pakietu TLS ClientHello. Ciąg wejściowy składa się z pięciu wartości oddzielonych przecinkami: wersji protokołu TLS, listy dopuszczalnych zestawów szyfrów (Cipher Suites), listy rozszerzeń (Extensions), listy obsługiwanych grup eliptycznych (Elliptic Curves) oraz formatów punktów krzywych eliptycznych (Elliptic Curve Point Formats). Uzyskany ciąg jest następnie haszowany funkcją MD5, tworząc zwięzły 32-znakowy identyfikator.

Kluczową zaletą technologii JA3 jest fakt, że biblioteki programistyczne (takie jak Python Requests, Go net/http, cURL czy WinHTTP) posiadają zupełnie inne zestawy szyfrów i rozszerzeń niż pełnoprawne przeglądarki internetowe. Nawet jeśli atakujący zmieni nagłówek User-Agent w warstwie HTTP, stos kryptograficzny systemu operacyjnego lub interpretera wysyła stałą strukturę ClientHello, co pozwala na natychmiastowe wykrycie manipulacji.

Nowszy standard JA4 rozszerza koncepcję JA3 o dodatkowe uodpornienie na permuracje rozszerzeń oraz formaty protokołów QUIC/HTTP3. W systemie Suricata inspekcja JA3 jest realizowana natywnie poprzez słowo kluczowe ja3.hash, co pozwala na bezproblemową budowę reguł korelacyjnych łączących warstwę TLS i warstwę HTTP w jednym sensorze sieciowym.

Poniżej przedstawiono listing skryptu maskującego tożsamość w Pythonie, konfigurację bramy brzegowej z mapowaniem haszy JA3 oraz sygnaturę detekcyjną NIDS Suricata.

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

1. Paradygmat Zero Trust: odrzucenie zaufania opartego na lokalizacji sieciowej na rzecz ciągłej weryfikacji tożsamości i kontekstu.
2. Zasada działania algorytmów pasywnego profilowania TLS: generowanie odcisków JA3 oraz standardu JA4.
3. Wykrywanie prób fałszowania nagłówka User-Agent poprzez analizę niespójności z kryptograficznym odciskiem handshake TLS.
4. Konfiguracja serwera Identity-Aware Proxy z dynamiczną ewaluacją kontekstu połączenia przed dopuszczeniem do aplikacji.
5. Integracja mechanizmów oceny ryzyka: reputacja adresu IP, integralność tokenów sesyjnych oraz zgodność profilu klienta.
6. Ochrona wewnętrznych portali strategicznych przed zaawansowanymi botami i zautomatyzowanymi narzędziami rekonesansu.

Przykładowe wnioski (wzór do sprawozdania): Wdrożenie kontekstowego serwera pośredniczącego Zero Trust z mechanizmem profilowania odcisków TLS JA3/JA4 pozwoliło na natychmiastowe wykrycie zamaskowanych skryptów atakujących portal redakcyjny. Choć złośliwy skrypt w języku Python przesyłał fałszywy nagłówek User-Agent imitujący przeglądarkę internetową, jego odcisk kryptograficzny JA3 bezbłędnie wskazał sygnaturę biblioteki sieciowej. Serwer proxy po wykryciu dysonansu pomiędzy tożsamością deklarowaną a profilem kryptograficznym pakietu ClientHello automatycznie zablokował żądanie z kodem HTTP 403. Dynamiczna weryfikacja kontekstu połączenia uniemożliwiła wykorzystanie skradzionych ciasteczek sesyjnych w zautomatyzowanych narzędziach scannerskich. Otrzymana architektura stanowi podręcznikowy przykład realizacji modelu Zero Trust, skutecznie chroniąc niejawne depesze prasowe przed nieautoryzowanym dostępem.

Zadanie odwołuje się do zagadnień Wykładu 1 oraz Wykładu 4, dotyczących protokołów transmisji danych w czasie rzeczywistym, specyfikacji WebSocket over TLS (WSS) oraz ograniczeń mechanizmu Same-Origin Policy (SOP) w nowoczesnych aplikacjach internetowych. Ćwiczenie weryfikuje efekty uczenia się: W1 (dogłębna znajomość architektury protokołu WebSocket RFC 6455 oraz anatomii ataku Cross-Site WebSocket Hijacking), U1 (konstrukcja złośliwej strony demonstracyjnej w środowisku laboratoryjnym przechwytującej prywatny strumień danych zalogowanego użytkownika), U2 (wdrożenie bezpiecznej walidacji nagłówka Origin oraz kryptograficznych tokenów powiązania sesji po stronie serwera), U3 (analiza ramek protokołu WebSocket w narzędziu Wireshark) oraz K1 (świadomość odpowiedzialności za ochronę poufności danych giełdowych i finansowych przetwarzanych w czasie rzeczywistym). Wymagania normatywne obejmują standard IETF RFC 6455 (The WebSocket Protocol), wytyczne OWASP WebSocket Security Guidance, klasyfikację CWE-346 (Origin Validation Error) oraz techniki MITRE ATT&CK: T1189 (Drive-by Compromise) i T1557.

Celem zadania jest zbadanie podatności protokołu WebSocket na ataki kradzieży sesji i podsłuchu danych w czasie rzeczywistym (Cross-Site WebSocket Hijacking - CSWSH) oraz wdrożenie wielowarstwowej inżynierii zabezpieczeń. Zespół studentów analizuje proces podnoszenia protokołu (HTTP Upgrade), wykazując, że przeglądarka internetowa automatycznie dołącza ciasteczka sesyjne użytkownika, podczas gdy reguły Same-Origin Policy nie blokują inicjowania połączeń WebSocket z domen obcych. Brak ograniczeń SOP w początkowej fazie uścisku dłoni stwarza poważne ryzyko niekontrolowanego wycieku poufnych informacji transakcyjnych. Pozwala to zewnętrznemu skryptowi na interakcję z prywatnym strumieniem giełdowym w imieniu nieświadomej ofiary.

W części praktycznej celem jest wdrożenie restrykcyjnej weryfikacji nagłówka Origin na serwerze pośredniczącym Apache/Nginx oraz implementacja jednorazowych, kryptograficznie zabezpieczonych biletów uwierzytelniających (One-Time Handshake Nonce). Studenci opracowują reguły NIDS Suricata monitorujące nietypowe żądania podniesienia protokołu oraz weryfikują skuteczność wprowadzonych zabezpieczeń, potwierdzając całkowite uniemożliwienie nawiązania nieautoryzowanego połączenia ze złośliwej witryny. Eksperyment dowodzi, że samo szyfrowanie kanału protokołem WSS nie chroni przed atakiem, jeśli serwer nie weryfikuje tożsamości źródła żądania.

Krajowa Platforma Obrotu Finansowego i Notowań Giełdowych udostępnia bezpieczny portal transakcyjny gielda.finanse.local. Aby zapewnić natychmiastowe aktualizacje salda rachunku oraz prywatnych zleceń maklerskich, aplikacja webowa korzysta z dwukierunkowego kanału WebSocket over TLS (WSS) pod adresem wss://gielda.finanse.local/stream. Uwierzytelnienie użytkownika w portalu realizowane jest za pomocą standardowego ciasteczka sesyjnego SESS_ID opatrzonego flagami Secure i HttpOnly.

Podczas audytu bezpieczeństwa wykazano, że programiści platformy założyli, iż obecność flagi HttpOnly zabezpiecza ciasteczko przed kradzieżą, a protokół TLS gwarantuje pełne bezpieczeństwo kanału. Zapomniano jednak, że uścisk dłoni protokołu WebSocket rozpoczyna się od standardowego żądania HTTP GET z nagłówkiem Upgrade: websocket. Zgodnie ze specyfikacją RFC 6455 przeglądarka internetowa zezwala na inicjowanie połączeń WebSocket z dowolnej innej domeny, automatycznie dołączając ciasteczka należące do domeny docelowej.

Zespół laboratoryjny wciela się w rolę audytorów Red Team, przygotowując kontrolowaną demonstrację podatności CSWSH. Studenci uruchamiają zewnętrzny serwer złośliwej witryny attacker-site.local. Gdy zalogowany inwestor odwiedzi spreparowaną stronę, ukryty skrypt JavaScript nawiązuje połączenie WebSocket z portalem giełdowym, wykorzystując aktywne ciasteczko ofiary. W rezultacie napastnik uzyskuje pełny dostęp do prywatnego strumienia notowań i stanu konta inwestora w czasie rzeczywistym.

Następnie studenci przechodzą do zadań defensywnych Blue Team. Rekonfigurują serwer WWW, wdrażając bezwzględną weryfikację nagłówka Origin oraz odrzucając połączenia z niezatwierdzonych domen kodem HTTP 403. Dodatkowo implementują mechanizm kryptograficznego biletu: przed nawiązaniem połączenia WSS aplikacja pobiera jednorazowy token powiązany z sesją, który musi zostać przesłany w parametrze zapytania uścisku dłoni. Zespół konfiguruje również sygnatury NIDS Suricata rejestrujące próby podejrzanych połączeń WebSocket.

• Node.js z biblioteką ws / Python z biblioteką websockets: środowisko do uruchomienia serwera WebSocket w konfiguracji podatnej i zabezpieczonej.
• Apache HTTP Server z modułem mod_proxy_wstunnel: serwer pośredniczący terminujący ruch WSS i przekazujący pakiety do backendu.
• Python 3 (biblioteka aiohttp / websockets): narzędzie do budowy skryptów testowych weryfikujących zachowanie nagłówków Origin.
• Wireshark / TShark: analizator protokołów do inspekcji ramek WebSocket (Masked Frame, Payload Data, Opcode).
• Przeglądarka internetowa (Firefox / Chromium): środowisko wykonawcze złośliwej witryny audytorskiej w języku JavaScript.
• Suricata NIDS 7.0+: system inspekcji z regułami analizującymi żądania Upgrade protokołu HTTP.

1. Zbuduj środowisko laboratoryjne z serwerem aplikacji giełdowej oraz oddzielnym serwerem symulującym witrynę adwersarza.
2. Uruchom usługę serwera WebSocket nasłuchującą na lokalnym porcie TCP i skonfiguruj Apache z modułem mod_proxy_wstunnel.
3. Wprowadź prostą logikę uwierzytelniania weryfikującą obecność ciasteczka sesyjnego SESS_ID w nagłówku zapytania podniesienia protokołu.
4. Uruchom przeglądarkę i zaloguj się na oficjalnym portalu gielda.finanse.local, uzyskując ciasteczko sesyjne.
5. Przygotuj stronę atakującą na serwerze attacker-site.local zawierającą złośliwy kod JavaScript inicjujący połączenie WebSocket.
6. Otwórz złośliwą stronę w tej samej przeglądarce i zaobserwuj automatyczne nawiązanie połączenia z serwerem giełdowym.
7. Zarejestruj w konsoli przeglądarki odbiór prywatnych ramek WebSocket ze stanem konta ofiary, dokumentując atak CSWSH.
8. Przechwyć pakiety za pomocą narzędzia Wireshark i przeanalizuj obecność nagłówka Origin: http://attacker-site.local.
9. Wprowadź na serwerze WebSocket moduł ścisłej walidacji nagłówka Origin, dopuszczający wyłącznie domenę gielda.finanse.local.
10. Zrestartuj usługę i ponownie otwórz złośliwą stronę, weryfikując odrzucenie połączenia błędem 403 Forbidden.
11. Zaprojektuj mechanizm tokenu kryptograficznego: wygeneruj jednorazowy token Ticket powiązany z bieżącą sesją użytkownika.
12. Zmodyfikuj kod serwera, aby wymagał obecności ważnego tokenu w ścieżce zapytania /stream?ticket=TOKEN_KRYPTO.
13. Wykaż, że złośliwa witryna nie jest w stanie wygenerować poprawnego tokenu ze względu na blokadę SOP w żądaniach XMLHttp/Fetch.
14. Opracuj sygnaturę NIDS Suricata wykrywającą żądania podniesienia protokołu WebSocket z niezaufanych domen w nagłówku Origin.
15. Przetestuj działanie sygnatury Suricata, rejestrując zdarzenie próby połączenia w logu fast.log.
16. Przeprowadź serię prób testowych z różnymi wariantami zapisu nagłówka Origin i potwierdź całkowite uszczelnienie kanału.
17. Opracuj sprawozdanie laboratoryjne z diagramem przepływu ataku, listingami kodu mitygującego oraz wnioskami inżynierskimi.

Podatność Cross-Site WebSocket Hijacking (CSWSH) jest bezpośrednim odpowiednikiem ataku CSRF w świecie protokołów czasu rzeczywistego. Kluczowa różnica polega na tym, że po nawiązaniu połączenia WebSocket komunikacja staje się dwukierunkowa i asynchroniczna. Oznacza to, że atakujący nie tylko może wywołać nieautoryzowaną akcję na serwerze, ale może również podsłuchiwać wszystkie dane odsyłane przez serwer do ofiary, co w klasycznym ataku CSRF jest blokowane przez mechanizm Same-Origin Policy.

Jedynym skutecznym mechanizmem weryfikacji tożsamości źródła żądania w fazie handshake protokołu WebSocket jest nagłówek Origin. Zgodnie ze specyfikacjami przeglądarek nagłówek ten jest automatycznie wstawiany przez silnik przeglądarki i nie może zostać zmodyfikowany przez skrypt JavaScript. Dlatego serwer WebSocket ma bezwzględny obowiązek weryfikacji wartości Origin względem ścisłej białej listy zaufanych domen.

Dodatkową warstwą obrony w duchu Defense in Depth jest stosowanie jednorazowych biletów kryptograficznych (One-Time Token / Ticket). Aplikacja webowa pobiera bilet za pośrednictwem chronionego zapytania HTTPS z aktywnym tokenem CSRF, a następnie przekazuje bilet jako parametr połączenia WebSocket. Ponieważ obca witryna nie ma możliwości odczytania odpowiedzi zapytania HTTPS (blokada SOP), nie jest w stanie pozyskać ważnego biletu do autoryzacji uścisku dłoni WSS.

Poniżej zamieszczono listing złośliwego kodu JavaScript, procedurę weryfikacji nagłówka Origin na serwerze w języku Python oraz sygnaturę sieciową NIDS Suricata.

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

1. Anatomia protokołu WebSocket: faza negocjacji HTTP Upgrade i przejście w pełnodupleksowy kanał dwukierunkowy.
2. Mechanizm ataku Cross-Site WebSocket Hijacking wynikający z braku ochrony Same-Origin Policy w protokole WebSocket.
3. Rygorystyczna walidacja nagłówka Origin po stronie serwera aplikacji WebSocket jako kluczowa linia obrony.
4. Wdrożenie jednorazowych, krótkotrwałych biletów uwierzytelniających generowanych przez REST API przed inicjalizacją kanału WSS.
5. Zastosowanie ciasteczek sesyjnych z flagą SameSite=Strict w celu zablokowania ich dołączania przez obce domeny.
6. Bezpieczeństwo giełdowych platform finansowych: szyfrowanie strumienia danych w locie za pomocą TLS i kontrola subskrypcji.

Przykładowe wnioski (wzór do sprawozdania): Praktyczna symulacja ataku Cross-Site WebSocket Hijacking na portalu transakcyjnym wykazała, że złośliwa strona otwarta przez tradera mogła bez przeszkód nawiązać połączenie z kanałem WSS i potajemnie odczytywać zlecenia maklerskie. Podatność wynikała z faktu, że serwer WebSocket polegał wyłącznie na ciasteczkach sesyjnych przesyłanych w nagłówku Upgrade, nie weryfikując pochodzenia żądania. Wdrożenie rygorystycznej białej listy nagłówka Origin natychmiast udaremniło próby zestawiania połączeń z nieautoryzowanych domen zewnętrznych. Dodatkowo zastąpiono uwierzytelnianie ciasteczkami mechanizmem jednorazowych biletów kryptograficznych ważnych przez 30 sekund i generowanych po zalogowaniu do API. Wprowadzone zmiany całkowicie zabezpieczyły giełdowy strumień danych w czasie rzeczywistym przed kradzieżą tajemnic handlowych i manipulacją zleceniami.

Zadanie stanowi syntetyczne podsumowanie całego kursu laboratoryjnego i integruje treści wszystkich wykładów w ramach złożonej operacji klasy Purple Teaming. Obejmuje zagadnienia ewolucji ataków socjotechnicznych nowej generacji, serwerów pośredniczących w czasie rzeczywistym (AiTM Phishing Proxy), kryptografii asymetrycznej w przeglądarce (standard FIDO2 / WebAuthn W3C) oraz obustronnego uwierzytelniania mTLS. Ćwiczenie weryfikuje efekty: W1 (dogłębna znajomość anatomii ataków AiTM omijających tradycyjne 2FA SMS/TOTP), W4 (matematyczne i kryptograficzne podstawy odporności kluczy FIDO2 wynikające z powiązania z tożsamością domeny rpId), U1 (uruchomienie kontrolowanego serwera proxy w języku Python przechwytującego poświadczenia w locie), U2 (wdrożenie biblioteki weryfikującej WebAuthn API i certyfikatów klienckich mTLS), U4 (opracowanie korelacyjnych reguł Sigma i sygnatur Suricata wykrywających anomalie IP w aktywnej sesji) oraz K1 (kompetencje do rekomendowania zarządom instytucji państwowych odejścia od podatnych schematów uwierzytelniania). Wymagania normatywne obejmują zalecenia CISA Phishing-Resistant MFA, wytyczne dyrektywy NIS 2, rozporządzenie DORA, standard W3C WebAuthn Level 2 oraz techniki MITRE ATT&CK: T1557, T1539 i T1556.

Głównym celem zadania jest przeprowadzenie pełnej, wieloetapowej operacji Purple Teaming demonstrującej całkowite przełamanie klasycznego uwierzytelniania dwuskładnikowego (2FA opartego o kody SMS lub aplikacje TOTP) za pomocą wieloetapowego ataku Adversary-in-the-Middle (AiTM). Zespół studentów w roli Red Teamu buduje przezroczysty serwer proxy pośredniczący w komunikacji z oficjalnym portalem rządowym, zwabia ofiarę na domenę podszywającą się i przechwytuje uwierzytelniony token sesyjny w nagłówku Set-Cookie natychmiast po poprawnym wpisaniu kodu 2FA przez ofiarę. Działanie to demaskuje iluzoryczność ochrony opartej wyłącznie na dynamicznych kodach jednorazowych w konfrontacji z aktywnym pośrednikiem ruchu.

W części defensywnej w roli Blue Teamu celem jest wdrożenie uwierzytelniania odpornego na phishing (Phishing-Resistant MFA) w postaci kluczy sprzętowych FIDO2 / WebAuthn oraz certyfikatów klienta mTLS. Zespół wykazuje, że sprzętowe powiązanie podpisu kryptograficznego z domeną Relying Party (rpId) definitywnie uniemożliwia przekazanie poświadczeń na serwer pośredniczący. Równolegle studenci wdrażają regułę Sigma korelującą nagłą zmianę adresu IP dla aktywnego ciasteczka oraz sygnaturę Suricata, tworząc kompletny system wczesnego ostrzegania w SOC. Podejście to łączy ofensywną walidację podatności z inżynierią odporności teleinformatycznej zgodną z wytycznymi agencji CISA.

Krajowa Administracja Skarbowa (KAS) udostępnia centralny portal podatkowy portal.kas.gov.local, przeznaczony do składania deklaracji finansowych i autoryzacji strategicznych operacji fiskalnych. W celu zabezpieczenia dostępu do kont urzędników wdrożono dwuskładnikowe uwierzytelnianie: po podaniu loginu i hasła użytkownik musi wprowadzić jednorazowy kod generowany w aplikacji mobilnej (standard TOTP RFC 6238). Kierownictwo instytucji uznało ten mechanizm za w pełni zabezpieczający system przed atakami phishingowymi.

Zespół operacyjny ds. bezpieczeństwa postanowił jednak zweryfikować to założenie w ramach ćwiczeń Purple Teaming. Tradycyjny phishing zbierający jedynie login i hasło jest rzeczywiście blokowany przez kody TOTP, lecz zdeterminowany adwersarz korzysta z serwerów pośredniczących czasu rzeczywistego (narzędzia klasy Evilginx / Muraena). Serwer pośredniczący nie jest statyczną stroną, lecz działa jako pełne reverse proxy przekazujące zapytania do oficjalnego portalu w ułamkach sekund, żądając od ofiary podania również kodu 2FA i natychmiast przechwytując finalne ciasteczko sesyjne.

W pierwszej fazie ćwiczenia studenci uruchamiają serwer AiTM Proxy pod domeną portal.kas-logowanie.local. Podczas kontrolowanej symulacji ofiara loguje się na fałszywym portalu, podając poprawne poświadczenia oraz kod TOTP. Serwer proxy przekazuje dane do oficjalnego backendu KAS, rejestruje wygenerowane ciasteczko sesyjne SESS_ID w pliku tekstowym i wstrzykuje je do przeglądarki audytora. Audytor otwiera chroniony panel administracyjny na nowej stacji bez znajomości hasła i bez ponownego podawania kodu 2FA, demonstrując krytyczną podatność architektury TOTP.

W drugiej fazie studenci wdrażają architekturę obronną. W portalu KAS logowanie zostaje przełączone na otwarty standard FIDO2 / WebAuthn wspierany przez klucze sprzętowe U2F oraz mechanizmy biometryczne Passkeys. Gdy ofiara podejmie próbę uwierzytelnienia na domenie serwera proxy, przeglądarka i klucz sprzętowy odmawiają wygenerowania podpisu dla fałszywej domeny, w 100% neutralizując atak. Na koniec studenci implementują w systemie SIEM korelacyjną regułę Sigma wykrywającą równoległe żądania z dwóch różnych podsieci IP dla tego samego identyfikatora sesji.

• Python 3 (moduły http.server, urllib.request, ssl): środowisko wykonawcze autorskiego serwera demonstracyjnego AiTM Reverse Proxy.
• Apache HTTP Server 2.4 z mod_ssl: oficjalny portal rządowy KAS z konfiguracją bezpiecznego logowania i certyfikatu TLS.
• Biblioteka WebAuthn (py_webauthn / simplewebauthn): komponenty programistyczne do kryptograficznej weryfikacji poświadczeń FIDO2.
• Klucz sprzętowy FIDO2 / wirtualny token WebAuthn w Chromium: urządzenie uwierzytelniające realizujące powiązanie z domeną rpId.
• Suricata NIDS 7.0+: system inspekcji sieciowej wykrywający anomalie nagłówków proxy i przekazywania tożsamości.
• Sigma CLI (sigmac): kompilator reguł korelacyjnych dla systemów SIEM (analiza logów Apache i zdarzeń sesji).
• Wireshark / TShark: narzędzie do inspekcji nagłówków HTTP i ciasteczek sesyjnych w strumieniu TCP.

1. Zbuduj środowisko sieciowe z oficjalnym portalem KAS (192.168.1.100), serwerem AiTM Proxy (192.168.1.75) oraz stacją audytora i ofiary.
2. Skonfiguruj oficjalny serwer Apache dla domeny portal.kas.gov.local z aplikacją wymagającą hasła i kodu TOTP.
3. Napisz w języku Python autorski serwer pośredniczący AiTM Reverse Proxy nasłuchujący na porcie 8443 pod domeną portal.kas-logowanie.local.
4. Zaimplementuj w serwerze proxy przekazywanie ciał żądań POST do oficjalnego backendu z zachowaniem nagłówków.
5. Dodaj logikę inspekcji nagłówka odpowiedzi Set-Cookie w celu automatycznego wyodrębniania i zapisywania ciasteczka sesyjnego.
6. Uruchom przeglądarkę ofiary i wejdź na adres serwera pośredniczącego portal.kas-logowanie.local.
7. Wprowadź poprawne dane logowania oraz wygenerowany w telefonie jednorazowy kod TOTP.
8. Zarejestruj przechwycenie pełnego ciasteczka sesyjnego przez serwer proxy w konsoli i pliku stolen_session.txt.
9. Uruchom nową, czystą przeglądarkę na stacji audytora i wstrzyknij przechwycone ciasteczko SESS_ID do magazynu cookie.
10. Otwórz oficjalny adres portalu portal.kas.gov.local i wykaż natychmiastowe uzyskanie dostępu do panelu urzędnika z pominięciem 2FA.
11. Udokumentuj krytyczną słabość tradycyjnego uwierzytelniania TOTP w raportowej tabeli podatności CVSS v3.1.
12. Wprowadź na serwerze rządowym implementację uwierzytelniania w otwartym standardzie FIDO2 / WebAuthn z parametrem rpId=portal.kas.gov.local.
13. Zarejestruj klucz sprzętowy FIDO2 w profilu użytkownika na oficjalnej domenie.
14. Ponów próbę zalogowania na fałszywym portalu pośredniczącym AiTM przy użyciu zarejestrowanego klucza FIDO2.
15. Zaobserwuj odmowę uwierzytelnienia przez przeglądarkę: klucz FIDO2 wykrywa niezgodność domeny i odrzuca wyzwanie kryptograficzne.
16. Opracuj sygnaturę NIDS Suricata wykrywającą komunikację przez proxy phishingowe na podstawie nagłówków X-Forwarded.
17. Zdefiniuj korelacyjną regułę Sigma wykrywającą użycie tego samego ciasteczka z dwóch różnych adresów IP w czasie poniżej 5 minut.
18. Przeprowadź końcowy test re-testowy, wykazując pełną odporność środowiska i zredaguj całościowy raport operacji Purple Teaming.

Istotą ataku Adversary-in-the-Middle (AiTM) na systemy uwierzytelniania jest fakt, że serwer pośredniczący nie próbuje łamać algorytmu generowania kodów TOTP. Zamiast tego zmusza ofiarę do legalnego wygenerowania kodu i wprowadzenia go w formularzu, po czym przekazuje kod do prawdziwego serwera w czasie jego ważności (okno 30 sekund). Prawdziwy serwer po weryfikacji wystawia uwierzytelnione ciasteczko sesyjne, które serwer proxy kopiuje i zapisuje. Tradycyjne metody 2FA (kody SMS, powiadomienia Push, aplikacje Google Authenticator) są całkowicie bezsilne wobec tego wektora.

Jedyną ustandaryzowaną obroną przed phishingiem AiTM jest technologia FIDO2 / WebAuthn (klucze YubiKey, tokeny FIDO, Windows Hello). W standardzie tym klucz kryptograficzny generuje podpis cyfrowy dla wyzwania (Challenge) przesłanego przez serwer, łącząc go z identyfikatorem domeny Relying Party (rpId), który jest pobierany bezpośrednio z paska adresu przeglądarki. Ponieważ przeglądarka ofiary znajduje się na fałszywej domenie phishingu, klucz tworzy podpis dla nieprawidłowego identyfikatora, który zostaje natychmiast odrzucony przez oficjalny serwer KAS.

Z punktu widzenia inżynierii detekcji Blue Team kluczowe jest monitorowanie anomalii sesyjnych. W momencie pomyślnego przejęcia ciasteczka przez atakującego, to samo ciasteczko sesyjne zaczyna generować zapytania z adresu IP ofiary oraz równolegle z adresu IP stacji audytora. Opracowana reguła Sigma z agregacją count(client_ip) by http_cookie > 1 pozwala na automatyczne unieważnienie sesji w czasie poniżej kilkunastu sekund od momentu przejęcia.

Poniżej przedstawiono fragmenty kodu autorskiego proxy AiTM w języku Python, strukturę reguły Sigma do wykrywania anomalii sesji oraz sygnaturę detekcyjną NIDS Suricata.

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

1. Mechanizm zaawansowanego ataku Adversary-in-the-Middle z użyciem narzędzi typu Evilginx i omijanie tradycyjnego 2FA opartego na TOTP.
2. Ograniczenia tradycyjnych metod MFA: brak kryptograficznego powiązania sesji z domeną docelową.
3. Implementacja uwierzytelniania odpornego na phishing (Phishing-Resistant MFA): standard FIDO2/WebAuthn oraz wzajemne TLS.
4. Inżynieria sygnatur detekcyjnych w systemie Suricata: wykrywanie wzorców ruchu serwerów proxy AiTM i anomalii w nagłówkach.
5. Opracowanie reguł korelacyjnych Sigma dla dzienników serwera WWW: detekcja nagłych zmian adresu IP dla aktywnej sesji.
6. Opracowanie rekomendacji obronnych dla strategicznych portali administracji skarbowej i instytucji państwowych.

Przykładowe wnioski (wzór do sprawozdania): Ćwiczenie Purple Teaming z wykorzystaniem narzędzia Evilginx wykazało, że standardowe uwierzytelnianie dwuskładnikowe oparte na kodach TOTP jest bezradne wobec nowoczesnych ataków typu Adversary-in-the-Middle. Napastnik pośredniczący w komunikacji przejął pełną tożsamość urzędnika skarbowego wraz z ciasteczkiem sesyjnym, uzyskując nieautoryzowany dostęp do panelu deklaracji podatkowych. Zaimplementowanie kluczy sprzętowych w standardzie FIDO2/WebAuthn całkowicie udaremniło ten atak, ponieważ przeglądarka kryptograficznie wiąże generowaną odpowiedź z rzeczywistą domeną wpisaną w pasku adresu. Równolegle analitycy defensywni wdrożyli reguły w systemie Suricata, które błyskawicznie wykrywają charakterystyczny ruch fałszywych serwerów pośredniczących w sieci. Przeprowadzona operacja jednoznacznie dowiodła konieczności wycofania kodów jednorazowych na rzecz standardu FIDO2 w ochronie krytycznych portali administracji publicznej.