Prezentujemy Wam drugi numer naszego nowego, S.M.S.-owego biuletynu bezpieczeństwa komputerowego „Z firewall’a wzięte”.

Wstęp

Przygotowaliśmy dla Was drugi numer naszego biuletynu bezpieczeństwa  komputerowego „Z firewall’a wzięte”. Znów macie możliwość zajrzenia do naszej infrastruktury i przekonania się z jakimi podatnościami mierzymy się codziennie. Zapraszamy również do zapoznania się z pierwszym numerem biuletynu, gdzie opisujemy, dlaczego postanowiliśmy stworzyć taki materiał.

Standardowo biuletyn składa się z 3 głównych części – ogólnej analizy statystycznej incydentów w naszej infrastrukturze, analizy przypadku jednego z wybranych przez nas zagrożeń oraz podsumowania całego zebranego przez nas materiału. Na końcu dodaliśmy również sekcje „Poprzednie numery”, co pozwoli Ci łatwo znaleźć wcześniejsze wydania biuletynu.

Chcielibyśmy również zachęcić naszych kolegów z branży do przyłączenia się do naszej inicjatywy i współpracy przy tworzeniu kolejnych wydań biuletynu. Jeśli masz pomysł jak wykorzystać Twój potencjał, pomysł lub produkt w materiale serdecznie zapraszamy do kontaktu mailowego w celu ustalenia szczegółów: blog@s-m-s.pl.

Mamy nadzieję, że zapoznanie się z materiałem sprawi Ci tyle satysfakcji ile nam sprawiło jego przygotowanie. Zapraszamy również do dyskusji na jego temat we wszystkich dostępnych kanałach – sekcja komentarzy na naszym blogu, nasze profile w social mediach (Facebook oraz Twitter) czy też pod adresem mailowym: blog@s-m-s.pl. Każda opinia na ten temat jest dla nas ważna i pomoże nam ulepszyć kolejne wydania biuletynu.

Miłej lektury!

Ogólna analiza statystyczna incydentów

W celu określenia skali i częstotliwości występowania zdarzeń w infrastrukturze najlepszym będzie przeanalizowanie dostępnych danych statystycznych. Dzięki takiemu zabiegowi będziemy mogli w sposób kompleksowy przedstawić kwestie cyberbezpieczeństwa naszej infrastruktury. Na potrzeby przygotowania tej części materiału wykorzystaliśmy technologię umożliwiającą nam stałe monitorowanie ruchu do naszych serwerów. Pozwoliło nam to wyszczególnić zdarzenia, które zostały przedstawione poniżej.

W listopadowym wydaniu biuletynu, podobnie jak w zeszłym miesiącu, badaniu poddane zostały dane zebrane z własnych narzędzi służących do administrowania ruchem do serwerów. Przeanalizowaliśmy dane za okres od 01.11.2019 do 30.11.2019. Do analizy statystycznej użyte zostały takie parametry jak dzienna liczba zdarzeń, najczęściej występujące incydenty, podział zagrożeń ze względu na rodzaj oraz potencjalną dotkliwość zdarzenia.

W analizowanym okresie czasu doszło w sumie do 3.981 zdarzeń. Natomiast dziennie dochodziło średnio do 133 prób ingerencji w nasze systemy. Liczbę zdarzeń występujących w każdym dniu zeszłego miesiąca obrazuje Wykres nr 1.

W listopadzie liczba prób kompromitacji naszych serwerów utrzymywała się na stałym poziomie. Dziennie występowało średnio około stu potencjalnych zagrożeń w naszej infrastrukturze. W tym miesiącu odnotowaliśmy dwa dni, w których liczba prób przeprowadzenia ataków gwałtownie wzrastała. Były to 18.11 oraz 27.11. Poniżej prezentujemy dwie tabele, w których pokazaliśmy rodzaje zagrożeń oraz liczbę takich zdarzeń w przeciągu tych dwóch dni.

 

Standardowo, do najbardziej popularnych zagrożeń, które udało się nam odnotować należały HTTP SQL Injection Attempt oraz UNIX Portmapper Remote Infomation Retrieving Attempt. Są to dwie często wykorzystywane metody ataku, gdyż charakteryzują się niskim skomplikowaniem, łatwością zastosowania oraz wysoką popularnością wśród cyberprzestępców.

Przedstawiamy Wam też nasz Top19 zagrożeń w listopadzie. Są to najczęściej wykorzystywane typy zagrożeń, poprzez użycie których atakujący próbowali skompromitować naszą infrastrukturę. Poniżej tabela zagrożeń wraz z liczbą zdarzeń.

Wyżej wspominamy o pojęciu potencjalnej dotkliwości zdarzenia. Jak sama nazwa wskazuje jest to szacowany zakres szkód jakie może wyrządzić dana podatność w naszej infrastrukturze o ile dojdzie do jej pomyślnego wykorzystania. Samą dotkliwość można podzielić na 5 różnych poziomów:

• Informacja – podejrzane zdarzenie, które nie stanowi bezpośredniego zagrożenia, ale poprzez samo jego zgłoszenie uwaga administratora może zostać zwrócona na głębsze problemy infrastruktury, które mogą zaistnieć w przyszłości.
• Niska – najniższy poziom dotkliwości wymagający ostrzeżenia. Zagrożenie ma znikomy wpływ na infrastrukturę organizacji. Zazwyczaj wymagają lokalnego bądź fizycznego dostępu do systemu i często mogą powodować problemy z prywatnością ofiary lub problemy powiązane z DoS oraz możliwy wyciek danych.
• Średnia – niewielkie zagrożenie, którego wpływ na infrastrukturę jest minimalny. Następstwem wykorzystania podatności z tej kategorii mogą być ataki typu DoS, które nie zagrażają celowi lub exploity, które od osoby atakującej wymagają przebywania w tej samej sieci LAN co ofiara. Zagrożenia poziomu średniego mogą mieć wpływ jedynie na niestandardowe konfiguracje oraz mało znane aplikacje. Zapewniają atakującemu bardzo ograniczony dostęp.
• Wysoka – zagrożenie, które potencjalnie może stać się krytycznym, jednak dzięki występowaniu czynników łagodzących nie jest możliwa jego eskalacja. Do kategorii zagrożeń poziomu wysokiego można zaliczyć zagrożenia, które są trudne do wykorzystania, nie dają podwyższonych uprawnień lub są w stanie dotknąć małej ilości ofiar.
• Krytyczna – zagrożenie poważne, które jest stanie dotknąć domyślnych instalacji szeroko rozpowszechnionego oprogramowania. Skutkuje kompromitacją serwera, a kod exploitacji jest powszechnie dostępny. Atakujący zwykle nie potrzebuje żadnych specjalnych danych uwierzytelniających ani wiedzy na temat poszczególnych ofiar, a cel nie musi być zmanipulowany w celu wykonywania jakichkolwiek specjalnych funkcji.

Na poniższym wykresie przedstawiliśmy potencjalną dotkliwość najpopularniejszych zdarzeń występujących w badanym okresie.

Podobnie jak ostatnio chcieliśmy sprawdzić z jakich krajów najczęściej pochodziły ataki. Aby to zrobić ponownie wykorzystaliśmy napisany przez nas program w bashu, który identyfikował adresy IP i przypisywał każdemu z nich kraj ich pochodzenia, a następnie je zliczał. W ten sposób otrzymaliśmy 195 unikalnych adresów IP wraz z ich krajem pochodzenia. Tym samym udało nam się zidentyfikować 29 krajów, z których próbowano skompromitować nasze usługi. Wszystkie atakujące nas państwa pokazaliśmy na poniższej mapie. Im ciemniejszy i bardziej nasycony kolor tym więcej ataków z danego miejsca odnotowaliśmy.

Analiza przypadku wybranych zgłoszeń

Zazwyczaj do analizy wybiera się przypadki podatności na krytycznym poziomie lub takie, które w jakiś inny sposób rzucają się nam w oczy. Pracując w przeszłości z produktami firmy Fidelis, zdobyliśmy doświadczenie oraz pewność, że tego typu podatności zostaną zablokowane przez nasze systemy bezpieczeństwa. Natomiast realnym zagrożeniem, które warte jest zwrócenia uwagi są podatności, które ‚zaświeciły się’ na żółto i trafiły do naszej sieci. Pomimo, że podatności które zostały zablokowane niosą za sobą potencjalnie największe zagrożenie to dzięki odpowiednim zabezpieczeniom nie mają one dużego wpływu na naszą infrastrukturę. Zdecydowanie bardziej niebezpiecznym przeciwnikiem są podatności na niższym poziomie, które nie są automatycznie blokowane przez system. Należy więc zwrócić uwagę na to, co jedynie odbiło się na firewall’u swoją obecnością, nie budząc najmniejszych podejrzeń w naszych systemach bezpieczeństwa.

W ten sposób też w tym miesiącu  wytypowaliśmy incydent bezpieczeństwa, a właściwie grupę incydentów, których analiza wydała nam się o wiele bardziej interesująca.

Liczba incydentów, które zostały przeanalizowane na potrzeby niniejszego biuletynu wyniosła łącznie 42. Co ciekawsze, nie są to ataki tylko jednego typu przy czym ukierunkowane są na jeden wektor, którym jest serwer WWW, a dokładnie aplikacje webowe. Oprócz wektora ataku, wspólnym mianownikiem dla powyższych incydentów jest również adres IP atakującego. Na dzień sporządzania analizy niestety adres IP jest już nieaktywny, ale na szczęście zostało nam trochę nagranego ruchu sieciowego i z niego też udało się nam wyciągnąć trochę informacji. Oczywiście nie bylibyśmy sobą gdybyśmy w pierwszej kolejności nie sprawdzili pochodzenia adresu IP. I tym razem – oczywiście mamy nadzieję, że w przyszłych biuletynach znajdziemy też takie smaczki – trafił się nam adres IP pochodzący z klasy adresowej należącej do… Google. Takie odkrycie było dla nas niemałym zaskoczeniem. Nie ukrywamy – nie spodziewaliśmy się dziwnych, podejrzanych zachowań z strony sieci Google. Poniżej prezentujemy dane dostępne dla zapytania whois dla adresu intruza.

Jak widzimy, adres należy do googlowskiej Content Delivery Network. Dla naszych mniej technicznych czytelników (oraz dla technicznych gwoli przypomnienia) wyjaśniamy co kryje się za tym pojęciem. Content Delivery Network (w skrócie CDN) jest to duży, rozproszony system dostarczania treści do wielu centrów danych i punktów wymiany ruchu w Internecie. Celem CDN jest udostępnianie zawartości o wysokiej dostępności i wydajności użytkownikom końcowym (czyli podmiotom korzystającym z takiej usługi). Do sieci CDN należy również oferowany przez Google Cloud Platform. Jest to pakiet usług w chmurze działający w tej samej infrastrukturze, której Google używa dla swoich usług przeznaczonych dla użytkowników końcowych. Do takich usług zaliczyć można wyszukiwarkę Google czy też YouTube. Niegdyś to tej samej sieci należała Picassa. Niegdyś był to flagowy menadżer i przeglądarka plików graficznych w Google. Natomiast od 12 lutego 2016 roku Google poinformowało użytkowników o zaprzestaniu dalszego rozwoju programu z dniem 15 marca 2016 w celu skupienia się na usłudze Zdjęcia Google.

Aby pozyskać więcej danych bez wykonywania ofensywnych działań uciekamy się do pomocy portalu Shodan.io, czyli pierwszej na świecie wyszukiwarki dla urządzeń sieciowych. Pierwsza część informacji, które można znaleźć na shodanie, to dane o kraju pochodzenia, ISP, organizacji która jest właścicielem lub jaki revdns ma dany adres IP. Te same informacje znajdujemy w bazie whois, jednakże shodan przekazuje je nam w postaci o wiele czytelniejszej.

Zanim przejdziemy do kolejnej części danych dostępnych na shodanie, warto przyjrzeć się temu co ustaliliśmy już do tej pory. Mówmy o adresie IP należącym do puli adresowej Google. Serwer który, wszelakie ewentualne certyfikaty oraz działania powinien mieć związane stricte z Google.

Kolejną częścią danych dostępną na shodanie jest listing otwartych portów oraz protokołów powiązanych z nimi. W tym przypadku dostępny był tylko jeden port, a na nim protokół RDP – czyli Remote Desktop Protocol, prościej mówiąc, zdalny pulpit, za pomocą którego można sterować zdalnie komputerem.

Czego możemy się dowiedzieć z powyższego screena? Pierwszą rzeczą na którą należy zwrócić, to data wygenerowania certyfikatu. Jest to 10.11.2019 11:50 GMT, a więc jest to 12:50 czasu polskiego. Widzimy też, że parametr CN (Common Name) ma wartość „hridoy”. Zazwyczaj podczas generowania certyfikatu przybiera on wartość hostname danej maszyny.

Pierwszy raz kiedy zarejestrowaliśmy ruch z tego serwera to 10.11.2019 11:01:00, a ostatni kontakt z naszą siecią odbył się 14.11.2019 7:41:50. Wynika z tego, że całkowity czas incydentu to nie całe 4 dni. W ciągu tych czterech dni możemy również 3 wyraźne okresy aktywności atakującego:

1. 11.11.2019 00:45:18 – 11.11.2019 3:15:36
2. 12.11.2019 14:20:35 – 12.11.2019 22:53:53
3. 13.11.2019 09:11:56 – 13.11.2019 21:13:37

Ostatni raz, maszyna została zarejestrowana przez shodan o 1:02:06 15.11.2019, po tym czasie nie zarejestrowaliśmy też aktywności tego adresu na naszym firewallu. Czas ten uznajemy za orientacyjny EOL (End of Life) tej maszyny.

Przez te cztery dni w różnych odstępach czasowych zostały zarejestrowane próby wykorzystania między innymi takich podatności jak:

 

WordPress MailPoet Newsletters Unauthenticated File Upload Vulnerability. Wtyczka WordPress „MailPoet Newletters” jest podatna na lukę polegającą na przesyłaniu plików podczas analizowania niektórych spreparowanych żądań HTTP. Luka w zabezpieczeniach wynika z braku odpowiedniej kontroli podczas obsługi funkcji przesyłania motywu. Nieuwierzytelniony atakujący może wykorzystać lukę w zabezpieczeniach, wysyłając spreparowane żądanie HTTP w celu przesłania złośliwych plików zip. Pomyślny atak może doprowadzić do zdalnego wykonania kodu z uprawnieniami serwera.

HTTP Directory Traversal Vulnerability. Luka w zabezpieczeniach związana z przejściem przez katalog podczas analizowania źle sformułowanych żądań HTTP. Ta usterka wynika z braku odpowiedniej kontroli w żądaniu HTTP URI. Pomyślny atak może zapewnić atakującemu dostęp do poufnych informacji, które mogą dodatkowo zostać wykorzystane podczas przeprowadzania innych ataków.

WordPress Cuckootap Theme Arbitrary File Download Vulnerability. Worpress jest podatny na lukę pobierania dowolnego pliku podczas analizowania niektórych spreparowanych żądań HTTP. Luka w zabezpieczeniach występuje w motywie Cuckootap, który umożliwia pobieranie dowolnych plików. Osoba atakująca może wykorzystać lukę w zabezpieczeniach, wysyłając spreparowane żądanie http z sekwencją przejścia katalogu w parametrach. Pomyślny atak może doprowadzić do ujawnienia poufnych danych plików.

Po wykryciu działalności intruza cały jego ruch przekierowaliśmy do osobnego serwera nazywanego przez nas „Black Gate”. Zadaniem tego serwera jest imitować usługi dostępne na atakowanym serwerze w rejestrowanym, izolowanym środowisku, gdzie niejednokrotnie pomagamy w kompromitacji w celu przechwycenia jak największej ilości informacji. Więcej o „Black Gate” napiszemy wkrótce. Poniżej zaprezentujemy wyniki obserwacji:

Wśród wtyczek WordPress pojawiła się nowa luka zero day, która dotyczy ponad 70 000 witryn korzystających z wtyczki Social Warfare. Wtyczka jest podatna na lukę Stored XSS (Cross-Site Scripting) i została usunięta z repozytorium wtyczek. Ataki mogą być przeprowadzane przez wszystkich użytkowników odwiedzających witrynę. Więcej na temat tej podatności możecie znaleźć tutaj: https://nvd.nist.gov/vuln/detail/CVE-2019-9978

W tym miejscu warto zauważyć, że o ile inne podatności były wykryte kilka dobrych lat temu to ta jest nowa. Tym samym sugeruje to, że botnet był aktualny, a atakujący musiał na bieżąco aktualizować kod. Zarówno luka jak i exploit zostały wykryte/opracowane w marcu tego roku.

WordPress (CMS) Cherry-Plugin Arbitrary File Upload RCE. Wtyczka WordPress o nazwie „Cherry Plugin” ma lukę, która umożliwia osobie atakującej przesyłanie plików bezpośrednio na serwer. Pliki te mogą być następnie wykonane przez atakującego zdalnie w celu wykonania kodu lub wykonania innych złośliwych działań. Expoitację z wykorzytsaniem tej podatności można podzielić na dwa etapy: 1. Atakujący wysyła żądanie POST do „wp-content/plugins/cherry-plugin/admin/import-export/upload.php”, a następnie 2. Atakujący może uzyskać dostęp do pliku na stronie „wp-content/plugins/cherry-plugin/admin/import-export/<malware file>”. Zaprezentowanie tej podatności jest o tyle kluczowe, że jasno zaprezentowaną mamy treść pliku, który intruz próbował wprowadzić na serwer. Prawdopodobnie ten sam plik znajdował się w pliku rock.zip.

Podsumowanie

W dzisiejszym materiale zaprezentowaliśmy pobieżne studium kilku przypadków. Tym razem wspólnym mianownikiem nie była wykorzystywana podatność (chociaż wektor ataku był ten sam), a wspólne źródło ataków. Już w trakcie przygotowania niniejszego materiału zauważyliśmy ruch o podobnym schemacie/przebiegu, jednakże w związku z wieloma podobieństwami postanowiliśmy je pominąć. Jak widać na powyższych przykładach botnety używają nie tylko starych błędów w oprogramowaniu, ale też korzystają z tych pojawiających na bieżąco i są regularnie aktualizowane. Ważnym elementem w obronie przed ich działalnością są częste i skrupulatnie aktualizacje naszych webaplikacji oraz stały monitoring infrastruktury. Podczas przeprowadzania badania i analizy w listopadzie ponownie żadne z wykorzystywanych podatności czy też zagrożeń nie wpłynęły na ciągłość działania naszych systemów, a próby każdego ataku zostały skutecznie odparte.

Poprzednie numery

Z firewall’a wzięte czyli biuletyn bezpieczeństwa komputerowego S.M.S. Nr 1 10/19