Session riding – zagrożenie dla internautów

Tysiące stron internetowych pada ofiarą ataku – hakerzy wprowadzają do nich złośliwy kod.

W G Data SecurityLabs wykryliśmy wiele stron internetowych, przy których manipulowali hakerzy. W poniższym artykule przedstawiamy szczegóły zagrożenia atakiem typu session riding oraz rady, jak się przed nim chronić.

Z atakiem session riding mamy do czynienia, gdy hakerzy umieszczają w zwykłej stronie internetowej złośliwy kod, prowadzący do pliku JavaScript umieszczonego na zewnętrznym serwerze. Plik “uprowadza” pliki cookies z danej sesji. Dzięki temu haker może podszywać się pod użytkownika strony.

Kod zamieszczony na stronie
Kod jest albo zamieszczony jako tekst jawny, albo zakodowany i trudny do odczytania.

Nasze skanery wykryły wprowadzony kod jako HTML:Script-inf. Użytkownicy, którzy używają filtra HTTP, są natychmiast informowani o zagrożeniu.

Zdeponowany JavaScript

Szkodliwy plik JavaScript został wykryty na kilkunastu serwerach, występował też pod różnymi nazwami. Jego najnowsza wersja pozyskuje informacje o przeglądarce, z której korzysta dany użytkownik i pobiera pliki cookies z jego komputera. Plik został zidentyfikowany jako Trojan.JS.Iframe.BDV i JS:Iframe-FP [Trj].

Możliwe scenariusze
Przykład: wyobraźmy sobie, że hakerzy wprowadzili złośliwy kod do sklepu internetowego. Niespodziewający się niczego użytkownik wchodzi na stronę i loguje się na kontro. W tym czasie uruchamia się złożliwy skrypt. Hakerzy zyskują dostęp do konta zakupowego użytkownika – mogą więc, bez jego wiedzy, na przykład zamawiać coś w jego imieniu.

Hakerzy mogą zamieścić dowolną zawartość na serwerze, do którego się włamali – dopóty, dopóki mają możliwość zalogowania się. Mogą na przykład używać serwera jako depozytu na pliki malware lub zamieszczać na nim skrypty, które przekierowywują użytkownika do złośliwych plików.

Jak kod zostaje zamieszczony na stronie?
Hakerzy mają wiele sposobów na włamanie się do systemów zarządzania stroną. Wielokrotnie informowano o przypadkach wykorzystywania słabych punktów systemów CMS. Ci, którzy pamiętają bombę (http://blog.gdatasoftware.com/blog/article/hacked-wordpress-pages-reveal-potential-time-bomb.html) zamieszczoną na zaatakowanych stronach w WordPressie, wiedzą, o czym mowa.

Często ofiarą ataków padają popularne systemy CMS takie jak WordPress czy Joomla. Ataki jednak nie ograniczają się do nich. Z dostępnych nam obecnie informacji wynika, że komputery użytkowników zarządzających treścią na stronach zostają zaatakowane plikami malware, które kradną hasła. Dzięki nim hakerzy mają dostęp do systemów zarządzania stroną.

O tym, jak ważne jest zabezpieczanie komputerów, można mówić w nieskończoność. Jeden zainfekowany komputer może szkodzić kolejnym, ponieważ ofiarą złośliwych plików padają wszyscy odwiedzający stronę, której administrator został zaatakowany.

Co może zrobić administrator?

·      Dla zabezpieczenia strony należy regularnie aktualizować system zarządzania stroną.

·      To samo dotyczy pluginów i wzorów strony.

·      Jeśli zarządzasz serwerem, upewnij się, że jest bezpieczny i stale aktualizowany. Jeśli korzystasz z zewnętrznego serwera, skontaktuj się w tej sprawie z jego właścicielem.

·      Hasła, zwłaszcza do CMS i FTP, należy wybierać ostrożnie. Kontro administratora nie powinno nazywać się “admin”. Każde z kont powinno posiadać swoje własne, starannie wybrane hasło. O hasłach i bezpieczeństwie można poczytać tutaj: http://www.gdatasoftware.co.uk/security-labs/information/tips-tricks/secure-passwords.html

·      Nieaktywne konta zarządzania stroną należy dezaktywować.

·      Wszystkie komputery, z których jest możliwy dostęp do systemów zarządzania stroną, muszą być regularnie skanowane i wyposażone w oprogramowanie chroniące przed plikami typu malware, kradnącymi hasła.