Zmiana hasła administratora przez bota, złośliwy kod w sklepie i błędy logowania mogą być objawami tego samego problemu: ktoś uzyskał dostęp do aplikacji. Przywrócenie działania serwisu to pierwszy etap. Drugi to ograniczenie możliwości kolejnego ataku. Dwa przypadki z naszej praktyki pokazują, dlaczego warto doprowadzić oba etapy do końca.
Przypadek pierwszy: bot zmienił hasło administratora WordPressa
Administrator serwisu o wydarzeniach zauważył, że bot zmienił hasło jego konta. Odzyskał dostęp, ustawił nowe hasło i zakończył podejrzaną sesję. Sprawdził też pozostałych użytkowników i dane kont. To były właściwe działania doraźne, ale nadal trzeba było ustalić, jak napastnik dostał się do środka.
Przeanalizowaliśmy logi, aktywność kont i stan aplikacji. Ustalenia wskazały na automatyczny atak wykorzystujący podatność używanej wcześniej wersji WordPressa. Zmiana hasła sama w sobie nie usuwała jego przyczyny.
Kontrola objęła pliki systemu, wtyczki, konta, uprawnienia i aktywne sesje. Nie znaleźliśmy nowych kont administratorów, backdoora ani zmian plików powiązanych z analizowanym incydentem. To wynik przeprowadzonych kontroli, a nie obietnica, że pojedynczy skan odpowie na każde pytanie dotyczące włamania.
Zweryfikowaliśmy zaktualizowany system, wymieniliśmy klucze uwierzytelniające i unieważniliśmy sesje administratorów. Mechanizm wykorzystany w ataku zablokowaliśmy dodatkowo na poziomie serwera dla siedmiu domen tego samego konta hostingowego. Po zmianach sprawdziliśmy stronę, logowanie i API. Serwis działał prawidłowo.
W tym przypadku reakcja objęła zarówno skutki incydentu, jak i drogę wykorzystaną do ataku. Dalsze zalecenia dotyczyły logowania dwuskładnikowego, haseł używanych również w innych usługach oraz monitorowania logów.
Przypadek drugi: infekcja sklepu PrestaShop
W sklepie działającym na PrestaShop 1.6 znaleźliśmy złośliwy kod w kilku miejscach aplikacji. Część plików udawała obrazy lub arkusz stylów, choć zawierała kod służący infekcji. Zmiany obejmowały też biblioteki szablonów, kontrolery i mechanizm logowania administratorów.
Dlatego usunięcie jednego podejrzanego pliku nie kończyło naprawy. Trzeba było sprawdzić kod aplikacji, moduły i pamięć podręczną. Zainfekowane pliki przenieśliśmy do kwarantanny, a potwierdzone zastrzyki w plikach objętych kontrolą wersji usunęliśmy przez przywrócenie sprawdzonych wersji. Zachowaliśmy przy tym modyfikacje sklepu, które nie nosiły śladów infekcji.
Wyczyszczenie pamięci podręcznej szablonów było częścią naprawy: zapisane wcześniej skompilowane pliki mogły nadal wywoływać błędy po poprawieniu kodu źródłowego. Po czyszczeniu sprawdziliśmy składnię kluczowych plików, odpowiedź sklepu i obecność rozpoznanych markerów infekcji. Sklep ponownie odpowiadał prawidłowo, a sprawdzane markery nie występowały.
Znaleźliśmy również kod służący do przechwytywania danych logowania administratorów. Z tego powodu zaleciliśmy zmianę haseł oraz dalsze zabezpieczenie środowiska. Przywrócenie plików nie zastępuje uporządkowania dostępu do sklepu.
Po wcześniejszym czyszczeniu nie uzyskaliśmy zgody na wdrożenie zalecanych zabezpieczeń. Problem później powrócił i sklep wymagał kolejnej interwencji. Ten przypadek pokazuje praktyczny skutek pozostawienia etapu zabezpieczenia poza zakresem naprawy. Nie oznacza to, że ustaliliśmy identyczną drogę wejścia przy każdym incydencie, oznacza, że samo oczyszczenie nie zapewniło trwałego rozwiązania problemu.
Co powinna obejmować naprawa po włamaniu?
Najpierw trzeba zachować materiał potrzebny do analizy i ustalić zakres incydentu. Następnie usunąć potwierdzony złośliwy kod, przywrócić sprawdzone pliki oraz zweryfikować działanie aplikacji. Równolegle należy ocenić dostęp administratorów, aktywne sesje i sekrety, które mogły zostać ujawnione.
Plan dalszych prac powinien odpowiadać stanowi konkretnej strony: może obejmować aktualizację systemu i modułów, ograniczenie dostępu, dodatkowe reguły serwera albo migrację starszej aplikacji. Ważne, żeby właściciel wiedział, co zostało już wykonane, a co pozostaje zaleceniem. Działająca strona i zakończony proces zabezpieczenia to dwa odrębne wyniki prac.
Potrzebujesz pomocy ze stroną lub sklepem?
Jeśli zauważasz nieznane konta, podejrzane przekierowania, zmiany haseł lub błędy po infekcji, skontaktuj się z Projectic. Przeanalizujemy problem, zaproponujemy zakres naprawy i pomożemy zaplanować zabezpieczenia po przywróceniu działania. Możemy też omówić stałą opiekę techniczną nad Twoją stroną lub sklepem.