Blog domeniarza

Niedawno jedna z moich stron- blog oparty o silnik WordPress- padła ofiarą ataku. Włamywaczowi udało się zrobić kilka rzeczy, które mnie dość mocno zaniepokoiły- a co najgorsze, musiałem spędzić sporo czasu, by dojść do tego JAK TO SIĘ STAŁO- jak mu się ten numer udał, mimo że blog był dość dobrze zabezpieczony???

1. Środowisko
2. Modyfikacje dokonane przez włamywacza
3. Analiza modyfikacji
4. Jak dokonano włamania
5. Naprawa

Środowisko

Zgodnie z regułami gry, regularnie dbałem o aktualizacje WordPress’a, zainstalowanych wtyczek i skórki. Wszystkie nieużywane komponenty były wywalane z bloga, by nie korciło kogoś eksperymentowanie np. z nieaktywną skórką czy wtyczką.

Logowanie do bloga było zabezpieczone m.in. przez mechanizm obrazków z losowymi literkami, hasła nasto-znakowe były generowane losowo, zawierając litery, cyfry, znaki specjalne… Zabezpieczenie obrazkiem ma swoją istotną zaletę- widziałem nie raz w logach całe serie prób logowania się metodą brute-force, w ciągu sekundy można wysłać do serwera nawet kilka takich żądań- bywa, że w ciągu godziny atakujący testuje parę tysięcy haseł. Przy zabezpieczeniach z SSL, z obrazkami- gwałtownie spada ilość prób i tempo tych prób. Zainteresowanym polecam przyjrzenie się temu tematowi- są np. wtyczki, które po kilku nieudanych próbach robią czasową blokadę IP, albo wprowadzają wydłużający się czas między kolejnymi próbami logowania.

Skórka została dobrana tak, by nie zawierała pliku “thumb.php” ani “timthumb.php” (wykorzystywane do generowania miniaturek), które dawno i wielokrotnie były kompromitowane i które są właściwie głównie wrzodem…. Wtyczki były dobrane wg oceny dbania o nie przez autorów i popularności, sprawdzałem je też we własnym zakresie pod kątem jakichś dziwnych skryptów, które mogłyby ułatwić komuś zrobienie włamu. Ponadto, w katalogu głównym bloga – jak w przypadku wszystkich stron i blogów, którymi zarządzam- zmodyfikowałem plik “.htaccess”, dodając sporo reguł zabezpieczających blog- choćby takie, które nie pozwalają by jakikolwiek plik bloga (pliki PHP, pliki JS) mógł ściągnąć jakąkolwiek treść z zewnątrz- spoza bloga. W dużej mierze przydatne okazały się artykuły na WordPress.org poświęcone bezpieczeństwu blogów, a także- co muszę przyznać z dużym naciskiem- artykuły na PerishablePress.Com- szczególnie te związane z budową “firewall’a” dla stron w oparciu o pliki “.htaccess” (zachęcam do zerknięcia do artykułu “5G Blacklist 2012“, a także “Protect Your Site with a Blackhole for Bad Bots“)

Modyfikacje dokonane przez włamywacza

Pomimo to- dostałem wiadomość od firmy hostingowej, iż system antywirusowy znalazł “niebezpieczne pliki” w obrębie bloga. (Całe szczęście, firma hostingowa ma dobre narzędzia do skanowania plików, regularne skanowanie plików w poszukiwaniu wirusów w PHP/JS i innych typach plików to ostatnia deska ratunku). Natychmiast zabrałem się za sprawdzenie, co to za pliki, gdzie, dlaczego, kiedy, kto……

Włamywacz w głównym katalogu, oraz w kilku innych katalogach zmodyfikował pliki “.htaccess“. Dla tych którzy nie wiedzą- pliki te zawierają kluczowe dyrektywy dla serwera WWW. Pliki “.htaccess” mają bardzo duże znaczenie dla bezpieczeństwa strony.

Do plików .htaccess dodano klauzule:

< IfModule mod_php5.c>
 php_value auto_append_file "google_verify.php"
< /IfModule>

< IfModule mod_php4.c>
 php_value auto_append_file "google_verify.php"
< /IfModule>

 Te klauzule “auto_append_file” są niezwykle niebezpieczne- oznaczają, że DO KAŻDEGO PLIKU dołączany jest na końcu plik “google_verify.php“. Haker nie musi modyfikować istniejących plików/skryptów, po prostu dołącza złośliwy kod na każdej naszej stronie, elemencie…

Analiza modyfikacji

Oczywiście, w miejscach w których zmieniono “.htaccess” dodano plik “google_verify.php”. I nie był to bynajmniej plik “hello ”- to był plik zawierający dość mocno zamaskowany kod skryptu. Nie jestem programistą- próbowałem zdekodować ten tekst i zrozumieć, jak działa, ale zmarnowałem sporo czasu i do niczego nie doszedłem. W końcu zwróciłem uwagę na interesującą rzecz- na komentarze. Były po łacinie…

Początkowo myślałem, że zabiorę się za ich tłumaczenie, bo może one opisują elementy kodu infekującego przeglądarki. Ale natychmiast po wpisaniu fragmentu komentarza w wyszukiwarce trafiłem na artykuł, który wszystko wyjaśnił.

Wpisałem tą frazę do Google:

google_verify.php  //Mauris gravida, libero ut tempor ultricies, ante erat blandit dui, vestibulum convallis ligula lacus et metus. Duis quis nunc justo, gravida sem

I od razu pierwsza pozycja w wynikach. Na stronie Unmask Parasites. Blog. opisano podobne przypadki. Autor wyjaśnia, że łaciński tekst pochodzi z generatorów typu Lorem Ipsum- więc jasne jest, że tłumaczenie komentarzy w skrypcie jest stratą czasu.

Poza tym, na wspomnianej stronie opisana jest zasada działania skryptu doklejanego do zhakowanej strony (skrypt próbuje infekować przeglądarkę odwiedzających – w udanych wypadkach zamienia komputer odwiedzającego w zombie i element botnetu, wykorzystywanego albo do kolejnych włamań albo np. do generowania maili).

W jednym z katalogów – poza plikiem infekującym przeglądarki- wrzucono skrypt PHP z backdoor‘em- tworzący shell’a (czyli wejście do systemu bez wiedzy/kontroli administratora, pozwalający na wykonanie każdego polecenia dostępnego na serwerze z poziomu linii komend).

W pliku z backdoor’em na początku skryptu jest komentarz:

# Web Shell by oRb

 Analiza backdoor’a sama w sobie była interesującym zajęciem. To nie pierwszy backdoor jakiego widziałem, muszę jednak przyznać, że na tle innych ten jest dość zaawansowany i daje bardzo duże możliwości włamywaczowi.

Pliki “.htaccess” i “google_verify.php” były w kilku egzemplarzach- w głównym katalogu strony, w katalogach trzech różnych wtyczek, w dwóch innych katalogach w obrębie bloga. Plik z backdoor’em / shell’em był jeden.

I ważna informacja, jaką muszę tu podać- pliki, które zostały dodane- miały bieżące daty, z momentu wgrywania ich na serwer. To ważny element- gdyby włamywacz zmienił po swojej akcji daty wgranych plików na takie daty/godziny, jak pozostałe pliki w katalogach- wyszukanie tych plików byłoby znacznie trudniejsze.

Poza tym- niczego więcej nie zmieniono. W zasadzie nie było konieczności- jak wyżej napisałem- mechanizm “auto_append_file” po prostu dokleja wszędzie plik “google_verify.php”, włamywacz nie musi niczego więcej zmieniać. A backdoor jest potrzebny- na wszelki wypadek, gdyby trzeba było ponownie infekować stronę (dla ułatwienia w przyszłości), albo gdyby włamywacz chciał rozszerzyć zakres swojej działalności – użyć serwera do innych celów poza atakowaniem przeglądarek odwiedzających osób. Np. do mailingu, do zamiany serwera w warez/składnicę nielegalnych czy zainfekowanych plików etc.

Jak dokonano włamania

Z grubsza wiedziałem już co zostało zmienione, najwięcej czasu spędziłem na odkrycie tego “JAK“. Przekopywałem się przez pliki “.htaccess”, WordPress’a, wtyczek, skórki- ale niczego nie znalazłem, żadnej luki pozwalającej na tak poważne modyfikacje. Zalinkowany wyżej artykuł doczekał się niedawno aktualizacji, w artykule z 18 lutego Autor wskazuje, iż popularną drogą do infekcji jest włam przez FTP. No i…. mamy go!

Nie wiem czemu nie wpadłem na to wcześniej. To prawdopodobnie zbyt duże zaufanie do siebie lub innych, albo za małe przywiązanie wagi do tej drogi dostępu do serwera- to dobra nauczka i dla mnie, i dla Czytelników- każdy kanał dostępu do serwera trzeba sprawdzić, sprawdzać, sprawdzać…. Obejrzałem logi dla wszystkich kont FTP założonych na serwerze i okazało się, że jedno z nich, nazwijmy je ‘kontraktor’, było w użyciu dokładnie w momencie, gdy zostały wrzucane złośliwe pliki na serwer. Sprawdziłem IP z jakich logowano się na to konto – adres pochodził z sieci kablowej w USA, w Pensylwanii. Oczywiście, prawdopodobnie z jakiegoś komputera typu zombie. Jak można się domyślić, użytkownik konta ‘kontraktor’ nie był w tym czasie w USA, w stanie Pensylwania…

Niestety pełnych logów z FTP nie mam- nie mam informacji o nieudanych próbach logowania. Nie wiadomo więc, czy logowanie nastąpiło po jakimś czasie, po dziesiątkach prób i ataków typu brute-force (lub wykorzystaniu jakiejś luki w serwerze FTP), czy może na komputerze ‘kontraktora’ był trojan przechwytujący hasła- a jak grupa hakerów uzyskała login/hasło do nieznanego im wcześniej serwera FTP- po prostu “w ciemno” zalogowała się i uruchomiła odpowiednie skrypty przejmujące kontrolę nad nieznaną im stroną. Informacja jak uzyskano wejście przez FTP byłaby interesująca. Na razie nie wiem jednak tego, zabezpieczenie istniejących kont FTP i ograniczenie grona osób, które korzystają z tej formy dostępu, jest jedynym w tej sytuacji rozwiązaniem.

Naprawa

Zanim natrafiłem na artykuł wykonałem już parę kroków, tj:

• usunięcie z plików “.htaccess” dyrektyw “auto_append_file”
• usunięcie plików “google_verify.php”
• usunięcie pliku z backdoor’em / shell’em
• w każdym katalogu- na wszelki wypadek- zmieniłem uprawnienia dla plików “.htaccess”, “index.php” lub “index.html”
• w katalogach można wyłączyć przeglądanie ich zawartości w przeglądarce (dyrektywa “Options All -Indexes” w pliku “.htaccess”) – dyrektywa wyłącza możliwość wyświetlenia w przeglądarce listy plików w danym katalogu
• pliki .htaccess można dodatkowo zabezpieczyć przed modyfikacją ich przez serwer WWW, dyrektywami:

  # SECURE HTACCESS
  <Files .htaccess>
   Order allow,deny
   Deny from all
  </Files>
  

• oczywiście, kolejną sprawą po zapoznaniu się z artykułem było zablokowanie konta FTP dla ‘kontraktora’- i na wszelki wypadek- zmiany hasła na jakieś ekstremalnie skomplikowane. Jeśli w przyszłości będzie potrzebny dostęp przez FTP- opracuję jakiś system haseł jednorazowych (OTP) lub inną formułę zabezpieczającą ten kanał dostępu.

W artykule (w aktualizacji z 18 lutego) są opisane kroki potrzebne do przywrócenia strony do jej oryginalnego stanu. Jest tam też sporo innych przydatnych informacji dotyczących włamań przy użyciu metody, z którą właśnie się zetknąłem.

I na koniec- podsumowując: każdy kij ma dwa końce. Włamanie to poważny problem. Możemy stracić ważne dane, ważną treść nad którą pracowaliśmy latami. Stronę, która ma wysoki PR i jest dobrze rozpoznawana w Internecie. Może skończyć się zablokowaniem usług, z których korzystamy- firma hostująca może nam podziękować bez zwrócenia pieniędzy za niewykorzystany okres świadczenia usług. W końcu łamiemy zasady, mamy wirusy na stronach etc. Z drugiej strony- to nauka, walka o przetrwanie… jak w rozprawie Darwina o ewolucji gatunków- przetrwają ci, którzy lepiej się dostosują do sytuacji. Dotyczy to także walki hacker-Ty i Twoje usługi. Oczywiście, możesz też zrzucić obowiązki na jakąś firmę zewnętrzną, samemu dbając tylko o treść na blogu- resztę (czyli kwestie bezpieczeństwa) przerzucając na innych. To jest pewne wyjście, ale może kosztować jakąś kwotę pieniędzy.

I jeszcze ostatnia, bardzo ważna uwaga- ten typ włamania nie jest związany konkretnie z WordPressem. To może dotyczyć KAŻDEJ strony, wykorzystującej PHP, do której można dostać się albo przez FTP, albo przez wykorzystanie jakiejś luki i wgranie odpowiednich plików na serwer.

Jeśli ktoś spotkał się z podobnym typem włamu/mechanizmem/skryptami- proszę o kontakt albo uwagi w komentarzach pod postem.