Sokszor szembe jön velünk a biztonság témaköre, ha egy nyílt forráskódú CMS rendszerről vagy e-kereskedelmi szoftverről van szó. Szintén sokakban felmerül a kérdés ezen belül, hogy milyen előnyei és milyen hátrányai vannak annak, ha valaki nyílt forráskódú megoldást használ egy egyedileg megírt rendszer helyett. A saját véleményemet erről a cikk végén olvashatod, most térjünk rá arra, amiért ide kattintottál: Prestashop és azok a fránya “feltörések”.
Mit is jelent a “feltörés”?
A hacker-cracker témakörét a média ugyanúgy elferdítette az idők során mint ahogyan azt a történelem számtalan példán keresztül prezentálja az őskortól egészen napjainkig (nem veszélyes az ólmozott benzin, a cukor töménytelen mennyiségben sem méreg, füvezni tilos de alkoholista lehetsz). Az előbb említett megnevezés, az ezt követő “hekkerkedés“, a “kalózkodás” és a “kiberbűnözés” is tagjai annak a görög tragédiának, melyek beillenek a fenti sorba.
Mivel véges még a digitális tinta is, most célzottan arra koncentrálunk, hogy mit is jelent feltörni egy Prestashop-ot. Az én olvasatomban ez ennyit tesz: valaki vagy valakik valami által olyan – a tulajdonos által nem megengedett – jogosultságot szerez(nek) a rendszer felett, mely alapból nem járna neki/nekik. Hogy ezzel a jogosultsággal mit kezd(enek) és ez kinek jó/kinek rossz, csupán aspektus kérdése. A gyakorlatban ez így néz ki: egy programozó/programozók tudásuk által – közvetett vagy közvetlen, ellenőrzött vagy ellenőrizetlen módon – olyan rendszerbe lépnek be és tevékenykednek amikhez egyébként nincs közük, amikhez alapvetően nincs legális hozzáférésük.
A valóságban ez pedig így fest (példával élek, ilyen szemmel tessék olvasni): a programozó készít egy bot-ot (robotot) ami nem más, mint egy apró program. A belsejébe feltételeket tesz, melyek által a világhálón sebezhetőségeket keresgél. Olyan apró réseket melyek vagy publikusak, vagy csak ő tudja őket, és tisztában van azzal, hogy némelyik Prestashop (rosszabb esetben mindegyik) tartalmazza/tartalmazhatja azt. Amint a kis bot talál egy ilyet, megpróbálja kihasználni azt – a fent említett résen keresztül.
Ha van publikus rés, akkor hogy hogy esélye van egy ilyen “tapogatózásnak”?
Sok százezer Prestashop van a világon. Ha valaki felfedez egy rést, egy sebezhetőséget, egy lyukat, egy bármit amit akár rossz célokra is fel lehet használni akkor jelenti azt a hivatalos közösségnek – ez az egyik előnye a nyílt forráskódnak. Az persze, hogy a felfedező valóban jelenti-e vagy kihasználja-e az rá van bízva – de szerencsére az előbbi eljárás a népszerű. A Prestashop igyekszik kiadni egy “fix”-et, vagy “patch”-et modul vagy egyéb köntös formájában, mely befoltozza a rést. Ezt követően a javítás már belekerül a következő verzióba. Sokan azonban nem figyelik a híreket, sok tulajdonos nem ért ehhez és a programozó, aki anno elkészítette a shopot már hegyen-völgyön túl van, így az adott – sokszor elavult – verziójú shopban nem kerül kijavításra a “hiba” sem a frissítés, sem a gyorsfix által. Ezért “éri meg” energiát fektetni a tapogatózásba – mert mindig van eredménye.
Megéri? Mi éri meg? Kinek jó ez és mire?
Az internet elterjedésével eltűntek azok a vírusok amik “elégették” a winyót, letörölték a merevlemezt vagy bosszantó üzeneteket írtak ki a monitorra. A felkutatható és ellopható információ lett a digitális feketepiac legnagyobb kincse, értéke és fizetőeszköze. Ha az interneten valami valami hasznosat tesz, de neked nem kell fizetni érte akkor magaddal fizetsz – az adataiddal. Lásd Facebook, Google, Twitter, Snapchat, Pinterest, Instagram és még ezer lapon keresztül lehetne folytatni a sort. A privátszférádért pedig rengetegen állnak sorba olyan összegeket kínálva amiket ki sem tudnánk mondani egy levegővel.
Ezt követően már nem kell nagy fantázia ahhoz, hogy kitaláljuk: egy-egy bot miért és mit keres Prestashop-ot és Prestashop-ban. Vegyünk csak pár példát:
- hírlevél-feliratkozottak ellopása: ők aztán a viagrától elkezdve a különböző szexoldalakon át mindenféle érdektelen és bosszantó e-mail-t fognak kapni életük végéig,
- vásárlók, regisztrációk ellopása ugyanezen célból,
- szervererőforrás ellopása SPAM célzattal, adathalász és egyéb e-mail-ek kiküldésére (bankkártya-adatok elkérése a PayPal nevében például),
- statisztika adatok eltulajdonítása ezerféle különböző kimutatás forrásanyagaként: vásárlói szokások, trendek, viselkedések elemzése majd célzott felhasználása marketing és hirdetési területen,
- rossz szerverbeállítások miatti feljebb-kutakodás: osztott tárhelyen való kitörés a Prestashop-mappából és más oldalakhoz való hozzáférés – mondanom sem kell milyen megfontolásból,
- egyedi megbízás (ritka): konkurencia célzott megbízása rendszerünk adataiért, vásárlónk adataiért: nevek, címek, telefonszámok, egyedi üzenetek… rendkívül kényes adatok. Jelszavak elemzése – bár a Prestashop meglehetősen biztonságosan tárolja ezeket, kellő odafigyeléssel, szorgalommal és nagyon gyenge (“12345678”, “szerelem”, stb.) jelszavakkal ezek visszanyerhetők és felhasználhatók más rendszerekben: kihasználva azt a felhasználói gyengeséget, hogy egy jelszót használnak mindenhová. Ebben az esetben a legnagyobb “nyereményt” az jelenti, amikor a Prestashop-beli jelszó megegyezik az ügyfél e-mail-címének jelszavával. Onnantól kezdve minden szolgáltatás, mely ahhoz az e-mail címhez kapcsolódik (bank, facebook, google-drive stb.) jelszó-emlékeztetővel átvehetővé válik a tulajdonostól (megjegyzés: a Google gmail szolgáltatása azért eléggé fejlett ezen a területen már). Képzeljétek magatokat bele egy ilyen lehetetlen helyzetbe: a lehetőségek száma végtelen. Átveszem a facebook és e-mail-fiókodat, így az előbbibe már nem vagy képes bejutni; majd segélykérő koholmánnyal megkérem az ezer ismerősödet, hogy utaljon pár száz forintot xy bankszámlaszámra, mert külföldön ragadtál miután ellopták a táskád, benne minden iratoddal és pénzeddel. Persze, a példa fiktív de élhető és talán érthető is.
Értem-értem, ez utóbbi már talán kicsit erőszakos volt: de csak azért tűnik annak, mert alapvetően az ilyen támadások pont nem kicsiny országunk bonyolult nyelvezetére és annak átlagpolgárainak átlagkeresetére specializálódott. Mindazonáltal érdemes résen lenni. Ezen felül szerintem meglehetősen presztízskérdés az, hogy az adott brand/márka, melyet éveken át megfeszített munkával építettünk megengedhet-e magának egy olyan bakit, ahol bárki által megnézhetővé és letölthetővé válik az összes ügyfelünk minden adata.
Prestashop és annak moduljai
A legkockázatosabb pontok természetesen a Prestashop modulok. Az ingyen letölthető fajtájúak egy nevenincs lengyel, cseh, vagy fura nyelvezettel megírt amerikai oldalról már önmagában ordítanak a gyanússágukról. Figyelj és jegyezd meg: semmi sincs ingyen (tudom, mit gondolsz és nem tévedsz – még ez a cikk sem! 😀 ). Viccet félretéve: mindenki fizet – valamivel. Ugyanígy legyél nagyon óvatos az ingyenes témákkal is. Ha nem biztos a forrás akkor inkább hagyd a fenébe mert nem ér meg annyit, amennyit később szívhatsz vele. Ha pedig mindenképp erre adod a fejed akkor kérj tanácsot! Erre való a fórum, vagy épp a Facebook csoportunk.
Fertőzés ezer és ezerféle lehet – nyilván attól függően, hogy mi a cél. Az egyik ilyen esetet kicsit felgöngyölítve, log-okban turkálással és egyéb utánajárással sikerült egy listát összeállítani arról, hogy a támadó bot mely modulokat “tapogatta” le: ezáltal adott a kezünkbe egy nagyszerű checklist-et. Így tehát, ha a lentiek bármelyike fent van a shopodban akkor vizsgáld meg, hogy valóban szükséged van-e rá, ha nem akkor töröld le (ne csak kikapcsold vagy eltávolítsd!). Ha maradnia kell, akkor nézz utána, hogy a legfrissebb változatot használod-e és járj utána, hogy az már biztonságos-e!
- columnadverts
- pm_advancedsearch4
- soopamobile
- soopabanners
- vtermslideshow
- simpleslideshow
- simpleslideshow
- productpageadverts
- homepageadvertise
- homepageadvertise2
- jro_homepageadvertise
- attributewizardpro
- cartabandonmentpro
- videostab
- advancedslider
- wg24themeadministration
- wdoptionpanel
- fieldvmegamenu
- pk_flexmenu
- pk_vertflexmenu
- megamenu
- wg24themeadministration
- nvn_export_orders
A fentiek többsége egyébként themeforest-es témák egy-egy alapvető modulja. Ha ilyen témát használsz akkor érdemes kétszer is átfésülni a listát! A fenti modulokhoz tartozó támadás leginkább abból áll, hogy az érintett modulhoz tartozó fájlfeltöltő (legtöbbször képfeltöltő) php-t a bot távolról a saját fájljával a végén hívja meg: ezzel rábírva a szervert, hogy feltöltse azt (cURL segítségével). Mondanom sem kell, a feltöltött fájlt aztán meghívják, lefut, onnantól kezdve pedig majdhogynem azt tesznek amit csak akarnak. Néhány konkrétabb példa:
- /modules/columnadverts/uploadimage.php
- /modules/columnadverts/slides/hous.php?kl=shell
- /modules/simpleslideshow/uploadimage.php
- /modules/attributewizardpro/file_upload.php
- /modules/cartabandonmentpro/upload.php
Ha megtörtént a baj
A céltól függően több jele is lehet annak, ha fertőzés ért minket. Jellemző az admin felület elérhetetlensége, új ablakban megnyíló kéretlen oldalak, súlyos (és elhanyagolt) esetben pedig a Google zárolja az webshopot. Erről ITT olvashatsz bővebben. Érdemes megjegyezni a Google Search Console fontosságát ebben az esetben is. Probléma felmerülésekor a Google azonnal értesíti minket e-mail formájában.
Szükségtelen hangsúlyozni, hogy mennyire fontos a jó hosting / tárhely szolgáltatás. Ha igazán hozzáértő emberek ülnek a másik oldalon akkor ők időben észlelik a bajt és az oldalt elszeparálják a további problémák elkerülése érdekében, ezzel egy időben pedig értesítik a tulajdonost a problémáról. Szükség esetén segítenek a megtisztításban – ezen felül pedig olyan biztonságos szerverkörnyezetet alakítanak ki ahol a legkevesebb esélye van annak, hogy ilyesmi megtörténik. Ha nem vagy biztos benne, hogy jelenlegi szolgáltatód eleget tesz e kötelességének, szólj nekünk és segítünk!
Fent említett nyílt forráskód – egyedi, zárt forráskód dióhéjban
Úgy gondolom mindkettőnek megvan a létjogosultsága. Én szeretem a nyílt forráskódot (ezért is vagyok inkább Linux-párti) mert hatalmas benne a növekedési potenciál, mindenre képes hamarabb reagálni és testreszabhatóbb (azáltal, hogy bárki aki ért hozzá, módosíthatja). Értelemszerűen ebből fakadnak a hátrányai is: bárki kereshet sebezhetőséget, valamint nagy benne a támadás által kinyerhető adat-potenciál (mivel ingyenes mivoltja miatt sokan használják).
A zárt forráskódú rendszerek viszont egy-egy programozóhoz vagy céghez köthetőek csupán: ha velük bármi történik akkor más nehezen (de inkább nem) fogja átvenni a fejlesztés, hibajavítás szerepét (szemben a nyílttal). Ezen felül pedig lehet bárki bármekkora zseni; több ezer fejlesztővel senki sem tudja felvenni a versenyt tudásban és tapasztalatban. Trendekre, sebezhetőségekre, gyors Google-változásokra egy nyílt forráskód véleményem szerint hamarabb reagál, mint zárt társa: illetve ha nem, akkor míg előbbi semmilyen (vagy kevés) anyagi befektetéssel jár, utóbbiról ez már nem mondható el.
Még 2013-ban írtam erről egy nem is olyan rossz cikket, IDE KATTINTVA éred el. Jó olvasgatást! 🙂
Vírusmentes eladásra fel!
🙂
A cikk megírásáért köszönet Tamásnak! 🙂
