Hacking for all!

https://chacker.pl/

Ta  część zapewnia ogólny pogląd na urządzenia wbudowane, aby zapewnić słownictwo i ogólne zrozumienie potencjalnych obszarów zainteresowania. Urządzenia wbudowane to urządzenia elektryczne lub elektromechaniczne, które spełniają określone potrzeby lub mają ograniczoną funkcję. Kilka przykładów urządzeń wbudowanych obejmuje systemy bezpieczeństwa, routery/przełączniki sieciowe, kamery, otwieracze drzwi garażowych, inteligentne termostaty, sterowalne żarówki i telefony komórkowe. Ponieważ nasze urządzenia zyskują zdalną łączność dla naszej wygody, zapewniają również atakującemu więcej możliwości wtargnięcia do naszego życia za pośrednictwem naszych sieci. Duża część dyskusji koncentruje się na układach scalonych (IC). Układ scalony to zbiór elementów elektrycznych w małej obudowie, często nazywany układem scalonym. Prostym przykładem jest układ scalony z poczwórną bramką OR o 2 wejściach, w którym cztery obwody OR o 2 wejściach są zaimplementowane wewnątrz jednego układu scalonego. W naszym przypadku układy scalone będą znacznie bardziej złożone i będą zawierać wszystkie elementy obliczeniowe w jednym układzie scalonym. Należy również zauważyć, że ten rozdział zakłada, że ​​znasz multimetr i podstawowe koncepcje obwodów elektrycznych, takie jak napięcie, prąd, rezystancja i uziemienie.

https://chacker.pl/

Tu przedstawiono różnicowanie binarne i różne narzędzia dostępne w celu przyspieszenia analizy. Przyjrzeliśmy się prostemu przykładowi dowodu koncepcji aplikacji, a następnie przyjrzeliśmy się rzeczywistej poprawce, aby zlokalizować zmiany w kodzie, zweryfikować nasze założenia i zweryfikować poprawkę. Jest to nabyta umiejętność, która ściśle wiąże się z doświadczeniem debugowania i czytania rozmontowanego kodu. Im częściej to robisz, tym lepiej będziesz identyfikować zmiany w kodzie i potencjalnie naprawione luki w zabezpieczeniach. Czasami łatwiej jest zacząć od wcześniejszych wersji lub kompilacji systemu Windows, a także od wersji 32-bitowej zamiast wersji 64-bitowej, ponieważ dezasemblacja jest często łatwiejsza do odczytania. Wiele błędów obejmuje dużą liczbę wersji systemu Windows. Nie jest niczym niezwykłym, że Microsoft również przemyca ciche zmiany kodu za pomocą innej poprawki. Czasami różni się to między wersjami systemu Windows, gdzie różnicowanie jednej wersji systemu Windows może dać więcej informacji niż różnicowanie innej wersji.

https://chacker.pl/

Przyjrzyjmy się przykładowi pozyskiwania i wyodrębniania zbiorczej aktualizacji dla systemu Windows 10. Kiedy spojrzymy na poprzednią listę luk CVE z lipca 2021 r., zobaczymy, że CVE-2021-34527 mówi: „Luka umożliwiająca zdalne wykonanie kodu w buforze wydruku systemu Windows”. Jest to luka o nazwie „PrintNightmare”, jak można zobaczyć w ogłoszeniu firmy Microsoft pod adresem https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34527. W okresie od czerwca 2021 r. do sierpnia 2021 r. i później wydano różne poprawki. Na potrzeby tego przewodnika pobierzemy zbiorczą aktualizację z czerwca 2021 r. i lipca 2021 r. dla systemu Windows 10 21H1 x64. Naszym celem jest zlokalizowanie podatnego i załatanego pliku powiązanego z PrintNightmare i uzyskanie wstępnych informacji o tym, jak został on naprawiony. Najpierw musimy przejść do https://www.catalog.update.microsoft.com/Home.aspx i wprowadzić kryteria wyszukiwania 2021-06 21H1 x64 cumulative. Po wykonaniu tej czynności otrzymamy następujące wyniki:

Pobierzemy plik „2021-06 Cumulative Update for Windows 10 Version 21H1 for x64-based Systems (KB5004476)”. Następnie zmienimy kryteria wyszukiwania na 2021-07 21H1 x64 cumulative. Wyniki są wyświetlane dalej.

Pobierzemy plik „2021-07 Cumulative Update for Windows 10 Version 21H1 for x64-based Systems (KB5004237)”. Mamy teraz obie zbiorcze aktualizacje, które powinny zawierać pliki potrzebne do sprawdzenia CVE-2021-34527, ale muszą zostać wyodrębnione. Poprawki można wyodrębnić ręcznie za pomocą narzędzia expand firmy Microsoft, dołączonego do większości wersji systemu Windows. Narzędzie to rozszerza pliki z formatu skompresowanego, takiego jak plik cabinet lub pakiet Microsoft Standalone Update (MSU). Gdy argument -F: jest używany do określenia pliku, obsługiwane są symbole wieloznaczne ze znakiem *. Polecenie wyglądałoby mniej więcej tak expand.exe -F:* <plik do wyodrębnienia> <miejsce docelowe>. Gdy uruchamiasz to polecenie w odniesieniu do pobranej zbiorczej aktualizacji, szybko wyodrębniany jest plik Patch Storage File (PSF) z rozszerzeniem .cab. Aby wyodrębnić zawartość, należy zastosować to samo polecenie expand do tego pliku. Wykonanie tego zajmie trochę czasu (prawdopodobnie ponad 10 minut), ponieważ zazwyczaj są dziesiątki tysięcy folderów i plików. Dla zwięzłości nie będziemy zagłębiać się w powiązaną wewnętrzną strukturę i hierarchię związaną z wnętrzem pliku poprawki, z wyjątkiem tych, które są niezbędne do szybkiego przejścia do różnicowania poprawek. Aby przyspieszyć proces, użyjemy narzędzia PatchExtract Grega Linaresa, które wykorzystuje narzędzie expand. Zaktualizowana wersja Jaime Geigera jest wymieniona w sekcji „Do dalszej lektury” i jest wersją używaną w tym rozdziale. Narzędzie PatchExtract to skrypt programu PowerShell, który zarówno wyodrębnia zawartość pliku poprawki, jak i starannie organizuje pliki w różnych folderach. Aby użyć tego narzędzia, dobrym pomysłem jest utworzenie folderu docelowego, w którym chcesz umieścić wyodrębnione pliki. Na nasze potrzeby nazwiemy jeden folder „2021-06”, a drugi folder „2021-07”. Wypakujemy zawartość aktualizacji z czerwca 2021 r. do folderu „2021-06”, a zawartość aktualizacji z lipca 2021 r. do folderu „2021-07”. Po skopiowaniu pliku zbiorczej aktualizacji .msu z czerwca 2021 r. do folderu „2021-06” uruchamiamy następujące polecenie (wpisane w jednym wierszu) za pomocą sesji PowerShell ISE:

Po wykonaniu tego polecenia, wyodrębnienie plików zajęło około 20 minut. Pojawiło się również kilka komunikatów programu PowerShell o już istniejących nazwach, ale nic nie przeszkodziło w pełnym wyodrębnieniu poprawki. Po zakończeniu pozostały nam różne foldery, w tym JUNK, MSIL, PATCH, WOW64, x64 i x86. Folder JUNK zawiera pliki, którymi nie jesteśmy zainteresowani, takie jak pliki manifestu i pliki katalogu zabezpieczeń. Folder PATCH zawiera większe zagnieżdżone pliki cabinet, które właśnie wyodrębniliśmy. Foldery MSIL, WOW64, x64 i x86 zawierają większość danych platformy i plików poprawek, którymi jesteśmy zainteresowani.

Wewnątrz folderu x64 znajduje się ponad 2900 podfolderów, wszystkie o różnych opisowych nazwach, jak widać tutaj:

W każdym z tych folderów znajdują się zazwyczaj dwa podfoldery, zwane „f” i „r”, które oznaczają odpowiednio forward i reverse. Inna nazwa podfolderu, na którą możesz się natknąć, to „n”, co oznacza null. Te foldery zawierają pliki poprawek delta. Folder „r” zawiera pliki różnicowe odwrotne, folder „f” zawiera pliki różnicowe do przodu, a folder „n” zawiera nowe pliki do dodania. Kiedyś poprawka obejmowała cały plik do zastąpienia, taki jak DLL lub sterownik. Microsoft przeszedł na format delta, w którym plik różnicowy odwrotny przenosi zaktualizowany plik, po zainstalowaniu, z powrotem do wersji Release To Manufacturing (RTM), a plik różnicowy do przodu przenosi plik z RTM do miejsca, w którym musi się znaleźć dla bieżącej aktualizacji.2 Jeśli nowy plik zostanie dodany do systemu w Patch Tuesday, za pośrednictwem folderu null, można go uznać za wersję RTM. Po załataniu tego pliku podczas kolejnej aktualizacji Patch Tuesday można zastosować plik różnicowy do przodu, aby stał się aktualny. Ta aktualizacja będzie również zawierać plik różnicowy odwrotny, który można zastosować, aby przywrócić plik do wersji RTM, tak aby można było zastosować przyszły różnicowy plik do przodu, aby nadal był aktualny. Jak wspomniano, kiedyś poprawki firmy Microsoft obejmowały całe pliki, aby zastąpić te, które są łatane; jednak jeśli przyjrzysz się plikom poprawek w folderach f i r, szybko zauważysz, że rozmiar pliku rzekomych bibliotek DLL lub sterowników jest o wiele za mały, aby stanowić cały plik. Kilka lat temu firma Microsoft stworzyła zestaw interfejsów API delta poprawek. Obecnym interfejsem API jest interfejs API MSDELTA.3 Zawiera on zestaw funkcji do wykonywania działań, takich jak stosowanie delty poprawek. Aime Geiger stworzył skrypt o nazwie „delta_patch.py”, aby wykorzystać interfejs API w celu zastosowania delt odwrotnych i do przodu, których wkrótce użyjemy. Pliki poprawek delta zawierają 4-bajtową sumę kontrolną CRC32 na początku pliku, po której następuje magiczna liczba PA30. Zanim przejdziemy do stosowania poprawek delta, musimy zidentyfikować plik powiązany z poprawką, która nas interesuje. CVE-2021-34527 jest powiązany z luką w zabezpieczeniach „PrintNightmare”. Aby ustalić, które pliki chcemy różnicować, musimy dowiedzieć się nieco więcej o usługach buforowania w systemie Windows. Spójrz na poniższy obraz firmy Microsoft, który pokazuje zarówno lokalne, jak i zdalne komponenty dostawcy drukarek:

Na obrazach możemy zobaczyć kilku kandydatów do różnic, w tym winspool.drv, spoolsv.exe, spools.dll i localspl.dll. Luka związana z PrintNightmare wskazywała na potencjalne zdalne wykonanie kodu (RCE). Na obrazie po prawej stronie możemy zobaczyć wywołanie RPC do spoolsv.exe. W naszej wstępnej analizie ustalono, że spoolsv.exe, winspool.drv i localspl.dll są najciekawszymi celami. Zaczniemy od analizy spoolsv.exe. Naszym następnym krokiem jest zastosowanie poprawek delta dla aktualizacji z czerwca 2021 r. i lipca 2021 r. Musimy zidentyfikować kopię spoolsv.exe z naszego folderu WinSxS systemu Windows 10, zastosować powiązaną odwrotną deltę, a następnie zastosować do przodu deltę dla każdego z dwóch miesięcy. WinSxS to technologia montażu równoległego systemu Windows. Krótko mówiąc, jest to sposób, w jaki system Windows może zarządzać różnymi wersjami bibliotek DLL i innymi typami plików. System Windows potrzebuje sposobu na zastąpienie zaktualizowanych plików, a także sposobu na powrót do starszych wersji, jeśli aktualizacja zostanie odinstalowana. Duża liczba bibliotek DLL i plików systemowych może być skomplikowana w zarządzaniu. Przejrzymy folder WinSxS, aby znaleźć kopię pliku spoolsv.exe i powiązaną z nim odwrotną poprawkę delta, aby przywrócić ją do wersji RTM. Przyjrzyj się następującemu poleceniu programu PowerShell i powiązanym wynikom:

Możemy zobaczyć plik spoolsv.exe z maja 2021 r., a także folder r i folder f, który zawiera pliki poprawki delta. Utworzymy folder spoolsv w naszym folderze C:\grayhat\Chapter 18\, a następnie skopiujemy cały plik spoolsv.exe wraz z folderem r i jego zawartością. Pozwoli nam to zastosować poprawkę odwrotnej delty, a następnie użyć poprawki do przodu delty z aktualizacji z czerwca 2021 r. i lipca 2021 r. do pliku, używając narzędzia delta_patch.py.

Jak widać, poprawki delta w przód i w tył zostały zastosowane pomyślnie. Mamy teraz wersje pliku spoolsv.exe zarówno na czerwiec, jak i lipiec. Użyjemy wtyczki BinDiff dla IDA Pro, aby porównać różnice między dwiema wersjami. Aby to zrobić, będziemy musieli wykonać następujące czynności:

• Sprawić, aby IDA wykonało swoją automatyczną analizę obu plików.
• Załaduj wersję z czerwca do IDA i naciśnij CTRL-6, aby wyświetlić menu BinDiff.

• Wykonaj diff i przeanalizuj wyniki.

W wynikach możemy zobaczyć zmiany w pięciu funkcjach, usunięcie czterech funkcji i dwóch importów oraz dodanie dwóch nowych funkcji w poprawionej wersji spoolsv.exe, jak widać na karcie Secondary Unmatched. Nazwa funkcji YRestrictDriverInstallationToAdministrators brzmi jak oczywista funkcja interesująca. Wykonajmy wizualną różnicę funkcji RpcAddPrinterDriverEx.

Możemy zobaczyć dużą liczbę różnic między wersjami funkcji. Przybliżając obszar w kierunku środka u góry, widzimy następujące:

Po stronie podstawowej (niezałatanej) znajduje się wywołanie RunningAsLUA, które zostało usunięte ze strony wtórnej (załatanej). W wersji załatanej znajduje się nowe wywołanie funkcji YRestrictDriverInstallationToAdministrators. Podczas badania odwołań krzyżowych do tej nowej funkcji widzimy dwa wywołania. Jedno wywołanie pochodzi z RpcAddPrinterDriver, a drugie z RpcAddPrinterDriverEx. Obie te funkcje zostały zidentyfikowane jako mające zmiany. Poniższa ilustracja pokazuje blok kodu w RpcAddPrinterDriverEx, w którym znajduje się wywołanie YIsElevationRequired i YImpersonateClient.

Przyglądając się każdej z tych funkcji, widzimy, że uzyskiwany jest dostęp do unikalnego klucza rejestru, jak pokazano poniżej:

Funkcja YIsElevationRequired sprawdza klucz o nazwie NoWarning-NoElevationOnInstall, a funkcja RestrictDriverInstallationToAdministrators sprawdza klucz o nazwie RestrictDriverInstallationToAdministrators. Wynik z funkcji YIsElevationRequired jest rejestrowany w r14, a wynik z funkcji RestrictDriverInstallationToAdministrators jest rejestrowany w r15. Przyjrzyjmy się pseudokodowi funkcji RpcAddPrinterDriverEx, aby lepiej zrozumieć przepływ. Używamy dekompilatora Hex-Rays, ale możesz również użyć narzędzia Ghidra lub innego.

Linia 4 pokazuje nam, że v6 reprezentuje r14, który będzie zawierał zwrot z YIsElevationRequired w linii 21. Linia 5 pokazuje nam, że v7 reprezentuje r15, który będzie zawierał zwrot z YRestrictDriverInstallationToAdministrators w linii 22. Linia 26 ustawia v10 (esi), jeśli użytkownik jest administratorem. Warunek w linii 45 mówi, że jeśli v6 jest ustawione (wymagane podniesienie), a nie v10 (nie jest administratorem), to my i zmienna a3 z 0x8000, co jest 10000000000000000 w systemie binarnym. To anuluje flagę na 15. pozycji bitu a3 (edi) na 0. Warunek w linii 48 mówi, że jeśli v7 nie jest ustawiona (instalacja nie jest ograniczona do administratorów) lub v10 jest ustawiona (jest administratorem), wywołaj funkcję YAddPrinterDriverEx, przekazując a3 (flagi kontrolowane przez użytkownika) jako jeden z argumentów. Jeśli sobie przypominasz, obraz od Microsoft dla komponentów dostawcy drukarki wysokiego poziomu pokazuje wywołanie RPC do zdalnego procesu spoolsv.exe. Z kolei wykonywanie przechodzi przez localspl.dll przed przejściem do trybu jądra w celu komunikacji z rzeczywistą drukarką. Patrząc na tabelę adresów eksportu (EAT) localspl.dll, możemy zobaczyć funkcję SplAddPrinterDriverEx. Została ona zdekompilowana, jak pokazano tutaj:

Spójrz na wiersze 28–33. Zmienna a4 jest taka sama jak zmienna a3 z poprzedniego pseudokodu zrzutu z RpcAddPrinterDriverEx, zawierająca flagi. Możemy kontrolować tę wartość, która w niezałatanej wersji spoolsv.exe nie ma kontroli powiązanych kluczy rejestru (NoWarningNoElevationOnInstall i RestrictDriverInstallationToAdministrators). Możemy skutecznie ominąć wywołanie ValidateObjectAccess i przejść bezpośrednio do InternalAddPrinterDriverEx. Wiersz 28 ustawia v12 na 0. Wiersz 29 mówi, że jeśli 15. pozycja bitu w a4 nie jest ustawiona, to ustaw v12 tak, aby było równe a7, co prawdopodobnie zmienia wartość v12 z 0. W wierszu 31, jeśli v12 jest ustawione (nie zero), to wywołaj ValidateObjectAccess i sprawdź, czy prawo sedebugprivilege jest ustawione. Jeśli uda nam się sprawić, że 15. pozycja bitu w a4 będzie włączona, to w wierszu 29 nie przejdziemy do bloku i zamiast tego wywołamy InternalAddPrinterDriverEx. To skutecznie pozwala atakującemu ominąć sprawdzanie i zainstalować sterownik, umożliwiając wykonanie kodu jako użytkownik NT AUTHORITY\SYSTEM. W momencie pisania tego tekstu nadal pojawiały się dodatkowe ustalenia i poprawki; jednak jest to jeden z głównych błędów, które można wykorzystać.

https://chacker.pl/

Drugi wtorek każdego miesiąca to miesięczny cykl poprawek firmy Microsoft, z okazjonalnymi poprawkami poza pasmem z powodu krytycznej aktualizacji. Proces ten znacząco się zmienił wraz z wprowadzeniem zbiorczych aktualizacji systemu Windows 10, które weszły w życie w systemie Windows 8 od października 2016 r., a także ze zmianą sposobu pobierania poprawek. Do kwietnia 2017 r. podsumowanie i poprawki zabezpieczeń dla każdej aktualizacji można było znaleźć na stronie https://technet.microsoft.com/en-us/security/bulletin. Od kwietnia 2017 r. poprawki są pobierane ze strony Microsoft Security TechCenter pod adresem https://www.catalog.update.microsoft.com/Home.aspx, a informacje podsumowujące są dostępne na stronie https://msrc.microsoft.com/update-guide/releaseNote/. Poprawki są zazwyczaj pobierane za pomocą narzędzia Windows Update z Panelu sterowania systemu Windows lub zarządzane centralnie przez produkt, taki jak Windows Server Update Services (WSUS) lub Windows Update for Business (WUB). Gdy potrzebne są poprawki do porównania, można je uzyskać z wyżej wymienionego łącza TechNet, używając składni wyszukiwania (YYYY-MM Build_Number Architecture), takiej jak „2021-07 21H1 x64”. Każdy biuletyn poprawki jest połączony z dodatkowymi informacjami o aktualizacji. Niektóre aktualizacje są wynikiem publicznie odkrytej luki w zabezpieczeniach, podczas gdy większość z nich jest wynikiem jakiejś formy skoordynowanego prywatnego ujawnienia. Poniższy link zawiera numery CVE powiązane z poprawionymi aktualizacjami: https://msrc.microsoft.com/update-guide/vulnerability. Po kliknięciu powiązanych linków, wyświetlane są tylko ograniczone informacje o luce w zabezpieczeniach. Im więcej informacji, tym większe prawdopodobieństwo, że ktoś szybko znajdzie poprawiony kod i stworzy działający exploit. W zależności od rozmiaru aktualizacji i złożoności luki w zabezpieczeniach, samo odkrycie poprawionego kodu może być trudne. Często podatny stan jest tylko teoretyczny lub może zostać wywołany tylko w bardzo specyficznych warunkach. Może to zwiększyć trudność w określeniu przyczyny źródłowej i stworzeniu kodu proof-of-concept, który skutecznie wyzwala błąd. Po ustaleniu przyczyny źródłowej i osiągnięciu podatnego kodu oraz udostępnieniu go do analizy w debugerze należy ustalić, jak trudne będzie uzyskanie wykonania kodu, jeśli ma to zastosowanie.

https://chacker.pl/

Każdy dostawca ma swój własny proces dystrybucji poprawek, w tym Oracle, Microsoft i Apple. Niektórzy dostawcy mają ustalony harmonogram, kiedy poprawki są wydawane, podczas gdy inni nie mają ustalonego harmonogramu. Posiadanie trwającego cyklu wydawania poprawek, takiego jak ten używany przez Microsoft, pozwala osobom odpowiedzialnym za zarządzanie dużą liczbą systemów na odpowiednie planowanie. Poprawki poza pasmem mogą być problematyczne dla organizacji, ponieważ mogą nie być łatwo dostępne zasoby do wdrażania aktualizacji. Skupimy się przede wszystkim na procesie zarządzania poprawkami Microsoft, ponieważ jest to dojrzały proces, który jest często ukierunkowany na cel różnicowania w celu odkrywania luk w zabezpieczeniach w celu osiągnięcia zysku.

https://chacker.pl/

W tym laboratorium wykonasz prostą różnicę z kodem pokazanym wcześniej w sekcji „Różnice aplikacji”. Pliki binarne ELF name i name2 mają zostać porównane. Plik name jest plikiem bez poprawki, a name2 jest plikiem z poprawką. Najpierw musisz uruchomić bezpłatną aplikację IDA 5.0, którą wcześniej zainstalowałeś. Po jej uruchomieniu przejdź do Plik | Nowy, wybierz kartę Unix z wyskakującego okienka i kliknij opcję ELF po lewej stronie, jak pokazano tutaj, a następnie kliknij OK.

Przejdź do folderu C:\grayhat\app_diff\ i wybierz plik „name”. Zaakceptuj domyślne opcje, które się pojawią. IDA powinna szybko zakończyć swoją autoanalizę, domyślnie wybierając funkcję main() w oknie demontażu, jak pokazano poniżej.

Naciśnij CTRL-F11, aby wyświetlić wyskakujące okienko turbodiff. Jeśli się nie pojawi, wróć i upewnij się, że poprawnie skopiowałeś niezbędne pliki dla turbodiff. Gdy okno turbodiff jest na ekranie, wybierz opcję „pobierz informacje z tego idb” i kliknij OK, a następnie kliknij OK. Następnie przejdź do Plik | Nowy, a pojawi się wyskakujące okienko z pytaniem, czy chcesz zapisać bazę danych. Zaakceptuj ustawienia domyślne i kliknij OK. Powtórz kroki wybierania karty Unix | ELF Executable, a następnie kliknij OK. Otwórz plik binarny ELF name2 i zaakceptuj ustawienia domyślne. Powtórz kroki otwierania wyskakującego okienka turbodiff i wybierania opcji „pobierz informacje z tego idb”. Teraz, gdy wykonałeś to dla obu plików, naciśnij ponownie CTRL-F11, gdy plik name2 jest nadal otwarty w IDA. Wybierz opcję „porównaj z…” i kliknij OK. Wybierz plik name.idb i kliknij OK, a następnie kliknij OK. Powinno pojawić się poniższe pole (aby uzyskać dokładny obraz, konieczne może być sortowanie według kategorii).

Należy pamiętać, że funkcja getName() jest oznaczona jako „podejrzana ++”. Kliknij dwukrotnie funkcję getName(), aby wyświetlić następujące okno:

Na tym obrazku lewe okno pokazuje poprawioną funkcję, a prawe okno pokazuje niepoprawioną funkcję. Niepoprawiony blok używa funkcji gets(), która nie zapewnia sprawdzania granic. Poprawiony blok używa funkcji fgets(), która wymaga argumentu size, aby pomóc zapobiec przepełnieniom bufora. Poprawiona dezasemblacja jest pokazana tutaj:

W obu funkcjach było kilka dodatkowych bloków kodu, ale są one białe i nie zawierają żadnego zmienionego kodu. Są po prostu kodem ochronnym stack-smashing, który weryfikuje stack canaries, po którym następuje epilog funkcji. W tym momencie ukończyłeś laboratorium. Idąc dalej, przyjrzymy się różnicom w świecie rzeczywistym.

https://chacker.pl/

Innym narzędziem, które omówimy jest turbodiff. Wybraliśmy je ze względu na możliwość działania z darmową wersją IDA 5.0. DarunGrim i Diaphora to również świetne narzędzia; jednak do ich używania wymagana jest licencjonowana kopia IDA, co uniemożliwia osobom czytającym ukończenie ćwiczeń w tym rozdziale bez posiadania lub zakupu licencjonowanej kopii. DarunGrim i Diaphora są przyjazne dla użytkownika i łatwe do skonfigurowania z IDA. Dostępna jest literatura pomocna w instalacji i użytkowaniu (zobacz sekcję „Dalsze informacje” na końcu tego rozdziału). Inną alternatywą są narzędzia różnicujące, które działają z innymi deasemblerami, takie jak Ghidra. Jak wspomniano wcześniej, wtyczkę turbodiff można pobrać ze strony internetowej http://corelabs.coresecurity.com/ i można ją bezpłatnie pobrać i używać na podstawie licencji GPLv2. Najnowsza stabilna wersja to wersja 1.01b_r2, wydana 19 grudnia 2011 r. Aby użyć turbodiff, musisz załadować dwa pliki do porównania jeden po drugim do IDA. Gdy IDA zakończy autoanalizę pierwszego pliku, naciśnij CTRL-F11, aby wyświetlić menu podręczne turbodiff. Z opcji dostępnych podczas pierwszej analizy pliku wybierz „pobierz informacje z tego idb” i kliknij OK. Powtórz te same kroki dla drugiego pliku, który ma zostać uwzględniony w diff. Gdy zostanie to wykonane dla obu plików do porównania, naciśnij ponownie CTRL-F11, wybierz opcję „porównaj z…”, a następnie wybierz inny plik IDB. Powinno pojawić się następujące okno.

W kolumnie kategorii możesz zobaczyć etykiety takie jak identyczne, podejrzane +, podejrzane ++ i zmienione. Każda etykieta ma znaczenie i może pomóc egzaminatorowi skupić się na najciekawszych funkcjach, przede wszystkim tych oznaczonych jako podejrzane + i podejrzane ++. Etykiety te wskazują, że sumy kontrolne w jednym lub większej liczbie bloków w wybranej funkcji są niezgodne, a także czy liczba instrukcji uległa zmianie. Po dwukrotnym kliknięciu żądanej nazwy funkcji wyświetlana jest wizualna różnica, przy czym każda funkcja pojawia się w osobnym oknie, jak pokazano tutaj:

https://chacker.pl/

Jak wspomniano wcześniej, na początku 2011 roku Google przejął niemiecką firmę programistyczną Zynamics, a znany badacz Thomas Dullien, znany również jako Halvar Flake, pełnił funkcję szefa badań. Zynamics był szeroko znany z narzędzi BinDiff i BinNavi, które pomagają w inżynierii wstecznej. Po przejęciu Google znacznie obniżyło cenę tych narzędzi do jednej dziesiątej pierwotnej ceny, dzięki czemu stały się znacznie bardziej dostępne. W marcu 2016 roku Google ogłosiło, że od tej pory BinDiff będzie darmowy. Projekt jest aktywnie utrzymywany przez Christiana Blichmanna, a BinDiff 7 jest najnowszą wersją w momencie pisania tego tekstu. BinDiff jest często chwalony jako jedno z najlepszych narzędzi tego typu, zapewniające dogłębną analizę zmian bloków i kodu. W połowie 2021 roku wsparcie BinDiff dla Ghidra i Binary Ninja, innego świetnego deasemblera, było w fazie beta. BinDiff 7 jest dostarczany jako pakiet instalacyjny Windows (.msi), plik pakietu oprogramowania Debian (.deb) lub plik obrazu dysku Mac OS X (.dmg). Instalacja wymaga jedynie kilku kliknięć, licencjonowanej kopii IDA Pro i wymaganej wersji Java Runtime Environment. Aby użyć BinDiff, musisz zezwolić IDA na przeprowadzenie automatycznej analizy dwóch plików, które chcesz porównać i zapisać pliki IDB. Po zakończeniu tej czynności i otwarciu jednego z plików w IDA naciśnij CTRL-6, aby wyświetlić interfejs graficzny BinDiff, jak pokazano tutaj:

Następnym krokiem jest kliknięcie przycisku Diff Database i wybranie innego pliku IDB dla diff. W zależności od rozmiaru plików, ukończenie diff może potrwać minutę lub dwie. Po zakończeniu diff w IDA pojawią się nowe zakładki, w tym Matched Functions, Primary Unmatched i Secondary Unmatched. Zakładka Matched Functions zawiera funkcje, które istnieją w obu plikach, które mogą lub nie zawierać zmian. Każda funkcja jest punktowana wartością od 0 do 1,0 w kolumnie Similarity, jak pokazano poniżej. Im niższa wartość, tym bardziej funkcja zmieniła się między dwoma plikami. Jak stwierdził Zynamics/Google w odniesieniu do zakładek Primary Unmatched i Secondary Unmatched, „Pierwsza wyświetla funkcje, które są zawarte w aktualnie otwartej bazie danych i nie były powiązane z żadną funkcją diffed database, podczas gdy podwidok Secondary Unmatched zawiera funkcje, które są w diffed database, ale nie były powiązane z żadną funkcją w pierwszej”.

Ważne jest, aby porównać poprawne wersje pliku, aby uzyskać najdokładniejsze wyniki. Gdy przejdziesz do Microsoft TechNet, aby uzyskać poprawki opublikowane przed kwietniem 2017 r., zobaczysz kolumnę po prawej stronie zatytułowaną „Zastąpione aktualizacje”. Proces pobierania poprawek rozpoczynający się w kwietniu 2017 r. zostanie wkrótce omówiony. Przejście do adresu URL w tej lokalizacji (Zastąpione aktualizacje) przeniesie Cię do poprzedniej najnowszej aktualizacji pliku, który jest łatany. Plik taki jak jscript9.dll jest łatany prawie co miesiąc. Jeśli porównasz wersję pliku z kilku miesięcy wcześniej z poprawką, która właśnie wyszła, liczba różnic między tymi dwoma plikami bardzo utrudni analizę. Inne pliki nie są łatane zbyt często, więc kliknięcie wspomnianego łącza Zastąpione aktualizacje przeniesie Cię do ostatniej aktualizacji danego pliku, dzięki czemu będziesz mógł porównać odpowiednie wersje. Po zidentyfikowaniu interesującej funkcji za pomocą BinDiff można wygenerować różnicę wizualną, klikając prawym przyciskiem myszy żądaną funkcję z zakładki Funkcje dopasowane i wybierając opcję Wyświetl wykresy przepływu lub klikając żądaną funkcję i naciskając CTRL-E. Poniżej znajduje się przykład różnicy wizualnej. Należy zauważyć, że nie oczekuje się, że będzie można odczytać deasemblację, ponieważ jest ona pomniejszona, aby zmieścić się na stronie.

https://chacker.pl/

Ręczna analiza skompilowanego kodu dużych plików binarnych za pomocą deasemblera, takiego jak Interactive Disassembler (IDA) Pro lub Ghidra, może być trudnym zadaniem nawet dla najbardziej doświadczonego badacza. Dzięki wykorzystaniu darmowych i dostępnych komercyjnie narzędzi do porównywania plików binarnych proces wyszukiwania interesującego kodu związanego z poprawioną luką może zostać uproszczony. Takie narzędzia mogą zaoszczędzić setki godzin spędzonych na odwracaniu kodu, który może nie mieć związku z poszukiwaną luką. Oto niektóre z najbardziej znanych narzędzi do porównywania plików binarnych:

• Zynamics BinDiff (bezpłatny) Zynamics BinDiff, nabyty przez Google na początku 2011 r., jest dostępny pod adresem www.zynamics.com/bindiff.html. Wymaga licencjonowanej wersji IDA (lub Ghidra).
• turbodiff (darmowy) Opracowany przez Nicolasa Economou z Core Security, turbodiff jest dostępny na stronie https://www.coresecurity.com/corelabs/

open-source-tools/turbodiff-cs. Można go używać z darmową wersją IDA 4.9 lub 5.0. Jeśli linki nie działają, spróbuj tutaj: https://github.com/nihilus/turbodiff.

• DarunGrim/binkit (darmowy) Opracowany przez Jeong Wook Oh (Matt Oh), DarunGrim jest dostępny na stronie https://github.com/ohjeongwook/binkit. Wymaga aktualnej licencjonowanej wersji IDA.
• Diaphora (darmowy) Opracowany przez Joxeana Koreta. Diaphora jest dostępna na stronie https://github.com/joxeankoret/diaphora. Oficjalnie obsługiwane są tylko najnowsze wersje IDA.

Każde z tych narzędzi działa jako wtyczka do IDA (lub Ghidra, jeśli zaznaczono inaczej), wykorzystując różne techniki i heurystyki do określania zmian kodu między dwiema wersjami tego samego pliku. Możesz uzyskać różne wyniki, używając każdego z narzędzi do tych samych plików wejściowych. Każde z narzędzi wymaga możliwości dostępu do plików bazy danych IDA (.idb), stąd wymóg licencjonowanej wersji IDA lub bezpłatnej wersji z turbodiff. W przykładach w tym rozdziale użyjemy komercyjnego narzędzia BinDiff, a także turbodiff, ponieważ działa ono z bezpłatną wersją IDA 5.0, którą nadal można znaleźć online w różnych witrynach, takich jak https://www.scummvm.org/news/20180331/. Pozwala to osobom bez komercyjnej wersji IDA na ukończenie ćwiczeń. Jedynymi narzędziami z listy, które są aktywnie utrzymywane, są Diaphora i BinDiff. Autorzy każdego z nich powinni być wysoko cenieni za dostarczanie tak wspaniałych narzędzi, które oszczędzają nam niezliczonych godzin prób znalezienia zmian w kodzie.

https://chacker.pl/

Poprawki zabezpieczeń, takie jak te od Microsoftu i Oracle, są jednymi z najbardziej dochodowych celów różnicowania plików binarnych. Microsoft historycznie miał dobrze zaplanowany proces zarządzania poprawkami, który odbywa się według miesięcznego harmonogramu, w którym poprawki są wydawane w drugi wtorek każdego miesiąca. Łatane pliki to najczęściej biblioteki DLL i pliki sterowników, chociaż wiele innych typów plików również otrzymuje aktualizacje, takie jak pliki .exe. Wiele organizacji nie łata swoich systemów szybko, pozostawiając atakującym i testerom penetracyjnym otwartą okazję do naruszenia tych systemów za pomocą publicznie ujawnionych lub prywatnie opracowanych exploitów za pomocą różnicowania poprawek. Począwszy od systemu Windows 10, Microsoft jest znacznie bardziej agresywny w zakresie wymagań dotyczących poprawek, co sprawia, że ​​odroczenie aktualizacji jest trudne. W zależności od złożoności łatanej luki w zabezpieczeniach i trudności w zlokalizowaniu odpowiedniego kodu, działający exploit może czasami zostać opracowany szybko w ciągu kilku dni lub tygodni po wydaniu poprawki. Exploity opracowane po inżynierii wstecznej poprawek bezpieczeństwa są powszechnie określane jako exploity 1-dniowe lub n-dniowe. Różnią się one od exploitów 0-dniowych, w których poprawka jest niedostępna w momencie jej odkrycia w środowisku naturalnym. W miarę przechodzenia przez ten rozdział szybko zobaczysz korzyści z różnicowania zmian kodu w sterownikach, bibliotekach i aplikacjach. Chociaż nie jest to nowa dyscyplina, różnicowanie binarne nadal przyciąga uwagę badaczy bezpieczeństwa, hakerów i dostawców jako realna technika odkrywania luk i czerpania zysków. Cena za exploit 1-dniowy nie jest zazwyczaj tak wysoka, jak za exploit 0-dniowy; jednak nie jest niczym niezwykłym, że można zobaczyć atrakcyjne wypłaty za bardzo pożądane exploity. Ponieważ większość luk jest ujawniana prywatnie bez publicznie dostępnego exploita, dostawcy ram eksploatacji chcą mieć więcej exploitów powiązanych z tymi prywatnie ujawnionymi lukami niż ich konkurenci