Sklepy na starych wersjach PrestaShop 1.7 potrafią działać latami bez widocznych problemów. Zamówienia spływają, płatności przechodzą, klienci nie narzekają. Właściciel wychodzi z założenia, że skoro nic się nie psuje, to nie ma czego ruszać. Problem w tym, że od zewnątrz sklep po włamaniu wygląda dokładnie tak samo jak przed nim. Różnica jest widoczna dopiero od środka.
Co znajdujemy w sklepach na starych wersjach Prestashop?
Przy audytach sklepów działających na porzuconych wydaniach 1.7 powtarza się zestaw znalezisk, który układa się w dość ponury wzorzec.
Klasyka to plik udający coś niewinnego. Nazwa jak skrypt JavaScript, pozostawiony w katalogu publicznym. Po sprawdzeniu okazuje się skompilowanym programem linuksowym z prawem wykonania: na przykład exploitem lokalnej eskalacji uprawnień, czyli narzędziem do przejęcia konta root na serwerze. Obok, w katalogach tymczasowych, zostają artefakty z jego testowania.
Do tego dochodzą rzeczy, których atakujący nawet nie musiał wnosić, bo czekały na niego na miejscu:
- Publicznie dostępny phpMyAdmin wgrany do katalogu sklepu, z danymi logowania do bazy w pliku konfiguracyjnym obok. Każdy, kto zna adres, ma otwartą furtkę do bazy z danymi klientów.
- Porzucone, stare instalacje na tym samym koncie FTP: kopie sklepu sprzed lat, wersje testowe, osobne serwisy, których nikt nie aktualizuje ani nie monitoruje.
- Menedżer plików w panelu administracyjnym w wersji z historycznie znaną podatnością na zdalne wykonanie kodu przez upload. W gałęzi 1.7 to jeden z najczęstszych punktów wejścia.
- Zero hardeningu: brak nagłówków bezpieczeństwa, otwarte CORS, wersje oprogramowania widoczne dla każdego skanera.
Bywa i tak, że baza danych jest jeszcze czysta: bez fałszywej bramki płatności, bez skimmera kart, bez podrzuconych kont administratora. To znaczy tyle, że audyt wypadł w oknie między rozpoznaniem a monetyzacją. Atakujący zdążył się rozgościć, ale jeszcze nie zaczął zarabiać.
Dlaczego wersja 1.7 jest problemem sama w sobie?
Starsze wydania gałęzi 1.7 nie otrzymują poprawek bezpieczeństwa od lat. Każda podatność odkryta po zakończeniu wsparcia zostaje w kodzie na zawsze. Lista publicznie znanych CVE dla tych wydań jest długa i ogólnodostępna, więc atakujący nie musi niczego odkrywać. Wystarczy, że skaner sprawdzi wersję sklepu (a ta często jest widoczna w nagłówkach lub plikach) i sięgnie po gotowy exploit.
Charakterystyczny ślad, na który regularnie trafiamy: zainstalowany moduł naprawczy do głośnej podatności z 2022 roku. Jego obecność oznacza, że sklep już kiedyś był atakowany i ktoś próbował go łatać. Sklepy na porzuconych wersjach nie są atakowane raz. Wracają na celownik regularnie, bo skanery szukające podatnych instalacji skanują sieć non stop.
Brak aktualizacji Prestashop 1.7.X — czym to grozi w praktyce?
Trzy scenariusze, które widujemy najczęściej przy skompromitowanych sklepach na starych wersjach:
Skimmer kart i fałszywe bramki płatności. Atakujący podmienia lub dokłada kod na stronie płatności i przechwytuje dane kart klientów. Sklep działa normalnie, właściciel niczego nie widzi, a klienci po zakupach zgłaszają nieautoryzowane transakcje. Poza stratami wizerunkowymi ten scenariusz otwiera temat odpowiedzialności z RODO, bo doszło do naruszenia ochrony danych osobowych, z obowiązkiem oceny zgłoszenia do UODO włącznie.
Przejęcie konta hostingowego. Sklep staje się przyczółkiem do ataku na cały serwer. Na hostingu współdzielonym exploit eskalacji uprawnień zagraża nie tylko Twojemu sklepowi, ale wszystkim klientom tego serwera. Działa to zresztą w obie strony: kompromitacja cudzego konta na tym samym serwerze może skończyć się zapisem w Twoich plikach.
Ciche wykorzystanie zasobów. Wysyłka spamu, hosting phishingu, kopanie kryptowalut. Sklep trafia na czarne listy, maile transakcyjne przestają dochodzić, pozycje w Google lecą w dół. Diagnoza trwa tygodniami, bo objawy nie wskazują wprost na włamanie.
Dlaczego stare instalacje na koncie to tykająca bomba?
Wątek, który w audytach powtarza się zaskakująco często: na jednym koncie hostingowym, obok żywego sklepu, leżą stare kopie „na wszelki wypadek”. Instalacja sprzed migracji, testowa wersja z zeszłego roku, porzucony sklep po poprzednim projekcie.
Wszystkie te kopie działają w kontekście tego samego użytkownika systemowego. Wystarczy jedna podatność w jednej zapomnianej instalacji, żeby atakujący uzyskał zapis w całym koncie, łącznie z katalogiem produkcyjnego sklepu. Porzuconych kopii nikt nie łata i nikt ich nie monitoruje, więc to najłatwiejsza droga wejścia. A po incydencie utrudniają śledztwo: przy kilku instalacjach ustalenie, którędy nastąpiło włamanie i czy wyczyściliśmy wszystko, robi się nieporównanie trudniejsze.
Zasada jest krótka: stare instalacje archiwizujemy poza serwerem produkcyjnym i usuwamy z konta.
Czy po włamaniu wystarczy „wyczyścić i zaktualizować”?
Kusząca opcja, bo tańsza. Problem w tym, że po głębokim incydencie nigdy nie ma pewności, że usunęło się wszystko. Backdoor może siedzieć w zmodyfikowanym pliku rdzenia, w module, w zadaniu cron, w koncie, którego nikt nie zweryfikował. Czyszczenie „w miejscu” na zainfekowanej instalacji sprzed ośmiu lat to budowanie na fundamencie, którego nie da się prześwietlić do końca.
Kolejność, którą rekomendujemy przy poważnych incydentach, wygląda inaczej:
- Reakcja na incydent. Zgłoszenie do hostingodawcy (exploit na koncie współdzielonym zagraża całemu serwerowi), zabezpieczenie dowodów, odcięcie publicznie dostępnych narzędzi administracyjnych.
- Odbudowa na czysto. Świeża instalacja aktualnej wersji PrestaShop 8 na nowym środowisku i migracja zweryfikowanych danych: produktów, zamówień, klientów. Bez przenoszenia ani jednego pliku ze starej instalacji.
- Rotacja wszystkich poświadczeń. FTP, panel administracyjny, baza danych, SMTP, klucze API. Wszystko, co istniało przed incydentem, traktujemy jako spalone.
- Hardening i zmiana środowiska. Hosting współdzielony bez dostępu SSH, bez kontroli nad firewallem i backupami nie daje warunków do utrzymania bezpieczeństwa. Docelowo VPS albo zarządzany hosting z izolacją konta i osobnym stagingiem.
Jak sprawdzić, czy Twój sklep internetowy ma ten problem?
Kilka pytań, na które warto znać odpowiedź już dziś:
- Na jakiej dokładnie wersji PrestaShop działa sklep i czy ta wersja wciąż otrzymuje poprawki bezpieczeństwa?
- Ile instalacji leży na koncie hostingowym poza produkcyjnym sklepem?
- Ilu jest SuperAdminów w panelu i czy każde konto ma uzasadnienie? Konta dawnych podwykonawców i agencji to norma, nie wyjątek.
- Czy phpMyAdmin lub inne narzędzia administracyjne są dostępne publicznie?
- Kiedy ostatnio ktoś przeglądał pliki sklepu pod kątem rzeczy, które nie powinny tam być?
Jeżeli na któreś z tych pytań odpowiedź brzmi „nie wiem”, to dobry moment na audyt bezpieczeństwa i gotowości do aktualizacji. Pełną listę rzeczy do sprawdzenia zebraliśmy w checkliście bezpieczeństwa sklepu PrestaShop. Robimy go w trybie wyłącznie do odczytu, więc diagnostyka niczego nie zmienia na produkcji. Dostajesz raport z konkretną listą ustaleń, priorytetami i rekomendowaną ścieżką: aktualizacja, odbudowa albo najpierw reakcja na incydent.
Jeśli Twój sklep wciąż działa na porzuconej wersji 1.7, pytanie nie brzmi „czy ktoś spróbuje wejść”, tylko „czy już nie wszedł”. Sprawdź, zanim odpowie za Ciebie ktoś inny — napisz do nas, a zaczniemy od bezpłatnej diagnostyki sklepu.
