W

dzisiejszych czasach bezpieczeństwo aplikacji webowych jest jednym z najważniejszych elementów bezpieczeństwa Internetu, w tym serwerów udostępniających usługi w sieci. Włamania na serwery HTTP niosą jednak za sobą wiele większe ryzyko niż podmiana zawartości strony. Cyberprzestępcy mogą uzyskać dostęp nie tylko do poświadczeń logowania użytkowników danej witryny, ale również plików serwera, co niesie za sobą o wiele szersze konsekwencje.

Książka o tematyce DFIR (Digital Forensics and Incident Response) z jednej strony pokazuje tradycyjne podejście informatyki śledczej, a z drugiej reagowanie na incydenty (Live Fornesics). Tematem przewodnim jest analiza powłamaniowa aplikacji webowej w środowisku Linux. Szczegółowo ukazuje techniczne podejście w tym analizę logów serwera Apache2 i systemu plików Linux Debian oraz zwraca uwagę na możliwości anti-forensics. Z książki czytelnicy dowiedzą się jak przeanalizować incydent związany z włamaniem na stronę w tym jakie operacje przeprowadzał atakujący dzięki analizie osi czasu czy pamięci procesu backdoora. Poruszone zostały też tematy pokrewne takie jak pisanie jednolinijkowych skryptów w powłoce bash czy wykorzystywanie narzędzi anti-forensics do analizy.

Pozycja, na którą zdecydowanie warto było czekać (jej publikacja nieco przedłużyła się ze względu na skład). Przede wszystkim jest to lektura “dwustronna”. Z jednej strony może być przeznaczona dla specjalistów związanych z bezpieczeństwem informatycznym, którzy chcą poszerzyć swoją wiedzę oraz warsztat odnośnie informatyki śledczej i reagowania na incydenty. Z drugiej – adresatem publikacji mogą być osoby zajmujące się autoryzowanymi atakami, którym zależy na zostawieniu jak najmniejszej ilości śladów swojej aktywności. Znajdziemy tutaj bardzo dużo ilości praktycznej wiedzy, która jest poparta wieloletnim doświadczeniem samego autora. Nie należy jednak nastawiać się na prowadzenie czytelnika za rękę schodami zaczynających się od podstawowych stopni. O tych można doczytać w dokumentacji omawianych narzędzi oraz w innych publikacjach odnoszących się do poruszanych technik i zagadnień. Jak zauważył sam autor ich rozwinięte opisy nic nowego by nie wniosły do tematu. Dlatego, jeśli nie czujemy się swobodnie w danym temacie zamiast tracić nerwy na brak wytłumaczenia lub opisu podstaw – warto zaparkować dalszą lekturę i na początku uzupełnić swoją wiedzę.

Lekturę zaczynamy od różnych technik zabezpieczania danych, które pozwolą nam na zachowanie większej lub mniejszej integralności danych do dalszej analizy. Po przejściu przez podstawowe informacje o systemie Linux rozpoczynamy przyspieszony kurs pisania jednolinijkowych skryptów (bash, sed, awk), które pomogą nam w analizie danych. Pierwsza część książki skupia się na analizie włamania przez aplikację webową. Wprowadzeniem do tej części jest przedstawienie serwera Apache wraz z jego formatem logów oraz metodami HTTP, które najczęściej są wykorzystywane od strony klienta. W dalszej części odnoszącej się do najczęściej występujących ataków (SQLi, RCE, LFI, RFI, XSS, CSRF, SSRF, Shellshock oraz DoS) przedstawione zostały realne próby ich przeprowadzenia za pomocą różnego rodzaju skanerów oraz narzędzi pośredniczących w ruchu HTTP. Program tej części książki przewidział również edukację pozwalającą na wykorzystaniu pełnego potencjału, jaki drzemie w analizie logów, a nawet ich odzyskiwaniu po celowym usunięciu. Mając świadomość, że ataki czasami na samych próbach się nie kończą, twórca przygotował dla nas bardzo ciekawą lekturę odnośnie “Studium przypadków”. Przed wydaniem tej publikacji dla wszystkich zainteresowanych osób został udostępniony projekt typu HackMe whitehat.eu.org, na którym znajdowały się różne podatne aplikacje. To właśnie przykłady z ich pomyślnego i niereżyserowanego forsowania znalazły się w opisanych przemyśleniach autora.

Druga część książki jest najbliższa mojemu sercu, czyli systemowi. Podejmuje ona tematykę powłamaniowej analizy systemu Linux, którą zaczynamy od wykonania lokalnego lub zdalnego obrazu dysku. Praca z nim rozpoczyna się od ukazania różnic w systemie plików oraz weryfikacji, czy wszystkie pakiety oprogramowania pochodzą z wiarygodnego źródła. Kolejnym krokiem jest sprawdzenie jądra systemu. Zostało ono podzielone na weryfikację modułów oraz pliku initrd w poszukiwaniu złośliwego oprogramowania. Podrozdział traktujący o logach systemowych został przedstawiony za pomocą systemu splunk, który potrafi znacznie przyśpieszyć ich przeglądanie za pomocą kwerend. Przydaje się też do sporządzania z nich raportów. Trochę szkoda, że nie został przedstawiony analogiczny przykład na podstawie stosu ELK, ale przynajmniej zostało o nim wspomniane. Pracę na obrazie dysku w dalszych podrozdziałach przecinają się z tematami odnoszącymi się do kont użytkowników, programów typu (s|g)uid, ukrywaniu plików i katalogów. Analogicznie, jak w przypadku aplikacji webowych – spotkamy się także z możliwością odzyskania skasowanych plików z dysku. Kropką nad i tej części jest łamanie pliku known_hosts (dla dystrybucji korzystających z włączonej opcji SSH – HashKnownHosts) za pomocą John The Ripper w wersji Jumbo.

Przeciwieństwem analizy obrazu jest praca na działającym systemie (ang. live forensics). Opis tego typu czynności pokazuje nam, jak zabezpieczyć najbardziej ulotne informacje systemu, do których zaliczyć można połączenia sieciowe, działające procesy oraz zawartość pamięci RAM. W tej części odkrywane są przed nami zagadnienia związane z zawartością wirtualnego systemu plików /proc; podstawami użycia poleceń lsof i netstat (w celu identyfikacji otwartych plików i połączeń); śledzeniem ładowania bibliotek systemowych i wykrywaniem ukrytych procesów, a także praktycznymi przykładami stosowania sysdig . Na tym etapie dowiemy się także, jak szybko i sprawnie za pomocą menedżera pakietów znaleźć różnice dokonane w plikach paczek od momentu ich pierwszej instalacji. Zostaniemy wprowadzeni również do wcześniej wspomnianego procesu zrzutu pamięci w celu dalszej analizy przy pomocy Volatility Framework. Jako, że autor publikacji jest członkiem grupy MalwareMustDie przedstawiony “podręcznik” informatyki śledczej kończy się bardzo fajnym przykładem analizy działania złośliwego oprogramowania służącego do tworzenia botnetu oraz przykładami tworzenia reguł Yara.

Uwagi? Oczywiście, jeśli mogę się trochę przyczepić to kilka uwag odnośnie tego wydawnictwa się znajdzie. Wspomnianych koncentratorów (ang. hub`ów) (rozdz. “Zabezpieczanie danych”) już raczej się nie stosuje do obsługi sieci (ze względu na wydajność i bezpieczeństwo). Prawdopodobnie autorowi chodziło o przełączniki (ang. switch`e), a w kontekście podsłuchania transmisji o funkcję port mirroringu, która pozwala na zdefiniowanie portu, na który będą kopiowane wszystkie pakiety “widziane” na zadanym, monitorowanym porcie. Funkcja ta często używana jest do podłączania systemów analizy ruch sieciowego takich jak systemy detekcji włamań IDS/IPS. Przy zaplanowanych zadaniach (rozdz. “Podstawowe informacje o systemie Linux”) zabrakło wspomnienia o poleceniu at, które z powodzeniem można zmusić do wykonywania cyklicznych zadań. W poleceniach uruchamianych przy starcie systemu pominięty został systemd (ls -laR /etc/systemd) będący już standardem w Debianie; skomplikowane polecenie podające przybliżoną datę instalacji systemu (debugfs -R 'stat /' `mount | grep 'on / ' | awk '{print $1}'` | grep crtime) można zastąpić znacznie prostszym (tune2fs -l /dev/sda1 | grep created); użytkownicy z uprawnieniami sudo mogą również posiadać swoje wpisy w katalogu /etc/sudoers.d, a polecenie: egrep -v "^#|^$" /etc/sudoers pominie ten wpis, ponieważ zaczyna się on właśnie od znaku komentarza: #includedir /etc/sudoers.d. Warto również, już odciąć się od przeszłości i nie promować używania md5sum mimo, że służy tylko do generowania sum kontrolnych (rozdz. “Wykonywanie kopii dysku”). Ortodoksyjni fajni od razu podniosą alarm, że Linux nie jest systemem uniksowym, a uniksopodobnym (rozdz. “Najczęściej występujące ataki”). Z kolei bardzo dobrym pomysłem, z którym spotkałem się pierwszy raz podczas lektury jest sporządzenie dynamicznych przypisów w postaci dedykowanych linków. Z jednej strony pełnią one funkcję skracaczy adresów URL, a z drugiej pozwolą autorowi na utrzymywanie ich aktualności.

Na zakończenie dla zachęcenia przyszłych czytelników, poniżej znajduje się fragment z rozdziału “Praca z obrazem dysku” udowadniający dlaczego nie możemy bezgranicznie ufać czasom plików występującym w systemie (wyniki poleceń zostały podmienione na własne przykłady):

Na początku tworzymy plik, na którym przeprowadzimy testy:

# echo 1 > /tmp/test
# stat /tmp/test
  File: '/tmp/test'
  Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
Device: 801h/2049d	Inode: 55134       Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2017-08-17 22:37:39.146566158 +0200
Modify: 2017-08-17 22:37:39.146566158 +0200
Change: 2017-08-17 22:37:39.146566158 +0200
 Birth: -

W kolejnym kroku sprawdzamy, na jakim systemie plików leży plik i wykorzystujemy tę informację w parametrze programu debugfs:

# df /tmp/test | tail -1 | awk '{print $1}'
/dev/sda1
# debugfs -w -R 'set_inode_field /tmp/test ctime 20160101010101' /dev/sda1
debugfs 1.42.13 (17-May-2015)

Na koniec należy opróżnić pamięć podręczną dla inode:

# echo 2 > /proc/sys/vm/drop_caches
# stat /tmp/test
  File: '/tmp/test'
  Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
Device: 801h/2049d	Inode: 55134       Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2017-08-17 22:37:39.146566158 +0200
Modify: 2017-08-17 22:37:39.146566158 +0200
Change: 2016-01-01 02:01:01.146566158 +0100
 Birth: -

Jak widać, czas ctime uległ zmianie. Aby zmodyfikować wszystkie czasy MAC, musimy na początku dodatkowo skorzystać z programu touch:

# touch -a -m -t 20160101010101 /tmp/test
# debugfs -w -R 'set_inode_field /tmp/test ctime 20160101010101' /dev/sda1
debugfs 1.42.13 (17-May-2015)
# echo 2 > /proc/sys/vm/drop_caches
# stat /tmp/test
  File: '/tmp/test'
  Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
Device: 801h/2049d	Inode: 55134       Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2016-01-01 01:01:00.000000000 +0100
Modify: 2016-01-01 01:01:00.000000000 +0100
Change: 2016-01-01 02:01:01.865576970 +0100
 Birth: -
# date
Thu Aug 17 23:00:08 CEST 2017

Warto również pamiętać, że w systemie plików ext4 mamy jeszcze crtime, oznaczający czas utworzenia:

# debugfs -R 'stat /tmp/test' /dev/sda1 | grep time
debugfs 1.42.13 (17-May-2015)
 ctime: 0x5685cfcd:ce5ea028 -- Fri Jan  1 02:01:01 2016
 atime: 0x5685c1bc:00000000 -- Fri Jan  1 01:01:00 2016
 mtime: 0x5685c1bc:00000000 -- Fri Jan  1 01:01:00 2016
crtime: 0x5995fe93:22f1b038 -- Thu Aug 17 22:37:39 2017
# debugfs -w -R 'set_inode_field /tmp/test crtime 1451610060' /dev/sda1
# echo 2 > /proc/sys/vm/drop_caches
# debugfs -R 'stat /tmp/test' /dev/sda1 | grep time
debugfs 1.42.13 (17-May-2015)
 ctime: 0x5685cfcd:ce5ea028 -- Fri Jan  1 02:01:01 2016
 atime: 0x5685c1bc:00000000 -- Fri Jan  1 01:01:00 2016
 mtime: 0x5685c1bc:00000000 -- Fri Jan  1 01:01:00 2016
crtime: 0x5685cfcc:22f1b038 -- Fri Jan  1 02:01:00 2016

który, jak widać, też można zmienić. Ale to nie wszystko, ponieważ występuje tutaj również dtime, który zapisuje czas usunięcia pliku…

Reasumując – jak najbardziej podzielam zdanie dr hab. inż. Jerzego Kosińskiego, że książka Adama Ziaji jest warta polecenia. Jedna z bardziej praktycznych publikacji polskiego autorstwa, z jakimi ostatnio miałem przyjemność się zaznajomić. W dodatku po zastanowieniu – myślę, że nie jest to tylko lektura dla osób zainteresowanych badaniami kryminalistycznymi systemu Linux. Oprócz (nie)bezpieczników bardzo wiele administratorów tego systemu znajdzie tutaj dla siebie garść przydatnych informacji. Szczególnie w kontekście umiejętności reagowania na różnego rodzaju incydenty i późniejsze prowadzenie dochodzenia z zabezpieczonymi dowodami.

Więcej informacji: Praktyczna analiza powłamaniowa: Aplikacja webowa w środowisku Linux