Ataki hakerskie na PrestaShop – jak się przed nimi bronić? Studium przypadku

Z tego artykułu dowiesz się:

• jak w praktyce wyglądają realne ataki hakerskie na sklepy PrestaShop,
• co zrobić w pierwszych godzinach po wykryciu włamania,
• jakich elementów higieny bezpieczeństwa najczęściej brakuje,
• jak sprawdzić, czy Twój sklep jest odpowiednio zabezpieczony.

Jak w praktyce wyglądają ataki hakerskie na sklepy PrestaShop?

Luki bezpieczeństwa w modułach i core PrestaShop to temat, z którym zespół Convertis miał już do czynienia. Widząc, że problem bywa poważny i może dotyczyć wielu sklepów, stworzyliśmy odpowiednie procedury i narzędzia, które wykorzystujemy, pomagając e-sklepom przy wykrytych przypadkach włamań, a także postanowiliśmy udostępnić je szerzej.

Nie lekceważ tego tematu. Zobacz, jak duże problemy może to powodować. Przeczytaj artykuł i obejrzyj film, w którym CEO Convertis – Grzegorz Frątczak, rozmawia z członkami zespołu Convertis: Pawłem Krystem – programistą PHP oraz Piotrem Trojanowskim – koordynatorem. Specjaliści omawiają trzy przypadki, z którymi mierzył się zespół Convertis i podkreślają, jak istotne jest szybkie działanie, a na co dzień higiena sklepu i odpowiednie środki bezpieczeństwa.

Problemy z bezpieczeństwem PrestaShop bywają związane z konkretnymi modułami oraz lukami w samym core. PrestaShop regularnie udostępnia aktualizacje zawierające poprawki bezpieczeństwa. Jednak samodzielne wgranie takiej łatki bywa możliwe tylko w wyjątkowych sytuacjach, gdy sklep działa na jednej z najnowszych wersji, bez większych modyfikacji i bez modułów zewnętrznych. W większości przypadków to zadanie dla programisty.

Włamania zdarzają się też tam, gdzie nie ma żadnego konkretnego, znanego modułu podatnego na atak. Sklep internetowy to nie gotowy produkt, tylko zestaw różnych elementów, w tym modułów, więc słabym punktem bywa też, na przykład, przejęta skrzynka mailowa dająca dostęp do panelu administracyjnego lub niewystarczające zabezpieczenia serwera.

Wdrażając nowy sklep, zaczynamy od czystej, najnowszej wersji PrestaShop, uzupełnionej oficjalnymi modułami od PrestaShop lub sprawdzonymi modułami własnymi. Klienci, którzy przychodzą do nas na stałą obsługę, często mają już swoją historię – wgrane moduły od przeróżnych dostawców, wcześniejsze modyfikacje i wtedy trudniej jest szybko doszukać się źródła problemu.

Trzy prawdziwe przypadki włamań na PrestaShop

Poniżej opisujemy trzy przypadki ataków na PrestaShop, z którymi zespół Convertis miał do czynienia.

Przypadek 1 – złośliwy formularz płatności

Problem został wychwycony dzień po tym, jak jeden z naszych programistów wprowadził modyfikację w sklepie Klienta. Klient zadzwonił i poinformował, że “zepsuliśmy mu sklep”, bo pojawia się jakiś dziwny formularz na stronie. Okazało się, że jest to formularz do wprowadzania danych karty kredytowej przy płatności za zamówienie. Na szczęście (jeśli można tak powiedzieć w tej sytuacji) ten formularz wyglądał dosyć podejrzanie i powinien dać do myślenia użytkownikowi, że jest z nim coś nie tak. M.in. pojawiały się tam informacje w języku angielskim, a był to polski sklep i wszędzie indziej zastosowany był język polski.

Szybko okazało się, że jest to atak hakerski, a nie zepsucie przez nas sklepu. Po prostu modyfikacja hakera była przygotowana już wcześniej, a wgrała i pokazała się w sklepie w momencie wgrywania naszej modyfikacji po manualnym zresetowaniu cache przez naszego programistę w celu odświeżenia sklepu.

Zadziałaliśmy bardzo szybko i szybko usunęliśmy złośliwy kod. Natomiast nie jesteśmy w stanie dojść do tego, jak haker dostał się do sklepu, bo to jest poza naszymi kompetencjami – zostało to zgłoszone do weryfikacji adminowi serwera. Niestety logi są trzymane przez ograniczony czas (tydzień, może miesiąc) – więc po dłuższym czasie nikt nie jest w stanie wychwycić kiedy i gdzie tak naprawdę doszło do włamania. A do tego wszystkie zmienione pliki miały zmienione odpowiednio daty modyfikacji, co bardzo utrudniało szukanie przyczyn.

Oczywiście po takim ataku wszystkie hasła zostały zmienione, a serwer dostał kilka dodatkowych funkcji do ochrony (nie możemy tutaj pisać o tych praktykach). A do tego wszyscy pracownicy sprawdzili, czy nie mają na komputerach lub telefonach jakiegoś złośliwego oprogramowania, które przechwytuje hasła i loginy.

Przypadek 2 – włamanie u przyszłego Klienta z czterema sklepami

To była o tyle nietypowa sytuacja, że to jeszcze nie był nasz Klient. I tutaj w rozmowie z handlowcem wyszło trochę przez przypadek, że Klient może mieć problem z bezpieczeństwem. Sprawdzenie tego zostało zlecone programistom i okazało się, że ten problem z bezpieczeństwem faktycznie istnieje i to od dłuższego czasu (być może nawet od kilku miesięcy), tylko Klient nie jest go świadomy. Temat był jeszcze o tyle skomplikowany, że Klient posiada aż cztery sklepy na dwóch  serwerach i naprawa powinna być zsynchronizowana.

Jako że to nie był nasz Klient, tutaj zadziałanie zajęło nam nieco więcej czasu, bo musieliśmy najpierw otrzymać dostęp do serwera, hasła, skonfigurować i połączyć się. U naszych stałych Klientów już to wszystko mamy na starcie i możemy bardzo szybko zacząć działać. Po otrzymaniu dostępów zrobiliśmy raport, wypisaliśmy wszystkie miejsca problematyczne i zaleciliśmy zablokowanie serwera, gdyż istniała obawa, że zanim po kolei w każdym sklepie to zostanie naprawione, to skutki całej sytuacji mogą być bardzo poważne.

Trzeba też dodać, że nie byliśmy w stanie zająć się wszystkim w ciągu kilku godzin, bo mieliśmy zaplanowane prace u swoich Klientów. No niestety nie jest tak, że nasi programiści czekają w gotowości na takie pożary. Wiadomo, że mają na bieżąco jakieś prace do wykonania, mamy zobowiązania wobec naszych Klientów.

Zresztą w tym samym czasie wiedząc już o problemach z bezpieczeństwem, zleciliśmy kontrole bezpieczeństwa u wszystkich naszych Klientów, więc już mieliśmy przez to ręce pełne roboty. Dlatego też Klient zwrócił się z naszym raportem do swoich administratorów, aby ugasili ten pożar.

Przypadek 3 – przekierowania widoczne tylko dla ruchu z wyszukiwarek

Tu sytuacja dotyczyła naszego Klienta, ale objawy były inne – następowały przekierowania z wyników wyszukiwania na obcą stronę. Został wstrzyknięty złośliwy kod w głównym pliku index.php, który dodawał na froncie skrypt działający tylko dla wejść z Google, Bing i MSN, przenoszący na inną, podejrzaną stronę. Wchodząc z innych źródeł niż organiczne wyniki wyszukiwania, można było normalnie przeklikiwać się przez sklep – to było sprytne zagranie ze strony hakera, bo przeglądając tylko sam sklep, nigdy nikt by się nie zorientował, że coś jest nie tak.

W tym przypadku ten atak nastąpił dosłownie w ostatniej chwili. Wcześniej uzgodniliśmy z Klientem, że przeprowadzimy audyt bezpieczeństwa i naniesiemy łatki w jego sklepie (już wiedzieliśmy, że trzeba to zrobić po pierwszych atakach). Wszystko było gotowe na kopii testowej sklepu, brakowało tylko krótkich testów po stronie Klienta i jego akceptacji. Nie zdążyliśmy jednak przed atakiem – stąd nauczka: nie czekać z takimi rzeczami, tylko działać pilnie od razu na produkcji.

Klient zadzwonił wieczorem z tym problemem. Główny programista nie był akurat dostępny, ale mieliśmy innego programistę, dostępnego w miarę szybko, który brał udział też w pracach związanych z poprzednimi dwoma przypadkami, więc od razu wiedział, o co chodzi. Działamy zespołowo, w nieregularnych zakresach godzin, więc zawsze ktoś jest dostępny.

Decyzje musiały zapadać bardzo szybko. Zdecydowaliśmy się przywrócić sklep z kopii zapasowej sprzed tygodnia – dla utrudnienia był to multishop, czyli tak naprawdę kilkadziesiąt sklepów naraz. Tu potwierdziła się stara prawda: to bardzo ważne, żeby kopie bezpieczeństwa były prawidłowo wykonywane i utrzymywane przez odpowiedni czas. Wybraliśmy wersję sprzed tygodnia, żeby wykluczyć infekcję, a później uzupełniliśmy ją do stanu aktualnego danymi z ostatniego tygodnia – to wydało się najrozsądniejszym sposobem na jak najszybsze przywrócenie sprzedaży.

Wyłączyliśmy serwer proxy, odcinając sklep całkowicie od internetu – dzięki temu przekierowania nie następowały, a pojawiał się jedynie błąd 502, co było mniejszym złem niż przekierowanie na podejrzaną stronę. Sklep był odcięty od internetu przez 24 godziny. W tym czasie dokładnie go skanowaliśmy, przygotowywaliśmy poprawki i weryfikowaliśmy logi, a także moduły płatności, żeby upewnić się, że nie zaszły w nich żadne zmiany. Zastosowaliśmy zmiany haseł w backoffice i do baz danych, zmianę klucza webapi oraz wdrożyliśmy w core zabezpieczenia blokujące możliwość wgrywania modułów. Uzupełniliśmy brakujące zamówienia z luki czasowej między powstaniem wykorzystanej kopii bezpieczeństwa a momentem wyłączenia sklepu. W sumie zajęło to około 30 roboczogodzin zespołu – programistów i koordynatora.

Mamy hipotezę, że był to zautomatyzowany atak, mający raczej na celu depozycjonowanie sklepu Klienta lub działanie na niekorzyść jego wizerunku niż wykradzenie danych, ale nie byliśmy w stanie tego potwierdzić. Pracujemy w bardzo skomplikowanym technicznie środowisku, z milionami linijek kodu – czasami nie jesteśmy w stanie zidentyfikować miejsca i czasu włamania ani ustalić do końca przyczyny.

Klient przeżył ogromny stres, ale ostatecznie był zadowolony, że udało się szybko opanować sytuację. Po wszystkim podsunął nam pomysł, żeby mieć przygotowaną procedurę na taką sytuację – to zmniejszyłoby poziom stresu u wszystkich i pomogło przyspieszyć decyzje oraz prace. To właśnie dało nam do myślenia, żeby przygotować checklistę kroków (mieliśmy już wcześniej podstawową listę, ale ją zaktualizowaliśmy) oraz mini-audyt bezpieczeństwa, który warto przeprowadzać w każdym sklepie PrestaShop co jakiś czas, dla świętego spokoju.

Przeczytaj więcej: Jak szybka reakcja Convertis pomogła klientowi po włamaniu na sklep internetowy!

Checklisty – co robić przed i po włamaniu hakerów na PrestaShop?

Nauczeni doświadczeniem przygotowaliśmy checklisty, dzięki którym można szybciej i bez pominięcia istotnych elementów sprawdzić, co się dzieje w sklepie pod kątem bezpieczeństwa:

• Checklista _ Jak zabezpieczyć sklep Prestashop przed atakami hakerskimi i co zrobić, gdy już nastąpił włam _220816
• Checklista – Jak postępować gdy mamy włam na sklepie PrestaShop_220816

Jak zabezpieczyć sklep PrestaShop? Wnioski z realnych ataków hakerskich

Jakie wnioski Paweł (programista) i Piotr (koordynator) wynieśli z powyższych sytuacji?

1. 1. Nie czekać z działaniem, jeśli już wiadomo, że coś się dzieje i mają miejsce takie ataki – lepiej zaryzykować i zadziałać bardzo szybko, wgrywając zmiany od razu na produkcji (a nie ostrożnie, najpierw na kopii), niż ryzykować, że dojdzie do ataku.
   2. Dbać przez cały czas o higienę sklepu oraz higienę bezpieczeństwa, czyli o:
      • odpowiednie hasła oraz ich zabezpieczenie,
      • niekorzystanie z backendu sklepu przez zewnętrzne wifi oraz zabezpieczanie własnej sieci wifi (duży problem, zwłaszcza w czasach pracy zdalnej),
      • utrzymywanie porządku w sklepie, na przykład usuwanie nieużywanych modułów – takie “śmieci” to furtki zwiększające ryzyko ataku, a w razie problemów kolejne setki czy tysiące linijek kodu do sprawdzenia.
   3. Wykonywać co jakiś czas audyty bezpieczeństwa, co zresztą sama firma PrestaShop wyraźnie zaleca.
   4. Utrzymywać kopie zapasowe sklepu.

1. Klienci, którzy przychodzą do nas z zewnątrz, mają często istną stajnię Augiasza – bardzo ciężko coś znaleźć w takim sklepie w razie kłopotów.Takie wydarzenia zawsze przypominają, niestety dość brutalnie, że hakerzy i ataki na strony istnieją. Na co dzień, przy dłuższej chwili ciszy, wiele osób o nich zapomina, ignorując podstawowe zasady bezpieczeństwa. Warto mieć świadomość, że chwila ciszy nie oznacza, że już nic się nie wydarzy – lepiej założyć, że wydarzy się na pewno, i zrobić wszystko, by nie przydarzyło się właśnie Tobie.
2. Przeczytaj także: Horror programisty – przypadek prawdziwy i bohatersko wygrany po boju straszliwym, czyli PrestaShop i dziurawe moduły

Moduł bezpieczeństwa w PrestaShop – co warto wiedzieć?

Poza higieną i procedurami warto też sięgać po narzędzia, które automatyzują część tej kontroli. Przykładem jest PrestaGuard – moduł skanujący sklep PrestaShop pod kątem znanych luk bezpieczeństwa w rdzeniu i zainstalowanych modułach.

Chcesz sprawdzić, jak dziś wygląda szerszy krajobraz zagrożeń dla sklepów PrestaShop? Zobacz: Cyberbezpieczeństwo PrestaShop: Co powinni wiedzieć polscy właściciele sklepów na celowniku cyberprzestępców?

Ataki hakerskie na PrestaShop – podsumowanie

Realne włamania na sklepy PrestaShop rzadko wyglądają tak, jak można by się spodziewać. To nie zawsze spektakularny atak, tylko często dobrze ukryta modyfikacja, którą trudno wyłapać bez odpowiednich procedur. Trzy przypadki, które opisaliśmy, pokazują, że kluczowe są: szybka reakcja, aktualne kopie zapasowe, higiena haseł i porządek w modułach sklepu. Checklisty i audyty bezpieczeństwa nie gwarantują, że atak nigdy nie nastąpi, ale realnie skracają czas reakcji i ograniczają skalę szkód, gdy już do niego dojdzie.

Nie wiesz, jak wygląda bezpieczeństwo Twojego sklepu na PrestaShop? Odezwij się do nas – sprawdzimy to razem, zanim zrobi to za Ciebie ktoś inny.