Zrzut pamięci i analiza jądra w systemach Windows i Unix

Informatec Digital » Zasoby » Zrzut pamięci i analiza jądra w systemach Windows i Unix

Gdy system operacyjny panikuje lub ulega awarii, jedynym sposobem na zrozumienie, co się stało, jest zrzut pamięci jądra i jego późniejsza analiza . Zrzuty te rejestrują stan wewnętrzny systemu w momencie awarii i są niezbędne do debugowania złożonych błędów, badania incydentów bezpieczeństwa lub przeprowadzania analiz kryminalistycznych.

Choć może to brzmieć bardzo „niskopoziomowo”, analiza zrzutów pamięci nie jest zarezerwowana wyłącznie dla programistów jądra. Administratorzy systemów, inżynierowie wsparcia, a nawet audytorzy bezpieczeństwa mogą z niej skorzystać, jeśli znają odpowiednie narzędzia, różne typy zrzutów i podstawowe techniki interpretacji . Przeprowadzimy Cię przez to wszystko w systemach Windows, Unix/Linux i BSD, używając narzędzi takich jak WinDbg, Crash, kgdb i LiME.

Czym jest zrzut pamięci jądra i dlaczego warto się nim zająć?

Zrzut pamięci jądra (często nazywany zrzutem awaryjnym jądra lub po prostu zrzutem awaryjnym ) to plik zawierający kopię, pełną lub częściową, pamięci w momencie, gdy system doznaje krytycznej awarii, takiej jak panika jądra w systemach Unix/Linux lub niebieski ekran śmierci (BSOD) w systemie Windows.

W praktyce zrzut tego typu zachowuje wewnętrzne struktury jądra, stosy wywołań, kontekst procesu i załadowane sterowniki . Dzięki temu, po awarii można przeprowadzić analizę post mortem, która jest bardzo podobna do debugowania działającego systemu, ale bez presji związanej z koniecznością dotykania maszyny produkcyjnej w trakcie jej awarii.

Powody, dla których zagłębiamy się w zrzuty jądra, są różne: od debugowania pozornie losowych błędów i sporadycznych awarii , po sprawdzenie, czy system został złośliwie zmanipulowany lub czy awaria mogła pozostawić ślady poufnych informacji na dysku.

Oprócz pełnych zrzutów pamięci istnieje możliwość wykonywania zrzutów pojedynczych procesów (klasyczne zrzuty pamięci ), które są bardzo przydatne, gdy chcemy ograniczyć problem do konkretnej aplikacji lub sprawdzić wpływ na poufność usługi, takiej jak klient poczty elektronicznej lub komunikatora.

Rodzaje zrzutów pamięci w systemie Windows i ich przydatność

W systemach Windows, sam system operacyjny może generować różne typy zrzutów w przypadku wystąpienia błędu STOP. Każdy typ charakteryzuje się innym poziomem szczegółowości, dlatego kluczowe jest, aby wiedzieć, jakiego typu zrzut jest potrzebny w zależności od problemu i ograniczeń miejsca na dysku.

Jednym z najczęściej spotykanych formatów w środowiskach użytkowników i wielu serwerach jest mały zrzut pamięci (minidump)Jest to ten, który zajmuje najmniej miejsca i zwykle znajduje się w %SystemRoot%\Minidump, z plikami w stylu MiniMMDDYY-01.dmp.

Ten mini-zrzut zawiera bardzo szczegółowe, ale ważne informacje: kod błędu STOP i jego parametry , listę sterowników załadowanych w momencie awarii, kontekst procesora, który się zatrzymał (PRCB), kontekst procesu i wątku (struktury EPROCESS i ETHREAD) oraz stos wywołań trybu jądra tego wątku.

Dzięki tym podstawowym strukturom, nawet przy użyciu minizrzutu, często można zidentyfikować sterownik lub moduł powodujący awarie, choć nie zawsze da się prześledzić cały proces, jeśli problem ma swoje źródło daleko od wątku, który był uruchomiony w momencie awarii, a dostępne informacje kontekstowe są ograniczone.

System Windows może również generować zrzuty pamięci jądra oraz znacznie większe zrzuty pełne, zawierające fragmenty lub całość pamięci fizycznej. Są one szczególnie przydatne do analizy niskiego poziomu, dochodzeń kryminalistycznych i zaawansowanego debugowania sterowników lub samego systemu.

Konfigurowanie i otwieranie zrzutów pamięci w systemie Windows za pomocą WinDbg i KD

Aby skorzystać ze zrzutów systemowych w systemie Windows, pierwszym krokiem jest prawidłowa konfiguracja opcji uruchamiania i odzyskiwania . W Panelu sterowania, w zaawansowanych właściwościach systemu, można wybrać typ zrzutu, który ma zostać wygenerowany w przypadku awarii, na przykład „Mały zrzut pamięci (256 KB)” oraz ścieżkę, w której zostanie on zapisany.

System wymaga również pliku stronicowania na woluminie rozruchowym o rozmiarze co najmniej kilku megabajtów do zapisu zrzutu. W nowoczesnych wersjach systemu Windows każda awaria tworzy nowy plik, a historia jest przechowywana w skonfigurowanym folderze, co umożliwia łatwy przegląd wcześniejszych incydentów.

Po wygenerowaniu istnieje kilka sposobów weryfikacji poprawności zrzutów. Klasycznym narzędziem jest Dumpchk.exe , który pozwala sprawdzić podstawową integralność pliku i wyświetlić informacje podsumowujące. Do bardziej zaawansowanej analizy wykorzystywane są narzędzia debugowania systemu Windows , w tym WinDbg (interfejs graficzny) i KD (wersja wiersza poleceń).

Po zainstalowaniu pakietu debugowania ze strony internetowej firmy Microsoft, narzędzia zazwyczaj znajdują się w folderze takim jak C:\Program Files\Debugging Tools for Windows . Stamtąd można otworzyć wiersz poleceń i załadować plik zrzutu za pomocą WinDbg lub KD, określając plik parametrem -z .

windbg -y <RutaSimbolos> -i <RutaBinarios> -z <RutaDump>

Ścieżka symbolu może wskazywać na serwer symboli z lokalnym buforowaniem , na przykład:

srv*C:\Symbols*https://msdl.microsoft.com/download/symbols

Chociaż ścieżka binarna zwykle wygląda tak: C:\Windows\I386 lub folder, do którego skopiowaliśmy pliki wykonywalne systemu odpowiadające wersji, która wygenerowała zrzut. Jest to ważne, ponieważ Minizrzuty nie zawierają wszystkich plików binarnych, tylko odniesienia do nich, więc debuger musi być w stanie je znaleźć.

Podstawowa analiza zrzutu awaryjnego jądra w systemie Windows

Po załadowaniu zrzutu za pomocą WinDbg lub KD, analiza zrzutu awaryjnego jądra jest bardzo podobna do sesji debugowania post mortem. Pierwszym poleceniem, które prawie każdy uruchamia, jest `!analyze` , które uruchamia automatyczną analizę i generuje raport wstępny.

Polecenie !analyze -show pokazuje kod sprawdzający błędy i jego parametryPodczas !analyze -v Daje znacznie bardziej szczegółowy wynik: podejrzany moduł, stos wywołań, informacje kontekstowe, a w wielu przypadkach także sugestie dotyczące możliwych przyczyn lub kroków diagnostycznych.

Aby uzupełnić tę analizę, polecenie .bugcheck ponownie drukuje kod błędu i powiązane parametry. Można je porównać z odnośnikiem do kodu bugcheck firmy Microsoft , aby poznać dokładne znaczenie każdej wartości i typowe przyczyny.

Polecenie lm N T (lista modułów) pozwala zobaczyć Lista załadowanych modułów ze ścieżką, adresami i statusemPomaga to potwierdzić, czy sterownik zidentyfikowany przez automatyczną analizę rzeczywiście znajduje się w pamięci i w jakiej jest wersji. Ta lista jest szczególnie przydatna, gdy podejrzewamy, że sterowniki innych firm lub komponenty zabezpieczeń wchodzą w interakcję z jądrem.

W razie potrzeby możemy uprościć ładowanie zrzutów, tworząc plik wsadowy , który pobiera ścieżkę do zrzutu i uruchamia KD lub WinDbg z odpowiednimi parametrami. W ten sposób wystarczy napisać krótkie polecenie zawierające tylko lokalizację pliku, a skrypt zajmie się resztą.

Korzystanie z WinDbg do głębokich zrzutów jądra

W przypadku zrzutów pamięci w trybie jądra WinDbg oferuje również możliwość pracy z wieloma plikami i sesjami. Zrzuty można otwierać z wiersza poleceń za pomocą opcji -z lub z interfejsu graficznego, korzystając z menu Plik > Otwórz zrzut pamięci lub skrótu klawiaturowego Ctrl+D.

Jeśli WinDbg jest już otwarty w trybie pasywnym, wystarczy wybrać plik w oknie dialogowym „Otwórz zrzut awaryjny”, określając ścieżkę dostępu lub przeglądając dysk. Po załadowaniu można w niektórych scenariuszach uruchomić sesję poleceniem „g” (Go) lub bezpośrednio uruchomić początkowe polecenia analizy.

Oprócz klasycznego !analyzeWarto zapoznać się z sekcja odniesienia do poleceń debugeraOpisuje wszystkie dostępne polecenia do odczytu struktur wewnętrznych, badania pamięci, interpretacji stosów i wielu innych. Wiele z tych technik ma zastosowanie zarówno w sesjach na żywo, jak i w zrzutach offline.

WinDbg pozwala również na pracę z wiele równoległych zrzutówMożemy dodać wiele parametrów -z w wierszu poleceń, po każdym z których będzie następować inna nazwa pliku, lub dodać nowe cele za pomocą polecenia .opendumpDebugowanie wielu miejsc docelowych jest przydatne do porównywania powtarzających się awarii lub łańcuchów incydentów.

W niektórych środowiskach zrzuty pamięci są pakowane w pliki CAB, aby zaoszczędzić miejsce lub ułatwić transmisję. WinDbg może bezpośrednio otwierać .cab z zrzutem wewnątrz, zarówno używając -z, jak i z .opendumpchociaż będzie czytał Wyodrębniony zostanie tylko jeden z wyrzuconych plików, a pozostałe nie zostaną wyodrębnione. które mogłyby znaleźć się w tym samym pakiecie.

Zrzuty awaryjne w systemach Unix i Linux: narzędzia, użyteczność i wymagania

W systemach Unix i GNU/Linux filozofia jest podobna, ale ekosystem narzędzi znacznie się różni. Większość jąder uniksopodobnych oferuje możliwość zapisania kopii pamięci w przypadku wystąpienia zdarzenia katastroficznego , co jest znane jako zrzut pamięci (core dump) lub zrzut awaryjny jądra (kernel crash dump).

Chociaż ich głównym zastosowaniem pozostaje rozwój jądra i sterowników, te zrzuty danych mają wyraźny aspekt bezpieczeństwa. Awaria może być spowodowana błędami programistycznymi, ale także nieudanymi złośliwymi działaniami, próbami manipulacji komponentami systemu lub nieudolnym wykorzystaniem warunków wyścigu.

W dobrze skonfigurowanym systemie Unix codzienne awarie zdarzają się rzadko, ale gdy już wystąpią, wskazane jest posiadanie infrastruktury zrzutu, takiej jak Kdump, LKCD lub inne rozwiązania umożliwiające przechwytywanie pamięci systemowej. Kluczowe jest jednak rozważenie zarówno wartości diagnostycznej zrzutu, jak i ryzyka, że ​​zawiera on bardzo wrażliwe dane.

Jednym z najbardziej wszechstronnych i powszechnie używanych narzędzi do tego typu analizy w systemie Linux jest crash , pierwotnie opracowany przez firmę Red Hat. Narzędzie to stało się praktycznie standardem w badaniu zrzutów jądra, a także w analizie działających systemów.

Awaria może działać na szkodę pamięci operacyjnej systemu poprzez /dev/mem lub w Red Hat i dystrybucjach pochodnych, używając konkretnego urządzenia /dev/crashMimo to powszechną praktyką jest dostarczanie narzędziu pliku zrzutu wygenerowanego przez mechanizmy takie jak Kdump, plik makedump, Zrzut dysku lub zrzuty specyficzne dla architektury, takie jak s390/s390x lub xendump w środowiskach wirtualnych.

Rola awarii i znaczenie vmlinux w systemie Linux

Narzędzie do usuwania awarii zostało stworzone częściowo w celu przezwyciężenia ograniczeń związanych z używaniem gdb bezpośrednio na /proc/kcoreMiędzy innymi dostęp do tego pseudo-obrazu pamięci może być ograniczony, a ponadto niektóre opcje kompilacji jądra utrudniają właściwą interpretację wewnętrznych struktur, jeśli dysponujemy wyłącznie skompresowanym plikiem wykonywalnym.

Aby crash działał poprawnie, potrzebne są dwa kluczowe elementy: skompilowany plik vmlinux z symbolami debugowania (zazwyczaj z flagami takimi jak -g) oraz sam zrzut jądra. Ta kombinacja pozwala narzędziu mapować adresy pamięci na funkcje, struktury i wiersze kodu.

Ważne jest, aby rozróżnić vmlinux i vmlinuzW większości systemów widoczny jest tylko vmlinux, czyli skompresowana, bootowalna wersja jądra. Crash wymaga symbolicznie zdekompresowanego vmlinux; bez niego, podczas próby załadowania zrzutu lub /dev/mem Napotkamy błędy typu nie można znaleźć uruchomionego jądra — proszę wprowadzić argument listy nazw.

Chociaż możliwe jest ręczne wyodrębnienie pakietu vmlinuz, proces ten nie zawsze jest prosty i w praktyce często znacznie wygodniej jest przekompilować jądro, aby uzyskać jednocześnie zarówno vmlinux, jak i vmlinuz. W środowiskach wymagających poważnej administracji, dobrą praktyką jest utrzymywanie osobnego pakietu vmlinuz dla każdej wdrożonej wersji jądra, specjalnie na takie sytuacje.

Po spełnieniu wymagań, uruchomienie crasha na pliku dump jest stosunkowo proste: wystarczy wskazać odpowiedni plik vmlinux i dump, a narzędzie otworzy interaktywną sesję, z której można eksplorować struktury jądra, wyświetlać listę procesów, przeglądać stosy wywołań i wyodrębniać dane kryminalistyczne . Osoby zainteresowane szczegółami mogą zapoznać się ze specjalistyczną dokumentacją, taką jak powszechnie znany dokument techniczny dotyczący crashy.

Ograniczenia /dev/mem i pierwsze podejścia w systemie Linux

Zanim zaczęto korzystać z konkretnych narzędzi, wielu administratorów próbowało wykonać zrzut pamięci. odczyt bezpośrednio z urządzenia /dev/memTo podejście wydawało się proste: użyj narzędzia takiego jak zrzut pamięci (który zrzuca to urządzenie na STDOUT) lub wyciąga z dd if=/dev/mem of=volcado.mem.

Jednakże współczesne jądra oferują opcje kompilacji, takie jak: CONFIG_STRICT_DEVMEMktóre poważnie ograniczają dostęp z przestrzeni użytkownika do /dev/memTypowym wynikiem jest to, że odczyt zostaje przerwany po małym bloku (np. 1 MB) lub, w najgorszym przypadku, błąd w tej interakcji może zakończyć się panika jądra natychmiastowe ponowne uruchomienie maszyny.

Taka ochrona jest całkowicie uzasadniona z punktu widzenia bezpieczeństwa, ale zmusza nas do poszukiwania innych sposobów na uzyskanie niezawodnego i kompletnego zrzutu danych, bez polegania wyłącznie na standardowych urządzeniach, które nie są już tak dostępne jak kiedyś.

Dlatego też obecnie panuje tendencja do polegania na konkretnych modułach lub zintegrowanej infrastrukturze zrzutu awaryjnego, zamiast po prostu próbować „zgarniać pamięć” za pomocą narzędzi przestrzeni użytkownika, które nie są zaprojektowane do współistnienia z nowoczesnymi zasadami ochrony jądra.

LiME Forensics: Ekstrakcja pamięci w systemach Linux i Android

Bardzo potężną alternatywą w świecie informatyki śledczej jest LiME (Linux Memory Extractor) , moduł jądra zaprojektowany specjalnie do kontrolowanego przechwytywania pamięci ulotnej bez ograniczeń, które dotyczą /dev/mem. LiME działa w przestrzeni jądra, dzięki czemu może uzyskiwać dostęp do pamięci RAM znacznie bardziej bezpośrednio.

LiME jest dystrybuowany wraz z kodem źródłowym i kompiluje się w oparciu o nagłówki jądra w użyciuProces kompilacji generuje moduł .ko specyficzne dla wersji jądra, do której zostanie załadowany. Po skompilowaniu możemy go zweryfikować za pomocą narzędzi takich jak file aby mieć pewność, że moduł ELF odpowiadający naszej architekturze został poprawnie wygenerowany.

Aby użyć LiME, wystarczy załadować moduł insmod z roota i przekazać mu odpowiednie opcje, na przykład poprzez określenie miejsce zrzutu sieciowego przy użyciu protokołu TCP i formatu surowego:

insmod lime-3.x.y.ko "path=tcp:4444 format=raw"

Równolegle na komputerze, który będzie odbierał zrzut, nasłuchujemy na skonfigurowanym porcie za pomocą narzędzia takiego jak ncprzekierowywanie wyjścia do pliku:

nc <IP_origen> 4444 > volcado.mem

Po kilku minutach, w zależności od ilości pamięci RAM i wydajności sieci, otrzymamy plik o rozmiarze odpowiadającym rozmiarowi pamięci fizycznej systemu źródłowego. Jest to kompletny zrzut pamięci RAM, który możemy przeanalizować za pomocą narzędzi kryminalistycznych, a nawet za pomocą ciągów znaków lub innych narzędzi, co stanowi pierwszy krok w celu zlokalizowania interesujących ciągów znaków.

Zrzuty procesów i ryzyko ujawnienia danych

Pełny zrzut jądra jest niezwykle pouczający, ale może być też przesadny, gdy interesuje nas tylko konkretny proces. W takim przypadku bardzo sensowne jest skorzystanie z... indywidualne zrzuty procesów korzystając z narzędzi takich jak gcore w systemach Unix/Linux.

Tego rodzaju zrzuty danych dla każdego procesu są znacznie mniejsze i łatwiejsze w zarządzaniu, dzięki czemu możesz skupić analizę na konkretnych aplikacjach, takich jak klient wiadomości (np. Skype) lub klient poczty e-mail (np. Thunderbird), w których stosunkowo łatwo jest znaleźć hasła w postaci zwykłego tekstu, tokeny sesji lub dane kontaktowe, badając ciągi pamięci.

Z perspektywy programistycznej, te zrzuty pamięci pomagają zlokalizować błędy programistyczne, wycieki pamięci lub niespójne stany usługi. Jednak z perspektywy bezpieczeństwa problem pojawia się, gdy te zrzuty są generowane rutynowo i przechowywane w lokalizacjach dostępnych dla innych użytkowników , zarówno w samym systemie, jak i we współdzielonych zasobach sieciowych.

Jeśli użytkownik zaplanuje na przykład zadanie cron Okresowo przechwytując zrzuty wrażliwych procesów i pozostawiając je w globalnie czytelnym katalogu, atakujący otwiera ogromne możliwości ujawnienia krytycznych informacji. W wielu scenariuszach audytu analiza tych plików pozwala atakującemu na odzyskanie danych. dane uwierzytelniające, listy kontaktów, historie komunikacji i inne prywatne dane przy stosunkowo niewielkim wysiłku.

Dlatego też podczas każdego poważnego audytu systemu Unix wskazane jest poświęcenie kilku minut na sprawdzenie, czy są generowane zrzuty (pełne lub częściowe), gdzie są przechowywane, jakie mają uprawnienia i czy istnieje jakiś automatyczny proces pozostawiający kopie w pamięci w zasięgu nieautoryzowanych użytkowników.

Analiza post mortem zrzutów w FreeBSD z kgdb

W świecie BSD, a szczególnie w FreeBSD, podejście do analizy post mortem obejmuje Włącz zrzuty awaryjne w systemie i skompiluj jądro z symbolami debugowaniaJest to kontrolowane z katalogu konfiguracji jądra, zwykle w /usr/src/sys/<arq>/conf.

W odpowiednim pliku konfiguracyjnym generowanie symboli można włączyć za pomocą następującego wiersza:

makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols

Po zmianie konfiguracji jądro musi zostać ponownie skompilowane. Niektóre obiekty zostaną wygenerowane ponownie (np. trap.o) ze względu na zmianę plików kompilacji. Celem jest uzyskanie jądra z ten sam kod, który powoduje problemy, ale dodaje niezbędne informacje debugowaniaZaleca się porównanie starych i nowych rozmiarów za pomocą polecenia size aby mieć pewność, że w pliku binarnym nie zaszły żadne nieoczekiwane zmiany.

Po zainstalowaniu jądra z symbolami możemy przeanalizować zrzuty za pomocą kgdb , zgodnie z opisem w oficjalnej dokumentacji. Nie wszystkie symbole mogą być kompletne, a niektóre funkcje mogą pojawiać się bez numerów wierszy lub informacji o argumentach, ale w większości przypadków poziom szczegółowości jest wystarczający, aby zlokalizować problem.

Nie ma absolutnej gwarancji, że analiza rozwiąże wszystkie incydenty, ale w praktyce strategia ta sprawdza się całkiem dobrze w dużym procencie scenariuszy , szczególnie gdy zrzuty pamięci połączy się z dokładnym przeglądem ostatnich zmian w systemie.

Najlepsze praktyki analizowania i dokumentowania błędów jądra

Niezależnie od systemu operacyjnego, analiza zrzutu jądra zwykle kończy się na odwoływaniu się do dokumentacji technicznej, baz wiedzy, specjalistycznych forów lub nawet samego kodu źródłowego jądra w celu zinterpretowania komunikatów, kodów błędów i nieznanych symboli.

W Linuksie bardzo pomocne jest korzystanie z oficjalnego drzewa kodu źródłowego, wbudowanej dokumentacji i zasobów społeczności. Wiele komunikatów o błędach jądra można powiązać z konkretnym plikiem, z którego pochodzą, co pomaga zrozumieć kontekst, w którym pojawia się konkretny błąd BUG() lub WARN().

W systemie Windows dokumentacja firmy Microsoft, jej baza wiedzy (KB) oraz fora techniczne zawierają szczegółowe wyjaśnienia kodów błędów, zalecenia dotyczące rozwiązywania problemów oraz znane wzorce błędów . Połączenie tych informacji z raportami z polecenia !analyze -v umożliwia opracowanie rozsądnego planu działań naprawczych.

Prawdziwa wartość zrzutu awaryjnego ujawnia się, gdy wszystkie te informacje zostaną zestawione z dogłębną znajomością systemu operacyjnego i konkretnego środowiska, w którym wystąpiła awaria . Tylko wtedy można opracować trwałe rozwiązania, a przede wszystkim zapobiec ponownemu wystąpieniu tego samego problemu w przyszłości, z poważniejszymi konsekwencjami.

Analiza zrzutu jądra to w gruncie rzeczy połączenie nauki i kunsztu: wymaga odpowiednich narzędzi, wcześniejszej konfiguracji (symboli, opcji zrzutu, bezpiecznego przechowywania) oraz sporego doświadczenia w odczytywaniu stosów, struktur i kodów błędów. Opanowanie tych technik pozwala nam nie tylko debugować złożone incydenty, ale także znacząco zwiększyć bezpieczeństwo i odporność zarządzanych przez nas systemów.