Infekcje na koncie hostingowym

Jeśli:

• antywirus zainstalowany na Twoim komputerze wykrył zagrożenie zidentyfikowane jako pochodzące z Twojej strony WWW
• przeglądarka internetowa wyświetliła ostrzeżenie o Twojej stronie jako dokonującej ataków
• otrzymałeś wiadomość e-mail z informacją o wykrytych wirusach na koncie

znaczy to, że Twoja strona została zainfekowana szkodliwym oprogramowaniem (wirusami komputerowymi).

Pamiętaj, że obowiązek zabezpieczenia strony i innych treści na koncie przed infekcjami wirusów spoczywa na Tobie jako użytkowniku konta, ponieważ Cyberfolks nie ingeruje w treści użytkowników. Ingerencja w treści kont byłaby przekroczeniem umownych warunków świadczenia usługi ze strony Cyberfolks. Z tego samego powodu Cyberfolks nie decyduje o treściach umieszczanych przez użytkownika na serwerze i nie dokonuje ręcznie ich weryfikacji wstępnej, ani nie zatwierdza ich dodania.

Poniżej zamieszczone są informacje jak rozwiązać ten problem.

Jak wirus znalazł się ma moim koncie?

Możliwe przyczyny i przypadki infekcji zalicza się do kategorii:

• wcześniejsza infekcja komputerów używanych przez osoby odpowiedzialne za treść zainfekowanej strony WWW. W czasie gdy osoba taka logowała się do zaplecza strony lub na serwer, hasło zostało „podsłuchane” lub odczytane z pamięci programu używanego do łączenia ze stroną lub serwerem
• wykrycie i wykorzystanie luki w kodzie strony umieszczonej na koncie. Zarówno strony napisane ręcznie przez webmastera, jak i strony oparte o popularne bezpłatnie dostępne CMS-y mogą stać się celem wirusów. Ten rodzaj problemu wynika z ciągłego skanowania stron internetowych przez botnety w poszukiwaniu znanych podatności.
• odgadnięcie hasła. Gdy botnet natrafi na stronę, na której wykryje znaną podatność na ataki (jak chociażby znany adres logowania do zaplecza strony nie chroniony w żaden dodatkowy sposób), rozpoczyna próby włamania na stronę, np. przez masowe próby zalogowania się na hasłach z list rankingowych popularnych haseł.

Możliwych przebiegów infekcji wirusowych jest wiele.

Do znanych częstych przebiegów infekcji pierwszej kategorii należą:

• odwiedzenie zewnętrznej strony WWW (nie mające związku z Twoim kontem) wcześniej zainfekowanej wirusem w podobny sposób
• otwarcie i aktywowanie szkodliwego załącznika przesłanego pocztą elektroniczną
• otrzymanie i użycie nośnika pamięci np. PENDRIVE, wcześniej używanego na zawirusowanym komputerze, zwłaszcza komputerze publicznie dostępnym

przy czym w każdym z powyższych przypadków, na komputerze osoby odpowiedzialnej za treść strony, nie było zainstalowanego antywirusa, lub nie rozpoznał on zagrożenia (skuteczność antywirusów jest wysoka ale nie stuprocentowa).

Do znanych częstych przebiegów infekcji drugiej kategorii należą:

• nieaktualizowanie używanych na koncie popularnych CMS-ów, wtyczek i szablonów, których popularność jest wykorzystywana przez atakujących, a zostały w ich nieaktualnej wersji wykryte luki umożliwiające przejęcie kontroli w sposób nieupoważniony
• generowanie dynamicznie kodu HTML, w którym odnośniki są przekazywane do zmiennych, które z kolei nie są kontrolowane czy zawierają wartości dozwolone, a konstrukcja kodu generującego stronę uruchamia wskazaną zawartość zmiennej
• brak weryfikacji danych przesyłanych formularzem, zwłaszcza gdy strona umożliwia przesłanie plików dostępnych do wywołania z serwera bezpośrednio po umieszczeniu ich na serwerze

Jak to możliwe że hasło mogło zostać odgadnięte?

• Włamywacze często dysponują dużymi „farmami komputerów zombie”, „botnetami” – dużą ilością zawirusowanych komputerów osobistych, za pośrednictwem których próbują zalogować się na zaplecze CMS-a. Jeśli z każdego z nich tylko raz spróbują się zalogować na zgadywane hasło, konwencjonalne mechanizmy zabezpieczeń przed atakami typu Brute Force mogą nie wystarczyć do odparcia takiego ataku. W takich przypadkach dobrym rozwiązaniem jest założenie blokady możliwości logowania do zaplecza strony z wszystkich poza zaufanymi adresami IP, lub dodanie / ustawienie niestandardowego lub niekonwencjonalnego logowania (np podwójne logowanie, zmiana domyślnego adresu logowania na inny).
• W internecie można znaleźć rankingi najpopularniejszych haseł (wystarczy wygooglać „najpopularniejsze hasła”) oraz informacje jak szybko słownikowo odgadywać hasła. Dlatego nie należy stosować prostych haseł, składających się z wyłącznie małych lub dużych liter, słów które można znaleźć w słownikach językowych, ani popularnych kombinacji cyfr takich jak lata. Hasła niemożliwe do odgadnięcia słownikowo zawierają małe i duże litery w różnej ilości oraz cyfry i znaki specjalne. Całe hasło powinno składać się z przynajmniej 8 znaków. Istnieją proste, lecz bardzo skuteczne, metody ułatwienia zapamiętania skomplikowanego hasła, np gdy traktujemy znak specjalny „!” jako odpowiednik litery „i”. Można utworzyć własną mapę takich przekształceń znaczeniowych i dzięki nim konstruować bardzo skomplikowane hasła, które jednocześnie będą bardzo łatwe do zapamiętania (np „kom!n”). Pamiętać jednak należy, aby unikać „przekształceń” łatwych do odgadnięcia jak wskazany przykładowy znak „!”. Nie zdradzaj nikomu swojej mapy takich przekształceń.

Jak rozwiązać problem wirusów na moim koncie?

W większości przypadków można postępować wg poniższej listy:

• Należy zacząć od sprawdzenia antywirusem swojego komputera i rozwiązać problem wirusów na nim, lub skorzystać z takiego komputera, o którym wiadomo, że jest wolny od wirusów i nie jest używany publicznie przez większą ilość osób.
  •  W przypadku wykrycia wirusów na komputerze osobistym, oprócz jego oczyszczenia, konieczna jest zmiana wszystkich potencjalnie przejętych haseł do:
    • skrzynek mailowych na które przesłane będą nowe hasła (czyli przypisanych w panelu klienta jako kontaktowe)
    • panelu klienta (http://panel.cyberfolks.pl)
    • panelu admina (adres panelu przesłany jest mailem powitalnym lub jego wtórnikiem)
    • kont FTP (za pośrednictwem panelu admina)
    • haseł dostępowych do baz danych, dla których został włączony dostęp z zewnątrz dla wszystkich adresów
  • Nawet jeśli antywirus nie znalazł wirusów na komputerze osobistym, nie można wykluczyć możliwości przejęcia hasła w inny sposób, więc zmiana haseł jest zalecana. Innymi sposobami przejęcia hasła mogło być np jego odgadnięcie, lub przejęcie hasła do czegoś innego gdzie używane było to samo hasło. Na serwerze hasła są przechowywane w sposób uniemożliwiający ich odczytanie, więc nie mogło zostać przejęte bezpośrednio z niego, z części nie przeznaczonej do kontroli przez użytkownika.
  • Dobrą praktyką jest zmienianie haseł przynajmniej raz na kilka miesięcy.
• W przypadku, gdy dostęp do stron WWW jest zablokowany, a jest konieczny do oczyszczenia konta, można poprosić administratorów o odblokowanie dostępu dla użytkownika po przesłaniu przez niego swojego adresu IP (można sprawdzić na stronie http://ip.vdl.pl). Zainfekowane strony proszę sprawdzać z zabezpieczonych komputerów, z których nie będzie ryzyka przejęcia haseł.
• Do oczyszczenia konta możliwe są do zastosowania różne metody:
  • sprawdzić cała zawartość konta na serwerze i oczyścić ze szkodliwego kodu
  • przywrócić własną niezainfekowaną kopię zapasową
  • skasować aktualną stronę i postawić nową od samego początku wyposażając ją w odpowiednie pluginy zabezpieczające (o tym więcej poniżej)
  • przenieść aktualną stronę w miejsce niedostępne publicznie i na jej podstawie postawić nową stronę od  samego początku wyposażając ją w odpowiednie wtyczki zabezpieczające
• do pobrania plików z konta można użyć standardowych narzędzi do połączenia FTP i SSH (np Filezilla, WinSCP), a z poziomu SSH możliwe jest analizowanie plików bezpośrednio na serwerze

Jak zidentyfikować które pliki na koncie są szkodliwe?

• do CMS-ów dostępne są wtyczki skanujące podobnie jak antywirus, ale nie ma gwarancji że takie narzędzie wykryje wszystko
• gdy posiadasz własną kopię zapasową plików strony, można pobrać pliki strony do siebie i użyć narzędzi do porównywania całych zawartości katalogów w poszukiwaniu różnic. Jednym z programów umożliwiających to jest WinMerge
• gdy wiadomo kiedy pliki były ostatnio modyfikowane przez osoby upoważnione i nie były zmieniane po wykryciu szkodników, można wygenerować bezpośrednio na serwerze listę plików posortowaną wg dat ostatnich zmian w plikach. Jeśli antywirus czegoś nie rozpoznał – znajdzie się to na tej liście. Przygotowaliśmy stronę instruującą jak efektywnie korzystać z tej listy -> kliknij tu aby przejść do strony
• do plików statycznych i szablonów mógła zostać dodana ramka IFRAME ładująca zewnętrzny adres lub szkodliwy kod javascript (jego wywołanie z zewnętrznego adresu) przekierowujący na inną szkodliwą stronę lub instalujący wirusy na komputerze internauty odwiedzającego zawirusowaną stronę. Należy w bezpieczny sposób pobrać treść strony i przejrzeć jej kod HTML – szkodliwy dodatek zwykle można rozpoznać przez wywołanie do zewnętrznej strony lub „nieczytelny kod”, a w niektórych przypadkach wyróżniające się odwołanie do dodatkowych plików na tym samym koncie. Do bezpiecznej analizy za pośrednictwem przeglądarki, należy wyłączyć uruchamianie javascript-u w przeglądarce, lub skorzystać z wtyczek np. NoScript
  • część szkodników dodawanych do kodu HTML, dodawana jest tylko w specyficznych warunkach – przez osadzony szkodliwy kod PHP w szablonach stron. Szkodnik tego typu najczęściej sprawdza jakiej przeglądarki www używa odwiedzający stronę i czy otwiera adres z odwołania z innej strony o zdefiniowanym adresie. W takim przypadku, niespełnienie warunków uniemożliwi skuteczne wykrycie szkodnika przez analizę samego kodu HTML. Pozostaje analiza kodu obecnego na serwerze lub odtworzenie warunków, w których szkodnik się ujawnia
• do plików uruchamianych, celem dynamicznego generowania stron, mógł zostać dodany szkodliwy kod pozwalający uruchomić zewnętrzny kod pobierany lub przesyłany ze zdalnego komputera za każdym razem, np. przez odpowiednie wywołanie GET lub POST do strony. Należy wtedy szukać fragmentów kodu pozwalających uruchomić inny kod generowany. W przypadku PHP funkcją na którą należy zwrócić szczególną uwagę jest eval() lub funkcje służące do budowania nowych funkcji w czasie parsowania kodu
• do plików uruchamianych mógł zostać dodany zakodowany / zaszyfrowany / zaciemniony kod, którego antywirus, ani żadne automatyczne metody skanowania, nie będą w stanie rozpoznać. Można go ręcznie / wizualnie zidentyfikować, poszukując w plików kodu znacznie różniącego się wyglądem od normalnego, gdyż nie daje się go odczytać i zrozumieć czytającemu kod bez „odszyfrowywania”. Przykładem takiego jest efekt pracy base64_encode.
• mogły zostać dodane do katalogów konta dodatkowe pliki, w tym kod uruchamiany z niestandardowych „rozszerzeń” plików. W takim wypadku należy sprawdzić czy nie został dodany do plików .htaccess dodatkowy kod zmieniający interpretację plików np. graficznych GIF, na wykonywalne (reguła AddHandler)
• pliki graficzne istniejące na serwerze mogły zostać zmodyfikowane do roli magazynu szkodliwego kodu. Działanie to ma na celu zmylić antywirusy i inne automatyczne mechanizmy wykrywania infekcji. Dość częstym przykładem tego jest dodanie w plikach JPG, w ich metadanych EXIF, w polu producenta i modelu aparatu fotograficznego, kodu „eval(base64_decode(…” lub podobnego. Obecność tego kodu można sprawdzić ręcznie każdym dobrym programem do edycji grafiki, sprawdzając dane EXIF (np. darmowym GIMP-em). Sam plik graficzny jest nieszkodliwy, ale zawsze występuje on w tandemie z innym szkodliwym plikiem, który odczytuje zmagazynowane szkodliwe dane z tego pliku graficznego. Z poziomu serwera można relatywnie szybko wykryć czasochłonnym poleceniem find szukającym samych plików graficznych z opcją -exec wywołującą grep -l base64 na znalezionych plikach.
• w internecie można znaleźć automatyczne skanery luk w stronach, lecz odradzamy wszystkie które wymagają podania danych dostępowych do serwera, a przed skorzystaniem z pozostałych należy upewnić się czy nie są oszustami
• można skorzystać z usługi firmy przeprowadzającej audyty bezpieczeństwa

Jak zidentyfikować pliki na koncie, przez które wirus lub włamywacz się dostał na konto?

Należy przejrzeć logi wywołań stron. W przypadku kont hostingowych są zawsze dostępne w katalogach domen oraz przez panel admina w statystykach i logach. W wielu przypadkach można w nich zlokalizować pierwotną lukę w kodzie strony wykorzystaną do włamania, pod warunkiem, że nie nastąpiła dawno z czasu z którego nie ma już logów.

W części przypadków, oprócz zmian w plikach, wirus dodaje „dodatkowych” użytkowników z prawami administracyjnymi w bazie danych używanej w CMS-ach. W takim przypadku należy sprawdzić ręcznie bazę danych, np przez phpmyadmin-a i usunąć ewentualne szkodliwe wpisy w tabelach użytkowników CMS-ów. Przykładem takiego działania może być usuwanie wirusów ze strony na WordPress.

Do analizy plików zalecamy włączenie funkcji zawijania wierszy – często szkodliwy kod wstawiony jest po kilkuset znakach „spacji”, więc łatwo jest go przegapić bez zawijania wierszy. Do przeglądania plików dobrym narzędziem jest Notepad++

Przywracanie własnej kopii zapasowej może być wykonane w różny sposób, np. przez panel Driect Admin w menu kopii zapasowych, lub przez FTP przesyłając pliki normalnie na serwer.

Na serwerach kont hostingowych zwykle dostępne są kopie zapasowe plików stron www oraz kopie zapasowe baz danych z ostatnich 2 tygodni, wykonywane przez administratorów. Jednakże zwykle widoczna część działań szkodników na koncie rozpoczyna się co najmniej kilka dni po pierwotnym uzyskaniu dostępu, a często po kilku tygodniach. W tej sytuacji należy najpierw sprawdzić daty plików rozpoznanych szkodników, czy są starsze niż backup. Jeśli tak, jego przywracanie kopii zapasowej wykonywanej przez administratorów nie rozwiąże problemu.

Jak uniknąć powtórzenia tego problemu w przyszłości?

• aktualizacje – aktualizować oprogramowanie zarówno na swoim komputerze osobistym, jak i kod stron umieszczanych na koncie, zwłaszcza opartych o popularne CMS-y
• antywirus – jeśli nie jesteś pewien czy Twój komputer jest wystarczająco zabezpieczony innymi sposobami, koniecznie zainstaluj na swoim komputerze osobistym antywirus monitorujący na bieżąco aktywność na komputerze
• wyposażyć używane CMS-y we wtyczki zabezpieczające np Better WP Security, RSFirewall itp. Dla CMS-ów dostępne są również różne wtyczki skanujące pliki konta w poszukiwaniu wirusów, prawie jak antywirusy. Oficjalne repozytorium wtyczek:
  • WordPressa http://wordpress.org/extend/plugins
  • Joomli http://extensions.joomla.org/extensions/access-a-security/site-security
  • Drupala https://drupal.org/project/Modules oraz nieoficjalne http://drupalmodules.com/category/Security
• kod stron pisany ręcznie specjalnie dla Twojej strony WWW powinien być sprawdzony ręcznie przez Twojego webmastera/programistę pod kątem możliwości injekcji kodu lub „rozkazów” nie przewidzianych przez autora kodu strony. Dość częstym problemem jest wykorzystywanie w linkach podstawienia wartości do zmiennej, która ma wskazywać na includowany plik php, lecz nie jest weryfikowane czy pod zmienną podstawione są dozwolone wartości.
• zablokować dostęp do części administracyjnej strony przez dodanie dodatkowej weryfikacji adresu IP (odpowiednio dostosowany wpis w .htaccess-ie często wystarczy). Adres IP możesz sprawdzić na http://ip.vdl.pl. W przypadku używania łącza internetowego ze zmiennym adresem IP, można dodać do wyjątków od blokady całe pule adresowe dostawcy łącza internetowego. Jak założyć taką blokadę opisane jest na tej stronie. W ostatnim czasie administracja wprowadziła odgórnie dodatkową weryfikację logowania na kokpit WordPressów, na części serwerów hostingowych. Spowodowało to znaczny spadek ilości włamań na WordPressy w starszych wersjach. Prawdopodobną przyczyną tak dużej różnicy przez ten prosty mechanizm jest to, że po dodaniu dodatkowej weryfikacji, automatyczne skanery stron włamywaczy widzą już, że strona jest wyposażona w niestandardowe zabezpieczenie i „odpuszczają” dalsze próby włamań. Działa to jednak tylko na WordPressy domen, które nie były wcześniej infekowane lub zostały całkowicie oczyszczone.
• zablokować dostęp przez FTP dla niezaufanych adresów IP – można skorzystać z panelu admina, lub umieścić w głównym katalogu konta dostosowany plik .ftpaccess – wtedy nawet jeśli hasło zostanie przejęte, włamywacz nie będzie mógł go wykorzystać
• dodać własną blokadę POST-owania w pliach .htaccess dedykowaną dla katalogów, które nie mają przyjmować żadnych POST-ów, np katalogi z przeznaczeniem wyłącznie dla plików nieuruchamianych, np katalogi na obrazy, dźwięki, cache. Można też dodać blokadę dostępu do plików w formatach innych niż dozwolonych z danych katalogów.

Jeśli przynajmniej część z powyższych metod zabezpieczenia zainfekowanej strony nie zostanie wprowadzona, ponowna infekcja tą samą metodą będzie jedynie kwestią czasu. Atakujący dysponujący botnetami cały czas „skanują” strony w internecie w poszukiwaniu stron podatnych na ich działania i często po kilku tygodniach próbują to zrobić do wcześniej zainfekowanych stron, nad którymi utracili nieuprawnioną kontrolę.

Powyższe metody będą skuteczne tylko w przypadku pełnego oczyszczenia konta ze szkodników.

Pozostawienie któregokolwiek grozi powtórką problemu nawet pomimo zastosowania powyżej proponowanych metod zabezpieczenia.

Im więcej plików jest na koncie oraz były one modyfikowane w sposób wydłużający sprawdzanie listy zmienianych plików, tym większe prawdopodobieństwo pominięcia backdoor-ów pozostawionych przez infekcję. Doświadczenie pokazuje, że tak często.

W takich wypadkach jedynym sensownym rozwiązaniem jest postawienie strony od nowa, kopiując treści z dotychczasowej, blokując możliwość normalnego dostępu do czyszczonej, co do której nie ma pewności całkowitego oczyszczenia.

Jeżeli dokładne oczyszczenie stron www nie jest możliwe lub trwałoby za długo, mimo to możliwe jest uratowanie przynajmniej części treści stron poprzez:

• Przeniesienie treści stron pod tymczasowy adres, zwykle wystarczy zmiana nazwy domeny na testową. Na kontach obsługiwanych Panelem Administracyjnym można to zrobić przez menu administracji domenami. Po zmianie nazwy domeny należy dodać od nowa dotychczasową. Pozwoli to na postawienie oddzielnej (czystej) wersji strony, która nie będzie konfliktować z dotychczasowym kodem strony. Jeśli kod strony na sztywno przypisany jest do adresu strony, należy przygotować stronę do zmiany adresu jeszcze przed jej wykonaniem.
  • Joomla nie ma tego problemu
  • WordPress wymaga zapoznania się z treścią strony: https://wordpress.org/support/article/moving-wordpress/
• Zabezpieczenie dostępu do dotychczasowej treści strony przez blokadę po adresie IP lub dodaniu dodatkowego logowania na hasło (w panelu admina menu katalogi na hasło)
• Nową instalację cms-a na docelowym adresie strony. Dla bezpieczeństwa, na czas migracji danych między cms-ami i zabezpieczaniem nowego, proponujemy dodać zabezpieczenie opisane w pkt 2.
• Zmigrowanie treści stron manualnie lub pół-automatycznie, weryfikując treści przenoszone. Weryfikacja jest konieczna ze względu na możliwość pozostawienia przez włamywacza nieuprawnionych wpisów w bazie danych (np dodatkowych użytkowników z prawami administratora zaplecza strony).

Proszę nie traktować powyższych jako jedynych możliwych metod rozwiązania tego problemu. W internecie można znaleźć wiele innych obszerniejszych poradników rozwiązywania takich problemów.