O bezpieczeństwie aplikacji webowych z lotu ptaka

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.

Metoda wodopoju, czyli dlaczego bezpieczeństwo strony WWW organizacji jest bardziej istotne niż się może wydawać.

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?

 

 

Badanie bezpieczeństwa infrastruktury sieciowej jako element proaktywnego podejścia do zarządzania bezpieczeństwem.

W niniejszym artykule omówimy metody, które mogą służyć do oceny stanu bezpieczeństwa sieci komputerowej. Najprościej mówiąc (za Słownikiem Języka Polskiego) stan bezpieczeństwa to stan braku zagrożeń. Bezpieczny system komputerowy to zatem system posiadający cechy, które skutecznie utrudniają nieuprawniony dostęp do jego zasobów.

Opiszemy różne metody określania i podnoszenia bezpieczeństwa w systemach IT.  Pokażemy też, że brak widocznych symptomów włamania nie daje miarodajnej wiedzy na ten temat oraz wskażemy, skąd taką wiedzę powinniśmy czerpać.

Metody ochrony sieci i systemów komputerowych najprościej można podzielić na reaktywne oraz proaktywne.

Metody reaktywne można przez analogię porównać do alarmu i monitoringu wizyjnego w budynku mieszkalnym. Spowodują wszczęcie alarmu po wykryciu podejrzanego działania, bądź też dostarczą informacji, na podstawie których operator będzie w stanie wywnioskować, że dzieje się coś niepożądanego. Wymieńmy podstawowe metody reaktywne w systemach IT:

  • Sensory IDS/IPS (ang. Intrusion Detection/Prevention Systems)
  • Monitoring ruchu sieciowego i logów (w szczególności zastosowanie tzw. systemów SIEM)
  • Kontrola integralności danych (przede wszystkim plików)
  • Zarządzanie incydentami (w szczególności skuteczne przerwanie incydentu)

Wymienione wyżej nazwy sugerują same, że chodzi tutaj o wykrycie konkretnego zdarzenia, czyli mówiąc bardziej fachowo: incydentu bezpieczeństwa. Incydent taki jest pojęciem szerokim i może składać się z kilku etapów, takich jak: rekonesans, kolejne próby przełamania wybranych zabezpieczeń, a następnie zainstalowanie ukrytej furtki (ang. backdoor) oraz finalnie eskalacja uprawnień – przełamanie kolejnych, głębszych zabezpieczeń, w celu osiągnięcia jak najwyższych praw dostępu lub najbardziej cennych danych. Wymienione powyżej przykładowe metody reaktywne odpowiadają różnym etapom ataku i mogą tu zadziałać z osobna lub łącznie.

Sens zastosowania takich metod jest oczywiście bezsporny, niemniej jednak zasadne byłoby postawienie tu prostego pytania – „Czy to nie jest już trochę za późno?”.

Wracając  do naszej analogii z budynkiem mieszkalnym – świetnie jest mieć informację o fakcie włamania się, ale idealnie byłoby, gdyby do tego włamania w ogóle nie doszło. Ponadto, czy brak sygnałów z systemów reaktywnych świadczy o wysokim bezpieczeństwie, czy może raczej o wysokich kompetencjach atakującego, który potrafi np. rozciągać atak w czasie, manewrować źródłowymi adresami IP i technikami oraz dysponuje zaawansowanymi “backdoorami” integrującymi się z głębokimi warstwami systemów operacyjnych?

Co więcej, już po uzyskaniu dostępu, atakujący z reguły nadal będzie chciał pozostać niezauważony przez długi czas, który umożliwi mu zorientowanie się, jakie dane i zasoby warte są jego uwagi.

W tym właśnie miejscu należałoby odwołać się do istnienia metod proaktywnych. Idąc w ślad za pierwotną definicją proaktywności – z obszaru psychologii – można powiedzieć, że są to metody polegające na kontrolowaniu danych sytuacji, przewidywaniu negatywnych scenariuszy oraz – co najważniejsze – zapobieganiu im.

Wracając do świata IT, metodami proaktywnymi określania i podnoszenia bezpieczeństwa są:

  • Skanowanie pod kątem podatności (popularnie zwane „skanami bezpieczeństwa”)
  • Wykonywanie testów penetracyjnych
  • Wywiad zagrożeń (ang. threat inteligence)
  • Stosowanie polityk i procedur bezpieczeństwa

Jak widać, wszystkie powyższe metody, w odróżnieniu od wcześniejszych, mają charakter zapobiegawczy. Skupmy się na dwóch pierwszych – obie polegają na badaniu odporności systemów i są metodami technicznymi.

Skanowanie pod kątem podatności to proces w dużej mierze zautomatyzowany. Dedykowany takiemu zadaniu skaner posiada bazę tysięcy znanych podatności, podatnych wersji oprogramowania i słabych konfiguracji usług. Baza taka służy do porównania z obrazem testowanej sieci, jaki jest uzyskiwany w procesie skanowania. Za wynikami takiego skanu oczywiście powinno pójść wprowadzenie poprawek i zabezpieczeń (oraz optymalnie ponowny skan). Jeśli skany są wykonywane regularnie od momentu powstania danej infrastruktury IT, to nasza pewność co do tego, że nie została ona gdzieś po drodze zasiedlona przez niepożądanych gości, powinna znacznie wzrosnąć – analogicznie jak w wypadku budynku z przeciwwłamaniowymi oknami, drzwiami i zamkami.

Pogłębioną względem skanów metodą analizy podatności są testy penetracyjne. W tym podejściu wyniki skanów stają się zaledwie wstępem do dalszych działań i stanowią fazę rekonesansu dla ataków. Mówimy oczywiście o atakach kontrolowanych i symulowanych, bo tak można określić testy penetracyjne. Testy penetracyjne od prawdziwych ataków różnią się jednak zasadniczo. Przede wszystkim:

  • Dotyczą możliwie szerokiej gamy podatności (komponentów), a nie jednej lub kilku
  • Są ograniczone czasowo
  • Nie mogą zaszkodzić testowanemu środowisku (jeśli jest produkcyjne)
  • Kończą się raportem

Czasochłonność ich wykonania względem skanów bezpieczeństwa jest znacząco większa, ponieważ w dużo większym stopniu angażuje się tu ludzi (ekspertów). Należy jednak stwierdzić, że o ile poprawnie przeprowadzone skany chronią przed podstawowymi i masowymi zagrożeniami z Internetu, to w wypadku testów penetracyjnych mówimy o ochronie przed atakami bardziej zaawansowanymi – podobnie jak one same prowadzonymi przez ludzi, a nie automaty.

O testach penetracyjnych, jak i innych proaktywnych metodach można by napisać jeszcze wiele ale to już temat na kolejne artykuły naszego bloga. 🙂

©Prawa autorskie. Wszystkie treści opublikowane na tym blogu objęte są prawami autorskimi. Zabrania się kopiowania, rozpowszechniania i ich odtwarzania bez zgody autora.

Błażej Bednarski – autor

Jest wieloletnim ekspertem z zakresu zarządzania systemami IT i bezpieczeństwa. Specjalizuje się w analizach podatności i testach bezpieczeństwa.