Włamanie na stronę i podmiana plików.

W dniu 18.11.2020 ta strona WWW zarządzana w CMS WordPress na skutek swej ukrytej działalności spowodowała zainteresowanie ze strony crawler’ów (botów przeszukujących) Google i w rezultacie wygenerowanie ostrzeżenia o ryzykownych działaniach:

Google Search Console Team napisał(a): Message type: [WNC-633200]  Search Console
W witrynie https://www.us.edu.pl/ wykryto treści zmodyfikowane przez hakerów
Do webmastera witryny https://www.us.edu.pl/
Wykryliśmy, że Twoja witryna została zaatakowana przez kogoś z zewnątrz, kto utworzył złośliwe treści na niektórych jej stronach. Jest to poważny problem, ponieważ ktoś wykorzystał reputację Twojej witryny po to, by udostępnić użytkownikom nieoczekiwane lub szkodliwe treści w Twojej witrynie lub pokazać je w wynikach wyszukiwania. Obniża to też jakość wyników, jakie użytkownicy widzą w wyszukiwarce Google. W związku z tym będziemy ostrzegać użytkowników, którzy znajdą Twoją witrynę w wynikach wyszukiwania, że zawiera ona treści zmienione przez hakerów. Aby usunąć to ostrzeżenie, wyczyść treści zmodyfikowane przez hakerów i prześlij prośbę o ponowne rozpatrzenie zgłoszenia. Gdy uznamy, że Twoja witryna nie zawiera już treści zmienionych przez hakerów, usuniemy to ostrzeżenie.
Poniżej znajdziesz przykłady adresów URL do stron, które zostały zaatakowane. Sprawdź je, by dowiedzieć się, gdzie konkretnie znajdują się treści zmodyfikowane przez hakerów. Ta lista nie jest wyczerpująca.
https://www.utracki.us.edu.pl/vivaohayo/456vtqer999250.htm
Aby rozwiązać ten problem:
1 Sprawdź problemy dotyczące bezpieczeństwa, by poznać szczegóły ataku hakerskiego
Przykłady dostępne w raporcie Problemy dotyczące bezpieczeństwa w Search Console pozwolą uzyskać wstępne informacje o stronach zmodyfikowanych przez hakerów.
Problemy dotyczące bezpieczeństwa

2 Sprawdź, czy inne strony lub pliki w Twojej witrynie nie zostały zaatakowane
Sprawdź całą witrynę (w tym stronę główną) pod kątem nieznanych treści zamieszczonych przez kogoś innego. Złośliwy kod może znajdować się w plikach HTML, JavaScript lub w innych plikach w witrynie. Może być on też ukryty w miejscach, które łatwo przeoczyć, takich jak pliki konfiguracji serwera (np. plik .htaccess) czy inne strony z dynamicznym skryptem (np. PHP lub JSP). Wszystko należy sprawdzić bardzo dokładnie.

3 Użyj narzędzia do sprawdzania adresów URL, by wyodrębnić złośliwe treści
Użytkownicy i roboty Google mogą różnie widzieć Twoje strony, dlatego możesz użyć narzędzia do sprawdzania adresów URL, by rozpoznać niektóre rodzaje ataków hakerskich. Wpisz w narzędziu adresy URL Twojej witryny, by sprawdzić, jak widzi je Google. Jeśli strona zawiera ukryte treści zmodyfikowane przez hakerów, to narzędzie może je ujawnić.
Narzędzie do sprawdzania adresów URL

4 Usuń wszystkie złośliwe treści
Możesz też poprosić o pomoc dostawcę usług hostingowych. Jeśli masz trudności z rozpoznaniem lub usunięciem problematycznych treści, możesz przywrócić starszą wersję witryny z kopii zapasowej.

5 Zabezpiecz witrynę przed kolejnymi atakami
Wyszukaj i usuń luki w zabezpieczeniach witryny, które umożliwiły jej zaatakowanie. Zmień hasła do kont administratorów. W razie wątpliwości poproś o pomoc swojego dostawcę usług hostingowych.

6 Prześlij prośbę o ponowne rozpatrzenie zgłoszenia
Po wprowadzeniu poprawek w witrynie prześlij prośbę o ponowne rozpatrzenie zgłoszenia i usunięcie ostrzeżenia. Dołącz wszystkie szczegółowe informacje i dokumenty, które pomogą nam ustalić, jakie zmiany zostały wprowadzone w witrynie.
Prośba o ponowne rozpatrzenie zgłoszenia
Potrzebujesz dodatkowej pomocy?
•Przeczytaj nasz poradnik Pomoc dla webmasterów witryn zaatakowanych przez hakerów.
•Więcej informacji o prośbach o ponowne rozpatrzenie zgłoszenia znajdziesz w naszym Centrum pomocy.
•Jeśli masz pytania, możesz je zadać na naszym forum. Pamiętaj, by oznaczyć wiadomość jako [WNC-633200].

Google LLC, 1600 Amphitheatre Parkway Mountain View, CA 94043 | Wysłaliśmy Ci tego e-maila związanego z obsługą, ponieważ Twoja witryna wyświetla się w Google Search Console | Anuluj subskrypcję tego typu wiadomości
Dodaj partnerów, którzy powinni otrzymywać wiadomości na temat tego konta Search Console

Tego dnia, o godzinie 13:22 zostałem o tym powiadomiony via mail, a o 13:34 strona została zablokowana dla zapobieżenia ew. nadużyciom. O godzinie 14.16 przystąpiłem do działań analizy problemu i identyfikacji zagrożenia. W wyniku rozmowy z DASiUS oraz pobieżnej analizy logów potwierdziło się, że w CMS zostały dokonane zmiany, które przeprogramowały jego zachowanie tworząc źródło treści w języku chińskim, pozornie wyglądające jak agregatory linków SEO. Możliwe, że miało to na celu jedynie wypromowanie w wyszukiwarkach wyselekcjonowanych stron chińskich, jednakże z uwagi na niepewny charakter i bezdyskusyjnie bezprawne działania należało się tym zająć. Pomijając fakt blokady strony, sama witryna wydawała się działać poprawnie.

Po przystąpieniu do analizy struktury plików uwagę zwróciły dwie formy nietypowego podejścia do tworzenia oprogramowania. Jeden z nich polegał na fakcie wygenerowania wielu katalogów o losowo utworzonych nazwach, co czyniły je nietypowym w miejscu w którym się znajdowały. Drugi z nich, bardziej zaawansowany, polegał na pojawieniu się plików o zaszyfrowanej zawartości, gdzie część była kodem php, a część z pozoru blokiem danych. Sam ten fakt wskazywał na chęć ukrycia kodu i w systemie takim jak WordPress był wysoce nietypowym. Wszystkie takie modyfikacje dotyczyły kilku katalogów:

• wp-content/plugins – katalogi o losowo wygenerowanych nazwach i ciekawy pod względem struktury plik [webindex.php],
• katalog główny systemu plików – podmienione standardowe pliki WordPress’a na inne z zaawansowaną strukturą wewnętrzną kodu.

Powodowały one między innymi pojawienie się treści dostępnych pod rozwinięciem adresów takich jak:

/z-craft/16367ybbl12625710.htm
/rodeo-drive/36624uokz1348588.htm
/a-life2010/11408lpsgt3ab-1565094.htm
/first23/12332cyfwtrusco-1146243.htm
/candleandsoap/8772mgbr761581-1603435csh.htm
/webike-rb/11847bhjl22628031.htm

itp…

oraz umożliwiały nieautoryzowany dostęp do systemu CMS.

Ponadto okazało się, że do systemu CMS WordPressa zostały dodane następujące osoby jako administratorzy (tylko ostatni jest prawidłowy, legalny i poprawny!):

Proces naprawczy polegał na:

• usunięciu podmienionych plików CMS i zastąpieniu go nowymi (katalogi wp-admin i wp-content w całości)¹w całości z czystej instalacji WordPress’a (tej samej wersji!!!),
• zastąpieniu plików w katalogu głównym WWW z pominięciem pliku wp-config.php (po analizie jego zawartości i sprawdzeniu czy nadal ma poziom uprawnień 660!!!)²w całości z “czystej” instalacji WordPress’a (tej samej wersji!!!),
• usunięciu z katalogu wp-content/plugins wszystkich katalogów podejrzanych (losowe nazwy niezwiązane z nazwami wtyczek),
• usunięciu z katalogu wp-content/plugins wszystkich podejrzanych plików ³nie istniejących w “czystej” instalacji,
• usunięciu nieautoryzowanych użytkowników w WordPress’a,
• zmiana hasła dostępowego do WordPress’a,
• zmiana hasła do bazy danych WordPress’a,
• aktualizacja używanych wtyczek do najnowszych wersji,
• zmiana hasła do ftp,
• zmiana hasła do systemu hostingu.

Wszystkie te zmiany spowodowały, że nie są już dostępne generowane katalogi. Tym niemniej zarzucenie tematu analizy źródła włamania spowodować może, że ów włam się powtórzy w najbliższym czasie, lub u innych użytkowników. Dlatego też samo przywrócenie strony “do życia” jest niewystarczające, należy spróbować przeanalizować dostępne logi, aby określić drogę wejścia do systemu.

Oczyszczenie strony nastąpiło 18.11.2020 o godzinie 15:32. Od tego momentu strona jest obserwowana w zastrzeżonym środowisku co do niepokojących zachowań. Skanowane i rejestrowane są także wszelkie próby kontaktu z nią. Pełne uruchomienie strony (zdjęcie zabezpieczeń izolujących stronę od dostępu z sieci Internet) miało miejsce w dniu 19.11.2020 w okolicach godziny 9.00.

Przy kolejnej iteracji weryfikacji strony 19.11.2020 okazało się, że plik index.php uległ modyfikacji, pojawił się też wcześniej usunięty plik robots.txt dla crawler’ów SE. Przy głębszej analizie struktury katalogów znaleziono trzy lokalizacje zawierające niezidentyfikowane skrypty o podejrzanej zawartości:

• /wp-admin i /wp-includes – znajdował się podkatalog ALFA-DATA ze szkodliwymi plikami,
• /cgi-bin – znajdował się w nim katalog test, a w nim katalog ALFA-DATA i szkodliwe pliki, w tym plik z treścią rozpoznawaną przez heurystyczny skaner jako wirus PHP/WebShell.NES!tr⁴PHP/WebShell.NES!tr jest identyfikowany jako trojan. Trojan jest rodzajem malware wykonującym działania w zainfekowanym systemie bez wiedzy użytkownika. Te aktywności sprowadzają się do nawiązywania zdalnych połączeń, przechwytywania aktywności klawiatury (np. podczas wpisywania haseł), zbierania informacji o systemie, pobierania i wysyłania plików, wprowadzania innych zainfekowanych składników do systemu (czyli jest BackDoor’em tworzącym dla hakera tzw. “tylne wejście” do systemu, co powoduje, że sama zmiana haseł dostępowych jest bezsensowna i nieskuteczna bez znalezienia i eliminacji takich “tylnych wejść”), tworzenia ataków typu Denial-of-Service (DoS) oraz uruchamiania lub zatrzymywania procesów..
• /wp-content/maintenance/assets/index.php – spreparowany plik także zawierający trojana PHP/WebShell.NES!tr.

Daty ich stworzenia wskazują na infekcję dokładnie miesiąc wcześniej tj. 18.10.2020r. Niestety zbiega się to z datą odtworzenia systemu CMS po błędzie podczas aktualizacji do najnowszej wersji systemowej. Jest to przeszkoda w określeniu dokładnej daty infekcji. Również w okresie ok. 18.09.2020 system zachowywał się bardzo niestabilnie, a przyczyna nie została zdiagnozowana, usterka ustąpiła samoczynnie bądź na skutek działań DASiUS (jakich?!) o których nie zostałem zwrotnie poinformowany po zgłoszeniu niestabilności witryny. Podejrzenie pada na błąd we wtyczce WordPressa.

Kolejne czynności naprawcze polegały na:

• usunięciu plików z /cgi-bin, /wp-admin/maint,
• usunięciu pliku index.php z /wp-content/maintenance/assets/
• przywrócenie z “czystej” instalacji pliku repair.php do katalogu /wp-admin/maint (z rozpędu dla pewności, już po usunięciu okazało się, że… nie był zmodyfikowany).
• zweryfikowanie z “czystą” instalacją plików w katalogu /wp-content/maintenance/

Możliwymi słabymi punktami są w niniejszym przypadku (w kolejności ustalonego, wg mojej wiedzy, prawdopodobieństwa):

• błędy w aktywnych wtyczkach, umożliwiające dostanie się do zarządzania stroną lub chociaż do struktury plików z prawem zapisu w katalogach,
• błędy w kodzie CMS (wersja dla bezpieczeństwa nie jest tutaj podawana), pozwalające na tę samą działalność co wymieniona powyżej,
• złamanie któregoś z haseł dostępowych.

Reasumując, można zauważyć, że:

• Przede wszystkim należy mieć na podorędziu kopie bezpieczeństwa strony. Nie jedną, ostatnią, ale wykonywane sekwencyjnie nawet do kilku miesięcy wstecz. Stawia to w trudności wyselekcjonowanie z takich kopii treści, które w międzyczasie uległy zmianie w ramach normalnego zarządzania witryną i jej ewolucji, ale pozwala cofnąć się do miejsca w którym kopia będzie “czysta”. Na szczęście w obecnym casusie nie nastąpiły żadne wyraźnie działania niszczące.
• Po drugie, należy mieć “w zasięgu” czystą instalację CMS w wersji zgodnej z używaną, aby móc jej użyć do porównania struktury plików, wyłapania anomalii i co najważniejsze jako “dawcę” poprawnych, nie przerobionych plików.
• Po trzecie, ale w normalnym, codziennym zarządzaniu CMS rzecz kluczowa – w miarę możliwości należy aktualizować struktury CMS zgodnie z pojawiającymi się poprawkami samego CMS, wtyczek (plug-in), czy motywu.
• Po czwarte należy właściwie skonfigurować WordPress’a – często zapominanym elementem jest zmiana praw dostępu do pliku wp-config.php, który powinien mieć uprawnienia 660 (rw- rw- —). Klasycznym zaś błędem z którym spotykam się co jakiś czas jest ustawianie praw do wszystkich katalogów na poziomie uprawnień 777 – “bo wtedy wszystko działa” jak mogę usłyszeć od “administratora” takiego systemu.
• Po piąte – zmieniać co jakiś czas hasła, używać haseł skomplikowanych, nie dających się złamać popularnymi metodami, czy atakiem brute-force.
• Po szóste – nie używać CMS WordPress… niestety używanie darmowych systemów popularnych wiąże się ze znacznie zwiększonym ryzykiem. Można się natknąć na spreparowane wtyczki, czy też “społeczność” hakerów pracuje nad wyszukiwaniem błędów w strukturach celem uzyskania dostępu administracyjnego. Znacznie pewniejszym sposobem jest użycie dobrego systemu niepowszechnego np. dedykowanego systemu CMS. W tym, niniejszym, konkretnym przypadku także jest to istotne, ale wizerunkowo nieuzasadnione, z powodów prowadzenia dydaktyki z tworzenia i administracji witryn opartych na popularnych CMS’ach.
• Po siódme – włamanie zawsze jest możliwe, że nastąpi. Zdarza się to największym graczom na rynku. Trzeba być przygotowanym jednak do reakcji i do przeciwdziałania temu. Trzeba też dalej prowadzić witrynę i zajmować się swoimi zadaniami.

Informacje powyższe opisałem dla innych użytkowników WordPress’a na wypadek sytuacji, kiedy to oni staną przed podobnym wyzwaniem. Może wtedy opisane wyżej procedury pomogą przywrócić ich witrynę do stanu świetności. Oby nigdy nie był ten wpis nikomu potrzebny.