Ataki na serwisy internetowe z użyciem plików konfiguracyjnych i wykonywalnych serwera Apache

06 maja 2013, 15:23 | Aktualności | komentarze 3
Tagi: ,
: zin o bezpieczeństwie - pobierz w pdf/epub/mobi.

Wstęp

Jak wynika z badań amerykańskiej firmy Sucuri zajmującej się monitorowaniem bezpieczeństwa serwisów internetowych, w ostatnim czasie zauważalnie wzrasta liczba ataków na strony www przez zainfekowane moduły serwera Apache oraz zmodyfikowane pliki konfiguracyjne. Są to dość wyrafinowane metody, z reguły trudne do wykrycia i dające spore możliwości atakującemu. Jak w praktyce wyglądają takie ataki?

Postaram się zaprezentować to w dalszej części artykułu.

 

Nowe wektory ataków

Od wielu lat głównym nośnikiem niebezpiecznego kodu w postaci malware były zainfekowane strony www. Złośliwy kod osadzano w treści strony z reguły na skutek udanego wykorzystania luk w rodzaju Stored XSS czy SQL Injection.

Jednak w ostatnim czasie pojawiły się dwa nowe źródła infekcji:

  • pliki konfiguracyjne serwera Apache oraz
  • jego binaria (w postaci ładowanych dynamicznie modułów).

W celu dokonania takiego ataku z reguły konieczne staje się wcześniejsze uzyskanie przez agresora dostępu do serwera na prawach użytkownika root (w prawidłowo skonfigurowanym systemie nikt poza rootem nie powinien mieć możliwości zmiany zawartości plików konfiguracyjnych serwera www), więc jest to wieloetapowy i dość zaawansowany typ ataku. Z drugiej strony, daje on dużo większe możliwości rozpowszechniania złośliwego kodu oraz ukrycia takich działań przed zbyt wczesnym wykryciem.

Sam sposób uzyskania dostępu do maszyny, na której znajduje się serwer www, oraz zdobycie uprawnień użytkownika ‚root’ to bardzo obszerny temat, wykraczający poza ramy tego wpisu (zainteresowanych zachęcam do odwiedzenia serwisu Packet Storm Security, Secunia oraz Exploit Database).

 

1. Atak z wykorzystaniem plików konfiguracyjnych serwera Apache

Przyjrzyjmy się pierwszemu z rozpatrywanych przypadków. Do przeprowadzenia tego rodzaju ataku potrzebne są dwa elementy:

  • plik z tzw. ‚payloadem’, czyli odpowiednio spreparowaną zawartością będącą „nośnikiem” dla złośliwego kodu, oraz
  • odpowiednio skonfigurowany serwer www, który zapewni dystrybucję tego kodu.

Pierwszy element może wyglądać tak, jak na zamieszczonym poniżej listingu (jest to maksymalnie uproszczony przykład, mający na celu zaprezentowanie jedynie schematu tworzenia takich plików):

Spreparowany odpowiednio kod JavaScript, inicjujący ładowanie malware.

Odpowiedni wpis we właściwym pliku konfiguracyjnym serwera Apache (apache2.conf, httpd.conf, .htaccess bezpośrednio w drzewie katalogów serwisu internetowego), to drugi element układanki – powinna się w nim znaleźć dyrektywa dołączająca złośliwy kod do każdego pliku PHP, przetwarzanego i zwracanego przez serwer:

Fragment wpisu odpowiedzialnego za automatyczne dołączanie wskazanego pliku do każdego przetwarzanego przez serwer skryptu PHP.

Efektem takiego działania będzie automatyczne dołączenie (dyrektywa PHP auto_prepend_file) pliku z kodem ładującym malware (lub wykonującym dowolną inną szkodliwą działalność na komputerze odwiedzającego zainfekowaną w ten sposób witrynę) do każdego pliku PHP, jaki będzie wysyłany przez serwer. Działanie auto_prepend_file jest analogiczne do działania dyrektywy require() lub include() z tą różnicą, że wykonywane jest z poziomu serwera, a nie kodu napisanego przez programistę.

 

2. Atak z wykorzystaniem modułów serwera Apache

Drugi rodzaj ataku wykorzystuje podobny mechanizm, ale tutaj „nośnikiem” informacji o złośliwym kodzie jest odpowiednio spreparowany moduł serwera Apache – skompilowany i uruchamiany wraz z innymi poprzez odpowiedni wpis w pliku konfiguracyjnym (httpd.conf, apache2.conf):

Wpis z przykładową bliblioteką będącą złośliwym modułem serwera Apache.

Nazwy modułów mogą być różne, na pierwszy rzut oka nie wzbudzają one żadnych podejrzeń – ot, kolejna skompilowana biblioteka .so. Z pozoru niegroźny moduł ma jednak nieograniczone możliwości. Specjaliści z Sucuri analizowali przypadek, w którym infekcja dokonywana była tylko w ściśle określonych przypadkach (na podstawie systemu operacyjnego i przeglądarki, z której inicjowane było żądanie HTTP złośliwy moduł decydował, czy serwer www ma dołączyć do zwracanej odpowiedzi złośliwy kod). Z perspektywy odwiedzających tak zainfekowaną stronę nawet analiza źródła HTML mogła niczego nie wykazać – wystarczyło, że wejście dokonane zostało z innej, niż docelowa, przeglądarki i kod był pozbawiony niebezpiecznego dodatku.

Pod tym adresem został zamieszczony kod źródłowy przykładowego złośliwego modułu. Poniżej znajduje się fragment, w którym można przeanalizować funkcję sprawdzającą, czy żądanie wyświetlenia zasobu nie pochodzi od któregoś z robotów indeksujących. W takim przypadku moduł nie dopuszcza do dołączenia złośliwego kodu JavaScript, by nie zdradzić swojej obecności silnikom wyszukiwarek (jak wiemy, dysponują one mechanizmami zgłaszania użytkownikom fakt odwiedzenia zainfekowanych stron www):

Fragment kodu źródłowego w języku C przykładowego złośliwego modułu serwera Apache; kompletny listing dostępny pod tym adresem.

 

Na zakończenie

Jeśli jesteś administratorem serwera www, warto poświęcić chwilę na analizę zawartości plików konfiguracyjnych pod kątem dziwnych i nieznanych wpisów. Analiza logów niewiele tutaj pomoże – tego rodzaju atak nie jest przeprowadzany „z zewnątrz”, stąd też rejestrowanie w logach żądań GET czy POST przychodzących do serwera nie wykaże niczego podejrzanego i dającego się jednoznacznie zidentyfikować np. jako atak SQL Injection (np. ciągi ‚UNION SELECT’ w treści żądania) czy specyficzne, JavaScript-owe payloady wskazujące na próby znalezienia podatności XSS. Atak dokonywany jest niejako „od środka”, niebezpieczny kod doklejany jest już na etapie interpretowania kodu PHP.

Przykładową procedurę wyszukania i usunięcia szkodliwego modułu Apache na serwerze pracującym pod kontrolą systemu Debian można znaleźć na blogu firmy Sucuri pod adresem Web Server Compromise – Debian Distro – Identify and Remove Corrupt Apache Modules.

Jeśli jako webmaster bądź użytkownik chcesz sprawdzić, czy Twoja strona hostowana na zewnętrznym serwerze nie zawiera złośliwego kodu, polecam odwiedziny na unmaskparasites.com, gdzie wystarczy wpisać adres www naszej witryny, a następnie cierpliwie poczekać na wynik audytu.

Ten dostępny pod tym adresem wskazuje, że możesz bez obaw przebywać na Sekuraku. :)

 

Źródła

 

Rafał ‚bl4de’ Janicki– bloorq[at]gmail.com

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. Michał

    Myślę, że jeśli ktoś ma w niepowołany sposób zmodyfikowane pliki konfiguracyjne serwera WWW to i tak już ma na głowie większe zmartwienie, bo prawdopodobnie ktoś mu wlazł na roota (no chyba, że zdarzają się tacy co dają prawa zapisu do plików konfiguracyjnych i nie robią żadnego hardeningu Apache/PHP)

    Odpowiedz
  2. Michał – w sumie tak, choć zauważ że to jest atak bardziej na innych userów niż tego kto ma normalnie na serwerze roota. Czyli ktoś dostaje roota na jakimś popularnym sajcie i teraz elegancko ten sajt hostuje malware, a sam atak nie zostawia po sobie za dużo śladów (przynajmniej na pierwszy rzut oka).

    –ms

    Odpowiedz
  3. bl4de

    Lub, uzupełniając powyższą odpowiedź – atakującemu może wręcz zależeć na takim właśnie wykorzystaniu przejętej maszyny (jako dystrybuującej złośliwy kod).

    Zauważ elegancję takiego rozwiązania (przykładowo tego w postaci modułu Apache, z f-cją sprawdzającą ciąg User Agent w nagłówku żądania) – atakujący może zdefiniować docelową platformę, która ma otrzymać „dodatek” w postaci JavaScript’owego malware.

    Eliminuje w ten sposób choćby przypadkowe wykrycie przez osobę korzystającą z przeglądarki Chrome działającej na Linuksie bądź z Safari na Mac OSX, gdy interesują go jedynie maszyny z Windows 7 i IE w wersji 9 – bo akurat na taką konfigurację ma przygotowanego exploita, ładowanego przez malware.

    Odpowiedz

Odpowiedz