procedura usuwania wirusów ze strony opartej o system CMS WordPress [Update]

Oczywiście scenariusz wykonywania naprawy może być inny. Przedstawiamy naszą propozycję na oczyszczenie instalacji WP z infekcji przy pomocy komend Linuksa. Na upartego wystarczy nam do tego sama konsola Linux. Np. przy pomocy serwera VPS.

Procedura została opracowana przy współpracy z zespołem strony profesjonalnie zajmującej się takimi naprawami: https://stronabezwirusa.com/

1. Porównanie wersji z kopii bezpieczeństwa z aktualną wersją plików

Jeśli dysponujemy kopią bezpieczeństwa najlepiej jest dodać ją do repozytorium SVN celem prześledzenia zmian w plikach.

a) Tworzymy repozytorium SVN oraz kopię roboczą:


(gdzie user – nazwa Twojego użytkownika)

b) Wgrywamy następnie do folderu


Pliki z kopii bezpieczeństwa.

Duże pliki binarne (mp3, mp4, jpg, png, zip, tar) nie są potrzebne do synchronizacji. Najlepiej je usunąć aby przyśpieszyć sobie pracę.

Znajdujemy takie pliki (o wielkości powyżej 500kb)


i je usuwamy:


Czytaj jak kopiować i wklejać tekst w konsoli Linux.

Jeśli plik jest to niezbędny plik .js albo .php – zostawiamy go.

Dodajemy wszystkie pliki do kontroli wersji i komitujemy:

c) Pobieramy pliki z zainfekowanej strony do osobnego folderu (tutaj utworzony poniżej folder: wordpress-infekcja), który uprzednio tworzymy:

d) Gdy już pliki zostaną pobrane dokonujemy synchronizacji:


Nastepnie przeglądamy listę zmian w plikach:


Listę dostępnych statusów odnośnie zmienionych plików znaleźć można tutaj : https://linuxporady.pl/lista-statusow-svn-subversion-eng/

Wykonane zmiany w plikach możemy sprawdzić poprzez komendę:


Jednak bardziej pomocne mogą okazać się programy typu Eclipse lub Netbeans z odp. wtyczkami SVN.

Następnie:

Usuwamy złośliwe pliki:


Leczymy złośliwie zmienione pliki


Przywracamy niezbędne dla działania systemu pliki usunięte (symbol “!” po komendzie svn st) przez hakera:


Po skrupulatnym wykonaniu powyższych czynności nowo powstałe pliki dodajemy do repozytorium:


Usunięte – wykluczamy z repozytorium:


Całość zmian komitujemy:

2. Znalezienie rozmaitych podejrzanych wystąpień w plikach

Każde takie odkrycie badamy z osobna pod kątem czy jest to istotnie zawartość skryptu WP albo modułu, czy fragment złośliwego kodu.

Automatycznie znaleziska są składowane w pliku “zmiany”, który za każdą komendą jest nadpisywany.

a) znalezienie plików które nie mają rozszerzenia PHP a mają znacznik php:

b) wystąpienia wieloelementowej tablicy _Global:

c) znalezienie wystąpień tłumionego include. Używamy kilku wariantów wyszukiwania:

d) znalezienie wystąpień hexowego wpisywania znaków w PHP:


tu zamiast 109 możemy użyć innych cyfr

e) znalezienie podejrzanych operacji na zmiennej tablicowej _FILE i funkcji haszującej:

f) komendy wyodrębniające podejrzane pod kątem exploitów pliki PHP:



g) znalezienie wystąpień includowanego kodu który jest zazwyczaj widoczny w ukrytych (zaczynających się od kropki) plikach PHP udających ikony (rozszerzenie .ico)

h) znalezienie podejrzanych skrytów o 8-literowej nazwie plików

W niektórych infekcjach – haker umieszcza na serwerze w losowych miejscach pliki o losowej nazwie (to istotne – nazwy są generowane automatycznie i nie mają sensu – to po prostu 8-literowy ciąg znaków). Zazwyczaj są one 8-literowe. Najlepiej wylistować wszystkie takie pliki i znaleźć takie podejrzane wystąpienia:


Dla przykładu plik o nazwie typu:


może wymagać wglądu – czy rzeczywiście jest częścią webserwisu. Jeśli nie i posiada podejrzany kod. Należy go skasować.

Oczywiście 8-literowy ciąg to nie standard. Jeśli pojawia się dużo plików np. 6-literowych należy odp. zmienić kryteria wyszukiwania.

 

 

Oczywiście ta lista możliwych podejrzanych zmian w plikach nie jest wyczerpująca.

Wszystkie ew. zmiany w plikach musimy zakomitować, aby mieć pewność że dysponujemy aktualną i oczyszczoną kopią roboczą:

3. Aktualizacja i weryfikacja modułów

Należy zaktualizować możliwe najwięcej komponentów w WP. Zatem:

  • jądro WordPress
  • motywy
  • wtyczki

Musimy się także zastanowić czy wszystkie zainstalowane wtyczki są niezbędne do funkcjonowania strony. Niepotrzebne lub podejrzane komponenty należy usunąć.

Po dokonaniu aktualizacji należy uwzględnić zmiany w kopii bezpieczeństwa w SVN. Powtarzamy tutaj proces z pkt. 1 tego artykułu.

4. Ustawienie prawidłowych uprawnień na plikach i folderach.

Następnie całość plików powinna być wgrana przez FTP na serwer docelowy uprzednio po usunięciu zawartości:

5. Zmiana haseł powiązanych ze stroną

a) Zmiana wszystkich dostępów FTP (skomplikowane hasło).

Najlepiej jest usunąć wszystkie konta FTP zostawiając tylko jedno, które ma trudne i unikalne hasło.

b) Zmiana wszystkich dostępów CMS.

W dziale użytkownicy w WP należy dokonać przeglądu którzy administratorzy są potrzebni, a którzy nie.

c) Zmiana hasła do bazy danych (skomplikowane, unikalne hasło)

Następnie należy je wprowadzić w pliku


w katalogu głównym

6. Asekuracyjnie. Porównajmy naszą zaktualizowaną wersję strony opartej o WordPress z bazową wersją tego CMS.

Analogicznie jak w pkt. 1:

Upewniamy się, że mamy aktualną wersję kopii roboczej opartej o kopię bezpieczeństwa z SVN:


Do osobnego folderu wgrywamy aktualną wersję CMS WordPress ze strony: https://pl.wordpress.org/

Tworzymy go w folderze pliki-stron:


Następnie synchronizujemy pliki z naszą kopią bezpieczeństwa sprawdzamy zmiany:


Większość wtyczek, motywów itp. będzie usunięta (symbol wykrzyknika). Zapewne nie zawierają się one w podstawowej wersji CMS. Najbardziej kluczowe mogą być podejrzane zmiany w plikach jądra CMS, albo usunięcie plików, które mają łudząco podobną nazwę do składowych plików CMS. Należy przeglądnąć ich zawartość.

7. Dodatkowe zabezpieczenia

Blokowanie wywołań plików php i ukrytych plików php.

W folderze:


Umieść plik o nazwie:


I zawartości:


Dodatkowo, zgodnie z informacjami zawartymi na stronie: https://perishablepress.com/protect-post-requests/ możemy zupełnie uniemożliwić requesty POST. Czyli jeśli nasza strona nie posiada formularza kontaktowego itp. możemy dodać taką regułę do .htaccess. Jednak uwaga – może to uniemożliwić logowanie do CMS. W takim wypadku na czas logowania należy ją zakomentować:


Widok zakomentowanej reguły:

8. Sprawdzenie podejrzanych użytkowników bazie danych.

Niekiedy hakerzy przejmują kontrolę nad systemem CMS i za jego pośrednictwem dokonują swoich działań.

Aby się upewnić, że w CMS nie ma takiego backdoora zaloguj się do bazy danych przez program PhpMyAdmin. Dane do zalogowania znajdziesz w pliku:


następnie zaznacz tabelę:


Jeśli w jej obrębie znajdują się podejrzane konta użytkowników

a) Usuń je – notując ich numery ID

b) Wywołaj komendę:


Gdzie 2 – to zanotowany numer ID.

c) zmień hasło do bazy danych i zaktualizuj je w pliku php:

9. Sprawdzenie sytuacji po paru dniach

Należy następnie sprawdzić sytuację na witrynie po paru dniach / tygodniach. Najlepiej dla szybkości pobrać jedynie pliki narażone na atak. Następnie prześledzić ich zmiany przez SVN na identycznej zasadzie jak w pkt. 1 albo 6 niniejszego artykułu:


Ewentualnie jak bazujemy na hostingu opartym o Direct Admin dodajmy takie komenty do crona: