O co chodzi z tą logiką detekcji?

bezpieczeństwo

Logika detekcji jest używana przez różnorodne mechanizmy w nowoczesnym oprogramowaniu do ochrony punktów końcowych. W branży cyberbezpieczeństwa określa się ją wieloma różnymi nazwami. Podobnie jak laicy używają terminu „wirus” na określenie tego, co specjaliści od bezpieczeństwa nazywają „złośliwym oprogramowaniem” (z technicznego punktu widzenia wirus to program, który rozprzestrzenia się poprzez umieszczanie swoich kopii w innym programie, pliku danych lub sektorze rozruchowym), logika detekcji bywa nazywana „sygnaturami”, „odciskami palców”, „wzorcami” albo „wskaźnikami IOC”. Kiedy zatem ktoś mówi o wirusie, zazwyczaj ma na myśli złośliwe oprogramowanie, a gdy mówi o sygnaturach, często myśli o logice detekcji. No chyba że mówi właśnie o prostych detekcjach sygnaturowych, których używano w latach osiemdziesiątych i dziewięćdziesiątych.

W F-Secure logikę detekcji często nazywamy po prostu „detekcjami”.

W poprzednich odcinkach tej serii pisałem o mechanizmach skanowania, mechanizmach behawioralnych i reputacji seciowej oraz o tym, jak współpracują one ze sobą w celu blokowania zagrożeń. Teraz chciałbym wyjaśnić, jak wygląda logika detekcji używana przez te mechanizmy i jak się ją tworzy.

Jest to nieco dłuższy artykuł, więc proszę o cierpliwość. Okazało się, że aby szczegółowo i sensownie wyjaśnić ten temat, będę musiał omówić kilka różnych obszarów. Poszczególne koncepcje w wielu miejscach łączą się ze sobą, więc postanowiłem przygotować jeden długi post zamiast kilku oddzielnych wpisów. Szkic tego tekstu przejrzało całkiem sporo osób, ale niektórzy właśnie wyjechali na wakacje, zatem mam nadzieję, że nikt nie będzie miał pretensji, że ujawniam te wszystkie informacje.

W nowoczesnych produktach zabezpieczających wykorzystuje się różne typy logiki detekcji. Omówię każdy z nich w oddzielnej sekcji.

static_analysis_research_closeup

O czym to mówiliśmy? Ach tak, skomplikowana matematyka i sztuczna inteligencja.

Chmurowa logika detekcji

Nowoczesne oprogramowanie zabezpieczające zwykle zawiera jeden lub więcej komponentów klienckich, które wykonują kwerendy przez internet. Logika detekcji jest często realizowana częściowo przez komponenty klienckie, a częściowo przez serwer. W najprostszych przypadkach unikatowy identyfikator obiektu (na przykład jego skrót kryptograficzny) jest przekazywany do serwera, który odsyła prosty werdykt „dobry/zły/nieznany”, uwzględniany przez program kliencki podczas podejmowania ostatecznej decyzji.

W bardziej skomplikowanych przypadkach program kliencki wyodrębnia z obiektu metadane i wysyła do je serwera, który następnie stosuje własny zbiór reguł i zwraca werdykt albo nowy zbiór wartości, które program kliencki przetwarza przed wydaniem werdyktu.

Nawet najprostsze wyszukiwania chmurowe są bardzo skuteczne. Systemy back-endu mają dostęp do pełnej bazy próbek, a także do informacji i metadanych zbieranych od wszystkich użytkowników naszego oprogramowania. Samo urządzenie końcowe nie miałoby dostępu do tych dodatkowych informacji. Kwerenda chmurowa umożliwia przekazanie ich do programu klienckiego, gdzie mogą zostać wykorzystane przez poszczególne komponenty ochronne. Dobrym przykładem jest sprawdzanie potencjalnej szkodliwości plików za pomocą wskaźnika prewalencji.

Warto wspomnieć tu jeszcze o skanowaniu chmurowym. Próbki można wysyłać z urządzenia końcowego do chmury w celu przeprowadzenia skomplikowanej analizy, której nie dałoby się wykonać po stronie klienta. Analiza ta może obejmować przepuszczanie próbki przez wiele mechanizmów skanowania, poddawanie jej analizie statycznej oraz dynamicznej. Detekcje na back-endzie projektuje się tak, aby wydawały werdykt poprzez przetwarzanie metadanych wygenerowanych podczas tych analiz. Omówię to bardziej szczegółowo w sekcji poświęconej detekcjom na back-endzie.

Heurystyczna logika detekcji

Zadaniem heurystycznej logiki detekcji jest wyszukiwanie wzorów często pojawiających się w złośliwych plikach. Detekcje heurystyczne mogą być generowane przez techniki maszynowego uczenia się albo tworzone ręcznie.

Stworzona ręcznie logika detekcji heurystycznej może na przykład sprawdzać, czy w skrypcie często występuje znak „+”, co może świadczyć o zastosowaniu typowych technik „zaciemniania” kodu. Bardziej skomplikowane ręczne detekcje mogą szukać wielu wzorów. Wskaźnik potencjalnej szkodliwości jest zwykle obliczany na podstawie obecności tego rodzaju wzorów, a następnie łączony z innymi metadanymi w celu wydania ostatecznego werdyktu.

System maszynowego uczenia się, który nauczono rozpoznawać strukturalne wzory często występujące w plikach złośliwych, ale nie w „czystych”, umożliwia zbudowanie złożonej logiki heurystycznej. W tym celu wprowadza się duże zbiory złośliwych i czystych plików, które zostały zweryfikowane przez ekspertów, do systemu maszynowego uczenia się, a następnie skrupulatnie testuje się wyniki. Jeśli uzyskany w ten sposób pakiet detekcji jest wystarczająco wydajny i nie generuje fałszywie pozytywnych ani fałszywie negatywnych wyników, wdraża się go w urządzeniu końcowym. Proces ten należy regularnie powtarzać, aby dostosować logikę detekcji do zmieniającego się krajobrazu zagrożeń. Tego rodzaju pakiety detekcji również działają na zasadzie wyszukiwania charakterystycznych cech i wzorów w próbkach oraz stosowania modeli matematycznych w celu obliczenia wskaźnika potencjalnej szkodliwości.

portable_executable_32_bit_structure-e1467965709229

Informacje zawarte w strukturze pliku PE można czasem wykorzystać w celu ustalenia, jak bardzo podejrzany jest dany plik.

Jakość detekcji heurystycznych zależy w dużym stopniu od tego, jak dobrze wyszkolono system maszynowego uczenia się. To z kolei zależy od jakości próbek użytych podczas etapów treningu i testowania, a jakość próbek – od odpowiedniej kombinacji automatyzacji i ludzkiego nadzoru. Wymaga to doświadczenia, czasu i środków, ale pozwala uzyskać znakomite efekty.

Reguły behawioralne

Mechanizmy analizujące wykonywanie kodu zawierają zbiór reguł, które pozwalają określić, czy obserwowane wzory behawioralne są podejrzane lub złośliwe.

Niektóre reguły behawioralne można wygenerować automatycznie, inne opracowuje się ręcznie. Poprzez badanie nowych technik włamań oraz wektorów ataku można stworzyć reguły behawioralne, zanim techniki te upowszechnią się w złośliwym oprogramowaniu. Następnie można zaprojektować ogólne reguły behawioralne, które wyłapują wszelkie rodzaje złośliwej aktywności, i w ten sposób pozostać o krok przed napastnikami.  Nasi badacze w F-Secure Labs zawsze wypatrują aktualnych trendów w krajobrazie zagrożeń. Kiedy zidentyfikują nowe metodologie, przystępują do pracy nad nowymi regułami w oparciu o wyniki badań.

Jak więc działają reguły behawioralne? Kiedy coś się wykonuje (może to oznaczać uruchomienie pliku wykonywalnego, otwarcie dokumentu w odpowiednim programie itd.), system generuje ślad wykonania. Ślad ten jest przekazywany do procedur detekcji, których zadaniem jest reagować na pewne sekwencje zdarzeń. Do typów zdarzeń, które może sprawdzać reguła behawioralna, należy na przykład:

  • tworzenie, niszczenie lub wstrzymywanie procesu,
  • próby „wstrzyknięcia” kodu,
  • manipulacje w systemie plików,
  • operacje na rejestrze.

Każde zdarzenie przekazywane do reguły behawioralnej zawiera zbiór powiązanych z nim metadanych. Reguły mają również dostęp do globalnych metadanych śladu wykonania, takich jak identyfikator procesu (PID), ścieżka do pliku i proces macierzysty. Dostępne są też metadane pochodzące z kwerend chmurowych oraz innych komponentów ochronnych, m.in. wskaźnik prewalencji oraz pochodzenie pliku (historia pliku od momentu, w którym pojawił się w systemie, która może obejmować na przykład adres URL, spod którego pobrano plik). Jak można sobie wyobrazić, wszystkie te informacje umożliwiają zbudowanie całkiem kreatywnej logiki.

Oczywiście, nieustannie aktualizujemy logikę i funkcje naszych komponentów detekcji behawioralnej w miarę, jak zmienia się krajobraz zagrożeń i jak dokonujemy ulepszeń.  Kto by tego nie robił?

Generyczna logika detekcji

Tworząc skomplikowane programy, które są wykonywane w urządzeniach końcowych, możemy zautomatyzować niektóre techniki inżynierii wstecznej w celu wykrywania złośliwego oprogramowania. Tutaj robi się interesująco, ale wyjaśnienie tego zajmie trochę czasu.

Istnieje wiele typów plików, które mogą zawierać złośliwy kod. Oto kilka przykładów:

  • dokumenty, na przykład w formacie PDF lub MS Office,
  • pliki wykonywalne przeznaczone do różnych systemów operacyjnych i architektur, takie jak PE, ELF, Mach-O i .NET.
  • pakiety aplikacyjne, takie jak APK, OS X (.app) i Flash (SWF),
  • obrazy dysku, takie jak ISO i DMG,
  • skompilowany kod bajtowy, na przykład klasy Javy lub pliki dex w Androidzie,
  • języki znakowania, takie jak HTML lub XML,
  • skrypty, na przykład VBScript, JavaScript oraz skrypty powłoki systemu operacyjnego,
  • kontenery, takie jak zip, 7z, i RAR.

Do pracy z tymi wszystkimi formatami plików często potrzebne są parsery. Parsery identyfikują użyteczne osadzone struktury i wyodrębniają je z odpowiednich kontenerów. Przykładem osadzonych struktur są zasoby (dźwięki, grafika, wideo i dane), nagłówki PE, sekcje PE, podpisy Authenticode, manifesty Androida i skompilowany kod.

Mówiąc prosto, parser dzieli plik wejściowy na części składowe i udostępnia je logice detekcji jako łatwo dostępne struktury danych. Formaty plików są często skomplikowane i obejmują wiele przypadków specjalnych. Dzieląc plik na części i przekazując strukturę danych do logiki detekcji, unikamy wielokrotnego powielania złożonego kodu analizy składniowej. Możemy też upewnić się, że kod jest niezawodny i wydajny.

W złośliwych plikach często osadzone są inne pliki (różnych typów). Na przykład złośliwy dokument PDF może zawierać osadzony kod Flash, kod wykonywalny, shellcode lub skrypty. Te osadzone pliki są często zaszyfrowane lub zaciemnione. Kiedy zewnętrzny złośliwy plik jest otwierany lub uruchamiany, deszyfruje zawarte w nim obiekty, zapisuje je w pamięci lub na dysku, po czym wykonuje.

Same złośliwe pliki wykonywalne często używają standardowych programów do kompresji/ochrony kodu, takich jak UPX lub ASPack, aby zaciemnić swój kod i struktury. W większości przypadków stosuje się kolejno kilka różnych programów do kompresji, a często również niestandardowe metody zaciemniania stworzone przez autora złośliwego oprogramowania. Docieranie do rzeczywistego kodu wewnątrz złośliwego pliku wykonywalnego przypomina obieranie cebuli.

Problem ze spakowanymi plikami polega na tym, że wszystkie wyglądają bardzo podobnie, a niektóre zwykłe pliki wykonywalne również używają kompresji. Aby prawidłowo zidentyfikować złośliwy plik, często trzeba usunąć te warstwy.

Usuwanie typowej kompresji jest łatwe – nietrudno rozpoznać standardowe programy do ochrony kodu. Trudniej usunąć niestandardowe zaciemnienie. Jednym ze sposobów jest wyodrębnienie kodu deszyfrującego oraz bloków danych ze złośliwego oprogramowania i uruchomienie ich w „piaskownicy” w taki sposób, żeby złośliwy kod sam się rozpakował. Innym trikiem jest napisanie procedury, która analizuje kod usuwający zaciemnienie, identyfikuje klucz deszyfrujący i lokalizuje dane, po czym wyodrębnia obraz wykonywalny.

Dzięki usunięciu warstw obronnych ze złośliwego pliku wykonywalnego logika detekcji może przeanalizować właściwy, głęboko ukryty kod. Uzyskany w ten sposób obraz można przetwarzać na wiele różnych sposobów. Te same techniki stosuje się do wyodrębniania obiektów z plików w formatach innych niż PE, takich jak dokumenty PDF i MS Office, a podobne metody deszyfrowania pozwalają usunąć zaciemnienie na przykład ze złośliwego kodu JavaScript.

Tworzenie detekcji tego typu bywa czasochłonne, ale z pewnością warte zachodu. Detekcje generyczne nie tylko pozwalają wyłapać dużą liczbę złośliwych plików, ale mają też długi okres ważności. W wielu przypadkach nowe warianty tej samej rodziny złośliwego oprogramowania są wykrywane przez dobrze napisaną detekcję generyczną bez żadnych modyfikacji. Na naszej mapie świata widać że większość, jeśli nie wszystkie spośród naszych 10 najczęstszych detekcji to ręcznie napisane detekcje generyczne.

Szczerze mówiąc, wszystko, co tu napisałem, to bardzo powierzchowne omówienie działania tych technologii. Trzeba pamiętać, że logika detekcji ma również dostęp do informacji z kwerend chmurowych oraz śledzenia pochodzenia plików i może działać na dowolnych strumieniach danych, w tym przechowywanych w pamięci i przesyłanych przez sieć, więc nietrudno zrozumieć, czemu te zagadnienia są tak skomplikowane. Żeby je dogłębnie wyjaśnić, prawdopodobnie trzeba by napisać całą książkę.

Sieciowa logika detekcji

Blokowanie ataków w sieci, na przykład pakietów exploitów, to coś, na co kładziemy duży nacisk. Powstrzymywanie zagrożeń na wczesnym etapie to skuteczny sposób ochrony urządzeń przed infekcjami.

Jak wspomniano w poprzedniej sekcji, strumienie danych napływających z sieci można analizować w podobny sposób, jak bada się pliki na dysku. Różnica polega na tym, że w sieci, w miarę przybywania informacji, można wykorzystać mechanizmy, które w locie blokują lub filtrują dostęp do dalszych wektorów ataku.

Sieciowa logika detekcji w urządzeniu końcowym ma dostęp do adresów IP i URL, zapytań DNS, certyfikatów TLS, nagłówków HTTP, treści HTTP oraz wielu innych metadanych. Może również badać reputację sieciową, w tym reputację adresów URL, certyfikatów i adresów IP (za pośrednictwem kwerend chmurowych). Dysponując tymi wszystkimi informacjami, można zrobić sporo interesujących rzeczy. Oto kilka przykładów.

  • Zachowanie witryny internetowej można badać w czasie rzeczywistym, co pozwala wykrywać i blokować pakiety exploitów.
  • Można zablokować komunikację między botem a jego serwerem dowodzenia na podstawie adresu IP, z którym próbuje skontaktować się bot. Można też blokować komunikację z serwerami dowodzenia na podstawie wzorów ruchu sieciowego.
  • Witryny wyłudzające informacje można blokować na podstawie nagłówka HTTP, treści HTTP albo jednego i drugiego.
  • Można blokować wiele typów złośliwych przekierowań, w tym przekierowania Flasha.

Technologie przechwytujące działające na poziomie sieci umożliwiają nam wyodrębnienie i zapisanie danych na temat obiektów przybywających do systemu. Metadane te są dostępne dla innych komponentów ochronnych, które uwzględniają je w procesie podejmowania decyzji.

Pamięciowa logika detekcji

Tropienie śladów złośliwego kodu w pamięci to użyteczna technika, zwłaszcza podczas instalacji w systemie, który wcześniej nie był chroniony. Niektóre typy złośliwego oprogramowania, zwłaszcza rootkity, można wykryć tylko tą metodą.

Niektóre złośliwe programy aktywnie zapobiegają instalacji oprogramowania ochronnego w systemie. Oczyszczenie systemu przed uruchomieniem instalatora jest zatem ważnym krokiem. Uruchamiamy procedury śledcze, w tym funkcje skanowania pamięci, na wczesnym etapie instalacji naszych produktów, aby usunąć ewentualne infekcje, do których doszło w przeszłości. Te same procedury śledcze mogą być uruchamiane okresowo lub ręcznie, aby zagwarantować, że nic nie prześliznęło się przez nasze szyki defensywne.

Jak już wspomniałem, przedzieranie się przez warstwy zaciemnienia bywa dość skomplikowane. Badając przestrzeń adresową używaną przez złośliwe oprogramowanie, często można znaleźć obraz z usuniętym zaciemnieniem. Nie jest to jednak regułą. Standardowe programy do kompresji zwykle zapisują kod w pamięci i uruchamiają go, ale jeśli złośliwe oprogramowanie używa niestandardowej metody zaciemniania, może skorzystać z różnych trików, aby kod pozostał zaciemniony nawet w pamięci. Prostym sposobem może być zaciemnienie łańcuchów tekstu. W bardziej skomplikowanych przypadkach kod jest przekształcany w specjalny, jednorazowy, generowany podczas kompilacji zbiór instrukcji, który jest wykonywany pod kontrolą niestandardowej maszyny wirtualnej.

Logika detekcji w systemach zaplecza

Duża moc naszych systemów zaplecza umożliwia nam kosztowną obliczeniowo, czasochłonną analizę próbek, której nie dałoby się przeprowadzić w urządzeniu końcowym. Wykonując szereg czynności analitycznych i łącząc rezultaty tych operacji z metadanymi pochodzącymi z kwerend klienckich oraz naszych systemów przechowywania próbek, możemy automatycznie przetwarzać i klasyfikować duże ilości próbek, czego nie bylibyśmy w stanie zrobić ręcznie. Procesy te dostarczają nam również wiele użytecznych informacji o zagrożeniach.

Niektóre technologie używane w naszych produktach do ochrony punktów końcowych można również wykorzystać do rygorystycznej analizy statycznej. W tym celu pisze się specjalny kod detekcyjny, który wyodrębnia metadane i identyfikuje charakterystykę próbki, zamiast po prostu wydać werdykt.  To tylko jedna z metod, których używamy do preparowania próbek. Inne systemy, zaprojektowane pod kątem przetwarzania konkretnych typów plików, również dostarczają istotne metadane na potrzeby logiki decyzyjnej. Ponadto przepuszczamy próbki przez systemy, które heurystycznie określają potencjalną szkodliwość pliku na podstawie cech strukturalnych.

static_analysis_research

Classy i Gemmy, dwa komponenty automatyzujące rozpoznawanie złośliwego oprogramowania, opracowane około pięć lat temu w ramach wspólnego projektu badawczego z uniwersytetem Aalto

Adresy URL i próbki, które można wykonać, są wysyłane do sandboksów i poddawane analizie dynamicznej. Ślad działania próbki uzyskuje się poprzez odpowiednie przygotowanie środowiska, w którym próbka jest wykonywana. Ślad ten dostarcza dodatkowych metadanych umożliwiających sklasyfikowanie próbki.

Czasem analiza tego typu dostarcza nam nowych próbek. Złośliwa próbka może na przykład próbować połączyć się z serwerem dowodzenia. Po zaobserwowaniu takiego zachowania adres serwera jest przekazywany z powrotem do systemu do dalszej analizy. Inny przykład, o którym wspomniałem wcześniej, to złośliwe oprogramowanie, które uruchamia osadzony kod. Kiedy tak się dzieje, osadzony kod jest przekazywany do systemu. Właśnie dlatego mamy logikę detekcji, która wykrywa nie tylko pierwotne złośliwe oprogramowanie, ale również wszystkie jego dalsze ogniwa w łańcuchu ataku.

Ponieważ nasze produkty zasięgają informacji w chmurze, możemy gromadzić metadane od wszystkich użytkowników. Metadane te pozwalają ustalić, jak bardzo podejrzana jest dana próbka. Na przykład prewalencja próbki może świadczyć o jej potencjalnej złośliwości.

Kiedy w pełni przetworzymy plik lub adres URL, przekazujemy wszystkie zgromadzone metadane do mechanizmu reguł, który określamy mianem automatyzacji zarządzania próbkami (Sample Management Automation, SMA). Reguły w tym systemie są częściowo pisane ręcznie, a częściowo adaptacyjne, w zależności od zmian w środowisku zagrożeń. System ten jest mózgiem całej naszej działalności – klasyfikuje i oznacza próbki w bazach danych, wydaje werdykty i powiadamia nas o nowych zagrożeniach.

Detekcje beta

Nie da się napisać dobrego oprogramowania bez skrupulatnych testów. Czasem nasi badacze wymyślają kreatywne sposoby wykrywania złośliwego oprogramowania, ale nie są pewni, jak zadziałają one w rzeczywistym świecie. Na przykład nowy typ detekcji może okazać się zbyt agresywny i zgłaszać mnóstwo fałszywie pozytywnych wyników, ale nie dowiemy się tego, dopóki nie wypróbujemy go „w naturze”. W takich przypadkach używamy detekcji beta.

Detekcja beta informuje nas, co by zrobiła, ale nie wyzwala żadnych rzeczywistych operacji w produkcie lub samym systemie. Gromadząc dane otrzymane od tych fragmentów kodu, możemy je zoptymalizować i wprowadzić do użytku dopiero wtedy, gdy będą działały tak, jak należy.

Detekcje beta to często bardzo zaawansowane programy. W wielu przypadkach wykorzystujemy w nich technologie opracowane z myślą o zagrożeniach, które umiemy już wyłapywać, ale używające innych, bardziej efektywnych metod. Staramy się, żeby każda stworzona ręcznie detekcja identyfikowała jak najwięcej rzeczywistych próbek, więc detekcje beta stanowią przydatne laboratorium do testowania nowych teorii. Wykorzystujemy detekcje beta zarówno w systemach back endu, jak i w urządzeniach końcowych.

Podsumowanie

Jak widać, logika detekcji przybiera wiele różnych form i może być używana do wielu różnych zadań. Technologie stojące za tymi metodami detekcji zaprojektowano tak, aby współpracowały ze sobą i chroniły urządzenia oraz użytkowników przed szeroką gamą wektorów ataku. Cały system jest dość skomplikowany, ale bardzo skuteczny. Ponadto nieustannie modernizujemy nasze technologie i metodologie w miarę, jak zmienia się krajobraz zagrożeń. Stosując wiele różnych warstw ochrony i nie stawiając wszystkiego na jedną kartę, utrudniamy napastnikom obejście zabezpieczeń. Kiedy więc następnym razem usłyszysz, jak ktoś mówi o „sygnaturach” w kontekście nowoczesnych produktów do ochrony punktów końcowych, będziesz wiedział, że albo jest niedoinformowany, albo sprzedaje fikcję.

P.S. Gdybyś się zastanawiał – kiedy wyżej napisałem, że nie wiem, czy wolno mi ujawnić te informacje,  oczywiście żartowałem. Otrzymujemy dużo pozytywnych opinii na temat tej serii artykułów i nie mamy nic przeciwko temu, żeby otwarcie opowiadać o naszych technologiach.

 

Autorem artykułu jest Andy Patel

 

Oceń artykuł

0 głosów

1 komentarzy

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Log Out / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Log Out / Zmień )

Facebook photo

Komentujesz korzystając z konta Facebook. Log Out / Zmień )

Google+ photo

Komentujesz korzystając z konta Google+. Log Out / Zmień )

Connecting to %s

Może Ci się też spodobać

%d bloggers like this: