Sklep po włamaniu: co robić w pierwszej godzinie

O włamaniu zwykle dowiadujesz się nie od systemu, tylko od klienta, który pisze, że po zakupie u Ciebie ktoś obciążył mu kartę, albo od operatora płatności, który blokuje konto. Pierwsza godzina decyduje, czy sprawa skończy się na jednym nerwowym dniu, czy na tygodniach sprzątania, karze i utracie zaufania. Poniżej kolejność działań, którą stosujemy przy pomocy zdalnej po włamaniu, razem z tym, czego nie robić.

Minuty 0 do 10: odcięcie

Celem pierwszych minut jest zatrzymanie szkód, nie ich zrozumienie. Każda minuta działania sklepu z podmienionym skryptem płatności to kolejne dane kart u przestępców.

1. Włącz tryb konserwacji. W panelu PrestaShop albo, jeśli panel nie działa lub nie ufasz mu, przez plik .htaccess lub konfigurację serwera. Klienci widzą komunikat, skrypty w sklepie nie wykonują się.
2. Zablokuj panel administracyjny. Ogranicz dostęp do katalogu panelu do Twojego adresu IP. Włamywacz, który ma hasło administratora, traci dostęp.
3. Wyłącz zadania cron i integracje. Żeby zainfekowane dane nie popłynęły do magazynu, kuriera czy marketplace.
4. Nie wyłączaj serwera i nie kasuj plików. Potrzebujesz ich jako dowodu i źródła informacji o tym, co się stało.

Minuty 10 do 30: hasła

Załóż, że włamywacz ma wszystkie hasła, które były zapisane w sklepie albo którymi logowano się do niego. Zmieniaj od najważniejszego.

• Panel hostingu i konto u dostawcy serwera.
• SSH i FTP do serwera. Jeśli FTP bez szyfrowania jest nadal włączony, wyłącz go na stałe.
• Baza danych. Nowe hasło wpisz do konfiguracji sklepu.
• Wszystkie konta administratora w PrestaShop. Nieznane konta usuń, nie tylko zablokuj.
• Klucze API: webservice, Admin API, klucze do operatora płatności, kurierów, BaseLinkera, systemu ERP.
• Skrzynki pocztowe, z których sklep wysyła maile i na które przychodzą powiadomienia o resetach haseł.
• Hasła osób, które logowały się do sklepu z własnych komputerów. Włamanie często zaczyna się od zainfekowanego laptopa pracownika, nie od sklepu.

Minuty 30 do 60: zabezpieczenie dowodów

Zanim zaczniesz sprzątać, zrób pełną kopię zainfekowanego sklepu: pliki, bazę, logi serwera WWW, logi PHP, logi logowań do panelu i do SSH. Zapisz ją poza serwerem, z datą. Ta kopia odpowie później na trzy pytania: kiedy weszli, jak weszli i do czego mieli dostęp. Bez niej zgłoszenie do UODO będzie zgadywaniem, a dziura zostanie niezałatana, bo nie będziesz wiedział, która to była.

Spisz też od razu, co wiesz: kiedy klient zgłosił problem, od kiedy sklep zachowuje się inaczej, co ostatnio instalowano, kto miał dostęp.

Pierwsza doba: ustalenie, co się stało

Dopiero teraz, ze sklepem odciętym i kopią zabezpieczoną, szukasz przyczyny. Najczęstsze scenariusze przy sklepach na PrestaShop są dość powtarzalne.

Objaw	Co zwykle za tym stoi	Gdzie szukać
Klienci zgłaszają obciążenia kart po zakupie	skrypt podmieniający formularz płatności (skimmer) w szablonie lub module	Pliki JavaScript szablonu i modułów, kod wstrzyknięty w bazie w konfiguracji sklepu lub w treściach CMS
Przekierowania na obce strony, obce reklamy	wstrzyknięty kod w pliku index, w .htaccess lub w szablonie	.htaccess, pliki rdzenia porównane z czystą wersją, zadania cron
Nowe konta administratora, zmienione maile	wykradzione hasło, luka w starym module	Dziennik logowań do panelu, tabela pracowników, data utworzenia kont
Spam wysyłany z serwera	wgrany plik PHP w katalogu na pliki (upload, img, modules)	Pliki PHP w katalogach, w których nie powinno ich być, pliki zmienione w ostatnich dniach
Sklep zaszyfrowany, żądanie okupu	przejęcie serwera, często przez stare PHP lub słabe hasło SSH	Logi SSH, panel hostingu, kopia zapasowa poza serwerem

Dwie techniki dają najwięcej: porównanie plików sklepu z czystą wersją tej samej wersji PrestaShop i modułów oraz lista plików zmienionych w ostatnich dniach. Większość wstrzykniętego kodu jest w plikach, które powinny być identyczne z oryginałem, albo w plikach, które nie powinny istnieć.

Czyszczenie: nie kasuj jednego pliku i nie wracaj do pracy

Usunięcie znalezionego skryptu to nie koniec. Włamywacze zostawiają kilka wejść, żeby wrócić, gdy usuniesz pierwsze. Czyszczenie, które się trzyma, wygląda tak.

Zgłoszenie do UODO: 72 godziny

Jeśli włamanie mogło objąć dane osobowe klientów, a przy sklepie niemal zawsze mogło, masz 72 godziny od stwierdzenia naruszenia na zgłoszenie do Urzędu Ochrony Danych Osobowych. Liczy się od momentu, w którym stwierdziłeś, że doszło do naruszenia, nie od momentu, w którym wszystko już wiesz. Jeśli po 72 godzinach nadal nie masz pełnych informacji, zgłaszasz to, co wiesz, i uzupełniasz później.

Zgłoszenie opisuje, co się stało, jakich danych i ilu osób dotyczy, jakie są możliwe skutki i co zrobiłeś. To właśnie dlatego kopia zainfekowanego sklepu i logi są tak ważne: pozwalają powiedzieć „dane kart wpisywane między 3 a 22 października” zamiast „nie wiemy”. Jeśli naruszenie niesie wysokie ryzyko dla klientów, a wyciek danych kart taki niesie, musisz też poinformować samych klientów.

Komunikacja z klientami

To najtrudniejsza część i ta, którą sklepy najczęściej odkładają. Nie odkładaj. Klient, który dowie się od banku, a nie od Ciebie, nie wróci. Klient, który dostanie od Ciebie jasny mail, ma szansę zrozumieć.

• Napisz prosto: co się stało, w jakim okresie, jakich danych dotyczy, co klient powinien zrobić (np. skontaktować się z bankiem i wymienić kartę), co Ty już zrobiłeś.
• Nie pisz „niewielka liczba klientów” ani „z powodu zaawansowanego ataku”. Pisz konkretnie i bez wybielania.
• Podaj jeden kontakt do pytań i odpowiadaj na nie.
• Powiadom operatora płatności, bo on może wymagać własnego raportu i może zablokować wypłaty, dopóki go nie dostanie.
• Jeśli sklep był przez kilka dni w trybie konserwacji, krótka informacja na stronie i w mediach społecznościowych jest lepsza niż milczenie.

Włamanie zdarza się każdemu, kto dość długo prowadzi sklep. To, jak zareagujesz w pierwszej godzinie, klienci zapamiętają bardziej niż samo włamanie.

Czego nie robić

• Nie przywracaj kopii sprzed tygodnia i nie wracaj do pracy, zanim ustalisz, jak weszli. Kopia może już zawierać tylne wejście, a luka nadal jest otwarta.
• Nie zmieniaj haseł z zainfekowanego komputera.
• Nie kasuj logów i zainfekowanych plików bez kopii. Są dowodem i źródłem informacji.
• Nie czekaj ze zgłoszeniem, aż będziesz wiedział wszystko. 72 godziny mijają szybciej, niż się wydaje.
• Nie ukrywaj sprawy przed klientami. Dowiedzą się i tak, lepiej od Ciebie.

Pytania, które słyszymy najczęściej

Czy mogę to zrobić samodzielnie?

Pierwsze kroki tak: tryb konserwacji, hasła, kopia. Ustalenie przyczyny i czyszczenie wymagają doświadczenia, bo przeoczone tylne wejście oznacza powtórkę za dwa tygodnie. Tu zwykle wchodzimy my, zdalnie, w ciągu godzin od zgłoszenia.

Skąd mam wiedzieć, czy wyciekły dane osobowe?

Z logów i z analizy wstrzykniętego kodu. Skimmer na stronie płatności oznacza dane kart. Dostęp do panelu lub bazy oznacza dane klientów z adresami. W razie wątpliwości załóż, że wyciekły, i zgłoś.

Czy po włamaniu muszę zmienić hosting?

Nie zawsze. Musisz zmienić to, przez co weszli: przestarzałą wersję PrestaShop, porzucony moduł, słabe hasło, stare PHP. Jeśli hosting nie daje wspieranego PHP ani logów, to jest moment na zmianę.

Jak nie dopuścić do tego ponownie?

Wspierana wersja PrestaShop i PHP, aktualne moduły od aktywnych autorów, osobne konta i dwuskładnikowe logowanie, zmieniony adres panelu, kopie poza serwerem i monitoring zmian w plikach. Czyli stała opieka, nie jednorazowe czyszczenie.