Sklep e-commerce na PrestaShop — wykryte aktywne włamanie

Dlaczego klient się zgłosił

Klient zgłosił się z pozornie błahym problemem — sklep działał wolno. W rozmowie wyszło coś znacznie poważniejszego: sprzedaż od dłuższego czasu spadała, a biznes szedł coraz gorzej bez wyraźnego powodu. Przegląd wyjaśnił dlaczego. Ktoś — na bieżąco i po cichu — wykradał dane: adresy e-mail klientów oraz historię zamówień (kto, co i za ile kupił). To dokładnie te dane, na których konkurencja buduje przewagę: gotowa baza klientów z ich koszykiem zakupowym.

Kluczowe ustalenia

1. KrytyczneAktywne backdoory (webshelle) wgrane na serwerDwa złośliwe skrypty PHP ukryte w plikach modułów. Analiza porównawcza kopii zapasowych dowiodła, że pojawiły się w konkretnym dniu (były nieobecne kilka dni wcześniej) — to potwierdzone, aktywne włamanie, a nie tylko teoretyczna podatność. Dawały atakującemu zdalne wykonywanie poleceń.
2. KrytyczneKlucz API sklepu umożliwiał odczyt danych klientów i zamówieńUjawniony token dostępowy do webservice API pozwalał odpytać sklep o dane klientów, adresy i pełną historię zamówień (kto, co i za ile kupił). To najprawdopodobniej główny kanał cichego, ciągłego wycieku bazy klientów i zamówień — bez śladu w panelu sklepu.
3. KrytyczneHasła do bazy danych dostępne z internetu (kopia .bak)Stara kopia pliku konfiguracyjnego z poświadczeniami do bazy, odłożona przy pracach deweloperskich i nieusunięta. Serwer oddawał ją jako czysty tekst (rozszerzenie .bak nie jest wykonywane jako PHP) — czytelna publicznie od ~2 lat.
4. KrytyczneTrwały backdoor w module integracyjnymSkrypt z dostępem do bazy danych i systemu plików, obecny na serwerze od jego powstania (~2 lata). Klasyczny mechanizm utrzymania dostępu (persistence) — niewidoczny w panelu sklepu.
5. KrytycznePrzestarzała platforma (PrestaShop 1.7, koniec wsparcia) + podatne modułySklep działał na PrestaShop 1.7 — wersji bez wsparcia bezpieczeństwa — z modułami z potwierdzonymi CVE. To fundament, na którym możliwe były pozostałe podatności; przesądza o konieczności modernizacji platformy.
6. WysokieTryb debug włączony na produkcjiAplikacja ujawniała wewnętrzne dane i ścieżki. Poprawione od ręki w trakcie analizy.
7. WysokieLogi z danymi klientów częściowo dostępne z sieciLog jednej z wtyczek (zawierający m.in. adresy IP klientów i kwoty zamówień) był dostępny publicznie, bez ochrony. Zabezpieczony regułą serwera; główne logi aplikacji były chronione (403).
8. WysokieNiebezpieczne funkcje PHP odblokowane, brak izolacjiFunkcje takie jak exec/system/shell_exec były dostępne, a izolacja ścieżek (open_basedir) niewłączona — to dramatycznie zwiększa skutki wejścia atakującego przez webshell.
9. ŚrednieKatalogi z prawami zapisu dla wszystkich (777)Część katalogów na pliki/media była world-writable — możliwość wgrania lub podmiany plików.
10. ŚrednieArchiwa ZIP modułów dostępne z sieciPozostawione paczki instalacyjne modułów można było pobrać z internetu — ułatwia analizę i atak na konkretne wersje.
11. ŚrednieBrak nagłówków bezpieczeństwa i wyłączone zabezpieczenia sesjiBrak HSTS/CSP/X-Frame-Options; ciasteczka sesji bez flag httponly/secure — większa powierzchnia ataków XSS/clickjacking/przejęcia sesji.

Co było zrobione dobrze

• Włamanie ograniczone do uprawnień aplikacji (użytkownik serwera WWW) — atakujący nie mógł odczytać systemowego pliku haseł (/etc/shadow)
• Pliki i hasła systemowe nietknięte od założenia serwera
• Główne logi aplikacji oraz pliki konfiguracyjne chronione (HTTP 403)
• Polityka poczty DMARC w trybie p=reject
• Posiadane kopie zapasowe umożliwiły forensykę i ustalenie momentu włamania

Plan naprawczy

1. Natychmiast: usunięcie obu webshelli i całego modułu z backdoorem, usunięcie kopii .bak z hasłami, unieważnienie i rotacja klucza API, wyłączenie trybu debug, zablokowanie dostępu do odsłoniętego logu
2. 24–48h (zespół dev): rotacja haseł/kluczy, konfiguracja open_basedir i disable_functions, naprawa uprawnień katalogów (777 →), usunięcie archiwów ZIP, aktualizacja podatnych modułów, włączenie nagłówków i zabezpieczeń sesji
3. Modernizacja: wykonaliśmy upgrade PrestaShop 1.7 → 8.x (powrót na wspieraną, regularnie łataną wersję); na czas prac ochrona ruchu przez CDN/WAF jako warstwa łagodząca

Wynik

Przegląd ujawnił aktywne włamanie: webshelle, długotrwały backdoor, hasła do bazy dostępne publicznie od ~2 lat oraz klucz API otwierający dane klientów i zamówień. Najgroźniejsze elementy usunęliśmy natychmiast; resztę przekazaliśmy zespołowi deweloperskiemu z planem naprawczym i rekomendacją migracji. Włamanie było ograniczone do uprawnień aplikacji — system operacyjny i hasła systemowe pozostały nienaruszone, a moment włamania udało się ustalić dzięki analizie kopii zapasowych. W ramach naprawy wykonaliśmy też upgrade platformy z PrestaShop 1.7 do 8.x — sklep wrócił na wspieraną, regularnie łataną wersję.