Laboratorium 2

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon3 Symetryczne i niesymetryczne algorytmy szyfrowania. Podpisy cyfrowe i funkcje skrótu. Autoryzacja i uwierzytelnianie w systemach komputerowych. W1 Architektura uwierzytelniania w lasach domenowych Active Directory i protokół Kerberos v5.

Głównym zamierzeniem zadania jest przeprowadzenie audytu bezpieczeństwa kontrolera domeny Active Directory oraz tożsamości domenowych w modelu Purple Teaming. Zespół bada odporność protokołu Kerberos na kradzież poświadczeń biletowych przy wykorzystaniu technik Kerberoasting oraz AS-REP Roasting. W części badawczej studenci identyfikują konta usługowe ze zdefiniowanymi nazwami Service Principal Name oraz słabymi poświadczeniami szyfrowanymi archaicznym algorytmem RC4-HMAC. Projekt łączy ekstrakcję biletów bazy TGS z analizą grafową relacji uprawnień za pomocą narzędzia BloodHound, co pozwala wykryć ukryte ścieżki eskalacji do grupy Domain Admins.

W części obronnej grupa konfiguruje utwardzenie środowiska domenowego poprzez wdrożenie kont gMSA z automatyczną rotacją 128-znakowych haseł oraz wymuszenie szyfrowania AES-256. Równolegle studenci tworzą regułę detekcyjną Sigma dla zdarzeń Windows Security Event ID 4769, wykrywającą anomalne żądania biletów z niebezpiecznym typem szyfrowania. Zwieńczeniem prac jest formalny raport audytowy zawierający wektor CVSS v3.1 oraz analizę zgodności z wymogami sektorowymi rozporządzenia DORA.

Bank Komercyjny „Pol-Bank” zarządza infrastrukturą Active Directory obejmującą ponad tysiąc stacji roboczych oraz sto serwerów aplikacyjnych i bazodanowych. W ramach przygotowań do audytu zgodności z rozporządzeniem DORA oraz Rekomendacją D Komisji Nadzoru Finansowego zarząd zlecił wewnętrzną weryfikację odporności domeny na ataki z pozycji zwykłego pracownika. Audytorzy otrzymują standardowe konto domenowe bez żadnych uprawnień administracyjnych w celu zasymulowania przejęcia stacji roboczej przez adwersarza.

Wstępny rekonesans wykazuje, że w strukturze Active Directory funkcjonuje kilkadziesiąt historycznych kont usługowych utworzonych dla instancji Microsoft SQL Server, systemów raportowych oraz demonów backupu. Wiele z nich posiada przypisane atrybuty Service Principal Name i hasła, które nie były zmieniane od kilku lat. Dodatkowo część kont serwisowych ma ustawioną flagę wyłączającą wymóg preautentykacji Kerberos, co otwiera drogę do ataku AS-REP Roasting.

Zespół audytorski ma za zadanie zweryfikować, czy atakujący posiadający fizyczny lub zdalny dostęp do pojedynczej stacji roboczej może w sposób cichy zażądać biletów TGS dla usług, a następnie odzyskać hasła w trybie offline bez wywoływania blokady konta. Kolejnym celem jest użycie narzędzia SharpHound w celu zmapowania relacji obiektów w bazie grafowej Neo4j i odnalezienia najkrótszej ścieżki do przejęcia kontroli nad lasem domenowym.

Po stronie obronnej grupa musi zaprojektować i przetestować architekturę eliminującą ten wektor zagrożenia. Obejmuje to migrację podatnych kont do Group Managed Service Accounts (gMSA), całkowite zablokowanie szyfrowania RC4 na kontrolerze domeny oraz wdrożenie monitorowania telemetrycznego w systemie SIEM. W sprawozdaniu zespół przedstawia listingi poleceń, wyniki łamania hashy, reguły Sigma oraz analizę ryzyka operacyjnego dla sektora bankowego.

• Kali Linux z pakietem narzędzi Impacket (GetUserSPNs.py, GetNPUsers.py)
• BloodHound Community Edition oraz silnik grafowej bazy danych Neo4j
• SharpHound do bezuprawnieniowej kolekcji relacji ACL w Active Directory
• Hashcat do kryptoanalizy biletów Kerberos w trybach 13100 i 18200
• Windows Server 2022 w roli kontrolera domeny Active Directory Domain Services
• System analizy logów i SIEM Wazuh zintegrowany z agentem Winlogbeat
• Narzędzie sigma-cli do walidacji i konwersji reguł detekcyjnych Sigma

1. Przygotowanie izolowanego środowiska domenowego oraz weryfikacja łączności sieciowej między stacją audytora a kontrolerem domeny BANK.LOCAL.
2. Sprawdzenie poprawności synchronizacji czasu NTP ze stacją domenową w celu uniknięcia odrzucenia pakietów Kerberos ze względu na błąd skew.
3. Wykonanie bezuprawnieniowego odpytania kontrolera domeny o listę kont posiadających zarejestrowane nazwy Service Principal Name przy użyciu Impacket GetUserSPNs.
4. Analiza atrybutów zwróconych kont i identyfikacja konta sql_svc z przypisaną usługą MSSQLSvc/sql01.bank.local.
5. Wysłanie formalnego żądania TGS-REQ o bilet serwisowy dla konta sql_svc oraz zapisanie zwróconego biletu TGS-REP w pliku tekstowym.
6. Identyfikacja kont użytkowników z atrybutem DONT_REQ_PREAUTH za pomocą skryptu GetNPUsers.
7. Wysłanie spreparowanego pakietu AS-REQ dla wytypowanego konta backup_user i przechwycenie odpowiedzi AS-REP zawierającej zaszyfrowany komponent.
8. Weryfikacja typu szyfrowania wyekstrahowanych biletów poprzez potwierdzenie obecności szyfru RC4-HMAC o identyfikatorze typu 0x17.
9. Uruchomienie kolektora SharpHound z poziomu stacji roboczej w celu zebrania informacji o grupach, sesjach, uprawnieniach ACL i relacjach zaufania.
10. Import zebranego archiwum ZIP do bazy danych Neo4j i wizualizacja środowiska w interfejsie przeglądarkowym BloodHound.
11. Uruchomienie kwerendy wyszukującej najkrótsze ścieżki od konta sql_svc do grupy Domain Admins oraz analiza uprawnienia GenericAll.
12. Przeprowadzenie ataku słownikowego z regułami przekształceń w Hashcat dla biletów TGS w trybie 13100 przy użyciu słownika haseł.
13. Odzyskanie hasła w postaci jawnej oraz weryfikacja możliwości uwierzytelnienia na kontrolerze domeny.
14. Analiza dziennika zdarzeń Windows Security: przegląd zdarzeń Event ID 4769 (żądanie biletu usługi Kerberos) oraz Event ID 4768 (żądanie biletu TGT).
15. Opracowanie i walidacja reguły detekcyjnej Sigma wykrywającej żądania biletów TGS z szyfrowaniem RC4 zgłaszane przez konta bez końcówki dolarowej.
16. Wdrożenie środków zaradczych: utworzenie konta gMSA z kluczem 128-znakowym oraz wymuszenie obsługi algorytmu AES-256 w parametrach konta.
17. Sporządzenie raportu audytowego z wyznaczeniem wektora CVSS v3.1, opisem ścieżki ataku i zaleceniami wdrożeniowymi dla instytucji finansowej.

Podczas realizacji ataku Kerberoasting kluczowe jest zrozumienie, że każdy uwierzytelniony użytkownik domeny posiada uprawnienie do zażądania biletu TGS dla dowolnej usługi ze zdefiniowanym SPN. Kontroler domeny szyfruje bilet skrótem NTLM konta powiązanego z daną usługą. Jeżeli konto posiada słabe hasło słownikowe, atakujący może odzyskać je całkowicie offline, bez ryzyka zablokowania konta w Active Directory:

W przypadku kont z wyłączonym wymogiem preautentykacji Kerberos (atrybut DONT_REQ_PREAUTH) żądanie AS-REQ można wysłać bez podawania hasła użytkownika. Kontroler domeny zwraca pakiet AS-REP z komponentem zaszyfrowanym haszem hasła badanego użytkownika:

Odzyskanie hasła w trybie offline przeprowadza się za pomocą narzędzia Hashcat. Dla biletów Kerberos 5 TGS stosuje się tryb 13100, natomiast dla biletów AS-REP tryb 18200:

W celu wykrywania ataków Kerberoasting w centrum operacji bezpieczeństwa (SOC) tworzy się regułę Sigma mapującą zdarzenia Windows Security Event ID 4769 z typem szyfrowania RC4 (0x17):

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

1. Analiza wektorów ataków na protokół Kerberos: techniki Kerberoasting oraz AS-REP Roasting wymierzone w konta o słabych hasłach.
2. Wykorzystanie grupy chronionej Protected Users w Active Directory w celu uniemożliwienia buforowania skrótów NTLM i delegacji biletów TGT.
3. Wdrożenie zarządzanych kont usługowych gMSA (Group Managed Service Accounts) z automatycznie rotowanymi, silnymi hasłami.
4. Mechanizmy replikacji domeny i ochrona przed atakiem DCSync poprzez rygorystyczny audyt uprawnień delegowanych w domenie.
5. Monitorowanie anomalnych zdarzeń logowania w kontrolerach domeny: identyfikatory zdarzeń 4768 (TGT), 4769 (TGS) oraz 4624.
6. Zgodność z wytycznymi bezpieczeństwa tożsamości Microsoft oraz regulacjami DORA i Rekomendacji D KNF w sektorze bankowym.

Przykładowe wnioski (wzór do sprawozdania): Audyt bezpieczeństwa tożsamości domenowej Active Directory wykazał, że obecność kont usługowych ze statycznymi hasłami i zarejestrowanymi nazwami SPN stwarza krytyczną podatność na ataki typu Kerberoasting. Pozyskane bilety TGS dla usług bazodanowych zostały z powodzeniem złamane offline w niespełna dwie godziny ze względu na niewystarczającą entropię haseł kont serwisowych. Zastąpienie tradycyjnych tożsamości kontami gMSA całkowicie wyeliminowało ten wektor zagrożenia poprzez narzucenie 128-bitowych, automatycznie zmienianych haseł. Dodanie kont administratorów do grupy Protected Users skutecznie zablokowało użycie przestarzałych szyfrów RC4 oraz delegację biletów TGT na stacjach roboczych. Zaimplementowanie precyzyjnych reguł detekcji w systemie SIEM dla zdarzeń 4769 umożliwiło natychmiastowe wykrywanie masowych zapytań o bilety usługowe, spełniając rygorystyczne wymagania unijnego rozporządzenia DORA.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon4 Bezpieczeństwo protokołów komunikacyjnych i sieci komputerowych. W1 Organizacja pamięci procesów, struktura ramki stosu i mechanizmy mitigacji błędów binarnych.

Celem ćwiczenia jest zbadanie mechanizmu podatności przepełnienia bufora na stosie w usłudze sieciowej oraz analiza działania zabezpieczeń jądra i kompilatora. Zespół laboratoryjny przeprowadza inżynierię wsteczną podatnego procesu telemetrycznego napisanego w języku C, analizując zachowanie rejestrów procesora w środowisku GDB z nakładką GEF. Studenci wyznaczają dokładną odległość do nadpisania rejestru wskaźnika instrukcji przy użyciu generowanego wzorca cyklicznego. Doświadczenie uczy konstrukcji bezpiecznego kodu oraz dowodzi konieczności stosowania bezpiecznych funkcji operujących na ciągach znaków.

W ramach analizy binarnej grupa konstruuje skrypt weryfikacyjny w języku Python z wykorzystaniem biblioteki Pwntools, realizujący technikę Return-to-libc w celu ominięcia stosu niewykonywalnego. Część defensywna obejmuje opracowanie sygnatury Suricata wykrywającej anomalne ładunki w strumieniu TCP oraz rekonfigurację kompilacji z pełnym zestawem flag ochronnych. Studenci dokumentują wpływ kanarków stosu i losowości przestrzeni adresowej na powstrzymanie przejęcia kontroli nad rejestrem instrukcji.

Przedsiębiorstwo strategiczne „Nafta-Przesył” zarządza infrastrukturą rurociągową transportującą paliwa płynne. Na serwerze bramy telemetrycznej uruchomiono demon sieciowy napisany w języku C, który nasłuchuje na dedykowanym porcie TCP i przyjmuje raporty ciśnienia oraz przepływu z terenowych stacji pomiarowych. Usługa ta została wdrożona wiele lat temu bez przeprowadzenia szczegółowej weryfikacji kodu źródłowego pod kątem podatności pamięciowych.

Analiza kodu demona ujawnia, że funkcja przetwarzająca ramkę telemetryczną kopiuje dane wejściowe do bufora o stałym rozmiarze za pomocą funkcji strcpy bez walidacji długości przekazanego ciągu. Na maszynie docelowej włączony jest mechanizm No-Execute (NX), który uniemożliwia bezpośrednie wykonanie powłoki umieszczonej w buforze stosu. Taka konfiguracja wymusza zastosowanie techniki Return-to-libc, polegającej na przekierowaniu wskaźnika instrukcji do istniejących fragmentów biblioteki standardowej C.

Zespoły audytorskie wcielają się w rolę analityków bezpieczeństwa badających podatność w wyizolowanym segmencie laboratoryjnym. Zadaniem grupy jest odtworzenie podatności, zbadanie zachowania procesu po wywołaniu błędu naruszenia ochrony pamięci oraz zidentyfikowanie adresu bazowego biblioteki libc i gadżetów procesora x86-64. Studenci tworzą powtarzalny skrypt sprawdzający, który przekazuje odpowiednio przygotowany ciąg bajtów.

Działania obronne koncentrują się na eliminacji podatności na dwóch poziomach: detekcji sieciowej oraz utwardzenia procesu budowania oprogramowania. Grupa projektuje regułę dla systemu IDS Suricata analizującą powtarzalne wzorce w pakietach oraz rekompiluje binarkę z mechanizmami Stack Canaries, FORTIFY_SOURCE i Position Independent Executable. W sprawozdaniu studenci przedstawiają zrzuty ekranu z debuggera, kod exploita oraz ocenę ryzyka w standardzie CVSS v3.1.

• Kali Linux ze środowiskiem Python 3 oraz biblioteką Pwntools
• Debugger GDB z rozszerzeniem GEF (GDB Enhanced Features)
• Narzędzie checksec do audytu aktywnych mechanizmów binarnych
• Narzędzie ROPgadget do lokalizacji sekwencji instrukcji w binariach
• Kompilator GCC do badania wpływu flag mitigacyjnych
• System wykrywania intruzów Suricata do detekcji sieciowej

1. Przygotowanie środowiska testowego z wyizolowaną siecią Host-Only i uruchomienie podatnego demona telemetrycznego na porcie TCP 9999.
2. Wykonanie wstępnego audytu mechanizmów ochronnych pliku binarnego za pomocą narzędzia checksec.
3. Analiza kodu źródłowego usługi w języku C ze szczególnym uwzględnieniem wywołania funkcji strcpy na buforze 256-bajtowym.
4. Uruchomienie procesu demona pod kontrolą debuggera GDB z rozszerzeniem GEF.
5. Wygenerowanie unikalnego wzorca cyklicznego o długości 300 bajtów za pomocą polecenia pattern create.
6. Wysłanie wygenerowanego wzorca do usługi sieciowej i zarejestrowanie momentu wystąpienia błędu SIGSEGV.
7. Odczytanie zawartości rejestru RIP w debuggerze i wyznaczenie dokładnego offsetu nadpisania adresu powrotu.
8. Wyszukanie gadżetu procesora x86-64 pop rdi ; ret w kodzie programu za pomocą ROPgadget.
9. Odczytanie statycznych adresów funkcji system oraz ciągu tekstowego /bin/sh w załadowanej bibliotece libc.
10. Konstrukcja autorskiego skryptu w języku Python z użyciem biblioteki Pwntools realizującego technikę Return-to-libc.
11. Wysłanie spreparowanego pakietu danych do usługi i weryfikacja uzyskania interaktywnej powłoki systemowej.
12. Analiza ruchu sieciowego wygenerowanego podczas eksploatacji podatności w narzędziu Wireshark.
13. Opracowanie reguły dla systemu Suricata wykrywającej próby wysyłania podejrzanych wzorców do portu 9999.
14. Przetestowanie działania reguły Suricata podczas ponownego uruchomienia exploita i analiza wpisów w fast.log.
15. Ponowna kompilacja kodu źródłowego usługi z włączeniem kanarków stosu (-fstack-protector-strong) oraz ochrony PIE.
16. Próba ponownego uruchomienia exploita przeciwko utwardzonej binarce i analiza komunikatu o przerwaniu stosu.
17. Sporządzenie sprawozdania z opisem mechanizmu ataku, wektorem CVSS v3.1 oraz rekomendacjami dotyczącymi bezpiecznego wytwarzania oprogramowania.

Przed przystąpieniem do analizy binarnej należy zweryfikować, jakie mechanizmy ochronne zostały wkompilowane w plik wykonywalny. Brak kanarków stosu (Stack Canaries) oraz statyczne adresowanie (No PIE) ułatwiają wyznaczenie wektora nadpisania, podczas gdy aktywny mechanizm NX uniemożliwia wykonanie shellcode bezpośrednio ze stosu:

W celu precyzyjnego wyznaczenia offsetu nadpisania wskaźnika instrukcji (RIP) w środowisku 64-bitowym generuje się wzorzec cykliczny de Bruijna, a po wystąpieniu błędu SIGSEGV sprawdza dopasowanie zawartości rejestru:

W architekturze x86-64 pierwszy argument wywołania funkcji przekazywany jest w rejestrze RDI. Do ustawienia argumentu dla funkcji system() niezbędny jest gadżet zdejmujący wartość ze stosu do rejestru RDI:

Poniżej przedstawiono autorski skrypt weryfikacyjny w języku Python wykorzystujący bibliotekę Pwntools, który składa łańcuch Return-to-libc i przejmuje powłokę demona:

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

1. Mechanizm przepełnienia bufora na stosie: nadpisanie ramki stosu oraz rejestru wskaźnika instrukcji procesora EIP lub RIP.
2. Analiza i działanie kompilatorowych mechanizmów ochrony pamięci: kanarki stosu (Stack Canaries), bit NX/DEP oraz losowość ASLR.
3. Konstrukcja łańcuchów gadżetów ROP (Return-Oriented Programming) w celu ominięcia zabezpieczenia pamięci niepodlegającej wykonaniu.
4. Rola zaawansowanych technik fuzzingu w automatycznym wykrywaniu anomalii i błędów zarządzania pamięcią w oprogramowaniu C i C++.
5. Bezpieczne refaktoryzowanie kodu: zastąpienie niebezpiecznych funkcji bibliotecznych ich bezpiecznymi odpowiednikami lub migracja do języków bezpiecznych pamięciowo.
6. Spełnienie wytycznych normy ISO/IEC 15408 oraz zaleceń CISA dotyczących eliminacji podatności pamięciowych w infrastrukturze krytycznej.

Przykładowe wnioski (wzór do sprawozdania): Laboratoryjna analiza podatności binarnej demona telemetrycznego w środowisku gdb-gef wykazała krytyczny brak walidacji rozmiaru danych wejściowych w funkcji obsługującej pakiety TCP. Nadpisanie adresu powrotu procesora spreparowanym ciągiem bajtów pozwoliło na przekierowanie przepływu sterowania do łańcucha gadżetów ROP i wykonanie powłoki z uprawnieniami usługi. Kompilacja oprogramowania z flagami ochronnymi fstack-protector-all oraz aktywacja mechanizmów ASLR i DEP w systemie operacyjnym skutecznie udaremniły bezpośrednią eksploatację exploita. Ostatecznym rozwiązaniem problemu było przepisanie podatnego modułu parsowania pakietów z użyciem bezpiecznych funkcji operujących na ograniczonych buforach oraz wdrożenie testów z użyciem AddressSanitizera. Wyeliminowanie podatności typu Memory Corruption stanowi fundamentalny warunek zapewnienia bezpieczeństwa przemysłowych systemów telemetrii gazociągowej.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon3 Symetryczne i niesymetryczne algorytmy szyfrowania. Podpisy cyfrowe i funkcje skrótu. Autoryzacja i uwierzytelnianie w systemach komputerowych. W1 Mechanizmy serializacji i deserializacji obiektów oraz podatności w architekturach wielowarstwowych.

Celem zadania jest zbadanie mechanizmu podatności niezaufanej deserializacji obiektów w architekturze rozproszonych mikroserwisów oraz wdrożenie bezpiecznych wzorców przetwarzania danych. Studenci analizują wektor ataku polegający na wstrzyknięciu spreparowanego strumienia bajtów do interfejsu API przyjmującego zserializowane obiekty języka Python oraz Java. W ramach części badawczej zespół konstruuje dowód koncepcji wykorzystujący łańcuchy powiązań do wykonania poleceń systemowych na podatnym węźle roboczym. Zadanie pozwala zrozumieć, dlaczego deserializacja danych pochodzących od klienta bez uprzedniej walidacji stanowi krytyczne zagrożenie dla integralności całego klastra.

W fazie defensywnej grupa projektuje mechanizmy remediacji poprzez zastąpienie natywnej deserializacji obiektowej bezpiecznymi formatami wymiany informacji takimi jak Protocol Buffers oraz JSON z rygorystyczną walidacją schematu. Dodatkowo studenci konfigurują reguły detekcyjne dla systemu IDS analizujące sygnatury znanych ładunków oraz izolują procesy przetwarzające za pomocą profili AppArmor i seccomp. Opracowane sprawozdanie zawiera ocenę wektora CVSS v3.1, analizę logów audytowych oraz formalny wzorzec bezpiecznej architektury mikroserwisowej.

Platforma logistyczna „Polska Sieć Przeładunkowa” zarządza flotą pojazdów i magazynami centralnymi w oparciu o architekturę mikroserwisów skomunikowanych kolejką komunikatów RabbitMQ i bramą API. W ramach optymalizacji wydajności programiści zaimplementowali wewnętrzną wymianę stanów obiektów zlecenia przy użyciu natywnego mechanizmu serializacji pickle w języku Python oraz binarnych strumieni Java.

Podczas zewnętrznego audytu architektury teleinformatycznej ujawniono, że punkt końcowy bramy API przyjmuje zserializowane ładunki bez weryfikacji ich sygnatury kryptograficznej ani typu przetwarzanego obiektu. Umożliwia to nieuwierzytelnionemu nadawcy przesłanie zmodyfikowanego pakietu danych, w którym zagnieżdżono instrukcje wywołujące powłokę systemową na poziomie interpretera w momencie wywołania metody odtwarzającej stan.

Zespół audytorski otrzymuje zadanie przeprowadzenia kontrolowanej weryfikacji podatności w wyizolowanym segmencie testowym. Studenci analizują strukturę klas bibliotecznych dostępnych w środowisku uruchomieniowym w celu zbudowania łańcucha wykonawczego. Eksperyment ma potwierdzić możliwość zdalnego uruchomienia kodu bez zakłócania ciągłości działania sąsiednich mikroserwisów w klastrze.

Część inżynierii defensywnej polega na całkowitym usunięciu niebezpiecznych parserów ze ścieżki przetwarzania danych wejściowych. Studenci implementują parser oparty na schemacie JSON Schema oraz Protocol Buffers, który odrzuca wszelkie nieznane pola i uniemożliwia automatyczną konkretyzację obiektów. Wyniki weryfikacji, konfiguracje filtrów wejściowych oraz reguły monitorowania zostają udokumentowane w sprawozdaniu technicznym.

• Środowisko Python 3 z modułami pickle, PyYAML oraz biblioteką jsonschema
• Narzędzie ysoserial do analizy łańcuchów gadżetów w środowisku Java
• Klient HTTP curl oraz narzędzie Burp Suite Community do manipulacji zapytaniami
• Framework Protocol Buffers (protoc) do definiowania bezpiecznych struktur danych
• System Suricata z regułami inspekcji strumieni HTTP do wykrywania ładunków binarnych
• Środowisko Docker CE do uruchomienia wyizolowanych kontenerów mikroserwisów

1. Uruchomienie wyizolowanego środowiska mikroserwisowego z podatnym punktem końcowym API w kontenerze Docker.
2. Analiza kodu źródłowego komponentu odbiorczego i identyfikacja wywołania pickle.loads bez walidacji danych.
3. Zbadanie działania metody specjalnej __reduce__ w mechanizmie serializacji obiektowej języka Python.
4. Napisanie generatora ładunku w języku Python tworzącego zserializowany obiekt wywołujący polecenie systemowe id.
5. Zakodowanie ładunku w formacie Base64 i przesłanie go w nagłówku zapytania HTTP POST do podatnego mikroserwisu.
6. Rejestracja wykonania polecenia w logach systemowych kontenera i potwierdzenie zdalnego wykonania kodu (RCE).
7. Analiza wektora podatności w środowisku Java z wykorzystaniem biblioteki ysoserial i łańcucha CommonsCollections.
8. Zbadanie śladów pozostawionych w dzienniku zdarzeń i telemetrii procesu podczas uruchamiania powłoki sh.
9. Zaprojektowanie reguły dla systemu IDS Suricata wykrywającej specyficzne sekwencje bajtów nagłówka pickle (bajty proto 0x80).
10. Przetestowanie skuteczności sygnatury Suricata podczas ponownego przesłania złośliwego pakietu danych.
11. Opracowanie bezpiecznego modelu danych w oparciu o specyfikację Protocol Buffers (plik zlecenia .proto).
12. Kompilacja definicji protobuf za pomocą kompilatora protoc i wygenerowanie bezpiecznych klas dostępowych.
13. Implementacja alternatywnego parsera JSON z formalną walidacją schematu za pomocą biblioteki jsonschema.
14. Przetestowanie zachowania nowego parsera wobec spreparowanych danych wejściowych i potwierdzenie odrzucenia pakietu.
15. Wdrożenie profilu bezpieczeństwa AppArmor blokującego uruchamianie powłok i programów potomnych w kontenerze.
16. Weryfikacja odmowy wykonania polecenia przez profil bezpieczeństwa jądra w przypadku próby ominięcia parsera.
17. Sporządzenie dokumentacji powykonawczej z kalkulacją CVSS v3.1, analizą ryzyka i wytycznymi bezpiecznego kodowania.

W języku Python moduł pickle pozwala na pełną rekonstrukcję grafu obiektów, co obejmuje wywoływanie dowolnych funkcji systemowych za pośrednictwem krotki zwracanej przez metodę __reduce__. Poniższy listing demonstruje strukturę podatnej klasy generującej złośliwy strumień bajtów:

Przesłanie przygotowanego ładunku do podatnego punktu końcowego API skutkuje natychmiastowym wykonaniem polecenia w momencie rekonstrukcji obiektu przez interpreter:

W celu wykrycia prób przesyłania ładunków serializacji pickle w ruchu HTTP wdraża się sygnaturę sieciową Suricata weryfikującą nagłówki protokołu:

Bezpieczna remediacja polega na zastąpieniu natywnej serializacji bezpiecznym formatem JSON z formalną walidacją schematu za pomocą biblioteki jsonschema:

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

1. Mechanizm ataku niebezpiecznej deserializacji: rekonstrukcja niezaufanych obiektów i wykonywanie niejawnych sekwencji metod (Gadget Chains).
2. Analiza łańcuchów gadżetów w bibliotekach Java prowadzących do zdalnego wykonania dowolnego kodu (Remote Code Execution – RCE).
3. Podatności modułów serializacji w popularnych technologiach backendowych: moduł pickle w Pythonie oraz formaty binarne .NET.
4. Wdrażanie mechanizmów walidacji i filtrowania deserializacji (ObjectInputFilter w Java) z zastosowaniem restrykcyjnych białych list klas.
5. Bezpieczne wzorce architektoniczne: zastąpienie natywnej serializacji formatami wymiany danych ze schematem walidacji (Protocol Buffers lub JSON Schema).
6. Rekomendacje OWASP Top 10 w kategorii Software and Data Integrity Failures w zakresie ochrony potoków przetwarzania danych.

Przykładowe wnioski (wzór do sprawozdania): Eksperyment z kontrolowaną eksploatacją kolejki komunikatów dowiódł, że przyjmowanie natywnie zserializowanych obiektów binarnych pozwala na zdalne wykonanie dowolnego kodu w mikroserwisie logistycznym. Za pomocą narzędzia ysoserial skonstruowano ładunek wykorzystujący łańcuch gadżetów w popularnej bibliotece pomocniczej, co zaowocowało natychmiastowym uzyskaniem powłoki systemowej w kontenerze przetwarzającym zlecenia. Zastosowanie mechanizmu Java ObjectInputFilter z rygorystyczną białą listą dozwolonych klas biznesowych zablokowało wykonanie wrogiego ładunku na etapie wstępnego odczytu strumienia. W ramach trwałej remediacji architektury zrezygnowano całkowicie z natywnej serializacji Javy na rzecz formatu Protocol Buffers ze ścisłą walidacją schematu wiadomości. Wdrożona zmiana całkowicie zneutralizowała wektor ataku CWE-502 i podniosła odporność architektury mikroserwisowej zgodnie z wytycznymi OWASP.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon4 Bezpieczeństwo protokołów komunikacyjnych i sieci komputerowych. W4 Tunele DNS, techniki ukrytej transmisji i inspekcja pakietów w sieciach IP.

Zadanie ma na celu zbadanie mechanizmu tworzenia ukrytych kanałów komunikacji wychodzącej za pośrednictwem protokołu DNS oraz zaprojektowanie metod ich skutecznego wykrywania i blokowania. Zespół analizuje techniki tunelowania danych stosowane do omijania tradycyjnych reguł zapory sieciowej blokującej bezpośredni ruch wychodzący TCP i UDP. W ramach symulacji studenci zestawiają tunel wykorzystujący zapytania o rekordy TXT i A z kodowaniem Base32 i Base64 za pomocą narzędzi Iodine oraz dnscat2. Realizacja scenariusza pozwala poznać specyfikę zapytań rekurencyjnych oraz ograniczenia tradycyjnych filtrów portowych.

W części analitycznej i obronnej grupa bada właściwości statystyczne ruchu DNS, w tym entropię Shannona nazw domenowych, długość etykiet oraz częstotliwość generowania zapytań w jednostce czasu. Studenci opracowują reguły dla systemu IDS Suricata identyfikujące anomalne zapytania oraz konfigurują polityki filtrujące na zaporze RouterOS i linuksowej zaporze nftables. Sprawozdanie podsumowuje skuteczność detekcji heurystycznej, prezentuje listingi przechwyconych pakietów oraz określa zasady bezpiecznej konfiguracji serwerów DNS w infrastrukturze krytycznej.

Ośrodek Badań Jądrowych i Materiałowych zarządza odizolowaną siecią laboratoryjną przechowującą wyniki pomiarów fizycznych i dane technologiczne. W celu uniemożliwienia wycieku informacji wprowadzono rygorystyczną politykę bezpieczeństwa sieciowego: ruch wychodzący do publicznego Internetu jest całkowicie zablokowany, z wyjątkiem zapytań DNS kierowanych do lokalnego serwera rozwiązującego nazwy.

Administratorzy założyli, że pozostawienie wyłącznie usługi DNS na porcie UDP 53 jest bezpieczne i nie pozwala na transmisję danych poufnych na zewnątrz organizacji. Audytorzy mają za zadanie zweryfikować to założenie, badając możliwość wykorzystania rekurencyjnego rozwiązywania nazw do zestawienia dwukierunkowego kanału sterowania C2 oraz transferu plików binarnych zakodowanych w poddomenach.

Grupa laboratoryjna konfiguruje serwer nazw autorytatywny dla domeny testowej oraz stację roboczą w wyizolowanej sieci wewnętrznej. Wykorzystując narzędzie tunelujące, studenci przesyłają próbkę danych pomiarowych, obserwując sposób fragmentacji i enkapsulacji pakietów w standardowych zapytaniach i odpowiedziach DNS.

Zespół defensywny analizuje telemetrię sieciową w narzędziach Wireshark i tshark, obliczając rozkład entropii znaków w przesyłanych etykietach oraz monitorując liczbę zapytań o rekordy typu TXT. Na podstawie zebranych danych inżynierowie konfigurują reguły wykrywania w Suricata oraz filtry ograniczające pasmo i blokujące podejrzane żądania na routerze brzegowym RouterOS.

• Narzędzie tunelowania DNS Iodine (iodined i iodine) oraz dnscat2
• Serwer DNS BIND9 skonfigurowany jako serwer autorytatywny dla strefy testowej
• Wireshark oraz tshark do analizy przechwyconych pakietów DNS
• Skrypt w języku Python z biblioteką SciPy do obliczania entropii Shannona ciągów
• System wykrywania intruzów Suricata z dedykowanymi regułami analizy DNS
• System operacyjny RouterOS (wirtualna maszyna CHR) do filtracji na poziomie zapory
• Narzędzie nftables do implementacji reguł ograniczania częstotliwości zapytań

1. Uruchomienie autorytatywnego serwera DNS BIND9 dla domeny testowej tunnel.lab w wyizolowanym segmencie sieci.
2. Konfiguracja rekordu delegacji NS wskazującego serwer tunelu jako autorytatywny dla strefy t.tunnel.lab.
3. Uruchomienie demona iodined na serwerze zewnętrznym z przypisaną wirtualną podsiecią IP 10.0.0.0/27.
4. Konfiguracja stacji roboczej klienta w sieci wewnętrznej z zablokowanym bezpośrednim dostępem do sieci zewnętrznej.
5. Zestawienie tunelu DNS za pomocą klienta iodine wskazującego lokalny serwer rozwiązujący jako pośrednika.
6. Weryfikacja utworzenia wirtualnego interfejsu sieciowego dns0 i sprawdzenie pomyślnego przydziału adresu IP.
7. Przeprowadzenie transferu testowego pliku tekstowego przez utworzony interfejs tunelu za pomocą narzędzia netcat.
8. Przechwycenie ruchu DNS generowanego podczas transferu za pomocą narzędzia tshark i zapis do pliku PCAP.
9. Analiza struktury zapytań: identyfikacja kodowania danych w etykietach subdomen oraz rekordów odpowiedzi TXT.
10. Opracowanie skryptu w języku Python obliczającego entropię Shannona nazw domenowych w zarejestrowanym ruchu.
11. Porównanie wyników entropii dla standardowego ruchu przeglądarkowego oraz ruchu generowanego przez tunel DNS.
12. Opracowanie reguły Suricata wykrywającej wysokie zagęszczenie zapytań o rekordy TXT o nietypowej długości odpowiedzi.
13. Konfiguracja reguł ograniczających liczbę zapytań DNS na sekundę (Rate Limiting) w narzędziu nftables.
14. Wdrożenie polityki inspekcji pakietów DNS na zaporze MikroTik RouterOS w tablicy IP Firewall Filter.
15. Przetestowanie odporności wdrożonych zabezpieczeń na próby nawiązania tunelu przy obniżonej przepustowości.
16. Ocena wpływu ograniczeń DNS na poprawne funkcjonowanie standardowych usług domenowych w organizacji.
17. Przygotowanie sprawozdania zawierającego wykresy entropii, konfiguracje zapory i wnioski dotyczące monitorowania DNS.

Tunelowanie DNS polega na kodowaniu danych binarnych w znakach dopuszczalnych w nazwach domenowych (RFC 1035), zazwyczaj z wykorzystaniem alfabetu Base32 lub Base64. Serwer rekurencyjny przesyła zapytanie do serwera autorytatywnego kontrolowanego przez adwersarza. Poniższy listing ilustruje uruchomienie serwera tunelującego Iodine:

Zestawienie połączenia ze stacji roboczej klienta realizuje się za pomocą polecenia iodine, wskazując adres lokalnego serwera rozwiązującego nazwy jako pośrednika:

Skuteczna detekcja opiera się na analizie entropii Shannona. Losowo wyglądające ciągi Base32 generują znacznie wyższą entropię niż naturalne nazwy domenowe (np. powyżej 3.8 dla alfabetu alfanumerycznego):

Poniżej przedstawiono regułę Suricata wykrywającą anomalnie długie odpowiedzi TXT charakterystyczne dla tuneli DNS:

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

1. Architektura ukrytych kanałów transmisyjnych (Covert Channels) i techniki tunelowania ruchu IP w zapytaniach DNS.
2. Statystyczna analiza ruchu DNS: badanie entropii Shannona w etykietach subdomen oraz anomalii długości nazw FQDN.
3. Analiza wolumetryczna i behawioralna: monitorowanie liczby zapytań o nietypowe rekordy (TXT, NULL) i częstotliwości żądań z pojedynczych hostów.
4. Implementacja mechanizmów ochrony DNS: strefy Response Policy Zones (RPZ), filtrowanie DNS Firewall oraz serwery Resolver z inspekcją heurystyczną.
5. Izolacja środowisk laboratoryjnych: ograniczenie ruchu DNS wyłącznie do wewnętrznych resolverów korporacyjnych z blokadą bezpośrednich połączeń zewnętrznych.
6. Zastosowanie systemów detekcji intruzów NIDS z dedykowanymi regułami analizy anomalii DNS w infrastrukturze krytycznej.

Przykładowe wnioski (wzór do sprawozdania): Praktyczna symulacja tunelowania danych za pomocą narzędzia iodine wykazała, że pozornie nieszkodliwy protokół DNS może zostać wykorzystany do ustanowienia pełnego, dwukierunkowego tunelu IP omijającego tradycyjne zapory sieciowe. Analiza ruchu sieciowego w środowisku Wireshark i Zeek ujawniła gwałtowny wzrost liczby zapytań o rekordy TXT oraz nienaturalnie wysoką entropię Shannona w nazwach subdomen, przekraczającą wartość 4,5 bita. Zaimplementowanie w lokalnym resolverze BIND9 mechanizmu Response Policy Zones z automatyczną listą reputacyjną umożliwiło natychmiastowe zrywanie sesji tunelujących. Skonfigurowanie reguł detekcji w systemie Suricata pozwoliło na alarmowanie o powtarzalnych zapytaniach FQDN o długości przekraczającej 60 znaków generowanych w stałych odstępach czasu. Wprowadzone zabezpieczenia skutecznie zablokowały kanał eksfiltracji danych z odizolowanej strefy badawczej, spełniając najwyższe normy bezpieczeństwa fizycznego i teleinformatycznego.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon4 Bezpieczeństwo protokołów komunikacyjnych i sieci komputerowych. W1 Mechanizmy wirtualizacji, przestrzenie nazw jądra Linux, grupy kontrolne cgroups i bezpieczeństwo kontenerów.

Głównym celem zadania jest przeprowadzenie audytu bezpieczeństwa środowiska wirtualizacji kontenerowej Docker oraz demonstracja wektorów ucieczki z kontenera do systemu operacyjnego gospodarza. Zespół laboratoryjny bada ryzyko związane z niebezpieczną konfiguracją uprawnień, w tym uruchamianiem kontenerów z flagą uprzywilejowaną, montowaniem gniazda unixowego docker.sock oraz nadmiarowymi uprawnieniami jądra. W części praktycznej studenci symulują przejęcie uprawnień administratora węzła klastra poprzez modyfikację mechanizmów cgroups oraz bezpośredni dostęp do urządzeń blokowych. Doświadczenie uświadamia, że sama izolacja przestrzeni nazw bez dodatkowych restrykcji nie stanowi wystarczającej bariery ochronnej.

W ramach inżynierii defensywnej grupa wdraża mechanizmy utwardzenia środowiska zgodnie z wytycznymi CIS Docker Benchmark. Studenci konfigurują dedykowane profile AppArmor oraz filtry wywołań systemowych seccomp, a także uruchamiają demona Dockera w trybie rootless uniemożliwiającym eskalację do uprawnień roota gospodarza. Sprawozdanie zawiera kompletną matrycę audytową, analizę wektora CVSS v3.1 oraz wytyczne dla zespołów DevOps budujących obrazy w łańcuchu CI/CD.

Spółka technologiczna „FinCloud Services” świadczy usługi hostingu mikroserwisów transakcyjnych dla instytucji finansowych w oparciu o środowisko Docker na serwerach z systemem Linux. W celu uproszczenia procedur wdrożeniowych programiści uruchomili kontener narzędziowy CI/CD z uprawnieniami uprzywilejowanymi oraz zamontowanym gniazdem sterującym silnika kontenerów.

Wewnętrzny audyt bezpieczeństwa wykazał, że w przypadku skompromitowania takiego kontenera atakujący może w ułamku sekundy uzyskać pełną kontrolę nad systemem operacyjnym serwera fizycznego. Dostęp do gniazda docker.sock pozwala na uruchomienie nowego kontenera z podmontowanym głównym systemem plików gospodarza, co całkowicie niweluje izolację procesów.

Zadaniem grupy audytorskiej jest przetestowanie dwóch scenariuszy ucieczki z kontenera: poprzez manipulację mechanizmem powiadamiania cgroups release_agent oraz poprzez interakcję z gniazdem zarządzającym. Studenci dokumentują kolejne etapy eskalacji w kontrolowanym środowisku wirtualnym bez wpływu na inne instancje.

Zespół defensywny przeprowadza audyt zgodności konfiguracji za pomocą narzędzia docker-bench-security, a następnie wdraża kompleksowe zabezpieczenia. Inżynierowie tworzą restrykcyjne profile seccomp blokujące niebezpieczne wywołania systemowe, konfigurują profile AppArmor oraz przenoszą usługi do trybu rootless. Wszystkie pliki konfiguracyjne i listingi CLI zostają włączone do raportu.

• Silnik kontenerów Docker Community Edition na systemie Linux Debian / Ubuntu
• Narzędzie audytowe docker-bench-security do weryfikacji zgodności z normą CIS
• Narzędzia AppArmor (apparmor-utils, aa-status, aa-complain)
• Biblioteka i narzędzia kontroli wywołań systemowych seccomp (libseccomp)
• Narzędzia inspekcji jądra i procesów: strace, capsh, nsenter
• Pakiet docker-ce-rootless-extras do uruchamiania demona bez uprawnień roota

1. Przygotowanie maszyny wirtualnej z zainstalowanym silnikiem Docker CE i włączoną obsługą modułów AppArmor.
2. Uruchomienie skryptu docker-bench-security i analiza raportu identyfikującego niebezpieczne domyślne parametry demona.
3. Uruchomienie podatnego kontenera testowego z flagą --privileged symulującego środowisko deweloperskie.
4. Weryfikacja listy uprawnień jądra (Linux Capabilities) wewnątrz kontenera za pomocą polecenia capsh --print.
5. Przeprowadzenie ucieczki z kontenera uprzywilejowanego za pomocą odwołania do mechanizmu notify_on_release w cgroups.
6. Wstrzyknięcie zlecenia wykonania polecenia zapisu do pliku gospodarza /tmp/escape.txt i weryfikacja jego utworzenia.
7. Uruchomienie drugiego scenariusza: kontener z zamontowanym wolumenem gniazda /var/run/docker.sock.
8. Wykorzystanie klienta dockera wewnątrz kontenera do uruchomienia nadrzędnego kontenera montującego /host z systemu plików gospodarza.
9. Wykonanie polecenia chroot /host i demonstracja uzyskania interaktywnej powłoki roota serwera fizycznego.
10. Zaprojektowanie restrykcyjnego profilu seccomp blokującego wywołania systemowe mount, ptrace oraz unshare.
11. Uruchomienie kontenera z nowym profilem seccomp i potwierdzenie zablokowania prób manipulacji jądrem.
12. Opracowanie profilu AppArmor dla kontenerów aplikacyjnych ograniczającego dostęp do katalogów /proc i /sys.
13. Konfiguracja flagi --read-only oraz parametru --security-opt=no-new-privileges:true w definicji kontenera.
14. Instalacja i konfiguracja środowiska Docker Rootless uruchamianego całkowicie w przestrzeni użytkownika.
15. Weryfikacja niemożności ucieczki do konta roota gospodarza nawet w przypadku uruchomienia kontenera uprzywilejowanego w trybie rootless.
16. Ponowne uruchomienie docker-bench-security i weryfikacja podniesienia ogólnego wskaźnika zgodności środowiska.
17. Sporządzenie formalnego sprawozdania z macierzą uprawnień, wektorem CVSS v3.1 i procedurą bezpiecznego wdrażania kontenerów.

Uruchomienie kontenera z flagą --privileged nadaje procesom niemal wszystkie możliwości jądra (Capabilities) oraz dostęp do urządzeń /dev gospodarza. Mechanizm cgroups release_agent wywołuje polecenie w przestrzeni jądra gospodarza w momencie zakończenia ostatniego procesu w grupie kontrolnej:

Poniższy listing demonstruje klasyczny skrypt ucieczki wykorzystujący mechanizm release_agent kontrolera pamięci cgroups v1:

Drugi powszechny błąd polega na udostępnieniu gniazda sterującego docker.sock wewnątrz kontenera. Pozwala to na utworzenie kolejnego kontenera montującego korzeń systemu plików gospodarza:

Utwardzenie środowiska polega na zastosowaniu restrykcyjnego profilu seccomp blokującego wywołania systemowe niezbędne do montowania i manipulacji przestrzeniami nazw:

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

1. Analiza wektorów ucieczki z kontenera (Container Breakout): zamontowane gniazdo docker.sock, flaga uprzywilejowana oraz nadmiarowe zdolności jądra.
2. Praktyczna demonstracja eksploatacji otwartego gniazda Dockera w celu uruchomienia uprzywilejowanego kontenera montującego system plików hosta.
3. Architektura Docker Rootless: uruchamianie demona i kontenerów w przestrzeni nazw użytkownika (User Namespaces) bez uprawnień roota na hoście.
4. Zastosowanie niemutowalnego systemu plików (read-only filesystem) oraz odrzucenie zbędnych zdolności jądra systemu Linux.
5. Ograniczanie powierzchni ataku na jądro Linuksa za pomocą profili Seccomp (blokowanie wywołań systemowych) oraz polityk AppArmor i SELinux.
6. Ciągły audyt konfiguracji konteneryzacji w oparciu o wytyczne CIS Docker Benchmark i zautomatyzowane narzędzia skanujące.

Przykładowe wnioski (wzór do sprawozdania): Audyt środowiska kontenerowego wykazał, że pozostawienie zamontowanego gniazda docker.sock w kontenerze CI/CD pozwala na natychmiastowe przejęcie całkowitej kontroli nad serwerem gospodarza. W ramach demonstracji ataku utworzono z wnętrza kontenera nową instancję z prawami roota montującą katalog główny hosta, uzyskując pełny dostęp do danych innych klientów w czasie poniżej jednej minuty. Wdrożenie trybu Docker Rootless w połączeniu z separacją przestrzeni nazw użytkowników uniemożliwiło procesom w kontenerze wykonywanie jakichkolwiek operacji administracyjnych na maszynie fizycznej. Zastosowanie flagi read-only dla systemu plików oraz odrzucenie wszystkich domyślnych zdolności jądra zablokowało możliwość pobrania i kompilacji exploitów lokalnych. Zrealizowane procedury utwardzające pozwoliły platformie na osiągnięcie 98% zgodności z zaleceniami CIS Docker Benchmark i spełnienie wymagań instytucji nadzoru finansowego.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon4 Bezpieczeństwo protokołów komunikacyjnych i sieci komputerowych. W1 Desynchronizacja protokołu HTTP, potokowanie zapytań i bezpieczeństwo pamięci podręcznej.

Celem ćwiczenia jest zbadanie mechanizmu desynchronizacji parsowania zapytań HTTP na styku serwera pośredniczącego reverse proxy oraz serwera aplikacji zaplecza. Studenci analizują podatności typu HTTP Request Smuggling w wariantach CL.TE oraz TE.CL, wynikające z rozbieżności interpretacji nagłówków Content-Length i Transfer-Encoding. W ramach symulacji laboratoryjnej zespół preparuje niestandardowe ramki protokołu HTTP/1.1, które pozwalają na przemycenie ukrytego zapytania do potoku przetwarzania. Badanie dowodzi, że brak spójności w implementacji specyfikacji RFC może prowadzić do nieautoryzowanego dostępu do danych innych użytkowników.

Druga część zadania poświęcona jest wykorzystaniu przemyconych zapytań do zatrucia pamięci podręcznej serwera brzegowego (Web Cache Poisoning) oraz kradzieży ciasteczek sesyjnych. Studenci projektują skuteczne środki zaradcze poprzez wymuszenie protokołu HTTP/2 na całej ścieżce komunikacji oraz wdrożenie ścisłej normalizacji nagłówków w serwerach Nginx i HAProxy. W sprawozdaniu grupa zamieszcza zrzuty heksadecymalne przesłanych pakietów, analizę wektora CVSS v3.1 oraz konfiguracje utwardzające serwery proxy.

Portal informacyjno-transakcyjny „e-Wiadomości” obsługuje miliony zapytań dziennie, wykorzystując architekturę dwuwarstwową: serwer buforujący i równoważący obciążenie HAProxy na brzegu sieci oraz klaster serwerów aplikacji opartych na serwerze Nginx i demonach Python Gunicorn w warstwie wewnętrznej.

Pomiędzy warstwą brzegową a zapleczem aplikacyjnym ruch przesyłany jest trwałymi połączeniami protokołu HTTP/1.1 w celu zmniejszenia opóźnień sieciowych. Podczas przeglądu konfiguracji audytorzy zauważyli, że serwer brzegowy priorytetowo traktuje nagłówek Content-Length, podczas gdy serwer aplikacji zaplecza interpretuje nagłówek Transfer-Encoding chunked, co tworzy klasyczną podatność desynchronizacji CL.TE.

Grupa audytorska przyjmuje rolę testerów bezpieczeństwa badających możliwość przemycenia zapytania administracyjnego w ciele pozornie poprawnego żądania publicznego. Studenci mają za zadanie wykazać, że odpowiedź na przemycone żądanie może trafić do pamięci podręcznej serwera proxy i zostać zaserwowana przypadkowym użytkownikom przeglądającym stronę główną portalu.

Zespół obronny ma za zadanie zlikwidować podatność bez uszczerbku dla wydajności portalu. Inżynierowie rekonfigurują reguły parsowania nagłówków w HAProxy, blokując wszelkie zapytania zawierające jednocześnie oba nagłówki długości, oraz wdrażają protokół HTTP/2 end-to-end eliminujący niejednoznaczność granic komunikatów. Wyniki testów i zrzuty konfiguracji zostają opisane w sprawozdaniu.

• Serwer proxy i load balancer HAProxy w wersji 2.6/2.8
• Serwer WWW i reverse proxy Nginx z modułem buforowania proxy_cache
• Serwer aplikacji Python Gunicorn z prostą aplikacją Flask
• Narzędzie netcat oraz klient curl do wysyłania surowych zapytań TCP
• Wireshark do inspekcji ramek i potoków HTTP w warstwie transportowej
• Narzędzie Burp Suite Community do powtarzania zapytań HTTP Repeater

1. Zbudowanie dwuwarstwowego środowiska testowego z serwerem HAProxy na froncie i serwerem Gunicorn na zapleczu.
2. Weryfikacja konfiguracji trwałych połączeń HTTP Keep-Alive na styku serwera proxy i serwera aplikacji.
3. Wysłanie kontrolnego zapytania HTTP/1.1 i weryfikacja poprawnego routingu odpowiedzi przez HAProxy.
4. Spreparowanie surowego zapytania zawierającego nagłówek Content-Length oraz Transfer-Encoding: chunked (wariant CL.TE).
5. Wysłanie przygotowanego zapytania za pomocą netcat z dołączeniem przemyconego prefiksu GET /admin HTTP/1.1.
6. Wysłanie drugiego, standardowego zapytania użytkownika i zarejestrowanie nieoczekiwanej odpowiedzi 404 lub 403 z zasobu /admin.
7. Analiza błędu desynchronizacji w zrzucie ruchu Wireshark dokumentująca rozbieżność wskaźników długości.
8. Odtworzenie wariantu TE.CL poprzez celowe zaciemnienie nagłówka Transfer-Encoding (np. dodanie spacji lub podwójnego nagłówka).
9. Zaprojektowanie scenariusza zatrucia pamięci podręcznej (Web Cache Poisoning) z wykorzystaniem przemyconego zapytania.
10. Przesłanie ładunku wymuszającego zapisanie fałszywej odpowiedzi w buforze proxy_cache dla ścieżki /index.html.
11. Weryfikacja serwowania zatrutej zawartości czystej sesji przeglądarki bez ingerencji w jej komunikację.
12. Rekonfiguracja HAProxy: włączenie rygorystycznego trybu normalizacji nagłówków i odrzucania niejednoznacznych żądań.
13. Weryfikacja działania dyrektyw http-request deny w przypadku wykrycia jednoczesnej obecności obu nagłówków.
14. Wdrożenie pełnej obsługi protokołu HTTP/2 między klientem, proxy a serwerami aplikacji zaplecza.
15. Ponowna próba przeprowadzenia ataku na środowisko utwardzone i potwierdzenie odrzucenia pakietu błędem 400 Bad Request.
16. Opracowanie reguły dla systemu IDS Suricata analizującej nieprawidłowe kombinacje nagłówków HTTP.
17. Przygotowanie sprawozdania technicznego z wyznaczeniem wektora CVSS v3.1, diagramem przepływu i konfiguracjami obronnymi.

Podatność HTTP Request Smuggling wariantu CL.TE polega na tym, że serwer frontowy (np. HAProxy) przetwarza nagłówek Content-Length, natomiast serwer aplikacji zaplecza uznaje nagłówek Transfer-Encoding: chunked. Poniższy listing ilustruje surową strukturę przemycanego zapytania:

Wysłanie surowego strumienia bajtów za pomocą netcat pozwala na ominięcie automatycznej normalizacji nagłówków realizowanej przez standardowe biblioteki klienta HTTP:

W celu ochrony przed atakami desynchronizacji w serwerze HAProxy konfiguruje się ścisłe reguły odrzucające zapytania posiadające oba nagłówki:

Równocześnie serwer Nginx w roli zaplecza należy skonfigurować zgodnie z rygorami normy RFC 9112, uniemożliwiając niejednoznaczne traktowanie nagłówków:

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

1. Mechanizm rozbieżności w parsowaniu nagłówków HTTP (HTTP Request Smuggling): konflikty pomiędzy Content-Length a Transfer-Encoding.
2. Kategoryzacja podatności: wariant CL.TE (frontend przetwarza CL, backend przetwarza TE) oraz TE.CL (frontend przetwarza TE, backend przetwarza CL).
3. Konsekwencje eksploatacji Request Smuggling: zatruwanie kolejki żądań innych użytkowników, kradzież ciasteczek sesyjnych i omijanie kontroli dostępu.
4. Mechanizm ataku zatruwania pamięci podręcznej (Web Cache Poisoning): manipulacja niekluczowymi nagłówkami HTTP w celu trwałego wstrzyknięcia złośliwej treści.
5. Konfiguracja utwardzonych serwerów pośredniczących: standaryzacja żądań HTTP/1.1 lub pełna migracja do protokołu HTTP/2 w całej ścieżce komunikacyjnej.
6. Metodyka audytu i automatyzacji testów desynchronizacji HTTP za pomocą wyspecjalizowanych narzędzi testowych.

Przykładowe wnioski (wzór do sprawozdania): Praktyczne testy podatności protokołu HTTP ujawniły krytyczną desynchronizację w przetwarzaniu nagłówków pomiędzy serwerem brzegowym HAProxy a serwerem aplikacji Nginx w architekturze portalu. Wykorzystanie wariantu ataku CL.TE z podwójnym nagłówkiem Transfer-Encoding pozwoliło na przemycenie ukrytego żądania HTTP, które zostało doklejone do kolejnego legalnego zapytania innego użytkownika. W rezultacie napastnik przechwycił wrażliwe tokeny uwierzytelniające sesji administratora oraz zatruł pamięć podręczną złośliwym skryptem JavaScript serwowanym milionom czytelników. Trwałym rozwiązaniem problemu było zrekonfigurowanie serwera pośredniczącego w celu bezwzględnego odrzucania żądań zawierających jednocześnie nagłówki Content-Length i Transfer-Encoding oraz włączenie ścisłej normalizacji protokołu HTTP/2. Przeprowadzone wdrożenie całkowicie usunęło podatności desynchronizacji zgodnie z najnowszymi wytycznymi bezpieczeństwa PortSwigger Web Security Academy.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon4 Bezpieczeństwo protokołów komunikacyjnych i sieci komputerowych. W1 Architektura chmury obliczeniowej, tożsamość IAM, usługa metadanych instancji i ochrona SSRF.

Celem zadania jest zbadanie podatności fałszowania żądań po stronie serwera (SSRF) w środowisku chmury hybrydowej oraz ocena ryzyka kompromitacji ról tożsamości IAM. Zespół audytorski analizuje aplikację webową pobierającą zasoby zewnętrzne, która umożliwia wysłanie nieautoryzowanego zapytania do adresu łącza lokalnego usługi metadanych instancji. Studenci przeprowadzają symulację ataku na usługę IMDSv1 w celu ekstrakcji tymczasowych poświadczeń bezpieczeństwa przypisanych do maszyny wirtualnej. Ćwiczenie uczy modelowania zagrożeń w architekturze chmurowej i pozwala zrozumieć skutki nadawania instancjom nadmiernych uprawnień w modelu IAM.

W fazie obronnej studenci przeprowadzają migrację usługi do bezpiecznego standardu IMDSv2, który wymusza autoryzację sesyjną tokenem pobieranym metodą PUT oraz ogranicza limit przeskoków pakietu IP. Dodatkowo grupa konfiguruje reguły filtrowania ruchu wychodzącego za pomocą zapory iptables oraz definiuje polityki minimalnych uprawnień Least Privilege dla ról aplikacyjnych. Końcowy raport zawiera kalkulację CVSS v3.1, reguły zapory oraz procedurę bezpiecznego zarządzania tożsamością w chmurze hybrydowej.

Korporacja ubezpieczeniowa „Asekuracja Polska” przetwarza wnioski o likwidację szkód w infrastrukturze chmury hybrydowej. Na maszynach wirtualnych uruchomiono portal dla klientów, który pozwala na dołączanie zdjęć uszkodzonych pojazdów poprzez podanie adresu URL pliku znajdującego się w zewnętrznym repozytorium.

Programiści wdrożyli moduł pobierania plików bez weryfikacji docelowego adresu IP, co pozwala użytkownikowi na wskazanie adresu pętli zwrotnej lub adresu łącza lokalnego 169.254.169.254. Poprzez ten adres instancja komunikuje się z usługą Instance Metadata Service w celu pobierania parametrów konfiguracyjnych i poświadczeń ról IAM.

Audytorzy mają za zadanie wykazać, że nieuwierzytelniony użytkownik portalu może za pośrednictwem luki SSRF odpytać usługę IMDSv1 i wyciągnąć klucz dostępowy, klucz tajny oraz token sesyjny AWS. Uzyskane poświadczenia pozwalają na bezpośrednie wywołanie interfejsów API dostawcy chmury i dostęp do zasobników S3 przechowujących dokumentację medyczną i dane osobowe klientów.

Zespół defensywny projektuje architekturę uniemożliwiającą eksfiltrację tożsamości. Studenci wdrażają wymuszenie IMDSv2 z parametrem hop-limit równym 1, co uniemożliwia kontenerom i procesom pośredniczącym odpytanie usługi, wprowadzają reguły zapory nftables blokujące dostęp do metadanych dla kont nieuprzywilejowanych oraz definiują rygorystyczne polityki IAM. Wyniki testów zostają udokumentowane w sprawozdaniu.

• Środowisko LocalStack lub emulator mock-imds do symulacji usługi metadanych chmurowych
• Biblioteka Python boto3 do weryfikacji uprawnień wyekstrahowanych poświadczeń
• Narzędzie curl oraz parser jq do manipulacji zapytaniami HTTP do API metadanych
• Systemowa zapora sieciowa iptables oraz nftables do blokowania ruchu łącza lokalnego
• Środowisko Open Policy Agent (OPA) do weryfikacji reguł minimalnych uprawnień IAM
• Aplikacja demonstracyjna w języku Python Flask podatna na Server-Side Request Forgery

1. Uruchomienie emulatora usługi metadanych instancji IMDS nasłuchującego na adresie 169.254.169.254:80.
2. Wdrożenie podatnej aplikacji webowej przyjmującej parametr url w module pobierania załączników.
3. Weryfikacja bezpośredniego odpytania ścieżki /latest/meta-data/ za pomocą polecenia curl ze stacji roboczej.
4. Spreparowanie zapytania HTTP do aplikacji webowej wymuszającego pobranie adresu metadanych instancji.
5. Identyfikacja nazwy przypisanej roli IAM poprzez odpytanie ścieżki /iam/security-credentials/.
6. Pobranie pełnego zestawu poświadczeń tymczasowych: AccessKeyId, SecretAccessKey oraz Token.
7. Konfiguracja profilu w narzędziu AWS CLI z wykorzystaniem skradzionych poświadczeń tymczasowych.
8. Próba wylistowania zawartości magazynów chmurowych S3 i potwierdzenie nieautoryzowanego dostępu.
9. Analiza mechanizmu ochrony standardu IMDSv2 opartego na wymogu sesyjnego tokenu pobieranego metodą PUT.
10. Rekonfiguracja usługi metadanych: wyłączenie IMDSv1 i włączenie wymogu tokenu z nagłówkiem X-aws-ec2-metadata-token.
11. Próba ponownego wykonania ataku SSRF metodą GET przeciwko IMDSv2 i weryfikacja błędu 401 Unauthorized.
12. Analiza ograniczenia parametru hop-limit=1 w pakietach IP uniemożliwiającego dostęp z poziomu kontenerów Docker.
13. Konfiguracja reguły zapory iptables blokującej dostęp do adresu 169.254.169.254 dla użytkownika www-data.
14. Przetestowanie działania reguły zapory i potwierdzenie całkowitego zablokowania połączeń z procesu aplikacji.
15. Opracowanie polityki IAM opartej na zasadzie najmniejszych uprawnień (Least Privilege) wykluczającej prawa do S3.
16. Weryfikacja odmowy dostępu do wrażliwych zasobników chmurowych pomimo ewentualnego przejęcia tożsamości.
17. Sporządzenie sprawozdania technicznego z wyznaczeniem wektora CVSS v3.1, diagramem sieciowym i procedurą migracji do IMDSv2.

W standardzie IMDSv1 usługa metadanych instancji odpowiada na zwykłe zapytania HTTP GET bez żadnego nagłówka autoryzacyjnego. Pozwala to atakującemu na łatwe wyciągnięcie tymczasowych kluczy IAM za pośrednictwem luki SSRF:

Standard IMDSv2 wprowadza wymuszenie pobrania tokenu sesyjnego metodą PUT z nagłówkiem X-aws-ec2-metadata-token-ttl-seconds, co skutecznie blokuje większość klasycznych ataków SSRF:

W celu wymuszenia bezpiecznego standardu IMDSv2 na poziomie instancji oraz ograniczenia liczby przeskoków pakietu konfiguruje się atrybuty metadanych w interfejsie CLI:

Dodatkową warstwę ochrony w systemie operacyjnym instancji stanowi reguła zapory iptables, która blokuje dostęp do adresu 169.254.169.254 dla konta użytkownika serwera WWW:

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

1. Anatomia podatności Server-Side Request Forgery (SSRF) i eskalacja uprawnień poprzez dostęp do interfejsu metadanych instancji chmurowej.
2. Porównanie mechanizmów bezpieczeństwa: podatny protokół IMDSv1 w zestawieniu z utwardzonym protokołem IMDSv2 wymagającym tokena sesyjnego.
3. Kradzież tymczasowych poświadczeń ról chmurowych (IAM Role Credentials) i przejęcie kontroli nad zasobami w chmurze obliczeniowej.
4. Wdrożenie zasady najmniejszych uprawnień (Least Privilege) w politykach IAM: eliminacja ról wielozadaniowych i nadmiarowych praw administratorskich.
5. Ochrona sieciowa punktu końcowego IMDS: reguły zapory ogniowej blokujące dostęp do adresu metadanych dla procesów serwera aplikacji.
6. Walidacja danych wejściowych w aplikacji: rygorystyczna biała lista dozwolonych domen oraz blokada prywatnych adresów IP (RFC 1918 i pętli zwrotnej).

Przykładowe wnioski (wzór do sprawozdania): Symulacja ataku SSRF w module pobierania dokumentacji wykazała, że podatność aplikacji pozwalała na bezpośrednie odpytanie adresu metadanych instancji chmurowej i pozyskanie poświadczeń roli IAM. W środowisku z aktywnym protokołem IMDSv1 napastnik natychmiast wyekstrahował tymczasowe klucze dostępowe, co pozwoliło mu na enumerację prywatnych zasobów magazynu chmurowego organizacji. Wymuszenie na wszystkich maszynach wirtualnych protokołu IMDSv2 w połączeniu z restrykcyjnym limitem przeskoków pakietów całkowicie udaremniło ten wektor ataku. Dodatkowo wdrożono lokalną regułę zapory iptables odcinającą proces serwera aplikacji od podsieci metadanych oraz ograniczono uprawnienia roli IAM wyłącznie do zapisu w jednym, dedykowanym zasobniku. Opracowane zabezpieczenia skutecznie zamknęły krytyczną ścieżkę eksfiltracji danych chmurowych, spełniając zalecenia dobrych praktyk bezpieczeństwa dostawców chmury.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon3 Symetryczne i niesymetryczne algorytmy szyfrowania. Podpisy cyfrowe i funkcje skrótu. W3 Kryptoanaliza tokenów uwierzytelniających JWT, integralność podpisów i schematy wymiany kluczy.

Celem zadania jest przeprowadzenie kryptoanalizy implementacji tokenów JSON Web Token oraz zbadanie podatności wynikających z błędów weryfikacji podpisów cyfrowych. Studenci analizują dwa krytyczne wektory ataku: wyłączenie walidacji sygnatury poprzez manipulację nagłówkiem algorytmu do wartości none oraz atak zamiany klucza (Key Confusion). W ramach symulacji laboratoryjnej zespół modyfikuje asymetryczny schemat weryfikacji RS256, zmuszając bibliotekę serwerową do potraktowania klucza publicznego jako symetrycznego sekretu algorytmu HMAC HS256. Projekt uczy rygorystycznego podejścia do implementacji kryptograficznych i wykazuje niebezpieczeństwa wynikające z automatycznego ufania parametrom nagłówka przesyłanym przez klienta.

W części defensywnej grupa projektuje bezpieczną architekturę walidacji tokenów w oparciu o białą listę dozwolonych algorytmów oraz jawne powiązanie kluczy z ich identyfikatorami Key ID. Studenci implementują mechanizm ścisłej weryfikacji czasu ważności tokenu i sygnatury kryptograficznej, a także konfigurują reguły inspekcji w bramie API Gateway blokujące podejrzane tokeny. Końcowy raport z audytu zawiera wektor CVSS v3.1, kod autorskich skryptów weryfikacyjnych w języku Python oraz wytyczne dla programistów tworzących usługi uwierzytelniania w architekturze Zero Trust.

Platforma bankowości elektronicznej „NeoBank Polska” wykorzystuje architekturę mikroserwisów, w której tożsamość użytkownika przekazywana jest w nagłówku autoryzacji HTTP w postaci bezstanowego tokenu JSON Web Token (JWT). Serwer uwierzytelniający podpisuje tokeny za pomocą klucza prywatnego RSA o długości 2048 bitów (algorytm RS256).

Bramy API oraz poszczególne mikroserwisy weryfikują podpis tokenu, pobierając klucz publiczny RSA wystawcy z publicznie dostępnego punktu końcowego certyfikatów. Podczas przeglądu kodu biblioteki uwierzytelniającej audytorzy zauważyli, że funkcja weryfikująca odczytuje algorytm podpisu bezpośrednio z nagłówka alg przesłanego tokenu i przekazuje pobrany klucz publiczny do funkcji sprawdzającej bez wymuszenia konkretnego algorytmu asymetrycznego.

Zespół audytorski ma za zadanie zweryfikować możliwość podrobienia tożsamości administratora systemu. Studenci konstruują ładunek podmieniający algorytm na HS256, w którym podpis generowany jest algorytmem HMAC-SHA256 z wykorzystaniem jawnego tekstu klucza publicznego RSA jako symetrycznego sekretu. Skuteczna weryfikacja takiego tokenu pozwala na nieautoryzowany dostęp do operacji finansowych.

Zespół obronny ma za zadanie zrekonfigurować bibliotekę uwierzytelniania i bramę API, wprowadzając sztywne wymuszenie algorytmu RS256 oraz odrzucanie jakichkolwiek tokenów z algorytmem none lub symetrycznym HS256. Studenci testują działanie nowej procedury weryfikacyjnej, sprawdzając odmowę dostępu dla zmanipulowanych tokenów. Wyniki testów zostają udokumentowane w sprawozdaniu.

• Środowisko Python 3 z bibliotekami PyJWT, cryptography oraz requests
• Narzędzie OpenSSL do inspekcji i konwersji formatów kluczy kryptograficznych (PEM, DER, JWK)
• Narzędzie jwt_tool do zautomatyzowanego testowania podatności tokenów JWT
• Hashcat do łamania słabych kluczy symetrycznych HMAC w trybie 16500
• Klient HTTP curl oraz parser JSON jq do ręcznej weryfikacji odpowiedzi API
• Framework Flask do uruchomienia demonstracyjnego punktu końcowego API

1. Uruchomienie serwera uwierzytelniania generującego tokeny JWT z podpisem RS256 oraz podatnego punktu końcowego API.
2. Pobranie przykładowego poprawnego tokenu użytkownika i zdekodowanie jego składowych: Header, Payload i Signature.
3. Sprawdzenie publicznego punktu końcowego serwera w celu pobrania klucza publicznego RSA w formacie PEM.
4. Przeprowadzenie testu podatności na usunięcie podpisu poprzez zmianę wartości nagłówka alg na none.
5. Wysłanie tokenu z pustym podpisem do API i weryfikacja odpowiedzi serwera.
6. Analiza mechanizmu podatności Key Confusion (zamiana algorytmu asymetrycznego RS256 na symetryczny HS256).
7. Napisanie skryptu w języku Python czytającego publiczny klucz RSA jako surowy ciąg bajtów symetrycznego sekretu HMAC.
8. Spreparowanie fałszywego tokenu z rolą administratora admin: true i wyliczenie poprawnego podpisu HMAC-SHA256.
9. Wysłanie sfałszowanego tokenu do chronionego zasobu API /api/admin/przelew i potwierdzenie ominięcia autoryzacji.
10. Analiza błędu implementacyjnego w bibliotece weryfikującej polegającego na dynamicznym doborze algorytmu.
11. Przeprowadzenie próby złamania symetrycznego sekretu HMAC za pomocą narzędzia Hashcat w trybie 16500.
12. Implementacja bezpiecznej procedury weryfikacji tokenu z jawną białą listą algorytmów algorithms=['RS256'].
13. Wdrożenie weryfikacji identyfikatora klucza kid z bazą zaufanych kluczy publicznych po stronie serwera.
14. Przetestowanie działania zaktualizowanego API przeciwko spreparowanemu tokenowi i rejestracja błędu InvalidAlgorithmError.
15. Konfiguracja reguły weryfikacji nagłówków na bramie API Gateway odrzucającej tokeny z niedozwolonymi algorytmami.
16. Weryfikacja rygorystycznej kontroli czasu wygaśnięcia tokenu (claim exp) oraz znacznika nbf (Not Before).
17. Sporządzenie sprawozdania technicznego z wyznaczeniem wektora CVSS v3.1, kodami PoC i wytycznymi bezpiecznej kryptografii.

Atak Key Confusion polega na wykorzystaniu faktu, że serwer weryfikujący podpis tokenu JWT dysponuje kluczem publicznym RSA. Jeżeli atakujący zmieni nagłówek na HS256, biblioteka weryfikująca potraktuje klucz publiczny jako symetryczny sekret HMAC:

Poniższy autorski skrypt w języku Python tworzy sfałszowany token administratora podpisany algorytmem HS256 przy użyciu pobranego klucza publicznego:

Przesłanie sfałszowanego tokenu do podatnego punktu końcowego API skutkuje pomyślną weryfikacją podpisu i przyznaniem uprawnień administratora:

Bezpieczna implementacja weryfikacji tokenu wymaga jawnego zdefiniowania białej listy algorytmów oraz użycia odpowiedniego obiektu klucza asymetrycznego:

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

1. Analiza podatności bibliotek weryfikujących tokeny JWT: akceptacja algorytmu 'none' i modyfikacja ładunku bez ważnego podpisu kryptograficznego.
2. Matematyczny mechanizm ataku zamiany klucza (Algorithm Confusion): weryfikacja podpisu RS256 za pomocą HS256 z kluczem publicznym RSA.
3. Łamanie słabych sekretów symetrycznych HS256 za pomocą dedykowanych narzędzi łamiących i słowników z regułami mutacyjnymi.
4. Ataki na nagłówki wstrzykiwania kluczy: podatności parametrów jku oraz x5u umożliwiające podrobienie źródła zaufania certyfikatów.
5. Wymuszenie rygorystycznej walidacji po stronie serwera: sztywne przypisanie dozwolonego algorytmu i weryfikacja oświadczeń czasowych.
6. Zgodność z wytycznymi bezpieczeństwa tokenów tożsamościowych określonymi w standardzie RFC 8725.

Przykładowe wnioski (wzór do sprawozdania): Zaawansowana kryptoanaliza implementacji tokenów JWT w platformie bankowości elektronicznej ujawniła podatność biblioteki weryfikującej na atak typu Algorithm Confusion. Przekształcenie nagłówka z RS256 na HS256 i podpisanie tokena kluczem publicznym RSA potraktowanym jako ciąg bajtów HMAC pozwoliło na bezproblemowe podrobienie uprawnień dyrektora departamentu skarbu. Równoległe testy wykazały brak weryfikacji oświadczenia 'exp' w jednym z mikroserwisów wewnętrznych, co umożliwiało bezterminowe używanie przechwyconych tokenów sesyjnych. Rekonfiguracja modułu uwierzytelniania poprzez sztywne zdefiniowanie listy dopuszczalnych algorytmów oraz walidację klucza publicznego wyłącznie z wewnętrznego, bezpiecznego magazynu JWKS natychmiast zablokowała ten wektor exploita. Wprowadzenie rygorystycznych testów jednostkowych weryfikujących odporność na manipulacje nagłówkami uczyniło system w pełni zgodnym ze standardem RFC 8725.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon3 Symetryczne i niesymetryczne algorytmy szyfrowania. Podpisy cyfrowe i funkcje skrótu. W1 Mechanizmy ochronne systemów operacyjnych Windows, telemetria procesów i ochrona punktów końcowych.

Celem ćwiczenia jest zbadanie mechanizmu ochrony stacji roboczych Windows za pomocą interfejsu Antimalware Scan Interface (AMSI) oraz analiza technik omijania inspekcji pamięci. Zespół bada wektor ataku polegający na dynamicznym patchowaniu funkcji AmsiScanBuffer w przestrzeni adresowej procesu PowerShell bez posiadania uprawnień administratora. Studenci analizują strukturę biblioteki amsi.dll w debuggerze procesów, identyfikują kody powrotu oznaczające brak zagrożenia i modyfikują bajty instrukcji w pamięci RAM. Doświadczenie pozwala zrozumieć, że mechanizmy skanowania buforów w pamięci procesu użytkownika mogą zostać zneutralizowane przez ten sam proces bez naruszania integralności jądra.

W części defensywnej studenci wdrażają telemetrię opartą na usłudze Microsoft Sysmon oraz rejestracji bloków skryptów PowerShell Script Block Logging (Event ID 4104). Grupa projektuje regułę detekcyjną w formacie Sigma identyfikującą próby wywołań funkcji manipulacji pamięcią VirtualProtect oraz odwołań do biblioteki amsi.dll. Ponadto inżynierowie konfigurują tryb ograniczonego języka Constrained Language Mode w zasadach GPO, co trwale uniemożliwia wywołania mechanizmu P/Invoke. Sprawozdanie zawiera wektor CVSS v3.1, zrzuty pamięci oraz reguły monitorowania EDR.

Spółka strategiczna „Energo-Audyt” zarządza infrastrukturą sieci elektroenergetycznej, a stacje robocze inżynierów zabezpieczone są systemem Windows 10/11 Enterprise z aktywną ochroną antywirusową i włączonym mechanizmem AMSI. Administratorzy założyli, że zablokowanie pobierania znanych narzędzi audytorskich całkowicie chroni stacje przed uruchomieniem nieautoryzowanego kodu w pamięci.

Mechanizm AMSI integruje powłokę PowerShell z silnikiem antywirusowym, przekazując treść skryptu do skanowania tuż przed wykonaniem, nawet jeśli kod został wcześniej zaciemniony lub rozkodowany w locie. Jednak biblioteka amsi.dll jest ładowana do przestrzeni adresowej każdego procesu powłoki, co pozwala procesowi na modyfikację własnego kodu maszynowego.

Zespół audytorski ma za zadanie przeprowadzić analizę działania funkcji AmsiScanBuffer w wyizolowanym środowisku laboratoryjnym. Studenci opracowują skrypt w języku PowerShell korzystający z mechanizmu P/Invoke, który odnajduje adres funkcji, zmienia atrybuty ochrony strony pamięci na PAGE_EXECUTE_READWRITE i nadpisuje początkowe instrukcje kodem zwracającym sukces skanowania.

Zespół Blue Team analizuje zdarzenia generowane w dzienniku Microsoft-Windows-PowerShell/Operational oraz zdarzenia Microsoft Sysmon Event ID 7 (Image Loaded) i Event ID 1 (Process Creation). Inżynierowie tworzą regułę Sigma wykrywającą manipulacje w pamięci powłoki oraz wdrażają politykę blokującą nieautoryzowane typy .NET za pomocą trybu Constrained Language Mode i polityki AppLocker. Sprawozdanie zawiera pełną dokumentację wdrożenia.

• System operacyjny Windows 10 / 11 Enterprise z powłoką PowerShell 5.1 oraz 7.x
• Narzędzie Microsoft Sysmon (System Monitor) z konfiguracją telemetryczną SwiftOnSecurity
• Agent Winlogbeat oraz platforma SIEM Wazuh do agregacji zdarzeń bezpieczeństwa
• Narzędzie sigma-cli do tworzenia i kompilacji reguł detekcyjnych
• Debugger procesów x64dbg do inspekcji pamięci i kodu maszynowego biblioteki amsi.dll
• Narzędzie Process Hacker / Process Explorer do monitorowania załadowanych modułów DLL

1. Przygotowanie stacji roboczej Windows z aktywnym mechanizmem Microsoft Defender i AMSI.
2. Uruchomienie konsoli PowerShell i próba wykonania znanego ciągu testowego amsiutils w celu wywołania blokady.
3. Zarejestrowanie komunikatu błędu o zablokowaniu skryptu przez oprogramowanie antywirusowe.
4. Uruchomienie procesu PowerShell pod kontrolą debuggera x64dbg i zlokalizowanie modułu amsi.dll.
5. Analiza kodu maszynowego funkcji AmsiScanBuffer i identyfikacja rejestrów sprawdzających stan bufora.
6. Wyznaczenie sekwencji bajtów instruującej funkcję do natychmiastowego powrotu z kodem HRESULT S_OK (b0 57 c3).
7. Napisanie jednolinijkowca w języku PowerShell wykorzystującego refleksję .NET do zlokalizowania biblioteki w pamięci.
8. Wywołanie funkcji systemowej VirtualProtect w celu nadania praw zapisu do strony pamięci z kodem funkcji.
9. Nadpisanie pierwszych bajtów funkcji AmsiScanBuffer wyznaczoną sekwencją instrukcji.
10. Ponowna próba wywołania wcześniej zablokowanego ciągu testowego i potwierdzenie braku reakcji obronnej.
11. Analiza wpisów w dzienniku zdarzeń Microsoft-Windows-PowerShell/Operational pod kątem zdarzenia Event ID 4104.
12. Weryfikacja telemetrii Microsoft Sysmon: analiza zdarzenia Event ID 7 (załadowanie amsi.dll do procesu powershell.exe).
13. Opracowanie reguły Sigma wykrywającej odwołania do funkcji VirtualProtect oraz manipulacji ciągami amsi w ScriptBlock.
14. Konfiguracja polityki PowerShell Constrained Language Mode (CLM) za pomocą zmiennej środowiskowej i rejestru.
15. Próba ponownego uruchomienia skryptu patchującego w trybie CLM i weryfikacja zablokowania mechanizmu P/Invoke.
16. Konfiguracja reguł AppLocker wymuszających uruchamianie wyłącznie podpisanych cyfrowo skryptów.
17. Sporządzenie sprawozdania z analizą telemetrii, wektorem CVSS v3.1, kodami reguł detekcyjnych i zaleceniami obronnymi.

Próba wykonania w konsoli PowerShell ciągów powiązanych z narzędziami audytorskimi wywołuje natychmiastową blokadę ze strony mechanizmu AMSI:

Technika AMSI Memory Patching polega na modyfikacji pierwszych bajtów funkcji AmsiScanBuffer w pamięci RAM procesu. Poniższy skrypt wykorzystuje refleksję .NET do zmiany atrybutów pamięci i nadpisania instrukcji:

Bardziej odporna technika polega na bezpośrednim nadpisaniu bufora funkcji AmsiScanBuffer za pomocą wywołania VirtualProtect w kodzie C# skompilowanym w pamięci:

W celu wykrycia prób manipulacji w pamięci procesów powłoki tworzy się regułę Sigma analizującą logi PowerShell Script Block Logging (Event ID 4104):

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

1. Analiza architektury interfejsu AMSI (Antimalware Scan Interface) w systemie Windows i badanie wektorów jego omijania w pamięci procesu.
2. Techniki zaciemniania kodu PowerShell: manipulacja wielkością liter, konkatenacja ciągów, kodowanie Base64 oraz wywołania przez obiekty WMI.
3. Konfiguracja zaawansowanej telemetrii systemowej za pomocą narzędzia Microsoft Sysmon: rejestracja procesów, połączeń sieciowych i ładowania modułów.
4. Włączanie rejestracji bloków skryptu (Script Block Logging) w celu dekodowania i rejestracji zaciemnionego kodu w pamięci RAM.
5. Opracowanie i testowanie reguł detekcji Sigma oraz sygnatur YARA ukierunkowanych na wykrywanie technik Living off the Land.
6. Mapowanie obserwowanych technik adwersarza na taksonomię MITRE ATT&CK w obszarze omijania obrony i wykonywania kodu.

Przykładowe wnioski (wzór do sprawozdania): Praktyczna analiza działania technik zaciemniania kodu PowerShell wykazała, że tradycyjne programy antywirusowe opierające się na sygnaturach statycznych są całkowicie bezradne wobec techniki Memory Patching biblioteki amsi.dll. Zmodyfikowanie w pamięci procesu funkcji weryfikującej skanera pozwoliło napastnikowi na uruchomienie zaawansowanych narzędzi audytorskich bez wywołania jakiegokolwiek alertu bezpieczeństwa w domyślnym monitorze systemu. Wdrożenie narzędzia Microsoft Sysmon z dedykowaną konfiguracją telemetryczną pozwoliło jednak na zarejestrowanie anomalnego zachowania procesu oraz podejrzanych wstrzyknięć pamięciowych. Włączenie funkcji Script Block Logging w polisie GPO umożliwiło zarejestrowanie pełnego, zdekodowanego kodu skryptu tuż przed jego wykonaniem przez silnik interpretera. Na podstawie zebranej telemetrii opracowano skuteczne reguły Sigma, które w czasie rzeczywistym powiadamiają analityków SOC o próbach manipulacji mechanizmami obronnymi stacji roboczych.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon4 Bezpieczeństwo protokołów komunikacyjnych i sieci komputerowych. W1 Metodyka Purple Teaming, symulacja łańcucha ataku MITRE ATT&CK i inżynieria detekcji.

Celem zadania jest przeprowadzenie wieloetapowego ćwiczenia w modelu Purple Teaming łączącego symulację łańcucha ataku z inżynierią reguł detekcji w infrastrukturze korporacyjnej. Zespół laboratoryjny odtwarza pełną ścieżkę operacyjną adwersarza: od początkowego przełamania publicznej aplikacji w strefie DMZ, przez tunelowanie ruchu i poruszanie się lateralne, aż po kompromitację kontrolera domeny za pomocą techniki DCSync. Scenariusz pozwala studentom prześledzić współzależności pomiędzy poszczególnymi taktykami matrycy MITRE ATT&CK Enterprise. Równolegle ćwiczenie weryfikuje zdolność systemów monitorowania do wczesnego wykrywania anomalii na każdym etapie ataku.

W części inżynierii defensywnej grupa analizuje telemetrię sieciową i systemową w konsoli SIEM Wazuh oraz czujniku NIDS Suricata. Studenci konstruują zestaw dedykowanych reguł Sigma dla zdarzeń replikacji Active Directory (Event ID 4662) oraz sygnaturę sieciową dla nietypowego ruchu RPC protokołu DRSUAPI. Zwieńczeniem prac jest kompleksowy raport audytowy zawierający łańcuch wektorów CVSS v3.1, kalkulację czasu wykrycia MTTD oraz rekomendacje architektoniczne Zero Trust zgodne z ustawą o KSC.

Krajowy Operator Telekomunikacyjny „Telco-Pol” zarządza infrastrukturą szkieletową i węzłami tranzytowymi o kluczowym znaczeniu dla łączności państwa. W strefie DMZ udostępniono portal zgłoszeniowy dla klientów biznesowych zintegrowany z wewnętrzną bazą danych oraz domeną Active Directory.

Zarząd spółki zlecił przeprowadzenie ćwiczenia Purple Team w celu zweryfikowania odporności centrum operacji bezpieczeństwa (SOC) na złożony atak wieloetapowy. Scenariusz zakłada kompromitację serwera portalu poprzez lukę weryfikacji danych, zestawienie ukrytego kanału Chisel do sieci LAN oraz próbę przejęcia tożsamości domenowej poprzez atak replikacji DCSync.

Audytorzy Red Team realizują kolejne fazy ataku według ściśle zdefiniowanego harmonogramu czasowego. Po uzyskaniu powłoki na serwerze DMZ studenci eskalują uprawnienia lokalne, tunelują ruch do wewnętrznego segmentu sieci i przeprowadzają atak Pass-the-Hash z wykorzystaniem poświadczeń skradzionych z pamięci stacji roboczej. Finałowym krokiem jest uruchomienie skryptu secretsdump w celu pobrania skrótu konta krbtgt z kontrolera domeny.

Zespół Blue Team obserwuje napływającą telemetrię w czasie rzeczywistym, mierząc czas od wykonania ataku do pojawienia się alertu (Mean Time to Detect). Analitycy tworzą sygnatury sieciowe i reguły korelacyjne, a po zakończeniu ćwiczenia organizują wspólną sesję debriefingu w celu optymalizacji reguł detekcyjnych i uszczelnienia zapór sieciowych. Wszystkie ustalenia trafiają do raportu końcowego.

• Kali Linux ze środowiskiem narzędziowym (Impacket, CrackMapExec, Chisel)
• System wykrywania intruzów Suricata 7.x skonfigurowany w trybie nasłuchu sieciowego
• Platforma SIEM Wazuh zintegrowana z agentami na serwerach Linux i Windows
• Narzędzie Chisel do zestawiania tuneli SOCKS5 przez protokół HTTP/WebSockets
• Środowisko Windows Server 2022 w roli Kontrolera Domeny z audytem replikacji
• Narzędzie sigma-cli do translacji reguł Sigma na format zapytań Wazuh / Elasticsearch
• Wireshark do badania wywołań zdalnych procedur MS-DRSR (Directory Replication Service)

1. Zbudowanie wielosegmentowego środowiska sieciowego obejmującego sieć zewnętrzną, strefę DMZ oraz sieć LAN.
2. Przeprowadzenie rekonesansu usług w strefie DMZ i identyfikacja podatności zdalnego wykonania kodu na serwerze portalu.
3. Uzyskanie powłoki systemowej na serwerze DMZ i eskalacja uprawnień do konta root za pomocą luki lokalnej.
4. Uruchomienie serwera Chisel na stacji audytora i zestawienie tunelu wstecznego z przejętego serwera DMZ.
5. Konfiguracja narzędzia proxychains do przekierowywania narzędzi audytorskich do wewnętrznej podsieci LAN.
6. Skanowanie segmentu LAN przez tunel SOCKS5 w celu zidentyfikowania stacji administratora i kontrolera domeny.
7. Ekstrakcja skrótów NTLM z pamięci procesu LSASS stacji administratora za pomocą zrzutu pamięci.
8. Przeprowadzenie ataku Pass-the-Hash za pomocą narzędzia CrackMapExec w celu potwierdzenia ważności poświadczeń.
9. Wykonanie ataku DCSync przy użyciu skryptu secretsdump.py i zażądanie replikacji tożsamości z kontrolera domeny.
10. Pomyślne wyekstrahowanie skrótu hasła konta krbtgt oraz kont administratorów domenowych.
11. Analiza ruchu sieciowego w narzędziu Wireshark: badanie wywołań RPC do interfejsu DRSUAPI (GUID e3514235...).
12. Opracowanie sygnatury Suricata wykrywającej próby replikacji Active Directory pochodzące ze stacji roboczych.
13. Analiza zdarzeń Windows Security na kontrolerze domeny: weryfikacja wpisu Event ID 4662 (AccessMask 0x100).
14. Utworzenie reguły Sigma wykrywającej uprawnienie Replicating Directory Changes zgłaszane przez nie-kontrolery.
15. Konwersja reguły Sigma do formatu reguł XML platformy Wazuh i weryfikacja generowania alertu o poziomie krytycznym.
16. Pomiar wskaźnika czasu detekcji MTTD (Mean Time to Detect) oraz wskaźnika skuteczności pokrycia reguł.
17. Opracowanie zaleceń obronnych: segmentacja sieciowa Tier 0, ograniczenie uprawnień replikacji w ACL domeny.
18. Sporządzenie kompleksowego raportu z ćwiczenia Purple Team z mapowaniem na matrycę MITRE ATT&CK i wektorami CVSS.

Po przełamaniu maszyny w strefie DMZ zestawienie tunelu SOCKS5 za pomocą narzędzia Chisel pozwala na przekierowanie ruchu narzędzi audytorskich do wewnętrznej sieci korporacyjnej:

Za pośrednictwem tunelu proxychains wykonuje się atak DCSync, który udaje legalny kontroler domeny replikujący bazę danych Active Directory:

Atak DCSync wykorzystuje procedury Directory Replication Service (MS-DRSR). Poniższa sygnatura Suricata wykrywa ruch replikacji RPC z adresów IP niebędących kontrolerami domeny:

W dzienniku zdarzeń Windows Security atak DCSync generuje zdarzenie Event ID 4662 ze specyficznym identyfikatorem GUID prawa replikacji DS-Replication-Get-Changes-All:

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

1. Metodyka prowadzenia operacji Purple Teaming: współpraca zespołów ofensywnych i defensywnych w oparciu o macierz MITRE ATT&CK.
2. Analiza łańcucha ataku (Cyber Kill Chain): od eksploatacji aplikacji w DMZ, przez kradzież poświadczeń z pamięci, aż po ruch boczny w sieci.
3. Inżynieria reguł detekcji: tworzenie precyzyjnych reguł korelacyjnych w systemie SIEM i EDR o minimalnym współczynniku fałszywych alarmów.
4. Weryfikacja mechanizmów obronnych systemu Windows: blokady Credential Guard, ochrona LSA Protection oraz ograniczenia PowerShell CLM.
5. Ograniczenie ruchu bocznego w sieci korporacyjnej za pomocą mikrosegmentacji i wdrożenia protokołu warstwowego zarządzania tożsamością.
6. Opracowanie kompleksowego raportu z lukami detekcyjnymi (Coverage Gaps) i harmonogramem wdrożenia zaleceń utwardzających infrastrukturę.

Przykładowe wnioski (wzór do sprawozdania): Przeprowadzone ćwiczenie Purple Teaming pozwoliło na realną ocenę skuteczności warstw detekcji i reagowania w krytycznej infrastrukturze operatora telekomunikacyjnego. Zespół czerwony zademonstrował pełny łańcuch ataku: od kompromitacji zewnętrznego serwera WWW, poprzez zrzut poświadczeń z procesu LSASS, aż po przejęcie kontroli nad kontrolerem domeny techniką Pass-the-Hash. Równoległa praca analityków błękitnych ujawniła istotne luki w telemetrii sieciowej oraz brak korelacji zdarzeń bocznego przemieszczania się intruza w systemie SIEM. Wdrożenie zabezpieczenia LSA Protection oraz aktywacja Credential Guard w środowisku domenowym natychmiast zablokowały możliwość nieautoryzowanego odczytu pamięci poświadczeń przez narzędzia ofensywne. Opracowany zestaw czternastu nowych reguł detekcyjnych powiązanych z taksonomią MITRE ATT&CK podniósł gotowość operacyjną centrum operacji bezpieczeństwa do najwyższego poziomu dojrzałości.