Odpowiedź na to pytanie zaciekawi na pewno niejedną osobę zajmującą się bezpieczeństwem IT, ale zanim przejdziemy do wyjaśniania tematu warto będzie w pierwszej kolejności odpowiedzieć na pytania: Czy zatem warto monitorować logi? Jak można ukryć po sobie aktywność oraz oszukać systemy monitorowania obecne w dzisiejszych czasach? Jak się przed tym uchronić? – na te i inne pytania postaramy się odpowiedzieć w poniższym artykule.
Na początek przytoczymy anegdotę o dwóch informatykach, w której jeden informatyk na imprezie pożyczył drugiemu 100zł i po jakimś czasie przypomniał się koledze, aby ten mu je oddał. Wtedy drugi informatyk odpowiedział: „A czy masz na to logi?”.
O tym, czy warto zbierać i monitorować aktywności nie mamy zamiaru przekonywać, ponieważ samo sedno anegdoty daje nam ku temu przesłanki. To na czym chcielibyśmy się skupić to jak „z głową” podejść do takiego tematu i jak nie dać się kolokwialnie „wprowadzić w maliny” – o tym jest ten artykuł.
Zanim jednak przejdziemy do konkretów przedstawmy na początek nasze postrzeganie rzeczywistości oraz jak tę rzeczywistość możemy zakrzywiać w różnych kierunkach wykorzystując do tego odpowiednie narzędzia hackerskie i metody. Na koniec pokażemy sposoby na radzenie z chorobami tego typu – pokażemy możliwe szczepionki.
Mamy logi – wiemy wszystko co się dzieje w naszym królestwie. A może niekoniecznie?
Większość rozwiązań do bezpieczeństwa IT dostępnych na rynku, w tym zaimplementowanych i działających wśród wielu firm w głównej mierze bazuje na informacji pochodzącej z logów systemowych Microsoft i/lub innych systemów/urządzeń oraz aplikacji. Niektóre firmy do problemu monitorowania logów podchodzą bardzo ambitnie i ostrożnie wdrażając zaawansowane systemy klasy SIEM (ang. Security Information and Event Management), inne zbierają logi wykorzystując do tego aplikacje firm trzecich, a jeszcze inne po prostu archiwizują logi stosując do tego skrypty, żeby je mieć na wypadek awarii lub do celów dowodowych. Jest też odsetek takich firm, które problem monitorowania logów taktują po macoszemu lub jeszcze ich on nie dotknął, ponieważ nie posiadają na to odpowiednio przygotowanej infrastruktury i dedykowanego działu bezpieczeństwa IT.
W ciągu kilkunastu lat naszej obecności w środowiskach IT, w tym wśród działów Bezpieczeństwa IT spotkaliśmy się ze stwierdzeniem, że „Administratorzy dostarczają nam wszystkie logi z systemów, więc na pewno jesteśmy w stanie dobrze monitorować bezpieczeństwo”. Jak się okazuje podejście to może czasem bywać złudne, ponieważ to sam administrator definiuje audyt logów. Automatycznie rodzą nam się pytania: A kto pilnuje administratora? Czy inspekcja zdarzeń (audyt) jest właściwie zdefiniowana? Co się stanie, jeśli ktoś przechwyci nam konto administratora i zmieni audyt? Tworzy się nam się błędne koło i szereg pytań jak zatem efektywnie monitorować logi i cały chaos z informacją w nich zawartą.
Pisząc o audycie (inspekcji logów) w kontekście środowiska Microsoft nie sposób nie wspomnieć o logach Security będących kopalnią wiedzy o logowaniach użytkowników, informacjach o adresach IP, zmianach w systemie, odpalanych procesach, uzyskiwanych dostępach i wielu innych aktywnościach. O tym jak wydobyć ciekawe informacje z logów pisaliśmy w artykule: Jakie przydatne informacje z logów może pozyskać hacker?
Logi Security Microsoft są z pewnością jednym z najważniejszych źródeł informacji dostarczanych dla systemów bezpieczeństwa. Czy powinniśmy zatem na nich polegać/ufać w 100% i czy samo monitorowanie logów nam wystarczy? Będziemy w tedy bezpieczni? Jak się okazuje nie, ponieważ są możliwości ich obejścia, a także tuszowania po sobie aktywności.
Na dodatek, żeby nie było tak kolorowo Microsoft zostawił po sobie furtkę pozwalającą obejść chociażby rejestrowanie w logach Security niektórych operacji zmian w Active Directory np. wykorzystując atak DCShadow omawiany w innym naszym poście. Więcej o audycie Microsoft i jego słabościach pisaliśmy także w osobnym artykule.
Czy jest możliwe oszukanie mechanizmów rejestrowania logów tak, aby pozostać niezauważonym?
Niestety, ale odpowiedź i w tym przypadku pozostaje twierdząca. Mało się o tym mówi, ale w 2017 roku wyciekły z NSA narzędzia pozwalające ukrywać po sobie aktywności w logach Microsoft. Stwarza to ogromne możliwości twórcom złośliwego oprogramowania w tworzeniu kodu i funkcji, które będą czyściły działania malware po fazie exploitacji.
Grupa nazywająca siebie Shadow Brokers opublikowała kilka narzędzi i exploitów skradzionych z grupy Equation Group, cyberspies, którzy prawdopodobnie pracowali dla amerykańskiej Agencji Bezpieczeństwa Narodowego (NSA). Jednym z narzędzi ujawnionych przez Shadow Brokers w kwietniu 2017 jest DanderSpritz, poeksploatacyjny framework, który pozwala hakerom zbierać dane, omijać i dezaktywować systemy bezpieczeństwa oraz przemieszczać się różnymi kontami pomiędzy komputerami w zarażonej sieci (tzw. Lateral movement).
Interesującą wtyczką DanderSpritz jest EventLogEdit, który służy do manipulowania plikami dziennika zdarzeń Windows, aby pomóc napastnikom w ukrywaniu ich śladów. Podczas gdy narzędzia hakerskie, które modyfikują dzienniki zdarzeń, są niezauważane, EventLogEdit jest bardziej wyrafinowany w porównaniu do innych, ponieważ umożliwia usuwanie pojedynczych wpisów z dzienników zabezpieczeń, aplikacji i systemu, nie pozostawiając żadnych oczywistych wskazówek, że pliki zostały edytowane. Więcej o narzędzi EventLogEdit i o zasadzie jego działania tutaj
Ponieważ większość systemów bezpieczeństwa (np. SIEM, parsery logów itp.) bazuje na natywnych logach systemowych, w tej sytuacji nie będą one w stanie poprawnie wychwycić zmian/logowań – ponieważ w systemie operacyjnym nie będzie po tym śladu. Dziennik logów Microsoft (Security, Application ,czy System ) nie będzie posiadał zdarzeń sugerujących działanie malware.
Na rynku dostępne są też inne techniki manipulacji logów, o których pisaliśmy w artykule
Jak sobie zatem radzić w sytuacji manipulacji logów i jak się przed tym uchronić?
Odpowiedzi na to pytanie jest kilka. Przede wszystkim najlepiej, abyśmy w pierwszej kolejności:
Wdrożyli odpowiednią politykę bezpieczeństwa w firmie. Zdefiniowali odpowiednio role i dostępy użytkowników oraz wyeliminowali użycie kont uprzywilejowanych na stacjach roboczych. Odpowiednie zabezpieczenie kont gwarantuje nam 90% bezpieczeństwa, ponieważ większość ataków wykorzystuje konta uprzywilejowane i słabości w implementacji mechanizmów uwierzytelniania Microsoft (patrz kampania KILLCHAIN).
Zabezpieczyli końcówki klienckie, z których może dojść do ataku. Wdrożyli system antywirusowy, systemy antymalware oraz web proxy. Systemy te powinny sprawdzać podpinane urządzenia do komputerów, pocztę email oraz ruch internetowy – ponieważ to są najczęstsze źródła zagrożeń.
Monitorowali wszystkie konta uprzywilejowane i stosowali się do odpowiednich polityk ich użycia.
Jeśli powyższe mechanizmy zawiodą lub nie będą w pełni wystarczalne, bo może się zdarzyć, że malware wykorzystuje nieznane do tej pory podatności systemu lub interakcja z systemem nastąpiła w sposób niekontrolowany do tej pory. Powinniśmy zastanowić się nad niezależnym alternatywnym systemie audytu logów, w którym:
Dostarczyć niezależne od logów systemowych i wiarygodne źródło wiedzy na temat aktywności oraz zmian w środowisku. W sytuacji, kiedy powyższe metody zawiodą, a malware przedostanie się do systemu operacyjnego, będziemy w stanie niezależnie od logów systemowych dostarczyć materiał dowodowy posiadający swój własny mechanizm rejestrowania zdarzeń. Taki system powinien dostarczyć] nam informacje o logowaniach i zmianach w systemie oraz uzupełnić informacje, których brakuje w logach Microsoft.
Wdrożyli system do analizy ruchu sieciowego (dekodujący pakiety sieciowe do warstwy 7). Z takiego systemu dowiemy się, czy nastąpiła komunikacja pomiędzy poszczególnymi urządzeniami w sieci i jaka aktywność została zarejestrowana.
Jak widać na podstawie powyższego artykułu i opierając się na odpowiednich dowodach/narzędziach, jesteśmy w stanie doprowadzić do sytuacji, w której, zdefiniowany nawet najbardziej restrykcyjny audyt nie uchroni nas przed atakiem. Jak wskazują dobre praktyki, w dzisiejszych czasach samo monitorowanie logów nie jest wystarczające i nie gwarantuje nam 100% przejrzystości w działaniu systemów. Jeśli nie podejdziemy do tematu z pewnym rozsądkiem i profesjonalnie, będziemy wciąż narażeni na niekontrolowane włamania i niewiedzę co się wydarzyło w środowisku. Na rynku są dostępne metody maskowania po sobie aktywności, ale to, czy na to zezwolimy bądź nie, zależeć będzie od stanu konfiguracji naszego środowiska IT, jego odpowiedniego zabezpieczenia oraz świadomości w jakim świecie żyjemy. W dzisiejszych czasach istnieją wyrafinowane metody łamania zabezpieczeń i tylko od nas samych będzie zależeć to w jakim stopniu będziemy wstanie sprostać tym problemom.