W artykule postaramy się przybliżyć tematykę zbierania i analizy szeroko rozumianych logów systemów informatycznych. Wyjaśnimy przy okazji, czym jest ostatnio popularne ostatnio pojęcie SIEM.

Cechą wszystkich systemów informatycznych jest to, że zapisują logi, czyli prowadzą dzienniki swoich działań. Bez logów niemożliwe byłoby zarówno bieżące nadzorowanie takich systemów, jak też dochodzenie przyczyn ich awarii. Logi systemowe mogą być także kopalnią wiedzy na temat zagrożeń i ataków, z którymi przychodzi mierzyć się serwerom i aplikacjom. Niestety, to ostatnie zastosowanie najczęściej jest zaniedbywane.  

Każdy, kto kiedyś zaglądał w dzienniki jakiejś aplikacji dostępnej w sieci, choćby wewnętrznej, zdaje sobie sprawę, jak bogate życiea ona prowadzi: loguje użytkowników  bądź odmawia zalogowania, dostarcza określonych zasobów, wchodzi w interakcje z innymi systemami, nawiązuje własne połączenia, miewa problemy z działaniem, zamyka się i jest uruchamiana – przykładów jest wiele. Wśród takich rejestrowanych działań oczywiście mogą pojawiać się też takie, które wynikają z prowadzonego ataku (bo atak sieciowy to pewna sekwencja zdarzeń odnotowanych na poszczególnych urządzeniach), bądź już jego konsekwencji (np. wyprowadzanie danych). To teraz wyobraźmy sobie firmę, gdzie mamy serwery HTTP,  load balancery, serwery backupu, program kadrowy, aplikację do fakturowania, serwer dyskowy, programy antywirusowe i wszystko to spięte infrastrukturą sieciową, która także składa się z podsystemów, jak przełączniki, routery, access pointy czy zapory sieciowe. Każdy z tych elementów jest źródłem logów. Każde takie źródło podczas ataku cybernetycznego wygeneruje i zapisze informacje, które danego ataku będą dotyczyć.

Wyobraźmy sobie zatem, jaką ilość informacji firma powinna przetworzyć, żeby trzymać rękę na pulsie.  Przyjrzyjmy się teraz, dlaczego jednak warto to robić i jak można sobie taką pracę ułatwić.

Ze wszelakich statystyk wynika, że w cyklu życia incydentu najdłuższy jest czas od wykonania ataku do momentu jego wykrycia, który to najczęściej wynosi tygodnie lub miesiące (polecamy tu np. coroczne raporty Verizon).  W tymże okresie atakujący prawdopodobnie będą buszować po serwerze i sieci lokalnej ofiary, prowadząc podsłuch, wyprowadzając dane i próbując kompromitować kolejne systemy. Dlatego codzienna analiza logów powinna być częścią obowiązków administratora systemów IT, tak samo jak bieżąca obsługa takich systemów, wgrywanie aktualizacji itd. Wykonywanie obowiązku monitoringu logów można sobie na szczęście ułatwić, choćby gromadząc wszystkie dzienniki w jednym miejscu – a konkretnie systemie, który je będzie agregował. Taki system nosi fachową nazwę “loghost” i spowoduje, że nie trzeba będzie przeglądać logów na każdym systemie IT z osobna. Przede wszystkim jednak, widząc zdarzenia ze wszystkich systemów w jednym zestawieniu, doświadczony administrator może zauważyć związki (korelacje) pomiędzy nimi i wyciągnąć czasem krytyczne dla firmy wnioski.

Monitoring logów można zoptymalizować jeszcze bardziej. Stanie się to dzięki zastosowaniu aplikacji, którae będzie nie tylko logi agregować, ale także znajdować korelację pomiędzy nadesłanymi danymi i samoczynnie oceniać stopień zagrożenia na bazie pojedynczych, jak też skorelowanych informacji. Aplikacja taka może robić to w czasie rzeczywistym, wysyłając powiadomienia o sytuacjach, które uzna za groźne. Takie aplikacje nazywamy SIEM (Security Information and Event Management) i obecnie notujemy na rynku ogromny wzrost ich popularności.  Siła SIEM-ów leży przede wszystkim w dużej liczbie i jakości reguł korelacji, która jest w nie wbudowana. Reguły te odzwierciedlają sekwencje różnych ataków i wynikają z doświadczeń producentów SIEM, gromadzonych często latami, podczas monitorowania cyberprzestrzeni, jak też analizy konkretnych przypadków włamań. Ponadto aplikacje tego typu umożliwiają długoterminowe przechowywanie danych historycznych – a takie mogą być potrzebne, gdyby jednak doszło do włamania i trzeba by prześledzić jego historię. Środowiska IT w firmach mają raczej tendencje rozwojowe, podobnie jak liczba ataków na świecie.  Wymaga to zastosowania skalowalnego rozwiązania do analizy logów. Systemy SIEM wpisują się dobrze w takie potrzeby. Zwykle wraz ze wzrostem liczby źródeł danych do analizy wystarczy rozbudować zasoby sprzętowe systemu. Rynek aplikacji SIEM także nie będzie więc malał. Klient musi tylko dobrze wybrać. Jak ? – polecamy choćby zajrzeć do raportów Gartnera.

W niniejszym artykule chcemy nakreślić podstawowe zagadnienia związane z bezpieczeństwem aplikacji webowych.

Można śmiało powiedzieć, że aplikacje webowe to obecnie jeden z najbardziej rozpowszechnionych typów oprogramowania. Używając słowa „aplikacja”, mamy na myśli serwisy WWW, które generują zawartość dynamicznie, tj. zmieniają swój wygląd pod wpływem działań użytkownika. W tym znaczeniu aplikacją webową nie będzie np. statyczna (tj. zawsze posiadająca ten sam, niezmienny dla użytkownika wygląd) strona napisana w czystym języku HTML. Będzie nią natomiast już serwis napisany choćby w języku PHP, który przyjmuje i wykonuje akcje od użytkownika, np. wysłanie formularza, wyszukanie produktu czy zalogowanie. W wypadku wspomnianego PHP wypadałoby jednak zastrzec, że złośliwi twierdzą, iż pojęcie takie jak „programista PHP” jest sprzeczne samo w sobie (a wręcz że to oksymoron) i, co za tym idzie, taki sam charakter ma “aplikacja webowa w PHP”. Tak naprawdę jednak kod witryn pisanych w tym języku potrafi być zarówno bardzo skomplikowany, jak też może sprowadzać się oczywiście do pojedynczych wstawek PHP w kodzie HTML.

Z punktu widzenia bezpieczeństwa aplikacje webowe są znacznie bardziej interesujące niż statyczne strony HTML. Te ostatnie posiadają przede wszystkim znacznie mniejszą powierzchnię ataku. Dla porównania możemy wyobrazić sobie długi i gruby mur pozbawiony bram, zbudowany z dużych i identycznych cegieł – w charakterze strony statycznej, oraz drugi – równie gruby ale zbudowany z różnorakich budulców, jak cegły, pustaki, drewno czy kamienie użyte w różnych konfiguracjach i do tego wyposażony w wiele różnych bram. W tym drugim wypadku możliwość znalezienia słabego punktu będzie znacznie bardziej prawdopodobna – wspomniana powierzchnia ataku będzie większa. Tak jak właśnie w wypadku dynamicznych stron WWW – aplikacji webowych.

Strony WWW, które reagują zmianą wyglądu i zachowania na działania użytkownika, przede wszystkim muszą przyjmować od niego wartości różnych zmiennych, jak choćby login i hasło, język w którym będzie wyświetlana treść, wspomniana fraza do wyszukania treści czy nazwa produktu, którego szczegółowe dane zostaną wyświetlone. Takie zmienne przesyłane przez przeglądarkę (tzw. parametry zapytań) pozwalają witrynie WWW wejść w interakcję z użytkownikiem, przy okazji stanowiąc też niestety potencjalną furtkę do włamania. Przeglądarka WWW ogranicza co prawda zakres danych, które mogą zostać przesłane do danego serwisu webowego, ale atakujący nie jest z kolei ograniczony do używania przeglądarki. Sztandarowym narzędziem atakujących aplikacje webowe (ale także testujących ich bezpieczeństwo) jest tzw. „intercepting proxy” – czyli program, który pozwala przechwycić wysyłane przez przeglądarkę żądania, a następnie już dowolnie je modyfikować i przesyłać w takiej formie do atakowanego serwera.

W jaki sposób spreparowany parametr żądania może naruszyć bezpieczeństwo aplikacji? Otóż treść żądania HTTP przetwarzana w aplikacji jest zazwyczaj przez wiele warstw programowych, np. żądanie jest dekodowane, następnie mapowane na zasób dyskowy bądź konkretny segment kodu wykonywalnego aplikacji, dalej może trafić do systemu bazodanowego, z którego to zostanie pobrana odpowiedź. Na końcu użytkownikowi zostanie wyświetlona odpowiedź na jego żądanie, która będzie z nim związana pośrednio (np. poprzez zapytanie do bazy danych) lub bezpośrednio (np. użytkownik zobaczy jakie przed chwilą zapytanie wpisał w polu wyszukiwania). W praktyce warstw tych może być więcej, a na każdej z nich może okazać się, że programista za nią odpowiedzialny nie przewidział skutków jakie wywoła dostarczenie odpowiednio spreparowanych danych (czyli głównie parametrów żądań) bądź ich konfiguracji. Co więcej, może zdarzyć się także, że pozornie nieznaczące uchybienia bezpieczeństwa na kilku warstwach mogą zsumować się do bardzo groźnej podatności (zaryzykujmy tu użycie pojęcia synergii). Pojęcie warstw aplikacji możemy rozszerzyć na komponenty, tj. dana warstwa może być zbudowana z wielu różnych komponentów, którymi są najczęściej biblioteki programistyczne.

Ten krótki artykuł pozwoli nam zrozumieć, jak skomplikowany system może stać za zmieniającymi się podstronami w naszej przeglądarce WWW. Niestety, wysoki poziom skomplikowania powoduje adekwatne ryzyko występowania błędów.

Wyobraźmy sobie dobrze zaprojektowaną sieć firmy czy urzędu taką, gdzie serwery dostępne publicznie, obsługujące WWW czy pocztę, są celowo odizolowane od usług dostępnych wewnątrz organizacji (tzw. intranetu). Mówimy, że taka odizolowana grupa komputerów stanowi strefę zdemilitaryzowaną. Korzyść takiego rozwiązania jest bezsporna – w wypadku kompromitacji eksponowanych w Internecie usług atakujący, by dostać się do usług wewnętrznych musi pokonać jeszcze strzeżoną (np. przez firewalla, IDS’a)  granicę pomiędzy takimi usługami a wspomnianą strefą. Podejście godne pochwały i wydaje się, że pozbawione wad. Gdy jednak dodamy do tego taką ludzką cechę jak dążenie do zbyt dużego ułatwiania sobie pracy, okaże się, że i takie się znajdą.

W naszej praktyce audytorsko-pentesterskiej zdarzało nam się spotkać strefę zdemilitaryzowaną pozbawioną znacznej części środków ochrony, w jaką wyposażone były inne zasoby w organizacji. Weźmy na przykład witrynę webową, która to zgodnie ze sztuką powinna znaleźć się w takiej strefie. Nierzadko można spotkać się z poglądem, że wizytówka w sieci może być chociażby rzadziej łatana, słabiej monitorowana lub zaniedbywana przy testach penetracyjnych. No bo po co, skoro serwer WWW nie przechowuje żadnych poufnych danych, jak osobowe bądź finansowe, a w wypadku podmiany treści (tzw. defacing) przywrócimy ją szybko z kopii zapasowej. Po wszystkim zaś zaktualizujemy oprogramowanie serwera i po sprawie.

Niestety okazuje się, że kompromitacja internetowego serwera WWW niesie ze sobą nie mniej poważne zagrożenie, mimo że całkiem innego rodzaju i mniej oczywiste. W obecnych czasach intruzi nastawieni są bardzo pragmatycznie – od umieszczania manifestów czy własnych logo na przejętych serwisach wolą zarabianie pieniędzy. Skala zarobku jest tym większa, im bardziej znany bądź zaufany serwis.

Jak zarobić? Najprościej w treści skompromitowanej strony umieścić skrypt do kopania kryptowalut. Generowanie takich całkowicie wirtualnych (bo bez żadnego pokrycia rzeczowego) pieniędzy polega z grubsza na zamianie energii elektrycznej, mniej lub bardziej wyspecjalizowanego komputera (zwanego koparką), na jednostki kryptowaluty. Jeśli wstrzykniemy na znaną stronę odpowiednie skrypty, to komputery osób, które tę stronę odwiedzą, staną się koparkami. Wydajność “górnicza” przeglądarki internetowej jest mniej niż mała – ale od czego efekt skali. Serwisami, które dały się poznać ze złej strony bycia przymusowymi kopalniami dla odwiedzających były np. myfitness.pl, ladnydom.pl i gazeta.pl – należące do grupy Gazeta.pl, jak też np. muratordom.pl czy strona Gminy Kołbaskowo (pełna lista na stronie https://zaufanatrzeciastrona.pl/post/uwazajcie-bo-znane-strony-www-kopia-kryptowaluty-na-waszych-komputerach/).

Wstrzyknięcie skryptów kopiących na stronę firmy czy urzędu to jednak stosunkowo łagodny scenariusz dla ofiary. Docieramy wreszcie do sprawy zapowiedzianej w tytule, której nazwa zapożyczona jest z zoologii – metody wodopoju. Drapieżnik przyczaja się tam, gdzie spodziewa się skupiska potencjalnych ofiar – w okolicy łagodnego brzegu zbiornika wodnego. Atakujący, który chce zaatakować banki, włamie się na stronę często odwiedzanego przez bankierów serwisu i tam umieści swoje skrypty, które zostaną wykonane przez ich przeglądarki.

Czy skrypt uruchamiany przez odwiedzaną przez nas stronę może wyrządzić nam szkodę inną, niż wyżej wspomniana kradzież mocy obliczeniowej? Niestety tak, a sprawę przesądzą tu aktualność przeglądarki, jej dodatki oraz liczba nieujawnionych do wiadomości publicznej podatności (tzw. 0-day) powyższych komponentów.  Polskie banki faktycznie zostały zaatakowane w październiku 2016 r., a wodopojem była strona Komisji Nadzoru Finansowego. Umieszczone w niej skrypty analizowały i atakowały niezałatane przeglądarki internetowe bankierów, zupełnie nie spodziewających się z tej – nomen omen – strony ataku. Za atakiem najprawdopodobniej stała grupa Lazarus, należąca do północnokoreańskiego RGB (piszemy o tym też tutaj: https://imns.pl/akademia/hacking-socjalistyczny/). Straty finansowe nie zostały podane do wiadomości publicznej.

Czy do atakowania użytkowników przez ich przeglądarki potrzeba zaawansowanej wiedzy? Niestety aktualnie już nie. W obszarze cyberbezpieczeństwa istnieje trend, by otwarcie dzielić się oprogramowaniem do testów podatności. Efektem ubocznym tego zjawiska jest, iż takie oprogramowanie służy zarówno do zamawianych, jak i tzw. “niezamawianych testów bezpieczeństwa”. Przykładem jest platforma BeEF – Browser Exploitation Framework, która jest niczym innym, jak zestawem skryptów do łamania bezpieczeństwa internetowych przeglądarek. Po uruchomieniu pobierają one kolejne rozkazy do wykonania ze zdalnego centrum kontroli. Zidentyfikowano dziesiątki stron, będących wodopojami z zainstalowanym oprogramowaniem BeEF, w tym wiele witryn organów rządowych różnych państw.

Trudno wyobrazić sobie większą utratę zaufania do organizacji (pomijając tu jednak wpadki Facebooka, jak np. ta z Cambridge Analytica), niż wynikającą z dopuszczenia przez nią do atakowania odwiedzających jej witrynę potencjalnych klientów. Czy na pewno więc bezpieczeństwo naszej wizytówki w sieci nie zasługuje na więcej uwagi?