Hakovana WooCommerce prodavnica, prvi koraci u čišćenju
← Blog

Hakovana WooCommerce prodavnica: kako smo je očistili

Ivan Pantić

Ukratko: vlasnik prodavnice javio se jer su mu kupci prijavili da ih sajt preusmerava na stranu stranicu. Prodavnica je njemu izgledala normalno. Našli smo backdoor u uploads folderu, izmenjen fajl teme, zakazan zadatak koji je sve vraćao i jedan administratorski nalog koji niko nije napravio. Ulaz je bio zastareo dodatak za dostavu. Čišćenje je trajalo nešto manje od dana, prodavnica nije bila ugašena, nijedna porudžbina nije izgubljena.

Ovaj tekst je prikaz stvarne intervencije. Detalji koji bi mogli da otkriju o kom je sajtu reč su izmenjeni, jer klijent na to ima pravo. Sve tehničko je opisano onako kako se stvarno odigralo, jer verujemo da je konkretan slučaj korisniji od uopštenih saveta.

Kako je počelo

Poziv je stigao kasno popodne. Vlasnik prodavnice je rekao da su ga dva kupca u istom danu pitala zašto ih njegov sajt vodi na neku stranu stranicu sa reklamama. On je odmah otvorio prodavnicu na svom računaru i sve je radilo savršeno. Naslovna se učitala, proizvodi su bili tu, korpa je radila. Pomislio je da su kupci pobrkali sajtove.

Onda ga je pozvao i treći.

Hakovana WooCommerce prodavnica retko odaje problem svom vlasniku, i baš to je najteži deo.

Ovo je najčešći način na koji vlasnik sazna da ima problem, i najčešći razlog zašto ne reaguje odmah. Kad hakovana WooCommerce prodavnica nastavi da izgleda ispravno vlasniku, lako je poverovati da je greška kod nekog drugog. A upravo to je i namera onoga ko je kod ubacio.

Zašto vlasnik ne vidi ono što vide kupci

Maliciozni kod za preusmeravanje skoro nikad ne radi za svakoga. Pre nego što odluči da li će nekoga preusmeriti, obično proveri nekoliko stvari: odakle je posetilac došao, da li je na mobilnom telefonu, i da li je ulogovan u administraciju.

Vlasnik prodavnice je gotovo uvek ulogovan, otvara sajt direktnim kucanjem adrese, i radi sa računara. To je tačno kombinacija koju maliciozni kod preskače. Kupac koji dolazi sa pretrage, sa telefona, izlogovan, je tačno ono što taj kod traži.

Zato prva stvar koju smo tražili od klijenta nije bila lozinka nego snimak ekrana od jednog od kupaca. Time smo za pet minuta imali potvrdu da problem postoji i grubu predstavu kuda vodi preusmeravanje.

Backdoor fajl skriven u uploads folderu među slikama proizvoda

Prvi sat, pre nego što smo bilo šta dirali

Postoji poriv da se odmah krene u brisanje. Kod prodavnice je taj poriv posebno opasan, jer se u bazi nalaze porudžbine, kupci i plaćanja. Jedan pogrešan potez tu ne znači izgubljen sadržaj nego izgubljen novac i pravni problem.

Puna kopija, uključujući zaraženu

Prva stvar je bila kompletna kopija fajlova i baze, u zatečenom stanju. Da, zaražena. Ta kopija služi kao osiguranje ako nešto tokom čišćenja pođe naopako, i kao dokazni materijal ako kasnije treba rekonstruisati šta se desilo i kada.

Kod prodavnice ovo ima i dodatnu težinu. Ako bi se ispostavilo da su podaci kupaca procurili, ta kopija je jedini način da se utvrdi šta je tačno bilo u bazi u trenutku upada.

Zaustavljanje štete, ali bez gašenja prodavnice

Klijent je pitao da li da ugasi sajt. Nismo preporučili. Prodavnica koja je nedostupan dan gubi prodaju, gubi pozicije u pretrazi, i šalje lošu poruku kupcima koji su već poručili.

Umesto toga smo prvo neutralisali sam mehanizam preusmeravanja, što je zaustavilo štetu prema kupcima, a prodavnica je nastavila da radi dok smo tražili ostatak. To je moguće samo ako se prvo tačno utvrdi gde je kod, pa je ovaj korak zapravo došao posle sledećeg.

Utvrđivanje obima

Pre čišćenja treba znati koliko je duboko. Proverili smo da li se preusmeravanje dešava na svim stranicama ili samo na nekima, da li pogađa sve posetioce ili samo deo, i da li na istom hosting nalogu postoje drugi sajtovi.

Poslednje pitanje se često preskoči, a bitno je. Ako na istom nalogu stoji još sajtova, infekcija često pređe sa jednog na drugi, i čišćenje samo jednog znači da će se za nedelju dana sve vratiti. U ovom slučaju je na nalogu bio još jedan stariji sajt, i on je takođe bio zahvaćen.

Šta smo našli

Svaka hakovana WooCommerce prodavnica koju smo do sada radili imala je više od jednog ulaza.

Nalazi su bili raspoređeni na pet mesta. To nije neobično. Napadači po pravilu ostavljaju više od jednog ulaza, računajući da će prvi biti pronađen.

PHP fajl sakriven među slikama proizvoda, lažni admin i zakazani zadatak

Backdoor u uploads folderu

Folder wp-content/uploads je predviđen za slike proizvoda, dokumente i medije. Tamo nikad ne bi trebalo da postoji fajl sa ekstenzijom .php. Našli smo ga u podfolderu sa slikama od pre dve godine, sa imenom koje je ličilo na sistemski fajl.

Sadržaj je bio jedan dugačak niz slova i brojeva bez ijedne prepoznatljive reči, koji se dekodira tek u trenutku izvršavanja. To je i način sakrivanja i najpouzdaniji znak da nešto nije u redu, jer legitiman kod nema razloga da bude nečitljiv.

Izmenjen fajl aktivne teme

U fajlu koji se učitava na svakoj stranici bila je dodata jedna linija, na samom kraju, iza više praznih redova. Da je neko otvorio taj fajl i pogledao ga bez skrolovanja do dna, ne bi video ništa.

Ta linija je bila sam mehanizam preusmeravanja. Ona je proveravala odakle posetilac dolazi i sa kog uređaja, pa je samo deo posetilaca slala dalje.

Zakazan zadatak koji je sve vraćao

Ovo je deo koji objašnjava zašto se infekcija često vraća posle naizgled uspešnog čišćenja. U WordPress sistemu zakazanih zadataka postojao je unos koji je na svakih nekoliko dana ponovo postavljao backdoor fajl, ako bi nestao.

Da smo obrisali samo fajl i temu, prodavnica bi bila čista nekoliko dana, a onda bi se sve vratilo. Vlasnik bi zaključio da čišćenje ne radi.

Administratorski nalog koji niko nije napravio

U listi korisnika stajao je nalog sa imenom koje je delovalo kao da pripada nekom dodatku. Datum registracije je bio u periodu kad se niko iz firme nije prijavljivao. Mejl adresa vezana za nalog nikad nije viđena.

To je bila rezerva za slučaj da sve ostalo bude uklonjeno. Sa punim administratorskim pravima, napadač bi se vratio kad god poželi, bez obzira na promenjene lozinke.

Ubačen kod u bazi podataka

Poslednji nalaz je bio u samoj bazi, u poljima koja se učitavaju pri svakom zahtevu. Ovo mesto se najčešće previdi, jer nije fajl. Ko čisti samo fajlove, ostavlja ovo netaknuto i sve se vraća čim se stranica ponovo otvori.

Kako je napadač ušao

Ovo pitanje je važnije od pitanja šta je ostavio. Ako se ulaz ne zatvori, sledeći upad je pitanje vremena, a ne verovatnoće.

Uzrok je bio dodatak za obračun troškova dostave, koji nije ažuriran gotovo dve godine. Za tu verziju je postojala javno objavljena ranjivost, a od objave do iskorišćavanja obično prođe svega nekoliko dana, jer automatizovane skripte redom proveravaju sajtove tražeći baš to.

Vlasnik nije ažurirao taj dodatak iz razloga koji je potpuno razumljiv i koji čujemo stalno: jednom je ažurirao nešto drugo, prodavnica je pukla, i od tada se plašio da dira bilo šta što radi. To je česta i skupa zamka. Strah od ažuriranja košta više nego povremeni problem sa nekompatibilnošću, jer se ranjivosti gomilaju.

Čišćenje korak po korak

Redosled je bitan koliko i sami koraci.

Lista koraka čišćenja dok korpa ostaje dostupna kupcima

Uklanjanje mehanizma preusmeravanja

Prvo je uklonjena linija iz teme, čime je zaustavljena šteta prema kupcima. Od tog trenutka nijedan posetilac više nije bio preusmeravan, iako čišćenje nije bilo završeno.

Uklanjanje backdoor fajlova i zakazanog zadatka

Zatim su uklonjeni fajl iz uploads foldera i zakazani zadatak, i to zajedno. Redosled je važan: da je prvo obrisan fajl a zadatak ostao, fajl bi se vratio.

Čišćenje baze

Ubačeni kod je uklonjen iz baze, uz proveru da nije ostao i u drugim tabelama. Kod prodavnice ovo traži dodatnu pažnju, jer se u bazi nalaze i podaci o porudžbinama koje ne smeju biti dirnute.

Uklanjanje lažnog naloga i poništavanje sesija

Lažni administratorski nalog je uklonjen, a zatim su poništene sve aktivne sesije i promenjeni bezbednosni ključevi. Ovo je korak koji se najčešće preskoči. Promena lozinke ne izbacuje nekoga ko je ranije ukrao kolačić prijave. Poništavanje sesija ga izbacuje.

Zatvaranje ulaza

Ranjivi dodatak je ažuriran, a nekoliko dodataka koji se uopšte nisu koristili je uklonjeno. Neaktivan dodatak sa ranjivošću je i dalje ranjiv, jer njegovi fajlovi i dalje stoje na serveru.

Promena svih lozinki

Administratorski nalozi, baza podataka, hosting panel i FTP pristup. Dok je backdoor bio aktivan, napadač je mogao da izvuče sve te podatke, pa ih treba tretirati kao kompromitovane bez obzira na to što nema dokaza da jeste.

Čišćenje drugog sajta na istom nalogu

Na kraju je očišćen i stariji sajt sa istog naloga, jer bi inače bio izvor ponovne infekcije.

Zašto je prodavnica poseban slučaj

Kod hakovane WooCommerce prodavnice čišćenje se planira drugačije nego kod običnog sajta.

Čišćenje prodavnice nije isto što i čišćenje običnog sajta, i to iz nekoliko razloga koje vredi razumeti pre nego što se bilo šta krene.

U bazi su tuđi podaci

Imena, adrese, brojevi telefona, istorija porudžbina. Ako je napadač imao pristup dovoljan da postavi kod, imao je pristup i tome. Kod ovog slučaja smo prošli kroz logove i utvrdili da nema traga masovnom izvlačenju podataka, ali to je pitanje koje se mora postaviti i na koje se mora odgovoriti, ne pretpostaviti.

Ako se ispostavi da je do curenja došlo, obaveštavanje kupaca nije stvar pristojnosti nego može biti i zakonska obaveza. To je razgovor koji se vodi trezveno, a ne u panici.

Porudžbine se dešavaju dok čistite

Obična stranica može da stoji u režimu održavanja sat vremena bez posledica. Prodavnica ne može. Zato se čišćenje planira tako da prodavnica ostane dostupna, a to znači pažljiviji rad i više provera posle svakog koraka.

Plaćanje se ne sme dirati

Dodaci za plaćanje su najosetljiviji deo. Njihovo ažuriranje usred čišćenja može da prekine tok naplate. Zato se prvo čisti, pa se tek posle, u kontrolisanom trenutku, radi ažuriranje onoga što dodiruje plaćanje, uz proveru probnom kupovinom.

Greške koje smo videli kod drugih pre nego što nas pozovu

Vlasnici prodavnica često pokušaju sami pre nego što se jave, što je razumljivo. Evo šta u praksi najviše odmogne, i zašto.

Vraćanje bekapa naslepo

Prvi refleks je vratiti prodavnicu na stanje od pre nedelju dana. Problem je dvostruk. Ako je infekcija starija od tog bekapa, vraća se zaražena prodavnica. A kod prodavnice se vraćanjem baze brišu i sve porudžbine nastale u međuvremenu, što je stvarna finansijska i pravna šteta.

Kod prodavnice se bekap vraća tek kad se zna tačan datum upada, i skoro nikad se ne vraća cela baza.

Brisanje svega što deluje sumnjivo

Fajl koji vam deluje čudno može biti deo dodatka koji koristite. Brisanjem gubite i mogućnost da vidite kada je postavljen i kroz šta je ušlo. Uvek prvo pogledati, pa tek onda uklanjati.

Instaliranje više bezbednosnih dodataka odjednom

Nijedan bezbednosni dodatak instaliran posle upada neće ukloniti kod koji je već tu. A na prodavnici, koja je ionako teža od običnog sajta, nekoliko takvih dodataka odjednom primetno usporava rad i ume da uđe u sukob sa dodacima za plaćanje.

Selidba na drugi hosting

Selidba zaražene prodavnice prenosi problem na novi server, a usput se gube logovi koji su bili najkorisniji trag. Prvo očistiti, pa tek onda razmišljati o selidbi ako je uopšte potrebna.

Prvih 48 sati posle čišćenja

Period odmah posle čišćenja je onaj u kom se vidi da li je posao stvarno završen. Zakazani zadaci i rezervni ulazi obično imaju odloženo dejstvo, pa se propust ne primeti odmah nego za nekoliko dana.

Kod ove prodavnice smo prvih 48 sati pratili nekoliko stvari. Da li se pojavljuje nov fajl koji nije bio tu, da li se menja neki fajl koji ne bi trebalo da se menja, da li se pojavljuje nov korisnik, i da li se u bazi menja nešto van uobičajenog toka porudžbina.

Ništa se nije pojavilo, što je bio prvi ozbiljan znak da su svi ulazi zaista zatvoreni. Da se pojavilo, značilo bi da je negde ostao još jedan mehanizam koji smo propustili, i tražili bismo dalje.

Vlasniku smo preporučili i da u tom periodu ne radi veće izmene na prodavnici. Razlog je praktičan: ako se nešto pokvari dok se paralelno menja tema ili dodaju dodaci, teško je razlučiti da li je uzrok ostatak infekcije ili obična greška u izmeni.

Koliko je ovo koštalo, i šta je bilo skuplje

Hakovana WooCommerce prodavnica gubi novac svakog dana dok problem traje, i to je trošak koji niko ne fakturiše.

Klijenti gotovo uvek pitaju za cenu čišćenja, a mnogo ređe računaju ono što je infekcija već koštala dok je trajala.

U ovom slučaju je preusmeravanje radilo nepunih deset dana pre nego što je iko reagovao. Za to vreme je deo posetilaca koji je dolazio iz pretrage završavao na tuđoj stranici umesto u prodavnici. Nemoguće je tačno izmeriti koliko je prodaje tako otišlo, ali je sasvim izvesno da je iznos bio veći od cene čišćenja.

Uz to ide i nešto što se ne vidi u brojkama. Tri kupca koja su prijavila problem su ljudi koji su već imali poverenja dovoljno da otvore sajt. Njihov utisak posle takvog iskustva se ne popravlja jednim čišćenjem.

Zato kod prodavnica brzina reagovanja vredi više nego kod običnih sajtova. Svaki dan odlaganja nije samo dodatni rizik, nego i merljiv gubitak.

Šta smo uradili posle čišćenja

Čišćenje nije kraj posla. Ono što dolazi posle određuje da li će se sve ponoviti.

Prvo, provera u Google alatkama da li je prodavnica označena u rezultatima pretrage. U ovom slučaju nije, jer je problem otkriven dovoljno brzo. Da jeste, uklanjanje upozorenja traži poseban zahtev i traje danima, pa je brzina reagovanja tu direktno štedela nedelje.

Drugo, uključen je nadzor koji svakodnevno poredi stanje fajlova i baze sa prethodnim. Razlog je jednostavan: ako je jedan backdoor bio dobro sakriven, moguće je da je i drugi. Nadzor hvata svaku novu izmenu odmah, umesto da se čeka da naraste u vidljiv problem.

Treće, klijent je dobio izveštaj sa spiskom svega što je pronađeno, gde je bilo, kroz šta je ušlo i šta je zatvoreno. To nije formalnost. Vlasnik koji zna kako je došlo do upada drugačije razmišlja o ažuriranjima nego onaj kome je samo rečeno da je sve rešeno.

Šta je klijent mogao da uradi drugačije

Ovo nije prebacivanje krivice, nego najkorisniji deo cele priče za nekoga ko čita.

Ažuriranje dodataka je zatvorilo ceo problem pre nego što je nastao. Ranjivost je bila poznata i zakrpljena mesecima ranije. Strah od ažuriranja je razumljiv, ali se rešava probnim okruženjem i bekapom, ne odlaganjem.

Uklanjanje nekorišćenih dodataka smanjuje površinu napada. Na ovoj prodavnici je bilo nekoliko dodataka koji godinama nisu korišćeni, a i dalje su stajali na serveru.

Redovan nadzor bi problem otkrio istog dana kad je backdoor postavljen, a ne nedeljama kasnije kad su kupci počeli da se žale. Razlika između te dve tačke u vremenu je razlika između sitne intervencije i cele ove priče.

Odvajanje sajtova na različite hosting naloge sprečava da infekcija sa jednog pređe na drugi. Deljenje jednog naloga je jeftinije, ali nosi ovaj rizik.

Šta ovaj slučaj govori uopšteno

Tri stvari se ponavljaju u gotovo svakom slučaju koji radimo.

Vlasnik retko prvi primeti problem. Skoro uvek javi neko sa strane, jer je maliciozni kod napravljen tako da vlasnika preskoči.

Ulaz je gotovo uvek nešto zastarelo. Ne neka sofisticirana tehnika, nego dodatak koji nije ažuriran, tema iz nezvaničnog izvora ili slaba lozinka.

Napadač uvek ostavi više od jednog puta nazad. Ko obriše prvo što nađe i stane, kupio je sebi nekoliko dana.

Kako sprečiti da WooCommerce prodavnica ponovo bude hakovana

Ako prepoznajete sličnu situaciju

Ako su vam kupci prijavili nešto što vi ne vidite, ili prosto želite da proverite na čemu ste, prvi korak ne mora ništa da košta. Besplatna brza analiza pregleda javno dostupan sadržaj sajta i traži poznate obrasce malvera, skrivene skripte i preusmeravanja. Bez naloga, bez instalacije, obično ispod minuta.

Vredi reći otvoreno šta ta provera ne može, jer je kod ovakvog slučaja to presudno. Ona vidi samo ono što je javno dostupno preko interneta. Od pet stvari koje smo našli u ovoj prodavnici, udaljena provera bi mogla da primeti samo preusmeravanje. Backdoor u fajlu, zakazani zadatak, lažni administrator i kod u bazi joj nisu vidljivi. Čist rezultat zato nije dokaz da je sve u redu.

Za pouzdan odgovor potreban je pregled samih fajlova i baze na serveru. Ako imate prodavnicu i sumnjate da nešto nije u redu, ili vam se infekcija već vraćala posle čišćenja, javite nam se. Pošaljite adresu i kratak opis šta se dešava. Kod prodavnica se trudimo da rad organizujemo tako da prodaja ne stane dok traje čišćenje.

Pitanja

Česta pitanja

Kratki odgovori uz ovaj članak. Ako ovde nema vašeg pitanja, pišite nam preko kontakta.

Zašto vlasnik prodavnice ne vidi preusmeravanje koje vide kupci?

Maliciozni kod skoro nikad ne radi za svakoga. Pre nego što nekoga preusmeri, proverava odakle je posetilac došao, da li je na telefonu i da li je ulogovan u administraciju. Vlasnik je obično ulogovan, kuca adresu direktno i radi sa računara, tačno ono što kod preskače.

Da li treba ugasiti WooCommerce prodavnicu tokom čišćenja?

Obično ne. Prodavnica koja je nedostupna gubi prodaju, pozicije u pretrazi i poverenje kupaca koji su već poručili. Bolje je prvo neutralisati mehanizam preusmeravanja, pa čistiti dok prodavnica ostaje dostupna, uz pažljiv redosled i bez diranja toka naplate usred intervencije.

Gde se najčešće krije backdoor u prodavnici?

Često u wp-content/uploads kao PHP fajl među slikama, u izmenjenoj temi (linija na kraju fajla), kao zakazan zadatak koji vraća infekciju, kao lažni administratorski nalog, i u bazi u poljima koja se učitavaju pri svakom zahtevu. Napadač po pravilu ostavi više od jednog ulaza.

Zašto vraćanje bekapa naslepo kod prodavnice može da škodi?

Ako je infekcija starija od bekapa, vraćate zaraženu prodavnicu. Ako vratite celu bazu, brišete i porudžbine nastale u međuvremenu: finansijska i pravna šteta. Bekap se vraća tek kad se zna datum upada, i skoro nikad se ne vraća cela baza.

Da li besplatna brza analiza dovoljno dokazuje da je prodavnica čista?

Ne. Ona vidi samo javno dostupan sadržaj. U tipičnom slučaju može da primeti preusmeravanje, ali ne i backdoor u fajlu, zakazani zadatak, lažnog admina ili kod u bazi. Za pouzdan odgovor treba pregled fajlova i baze na serveru.