10:31
30/7/2019

Budzisz się rano i okazuje się, że Twoja strona służy do rozsyłania malware’u. Google ostrzega przed nią ludzi, na social mediach wylewa się hejt, masz problem z wynajęciem ekipy do sprzątania, a Twój admin jest akurat na wakacjach. Ten koszmar może się zdarzyć każdemu i jeśli chcesz uniknąć lawiny problemów to lepiej przeczytaj poniższy artykuł, przygotowany przez Holm Security, których klient miał dokładnie ten problem.

W ramach Holm Security dostarczamy na polskim rynku rozwiązania do przeprowadzania oceny poziomu bezpieczeństwa. Zwykle podczas rozmów z naszymi klientami słyszymy o incydentach, których można było w bardzo prosty sposób uniknąć. Postanowiliśmy na łamach Niebezpiecznika przytoczyć jedną z takich historii, aby pokazać wam nieco inną perspektywę – jak taki atak wygląda z punktu widzenia właściciela firmy/serwisu/sklepu internetowego itp. Całość, przedstawiona została za zgodą naszego klienta oraz po odpowiednim zanonimizowaniu.

Jakiś czas temu firma, którą prowadzi jeden z Klientów (na potrzeby artykułu nazwijmy go Andrzejem) padła ofiarą ataku. Takich historii znamy sporo, ale ta konkretna będzie dobrym przykładem dla każdego, kto podejmuje decyzje o wdrażanych środkach bezpieczeństwa. Nie ma tutaj znaczenia czy będzie to project manager z korpo, czy wasz kolega Stanisław sprzedający śrubki w internecie.

Twoja strona rozsiewa malware!

Zacznijmy od streszczenia rozmowy z Andrzejem.

W ostatnim czasie firma, którą prowadzę padła ofiarą ataku hakerów (…)

(…) Bardzo cenię sobie dobry sen, dlatego zwykle w nocy korzystam z trybu „nie przeszkadzać” (…). Tego konkretnego poranka okazało się to dla mnie niezwykle zgubne (…) Moim oczom ukazała się cała masa powiadomień z różnych źródeł. Duża część pochodziła z naszego service desku, część od zespołu technicznego, inne z portali społecznościowych.

Wśród nich znalazła się również informacja od Googla, która – patrząc z perspektywy czasu – spowodowała spore straty finansowe dla mojej firmy. Szybko dostrzegłem, że w treści każdego z powiadomień przewijały się kluczowe zwroty takie jak atak, haker, blokada, brak dostępu itp. W tym momencie stało się dla mnie jasne, że padliśmy ofiarą ataku – nie znałem jeszcze skali, ale po samej ilości powiadomień wiedziałem już, że oznacza to dosyć duże kłopoty. Odruchowo wpisałem adres mojego sklepu internetowego w przeglądarce, jednak to co zobaczyłem, spowodowało, że odjęło mi mowę.

Andrzej zobaczył to.

 

Ataku zapewne nie udałoby się uniknąć nawet gdyby Andrzej tej nocy nie spał i ciągle wpatrywał się w telefon. „Wybuch pożaru” to był tylko widoczny skutek czegoś, co nastąpiło wcześniej.

(…) Okazało się, że faktycznie padliśmy ofiarą ataku hakerów. Ktoś wykorzystywał od dłuższego czasu NASZĄ stronę do atakowania NASZYCH klientów z wykorzystaniem złośliwego oprogramowania. Gdybyście chcieli wiedzieć jak w takiej sytuacji czuje się właściciel firmy to pomogę wam sobie to wyobrazić – dział obsługi klienta zawalany kolejnymi zgłoszeniami od użytkowników – jedni narzekali, że nie mogą dostać się do strony, inni wysyłali zażalenia (nazwijmy to w ten sposób) że przez nas obawiają się o bezpieczeństwo swoich urządzeń, jeszcze inni słali groźby z karami RODO, obowiązkiem informacyjnym itd.

Social Media to samo – hejt w komentarzach, portale technologiczne już zdążyły napisać o naszej wpadce, skrzynka odbiorcza pełna, aktywność naszej konkurencji nagle wzrosła o co najmniej 100%.

Tu się pali, a terminy jak w NFZ

Andrzej postanowił podjąć środki zaradcze i przekonał się, że nie jest to całkiem proste.

Trzeba działać szybko – muszę znaleźć kogoś, kto będzie w stanie pozbyć się tego dziadostwa z naszych serwerów (mam tutaj na myśli malware, nie komunikat Googla – tym trzeba będzie zająć się w kolejnym kroku). Zespół mówi, że nie ma odpowiednich kompetencji więc muszę znaleźć kogoś innego.

Wszystkie zespoły pentesterskie do których dzwoniłem są zawalone pracą, terminy jak w NFZ. W końcu znalazłem jeden zespół, który zgodził się zająć pilnym przypadkiem – cena jak zwykle w takich przypadkach x1000, ale nie byłem w pozycji do negocjacji. Zaaranżowanie podpisania wszystkich potrzebnych umów, NDA, DPA, ITP – wszystko na szybko, ze wstydem przyznaję, że nawet nie czytałem.

Ważniejsze było rozpoczęcie pracy nad naprawą problemu, ale zespół spiął się szybko i dostałem informację, że za 10 min zaczynają działać – proszą jeszcze o przesłanie kontaktu do administratora, lub wszystkich niezbędnych dostępów. Powinno być proste – szybki telefon do Jarka i działamy dalej. Powinno być, ku**a – zapomniałem, że Jarek wygrzewa dupę na Malcie i odebranie telefonu z pracy, to ostatnia rzecz, która przyszłaby mu teraz do głowy (…) Po 5 godzinach Jarek oddzwonił, przekazał wszystkie dane chłopakom częściowo przez telefon, częściowo przez maila (wiem, to brzmi jak nie uczenie się na błędach, ale nie było czasu na rozsądek) i zespół mógł rozpocząć proces czyszczenia serwera i oceny szkód (…).

Naszym zdaniem Andrzej powinien zachować spokój i nie działać pod wpływem emocji. Warto mieć przygotowane (i przepracowane!) procedury postępowania w takich przypadkach. Gdyby Andrzej wykonał na wcześniejszym etapie analizę ryzyka, to sytuacja, w której nikt nie ma dostępu do serwerów powinna zostać bardzo szybko zidentyfikowana, a ryzyko jej wystąpienia odpowiednio zminimalizowane.

Dobrą opcją jest również posiadanie alternatywnego, bezpiecznego kanału komunikacji.

(…) W ciągu kolejnych godzin zespół znalazł i usunął źródło problemu. Okazała się nim wtyczka do naszego CMS. Do tej pory byłem przekonany, że WordPress jest bezpieczny – w końcu wszyscy mówią, że jest ciągle testowany przez społeczność również pod kątem bezpieczeństwa, a znalezione podatności są szybko poprawiane. Mnie jednak nie ochroniła nawet automatyczna aktualizacja! (…)

Bezpieczeństwo jest bardzo złożone

Niestety na bezpieczeństwo aplikacji składa się wiele czynników. Sama aktualizacja WordPressa nie ochroniła Andrzeja przed atakiem, ponieważ był to tylko jeden z wielu elementów.

Andrzej zapomniał o aktualizacji wtyczek, które należy wykonywać osobno, a także szablonów – a wy pamiętacie? Nawet jeśli tak, to warto podkreślić, że same aktualizacje tych komponentów nie wystarczą – mamy tam również serwer, na nim zainstalowany jest system operacyjny, gdzie z kolei uruchomione są pewne serwisy (część z nich dostępna z poziomu Internetu) i ponownie – wszystko to również należy aktualizować na bieżąco. To nadal nie daje gwarancji uniknięcia ataku, bo część podatności nie jest znana publicznie, a do tego mamy coś takiego jak czynnik ludzki.

Jeżeli w tym momencie uważasz, że do ogarnięcia tych wszystkich rzeczy potrzebny jest Ci sztab specjalistów (i ogromny budżet na ich utrzymanie), to częściowo masz rację. Mamy jednak i dobrą wiadomość – duża część tej pracy może zostać zautomatyzowana przy użyciu odpowiednich narzędzi.

Jako Holm Security jesteśmy jednym z dostawców tego typu narzędzi. Firma pochodzi ze Szwecji ale od tego roku mamy oddział w Polsce. Zajmujemy się dostarczaniem narzędzi do przeprowadzania automatycznej i systematycznej oceny poziomu bezpieczeństwa. Polski oddział firmy prowadzą Paweł Dworucha i Mateusz Piaszczak –- jeżeli macie jakieś pytania w kwestii naszych produktów, to piszcie do nich śmiało! Więcej informacji znajdziecie na stronie Holmsecurity.pl oraz na LinkedIn.

Jak przebiegał atak?

Specjalnie dla was – bazując na informacjach od Andrzeja – odtworzyliśmy krok po kroku jak wyglądało przeprowadzenie włamania z punktu widzenia atakującego. Odwzorowaliśmy środowisko 1:1 w naszym laboratorium – CentOS 7, baza danych mySql, WordPress (w wersji, która była aktualna w momencie ataku) i nie zaktualizowana wtyczka WordPress Grace Media Player.

No dobra – my mamy takie informacje, ale skąd atakujący wiedział z czym ma do czynienia? Odpowiedź jest prosta – wystarczyło spojrzeć do źródła strony, żeby dostrzec kilka wskazówek:

Pierwsza z nich, to ścieżka do skryptów i styli („wp-includes” i „wp-content”), która powinna nakierować na rodzaj CMS’a. Jeżeli to wciąż nie byłoby wystarczające, wspomniany CMS w domyślnej konfiguracji sam się pięknie przedstawia pod meta tagiem „generator” podając również konkretną wersję.

Uwaga, można ten tag ukryć, lub pójść krok dalej i zmylić przeciwnika wpisując inny numer wersji! Ale wracając – skoro WordPress, to WPScan (Komenda:
wpscan –url domena –enumerate vp – polecamy również sprawdzenie opcji enumerate u
;)):

Screen powyżej można streścić jako GAME OVER. Wystarczyło, żeby atakujący otworzył jeden z podanych linków (np. https://www.exploit-db.com/exploits/46537) i przeczytał instrukcję – a właściwie tę jedną, konkretną linijkę:

Jeżeli dokleimy wspomniany fragment do naszej strony, to otrzymamy wyświetlony plik passwd:

 

W tym wypadku, na serwerze ofiary został również znaleziony złośliwy plik (a konkretnie webshell WSO), który w połączeniu z LFI zapewnił atakującemu tzw. Quick Win. W jaki sposób plik znalazł się na serwerze? Podczas analizy logów okazało się, że został wgrany na serwer tradycyjną metodą – korzystając z funkcjonalności dodawania załączników na jednej z podstron (winny jak zwykle brak walidacji!). Po wgraniu pliku na serwer atakujący musiał jedynie odnaleźć prawidłową ścieżkę na serwerze (domyślny katalog?) i to wszystko:

Dzięki temu otrzymał wygodny, graficzny interfejs webowy z możliwością wykonywania dowolnych (w zakresie przysługujących uprawnień, ale od czego mamy coś co nazywa się Local Privilege Escalation) akcji na serwerze.

Jeszcze jedna rzecz do zrobienia

Ostatnim problemem do rozwiązania pozostało usunięcie komunikatu od Googla. W tym celu właściciel serwisu musi zalogować się do Google Webmasters Tool i potwierdzić, że pozbył się problemu.

Następnie Google przeprowadzi weryfikację i jeżeli całość przebiegła pomyślnie, to czerwony komunikat zostanie wyłączony. W skrajnym przypadku może to potrwać nawet kilka dni – zastanów się, czy Twoja firma może sobie na to pozwolić?

Co robić? Jak żyć?

Jeżeli udało Ci się dobrnąć do tego miejsca to z znak, że zasługujesz na kilka złotych porad, dzięki którym unikniesz sytuacji opisanych powyżej.

  • Aktualizuj wszystko i rób to jak najszybciej (CMS, themy, pluginy, serwery – WSZYSTKO).
  • Przygotuj plan działania w wypadku sytuacji kryzysowej – kontakty, ludzie, backupy.
  • Skanuj swoje aplikacje pod kątem bezpieczeństwa (pamiętaj, że nie wszystkie podatności są znane publicznie) i ustaw powiadomienia mailowe/SMS.
  • Traktuj wszystkie dane wprowadzane przez użytkowników jako potencjalnie groźne – wszystkie formularze powinny mieć walidację!
  • Skonfiguruj powiadomienia mailowe w Google Search Console.

Niniejszy artykuł jest artykułem sponsorowanym, został stworzony przez firmę HolmSecurity, a za jego opublikowanie redakcja Niebezpiecznika otrzymała wynagrodzenie.

Przeczytaj także:

24 komentarzy

Dodaj komentarz
  1. >Jeżeli w tym momencie uważasz, że do ogarnięcia tych wszystkich rzeczy potrzebny jest Ci sztab specjalistów (i ogromny budżet na ich utrzymanie), to częściowo masz rację. Mamy jednak i dobrą wiadomość – duża część tej pracy może zostać zautomatyzowana przy użyciu odpowiednich narzędzi.

    Sztab specjalistów do akutalizacji… Artykuły komediowe na niebezpiecnziku to dla mnie nowość.

    • nie tylko aktualiacji, jeszcze usunięcia webshella co będzie już trudniejsze – trzeba pamiętać że większość użytkowników nie pamięta danych do logowania do panelu klienta czy panelu zarządzania serwerem, a co dopiero do FTP i często naprawianie strony zaczyna się np. od zmiany kontaktowego adresu e-mail celem ustalenia nowego hasła do panelu klienta :) A tu już niestety specjalista potrzebny bo użytkownik strony rzadko kiedy potrafi czytać ze zrozumieniem.

    • Choć to brzmi jak marketingowy bełkot, to są tez osoby które muszą same uciągnąć wszystko i po prostu nie wystarcza czasu by się znać na wszystkim i wszystkiego dopilnować.
      Także jeśli są osoby które chętnie pomagają (odpłatnie lub nie) to tylko się cieszyć.
      A tu nie zawsze chodzi w grę tylko aktualizacja i tylko jeden system operacyjny.

    • @ooooo: masz rację, ale wszystko tak na prawdę zależy od skali…

  2. Jeden dodatkowy złośliwy plik – ten to miał farta w takim razie. Widywałem już dopisany złośliwy kod na początku każdego pliku PHP (jakieś 50000) plików, albo pliki dograne przez złośliwe pliki dograne przez złośliwe pliki dograne przez złośliwe pliki … ciągnące się aż do końca dostępnych logów.

    Bardzo często lepiej jest postawić stronę od nowa niż bawić się w czyszczenie.

    • z 50 000 plików się nie spotkałem ale z tysiącami już tak, regularny backup rozwiązuje sprawę

    • Gorzej jeśli pierwotna infekcja nastąpiła miesiące temu, po wszsytkich katalogach pochowane są webshelle czy inne backdoory i nawet jak masz backup sprzed jakiegoś czasu to włamywaczowi wystarczy tylko powtórzyć ostatnią operację i zainfekować znowu :)

  3. Zgadzam się z powyższą wypowiedzią Marka. Wystarczy mieć backup, każdy hoster o ile nie jest to serwer dedykowany ma obowiązek trzymać backupy najmniej 2 tygodnie wstecz, zazwyczaj można się z resztą cofnąć z panelu do wybranego backupu. Jeżeli hoster tego nie robi zmień hosting i po problemie. Nawet jeżeli na stronę była wrzucana duża ilość danych ktoś kto je obrabiał ma na pewno kopię, więc przywrócenie backupu + dogranie danych (tym bardziej w WP) to zadanie dla każdego średnio ogarniętego nastolatka…

    • taaa “ma obowiązek” :) obowiązek mają taki, jaki sobie zapiszą w regulaminieżeby nie szukać daleko, jeszcze z rok, półtora temu nazwa.pl miała backup do 48 godzin wstecz (nie wiem jak teraz).

      A wgranie kopii w 90% przypadków spowoduje że stan na chwilę obecną jest następujący – masz teraz stronę zainfekowaną tak samo jak tydzień temu, atakujący robi jeszcze raz to samo i wracamy do punktu wyjścia :)

  4. Gorzej jeśli pierwotna infekcja nastąpiła miesiące temu, po wszsytkich katalogach pochowane są webshelle czy inne backdoory i nawet jak masz backup sprzed jakiegoś czasu to włamywaczowi wystarczy tylko powtórzyć ostatnią operację i zainfekować znowu :)

  5. Uważam, że dobrym pomysłem mogłoby być przygotowanie strony na tym portalu z polecanymi firmami i ich usługami. W razie pilnej potrzeby zainteresowany czytelnik mógłby szybko wyklikać sobie firmę do pomocy, a niebezpiecznik zarobiłby na linku afiliacyjnym ;)

    • Ale to artykuł sponsorowany, zapłacono za promocję dobrej firmy, a nie propagowanie takich usług :C

  6. Fajna historyjka, często jednak odległa od rzeczywistości.
    Bo jednak typowi Andrzeje nie szukają fachowej pomocy (zwłaszcza na cito z krotność stawki), a szukają prostego i darmowego rozwiązania np. w postaci magicznej wtyczki “napraw mi stronę”.
    Tak potem przechodzą dłuuuuższą zabawę np. WordFence i niezliczone próby przywracania backupów, by po tygodniu/ach, miesiącu/ach wrócić i wystawić zlecenie pt. kto najtaniej zrobi ….a tutaj pole do popisu mają Janusze, nie fachowcy ;p

    • A najtaniej wyjdzie zwykle postawić stronę na nowo :) Bo czyszczenie tysięcy potencjalnie zmodyfikowanych plików, jeśli nie ma się super hiper dedykowanych narzędzi (które i tak mogą coś przegapić) raz – mija się z celem, dwa – kosztowałoby więcej

    • Czysczenei WP to kwestia kiluset zlotych – nie zawsze w tej cenei zrobsiz nwoa strone

    • Jeżeli ktoś stawia swoją stronę usługową (np. Sklep internetowy) na Wordpresie, to raczej nie jest gotowy zapłacić nawet podwójnej opłaty. Jeśli ktoś opiera swoje usługi na WordPressie lub Joomli, to prowadzi parodię biznesu, a nie prawdziwą firmę. WordPress jest dobry do stron informacyjnych i blogów.

  7. “ale nie byłem w pozycji do negocjacji”
    Marna kalka z angielskiego zdradza, że reklamodawca, z którym tu mamy do czynienia, zajmuje się może (nieudolnie) tłumaczeniami z języków obcych, ale powierzyć im troskę o swoje IT jest dość karkołomne.

  8. Sztab specjalistów do WP? Serio? I ciężko znaleźć? Rozumiem jakby to był jakiś mniej popularny system ale nie WP. Czyszczenie wordpressa (oczywiście zależy jak rozbudowanego) to średnio koszt max 1000zl.

  9. Nie rozumiem dlaczego uzyskanie dostępu do /etc/passwd jest wskazane jako sukces atakującego. Oczywiście to nie powinno mieć miejsca. Warto jednak mieć na uwadze, że hasła są w /etc/shadow który nie jest dostępny dla wszystkich użytkowników systemowych a tym samym nie jest dostępny dla użytkownika www-data czyli serwera www.

    • To wskazuje bardziej na potwierdzenie istnienia podatności Local File Inclusion (taki proof of concept jakim jest alert(1) przy testowaniu XSS) z wykorzystaniem której, możemy próbować eskalowania ataku.

    • Ale można zrobić honeypot i pod /etc/passwd podlinkować inny plik. Ba! Można zasymulować, że jest to plik starego typu (przechowujący skróty haseł) i dać komuś bezsensowne koszty.
      Jeszcze lepiej, jak podlinkuje się fikcyjny /etc/ssh/sshd.conf, gdzie będzie wyłączone logowanie kluczem i umożliwione logowanie do kont z internetu.

  10. Zazwyczaj do ogarniania strony nie jest potrzebny sztab specjalistów, często sam właściciel przy odrobinie podstawowej wiedzy z WP sam zaktualizuje system i wtyczki, a w razie problemów przy aktualizacji, które równiez się zdarzają, może przywrócić wcześniej utworzony backup np. za pomocą wtyczki updraft.

    Można tez komuś zapłącić z aopiekowanie się stroną, czyli aktualizacje WordPressa, wtyczek i natychmiastową reakcję w razie problemów.
    Sam trudnię się tego typu usługami i w tym wypadku klienci płacą głównie za gotowość w razie problemów i spokojna głowę, a nie za wykonaną pracę(monitorowanie dostepności strony, aktualizacje), której przy dobrze zabezpieczonej i często aktualizowanej stronie jest niewiele.

  11. Często problemem nie jest samo włamanie, a to, że strony są nieaktualizowane — WordPressy i inne dziadostwa. Mija się to z celem, bo prędzej czy później znów ktoś się tam włamie.

    Puszcza się bota na parę milionów stron zescarpowanych z wyników wyszukiwania i z automatu wgrywa malware czy podmienia stronę.

  12. Z tym komunikatem z Google Search Console to koniecznie trzeba wysłać ponowną prośbę do Google o rozpatrzenie. Jeżeli tego nie zrobimy, to nawet po naprawie usterki komunikat będzie wisiał (testowałem to na przechwyconej zainfekowanej domenie, która wygasła – po zainstalowaniu domeny i WP na własnym serwerze kara za atak hakerski została odziedziczona w Google Search Console po poprzednim właścicielu). Ale generalnie wystarczyło tylko kliknąć zgłoszenie do Google i kara została zdjęta. Dalej już możemy pozycjonować stronę i ją rozbudowywać.

    Wracając jeszcze do tematu aktualizacji wtyczek niestety, ale czasami bywają takie kłopoty, że wtyczka z repozytorium WP jest rozbudowywana przez programistę. Wiadomo, że po aktualizacji pluginu do nowej wersji praca programisty pójdzie na marne. Dlatego trzeba wiedzieć z kim się współpracuje oraz znać ryzyka i zagrożenia zastosowanych rozwiązań wdrażanych “po kosztach”, aby później nie obudzić się z ręką w nocniku.

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: