Sklep internetowy (dane poufne) · Handel internetowy

Usunięcie backdoora i skimmera kart płatniczych ze sklepu WooCommerce

Analiza włamania do sklepu WooCommerce przez lukę w rdzeniu WordPressa. Odnalezienie i usunięcie skimmera, czyli skryptu podkradającego dane kart płatniczych przy zakupie, usunięcie kont napastników, zamknięcie drogi wejścia i materiał dla prawnika do zgłoszenia UODO.

Strona główna serwisu: Sklep internetowy (dane poufne)
plików sklepu sprawdzonych – zero obcych plików i obcych kont po sprzątaniu
100%
droga wejścia – luka zaktualizowana, punkt ataku zablokowany na zaporze, aktualizacje znów działają
zamknięta
dokładny okres wycieku ustalony z logów – zawiadomienie objęło tylko klientów faktycznie dotkniętych
5 dni

01 · Wyzwanie

Wyzwanie

Właściciel sklepu WooCommerce dowiedział się o problemie od klientów: przy płatności pojawiało się dodatkowe okno proszące o dane karty. Tak działa skimmer: skrypt podstawiony w sklepie, który przy zakupie przechwytuje dane kart płatniczych i wysyła je napastnikom, a zamówienie przechodzi normalnie, więc nikt niczego nie zauważa. Skaner antywirusowy zainstalowany w sklepie zgłaszał kilka podejrzanych plików, ale ich usunięcie nic nie zmieniało. Trzeba było ustalić, jak napastnik uzyskał dostęp, co dokładnie zrobił, ile zamówień przeszło przez podstawioną płatność – i przygotować to w formie, którą prawnik klienta mógł wykorzystać przy zgłoszeniu do UODO.

02 · Rozwiązanie

Rozwiązanie

Zacząłem od logów serwera, nie od plików. Oś czasu pokazała serię żądań do jednego punktu API WordPressa, przez który napastnicy wykorzystali świeżo ujawnioną lukę w rdzeniu, utworzyli konta administratora i wchodzili do panelu bez logowania hasłem – przez sfałszowane ciasteczka sesji. Kilka dni później jedna z grup podłożyła skimmer. Nie w plikach: w polu ustawień wtyczki do wstawiania skryptów, zapisanym w bazie danych. Dlatego skaner plików go nie widział.

Dalsze kroki:

  • porównałem wszystkie pliki rdzenia WordPressa z oficjalną wersją i sprawdziłem serwer pod kątem obcych plików – żadnych webshelli, alarmy skanera okazały się fałszywe,
  • usunąłem konta napastników, wyczyściłem pole ze skimmerem i wymieniłem wszystkie klucze i hasła dostępowe – do panelu, bazy danych i sesji logowania – przez co przejęte dane logowania przestały działać, a każdy zalogowany został wylogowany,
  • ustaliłem, dlaczego sklep nie wykonał aktualizacji: dwa mechanizmy automatycznych aktualizacji wzajemnie się blokowały – naprawiłem to i sprawdziłem, czy aktualizacje bezpieczeństwa znowu działają,
  • dodałem na zaporze regułę blokującą punkt API użyty w ataku i zaktualizowałem wtyczki ze znanymi lukami,
  • z logów wyznaczyłem rzeczywiste okno działania skimmera i liczbę zamówień, które przez nie przeszły, oraz oceniłem, czy są ślady pobrania bazy klientów.

03 · Efekty

Efekty

Sklep wrócił do sprzedaży z czystym kodem, działającymi aktualizacjami i zablokowanym wektorem ataku. Prawnik klienta dostał materiał z konkretnym oknem czasowym i listą zamówień objętych ryzykiem, zamiast domysłów – co ograniczyło zakres zawiadomienia do klientów, których problem faktycznie dotyczył. Sposób pracy przy takich zgłoszeniach opisuję na stronie usuwania wirusów z WordPressa.

Odpowiadam w 24 godziny

Bezpłatna wycena

Napisz, co ma powstać albo co wymaga naprawy. Odpowiada ta sama osoba, która potem wykonuje pracę.