Igła w stogu siana
-
- 27.01.2009
Po wykryciu podejrzanych połączeń przychodzi czas na analizę przyczyn i źródła infekcji. Czasami jest to trudniejsze niż odkrycie samego ruchu spyware i „namierzenie” zarażonej stacji roboczej.
Jak może przebiegać atak
Scenariusz zdarzeń może być następujący. Podczas zwykłego surfowania po Internecie, użytkownik otworzył stronę, która wyglądała na zwykły błąd Error 404, wyświetlany przez serwer w przypadku błędnego łącza. Tymczasem właśnie ten serwis, utrzymywany na źle zabezpieczonym serwerze IIS w systemie Windows Server 2008, został przejęty przez przestępców. Wyszukiwana strona została podmieniona na taką, która przypomina standardowy błąd Error 404 wyświetlany przez taki serwer. Chociaż wyglądała zwyczajnie, w treści kodu było odwołanie do skryptu Jscript i przeglądarka podążyła za linkiem, pobierając plik z innego serwera w Korei. Dziurawy Internet Explorer został skompromitowany, umożliwiając pobranie i uruchomienie dowolnego kodu na stacji roboczej. Sprytnie przygotowana aplikacja dokonała wstrzyknięcia kodu do przeglądarki i pobrała pozostałe składniki spyware, łącząc je z kilku plików, a następnie zainstalowała. Ustawienia zapory Windows Vista nie musiały być w ogóle modyfikowane, gdyż firewall ten nie chroni przed takimi połączeniami wychodzącymi. Po restarcie spyware już się uruchamiało automatycznie, omijało zabezpieczenia systemu i okresowo wysyłało drobne paczki danych z wbudowanego keyloggera. Połączenia odbywały się na różne porty (443, 53) przy użyciu nieznanego protokołu.
Analiza samej strony Error 404 pokazała, że kod skryptu został zapisany w postaci maksymalnie utrudniającej rozpoznanie. Przeglądanie strumienia TCP/IP za pomocą narzędzia Wireshark, z użyciem opcji Follow TCP stream pokazało jedynie heksadecymalny zapis jakichś znaków w unikodzie, a następnie obliczanie parametrów za pomocą pogmatwanego skryptu. Dopiero jego analiza pokazała, co naprawdę robi – sprawdza wersję przeglądarki i systemu operacyjnego, a następnie pobiera odpowiednie pliki z odległego serwera i eksploituje błąd przeglądarki. Wykrycie źródła takiej infekcji bez narzędzi, które potrafią sprawnie filtrować zebrane archiwum ruchu, byłoby bardzo trudne.
1. Należy utrzymywać wszystkie systemy w pełni zaktualizowane i chronione oprogramowaniem antywirusowym.
2. Połączenia od stacji roboczych do Internetu nie mogą wychodzić bezpośrednio, należy przeprowadzać je przez odpowiednio skonfigurowany serwer proxy.
3. Połączenia SSL powinny być domyślnie zablokowane, odblokowywane jedynie do wybranych serwerów. To samo dotyczy portu DNS (zablokować wszelkie połączenia, robiąc wyjątek jedynie dla korporacyjnych serwerów DNS).
4. Należy monitorować ruch ICMP, gdyż są już programy, które korzystają z tunelu IP over ICMP.
5. W sieci powinno być narzędzie, które analizuje ruch pod kątem protokołów, umożliwiające zablokowanie niepożądanych połączeń.
