Lekcja z Plus Banku

Włamanie do systemu transakcyjnego Plus Banku sprawiło, że powrócił temat związany z obroną aplikacji webowych przed atakiem. Większości podobnych zdarzeń można było zapobiec, a samą organizację – przygotować na to, co może się zdarzyć.

W przypadku instytucji finansowych jednym z ważniejszych punktów jest samoobsługowy system dostępu do usług przez Internet. Jest to przeważnie aplikacja webowa, przeznaczona do realizacji transakcji finansowych, a zatem charakteryzuje się wysokim poziomem ryzyka i wymaga szczególnej ochrony. Przejęcie kontroli nad taką aplikacją przez włamywacza skutkuje bardzo poważnymi stratami okradzionej firmy – o takim zdarzeniu pisaliśmy w artykule „Poważne włamanie do systemu transakcyjnego polskiego banku” (Computerworld.pl, 09 czerwca 2015r.). Zdarzeniom tym można było zapobiec.

Historia poważnego włamania

Jeden z internautów, posługujący się pseudonimem Polsilver na największym polskojęzycznym podziemnym forum dyskusyjnym TORepublic przyznał się do ataku na serwis transakcyjny Plus Banku. Polsilver pisze o przejęciu 15 tysięcy kont, do których dostępne były loginy i hasła, rozpoznaniu działania aplikacji systemu transakcyjnego i ominięciu konieczności potwierdzania przelewów za pomocą hasła SMS. Wspomina o przejęciu danych osobowych, informacji o transakcjach z wielu rachunków (w tym prezesa Polkomtela – Tobiasa Solorza) oraz kart płatniczych, a także o kradzieży znacznej kwoty pieniędzy, rzędu miliona złotych. Włamywacz zażądał od banku wypłacenia okupu. Opisywanym zdarzeniom można było zapobiec za pomocą odpowiednich procedur, a także powszechnie dostępnych rozwiązań technicznych.

Zobacz również:

Zablokować niepożądane zapytania

Aplikacja webowa jest stosunkowo łatwym celem, co znajduje swoje odzwierciedlenie w liczbie rejestrowanych podatności i incydentów. Za większość udanych ataków odpowiadają dwie kategorie luk – wstrzyknięcie kodu (pierwsze miejsce listy OWASP) oraz błędy w wykorzystywaniu skryptów (Cross-Site Scripting, miejsce trzecie na liście OWASP). Kolejne podatności polegają na wykorzystaniu błędów w uwierzytelnieniu oraz niebezpiecznym wywołaniu obiektów. Obrona przed najważniejszymi atakami polega na tym, by aplikacja nie przetwarzała wprowadzonych danych, które wykraczają poza dopuszczalne parametry (usunięcie podatności) albo na tym, by takich danych do aplikacji nie dopuścić, blokując je na zaporze sieciowej WAF (web application firewall). Czasami pojawiają się jednak problemy wynikające ze złożoności dzisiejszego oprogramowania.

Karl Triebes, CTO firmy F5 mówi: „problem polega na tym, że większość urządzeń nie odróżnia tego, co dozwolone, a co nie w danej aplikacji webowej. Większość rozwiązań do poszukiwania ataków wykorzystuje sygnatury, które dopasowuje do strumienia danych. W ten sposób można znaleźć użycie konkretnego eksploita, ale nie da się wykryć ataku takiego jak forceful browsing. Nasze podejście zakłada obserwację transakcji oraz przepływu pytań i odpowiedzi do aplikacji, a następnie automatyczne zbudowanie założeń polityki zezwalającej lub blokującej zapytania. Tę politykę można dostosować i po eliminacji ewentualnych fałszywych alarmów otrzymuje się zestaw reguł, które pozwolą na sprawne odfiltrowanie typowych ataków. To podejście będzie działać także w przypadku aplikacji w chmurze”.

Obronić się przed atakiem wewnątrz SSL

Rośnie udział zdarzeń bezpieczeństwa w szyfrowanych połączeniach

W badaniu ruchu sieciowego przeprowadzonym przez IDG Poland, aż 17,9% zgłoszeń rejestrowanych przez system obejmowało ruch HTTPS na domyślnym porcie 443. Oznacza to, że inspekcja i ochrona przed zagrożeniami przechodzącymi wewnątrz szyfrowanych połączeń będzie bardzo istotna w praktyce działań mających na celu utrzymanie bezpieczeństwa systemów IT w kolejnych latach.

Jedynym sposobem zapewnienia poufności transmisji danych przez niepewne medium, jakim jest Internet, jest skuteczne szyfrowanie danych. Wewnątrz szyfrowanego połączenia SSL można jednak przesłać praktycznie dowolne porcje informacji, w tym także pakiety związane z atakami na webowe aplikacje. Aby taki atak odfiltrować, należy zapewnić widoczność informacji, która jest przesyłana na drodze klient – serwer wewnątrz szyfrowanego połączenia.

Karl Triebes wyjaśnia: „wewnątrz połączenia zabezpieczanego przez SSL można wysłać każdy z typowych ataków na aplikacje i dla zapór sieciowych starszej generacji taki atak będzie niewidoczny. Aby dokonać analizy, można wstrzymać ruch na urządzeniu, a następnie deszyfrowany strumień filtrować na zaporze aplikacyjnej WAF oraz za pomocą systemu IPS. Jeśli założenia polityki bezpieczeństwa wymagają szyfrowania komunikacji wewnątrz firmowego centrum danych, ruch po inspekcjimożna z powrotem zaszyfrować na drodze od zapory do serwera. W ten sposób systemy bezpieczeństwa mogą chronić aplikacje webowe także przed atakami realizowanymi w szyfrowanym połączeniu SSL”.

Obecnie mamy do czynienia z radykalnym wzrostem udziału szyfrowanych połączeń – jeszcze kilka lat temu rzadkością był udział na poziomie wyższym niż 40% ogółu ruchu z datacenter. Obecnie w niektórych instytucjach obserwuje się odsetek ruchu SSL na poziomie 80%, a serwisy, takie jak Facebook lub usługi Google'a domyślnie szyfrują wszystkie połączenia. Następnym krokiem będzie zatem wzrost liczby i powagi incydentów związanych z ruchem SSL.

Wykryć manipulacje aplikacją

Przy konstrukcji aplikacji najpoważniejsze założenie dotyczy klienta – autorzy aplikacji milcząco zakładają, że klientem będzie przewidywalna w działaniu przeglądarka internetowa. Wiele ataków wykorzystuje ten fakt i polega na modyfikacji parametrów przesyłanych z powrotem do serwera. Podmianie mogą ulegać wartości pól formularzy, parametry wywołań, adresy URL, a także sam kod aplikacji. Takie zmiany zazwyczaj wykonuje złośliwe oprogramowanie na stacji roboczej, ale może to również zrobić włamywacz lub tester podatności za pomocą specjalnie przygotowanego narzędzia, takiego jak burp lub ZAP. Modyfikacje działania aplikacji webowej można jednak wykryć.

Karl Triebes wyjaśnia: „parametry aplikacji chronimy za pomocą specjalnego kodu JavaScript umieszczanego przez urządzenie w strumieniu komunikacji oprogramowania. Każde pole formularza, każdy parametr, zawiera kryptograficzną sumę kontrolą. Sumę tę można sprawdzić, wykrywając każdą modyfikację wprowadzoną przez włamywaczy lub złośliwe oprogramowanie. Kod JavaScript wysyła informacje w taki sposób, że można wykryć próbę modyfikacji także po stronie klienta aplikacji webowej”.

Nadać odpowiednie uprawnienia

Niezależnie od innych technik obrony przed atakami, strategia stosowania minimalnych przywilejów koniecznych do wykonania danego zadania znacząco utrudnia włamywaczowi działanie w atakowanych systemach IT. Niestety w wielu przypadkach aplikacje webowe mają zbyt wysokie uprawnienia.

Marcin Kozak, architekt bezpieczeństwa informacji w firmie Oracle Polska mówi: „Wiele mówi się o koncepcji nadawania minimalnych uprawnień, tych niezbędnych z punktu widzenia działania biznesu, ale niewiele jest firm, które tą koncepcję realizują. Myśląc o uprawnieniach, należy rozważać podejście całościowe, tj. uwzględniać proces uwierzytelnienia, bezpieczeństwo repozytorium, aplikacji i usług, a nie tylko wycinek, taki jak pojedyncza aplikacja webowa. Zarządzanie uprawnieniami jedynie na poziomie aplikacji przy otwartym dostępie do repozytorium sprawia, że pozostawia się wiele furtek włamywaczom. Z naszych badań wynika, że nawet 40% uprawnień jest nadmiarowych. Często spotyka się sytuację w której uprawnienia systemowe, które umożliwiają odczytanie lub zapis do każdej tabeli w bazie, są nadawane zwykłym użytkownikom bez właściwej weryfikacji czy faktycznie istnieje taka potrzeba biznesowa. Jeśli dostawca aplikacji przygotowuje listę uprawnień, na której są uprawnienia systemowe wysokiego ryzyka – jak przykładowe SELECT ANY TABLE – to klient powinien się zastanowić, zanim podpisze odbiór takiego systemu. Po podpisaniu umowy wszystkie ryzyka przechodzą na klienta mimo to, że to nie on te aplikacje projektował. Warto zastanowić się, czy biznes, odpowiedzialny za aktywa informacyjne, rozumie mechanizmy uprawnień nadawanych przez IT, zwykle opisane technicznym językiem”.

Odeprzeć atak odmowy obsługi

Jednym z coraz częściej spotykanych ataków jest zablokowanie pracy aplikacji za pomocą różnych żądań – atak odmowy obsługi. Najczęściej spotykanym atakiem jest DDoS wolumetryczny, w którym serwery atakowanej organizacji są bombardowane żądaniami pobierania obiektów lub po prostu pakietami TCP i UDP (takimi jak nadzwyczaj popularny atak TCP SYN flood). Drugim pod względem popularności rodzajem ataku jest wypełnianie zasobów serwera przez bardzo wolne połączenia. Niezależnie od stosowanej techniki ataku, jego skutkiem jest niedostępność danej usługi, strony lub aplikacji i spowodowane tym straty.

Karl Triebes mówi: „Wolumetryczny atak DDoS może przyjąć tak dużą skalę, że będzie wymagać filtrowania w centrum danych, które znajduje się możliwie blisko punktu styku między operatorami. Atak polegający na ciągłym pobieraniu dużych obiektów można zablokować, wprowadzając obowiązek zalogowania lub przepisania obrazków CAPTCHA. Coraz częściej mamy jednak do czynienia z atakami powolnymi, w których klient pobiera dane z nadzwyczaj małą prędkością, wolniej niż nawet najwolniejsze z łączy mobilnych, wypełniając przy tym wszystkie dostępne połączenia serwera. Obrona przed takim atakiem polega na odrzucaniu tych nadzwyczaj powolnych połączeń na zaporze sieciowej, przy czym sesja może być maskowana, by do serwera w ogóle nie docierała”.

Zapewnić powtarzalność cyklu bezpieczeństwa

Specjaliści podkreślają, że bezpieczeństwo nie jest stanem w danej chwili, ale jest to proces, który wymaga ciągłych działań. W omawianym przypadku obrony aplikacji webowej niezbędne będzie zatem przyjęcie założenia, że każda wersja aplikacji najprawdopodobniej zawiera podatności, dla których muszą być wprowadzone odpowiednie działania zaradcze. Cykl rozwoju aplikacji obejmowałby zatem testowanie podatności przed wydaniem każdej wersji, testy penetracyjne w środowisku testowym oraz produkcyjnym. Należy przy tym pamiętać, że testy penetracyjne muszą obejmować całość platformy, włącznie z serwerami, warstwą middleware oraz bazami danych. W ten sposób można będzie wychwycić przeważającą większość typowych podatności wynikających z niedopatrzenia programistów (błędy takie jak SQL Injection), braku wprowadzenia aktualizacji oprogramowania lub jego niewłaściwej konfiguracji oraz źle nadawanych uprawnień. Wynik audytu bezpieczeństwa, zawierający konkretny spis podatności musi uruchamiać procedurę niezwłocznego usuwania tych luk. Skuteczność tej procedury należy sprawdzać. Jest to możliwe także w przypadku projektów rozwijanych w modelu Agile – przykładem może być opis budowy i wdrożenia aplikacji Everest w PZU S.A. (Computerworld 22/2014). Zagadnienia związane z integracją badania podatności aplikacji z cyklem jej rozwoju również opisywaliśmy w artykule „Jak zabezpieczyć aplikację webową” (Computerworld 8-9/2015).

Skorzystać z ubezpieczenia

Na dojrzałych rynkach ubezpieczeniowych (w tym amerykańskim, australijskim i nowozelandzkim) firmy mogą skorzystać z ubezpieczenia od strat spowodowanych atakiem cybernetycznym. Aby skorzystać z tego ubezpieczenia firma musi spełnić pewne warunki, między innymi posiadać odpowiednie procedury, zarządzanie ryzykiem, testy aplikacji oraz wymagane wyposażenie do obrony przed atakami. Obecnie oferta ubezpieczeniowa tego rodzaju w naszym kraju jest niemal nieznana, a same firmy nie wydają się przygotowane do tego, by z niej korzystać.

Wykryć złośliwe oprogramowanie

Jednym z powszechnych problemów, z którymi musi się zmierzyć firma świadcząca usługi za pomocą aplikacji webowych, jest obecność złośliwego oprogramowania, zarówno na stacji roboczej, jak i na urządzeniach mobilnych.

Bartosz Chmielewski, inżynier w firmie Intel Security mówi: „problem nie jest nowy – ze złośliwym oprogramowaniem mamy do czynienia od dawna, ale ostatnimi czasy znacząco się nasilił. Chodzi tu o poziom skomplikowania kodu złośliwego i zaawansowanych technik zmierzających do utrudnienia wykrywania takiego kodu. Systemy sygnaturowe działają niezawodnie, ale tylko w sytuacji, gdy kod jest znany producentowi rozwiązania bezpieczeństwa, które wydaje również sygnatury. Dziś kod złośliwy często tworzony jest na potrzeby jednego ataku lub szeregu jednoczesnych ataków i okres jego eksploatacji jest krótki, a zatem definicja w systemach sygnaturowych czy reputacyjnych pojawia się zbyt późno. Aby podnieść swoją skuteczność przy walce ze złośliwym oprogramowaniem, niezbędne stają się rozwiązania klasy sandbox, które wykrywają podejrzaną aktywność oprogramowania automatycznie uruchamianego w testowym środowisku. Nietypowe zachowania mogą być wykryte zarówno przez systemy klasy SIEM, jak i specjalne komponenty systemów IPS i dzięki temu mogą nam wskazać komputery, które już zostały zainfekowane lub nawet procesy, które za tę infekcję są odpowiedzialne”.

Brak odpowiedzi to najgorsza odpowiedź

Eksperci do spraw bezpieczeństwa podkreślają, że w historii wielu organizacji zdarzają się poważne incydenty, które przeradzają się w sytuacje kryzysowe. W takim przypadku kluczem do minimalizacji skutków zdarzenia będzie szybkie przygotowanie i wdrożenie odpowiedzi na zagrożenie. Odpowiedź powinna zawierać także czytelny komunikat związany z samym incydentem. W artykule „Podnieść firmę z kolan” (Computerworld 1-2/2015) omawiane były zdarzenia, w tym komunikaty, które należy podjąć po zaistnieniu sytuacji kryzysowej związanej z zagrożeniem cybernetycznym. W przypadku ataku hakerskiego przeciw systemowi transakcyjnemu banku takiej komunikacji ze strony zarządu zabrakło. Autorzy portalu Zaufana Trzecia Strona informują, że otrzymali oficjalne wezwanie od radcy prawnego reprezentującego bank, wzywające do zaniechania publikacji, które miały naruszać dobra banku, a nieco później także anonimową groźbę wypełniającą znamiona przestępstwa ściganego na mocy art. 190 par. 1 KK.

Tomasz Chlebowski, prezes zarządu ComCERT komentuje: „Bank nie był dostatecznie zabezpieczony, nie posiadał wdrożonych odpowiednich procedur. Przewlekanie komunikacji i dużo prawnych ostrzeżeń to brak profesjonalizmu. Zamiast z otwartą przyłbicą podjąć temat (zdarzenia i odpowiedzi na problem – przyp.red.), postępuje zgodnie z najgorszymi wzorcami”.

Z tą opinią zgadza się także Bartosz Leoszewski, prezes firmy FancyFon S.A. i mówi: „zgadzam się z zarzutami o nieprofesjonalnym zachowaniu. Moim zdaniem zawiniło nieprzygotowanie i niewdrożenie w życie procedur. Nie wiemy, czy zabrakło rozwiązań technicznych, ale wiemy na pewno, że właściwe procedury nie zadziałały”.

(wypowiedź podczas panelu dyskusyjnego na konferencji Samsung Business Summit, 09 czerwca 2015r.)


TOP 200