[PrestaShop 1.6] Fałszywy formularz PayPal w miejscu metody płatności. Czy to atak hakerski?

Fałszywa płatność PayPal w PrestaShop – czy to kolejna odsłona ataku znanego z PS 1.7?

Już raz poruszaliśmy na blogu atak na kod PrestaShop 1.7, który powodował podczas zamówienia przekierowanie na formularz PayPal:

Czasowe wyłączenie sklepu dla klientów z możliwością oglądania go przez właściciela [Aktualizacja]

Okazuje się, że PrestaShop 1.6 ma też swój „odpowiednik” jeśli chodzi o fałszywą metodę płatności także pod tą wersję. Wersja, którą bierzemy tutaj pod uwagę to: PrestaShop 1.6.1.24.

Chcemy tutaj podkreślić, że metoda płatności PayPal jest w pełni bezpieczna i możemy ją rekomendować dla właścicieli sklepów PrestaShop. Opisywany tutaj atak nie miał z oficjalnym modułem PayPal nic wspólnego. Nawet sklep, na którym on wystąpił nigdy z niego nie korzystał..

Warto też wspomnieć, że sam producent PrestaShop wskazuje na możlwość takiego ataku na starszych wersjach oprogramowania na swoim blogu.

Jednak warto zauważyć, że atak ten jest szczególnie ciężki do wykrycia w kodzie (o czym szerzej w dalszej części artykułu) i na pierwszy rzut oka wydaje się, że naprawa takiego sklepu jest wręcz niemożliwa… Jednak.. naszemu zespołowi się to w pełni udało 🙂 Poniżej szczegóły.

Jakie są symptomy ataku?

Pierwszym sygnałem są niedostępne metody płatności oferowane przez sklep. Zamiast tego w szablonie, gdzie się pojawiają sposoby na zapłatę za towar (przelew on-line, przelew tradycyjny, płaność przy odbiorze itp.) pojawia się tylko 1 metoda płatności. Fałszywy baner PayPal, który „udaje” oficjalny moduł patności przez ten kanał. Nawet, co ważne jeśli w naszym sklepie nie ma i nigdy nie było modułu PayPal:

Widok w sklepie korzystającym z zamówienia na 1 stronie (One Page Checkout):

Widok dla standarowego zamówienia:

Widok po kliknięciu w baner:

Jak widać banner na pierwszy rzut oka jest łudząco podobny do oficjalnego modułu płatnosci PayPal w PrestaShop.

Jednak po jego kliknięciu (co widać na screenie powyżej) pojawia się formularz do wyłudzenia danych karty kredytowej. Dane są następnie zczytywane przez przestępców i przez nich wykorzystywane.

UWAGA! Jeśli takie objawy ataku ma Twój sklep internetowy musisz działać natychmiast ! Przestępcy podszywający się pod PayPal mogą narazić Twoich klientów na stratę pieniędzy, co może mieć katastrofalne konsekwencje także dla Ciebie !

Co robić, jeśli zauważę taki atak?

Na sam początek, aby nie wyłączać kompletnie sklepu (i np. nie stracić pozycji SEO – pozycjonowanie) sugerujemy włączyć tzw. „tryb katalogu” w sklepie PrestaShop.

Oznacza to, że sklep będzie w pełni możliwy do jego przeglądania (opisy produktów, kategorii) jednak nie będzie można na nim złożyć zamówienia.

Wystarczy, że wejdziesz w dział:

Preferencje -> Produkty

I zaznaczysz opcję „Tryb katalogu” na TAK:

Zabezpieczy Cię to przed statą pozycji w Google oraz uniemożlwi to wyświetlanie ataku przez fałszywy moduł PayPal. Jednak, jak wspomniano wyżej, tryb katalogu także zablokuje tworzenie nowych zamówień przez klientów. Czyli mówiąc wprost – klienci nie będą mogli nic kupić na Twoim sklepie.

Aby dalej prowadzić sprzedaż są niestety konieczne zmiany w kodzie i plikach, które opiszemy poniżej.

– – – – –

AUTOREKLAMA 🙂

Nasz zespół programistyczny stworzył specjalny moduł do usuwania tej infekcji (nawet jeśli ona powróci). Zapraszamy do zapoznania się z ofertą:

– – – – –

Usunięcie infekcji – kopia bezpieczeństwa

Na początek wykonaj kopię bezpieczeństwa plików oraz bazy danych. O spakowanie plików sklepu możesz poprosić Twojego administratora serwera. Co do bazy danych możesz to wykonać samemu/ej w dziale:

Zaawansowane -> Kopia zapasowa DB

Pobranie plików wersji oryginalnej PrestaShop

Kolejnym etapem jest ustalenie jaką dokłądną wersję PrestaShop 1.6 posiadasz. Numer tej wersji jest widoczny podczas logowania do admina sklepu oraz w dziale:

Zaawansowane -> Informacje konfiguracyjne

Pobierz następnie oryginalne pliki PrestaShop tej wersji korzystając z linku postaci:

https://download.prestashop.com/download/releases/prestashop_[NUMER-WERSJI].zip

dla przykładu jak posiadasz wersję 1.6.1.24, użyj linku:

https://download.prestashop.com/download/releases/prestashop_1.6.1.24.zip

Lista zainfekowanych plików.

Jak opisano wyżej, infekcja jest wyjątkowo trudna do analizy. Przestępcy dla utrudnienia odnalezienia zmodyfikowanych przez siebie plików – zmienili praktycznie każdy plik PHP na serwerze. W bardzo chytry i prosty sposób. Po prostu dodali komentarz na początku każdego pliku PHP. Dla przykładu plik przed zmianą:

<?php
/*
* 2007-2017 PrestaShop
*
* NOTICE OF LICENSE

Plik po zmianie:

<?php
/**/
/*
* 2007-2017 PrestaShop
*
* NOTICE OF LICENSE

Ta niewielka zmiana w kodzie powoduje, że praktycznie każdy plik PHP w sklepie jest zmodyfikowany względem oryginału i ciężko „wyłowić” infekcję przez np. analizę plików za pomocą SVN lub GIT – więcej informacji na ten temat znajdziesz tutaj.

W każdym razie w wyniku naszych działań udało się ustalić, które pliki zostały zainfekowane. Są to:

M       classes/Dispatcher.php
M       classes/Employee.php
M       classes/Tools.php
M       config/alias.php
M       controllers/front/IndexController.php
M       modules/bankwire/controllers/front/validation.php
M       tools/smarty/sysplugins/smarty_cacheresource.php

Należy ww. pliki PHP, gdzie jest złośliwy kod usunąć, a na ich miejsce wstawić pliki z pobranej paczki ze strony producenta oprogramowania PrestaShop.

UWAGA! Jeśli Twój sklep posiada jakieś niestandardowe modyfikacje należy je uwzględnić podczas wyleczenia pliku. W takim wypadku konieczna jest tutaj praca programisty.

Oczywiście nie tylko te pliki mogą zawierać złośliwą infekcje i konieczne jest sprawdzenie także innych. Ale tym musi zająć się specjalista. Ponownie zapraszamy do skorzystania z naszej oferty.

Szczególnie niebezpieczny plik.

Z pośród wyszczególnionych plików, które zawierały kod wklejony przez hakera najistotniejszym jest plik:

tools/smarty/sysplugins/smarty_cacheresource.php

Kod został w nim głęboko zaszyfrowany i ciężko jest go wyłowić np. przez analizatory kodu. Jest doklejony niepostrzeżenie na końcu pliku i może to uciec uwadze programisty. Użyto w nim ponadto specyficznego kodowania i może być wręcz nieczytelny dla niektórych edytorów tekstowych:

To praktycznie ten kod odpowiada za wyświetlenie fałszywego modułu. Należy wykasować ten plik i na jego miejsce wstawić oryginalny z pakietu dla tej wersji.

Warto tutaj zaznaczyć, że otwieranie/edycja takich plików jest wględnie bezpieczne dla Twojego komputera. Kod w nich zawarty nie ma nic wspólnego z ewentualnym atakiem na Twój system operacyjny. Nie masz zatem co się obawiać np. zaifekowania Twojego komputera. Jest to zupełnie inne zagrożenie 🙂 W każdym razie nasza redakcja nie odpowiada za ew. szkody wywołane nieumiejętnym wykorzystaniem tego kodu.

Możliwe problemy.

Po podmianie plików możesz natrafić na problemy z działeniem sklepu. Spróbuj następujących wskazówek.

Usunięcie cache

Usuń cache sklepu. Wykasuj folder

/cache

oraz wejdź w dział

Zaawansowane -> Wydajność

i wyłącz kompletnie pamięć podręczną (cache) i wymuś kompilację:

Wyczyszczenie nadmiarowych tabel

Twój sklep w zależności od ustawień może też składować pliki cache w bazie danych. Dla pewności możesz wykasować nadmiarowe tabele z bazy MySQL. Co prawda pozbędziesz się też logów i statystyk, ale baza (jeśli np. jest przeładowana) powinna dodatkowo wpłynąć na szybsze działanie sklepu. Opisywaliśmy to w artykule:

wyczyszczenie niepotrzebnych tabel w bazie danych [Aktualizacja]

Złe działanie wbudowanego systemu Smarty.

System Smarty to wbudowany w PrestaShop system oddzielający PHP od kodu HTML. Istnieje on w tym silniku sklepu internetowego praktycznie od samego początku. W każdym razie infekcja także dotknęła elementy tej biblioteki i jej funkcjonowanie może powodować błedy w działaniu szablonu. Poprzez wyświetlanie białej strony, a po właczeniu błędów PHP – błędy dotyczące Smarty.

Najszybszym rozwiązaniem będzie usunięcie całego folderu:

/tools/smarty

I na jego miejsce wstawienie folderu z pliku ZIP z oryginalnymi plikami biblioteki ze strony producenta.

Zabezpieczenie sklepu

Jednak co zrobić aby infekcja się nie pojawiła się ponownie? Niestety poza aktualizacją do wersji minimum 1.7.8.2 ciężko coś innego doradzić… Jednak wiadomo wiąże się to z dużą przebudową sklepu, koniecznością zakupu i konfiguracji nowego szablonu, jego przetłumaczeniem itp. Wymaga to kalkulacji kosztów.

Jednak to, co możesz zrobić juz teraz to:

• Natychmiastowa zmiana dostępów do MySQL i naniesienie zmian w pliku:

  config/settings.inc.php

• Natychmiastowe usunięcie wszystkich kont FTP na serwerze sklepu, pozostawienie tylko jednego konta i przypisanie mu zawiłego hasła
• Natychmiastowa zmiana hasła do serwera (hosting) szczególnie jak hasło do serwera było takie same jak do FTP !
• Natychmiastowe usunięcie wszystkich kont administatora sklepu (dział Administracja -> Pracownicy), pozostawienie tylko 1 konta i zmiana hasła na bardzo skomplikowane
• Opcjonalna zmiana wartości zmiennej _COOKIE_KEY_ w pliku

  config/settings.inc.php

  na inny ciąg losowych znaków o tej samej długości. UWAGA ! będzie to skuktowało koniecznością zmiany hasła przez każdego klienta (w tym konta admina!). Tzn stare hasła juz nie zadziałają i należało by o tym poinformować klientów np. na stronie logowania do swojego konta.

• Natychmiastowa zmiana ścieżki do logowania do admina. Po prostu na FTP zmień nazwę folderu, gdzie się logujesz. Np. jeśli jest to

  [adres-sklepu]/admin123123

  zmień nazwę folderu o nazwie „admin123123” na serwerze na np. „ZHSLDz92FvkXF” wtedy adres logowania do admina będzie miał postać:

  [adres-sklepu]/ZHSLDz92FvkXF

  Logowanie będzie działało tak samo jak dotychczas jednak pod innym adresem.

• Wskazany jest monitoring kodu i bazy danych takiego sklepu przez parę dni/tygodni po ataku. Czy włam nie wystąpił ponownie lub czy w plikach sklepu lub wpisach bazy danych nie występują dziwne ruchy.
• Zakupienie specjalistycznego modułu do leczenia plików PrestaShop. Wspomnieliśmy o tym w artykule. Moduł automatycznie (CRON) usuwa i leczy pliki na podstawie wzorców. Więcej na ten temat przeczytasz tutaj.

Usunięcie kodu – analogicznie jak w PrestaShop 1.7

Rozważ też wykonanie tej modufikacji w Twoim sklepie. Tak jak zaznaczyliśmy w tamtym artykule – jest to jeszcze w fazie sprawdzania.

– – – – – –

Mamy nadzieję, że opisany tutaj sposób poradzenia sobie z tym atakiem przysłużył się Tobie z naprawą Twojego sklepu! Podziel się Twoim doświadczeniem w komentarzu pod postem albo na naszym profilu na FB 🙂

Powodzenia !