[OWASP Top 10] A10

Cześć!

To już ostatni odcinek z serii OWASP Top 10, w której tłumaczę 10 najpopularniejszych błędów powiązanych z witrynami internetowymi.

Dzisiaj o ostatnim błędzie z listy, czyli o niewystarczającym logowaniu oraz monitorowaniu.

I myślę tutaj, że może pojawić się pytanie: ale jak to? Przecież brak logowania to nie jest błąd sam w sobie.

Przecież jeżeli nic nie logujemy to też nic nie może zostać wykradzione.

Poza tym jak ktoś miałby włamać się do naszego systemu tylko przez to, że nie logowaliśmy jakichś danych.

I rzeczywiście ten punkt jest nieco kontrowersyjny.

Zastanówmy się zatem nad powodami, dlaczego został umieszczony na tej liście na zaszczytnym, ostatnim miejscu.

Według raportu IBM w 2016 roku wykrycie włamania do firmy zajęło średnio 191 dni.

Całkiem sporo czasu. I właśnie o to chodzi w tym punkcie.

Jeżeli nie posiadamy logów, to nawet jeżeli wykryjemy po pewnym czasie włamanie - tak naprawdę dalej jesteśmy w punkcie wyjścia.

Nadal nie wiemy bowiem kiedy ono nastąpiło, co było powodem - czy błąd w oprogramowaniu, a może nieuwaga pracownika.

A co najważniejsze: jakie dane zostały skradzione, czy atakujący wprowadził jakieś zmiany do naszego systemu, jak również ciężko odpowiedzieć na pytanie, czy dalej nie posiada on dostępu do naszych danych?

Jeżeli nie wiemy co było powodem ataku, nie wiemy również czy ten powód dalej nie istnieje.

Stąd też taki nacisk, aby logować wszędzie tam gdzie jest to możliwe.

Zacznijmy więc od najprostszych rzeczy, które niejako same nasuwają się kiedy myślimy o tym temacie.

Na pierwszy ogień idzie więc monitorowanie nieudanych, jak również udanych prób logowania do naszych systemów.

Jeżeli posiadasz chwilę wolnego czasu, warto postawić sobie tymczasowy wirtualny serwer z obsługą SSH - wystawiony na cały świat.

Średnio już po kilkunastu minutach w logach odnajdziemy informacje na temat prób logowania się na taki serwer.

Takie próby mają miejsce cały czas i właśnie to powinien pokazać ten eksperyment.

Używając tych danych możemy skonfigurować bowiem odpowiednie systemy, w stylu fail2ban, które po pewnej ilości prób zablokują dany adres IP na pewien czas.

Wspomniałem jednak o logowaniu również prób, który były udane.

Dlaczego? Jeżeli ktoś pozyskał dane do logowania, na przykład przy pomocy jakiejś strony phishingowej - prędzej czy później będzie próbował ich użyć.

A takie logowanie powiedzie się. W logach jednak zobaczymy adres IP, z którego nastąpiło logowanie.

Jeżeli jesteśmy polską firmą i wszyscy pracownicy pracują właśnie stąd, to logowanie się z adresu kanadyjskiego może być nieco dziwne.

Równocześnie takie logowanie pozwala zobaczyć jak wygląda nasza sieć i infrastruktura w normalnych warunkach - czyli wtedy, kiedy nikt nas nie atakuje.

Łatwiej wtedy będzie wykryć na tej podstawie anomalie.

Jeżeli pracujemy od 8 do 16 po co ktoś miałby się logować o 19?

Albo dlaczego jakaś maszyna nagle została zresetowana, chociaż nikt z działu IT nie poinformował o planowanym maintenance danego serwera?

Ale gdzie te dane logować?

Najlepiej do jakiegoś jednego systemu - tak, aby można było je wszystkie razem grupować, sortować i przeszukiwać.

Osobne logi ma bowiem firewall, osobne każdy z serwerów. Do tego dochodzą jeszcze dane z komputerów pracowników, antywirusów i Windowsa.

Można się w tym wszystkim pogubić.

No i warto też ustawić odpowiednie uprawnienia do tych plików - tak aby nikt nie mógł ich usunąć.

Pomijam już kwestię retencji - wszak dużo danych to dużo miejsca, a dużo miejsca to spore koszty - lecz logi przetrzymywane 24 godziny na wiele nie pomogą.

Dochodzi jeszcze kwestia ich integralności - czy ktoś może je edytować i czy będziemy w stanie wykryć taką edycję.

A może logowanie da się po prostu globalnie wyłączyć?

W przypadku Amazona logi mogą być przechowywane w CloudTrail.

Usługę tą włącza się per region.

Jeżeli zatem zapomnimy, że część serwerów hostowana jest w Stanach zamiast Europie i tam również nie uruchomimy tej usługi - nic nie zobaczymy.

Atakujący posiadający odpowiednie uprawnienia może również tą usługę po prostu wyłączyć.

Inne opcje to usunięcie kubełka S3, w którym przechowywane są wszystkie dane.

Jeżeli kubełek nie istnieje - dane nie mają się gdzie zapisywać, więc logowanie nie działa.

Warto też pomyśleć o synchronizacji zegarów na wszystkich maszynach.

Jeżeli bowiem na jednym serwerze czas zostanie zresetowany albo nie będzie odpowiednio ustawiony, nagle może się okazać że logi owszem - posiadamy, ale nie jesteśmy w stanie skorelować wszystkich informacji ponieważ różne serwery używały różnego czasu.

Również błędy z aplikacji czy też serwera bazodanowego mogą być wyznacznikiem potencjalnego ataku.

Jeżeli bowiem produkcyjna aplikacja działająca stabilnie i bez błędów nagle zaczyna rzucać wyjątkami, może to oznaczać, że ktoś próbuje przygotować działający atak "object injection" i jego dotychczasowy exploit nie działa w pełni produkując błędy.

Długie zapytania w bazie danych mogą oznaczać błędy typu "Blind SQL Injection", gdzie wykorzystując czas próbuje się zwrócić wartości binarne.

Logi z CSP mogą wskazywać na próby ataków XSS.

Nie zawsze pierwszy atak się udaje. Czasami dany atak zadziała dopiero za którymś razem - a monitorując te próby możemy w porę załatać aplikację.

To samo tyczy się komputerów i laptopów naszych pracowników.

Czy monitorujemy aplikacje, które uruchamiają a także logi antywirusa?

A może któryś z nich próbował podłączyć pendrive?

Łączenie się z obcymi serwerami przy pomocy SSH, RDP lub TeamViewer to nie jest standardowa praktyka.

Akcje o szczególnym znaczeniu winny być dodatkowo monitorowane.

Tworzenie nowego administratora lub też generowanie nowego klucza API to nie jest czynność, którą wykonuje się na co dzień.

Na koniec - logi mogą zawierać praktycznie wszystko w zależności od serwisu, jaki posiadamy.

To oznacza, że przed przypadek mogą się tam znaleźć również informacje poufne.

Winniśmy dołożyć wszelkich starań, aby hasła, numery kart lub innych wrażliwych danych były zamieniane na gwiazdki.

Dalej jednak dostęp do logów winien być przydzielane wąskiemu gronu osób, które potrzebują go do pracy.

Teraz już widzisz jak wiele małych klocków musi odpowiednio zadziałać, aby monitorowanie było skuteczne.

Tylko wtedy w razie problemów będziemy w stanie odpowiedzieć na pytania kto, gdzie i dlaczego, jak również zgłosić prawdopodobny wyciek do organów państwowych oraz poinformować użytkowników, których dane mogły być zagrożone.

A ten temat jest tym ważniejszy, po wprowadzeniu w naszym kraju RODO, które może nałożyć na firmę karę w przypadku niedopełnienia formalności.

Jak bowiem mamy skontaktować się z potencjalnymi ofiarami, jeżeli nie wiemy jakie dane zostały wykradzione?

Free stock footage by Videezy.com

Stock footage provided by Videvo, downloaded from https://www.videvo.net

Icon made by Smashicons, Freepik www.flaticon.com