cross-site contamination

Cross-site contamination (zakażenie krzyżowe) to przeniesienie infekcji z jednej witryny na inne strony w tym samym koncie hostingowym albo na tym samym serwerze. Sucuri definiuje je jako sytuację, w której strona zostaje zainfekowana przez sąsiednie witryny w tym samym środowisku z powodu słabej izolacji na serwerze albo w konfiguracji konta ^[2]. Skutek praktyczny jest prosty: wyczyszczenie jednej strony nie kończy problemu, bo infekcja wraca z sąsiedniej. Sucuri wskazuje zakażenie krzyżowe jako jeden z czynników ciągłych reinfekcji wielu aktualnych i utwardzonych stron ^[1].

Jak działa

Zakażenie krzyżowe jest odmianą zjawiska lateral movement, czyli przemieszczania się napastnika po środowisku. W kontekście stron internetowych oznacza to według Sucuri zdobycie dostępu do jednej witryny i użycie jej jako przyczółka do infekowania innych stron w tym samym środowisku ^[2].

Warunkiem jest wspólny zapis. Strony w jednym koncie cPanel należą domyślnie do tego samego właściciela i grupy co strona główna w katalogu public_html, a proces PHP działa jako ten sam użytkownik ^[2]. Pliki jednej strony mogą więc czytać i zapisywać pliki drugiej ^[2]. W zwykłej pracy to nie przeszkadza, ale gdy na koncie pojawi się złośliwe oprogramowanie (malware), rozchodzi się ono po wszystkich stronach.

Przebieg infekcji między dwiema stronami na jednym koncie pokazuje schemat poniżej.

RYS. 1Zakażenie krzyżowe na jednym koncie

Odmiany

Sucuri zwraca uwagę na VPS, na którym administrator, żeby pozbyć się błędów „permission denied” przy aktualizacjach, przekazuje wszystkie pliki użytkownikowi serwera WWW ^[2]. Jeśli w katalogu jest kilka stron, każda może wtedy zapisywać pliki pozostałych ^[2].

W WordPressie

Dokumentacja WordPressa ostrzega wprost: jeśli strona jest na hostingu współdzielonym i inna witryna na tym samym serwerze zostanie przejęta, twoja strona także może zostać przejęta ^[3]. Zaleca też, by kilka blogów na jednym serwerze trzymać w osobnych bazach danych, zarządzanych przez różnych użytkowników ^[3].

Kluczowy jest plik wp-config.php, który zawiera dane logowania do bazy. Sucuri w 2016 roku opisał atak, w którym napastnik, mając już jedną przejętą stronę na serwerze, wyszukiwał inne witryny WordPress pod tym samym adresem IP ^[1]. Na każdej próbował przez lukę pobierania dowolnych plików odczytać wp-config.php, a potem łączył się z bazą danych z przejętej strony ^[1]. Ponieważ połączenie szło z tego samego serwera, nie blokowała go reguła dopuszczająca tylko lokalne połączenia ^[1]. Uprawnienia 400 na pliku też nie pomagały, bo odczytu dokonywał proces serwera WWW, który musi ten plik czytać ^[1]. Mechanizm odczytu opisuje hasło path traversal, a ochronę pliku utwardzanie pliku wp-config.php.

Na zakażenie krzyżowe szczególnie narażone są strony „zapomniane”. Sucuri zauważa, że poza jedną lub dwiema głównymi stronami administratorzy często mają kilka innych, które nie dostają aktualizacji wtyczek i motywów na czas ^[2]. Taka porzucona wtyczka na pobocznej stronie staje się wejściem do całego konta.

Zagrożenia i skutki

• Reinfekcja. Czyszczenie jednej strony nie pomaga, dopóki zainfekowana jest sąsiednia ^[1].
• Nowi administratorzy i podmiana treści. Z danymi bazy napastnik może utworzyć nieautoryzowane konto administratora na każdej podatnej stronie albo zmienić jej tytuł, czyli dokonać podmiany treści strony ^[1].
• Zarażanie odwiedzających. Złośliwe oprogramowanie SocGholish z fałszywymi aktualizacjami przeglądarki wstrzykuje się do każdego pliku JavaScript, do którego ma prawo zapisu ^[2]. Ofiary fałszywych aktualizacji mogą później stać się celem ransomware ^[2]; zob. też drive-by download.
• Blokady. Jedna przejęta strona albo jedna pominięta aktualizacja może sprawić, że cała grupa stron zacznie rozsyłać złośliwy kod i trafi na listy blokowanych w wyszukiwarkach i programach antywirusowych ^[2]; zob. wpis na czarną listę (blacklisting).

Jak się bronić

Podstawą jest izolacja, zgodna z zasadą najmniejszych uprawnień. Sucuri zaleca osobne konto cPanel dla każdej strony, a na VPS rozdzielenie stron przez PHP-FPM ^[2]:

1. Każda strona we własnym katalogu domowym ^[2].
2. Pliki i katalogi strony należą do jej własnego użytkownika ^[2].
3. Proces PHP strony działa jako ten sam użytkownik ^[2].

Przy kilku kontach cPanel Sucuri zaleca też włączenie ochrony przed dowiązaniami symbolicznymi w ustawieniach Apache i użycie dyrektywy open_basedir ^[2]. Dokumentacja PHP wyjaśnia, że open_basedir ogranicza pliki dostępne dla PHP do wskazanego drzewa katalogów, a dowiązania symboliczne są rozwiązywane, więc nie da się jej nimi obejść ^[4]. Ta sama dokumentacja ostrzega, że to tylko dodatkowa siatka bezpieczeństwa, która nie jest kompletna i nie może być jedyną ochroną ^[4].

Pozostałe środki:

• Osobna baza danych i osobny użytkownik bazy dla każdej strony ^[3].
• Pliki strony należą do konta właściciela, a zapis dla serwera WWW tylko tam, gdzie WordPress go potrzebuje ^[3]; zob. uprawnienia plików.
• Pełne łatanie wszystkich stron na koncie, także pobocznych ^[1], a do czasu łatki wirtualne patchowanie (virtual patching) w zaporze WAF ^[1].
• Regularna kopia zapasowa (backup) całej instalacji i bazy danych w zaufanym miejscu ^[3].

Przy infekcji trzeba czyścić wszystkie strony na koncie naraz i zmienić wszystkie hasła, także do baz danych; opisuje to hasło czyszczenie przejętej strony.

Historia i przykłady

We wrześniu 2016 roku Sucuri opisał masowe przejmowanie stron WordPress na serwerach współdzielonych przez odczyt wp-config.php sąsiednich witryn ^[1]. Jako najgłośniejszy przykład luki pobierania plików wskazał starą wersję wtyczki RevSlider, która od ujawnienia w 2014 roku doprowadziła do przejęcia setek tysięcy stron ^[1]. W styczniu 2024 roku Sucuri wskazał kampanię Balada Injector, której kod szuka innych stron do zainfekowania jak najwyżej w strukturze katalogów ^[2].