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.