30.06.
2012

Na sledi vdora v spletno stran

Pri izdelavi spletnih strani je pomembno, da se posvetimo tudi varnostnemu vidiku. Še posebej pri uporabi odprtokodnih CMS sistemov, kot so Joomla, WordPress in podobni. Redno izvajamo varnostne kopije podatkov (baze in datotek), nadgradnje sistema in nagradnje vtičnikov.

Posebno pozornost moramo nameniti izbiri vtičnikov (plugini, komponente). Nekateri so spisani precej površno in lahko predstavljajo resno varnostno grožnjo. Že z minimalnim poznavanjem tehnik vdiranja lahko napadalec izkoristi kakšno splošno znano varnostno pomanjkljivost in pridobi dostop do vsebin na spletni strani. Pred namestitivjo vtičnika je priporočljivo preveriti, če nima kakšnih znanih ranljivosti – z iskanjem po Googlu v stilu “imevtičnika exploit”, “imevtičnika vulnerability” ali s pregledom strani s seznami “exploitov”.

Kljub upoštevanju dobrih praks včasih napadalec pridobi dostop do datotek na vašem strežniku. Takrat je dobro poznati nekaj osnovnih metod zaznavanja in odstranjevanja zlonamerne kode. Možnosti za odkrivanje in odstranitev je ogromno, spodaj opisani način je le eden izmed možnih. Ima svoje dobre lastnosti in tudi pomanjkljivosti. Kdo drug bi se odkrivanja lotil povsem drugače, zato ne morem trditi, da je ta način dober ali slab. But it got the job done :)

Opisani primer je posledica slabe varnosti   na strežniku, kjer je prišlo do vdora in pridobitve korenskega dostopa. Napadalec je v namestitve WordPress in Joomla CMS vstavil zlonamerno kodo, ki je Googlu pošiljala spremenjeno vsebino spletne strani z namenom pridobiti povratne povezave za optimizacijo spletne trgovine.

Kako je potekalo odkrivanje vdora?

1. Obvestilo s strani Google webmaster tools

Večina naših spletnih mest je vključena v storitvi Google Webmaster tools in Google Analytics. Poleg očitnih prednosti s stališča analiz obiska in optimizacije ima Google Webmaster tools tudi vgrajen skener zlonamerne kode. Ta je zaznal problematično vsebino na spletni strani in mi poslal obvestilo:

Ob obisku problematičnega URL naslova je bilo videti, da je pri vdoru v stran nameščena zlonamerna koda. Ta je pod določenimi pogoji namesto prave vsebine obiskovalcu poslala prispevek, ki je prikazoval podatke o torbicah s Kitajske in imel povezave na spletno trgovino. Žal je Google že indeksiral to vsebino in jo tudi prikazoval med iskalnimi zadetki. Poleg imena strani je v zadetkih izpisovalo, da je stran morda okužena.

2. Prvi koraki po vdoru

Kot sem kasneje izvedel od ponudnika, je do vdora prišlo na neki drugi spletni strani, ki je gostovala na istem strežniku. Napadalci so s pridobitvijo korenskega dostopa lokalno okužili vse račune z Joomla ali WordPress CMS sistemi.   Ob zaznavi vdora te informacije žal še nisem imel, zato sem reagiral tako, kot da bi bil izvor vdora na naši spletni strani.

Najprej sem o vdoru obvestil ponudnika gostovanja. Nastavil sem .htaccess datoteko, da sem začasno do strani imel dostop le s svojega IP naslova.

# Vsebina .htaccess datoteke. namesto 111.222... se vpiše lasten IP naslov
order deny,allow 
deny from all 
allow from 111.222.333.444

Sledila je menjava vseh gesel za spletno stran (ftp, baze, shell, cpanel). Glede na to, da imam za gesla vedno vsaj 9 različnih znakov, niti ni bilo velike bojazni, da bi jih lahko dešifrirali. Vseeno pa je to priporočljivo. Sploh zato, ker je že Joomlino geslo za bazo v plaintext obliki.

3. Odkrivanje spremenjenih datotek

Preden stran spet odprem za promet, sem moral odkriti izvor vdora, odstraniti zlonamerno kodo in zaščititi sistem. Odločil sem se za odstranjevanje preko terminalskega dostopa do računa gostovanja. Pri odkrivanju zlonamerne kode so v pomoč predvsem ukazi za iskanje spremenjenih datotek in dnevniški zapisi na strežniku.

Najprej sem pogledal strežniške dnevnike, da bi odkril, kdaj je prišlo do vdora. V Webmaster Tools je bil napisana URL povezava, katero sem potem iskal v strežniških datotekah (http.log) in tam tudi našel prvo pojavljanje (podobnega) URLja. Zanimivo je, da je takrat ob obisku URLja vrglo 404 error. Kasneje so se pokazale kode 200 (OK).

Zdaj sem vedel, kdaj približno je na stran začel prihajati promet, ki je izvajal napadalčevo kodo. Zato sem s pomočjo ukaza find poiskal datoteke, ki so bile spremenjene v bližini tega časa.

$find . -type f -cmin -XXX

Kjer je XXX število minut od trenutnega časa do časa malo pred prvim pojavom zahtevkov. Na seznamu sta bili 2 datoteki, ki sta bili spremenjeni. Datoteke te spletne strani se le redko spreminjajo, zato je bilo iskanje bistveno olajšano.

Datoteka application.php je sistemska datoteka Joomla CMS in je bila spremenjena brez meni znanega razloga. Druga datoteka je za ime uporabljala naključen niz znakov, kar je pogosta praksa datotek, ki vsebujejo zlonamerno kodo. Vsebina datotek je to potrdila.

Zapisal sem si datum spremembe oz. kreiranja obeh datotek, odstranil @include_once zapis iz application.php in izbrisal datoteko z zlonamerno kodo. Po poskusu obiska problematičnega URL naslova sem dobil 404 error, kar je pomenilo, da sem iz Joomle odstranil skripto za prikaz prirejene vsebine. Žal pa s tem nisem odstranil vse napadalčeve kode. Pregledal sem dnevniške datoteke ob času nastanka obeh datotek, a nisem dobil nič omembe vrednega.

4. Posodobitev CMS sistema in skeniranje

Na strežnik sem naložil najnovejšo različico CMS sistema Joomla in posodobil vse vtičnike. Datotekam in mapam sem dodelil pravilne pravice. Pregledal sem cron, ftp in shell uporabnike in seznam poddomen – stvari, ki bi jih napadalec lahko spremenil v svojo korist. Vse je bilo videti OK.

Preko terminalskega dostopa sem na strežnik naložil ClamAV antivirus. Ta je zaznal še eno okuženo datoteko, in sicer web shell skripto za prikrit dostop do   računa gostovanja, shranjeno v  page.php. Skripta je imela spremenjen datum kreiranja datoteke, zato je z ukazom find na začetku nisem mogel najti.

Zanimivo je tudi, da nikjer v logih (access, http, error) ni bilo najti dostopov do te skripte. Morda so jo napadalci pustili le kot stranska vrata, v primeru da bi odstranil le prej omenjeni datoteki. Tudi to datoteko sem odstranil. Prepričan, da je stran zdaj čista, sem popravil .htaccess datoteko in odprl dostop obiskovalcem.

Dnevniške datoteke sem pregledal za sumljivimi POST/GET requesti okoli datuma nastanka page.php, preko katerih bi napadalci lahko pridobili dostop, vendar neuspešno. To pa zato, ker niso vdrli preko varnostne luknje na tej strani, ampak so datoteke lokalno prenesli v uporabniški račun. Če bi vdrli preko varnostne luknje na tej strani, bi se to po vsej verjetnosti videlo v dnevniških datotekah (ni pa nujno).

5. Še zadnji koraki

Redno preverjanje dnevniških datotek je pokazalo, da je stran še vedno dobivala zahtevke po spremenjeni vsebini. Vsi zahtevki so vrnili kodo 404 (not found), kar pomeni, da je stran čista. Googlu sem v Webmaster tools poslal “reconsideration request” o očiščeni strani, ki so ga v roku 48 ur potrdili. Ponudnik gostovanja je sporočil, da so odpravili varnostne pomankljivosti in odstranili strani, ki so bile izvor vdora. Zagotovili so, da so nastavitve sedaj postavljene tako, da je strežnik bolj varen.

Vseeno pa nisem želel pustiti česarkoli naključju. Povsem možno je, da se vdor ponovi, čeprav zagotavljajo večjo varnost. Glede na to, da ima ta stran izredno malo sprememb na datotečnem nivoju, sem se odločil v CRON dati ukaz, ki mi bo javljal spremembe datotek. Ukaz se zažene vsako uro in v kolikor dobi kakšno spremembo v mapi home, mi na mail pošlje izpis spremenjenih datotek.

find ~/ -type f -cmin -60

Prav tako sem v cron dodal zapis, ki enkrat dnevno posodobi Clam antivirus in opravi skeniranje datotek.

Stran zdaj spet deluje brez težav. Na srečo napadalci niso povzročili večje škode. Varnostne kopije se sicer redno izvajajo in shranjujejo na varno lokacijo, tako da tudi v primeru izbrisa podatkov večje škode nebi bilo.

komentarja 2

Dodaj komentar
  1. Pa si lahko prepričan, da je po taki stvari strežnik 100% čist?

    • Ne moreš bit kar prepričan, lahko pa preveriš par stvari in potem trdiš, da je strežnik očiščen. Fajn je dobro preverit log datoteke (access log, ftp log, error log), crontab (da ni vdiralec pustil kakih čudnih opravil), narediti scan datotek z antivirusom, ter seveda zamenjat geslo za dostop. Naprej od tu pa je vse odvisno od tega, kaksen dostop do streznika imas in koliksno je tvoje znanje upravljanja z njim. V najslabsem primeru lahko prosis skrbnika streznika, naj pregleda sistem. Drugace pa se tudi sam lotis in preverjas procese, povezave, odprte porte, ipd.