Włamania – Ataki hakerskie na PrestaShop – studium przypadku

PrestaShop – luka bezpieczeństwa – co musisz o niej wiedzieć

Widząc, że sytuacja jest poważna i powtarzalna stworzyliśmy odpowiednie procedury i narzędzia, które sami wykorzystujemy pomagając sklepom przy kolejnych wykrytych przypadkach włamań, ale też postanowiliśmy udostępnić je szerzej. Mamy ograniczone moce przerobowe i w ostatnim czasie ręce pełne roboty, więc wszystkim sklepom nie będziemy w stanie sami pomóc.

Masz sklep na PrestaShop?

Nie lekceważ tego tematu – zobacz, jak duże problemy może to powodować. Przeczytaj artykuł i obejrzyj film.

To jest pierwszy tak poważny atak hakerski na PrestaShop, z jakim mamy do czynienia w naszej 6-letniej historii pracy na na tej platformie. Postanowiliśmy mówić o tym głośno, uświadamiać o zagrożeniu i pomóc sklepom. Po pierwsze nagraliśmy specjalny odcinek filmu z serii Prosta Presta, w którym CEO Convertis – Grzegorz Frątczak rozmawia z członkami zespołu Convertis – Pawłem Krystem – programistą PHP oraz Piotrem Trojanowskim – Koordynatorem. Panowie poruszają temat ataków hakerskich, które wydarzyły się w ostatnim czasie, a w których opanowaniu mieli okazję uczestniczyć.

W nagraniu omawiamy trzy przypadki, z którymi walczył zespół Convertis, ale też uczulają jak istotne w tym wszystkim jest szybkie działanie, a na co dzień higiena sklepu i jego bezpieczeństwa.

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.

Jeśli sam działasz technicznie na PrestaShop i masz do niej jakieś uwagi, zgłoś nam je koniecznie – chętnie ją uzupełnimy. W ten sposób razem przyczynimy się do poprawy bezpieczeństwa PrestaShop.  Jeśli zapiszesz się do naszego newslettera będziemy Ci wysyłać jej aktualizację.

Checklisty

• 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

Obejrzyj lub przeczytaj

Ten artykuł został napisany na bazie video dotyczącego wlamów na Prestę w ramach  serii Prosta Presta. Jeśli chcesz zobaczyć jak wyglądała dyskusja kliknij zapraszamy na nasz kanał  Convertis – Agencja Ecommerce

PrestaShop – poprawka bezpieczeństwa

Z rozmowy z Pawłem i Piotrem wynika, że problemy z bezpieczeństwem Presty są związane z modułem wishlisty oraz wersją PrestaShop 1.7, a także pewnymi lukami w jej corze. PrestaShop informuje o aktualizacji, w której jest już wdrożona poprawka bezpieczeństwa, ale czy właściciel sklepu internetowego jest w stanie załatwić sprawę samodzielnie?

Według Pawła, w pewnych wyjątkowych sytuacjach być może tak. Ale musiałby to być przypadek, gdzie sklep posiada jedną z najnowszych wersji PrestaShop bez dużych modyfikacji oraz raczej bez modułów zewnętrznych i może samodzielnie dokonać aktualizacji do najnowszej wersji Prestashop. Jednak w większość przypadków tak nie jest i jedynie programista jest w stanie wgrać łatkę bezpieczeństwa poprawnie.

Co ciekawe w naszego doświadczenia wynika, że włamy zdarzają się również w wersji 1.6, gdzie nie ma modułu wishlisty. Także sytuacja jest dosyć skomplikowana. Należy jednak pamiętać, że sklep internetowy to nie jest gotowy produkt, tylko zestaw różnych elementów, m.in. modułów. Musimy pamiętać też, że atak może nastąpić w jakiś zupełnie inny sposób np. poprzez włamanie na skrzynkę mailową klienta i uzyskanie dostępu do panelu administarcyjnego, co umożliwi hakerowi wprowadzenie zmian w sklepie z poziomu administratora. Słabym punktem mogą być też niewystarczające zabezpieczenia serwera.

My wdrażając nowy sklep zaczynamy od czystej najnowszej wersji Presty, uzupełniony oficjalnymi modułami od PrestaShop lub swoimi, które dobrze znamy, wiemy co tam jest. Klienci którzy do nas przychodzą na stałą obsługę często mają już jakąś historię – wgrane moduły od przeróżnych dostawców, modyfikacje. Wówczas jest naprawdę ciężko doszukać się pewnych rzeczy.

PrestaShop – walka z atakiem hakerskim – case studies

W filmie Grzegorz, Paweł i Piotr omawiają trzy przypadki, z którymi zespół Convertis miał do tej pory do czynienia:

PRZYPADEK 1

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

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

Tutaj sytuacja dotyczyła naszego Klienta, ale objawy były nieco inne, a mianowicie 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 js, a ten działał tylko dla wejść z Google, Bing i MSN i przenosił na inną, “trefną stronę”. Natomiast wchodząc z innych źródeł niż organiczne wyniki wyszukiwania, można było normalnie przeklikiwać się przez sklep. I to było sprytne zagranie ze strony hakera, bo chodząc tylko po sklepie nigdy nikt by się nie zorientował, że coś jest nie tak.

W tym przypadku ten atak nastąpił dosłownie w ostatniej chwili. Już 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. Wymagało tylko krótkich testów po stronie Klienta i jego akceptacji (taki był standardowy proces działania z tym klientem), Ale nie zdążyliśmy przed atakiem – stąd nauczka: nie czekać z tym, tylko działać pilnie od razu na produkcji.

W każdym razie wieczorem Klient zadzwonił z tym pożarem.  Niestety główny programista nie był dostępny, ale za to mieliśmy innego programistę, który akurat był dostępny w miarę szybko i też brał udział w pracach związanych z atakami w poprzednich dwóch przypadkach, więc już wiedział, o co chodzi.. Na szczęście działamy zespołowo i nieregularnych zakresach godzin, więc zawsze ktoś jest dostępny.

Tutaj musiały być podejmowane bardzo szybko decyzje. I zdecydowaliśmy że przywracamy sklep z kopii zapasowej sprzed tygodnia. Dodać należy jeszcze, że dla utrudnienia był to multishop, więc tak naprawdę kilkadziesiąt sklepów na raz (bardzo skomplikowany sklep).

I tutaj potwierdziła się stara prawda, że jest super ważne, żeby kopie bezpieczeństwa były prawidłowo wykonywane i utrzymywane za dany czas. Zdecydowaliśmy się przywrócić wersję sprzed tygodnia,  aby wykluczyć infekcje i później uzupełnić ją do stanu aktualnego danymi z ostatniego tygodnia. Wydało się to najrozsądniejszym sposobem na jak najszybsze przywrócenie sprzedaży, a  istniało duże prawdopodobieństwo, że atak miał miejsce kilka dni wcześniej, więc kopia sprzed tygodnia powinna przywrócić stan sprzed ataku.

Wyłączyliśmy serwer proxy, więc odcięliśmy sklep całkowicie od Internetu – dzięki temu te przekierowania nie następowały, tylko pojawiał się błąd 502, co również według nas było mniejszym złem niż przekierowanie na jakąś obcą, podejrzaną stronę.

Był wieczór, więc niestety w serwerowni też to był czas dyżurów i  trzeba było trochę nacisków tam wywrzeć, by uzyskać błyskawiczną pomoc w tej sprawie, a nie dopiero rano następnego dnia.

Sklep był odcięty od Internetu przez 24 godziny. W tym czasie w tle skanowaliśmy go dokładnie i przygotowywaliśmy poprawki oraz weryfikowaliśmy logi. Weryfikowaliśmy także moduł PayPal i PayU, czy tam nie zaszły jakieś zmiany – chodziło o bezpieczeństwo danych płatności. Zastosowaliśmy zmiany haseł w backoffice, haseł do baz danych, zmiany klucza webapi oraz wdrożyliśmy w corze Presty zabezpieczenia, które blokują możliwość wgrywania modułów. Następnie uzupełniliśmy brakujące zamówienia z tej luki czasowej od czasu powstania wykorzystanej tutaj kopii bezpieczeństwa do momentu wyłączenia sklepu po wykryciu ataku. Po tych wszystkich pracach uruchomiliśmy serwer proxy, żeby na nowo udostępnić sklep użytkownikom. Oczywiście po tym byliśmy jeszcze czujni i w gotowości, sprawdzając, czy już nic niepokojącego się nie dzieje. Do wieczora sklep został przywrócony. W sumie zajęło to około 30 roboczogodzin zespołu, czyli programistów i koordynatora.

Nieprzespana noc, dużo stresu, presja czasu, trudne decyzje, ale udało się – opanowaliśmy to.

Mamy hipotezę, że był to zautomatyzowany atak, który raczej miał na celu depozycjonowanie sklepu Klienta lub działanie na niekorzyść Jego wizerunku niż wykradzenie danych. Potwierdzić tego nie byliśmy w stanie. Pracujemy w bardzo skomplikowanym technicznie środowisku z milionami linijek kodu – czasami nie jesteśmy w stanie zidentyfikować miejsca i czasu, gdzie nastąpił włam ani ustalić do końca przyczyny.

Klient przeżył ogromny stres, ale ostatecznie był zadowolony z tego, że udało się szybko opanować pożar. Po wszystkim podsunął nam pomysł, żeby mieć przygotowaną procedurę na taka sytuacje – to by pewnie zmniejszyło poziom stresu u wszystkich i pomogło przyspieszyć decyzje oraz prace. Tak, tak. Nie jesteśmy omnibusami i korzystamy z doświadczeń i rad od ludzi na około!

I to nam dało do myślenia, aby przygotować checklistę kroków (wcześniej posiadaliśmy podstawową listę, zanim sklep został zaatakowany i teraz ją zaktualizowaliśmy), które należy podjąć oraz mini-audyt bezpieczeństwa, który warto przeprowadzić w każdym sklepie PrestaShop, a tak naprawdę w każdym sklepie warto go przeprowadzać co jakiś czas dla świętego spokoju.

Jak dbać o bezpieczeństwo sklepu internetowego

Jakie wnioski Paweł i Piotr wynieśli z powyższych sytuacji?

1. Nie czekać z działaniem, jeśli już wiadomo, że coś się dzieje i są 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:
   1. odpowiednie hasła, a także ich zabezpieczenie (wystarczy poczytać Niebiezpiecznika, jak łatwo stracić hasła)
   2. nie korzystać z backendu sklepu przez zewnętrzne wifi oraz zabezpieczać sieć wifi (duży problem zwłaszcza teraz w czasach pracy zdalnej)
   3. utrzymywać porządek w sklepie np. usuwać nieużywane moduły – takie “śmieci” to furtki, które zwiększają ryzyko ataku, a w razie problemów kolejne setki-tysiące linijek kodu, które trzeba sprawdzić

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.

1. Wykonywać co jakiś czas audyty bezpieczeństwa, co zresztą sama PrestaShop wyraźnie zaleca w oficjalnej informacji wydanej na temat tych problemów z bezpieczeństwem.
2. Utrzymywać kopie zapasowe sklepu.

Takie wydarzenia zawsze przypominają (niestety dosyć brutalnie), że hakerzy i ataki na strony istnieją. Na co dzień przy dłuższej chwili ciszy często wiele osób zapomina o nich ignorując podstawowe zasady bezpieczeństwa. Warto mieć świadomość, że chwila ciszy nie oznacza, że już nic nigdy się nie wydarzy. Lepiej mieć z tyłu głowy, że wydarzy się na pewno i zrobić wszystko, by nie przydarzyło się właśnie nam.