Grey Hat Hackingchacker.pl



Między uznaniem , a progiem karceru…



01.07.2021

Mutacje przeciwko przepełnieniu stosu

Wcześniej dowiedziałeś się o przyczynach przepełnienia stosu i sposobach ich wykorzystania. W tej sekcji omówimy proste zmiany w pliku binarnym, które mogą spowodować awarię działającego exploita atakującego. Przypomnijmy, że miejsce na zmienne lokalne alokowane na stosie jest przydzielane podczas prologu funkcji przez dostosowanie wskaźnika stosu po wejściu do tej funkcji. Poniżej przedstawiono źródło C dla funkcji badCode wraz z kodem prologu x86, który może zostać wygenerowany dla badCode.

void badCode(int x) {
char buf[256];
int i, j;
//body of badCode here
}
; generated assembly prologue for badCode
badCode:
push ebp
mov ebp, esp
sub esp, 264

Tutaj instrukcja, która odejmuje 264 od esp, przydziela przestrzeń stosu na 256-bajtowy bufor i dwie 4-bajtowe liczby całkowite i oraz j. Wszystkie odwołania do zmiennej w [ebp-256] odnoszą się do 256-bajtowego bufora bufora. Jeśli atakujący odkryje lukę prowadzącą do przepełnienia 256-bajtowego bufora, może opracować exploita, który kopiuje co najmniej 264 bajty do buf (256 bajtów do wypełnienia buf, 4 bajty do nadpisania zapisanej wartości ebp i dodatkowe 4 bajtów do kontrolowania zapisanego adresu zwrotnego) i przejęcia kontroli nad podatną na ataki aplikacją. Zmutowanie tej aplikacji to prosta sprawa zmodyfikowania układu stosu w taki sposób, aby lokalizacja zapisanego adresu zwrotnego względem początku bufora była czymś innym niż spodziewa się atakujący. W takim przypadku chcielibyśmy w jakiś sposób przenieść buf tak, aby był oddalony o więcej niż 260 bajtów od zapisanego adresu zwrotnego. To prosty, dwuetapowy proces. Pierwszym krokiem jest sprawienie, aby badCode zażądało więcej miejsca na stosie, co jest osiągane przez modyfikację stałej, która jest odejmowana od esp w prologu. W tym przykładzie wybieramy przeniesienie buf na przeciwną stronę zmiennych i oraz j. Aby to zrobić, potrzebujemy wystarczająco dużo dodatkowej przestrzeni, aby pomieścić buf i pozostawić i i j w ich pierwotnych lokalizacjach. Zmodyfikowany prolog znajduje się na poniższej liście:

; mutated assembly prologue for badCode
badCode:
push ebp
mov ebp, esp
sub esp, 520

Ostatnią zmianą wymaganą do zakończenia mutacji jest zlokalizowanie wszystkich odniesień do [ebp-256] w oryginalnej wersji badCode i aktualizacja offsetu z ebp, aby odzwierciedlić nową lokalizację buf w [ebp-520]. Całkowita liczba bajtów, które muszą zostać zmienione, aby dokonać tej mutacji, to jeden dla zmiany prologu plus jeden dla każdej lokalizacji, która odwołuje się do buf. W wyniku tej konkretnej mutacji 264-bajtowe nadpisanie atakującego jest znacznie mniejsze niż adres zwrotny, który próbuje nadpisać. Nie znając układu naszego zmutowanego pliku binarnego, atakujący może tylko zgadywać, dlaczego jej atak się nie powiódł, zakładając, że mamy nadzieję, że nasza konkretna aplikacja jest załatana, co prowadzi ją do innych, niezałatanych ofiar. Pamiętaj, że aplikacja pozostaje tak podatna na ataki jak zawsze. Bufor o wielkości 528 bajtów nadal nadpisze zapisany adres powrotu. Sprytny napastnik może próbować powiększyć swój bufor, stopniowo dołączając kopie pożądanego adresu zwrotnego do końcowego końca bufora, w końcu potykając się o odpowiedni rozmiar bufora, aby wykorzystać naszą aplikację. Jednak na koniec warto dodać, że wprowadziliśmy kilka nowych przeszkód, które atakujący musi pokonać. Po pierwsze, lokalizacja buf zmieniła się na tyle, że dowolny adres zwrotny wybrany przez atakującego może nie trafić poprawnie w nową lokalizację buf, powodując w ten sposób przegapienie swojego szelkodu. Po drugie, zmienne i oraz j leżą teraz pod buf i obie zostaną uszkodzone przez przepełnienie atakującego. Jeśli dane wejściowe atakującego powodują umieszczenie nieprawidłowych wartości w którejkolwiek z tych zmiennych, możemy zaobserwować nieoczekiwane zachowanie w badCode, które może spowodować zakończenie funkcji w sposób nieprzewidziany przez naszego atakującego. W tym przypadku i oraz j zachowują się jak prowizoryczne kanarki stosu. Bez dostępu do naszego zmutowanego pliku binarnego osoba atakująca nie zrozumie, że musi zachować szczególną ostrożność, aby zachować integralność zarówno i, jak i j. Wreszcie, moglibyśmy przydzielić więcej miejsca na stosie w prologu, na przykład odejmując 536 bajtów i przenosząc buf do [ebp-527]. Efektem tej subtelnej zmiany jest to, że buf zaczyna się od czegoś innego niż granica 4 bajtów. Bez znajomości wyrównania buf, jakikolwiek adres zwrotny zawarty w danych wejściowych atakującego prawdopodobnie nie zostanie prawidłowo wyrównany, gdy nadpisze zapisany adres zwrotny, co ponownie doprowadzi do niepowodzenia exploita atakującego. Powyższy przykład przedstawia tylko jeden sposób, w jaki można zmodyfikować układ stosu w celu udaremnienia wszelkich zautomatyzowanych ataków, które mogą pojawić się w przypadku naszej podatnej na ataki aplikacji. Należy pamiętać, że ta technika zapewnia jedynie bezpieczeństwo poprzez ukrycie i nigdy nie powinna być traktowana jako trwała naprawa luki w zabezpieczeniach. Jedynym celem tego rodzaju łaty powinno być umożliwienie uruchomienia aplikacji w okresie między ujawnieniem luki w zabezpieczeniach a wydaniem odpowiedniej łaty przez aplikację sprzedawcy.
Powrót

02.07.2021

Mutacje przeciwko przepełnieniu sterty

Wcześniej widzieliśmy mechanikę exploitów przepełnienia sterty. Podobnie jak przepełnienia stosu, udane przepełnienia sterty wymagają od atakującego dokładnego obrazu układu pamięci otaczającego podatny bufor. W przypadku przepełnienia sterty celem atakującego jest nadpisanie struktur kontroli sterty specjalnie dobranymi wartościami, które spowodują, że procedury zarządzania stertą zapiszą wartość wybraną przez atakującego w wybranej przez niego lokalizacji. Dzięki tej prostej możliwości arbitralnego zapisu osoba atakująca może przejąć kontrolę nad zagrożonym procesem. Aby zaprojektować mutację, która zapobiega konkretnemu atakowi przepełnienia, musimy zmienić układ sterty na inny niż ten, którego spodziewa się atakujący na podstawie swojej analizy podatnego pliku binarnego. Ponieważ cały punkt omawianych mutacji polega na wygenerowaniu prostej łatki, która nie wymaga większych poprawek pliku binarnego, musimy wymyślić prostą technikę mutowania sterty bez konieczności wstawiania nowego kodu do naszego pliku binarnego. Odwołanie że wykonaliśmy mutację w buforze stosu, modyfikując prolog funkcji, aby zmienić rozmiar przydzielonych zmiennych lokalnych. W przypadku przepełnienia sterty analogiczna mutacja polegałaby na zmodyfikowaniu rozmiaru bloku pamięci przekazanego do malloc/new, gdy alokujemy blok pamięci, którego przepełnienie spodziewa się atakujący. Podstawową ideą jest zwiększenie ilości żądanej pamięci, co z kolei spowoduje, że układ bufora atakującego nie będzie odpowiadał strukturom kontrolnym, na które atakuje. Poniższa lista przedstawia alokację 256-bajtowego bufora sterty:

; allocate a 256 byte buffer in the heap
push 256
call malloc

Po przydzieleniu tego bufora atakujący spodziewa się, że struktury kontroli sterty leżą w dowolnym miejscu od 256 do 272 bajtów w buforze (patrz rozdział 8, aby dowiedzieć się, jak odświeżyć układ sterty). Jeśli zmodyfikujemy poprzedni kod do następującego:

; allocate a 280 byte buffer in lieu of a 256 byte buffer
push 280
call malloc

wtedy założenia atakującego dotyczące lokalizacji struktury kontroli sterty stają się nieważne, a jego exploit staje się znacznie bardziej prawdopodobny, aby zawieść. Mutacje sterty stają się nieco bardziej skomplikowane, gdy rozmiar przydzielonego bufora musi zostać obliczony w czasie wykonywania. W takich przypadkach musimy znaleźć sposób na zmodyfikowanie obliczeń, aby obliczyć nieco większy rozmiar.
Powrót

03.07.2021

Mutacje przeciwko exploitom ciągu formatującego

Podobnie jak w przypadku przepełnienia stosu, exploity wykorzystujące ciąg formatujący wymagają od atakującego posiadania określonej wiedzy na temat układu stosu. Dzieje się tak, ponieważ atakujący wymaga, aby wartości wskaźników znajdowały się w bardzo określonych miejscach na stosie, aby uzyskać możliwość dowolnego zapisu, którą oferują ciągi formatujące. Na przykład osoba atakująca może polegać na wartościach indeksowanych parametrów, takich jak "%17$hn" w swoim ciągu formatu. Mutacje mające na celu złagodzenie luki w ciągach formatu opierają się na tych samych założeniach dotyczących modyfikacji układu, których użyliśmy do łagodzenia przepełnień stosu i sterty. Jeśli uda nam się zmodyfikować stos w sposób, który spowoduje, że założenia atakującego dotyczące lokalizacji ich danych staną się nieważne, prawdopodobnie zakończy się niepowodzeniem. Rozważ pasek funkcji i część asemblera wygenerowaną dla niego w poniższym listingu:

void bar() {
char local_buf[1024];
//now fill local_buf with user input

printf(local_buf);
}
; assembly excerpt for function bar
bar:
push ebp
mov ebp, esp
sub esp, 1024 ; allocates local_buf
;do something to fill local_buf with user input

lea eax, [ebp-1024]
push eax
call print

Oczywiście zawiera to usterkę ciągu formatującego, ponieważ local_buf, który zawiera dane wejściowe dostarczone przez użytkowników, zostanie użyty bezpośrednio jako ciąg formatujący w wywołaniu printf. Układ stosu dla bar i printf pokazano na rysunku 19-5. Rysunek 19-5 pokazuje, że atakujący może oczekiwać odwoływania się do elementów local_buf jako parametrów od 1$ do 256$ podczas konstruowania ciągu formatu. Dokonując prostej zmiany pokazanej na poniższej liście, przydzielając dodatkowe 1024 bajty w ramce stosu paska, założenia napastnika nie zostaną spełnione, a jej wykorzystanie ciągu formatu najprawdopodobniej się nie powiedzie.

; Modified assembly excerpt for function bar
bar:
push ebp
mov ebp, esp
sub esp, 2048 ; allocates local_buf and padding
;do something to fill local_buf with user input

lea eax, [ebp-1024]
push eax
call print

Zauważ, że dodatkowa przestrzeń stosu przydzielona w prologu baru powoduje przesunięcie lokalizacji local_buf z perspektywy printf. Wartości, które atakujący spodziewa się znaleźć w lokalizacjach od 1$ do 256$, znajdują się teraz w lokalizacjach od 257$ do 512$. W rezultacie wszelkie założenia atakującego dotyczące lokalizacji jej ciągu formatu stają się nieważne, a atak kończy się niepowodzeniem. Podobnie jak w przypadku innych technik mutacji, należy pamiętać, że ten rodzaj łaty nie koryguje podstawowej wrażliwości. W poprzednim przykładzie pasek funkcji nadal zawiera usterkę ciągu formatu, którą można wykorzystać, jeśli osoba atakująca ma odpowiednią wiedzę na temat układu stosu paska. Jednak osiągnięto pewien stopień odporności na wszelkie zautomatyzowane ataki, które mogą zostać stworzone w celu wykorzystania niezałatanej wersji tej luki. Nie można wystarczająco podkreślić, że nigdy nie należy tego traktować jako długoterminowego rozwiązania sytuacji możliwej do wykorzystania i że należy jak najszybciej zastosować odpowiednią, dostarczoną przez dostawcę poprawkę.
Powrót

04.07.2021

Inicjatywy łatania stron trzecich

Za każdym razem, gdy usterka jest publicznie ujawniana, dostawca oprogramowania, którego dotyczy luka, jest dokładnie sprawdzany. Jeśli luka zostanie ogłoszona w związku z wydaniem łaty, opinia publiczna chce wiedzieć, jak długo sprzedawca wiedział o luce przed jej wydaniem. Jest to ważna informacja, ponieważ pozwala użytkownikom dowiedzieć się, jak długo dostawca pozostawił ich podatnych na potencjalne ataki typu zero-day. Gdy luki w zabezpieczeniach zostaną ujawnione przed powiadomieniem dostawcy, użytkownicy oprogramowania, którego dotyczy problem aby żądać szybkiej reakcji od dostawcy, aby mógł załatać swoje oprogramowanie i stać się odpornym na potencjalne ataki związane z nowo ogłoszoną luką w zabezpieczeniach. W rezultacie czas reakcji dostawcy stał się jednym z czynników, które niektórzy wykorzystują do wyboru aplikacji, które najlepiej odpowiadają ich potrzebom. W niektórych przypadkach dostawcy postanowili regulować częstotliwość, z jaką publikują aktualizacje zabezpieczeń. Microsoft, na przykład, jest dobrze znany z procesu "Wtorku łat", który publikuje aktualizacje zabezpieczeń w drugi wtorek każdego miesiąca. Niestety, sprytni napastnicy mogą zdecydować się na ogłoszenie luk w zabezpieczeniach następnego dnia, próbując zapewnić sobie co najmniej miesięczny czas reakcji. W odpowiedzi na spostrzegane spowolnienie ze strony producentów oprogramowania, jeśli chodzi o łatanie luk w zabezpieczeniach, ostatnio wzrosła liczba łatek bezpieczeństwa innych firm udostępnianych po ujawnieniu luk. Wydaje się, że trend ten rozpoczął się od Ilfaka Guilfanova, autora IDA Pro, który pod koniec grudnia opublikował łatkę dla WindowsWMFexploit 2005. Nic dziwnego, że Microsoft odradzał używanie tej łatki innej firmy. Zaskakujące było poparcie dla poprawki przez SANS Internet Storm Center. Przy tak sprzecznych informacjach, co zrobi przeciętny użytkownik komputera? Jest to trudne pytanie, które musi zostać rozwiązane, jeśli pomysł łatania stron trzecich ma kiedykolwiek stać się powszechnie akceptowany. Niemniej jednak, w następstwie exploita WMF, wydano dodatkowe łatki stron trzecich dla nowszych luk w zabezpieczeniach. Byliśmy także świadkami utworzenia grupy specjalistów ds. bezpieczeństwa w samozwańczym Zespole Reagowania na Sytuację Ratunkową Zeroday (ZERT), którego celem jest szybkie opracowywanie łat w następstwie ujawnień publicznych luk w zabezpieczeniach. Wreszcie, w odpowiedzi na jeden z niedawnych starań o generowanie błędów, nazwany "Miesiącem Błędów Apple", były programista Apple Landon Fuller przeprowadził własny równoległy projekt "Miesiąc Napraw Apple". Wynik netto dla użytkowników końcowych, pomijając kwestię tego, w jaki sposób strona trzecia może opracować łatę szybciej niż dostawca aplikacji, jest taki, że w niektórych przypadkach łatki dla znanych luk w zabezpieczeniach mogą być dostępne na długo przed wydaniem przez producentów oficjalnych łatek. Należy jednak zachować szczególną ostrożność podczas korzystania z tych łat, ponieważ nie można oczekiwać wsparcia ze strony producenta, jeśli taka łatka ma jakiekolwiek szkodliwe skutki uboczne.
Powrót

05.07.2021

Złośliwe oprogramowanie

Złośliwe oprogramowanie można zdefiniować jako dowolną niezamierzoną i niechcianą instalację oprogramowania w systemie bez wiedzy lub chęci użytkownika.

Rodzaje złośliwego oprogramowania

Istnieje wiele rodzajów złośliwego oprogramowania, ale do naszych celów wystarczy poniższa lista złośliwego oprogramowania.

Wirus : Wirus to pasożytniczy program, który dołącza się do innych programów w celu zainfekowania tego programu i wykonania niechcianych funkcji. Wirusy mają różne nasilenie i zagrożenie, jakie stanowią. Niektóre są łatwe do wykrycia, a inne bardzo trudne do wykrycia i usunięcia z systemu. Niektóre wirusy wykorzystują technologię polimorficzną (zmieniającą się) do morfowania podczas przechodzenia z systemu do systemu, przedłużając w ten sposób ich wykrywanie. Wirus wymaga od użytkowników pomocy poprzez uruchomienie aplikacji lub skryptu, który zawiera wirusa. Użytkownicy mogą nie wiedzieć, że wykonali wirusa; zamiast tego mogą myśleć, że otwierają obraz lub pozornie nieszkodliwą aplikację.
Koń trojański : koń trojański to złośliwe oprogramowanie, które wykonuje nikczemny czyn w imieniu napastnika bez wiedzy użytkownika o jego istnieniu. Jak sama nazwa wskazuje, niektóre konie trojańskie przedostają się do systemu osadzonego w innym oprogramowaniu. Wiadomo, że pirackie oprogramowanie zawiera kod konia trojańskiego.
Robaki : Mówiąc najprościej, robaki to wirusy samorozmnażające się. Nie wymagają żadnego działania ze strony użytkownika, aby wykonać i przejść z systemu do systemu. W ostatnich latach robaki były powszechne i były wykorzystywane do wielu celów, takich jak dystrybucja koni trojańskich i innych form złośliwego oprogramowania
. Oprogramowanie szpiegowskie/adware : Oprogramowanie szpiegujące i reklamowe opisuje klasę oprogramowania, które jest instalowane bez wiedzy użytkownika w celu zgłaszania atakującemu zachowania użytkownika. Atakujący w tym przypadku może działać pod przykrywką reklamodawcy, specjalisty ds. marketingu lub badacza Internetu. Poza oczywistymi problemami z prywatnością, w większości przypadków ta klasa oprogramowania nie jest złośliwa. Istnieją jednak pewne formy oprogramowania szpiegującego, które wykorzystują technologię rejestrowania klawiszy do przechwytywania naciśnięć klawiszy przez użytkownika i odprowadzania ich z komputera do centralnej bazy danych. W takim przypadku mogą być gromadzone hasła i informacje finansowe, a oprogramowanie szpiegujące należy uznać za duże zagrożenie dla użytkownika lub organizacji.
Powrót

06.07.2021

Techniki obrony przed złośliwym oprogramowaniem

Jednym z najważniejszych aspektów złośliwego oprogramowania jest jego trwałość po ponownym uruchomieniu i długowieczność. W tym celu napastnicy podejmują doskonałe środki obronne, aby chronić część złośliwego oprogramowania przed wykryciem.

Rootkity : Definicja "rootkita" ewoluowała, ale obecnie powszechnie odnosi się do kategorii oprogramowania, które ukrywa siebie i inne oprogramowanie przed administratorami systemu, aby wykonać jakieś nikczemne zadanie. Dobry rootkit zapewni pewną formę przeżywalności restartu i ukryje procesy, pliki, wpisy rejestru, połączenia sieciowe, a co najważniejsze, ukryje się.
Packery : Packery służą do "pakowania" lub kompresowania formatu pliku Windows PE. Najczęstsze packery to

•  UPX
•  ASPack
• o tElok

Opakowania ochronne z szyfrowaniem : Niektórzy hakerzy używają narzędzi do pakowania swoich plików binarnych za pomocą szyfrowania za pomocą narzędzi takich jak:

•  Burney
•  Shiva

Wykrywanie maszyn wirtualnych: Jak można się było spodziewać, ponieważ coraz więcej obrońców zaczęło używać VMware do przechwytywania i badania złośliwego oprogramowania, wiele rodzajów złośliwego oprogramowania wykorzystuje teraz jakąś formę wykrywania maszyn wirtualnych (maszyny wirtualne). W dalszej części tego rozdziału opiszemy stan tego wyścigu zbrojeń
Powrót

07.07.2021

Najnowsze trendy w technologii Honeynet

Mówiąc o wyścigach zbrojeń, wraz z ewolucją technologii atakujących ewoluowała również technologia używana przez obrońców. Ta gra w kotka i myszkę odbywa się od lat, ponieważ napastnicy próbują pozostać niezauważeni, a obrońcy próbują wykryć najnowsze zagrożenia i wprowadzić środki zaradcze, aby lepiej chronić swoje sieci.
Honeypoty: Honeypoty to systemy wabików umieszczone w sieci wyłącznie w celu przyciągnięcia hakerów. W systemach nie ma prawdziwej wartości, nie ma poufnych informacji i po prostu wyglądają, jakby były wartościowe. Nazywa się je "honeypot", ponieważ gdy hakerzy włożą rękę do garnka i skosztują miodu, wracają po więcej.
Honeynet: Honeypot to pojedynczy system służący jako wabik. Honeynet to zbiór systemów udających wabik. Innym sposobem myślenia o tym jest to, że honeynet zawiera dwa lub więcej honeypotów
Powrót

08.07.2021

Dlaczego używane są Honeypoty

Istnieje wiele powodów, dla których warto używać honeypota w sieci korporacyjnej, w tym oszustwa i zbieranie informacji.

Oszustwo jako motyw


American Heritage Dictionary definiuje oszustwo jako "1. Użycie oszustwa; 2. Fakt lub stan bycia oszukanym; 3. Podstęp; sztuczka." Honeypot może być używany do oszukiwania napastników i nakłaniania ich do pominięcia "klejnotów koronnych" i uruchomienia alarmu. Pomysł tutaj jest taki aby twój honeypot znajdował się w pobliżu głównej alei prowadzącej do twoich klejnotów koronnych.

Inteligencja jako motyw

W odniesieniu do honeypotów inteligencja ma dwa znaczenia: (1) wskazania i ostrzeżenia oraz (2) badania.

Wskazania i ostrzeżenia

Prawidłowo skonfigurowany honeypot może dostarczyć cennych informacji w postaci wskazań i ostrzeżeń o ataku. Honeypot z definicji nie ma uzasadnionego celu, więc każdy ruch przeznaczony dla lub pochodzący z honeypota można od razu uznać za złośliwy. Jest to kluczowy punkt, który zapewnia kolejną dogłębną obronę. Jeśli nie ma znanej sygnatury ataku, którą mógłby wykryć system IDS oparty na sygnaturach, i nie ma systemu IDS opartego na anomaliach, który obserwuje ten segment sieci, pułapka może być jedynym sposobem wykrycia złośliwej aktywności w przedsiębiorstwie. W tym kontekście honeypot można traktować jako ostatnią siatkę bezpieczeństwa w sieci i jako uzupełnienie istniejącego systemu IDS.

Badania

Innym równie ważnym zastosowaniem honeypotów są badania. W obszarze badań wykorzystuje się coraz więcej honeypotów. Projekt Honeynet jest liderem tego wysiłku i nawiązał sojusz z wieloma innymi organizacjami. Codziennie ruch jest przechwytywany, analizowany i udostępniany innym specjalistom ds. bezpieczeństwa. Pomysł polega na obserwowaniu atakujących w akwarium i wyciąganiu wniosków z ich działań w celu lepszej ochrony sieci jako całości. Obszar badań honeypotów napędzał koncepcję nowych technologii i technik. W dalszej części tego rozdziału skonfigurujemy pułapkę badawczą, aby złapać trochę złośliwe oprogramowanie do analizy.
Powrót

09.07.2021

Ograniczenia

Choć koncepcja honeypotów brzmi atrakcyjnie, jest jednak pewien minus. Wady honeypotów są następujące.

Ograniczony punkt widzenia

Honeypot zobaczy tylko to, co jest na niego skierowane. Może siedzieć miesiącami lub latami i niczego nie zauważać. Z drugiej strony, studia przypadków dostępne na stronie głównej Honeynet opisują ataki w ciągu kilku godzin od umieszczenia pułapki w sieci. Wtedy zaczyna się zabawa; jeśli jednak napastnik wykryje, że biega w pułapce miodu, zabierze jej zabawki i odejdzie.

Ryzyko

Za każdym razem, gdy wprowadzasz do sieci inny system, pojawia się nowe ryzyko. Wielkość ryzyka zależy od rodzaju i konfiguracji honeypota. Głównym ryzykiem nałożonym przez honeypot jest ryzyko, jakie skompromitowany honeypot stanowi dla reszty Twojej organizacji. Nie ma nic gorszego niż atakujący uzyskujący dostęp do twojego honeypota, a następnie wykorzystujący go jako punkt wyjścia do dalszego ataku na twoją sieć. Inną formą ryzyka narzucanego przez honeypoty jest odpowiedzialność podrzędna, jeśli atakujący użyje honeypota w Twojej organizacji do zaatakowania innych organizacji. Aby pomóc w zarządzaniu ryzykiem, istnieją dwa rodzaje honeypotów: niska interakcja i wysoka interakcja.
Powrót

10.07.2021

Honeypoty o niskiej interakcji

Honeypoty o niskiej interakcji emulują usługi i systemy w celu zmylenia atakującego, ale nie oferują pełnego dostępu do podstawowego systemu. Tego typu honeypoty są często używane w środowiskach produkcyjnych, w których ryzyko zaatakowania innych systemów produkcyjnych jest wysokie. Tego typu honeypoty mogą uzupełniać technologie wykrywania włamań, ponieważ oferują bardzo niski wskaźnik wyników fałszywie dodatnich, ponieważ wszystko, co do nich przychodzi, było nieoczekiwane, a tym samym podejrzane.
honeyd

honeyd to zestaw skryptów opracowanych przez Niels Provos i stał się de facto standardem dla honeypotów o niskiej interakcji. Istnieje kilka skryptów emulujących usługi IIS, telnet, ftp i inne. Narzędzie jest dość skuteczne w wykrywaniu skanów i bardzo podstawowego złośliwego oprogramowania. Jednak szklany sufit jest dość widoczny, jeśli napastnik lub robak próbuje zrobić zbyt wiele.

Nepenthes

Nepenthes jest nowicjuszem na scenie i został połączony z projektem mwcollect, tworząc całkiem imponujące narzędzie. Przewaga tego narzędzia nad Honeyd polega na tym, że szklany sufit jest znacznie, znacznie wyższy. Nepenthes stosuje kilka technik, aby lepiej emulować usługi, a tym samym wydobyć więcej informacji od atakującego lub robaka. System jest zbudowany w celu wyodrębniania plików binarnych ze złośliwego oprogramowania w celu dalszej analizy, a nawet może wykonywać wiele typowych wywołań systemowych, które szelkod wykonuje w celu pobrania etapów drugorzędnych i tak dalej. System zbudowany jest na zestawie modułów przetwarzających protokoły i szelkod.
Powrót

11.07.2021

Honeypoty o wysokiej interakcji

Z drugiej strony, honeypoty o wysokiej interakcji są często prawdziwymi dziewiczymi kompilacjami systemów operacyjnych z kilkoma lub bez poprawek i mogą być w pełni zagrożone przez atakującego. Honeypoty o wysokiej interakcji wymagają wysokiego poziomu nadzoru, ponieważ atakujący ma pełną kontrolę nad honeypotem i może z nim zrobić, co chce. Często honeypoty o wysokiej interakcji są wykorzystywane w roli badawczej zamiast produkcyjnej.
Powrót

12.07.2021

Rodzaje Honeynetów

Jak już wspomniano, honeynet to po prostu kolekcje honeypotów. Zwykle oferują małą sieć wrażliwych pułapek, z którymi atakujący może się bawić. Technologia Honeynet zapewnia zestaw narzędzi do prezentowania systemów atakującemu w nieco kontrolowanym środowisku, dzięki czemu można badać zachowanie i techniki atakujących.

Gen I Honeynets
W maju 2000 r. Lance Spitzner założył system w swojej sypialni. Tydzień później system został zaatakowany, a Lance zwerbował wielu swoich przyjaciół do zbadania ataku. Reszta, jak mówią, to historia i narodziła się koncepcja honeypotów. Wtedy, Gen I Honeynets używał routerów do oferowania połączenia z honeypotami i oferował niewiele w zakresie gromadzenia danych lub kontroli danych. Lance utworzył organizację honeynet.org, która do dziś pełni kluczową rolę, pilnując atakujących i "oddając" te cenne informacje branży zabezpieczeń.
Gen II Honeynets
Opracowano Honeynets Gen II, a artykuł został opublikowany w czerwcu 2003 r. na stronie honeynet.org. Kluczową różnicą jest zastosowanie technologii pomostowej, która umożliwia umieszczenie sieci honeynet wewnątrz sieci korporacyjnej, przyciągając w ten sposób zagrożenia wewnętrzne. Co więcej, most służył jako rodzaj odwróconej zapory ogniowej (zwanej "honeywall"), która oferowała podstawowe możliwości gromadzenia i kontroli danych.
Gen III Honeynets
W 2005 roku Honeynets Gen III zostały opracowane przez honeynet.org. Honeywall przekształcił się w produkt o nazwie roo i znacznie poprawił możliwości gromadzenia i kontroli danych, zapewniając jednocześnie zupełnie nowy poziom analizy danych za pośrednictwem interaktywnego interfejsu internetowego o nazwie Walleye.

Architektura

Gen III Honeynets (roo) służy jako niewidoczne przednie drzwi sieci honeynetu. Most pozwala na kontrolę danych i zbieranie danych z samego honeywalla. Honeynet można teraz umieścić tuż obok systemów produkcyjnych, w tym samym segmencie sieci.

Kontrola danych

Honeywall zapewnia kontrolę danych poprzez ograniczenie wychodzącego ruchu sieciowego z honeypotów. Ponownie, jest to niezbędne, aby zmniejszyć ryzyko stwarzane przez zhakowane honeypoty atakujące inne systemy. Celem kontroli danych jest zrównoważenie potrzeby komunikowania się zhakowanego systemu z systemami zewnętrznymi (w celu pobrania dodatkowych narzędzi lub uczestniczenia w sesji IRC dowodzenia i kontroli) z potencjałem systemu do atakowania innych. Aby zapewnić kontrolę danych, reguły ograniczania szybkości iptable (zapory) są używane w połączeniu z systemem snort-inline (system zapobiegania włamaniom), aby aktywnie modyfikować lub blokować ruch wychodzący.

Zbieranie danych

Honeywall ma kilka metod zbierania danych z honeypotów. Następujące źródła informacji są łączone w wspólny format zwany hflow:

•  Monitor przepływu Argus
•  IDS Snort
•  P0f - pasywne wykrywanie systemu operacyjnego
•  Sebek defensywne dane rootkita z honeypotów
•  przechwytywanie ruchu Pcap

Analiza danych
Interfejs sieciowy TheWalleye oferuje bezprecedensowy poziom zapytań dotyczących ataków i danych kryminalistycznych. Od początkowego ataku, przez przechwytywanie naciśnięć klawiszy, po przechwytywanie exploitów dnia zerowego o nieznanych lukach, interfejs Walleye udostępnia wszystkie te informacje na wyciągnięcie ręki. Istnieje wiele innych nowych funkcji Honeynetu roo Gen III (zbyt wiele, aby je tutaj wymienić) i zachęcamy do odwiedzenia strony honeynet.org, aby uzyskać więcej szczegółów i białe księgi.
Powrót

13.07.2021

Przełamywanie technologii wykrywania Vmware

Atakujący nieustannie szukają sposobów na wykrycie VMware i innych technologii wirtualizacji. Jak opisano w odnośnikach Listona i Skoudisa, stosuje się kilka technik.

Narzędzie: Metoda

redPill : Polecenie Stored Interrupt Descriptor Table (SIDT) pobiera adres tabeli deskryptorów przerwań (IDT) i analizuje adres, aby określić, czy używany jest VMware.
Scoopy : Opiera się na sztuczce SIDT/IDT z redPill, sprawdzając adres globalnej tabeli deskryptorów (GDT) i lokalnej tabeli deskryptorów (LDT), aby zweryfikować wyniki redPill.
Doo : Dołączony do narzędzia Scoopy, sprawdza wskazówki w kluczach rejestru, sterownikach i innych różnicach między sprzętem VMware a rzeczywistym sprzętem.
Jerry : Niektóre z normalnych zestawów instrukcji x86 są zastępowane przez VMware i niewielkie różnice można wykryć, porównując oczekiwany wynik normalnej instrukcji z rzeczywistym wynikiem.
VmDetect : VirtualPC wprowadza instrukcje do zestawu instrukcji x86. VMware wykorzystuje istniejące instrukcje, które są uprzywilejowane. VmDetect używa technik, aby sprawdzić, czy istnieje którakolwiek z tych sytuacji. Jest to najskuteczniejsza metoda i jest pokazana dalej.

Jak Liston i Skoudis poinformowali w webcastie SANS, a później opublikowali, istnieją pewne nieudokumentowane funkcje w VMware, które są dość skuteczne w eliminowaniu najczęściej używanych sygnatur środowiska wirtualnego. Umieść następujące wiersze w pliku .vmx zatrzymanej maszyny wirtualnej:

isolation.tools.getPtrLocation.disable = "TRUE"
isolation.tools.setPtrLocation.disable = "TRUE"
isolation.tools.setVersion.disable = "TRUE"
isolation.tools.getVersion.disable = "TRUE"
monitor_control.disable_directexec = "TRUE"
monitor_control.disable_chksimd = "TRUE"
monitor_control.disable_ntreloc = "TRUE"
monitor_control.disable_selfmod = "TRUE"
monitor_control.disable_reloc = "TRUE"
monitor_control.disable_btinout = "TRUE"
monitor_control.disable_btmemspace = "TRUE"
monitor_control.disable_btpriv = "TRUE"
monitor_control.disable_btseg = "TRUE"

PRZESTROGA: Chociaż te polecenia są dość skuteczne w udaremnianiu działania RedPill, Scoopy, Jerry, VmDetect i innych, zakłócają niektóre "komfortowe" funkcje maszyny wirtualnej, takie jak mysz, przeciąganie i upuszczanie, udostępnianie plików, schowek i tak dalej . Te ustawienia nie są udokumentowane przez użytkownika VMware na własne ryzyko!

Ładując maszynę wirtualną z poprzednimi ustawieniami, udaremnisz większość narzędzi, takich jak VmDetect
Powrót

14.07.2021

Łapanie złośliwego oprogramowania: zastawianie pułapki

W tej sekcji skonfigurujemy bezpieczne środowisko testowe i zajmiemy się wykrywaniem złośliwego oprogramowania. Uruchomimy VMware na naszym hoście i uruchomimy Nepenthes na wirtualnej maszynie Linux, aby złapać trochę złośliwego oprogramowania. Aby uzyskać ruch do naszego honeypota, musimy otworzyć naszą zaporę ogniową lub w moim przypadku, aby ustawić adres IP pułapki jako DMZhost na mojej zaporze.

Konfiguracja hosta Vmware

W tym teście użyjemy VMware na naszym hoście i ustawimy pułapkę za pomocą tej prostej konfiguracji:



UWAGA : Istnieje niewielkie ryzyko związane z uruchomieniem tej konfiguracji; teraz ufamy temu honeypotowi w naszej sieci. W rzeczywistości ufamy, że program Nepenthes nie ma żadnych luk, które mogą umożliwić atakującemu uzyskanie dostępu do podstawowego systemu. Jeśli tak się stanie, atakujący może następnie zaatakować resztę naszej sieci. Jeśli czujesz się niekomfortowo z tym ryzykiem, załóż miodową ścianę.

Konfiguracja gościa Vmware

Dla naszego gościa VMware użyjemy bezpiecznej dystrybucji Linuksa o nazwie BackTrack, którą można znaleźć na www.remote-exploit.org. Ta kompilacja Linuksa jest raczej bezpieczna i dobrze utrzymana. To, co podoba mi się w tej kompilacji, to fakt, że żadne usługi (poza bootpem) nie są domyślnie uruchamiane; dlatego żadne niebezpieczne porty nie są narażone na atak.

Używanie Nepenthes do łapania muchy

Najnowsze oprogramowanie Nepenthes można pobrać ze strony http://nepenthes.mwcollect.org.

Oprogramowanie Nepenthes wymaga pakietu adns, który można znaleźć na stronie www.chiark .greenend .org.uk/~ian/adns/. Aby zainstalować Nepenthes na BackTrack, pobierz te dwa pakiety i wykonaj następujące kroki:

BT sda1 # tar -xf adns.tar.gz
BT sda1 # cd adns-1.2/
BT adns-1.2 # ./configure
BT adns-1.2 # make
BT adns-1.2 # make install
BT adns-1.2 # cd ..
BT sda1 # tar -xf nepenthes-0.2.0.tar.gz
BT sda1 # cd nepenthes-0.2.0/
BT nepenthes-0.2.0 # ./configure
BT nepenthes-0.2.0 # make
BT nepenthes-0.2.0 # make install

UWAGA: Jeśli chcesz uzyskać bardziej szczegółowe informacje o nadchodzących exploitach i modułach Nepenthes, włącz tryb debugowania, zmieniając konfigurację Nepenthes w następujący sposób: ./configure -enable-debug-logging

Teraz, gdy masz już zainstalowany Nepenthes, możesz go dostosować, edytując plik nepenthes.conf.

BT nepenthes-0.2.0 # vi /opt/nepenthes/etc/nepenthes/nepenthes.conf

Wprowadź następujące zmiany: usuń komentarz z wtyczki submit-norman. Ta wtyczka wyśle e-mailem wszystkie przechwycone próbki do Norman Sandbox i Nepenthes Sandbox (wyjaśnione później).

// submission handler
"submitfile.so", "submit-file.conf", "" // save to disk
"submitnorman.so", "submit-norman.conf", ""
// "submitnepenthes.so", "submit-nepenthes.conf", "" // send to downloadnepenthes
Teraz musisz dodać swój adres e-mail do pliku submit-norman.conf:
BT nepenthes-0.2.0 # vi /opt/nepenthes/etc/nepenthes/submit-norman.conf w następujący sposób:

submit-norman
{
// this is the address where norman sandbox reports will be sent
email "youraddresshere@yourdomain.com";
urls ("http://sandbox.norman.no/live_4.html",
"http://luigi.informatik.uni-mannheim.de/submit.php?action= verify");
};

Na koniec możesz rozpocząć Nepenthes.

BT nepenthes-0.2.0 # cd /opt/nepenthes/bin
BT nepenthes-0.2.0 # ./nepenthes
…ASCII art truncated for brevity…
Nepenthes Version 0.2.0
Compiled on Linux/x86 at Dec 28 2006 19:57:35 with g++ 3.4.6
Started on BT running Linux/i686 release 2.6.18-rc5
[ info mgr ] Loaded Nepenthes Configuration from
/opt/nepenthes/etc/nepenthes/nepenthes.conf".
[ debug info fixme ] Submitting via http post to
http://sandbox.norman.no/live_4.html
[ info sc module ] Loading signatures from file
var/cache/nepenthes/signatures/shellcode-signatures.sc
[ crit mgr ] Compiled without support for capabilities, no way to run capabilities

Jak widać po zgrabnej grafice ASCII, Nepenthes jest otwarty i czeka na złośliwe oprogramowanie. Teraz czekaj. W zależności od otwartości Twojego dostawcy usług internetowych, ten okres oczekiwania może potrwać od kilku minut do kilku tygodni. W moim systemie po kilku dniach otrzymałem ten wynik z Nepenthes:

[ info mgr submit ] Plik 7e3b35c870d3bf23a395d72055bbba0f ma typ MS-DOS wykonywalny PE dla MS Windows (GUI) Intel 80386 32-bitowy, skompresowany UPX
[ info fixme ] Submitted file 7e3b35c870d3bf23a395d72055bbba0f to sandbox http://luigi.informatik.uni-mannheim.de/submit.php?action=verify
[ info fixme ] Submitted file 7e3b35c870d3bf23a395d72055bbba0f to sandbox http://sandbox.norman.no/live_4.html

Powrót

15.07.2021

Wstępna analiza złośliwego oprogramowania

Gdy złapiesz muchę (złośliwe oprogramowanie), możesz przeprowadzić wstępną analizę, aby określić podstawowe cechy złośliwego oprogramowania. Narzędzia wykorzystywane do analizy złośliwego oprogramowania można zasadniczo podzielić na dwie kategorie: statyczne i aktywne. Narzędzia do analizy statycznej próbują analizować plik binarny bez faktycznego wykonywania pliku binarnego. Narzędzia do analizy na żywo będą badać zachowanie pliku binarnego po jego wykonaniu.

Analiza statyczna
Istnieje wiele narzędzi do podstawowej statycznej analizy złośliwego oprogramowania. Możesz je pobrać z referencji. Omówimy niektóre z najważniejszych i przeprowadzimy analizę statyczną naszego nowo przechwyconego pliku binarnego złośliwego oprogramowania.

PEiD
Pierwszą rzeczą, którą musisz zrobić z obcym plikiem binarnym, jest określenie typu pliku. Narzędzie PEiD jest bardzo przydatne do informowania, czy plik jest plikiem binarnym systemu Windows i czy plik jest skompresowany, zaszyfrowany lub w inny sposób zmodyfikowany. Narzędzie może zidentyfikować 600 sygnatur binarnych. Wiele wtyczek zostało opracowanych w celu zwiększenia jego możliwości. Użyjemy PEiD do przeglądania naszego pliku binarnego. Potwierdziliśmy, że plik jest spakowany UPX.

UPX
Aby rozpakować plik do dalszej analizy, korzystamy z samego narzędzia UPX. Teraz, gdy plik jest już rozpakowany, możemy kontynuować analizę.

Ciągi znaków
Aby wyświetlić ciągi ASCII w pliku, uruchom polecenie ciągi. Linux jest dostarczany z poleceniem strings; wersję dla systemu Windows można pobrać z odnośnika.

C:\>strings.exe z:\7e3b35c870d3bf23a395d72055bbba0f >foo.txt
C:\>more foo.txt
< snip >
.text
.data
< snip >
InternetGetConnectedState
wininet.dll
USERPROFILE
%s%s
c:\
Gremlin
Soft%sic%sf%sind%ss%sr%sVe%so%sun
ware\M

ww%sic%ss%s%so%c

KERNEL32.DLL
ADVAPI32.dll
GetSystemTime
SetFileAttributesA
GetFileAttributesA
DeleteFileA
CopyFileA
CreateMutexA
GetLastError
< snip >
lstrlenA
Sleep
< snip >
ReadFile
CreateFileA
< snip >
RegOpenKeyExA
RegCloseKey
RegSetValueExA
wsprintfA
!"#&(+,-./0123456789=>?@ABCDPQ

Jak widać powyżej, plik binarny wykonuje kilka wywołań interfejsu API systemu Windows dla katalogów, plików, rejestrów, wywołań sieciowych i tak dalej. Zaczynamy poznawać podstawowe funkcje robak:

•  Aktywność sieciowa
• o Aktywność plików (wyszukiwanie, usuwanie i zapisywanie)
•  Działalność rejestru
•  Sprawdzanie czasu systemowego i czekanie (uśpienie) przez pewien okres some
•  Ustaw muteks, aby w danym momencie działała tylko jedna kopia robaka

Inżynieria odwrotna

Ostateczną formą analizy statycznej jest inżynieria odwrotna; zachowamy ten temat do następnej części.

Analiza na żywo

Przejdziemy teraz do fazy analizy na żywo. Najpierw musimy podjąć pewne środki ostrożności.
Powrót

16.07.2021

Środki ostrożności

Ponieważ mamy zamiar uruchomić plik binarny w żywym systemie, musimy upewnić się, że zawieramy wirusa w naszym systemie testowym i nie przyczyniamy się do problemu ze złośliwym oprogramowaniem, przekształcając nasz system testowy w zainfekowany skaner Internetu. użyje naszego sprawdzonego oprogramowania VMware do powstrzymania robaka. Po przesłaniu pliku binarnego i wszystkich potrzebnych nam narzędzi do dziewiczej wersji systemu Windows XP wprowadzamy następujące zmiany ustawień, aby uwzględnić złośliwe oprogramowanie w systemie: Jako kolejny środek ostrożności zaleca się zmianę ustawień sieci lokalnej wirtualnego system operacyjny gościa do jakiejś nieprawidłowej sieci. Ten środek ostrożności ochroni system hosta przed zainfekowaniem, jednocześnie umożliwiając monitorowanie aktywności sieciowej. Z drugiej strony, korzystasz z zapory ogniowej i ochrony antywirusowej na swoim hoście, prawda?

Powtarzalny proces

Podczas analizy na żywo będziesz korzystać z funkcji migawki VMware i powtarzać kilka testów w kółko, dopóki nie zorientujesz się, jak zachowuje się plik binarny. Poniżej przedstawiono proces analizy na żywo:

•  Skonfiguruj narzędzia do monitorowania plików, rejestru i sieci (ustal punkt odniesienia).
•  Zapisz migawkę za pomocą VMware.
•  Uruchom podejrzany plik binarny.
•  Sprawdź narzędzia pod kątem zmian systemowych w stosunku do stanu wyjściowego.
•  Interakcja z binarnymi fałszywymi serwerami DNS, e-mail i IRC zgodnie z wymaganiami.
•  Odwróć migawkę i powtórz proces.

UWAGA: Musieliśmy umieścić rozszerzenie pliku .exe w pliku binarnym, aby go wykonać.

Regshot

Przed wykonaniem pliku binarnego zrobimy migawkę rejestru za pomocą Regshota. Po wykonaniu pliku binarnego, zrobimy drugą migawkę, klikając przycisk drugiego ujęcia, a następnie porównamy dwie migawki, klikając przycisk porównuj. Z tych danych wyjściowych widzimy, że plik binarny umieści wpis w rejestrze HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\. Nazwa klucza Gremlin wskazuje na plik C:\WINDOWS\System32\intrenat.exe. Jest to metoda zapewniająca, że złośliwe oprogramowanie przetrwa ponowne uruchomienie, ponieważ wszystko w tym rejestrze będzie uruchamiane automatycznie po ponownym uruchomieniu.

FileMon

Program FileMon jest bardzo przydatny w wyszukiwaniu zmian w systemie plików. Dodatkowo wszelkie wyszukiwania wykonywane przez plik binarny zostaną wykryte i zarejestrowane. To narzędzie jest dość głośne i zbiera setki zmian plików przez pozornie bezczynny system Windows. Dlatego pamiętaj, aby wyczyścić narzędzie przed wykonaniem pliku binarnego i "zatrzymać przechwytywanie" około 10 sekund po uruchomieniu narzędzia. Po znalezieniu procesu złośliwego oprogramowania w dziennikach możesz filtrować ten proces, aby odciąć się od szumu. W naszym przypadku po uruchomieniu pliku binarnego i przejrzeniu logów widzimy dwa pliki zapisane na dysku twardym: intrenat.exe i sync-src-1.00.tbz. Liczba zmian w plikach, które pojedynczy plik binarny może wykonać w ciągu kilku sekund, może być przytłaczająca. Aby pomóc w analizie, zapiszemy wynik do płaskiego pliku tekstowego i przeanalizujemy go ręcznie. Wyszukując tag CREATE, mogliśmy zobaczyć jeszcze więcej miejsc docelowych pliku sync-src-1.00.tbz

2334 3:12:40 PM 7e3b35c870d3bf2:276 CREATE C:\sync-src-1.00.tbz
SUCCESS
Options: OverwriteIf Access: All
2338 3:12:41 PM 7e3b35c870d3bf2:276 CREATE C:\WINDOWS\sync-src-1.00.tbz
SUCCESS Options: OverwriteIf Access: All
2344 3:12:41 PM 7e3b35c870d3bf2:276 CREATE C:\WINDOWS\System32\sync-src-
1.00.tbz SUCCESS Options: OverwriteIf Access: All
2351 3:12:41 PM 7e3b35c870d3bf2:276 CREATE
C:\DOCUME~1\Student\LOCALS~1\Temp\sync-src-1.00.tbz SUCCESS
Options: OverwriteIf Access: All
2355 3:12:41 PM 7e3b35c870d3bf2:276 CREATE C:\Documents and Settings\Student\sync-src-1.00.tbz SUCCESS Options: OverwriteIf Access:
All

Co to jest plik sync-src-1.00.tbz i dlaczego jest kopiowany do kilku katalogów? Po dalszej inspekcji okazuje się, że jest to kod źródłowy jakiegoś programu. Hmm, to podejrzane; dlaczego atakujący miałby chcieć, aby kod źródłowy został umieszczony w całym systemie, szczególnie w lokalizacjach profilu użytkownika? Zaglądając do tego archiwum, znajdujemy w pliku main.c następujący ciąg: "sync.c, v 0.1 2004/01". Szybkie sprawdzenie Google ujawnia, że te pliki są kodem źródłowym wirusa MyDoom. Możesz również zobaczyć w kodzie źródłowym dołączenie biblioteki massmail.h. Ponieważ nie widzimy żadnych wywołań API wiadomości e-mail, wygląda na to, że nasz plik binarny nie jest skompilowany ze źródła; zamiast tego zawiera źródło jako ładunek. To naprawdę dziwne. Być może atakujący stara się zapewnić, że nie jest jedynym, który posiada kod źródłowy tego wirusa MyDoom. Być może uważa, że rozpowszechnianie go wraz z tym drugim robakiem utrudni organom ścigania prześledzenie jego kodu.

Eksplorator procesów

Narzędzie Process Explorer jest bardzo przydatne w badaniu uruchomionych procesów. Korzystając z tego narzędzia, możemy zobaczyć, czy nasz proces odradza inne procesy. W tym przypadku tak nie jest. Widzimy jednak wiele wątków, które prawdopodobnie są używane do dostępu do sieci, dostępu do rejestru lub dostępu do plików. Kolejną świetną cechą tego narzędzia są właściwości procesu, które zawierają listę gniazd sieciowych. To narzędzie jest również przydatne do wyszukiwania ciągów zawartych w pliku binarnym.

TCPView

Narzędzie TCPView może służyć do sprawdzania aktywności sieciowej. Jak widać, złośliwe oprogramowanie próbuje przeskanować naszą podsieć w poszukiwaniu innych zainfekowanych komputerów na porcie 3127. W tym momencie możemy wyszukać w Google "TCP 3127" i dowiedzieć się, że port jest używany przez robaka MyDoom jako backdoor. Przy naszej ograniczonej wiedzy w tym momencie wydaje się, że nasze złośliwe oprogramowanie łączy się z istniejącymi ofiarami zainfekowanymi przez MyDoom i upuszcza kopię kodu źródłowego MyDoom na tych maszynach.

Pakiet analityka złośliwego oprogramowania (iDefense)

Laboratoria iDefense oferują świetny zestaw narzędzi o nazwie Malware Analyst Pack (MAP). W MAP zawarte są następujące narzędzia. Chociaż nie są one szczególnie przydatne w przypadku tego złośliwego oprogramowania, mogą okazać się przydatne w przyszłości. Na przykład, jeśli analizowane złośliwe oprogramowanie próbuje wysłać e-mail, połączyć się z serwerem IRC lub zalać serwer sieciowy, narzędzia te mogą bezpiecznie stymulować złośliwe oprogramowanie i wydobywać ważne informacje.

ShellExt : Cztery rozszerzenia eksploratora, które zapewniają menu kontekstowe prawego przycisku myszy

socketTool: Ręczny klient TCP do sprawdzania funkcjonalności

MailPot: Pot przechwytywania serwera poczty

fakeDNS: fałszuje odpowiedzi DNS na kontrolowane adresy IP

sniff_hit : sniffer HTTP, IRC i DNS

sclog : Aplikacja do badania i analizy kodu Shellcode

IDCDumpFix : Pomaga w szybkiej inżynierii wstecznej spakowanych aplikacji

Shellcode2EXE : osadza wiele formatów kodu powłoki w łusce .exe

GDIProcs : Wykrywa ukryty proces, patrząc w DISharedHandleTable
Powrót

17.07.2021

Technologia piaskownicy Norman

Najlepsze zostawiliśmy na koniec. Jak widzieliście wcześniej w sekcji Nepenthes, skonfigurowaliśmy Nepenthes, aby automatycznie zgłaszał pliki binarne do Norman Sandbox. Witryna Norman Sandbox odbiera plik binarny i przeprowadza automatyczną analizę w celu wykrycia zawartych plików, zmodyfikowanych kluczy rejestru, aktywności sieciowej i podstawowego wykrywania znanych wirusów. Piaskownica faktycznie symuluje wykonanie pliku binarnego w środowisku piaskownicy (bezpiecznym), aby wyodrębnić dane kryminalistyczne. Krótko mówiąc, piaskownice robią wszystko, co robiliśmy, a nawet więcej, w sposób zautomatyzowany i dostarczają nam raport w ciągu kilku sekund. Raport jest dość imponujący i oferuje bezprecedensowe informacje "pierwszego przejścia", które w ciągu kilku sekund podadzą nam podstawowe dane na temat przechwyconego pliku binarnego. Zgodnie z oczekiwaniami, po wcześniejszym wyjściu z Nepenthes otrzymaliśmy następujący e-mail z adresu sandbox@eunet.no:

Your message ID (for later reference): 20070112-3362
Hello,
Thanks for taking the time to submit your samples to the Norman Sandbox
Information Center.
< snip >
nepenthes-7e3b35c870d3bf23a395d72055bbba0f-index.html : W32/Doomjuice.A
(Signature: Doomjuice.A)
[ General information ]
* Decompressing UPX.
* File length: 36864 bytes.
* MD5 hash: 7e3b35c870d3bf23a395d72055bbba0f.
[ Changes to filesystem ]
* Creates file C:\WINDOWS\SYSTEM32\intrenat.exe.
* Deletes file C:\WINDOWS\SYSTEM32\intrenat.exe.
* Creates file C:\sync-src-1.00.tbz.
* Creates file N:\sync-src-1.00.tbz.
* Creates file C:\WINDOWS\sync-src-1.00.tbz.
* Creates file C:\WINDOWS\SYSTEM32\sync-src-1.00.tbz.
* Creates file C:\WINDOWS\TEMP\sync-src-1.00.tbz.
* Creates file C:\DOCUME~1\SANDBOX\sync-src-1.00.tbz.
[ Changes to registry ]
* Creates value "Gremlin"="C:\WINDOWS\SYSTEM32\intrenat.exe" in key
HKLM\Software\Microsoft\Windows\CurrentVersion\Run".
[ Network services ]
* Looks for an Internet connection.
* Connects to "192.168.0.0" on port 3127 (TCP).
* Connects to "CONFIGURED_DNS" on port 3127 (TCP).
* Connects to "192.168.0.2" on port 3127 (TCP).
* Connects to "192.168.0.3" on port 3127 (TCP).
* Connects to "192.168.0.4" on port 3127 (TCP).
< snip >
* Connects to "230.90.214.20" on port 3127 (TCP).
* Connects to "230.90.214.21" on port 3127 (TCP).
* Connects to "230.90.214.22" on port 3127 (TCP).
* Connects to "230.90.214.23" on port 3127 (TCP).
[ Process/window information ]
* Creates a mutex sync-Z-mtx_133.
* Will automatically restart after boot (I'll be back…).
[ Signature Scanning ]
* C:\WINDOWS\SYSTEM32\intrenat.exe (36864 bytes) : Doomjuice.A.
< snip >
(C) 2004-2006 Norman ASA. All Rights Reserved.
The material presented is distributed by Norman ASA as an information source only.

Wow, ten raport zawiera całkiem przydatne informacje, potwierdza wszystkie nasze ustalenia i wskazuje, że przechwyciliśmy wariant robaka Doomjuice.A (który wykorzystuje istniejące ofiary MyDoom). Możemy zobaczyć podstawowe kroki, które wykonuje robak. W rzeczywistości w wielu przypadkach raport piaskownicy wystarczy i uchroni nas przed ręczną analizą złośliwego oprogramowania.

UWAGA: Być może zauważyłeś, że pliki konfiguracyjne Nepenthes również wysyłają kopię złośliwego oprogramowania do piaskownicy Nepenthes pod adresem luigi.informatik.unimannheim. de. Możesz usunąć to miejsce docelowe z pliku submit-norman.conf, jeśli chcesz.

Co odkryliśmy?

Wygląda na to, że przechwycony plik binarny rzeczywiście był formą złośliwego oprogramowania zwanego robakiem. Szkodnik ten został sklasyfikowany przez producentów wirusów jako pierwszy z rodziny robaków Doomjuice (Doomjuice.A). Wydaje się, że celem robaka jest łączenie się z już zainfekowanymi ofiarami MyDooma. Po pierwsze, tworzy muteks, aby zapewnić, że tylko jedna kopia złośliwego oprogramowania jest uruchamiana w danym momencie. Następnie chroni się, tworząc wpis rejestru w celu ponownego uruchomienia. Następnie umieszcza kopię kodu źródłowego wirusa MyDoom w kilku miejscach w systemie. Następnie robak rozpoczyna metodyczne skanowanie w poszukiwaniu innych zainfekowanych ofiar MyDoom (które nasłuchują na porcie TCP 3127).

UWAGA: Bez inżynierii wstecznej nie jesteś w stanie określić wszystkich funkcji binarnych. W tym przypadku, co można potwierdzić w Google, okazuje się, że na microsoft.com wbudowany jest atak typu denial-of-service, ale nie byliśmy w stanie go wykryć za pomocą samej analizy statycznej i na żywo. Atak DoS jest uruchamiany tylko w określonych sytuacjach.
Powrót

18.07.2021

Hakowanie złośliwego oprogramowania

Dlaczego zawracamy sobie głowę omawianiem złośliwego oprogramowania w książce o hakowaniu? Jednym z powodów jest to, że złośliwe oprogramowanie jest dziś tak wszechobecne, że praktycznie nie można go uniknąć. Jeśli wiesz cokolwiek na temat bezpieczeństwa komputera, prawdopodobnie zostaniesz poproszony o poradę, jak radzić sobie z niektórymi problemami związanymi ze złośliwym oprogramowaniem - od tego, jak go uniknąć, po sposób czyszczenia po infekcji. Złośliwe oprogramowanie do inżynierii wstecznej może pomóc w zrozumieniu następujących kwestii:

•  W jaki sposób złośliwe oprogramowanie instaluje się w celu opracowania procedur deinstalacji.
•  Pliki powiązane z aktywnością złośliwego oprogramowania, które pomagają w czyszczeniu i wykrywaniu.
•  Z jakim hostem komunikuje się złośliwe oprogramowanie, aby pomóc w śledzeniu złośliwego oprogramowania do jego źródła. Może to obejmować wykrywanie haseł lub innych mechanizmów uwierzytelniania używanych przez złośliwe oprogramowanie.
•  Zdolność złośliwego oprogramowania do zrozumienia aktualnego stanu wiedzy lub porównania z istniejącymi rodzinami złośliwego oprogramowania.
•  Jak komunikować się ze złośliwym oprogramowaniem jako sposób na zrozumienie, jakie informacje zebrało złośliwe oprogramowanie lub jako sposób wykrywania dodatkowych infekcji.
•  Luki w złośliwym oprogramowaniu, które mogą pozwolić na zdalne usunięcie złośliwego oprogramowania na zainfekowanych maszynach.

Powrót

19.07.2021

Trendy w złośliwym oprogramowaniu

Jak każda inna technologia, złośliwe oprogramowanie staje się coraz bardziej wyrafinowane. Twórcy złośliwego oprogramowania starają się, aby ich narzędzia były niewykrywalne. Praktycznie każda znana technika ofensywna została włączona do złośliwego oprogramowania, aby utrudnić obronę przed nią. Chociaż rzadko zdarza się, aby całkowicie nowe techniki pojawiały się jako pierwsze w złośliwym oprogramowaniu, twórcy złośliwego oprogramowania szybko adoptują nowe techniki po ich upublicznieniu i szybko dostosowują się w obliczu nowych technik obronnych.

Wbudowane komponenty

Twórcy złośliwego oprogramowania często starają się dostarczyć kilka komponentów w jednym ładunku złośliwego oprogramowania. Takie dodatkowe komponenty mogą obejmować sterowniki na poziomie jądra przeznaczone do ukrywania obecności złośliwego oprogramowania oraz komponenty klienta i serwera złośliwego oprogramowania do obsługi eksfiltracji danych lub świadczenia usług proxy przez zainfekowany komputer. Jedną z technik osadzania tych dodatkowych komponentów w złośliwym oprogramowaniu Windows jest wykorzystanie sekcji zasobów w plikach binarnych systemu Windows.

UWAGA: Sekcja zasobów w pliku binarnym środowiska Windows PE jest przeznaczona do przechowywania dostosowywalnych obiektów blob danych, które można modyfikować niezależnie od kodu programu. Zasoby często zawierają mapy bitowe dla ikon programów, szablony okien dialogowych i tabele ciągów, które ułatwiają internacjonalizację programu poprzez uwzględnienie ciągów opartych na alternatywnych zestawach znaków.

System Windows oferuje możliwość osadzania niestandardowych zasobów binarnych w sekcji zasobów. Twórcy złośliwego oprogramowania wykorzystali tę możliwość, aby osadzić całe pliki binarne, takie jak dodatkowe pliki wykonywalne lub sterowniki urządzeń, w sekcji zasobów. Gdy złośliwe oprogramowanie początkowo się uruchamia, wykorzystuje funkcję LoadResource, aby wyodrębnić osadzony zasób ze złośliwego oprogramowania przed zapisaniem go na lokalnym dysku twardym.

Korzystanie z szyfrowania

W przeszłości nierzadko zdarzało się, że złośliwe oprogramowanie nie wykorzystywało żadnego szyfrowania, aby utrudnić analizę. Z biegiem czasu autorzy złośliwego oprogramowania wskoczyli na modę szyfrowania jako sposób ukrywania swoich działań, niezależnie od tego, czy chcą chronić komunikację, czy też starają się zapobiec ujawnieniu zawartości pliku binarnego. Algorytmy szyfrowania obserwowane w dzikim zakresie, od prostych kodowań XOR do kompaktowych szyfrów, takich jak Tiny Encryption Algorithm (TEA), a czasami bardziej wyrafinowanych, takich jak DES. Konieczność samowystarczalności ogranicza złośliwe oprogramowanie do korzystania z szyfrów symetrycznych, co oznacza, że klucze deszyfrujące muszą być zawarte w samym złośliwym oprogramowaniu. Twórcy złośliwego oprogramowania często próbują ukryć obecność swoich kluczy poprzez dalsze kodowanie lub dzielenie kluczy za pomocą łatwo odwracalnego, ale miejmy nadzieję, trudnego do rozpoznania procesu. Odzyskiwanie kluczy odszyfrowywania jest niezbędnym krokiem do inżynierii wstecznej dowolnego zaszyfrowanego złośliwego oprogramowania.

Techniki ukrywania przestrzeni użytkownika

Zaobserwowano, że złośliwe oprogramowanie podejmuje dowolną liczbę kroków w celu ukrycia swojej obecności w zainfekowanym systemie. Ukrywając się na widoku w bałaganie katalogu systemu Windows pod nazwami, które użytkownik może uznać za należące do legalnych komponentów systemu operacyjnego, malware ma nadzieję pozostać niewykryte. Alternatywnie, złośliwe oprogramowanie może zdecydować się na utworzenie własnego katalogu instalacyjnego głęboko w hierarchii programu instalacyjnego, próbując ukryć się przed ciekawskimi użytkownikami. Istnieją również różne techniki uniemożliwiające zainstalowanym programom antywirusowym wykrycie nowo zainfekowanego komputera. Prymitywną, ale skuteczną metodą jest zmodyfikowanie pliku hosts systemu w celu dodania wpisów dotyczących hostów, o których wiadomo, że są powiązane z aktualizacjami antywirusowymi.

UWAGA : Plik hosts to prosty plik tekstowy, który zawiera mapowania adresu IP na nazwy hostów. Plik hosts jest zwykle sprawdzany przed wykonaniem wyszukiwania DNS w celu rozwiązania nazwy hosta na adres IP. Jeśli nazwa hosta zostanie znaleziona w pliku hosts, używany jest powiązany adres IP, co oszczędza czas potrzebny na wyszukiwanie DNS. W systemach Windows plik hosts można znaleźć w katalogu systemowym pod system32\drivers\etc. W systemach Unix plik hosts można znaleźć w /etc/hosts.

Modyfikacje idą tak daleko, że wstawiają dużą liczbę znaków powrotu karetki na końcu istniejących wpisów hosta przed dołączeniem szkodliwych wpisów hosta w nadziei, że przypadkowy obserwator nie przewinie w dół i nie zauważy dołączonych wpisów. Powodując niepowodzenie aktualizacji oprogramowania antywirusowego, nowe generacje złośliwego oprogramowania mogą pozostać niewykryte przez długi czas. Typowi użytkownicy mogą nie zauważyć, że ich oprogramowanie antywirusowe nie zaktualizowało się automatycznie, ponieważ ostrzeżenia o tym fakcie nie są w ogóle generowane lub są po prostu odrzucane przez nieświadomych użytkowników.

Korzystanie z technologii rootkit

Autorzy złośliwego oprogramowania coraz częściej sięgają po techniki rootkit, aby ukryć obecność swojego złośliwego oprogramowania. Komponenty rootkita mogą być dostarczane jako komponenty osadzone w początkowym ładunku złośliwego oprogramowania, jak opisano wcześniej, lub pobierane jako dodatkowe etapy po początkowej infekcji złośliwym oprogramowaniem. Usługi implementowane przez komponenty rootkita obejmują między innymi ukrywanie procesów, ukrywanie plików, rejestrowanie kluczy i ukrywanie gniazd sieciowych.

Środki trwałe

Większość złośliwego oprogramowania podejmuje kroki w celu zapewnienia, że będzie nadal działać nawet po ponownym uruchomieniu systemu. Osiągnięcie pewnego stopnia trwałości eliminuje konieczność ponownego infekowania komputera za każdym razem, gdy jest on ponownie uruchamiany. Podobnie jak w przypadku innych zachowań złośliwego oprogramowania, sposób, w jaki osiąga się trwałość, z czasem stał się bardziej wyrafinowany. Najbardziej podstawowe formy trwałości są osiągane przez dodawanie poleceń do skryptów startowych systemu, które powodują wykonanie złośliwego oprogramowania. W systemach Windows ewoluowało to do dokonywania określonych modyfikacji rejestru w celu osiągnięcia tego samego efektu.

UWAGA : Rejestr systemu Windows to zbiór wartości konfiguracji systemu, które szczegółowo opisują konfigurację sprzętu i oprogramowania dla danego komputera. Rejestr zawiera klucze, które luźno odpowiadają katalogom; wartości, które luźno utożsamiają się z plikami; oraz dane, które luźno odpowiadają zawartości tych plików. Określając wartość klucza rejestru HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, można na przykład nazwać program uruchamiany przy każdym logowaniu użytkownika.

Inne manipulacje w rejestrze obejmują instalowanie komponentów złośliwego oprogramowania jako rozszerzeń do powszechnie używanego oprogramowania, takiego jak Eksplorator Windows lub Microsoft Internet Explorer. Ostatnio złośliwe oprogramowanie zaczęło instalować się jako usługa systemu operacyjnego lub sterownik urządzenia, dzięki czemu składniki złośliwego oprogramowania działają na poziomie jądra i są uruchamiane podczas uruchamiania systemu
Powrót

20.07.2021

Oderwanie od zaciemnienia cebuli

Jedną z najbardziej rozpowszechnionych cech współczesnego złośliwego oprogramowania jest zaciemnianie. Zaciemnianie to proces modyfikowania czegoś, aby ukryć jego prawdziwy cel. W przypadku złośliwego oprogramowania zaciemnianie jest wykorzystywane do tego, aby zautomatyzowana analiza złośliwego oprogramowania była prawie niemożliwa i aby maksymalnie udaremnić ręczną analizę. Istnieją dwa podstawowe sposoby radzenia sobie z zaciemnianiem. Pierwszym sposobem jest po prostu zignorowanie go. W takim przypadku jedyną realną opcją zrozumienia natury złośliwego oprogramowania jest obserwowanie jego zachowania w starannie oprzyrządowanym środowisku, jak opisano w poprzednim rozdziale. Drugim sposobem radzenia sobie z zaciemnianiem jest podjęcie kroków w celu usunięcia zaciemnienia i ujawnienia oryginalnego "odciemnionego" programu, który można następnie przeanalizować za pomocą tradycyjnych narzędzi, takich jak deasemblery i debuggery. Oczywiście autorzy złośliwego oprogramowania rozumieją, że analitycy będą próbowali przełamać wszelkie zaciemnianie i w rezultacie projektują swoje złośliwe oprogramowanie z funkcjami mającymi na celu utrudnienie odtajnienia. Odciemnienie nigdy nie może być naprawdę niemożliwe, ponieważ złośliwe oprogramowanie musi ostatecznie działać na docelowym procesorze; zawsze będzie można obserwować sekwencję instrukcji wykonywanych przez złośliwe oprogramowanie przy użyciu kombinacji narzędzi sprzętowych i programowych. Najprawdopodobniej celem autora szkodliwego oprogramowania jest po prostu utrudnienie analizy na tyle, aby otworzyło się okno możliwości dla szkodliwego oprogramowania, w którym może działać bez wykrycia.
Powrót

21.07.2021

Podstawy pakowania

Narzędzia używane do zaciemniania skompilowanych programów binarnych są ogólnie nazywane pakerami. Termin ten wynika z faktu, że jedną z technik zaciemniania programu binarnego jest po prostu skompresowanie programu, ponieważ skompresowane dane wydają się wyglądać znacznie bardziej losowo i na pewno nie przypominają języka maszynowego. Aby program rzeczywiście działał na komputerze docelowym, musi pozostać prawidłowym plikiem wykonywalnym dla platformy docelowej. Standardowym podejściem przyjmowanym przez większość programów pakujących jest osadzenie kodu pośredniczącego rozpakowywania w spakowanym programie i zmodyfikowanie punktu wejścia programu tak, aby wskazywał na ten kod rozpakowujący. Po wykonaniu spakowanego programu system operacyjny odczytuje nowy punkt wejścia i inicjuje wykonanie spakowanego programu na etapie rozpakowywania. Zadaniem kodu pośredniczącego rozpakowywania jest przywrócenie spakowanego programu do jego pierwotnego stanu, a następnie przekazanie kontroli przywracanemu programowi. Pakowacze różnią się znacznie stopniem zaawansowania. Najbardziej podstawowe programy pakujące po prostu wykonują kompresję kodu i sekcji danych pliku binarnego. Bardziej wyrafinowane pakery nie tylko kompresują, ale także wykonują pewien stopień szyfrowania sekcji pliku binarnego. Wreszcie, wiele programów pakujących podejmie kroki, aby zaciemnić tabelę importu pliku binarnego, kompresując lub szyfrując listę funkcji i bibliotek, od których zależy plik binarny. W tym ostatnim przypadku kod pośredniczący rozpakowywania musi być wystarczająco wyrafinowany, aby wykonać wiele funkcji dynamicznego programu ładującego, w tym ładowanie dowolnych bibliotek, które będą wymagane przez rozpakowany plik binarny i uzyskanie adresów wszystkich wymaganych funkcji w tych bibliotekach. Najbardziej oczywistym sposobem na to jest wykorzystanie dostępnych funkcji systemowego API, takich jak funkcje Windows LoadLibrary i GetProcAddress. Każda z tych funkcji wymaga danych wejściowych ASCII w celu określenia nazwy biblioteki lub funkcji, pozostawiając plik binarny podatny na analizę ciągów. Bardziej zaawansowane programy rozpakowujące wykorzystują techniki łączenia zapożyczone ze społeczności hakerów, z których wiele jest szczegółowo opisanych w doskonałej pracy Matta Millera na temat zrozumienia shellcode systemu Windows. Co pakowacze mają nadzieję osiągnąć? Pierwszą, najbardziej oczywistą rzeczą, jaką osiągają pakery, jest to, że pokonują analizę ciągów programu binarnego.

UWAGA: Narzędzie strings jest przeznaczone do skanowania pliku w poszukiwaniu sekwencji kolejnych znaków ASCII lub Unicode i wyświetlania użytkownikowi ciągów przekraczających określoną minimalną długość. ciągi mogąbyćużyte do szybkiego poznania ciągów, które są manipulowane przez skompilowany program, jak również bibliotek i funkcji, do których program może się odwoływać, ponieważ takie nazwy bibliotek i funkcji są zwykle przechowywane jako ciągi ASCII w tabeli importu programu .

strings nie jest szczególnie skutecznym narzędziem do inżynierii wstecznej, ponieważ obecność określonego ciągu w pliku binarnym w żaden sposób nie sugeruje, że ciąg jest kiedykolwiek używany. Prawdziwa analiza behawioralna to jedyny sposób na ustalenie, czy dany ciąg jest kiedykolwiek używany. Na marginesie, brak jakichkolwiek ciągów wyjściowych jest często szybkim wskaźnikiem, że plik wykonywalny został w jakiś sposób spakowany.
Powrót

22.07.2021

Rozpakowywanie plików binarnych

Zanim zaczniesz analizować zachowanie złośliwego oprogramowania, najprawdopodobniej będziesz musiał je rozpakować. Podejścia do rozpakowywania różnią się w zależności od konkretnego zestawu umiejętności, ale zwykle kilka pytań jest przydatnych, aby odpowiedzieć przed rozpoczęciem walki o rozpakowanie czegoś.

Czy to złośliwe oprogramowanie jest spakowane?

Jak rozpoznać, czy plik binarny został spakowany? Nie ma jednej najlepszej odpowiedzi. Narzędzia takie jak PEiD mogą zidentyfikować, czy plik binarny został spakowany przy użyciu znanego pakera, ale nie są zbyt pomocne w przypadku użycia nowego lub zmutowanego pakera. Jak wspomniano wcześniej, łańcuchy mogą dać wyobrażenie, czy plik binarny został spakowany. Typowe łańcuchy wyjściowe w spakowanym pliku binarnym będą składały się głównie ze śmieci wraz z nazwami bibliotek i funkcji wymaganych przez rozpakowujący. Częściowa lista ciągów wyodrębnionych z próbki robaka Sobig jest pokazana poniżej:

!This program cannot be run in DOS mode.
Rich
.shrink
.shrink
.shrink
.shrink
'!Vw@p
KMQl\PD%
N2]B
<…>
cj}D
wQfYX
kernel32.dll
user32.dll
GetModuleHandleA
MessageBoxA
D}uL
:V&&
tD4w
XC001815d
XC001815d
XC001815d
XC001815d
XC001815d

Te ciągi znaków mówią nam bardzo niewiele. Rzeczy, które możemy zobaczyć, obejmują nazwy sekcji wyodrębnione z nagłówków PE (.shrink). Istnieje wiele narzędzi, które są w stanie zrzucić różne pola z nagłówków plików binarnych. W tym przypadku nazwy sekcji są niestandardowe dla wszystkich znanych nam kompilatorów, co wskazuje, że prawdopodobnie miało miejsce pewne przetwarzanie końcowe (takie jak pakowanie) pliku binarnego. Narzędzie objdump może być użyte do łatwego wyświetlenia większej ilości informacji o pliku binarnym i jego sekcjach, jak pokazano poniżej:

$ objdump -fh sobig.bin
sobig.bin: file format pei-i386
architecture: i386, flags 0x0000010a:
EXEC_P, HAS_DEBUG, D_PAGED
start address 0x0041ebd6
Sections:
Idx Name Size VMA LMA File off Algn
0 .shrink 0000c400 00401000 00401000 00001000 2**2
CONTENTS, ALLOC, LOAD, DATA
1 .shrink 00001200 00416000 00416000 0000d400 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .shrink 00001200 00419000 00419000 0000e600 2**2
CONTENTS, ALLOC, LOAD, DATA
3 .shrink 00002200 0041d000 0041d000 0000f800 2**2
CONTENTS, ALLOC, LOAD, DATA

Warto zauważyć w tym wykazie, że wszystkie sekcje mają tę samą nazwę, co jest bardzo nietypowe, oraz że punkt wejścia programu (0x0041ebd6) znajduje się w czwartej sekcji (obejmującej 0x0041d000-0x0041f200), co jest również bardzo nietypowe, ponieważ sekcja wykonywalna (zwykle .text) jest najczęściej pierwszą sekcją w pliku binarnym. Czwarta sekcja prawdopodobnie zawiera odcinek rozpakowujący, który rozpakuje pozostałe trzy sekcje przed przekazaniem sterowania na adres w pierwszej sekcji. Inną rzeczą, na którą należy zwrócić uwagę z danych wyjściowych ciągów, jest to, że plik binarny wydaje się importować tylko dwie biblioteki (kernel32.dll i user32.dll), a z tych bibliotek importuje tylko dwie funkcje GetModuleHandleA i MessageBoxA). To zaskakująco mała liczba funkcji dla dowolnego programu do zaimportowania. Spróbuj uruchomić dumpbin na dowolnym pliku binarnym, a zazwyczaj otrzymasz kilka ekranów pełnych informacji dotyczących importowanych bibliotek i funkcji. Wystarczy powiedzieć, że ten konkretny plik binarny wydaje się być spakowany, a proste narzędzie, takie jak łańcuchy, wystarczyło, aby było to dość oczywiste.
Powrót

23.07.2021

Jak spakowano to złośliwe oprogramowanie?

Teraz, gdy już zidentyfikowałeś spakowany binarny i twój puls zaczyna rosnąć, warto spróbować dokładnie określić, w jaki sposób binarny został spakowany. "Dlaczego?" możesz zapytać. W większości przypadków nie będziesz pierwszą osobą, która napotka konkretny schemat pakowania. Jeśli potrafisz zidentyfikować kilka kluczowych cech schematu pakowania, możesz być w stanie wyszukać i wykorzystać narzędzia lub algorytmy, które zostały opracowane do rozpakowywania analizowanego pliku binarnego. Wielu pakowaczy pozostawia charakterystyczne znaki dotyczące swojej tożsamości. Niektóre programy pakujące wykorzystują dobrze znane nazwy sekcji, podczas gdy inne pozostawiają ciągi identyfikujące w spakowanym pliku binarnym. Jeśli masz szczęście, natrafisz na spakowany plik, dla którego istnieje automatyczny program rozpakowujący. Pakowacz UPX jest dobrze znany jako paker, który oferuje opcję cofania. Przynajmniej ta opcja jest dobrze znana inżynierom odwrotnym. Co zaskakujące, duża liczba autorów złośliwego oprogramowania nadal wykorzystuje UPX jako preferowany program pakujący (być może dlatego, że jest bezpłatny i łatwy do uzyskania). Fakt, że UPX można łatwo odwrócić, zrodził cały rynek wtórny narzędzi do postprocessingu UPX zaprojektowanych do modyfikowania plików generowanych przez UPX na tyle, aby UPX odmówił ich rozpakowania. Narzędzia takie jak plik (który ma podstawową zdolność identyfikacji pakera), PEiD i Google są najlepszym sposobem na dokładne określenie, które narzędzie pakujące mogło zostać użyte do zaciemnienia określonego pliku binarnego.
Powrót

24.07.2021

Jak odzyskać oryginalny plik binarny?

W idealnym świecie, gdy raz (jeśli?) zidentyfikujesz narzędzie używane do spakowania pliku binarnego, będziesz w stanie szybko zlokalizować narzędzie lub procedurę automatycznego rozpakowywania tego pliku binarnego. Niestety świat nie jest idealnym miejscem i częściej niż chcesz, będziesz musiał samodzielnie przebić się przez proces rozpakowywania. Istnieje kilka różnych podejść do rozpakowywania, z których każde ma swoje zalety i wady.

Rozpakowanie Uruchom i Zrzuć

W przypadku większości spakowanych programów pierwsza faza wykonania obejmuje rozpakowanie oryginalnego programu w pamięci, załadowanie wymaganych bibliotek i wyszukanie adresów importowanych funkcji. Po wykonaniu tych czynności obraz pamięci programu bardzo przypomina jego oryginalną, rozpakowaną wersję. Jeśli migawkę obrazu pamięci można w tym momencie zrzucić do pliku, plik ten można przeanalizować tak, jakby nigdy nie miało miejsca pakowanie. Zaletą tej techniki jest to, że wbudowany odcinek rozpakowania jest wykorzystywany do rozpakowywania za Ciebie. Najtrudniejszą częścią jest dokładne określenie, kiedy wykonać migawkę pamięci. Migawka musi zostać wykonana po rozpakowaniu i zanim program zdąży zatrzeć ślady. Jest to jedna z wad takiego podejścia do rozpakowywania. Inną, być może bardziej znaczącą wadą, jest to, że złośliwe oprogramowanie musi mieć możliwość działania, aby mogło się samo rozpakować. Aby to zrobić bezpiecznie, środowisko piaskownicy należy skonfigurować zgodnie z opisem w sekcji analizy na żywo w rozdziale 20. Większość systemów operacyjnych zapewnia dostęp do pamięci uruchomionych procesów. Istnieją narzędzia dla systemów Windows, które pomagają w tym procesie. Jednym z wczesnych narzędzi (już nieutrzymywanych) do wyodrębniania uruchomionych procesów z pamięci był ProcDump. LordPE by Yoda to nowsze narzędzie zdolne do zrzucania obrazów procesów z pamięci. LordPE wyświetla pełną listę uruchomionych procesów. Po wybraniu procesu LordPE wyświetla pełną listę plików powiązanych z tym procesem, a zrzucanie pliku wykonywalnego jest możliwe po kliknięciu prawym przyciskiem myszy.


Powrót

25.07.2021

Rozpakowywanie wspomagane debugerem

Umożliwienie bezpłatnego uruchamiania złośliwego oprogramowania nie zawsze jest dobrym pomysłem. Jeśli nie wiemy, co robi złośliwe oprogramowanie, może mieć okazję siać spustoszenie, zanim uda nam się zrzucić obraz pamięci na dysk. Debugery oferują większą kontrolę nad wykonaniem dowolnego analizowanego programu. Podstawową ideą korzystania z debuggera jest umożliwienie złośliwemu programowi działania na tyle długo, aby samo się rozpakowało, a następnie wykorzystanie możliwości zrzutu pamięci debuggera do zrzutu obrazu procesu do pliku do dalszej analizy. Problem polega na określeniu, jak długo to wystarczy. Podstawowym problemem podczas pracy z samomodyfikującym się kodem w debuggerze jest to, że programowe punkty przerwania (takie jak x86 int 3) są trudne w użyciu, ponieważ zapisany opcode punktu przerwania (0xCC na x86) może zostać zmodyfikowany zanim program dotrze do lokalizacji punktu przerwania . W rezultacie procesor pobierze coś innego niż kod punktu przerwania i nie zdoła poprawnie złamać. Sprzętowe punkty przerwania mogą być używane na procesorach, które je obsługują; pozostaje jednak problem, gdzie ustawić punkt przerwania. Bez prawidłowego demontażu nie jest możliwe określenie, gdzie ustawić punkt przerwania. Jedynym rozsądnym podejściem jest użycie pojedynczego kroku do momentu ujawnienia jakiegoś wzorca wykonania, takiego jak pętla, a następnie wykorzystanie punktów przerwania do wykonania pętli do końca, w którym to momencie wznawiasz pojedynczy krok i powtarzasz proces. Może to być bardzo czasochłonne, jeśli autor programu pakującego zdecyduje się na użycie wielu małych pętli i samomodyfikujących się sekcji kodu, aby udaremnić analizę. Joe Stewart opracował wtyczkę OllyBonE dla OllyDbg, debuggera systemu Windows. Wtyczka została zaprojektowana tak, aby oferować funkcję punktu przerwania Break-on-Execute. Break-on-Execute umożliwia odczytanie lub zapisanie lokalizacji pamięci jako danych, ale powoduje wyzwolenie punktu przerwania, jeśli ta lokalizacja pamięci jest pobierana, co oznacza, że lokalizacja jest traktowana jako adres instrukcji. Zakłada się tutaj, że najpierw należy zmodyfikować spakowane dane programu podczas procesu rozpakowywania, zanim ten kod będzie mógł zostać wykonany. OllyBonE może być użyty do ustawienia punktu przerwania Break-on-Execute w całej sekcji programu, umożliwiając wykonanie programu przez fazę rozpakowywania, ale przechwytując przeniesienie kontroli z kodu pośredniczącego rozpakowywania do nowo rozpakowanego kodu. W przykładzie Sobiga użycie OllyBonE do ustawienia punktu przerwania w sekcji zero, a następnie zezwolenie na uruchomienie programu spowoduje rozpakowanie programu. Ale uniemożliwi to wykonanie rozpakowanego kodu, ponieważ punkt przerwania zostanie wyzwolony, gdy kontrola zostanie przeniesiona do dowolnej lokalizacji w sekcji zerowej. Po rozpakowaniu programu OllyDump i PE Dumper to dwie dodatkowe wtyczki do OllyDbg, które służą do zrzucania rozpakowanego obrazu programu z powrotem do pliku.
Powrót

26.07.2021

Rozpakowywanie wspomagane przez IDA

Autorzy programów pakujących doskonale zdają sobie sprawę, że inżynierowie wsteczni wykorzystują debuggery do rozpakowywania plików binarnych. W rezultacie wiele obecnych programów pakujących zawiera techniki zapobiegające debugowaniu, aby utrudnić rozpakowywanie wspomagane przez debugger. Obejmują one

•  Wykrywanie debuggera Użycie funkcji IsDebuggerPresent (Windows), testy synchronizacji w celu wykrycia wolniejszego niż oczekiwano wykonania, badanie licznika znaczników czasu x86, testowanie flagi śledzenia procesora oraz wyszukiwanie procesów związanych z debugerem to tylko kilka przykładów.
•  Przechwytywanie przerwań Debugery polegają na możliwości przetwarzania określonych wyjątków procesora. Aby to zrobić, debugery rejestrują programy obsługi przerwań dla wszystkich przerwań, które spodziewają się przetworzyć. Niektóre programy pakujące rejestrują własne programy obsługi przerwań, aby uniemożliwić debugerowi odzyskanie kontroli.
•  Manipulacja rejestrami debugowania Debugery muszą ściśle kontrolować wszelkie rejestry debugowania sprzętu, które może posiadać jednostka centralna. Aby zapobiec debugowaniu wspomaganemu sprzętowo w systemie Windows, niektóre programy pakujące konfigurują programy obsługi wyjątków, a następnie celowo generują wyjątek. Ponieważ mechanizm obsługi wyjątków systemu Windows przyznaje procesowi dostęp do rejestrów debugowania x86, paker może wyczyścić wszelkie sprzętowe punkty przerwania, które mogły zostać ustawione przez debuger.
•  Samomodyfikujący się kod Utrudnia to ustawienie programowych punktów przerwania, jak opisano wcześniej.
•  Zapobieganie debugowaniu Aby debugować proces, debuger musi mieć możliwość przyłączenia się do tego procesu. Systemy operacyjne pozwalają tylko jednemu debugerowi na dołączenie do procesu w danym momencie. Jeśli debuger jest już dołączony do procesu, drugi debuger nie może dołączyć. Aby zapobiec korzystaniu z debuggerów, niektóre programy dołączają się do siebie, skutecznie wyłączając wszystkie debugery. Jeśli debugger jest używany do początkowego uruchomienia programu, program nie będzie mógł dołączyć się do siebie (ponieważ debugger jest już dołączony) i generalnie zostanie zamknięty.

Oprócz technik antydebugowania, wiele programów pakujących generuje kod zaprojektowany w celu udaremnienia analizy dezasemblacji fragmentu rozpakowywania. Niektóre typowe techniki zapobiegające dezasemblacji obejmują przeskakiwanie do środka instrukcji i przeskakiwanie do wartości obliczonych w czasie wykonywania. Przykład pierwszej techniki pokazano na poniższym zestawieniu, która wyraźnie zatrzymała IDA na jej drodze:

0041D000 sub_41D000 proc near
0041D000 pusha
0041D001 stc
0041D002 call near ptr loc_41D007+2
0041D007 loc_41D007:
0041D007 call near ptr 42B80Ch
0041D007 sub_41D000 endp
0041D00C db 0
0041D00D db 0
0041D00E db 5Eh
0041D00F db 2Bh
0041D010 db 0C9h

Tutaj instrukcja w lokalizacji 41D002 próbuje wywołać lokalizację 41D009, która znajduje się w środku 5-bajtowej instrukcji, która zaczyna się w lokalizacji 41D007. IDA nie może podzielić instrukcji w 41D007 na dwie oddzielne instrukcje, więc zostaje zatrzymana w swoich śladach. Ręczne formatowanie wyświetlacza IDA zapewnia dokładniejszy demontaż, jak pokazano w poniższym kodzie, ale znacznie wydłuża czas potrzebny na analizę pliku binarnego:

0041D000 pusha
0041D001 stc
0041D002 call loc_41D009
0041D002 ; ----------------------------------------
0041D007 db 0E8h ; F
0041D008 db 0
0041D009 ; ----------------------------------------
0041D009 loc_41D009:
0041D009 call $+5
0041D00E pop esi
0041D00F sub ecx, ecx
0041D011 pop eax
0041D012 jz short loc_41D016
0041D012 ; ----------------------------------------
0041D014 db 0CDh ; -
0041D015 db 20h
0041D016 ; ----------------------------------------
0041D016 loc_41D016:
0041D016 mov ecx, 1951h
0041D01B mov eax, ecx
0041D01D clc
0041D01E jnb short loc_41D022

Ta lista ilustruje również użycie wartości środowiska wykonawczego do wpływania na przepływ programu. W tym przykładzie operacje w 41D00F i 41D01D skutecznie przekształcają skoki warunkowe w 41D012 i 41D01E w skoki bezwarunkowe. Fakt ten nie może być znany deasemblerowi, a ponadto służy do udaremniania generowania dokładnego demontażu. W tym momencie użycie deasemblera do rozpakowania zaciemnionego kodu może wydawać się niemożliwe. IDA Pro jest wystarczająco potężny, aby w wielu przypadkach umożliwić demaskację. Dwie opcje rozpakowywania obejmują użycie skryptów IDA i użycie wtyczek IDA. Kluczową koncepcją do zrozumienia jest to, że baza danych deasemblacji IDA może być postrzegana jako załadowany obraz pamięci analizowanego pliku. Kiedy IDA początkowo ładuje plik wykonywalny, mapuje wszystkie bajty pliku wykonywalnego na odpowiadające im lokalizacje w pamięci wirtualnej. Użytkownicy IDA mogą odpytywać i modyfikować zawartość dowolnej lokalizacji w pamięci programu, tak jakby program został załadowany przez system operacyjny. Skrypty i wtyczki mogą to wykorzystać do naśladowania zachowania analizowanego programu. Aby wygenerować skrypt IDC zdolny do rozpakowania pliku binarnego, algorytm rozpakowywania musi zostać przeanalizowany i zrozumiany na tyle dobrze, aby napisać skrypt wykonujący te same czynności. Zwykle wiąże się to z odczytaniem bajtu z bazy danych za pomocą funkcji Byte, zmodyfikowaniem tego bajtu w taki sam sposób, jak robi to rozpakowywanie, a następnie zapisaniem bajtu z powrotem do bazy danych za pomocą funkcji PatchByte. Po wykonaniu skryptu będziesz musiał zmusić IDA do ponownej analizy nowo rozpakowanych bajtów. Dzieje się tak, ponieważ skrypty są uruchamiane po zakończeniu przez IDA wstępnej analizy pliku binarnego. Po wykonaniu każdej akcji, którą podejmiesz w celu zmodyfikowania bazy danych w celu ujawnienia nowego kodu, musisz powiedzieć IDA, aby przekonwertowała bajty na kod lub ponownie przeanalizowała zaatakowany obszar. Podczas gdy rozpakowywanie oparte na skrypcie omija wszelkie techniki zapobiegające debugowaniu stosowane przez program pakujący, główną wadą rozpakowywania opartego na skrypcie jest to, że nowe skrypty muszą być generowane dla każdego nowego programu rozpakowującego, który się pojawia, a istniejące skrypty muszą być modyfikowane przy każdej zmianie w istniejących programach rozpakowujących . Ten sam problem dotyczy wtyczek IDA, których opracowanie i instalacja zazwyczaj wymagają jeszcze większego wysiłku, co sprawia, że ukierunkowane rozpakowywanie wtyczek nie jest optymalnym rozwiązaniem. Wtyczka emulatora IDA x86 (x86emu) została zaprojektowana, aby rozwiązać ten problem. Zapewniając emulację zestawu instrukcji x86, x86emu daje efekt osadzania wirtualnego procesora w IDA Pro. Po aktywacji (domyślnie ALT-F8) x86emu prezentuje interfejs sterowania podobny do debugera. Po załadowaniu x86emu alokuje pamięć do reprezentowania rejestrów x86, stosu i sterty do użycia podczas emulacji programu. Użytkownik może manipulować zawartością emulowanych rejestrów x86 w dowolnym momencie za pomocą konsoli sterowania emulatora. Przejście emulatora powoduje, że wtyczka odczytuje z bazy danych IDA w miejscu wskazanym przez rejestr eip, dekoduje odczytaną instrukcję i wykonuje czynności wskazane przez instrukcję, w tym aktualizację dowolnych rejestrów, flag lub pamięci, które mogło się zmienić. Jeśli zapisywana lokalizacja pamięci znajduje się w bazie danych IDA (w przeciwieństwie do emulowanego stosu lub sterty), emulator odpowiednio aktualizuje bazę danych, przekształcając w ten sposób bazę danych zgodnie z instrukcjami zawartymi w programie rozpakowującym. Po wykonaniu wystarczającej liczby instrukcji emulator przekształci bazę danych IDA w taki sam sposób, w jaki program rozpakowujący przekształciłby program, gdyby faktycznie był uruchomiony, a analiza pliku binarnego może być kontynuowana tak, jakby plik binarny nigdy nie był w ogóle zapakowane. Wtyczka emulatora zawiera różne funkcje ułatwiające emulację plików binarnych systemu Windows, w tym:

•  Generowanie ramek SEH i przesyłanie do zainstalowanego programu obsługi wyjątków, gdy wystąpi wyjątek.
•  Automatyczne przechwytywanie połączeń bibliotecznych. Niektóre wywołania bibliotek są emulowane, w tym LoadLibrary, GetProcAddress i inne. Wywołania funkcji, dla których x86emu nie ma emulacji wewnętrznej, generują wyskakujące okienko, które wyświetla aktualny stan stosu i oferuje użytkownikowi możliwość określenia wartości zwracanej oraz zdefiniowania zachowania funkcji.
•  Śledzenie wywołań CreateThread, dające użytkownikowi możliwość przełączania się między wieloma wątkami podczas emulowania instrukcji.

Emulator oferuje podstawową funkcję punktu przerwania, która nie opiera się na programowych punktach przerwania lub rejestrach kontrolnych debugowania, zapobiegając udaremnieniu mechanizmu punktu przerwania przez programy rozpakowujące. Wreszcie emulator oferuje możliwość wyliczenia przydzielonych bloków sterty i zrzucenia dowolnego zakresu pamięci z bazy danych do pliku. Zalety rozpakowywania opartego na emulatorze obejmują fakt, że oryginalny program nigdy nie jest wykonywany, co czyni to podejście bezpiecznym i eliminuje potrzebę budowania i utrzymywania piaskownicy. Dodatkowo, ponieważ emulator działa na poziomie instrukcji procesora, jest odporny na zmiany algorytmiczne w rozpakowującym i może być używany przeciwko nieznanym rozpakowującym bez zmian. Wreszcie emulator jest odporny na debugger i wirtualne techniki wykrywania maszyn. Wady obejmują to, że nie można zaobserwować prawdziwego zachowania, takiego jak połączenia sieciowe, pliku binarnego, a obecnie kompletny zestaw instrukcji x86 nie jest emulowany. Jako że emulator był przeznaczony przede wszystkim do rozpakowywania, żadne z tych ograniczeń nie wchodzi w grę.

Rozpakowałem plik binarny - co teraz?

Po uzyskaniu rozpakowanego pliku binarnego można zastosować bardziej tradycyjne techniki analizy. Pamiętaj jednak, że jeśli Twoim celem jest wykonanie czarnoskrzynkowej analizy działającej próbki złośliwego oprogramowania, to rozpakowanie prawdopodobnie nie było konieczne. Po zadaniu sobie trudu rozpakowania pliku binarnego, najbardziej logicznym następnym krokiem jest analiza za pomocą deasemblera. Warto zauważyć, że w tym momencie należy przeprowadzić analizę ciągów na rozpakowanym pliku binarnym, aby uzyskać bardzo przybliżone pojęcie o niektórych rzeczach, które może próbować wykonać plik binarny.
Powrót

27.07.2021

Złośliwe oprogramowanie inżynierii wstecznej

Zakładając, że udało Ci się uzyskać rozpakowaną próbkę złośliwego oprogramowania za pomocą jakiegoś mechanizmu rozpakowywania, gdzie dalej? W rozdziale 20 omówiono niektóre techniki przeprowadzania analizy czarnoskrzynkowej próbek złośliwego oprogramowania. Czy łatwiej jest analizować złośliwe oprogramowanie, gdy jest ono w pełni ujawnione w IDA? Niestety nie. Analiza statyczna to bardzo żmudny proces i nie ma magicznej recepty na jej ułatwienie. Dokładne zrozumienie typowych zachowań złośliwego oprogramowania może przyspieszyć ten proces.

Faza konfiguracji złośliwego oprogramowania

Pierwsze działania, które podejmuje większość złośliwego oprogramowania, skupiają się na przetrwaniu. Funkcje zwykle zaangażowane w fazę utrwalania często obejmują tworzenie plików, edycję rejestru i instalację usług. Niektóre przydatne informacje dotyczące trwałości obejmują nazwy wszelkich plików lub usług, które są tworzone, oraz wszelkie klucze rejestru, którymi się manipuluje. Ciekawa technika ukrywania danych stosowana w niektórych złośliwych programach polega na przechowywaniu danych w niestandardowych lokalizacjach w pliku binarnym. Wcześniej omawialiśmy fakt, że zaobserwowano pewne złośliwe oprogramowanie, które przechowuje dane w sekcji zasobów plików binarnych systemu Windows. Jest to ważna rzecz, o której należy pamiętać, ponieważ IDA zazwyczaj domyślnie nie ładuje sekcji zasobów, co uniemożliwi analizę jakichkolwiek danych, które mogą być tam przechowywane. Inną niestandardową lokalizacją, w której zaobserwowano, że złośliwe oprogramowanie przechowuje dane, jest koniec pliku, poza zdefiniowanymi granicami sekcji. Szkodnik lokalizuje te dane, analizując własne nagłówki, aby obliczyć całkowitą długość wszystkich sekcji programu. Następnie może wyszukać koniec wszystkich danych sekcji i odczytać dodatkowe dane, które zostały dołączone na końcu pliku. W przeciwieństwie do zasobów, które IDA może załadować w przypadku ręcznego ładowania, IDA nie załaduje danych, które znajdują się poza zdefiniowanymi sekcjami.

Faza działania złośliwego oprogramowania

Gdy złośliwe oprogramowanie ustali swoją obecność na komputerze, złośliwe oprogramowanie przystępuje do swojego głównego zadania. Większość współczesnego szkodliwego oprogramowania realizuje jakąś formę komunikacji sieciowej. Funkcje do wyszukania obejmują wszelkie funkcje konfiguracji gniazd dla gniazd klienta (połączenia) lub serwera (nasłuchiwania, akceptowania). Windows oferuje dużą liczbę funkcji sieciowych poza tradycyjnym modelem gniazd Berkeley. Wiele z tych wygodnych funkcji można znaleźć w bibliotece WinInet i obejmują one funkcje takie jak InternetOpen, InternetConnect, InternetOpenUrl i InternetReadFile. Złośliwe oprogramowanie, które tworzy gniazda serwera, zazwyczaj działa w jednej z dwóch możliwości. Albo złośliwe oprogramowanie posiada możliwość łączenia się z backdoorem, albo złośliwe oprogramowanie implementuje funkcję proxy. Analiza sposobu obsługi przychodzących danych ujawni, w jakim stopniu działa złośliwe oprogramowanie. Backdoory zazwyczaj zawierają pewną formę pętli przetwarzania poleceń, w której porównują przychodzące polecenia z listą prawidłowych poleceń. Typowe możliwości backdoora obejmują możliwość wykonania pojedynczego polecenia i zwracać wyniki, możliwość wysyłania lub pobierania pliku, możliwość zamykania backdoora oraz możliwość tworzenia kompletnej powłoki poleceń. Backdoory, które udostępniają pełne powłoki poleceń, zazwyczaj konfigurują gniazdo podłączonego klienta jako standardowe wejście i wyjście dla uruchomionego procesu powłoki potomnej. W systemach uniksowych zwykle obejmuje to wywołania dup lub dup2, rozwidlenia i execve do spawnowania /bin/sh. W systemach Windows zwykle wiąże się to z wywołaniem CreateProcess w celu wywołania cmd.exe. Jeśli złośliwe oprogramowanie działa jako proxy, przychodzące dane będą natychmiast zapisywane w drugim gnieździe wychodzącym. Złośliwe oprogramowanie, które tworzy tylko połączenia wychodzące, może działać praktycznie w dowolnym zakresie: robak, agent DDoS lub prosty bot, który próbuje zadzwonić do domu. Przydatne jest przynajmniej ustalenie, czy złośliwe oprogramowanie łączy się z wieloma hostami (może to być robak), czy z pojedynczym hostem (może dzwonić do domu) oraz z jakim portem (portami) próbuje się połączyć złośliwe oprogramowanie. Powinieneś postarać się wyśledzić, co robi złośliwe oprogramowanie, gdy połączy się ze zdalnym hostem. Można używać dowolnych obserwowanych portów i protokołów do tworzenia narzędzi do wykrywania złośliwego oprogramowania i ewentualnie usuwania. Coraz częściej złośliwe oprogramowanie wykonuje podstawowe szyfrowanie przesyłanych danych. Szyfrowanie musi nastąpić tuż przed transmisją danych lub zaraz po ich odebraniu. Identyfikacja algorytmów szyfrowania wykorzystywanych przez złośliwe oprogramowanie może prowadzić do opracowania odpowiednich dekoderów, które z kolei mogą zostać wykorzystane do określenia, jakie dane mogły zostać wykradzione przez złośliwe oprogramowanie. Możliwe jest również opracowanie koderów, których można użyć do komunikacji ze złośliwym oprogramowaniem w celu jego wykrycia lub wyłączenia. Liczba technik komunikacyjnych wykorzystywanych przez autorów szkodliwego oprogramowania rośnie z każdym nowym szczepem szkodliwego oprogramowania. Znaczenie analizy złośliwego oprogramowania polega na zrozumieniu aktualnego stanu społeczności złośliwego oprogramowania w celu poprawy technik wykrywania, analizy i usuwania .

Ręczna analiza złośliwego oprogramowania jest bardzo powolnym procesem, który najlepiej jest pozostawić w przypadkach, w których napotykane są nowe rodziny złośliwego oprogramowania lub gdy dogłębna analiza próbki złośliwego oprogramowania jest absolutnie konieczna.

Automatyczna analiza złośliwego oprogramowania

Zautomatyzowana analiza złośliwego oprogramowania to praktycznie nierozwiązywalny problem. Po prostu nie jest możliwe, aby jeden program dokładnie określił zachowanie innego programu. W rezultacie zautomatyzowana analiza złośliwego oprogramowania została zredukowana do dopasowywania sygnatur lub stosowania różnych heurystyk, z których żadna nie jest zbyt skuteczna w obliczu pojawiających się zagrożeń złośliwym oprogramowaniem. Jedna z obiecujących metod rozpoznawania złośliwego oprogramowania, opracowana przez Halvar Flake i SABRE Security, wykorzystuje technologię leżącą u podstaw produktu BinDiff firmy do wykonywania opartej na wykresach analizy różnicowej między nieznanymi plikami binarnymi a znanymi próbkami złośliwego oprogramowania. Analiza oparta na wykresie służy do opracowania miary podobieństwa między nieznaną próbką a znanymi próbkami. Obserwując podobieństwa genetyczne w ten sposób, można określić, czy nowy, nieznany plik binarny jest pochodną znanej rodziny złośliwego oprogramowania.
Powrót