Czasem po wpisaniu w przeglądarce adresu własnej strony internetowej można się wielce zdziwić i np. jej nie zastać. Bądź, co gorsze, zastać zupełnie inną o - delikatnie mówiąc - niepożądanej treści. Niekiedy może się również zdarzyć, że strona jest dostępna dla odwiedzających, jednak wykonuje operacje, których jej twórca nie przewidział. Takie bądź podobne symptomy oznaczają jedno - strona WWW została zhakowana i wymaga szybkiej reakcji jej administratorów.
W dzisiejszym wpisie opowiem o ataku, którego sam w ostatnim czasie doświadczyłem - o jego potencjalnych przyczynach, przebiegu i skutkach, a także przywracaniu strony do życia.
{flike}
Błąd 500 - włamanie na serwer i zhakowany plik .htaccess
Poniedziałek, 28 grudnia, godz. 7:50 - wprowadzam w przeglądarce adres panelu administracyjnego swojej strony InformatykaWFirmie.pl (chcąc napisać kolejny artykuł). Zamiast ekranu logowania (a także każdego innego ekranu strony) moim oczom ukazuje się jednak komunikat błędu 500. Jego przyczyna leży po stronie serwera, na którym hostowana jest witryna. Szybko sprawdzam czy problem dotyczy tej konkretnej strony WWW czy może wszystkich witryn zainstalowanych na danym serwerze - odwiedzając po kolei każdą z moich stron internetowych (dla większości z nich mam wykupiony hosting u tego samego providera). Okazuje się, że błąd 500 występuje tylko na InformatyceWFirmie.pl.
Oczywiście, niedostępność strony w internecie to dla jej właściciela istny dramat: ryzyko utraty stałych czytelników, zniechęcenie / brak dostępu do informacji przez potencjalnych klientów (a więc ryzyko utraty sprzedaży) czy w końcu spadek pozycji witryny w wynikach wyszukiwania Google (a w przypadku strony zainfekowanej złośliwymi skryptami ryzyko zablokowania jej zasobów). Straty mogą więc być naprawdę bolesne, jeśli nie zareagujemy odpowiednio szybko.
Jako że błąd 500 (Internal Server Error) bardzo często jest spowodowany nieprawidłowymi wpisami w pliku .htaccess umieszczanym w głównym katalogu witryny, odpowiedzialnym m.in. za przekierowania adresów URL, postanowiłem zweryfikować jego zawartość. Okazało się, że w sekcji RewriteBase (w moim przypadku normalnie pustej) pojawiło się kilkadziesiąt wpisów tego rodzaju:
Złośliwy kod szybko wyeliminowałem, przywracając starą, tj. prawidłową wersję pliku .htaccess na serwerze (pozyskałem go z jednej z kopii zapasowej, które wykonuję po każdej aktualizacji strony). InformatykaWFirmie.pl znów działa, błąd 500 nie występuje.
Skąd wzięły się złośliwe wpisy w moim pliku .htaccess? Zostały podmienione przez hakera, który dostał się na serwer - świadczą o tym daty modyfikacji plików (m.in. .htaccess czy index.php) wskazujące noc 28 grudnia i w żaden sposób nie pokrywające się z czasem moich działań.
Zabezpieczenia i poszukiwania złośliwego kodu
Samo przywrócenie strony do życia nie rozwiązuje problemów webmastera. Atak hakerski nie został przeprowadzony bez przyczyny (haker w jakiś sposób musiał dostać się przecież na serwer aby podmienić pliki) - należało je więc zdiagnozować i wyeliminować. Ponadto, nieprawidłowości mogły dotyczyć nie tylko pliku .htaccess (co było ewidentne), ale również innych, mniej oczywistych miejsc. Pozostawienie strony w takim stanie z pewnością skutkowałoby regularnym nawrotom problemów.
Jako że moja strona wykonana jest w oparciu o popularny opensource'owy system CMS Joomla!, w celu zabezpieczenia strony przed ponownymi atakami oraz zdiagnozowania problemu, posłużyłem się metodami opisanymi na blogu nooblog.pl. A mianowicie:
- Wiedząc, że haker dostał się na na serwer z moją stroną (a więc może to zrobić ponownie), usunąłem dotychczas stosowane przeze mnie konto FTP i utworzyłem nowe (z nowymi danymi autoryzacyjnymi).
- To samo zrobiłem z kontem administratora w systemie CMS Joomla!.
- Zaktualizowałem stosowanego przeze mnie klienta FTP (zdarza się, że jego luki są wykorzystywane przez hakerów do wykradania loginów i haseł do kont FTP).
- Użyłem skryptu JAMSS do zdiagnozowania stanu witryny. Skrypt skanuje pliki Joomli! i informuje o potencjalnych nieprawidłowościach i zagrożeniach, wynikających z odnalezionych konkretnych fragmentów kodu (np. złośliwych umożliwiających hakerowi dostęp do witryny, osadzonych w core'owych plikach systemu). JAMSS wykazał kilkadziesiąt zainfekowanych obszarów, które mogłyby zostać ponownie wykorzystane przez hakera do przejęcia witryny. W takiej sytuacji stanąłem przed wyborem: mozolne czyszczenie plików strony ze złośliwego kodu bądź przywrócenie jej z ostatniej prawidłowej kopii zapasowej.
- Oczywiście wybrałem wariant drugi. Kopie zapasowe wykonuję po każdej aktualizacji witryny, a więc przywrócenie poprzedniej wersji nie wiązało się dla mnie z żadnymi stratami zawartości strony (wyjątkiem było niestety kilka utraconych komentarzy czytelników). Posiadaczom stron opartych na systemie Joomla! polecam dodatek Akeeba Backup, dzięki któremu jednym kliknięciem wykonamy kopię zapasową witryny - zarówno jej plików, jak i bazy danych. Jej przywrócenie jest niemal w stu procentach automatyczne i trwa może z 10 minut.
- Po przywróceniu strony z jej kopii zapasowej, zaktualizowałem system Joomla!, a także wszystkie zainstalowane rozszerzenia do najnowszej wersji (aktualizacje usuwają znane luki w zabezpieczeniach oprogramowania - a te są najczęstszą przyczyną ataków hakerskich na strony oparte na gotowych systemach CMS).
Narzędzia dla webmasterów Google - niepożądany użytkownik
Niestety, zainfekowanie samej strony to nie wszystko, na co stać hakerów. Okazuje się, że potrafią oni również przejąć kontrolę nad Narzędziami dla webmasterów Google (rozwiązania pozwalającego na zarządzanie relacjami pomiędzy stroną WWW, a wyszukiwarką Google oraz ich monitorowanie).
Myślę, że warto w tym miejscu wspomnieć o tym, dlaczego hakerzy atakują strony internetowe. Robią to przede wszystkim po to, aby pozyskać dodatkowy ruch dla własnych witryn - poprzez przekierowania (np. próba wejścia na InformatykęWFirmie.pl kończy się wizytą na XXX.com) czy też "pozyskiwanie" silnych linków w celu poprawy własnej pozycji w wynikach wyszukiwania (np. osadzenie linka XXX.com na jednej z popularnych podstron InformatykiWFirmie.pl). Oczywiście zdarza się i tak, że celem ataku jest po prostu dana strona internetowa (hakerom przyświeca np. chęć zablokowania jej zasobów).
O tym, że przejęto kontrolę nad kontem mojej strony w Narzędziach dla webmasterów Google, dowiedziałem się w zasadzie przypadkowo. Zalogowałem się w usłudze aby sprawdzić czy atak hakerski nie wpłynął negatywnie na pozycję InformatykiWFirmie.pl w wynikach wyszukiwania (na szczęście nie - zdecydowała o tym odpowiednio szybka reakcja - strona nie była dostępna jedynie przez kilka godzin). Przywitał mnie tam komunikat informujący o "nowym użytkowniku usługi". Jak to możliwe, że ktoś został administratorem mojego konta bez mojej wiedzy? Otóż w "Narzędziach dla webmasterów" konto dla danej strony może utworzyć każdy (gdybym zechciał mógłbym np. za chwilę utworzyć takowe dla Microsoft.com - mimo że nie jestem jej właścicielem). Oczywiście, Google weryfikuje czy rzeczywiście jesteśmy właścicielami danej witryny. Jednak jedną z opcji weryfikacji jest przesłanie na serwer strony WWW przygotowanego przez Google pliku. Hakerzy, mając dostęp do serwera, mogą bez problemu taką weryfikację przeprowadzić i administrować kontem cudzej witryny.
Obce konto szybko usunąłem, weryfikując następnie jakich zmian dokonano bez mojej wiedzy. Okazało się, że w usłudze Narzędzia dla webmasterów zaktualizowano mapę strony, zawierającą wpisy niepochodzące z InformatykiWFirmie.pl. Szczęśliwie Google nie zdążyło jeszcze jej w stu procentach uwzględnić - udało mi się anulować aktualizację. Mimo to, niektóre z podstron witryny prezentowane były w wynikach wyszukiwania Google w sposób następujący (co przekładało się oczywiście na liczbę odwiedzin - wszak nikt rozsądny nie kliknie w link opisany w języku chińskim):
Następnie, wywołałem ponownie proces indeksacji podstron witryny (już niezainfekowanej złośliwymi skryptami) za pomocą funkcji Indeksowanie -> Pobierz jako Google -> Pobierz i zrenderuj (stronę główną wraz ze stronami z linkami bezpośrednimi) - tak, aby boty Google pobrały i zapamiętały właściwe linki i opisy InformatykiWFirmie.pl. Następnego dnia chińskie znaczki zniknęły, a ja tym samym mogłem zamknąć temat przywracania strony do życia.
Lepiej zapobiegać niż leczyć
Mimo że udało mi się szybko uporać z atakiem hakerskim na moją stronę i ostatecznie nie przyniósł on długotrwałych negatywnych skutków, trudno cieszyć się z samego ataku - tj. tego, że do niego dopuściłem. Przyczyną była najprawdopodobniej luka w zabezpieczeniach stosowanej przeze mnie (nieaktualnej) wersji systemu CMS Joomla!, na którym oparty jest mój blog. Jest to tym bardziej smutne, że proces aktualizacji tego oprogramowania jest dziecinnie prosty, szybki i w pełni automatyczny (wystarczy jedno kliknięcie). Szczęście w nieszczęściu tworzyłem regularnie kopie zapasowe strony - w przeciwnym wypadku czekałoby mnie mozolne czyszczenie plików witryny ze złośliwych skryptów - bardzo pracochłonne, a często i nieskuteczne.
Atakom hakerskim, które mogą dotknąć każdą witrynę - niezależnie od jej wielkości i popularności, zdecydowanie łatwiej przeciwdziałać niż likwidować ich ewentualne skutki. Dlatego dbajmy o regularne aktualizacje oprogramowania, na którym oparte są nasze witryny i za pomocą którego przesyłamy dane na serwer WWW. Pamiętajmy również o odpowiedniej polityce bezpieczeństwa - tj. niestandardowych loginach i silnych hasłach do paneli administracyjnych i FTP. W końcu nie zapominajmy o częstych kopiach zapasowych strony internetowej - nigdy nie wiadomo kiedy mogą uratować nas przed utratą efektów naszej często wieloletniej pracy.
Komentarze (4)