Sokkal durvább hibák is vannak a magyar weben, mint amit a BKK-nál láttunk
További Tech cikkek
- Könnyen megeshet, hogy a Google kénytelen lesz eladni a Chrome-ot
- A Huawei hivatalosan is bejelentette, előrendelhető a Mate 70
- Lesöpörheti Elon Musk X-ét a Bluesky, már a Google is relevánsabbnak találja
- Ezek a leggyakrabban használt jelszavak – érdemes változtatni, ha ön is használja valamelyiket
- Azonnal cserélje le, ha ilyen routert használ!
Óriási erőfeszítéseket tesznek az internetes cégek azért, hogy bízzunk bennük, hajlandók legyünk online vásárolni, és a bolti sorban állás helyett valami hasznos időtöltést keressünk magunknak. A bizalmunkat azzal tudják megerősíteni, hogy a lehető legjobb védelmi rendszert építik ki, hogy senki se férjen hozzá az eladó és a vevő közti kommunikációhoz, személyes adatok ne kerülhessenek illetéktelen kezekbe.
Most átvesszük, mit tanulhatnak ebből az esetből a vevők, a webshopok fejlesztői, illetve azok, akik megrendelőként készíttetnek egy online boltot.
Ami a lakat mögött van
Vevőként a webes vásárlások során arra kell odafigyelni, hogy a böngésző mit jelez nekünk. Jó jel, ha a weboldal címe előtt egy kis zöld lakatot látunk, és mellette vagy az oldalt működtető vállalat neve van odaírva, vagy csak ennyi: Biztonságos. Ez arra utal, hogy a weboldal szervere és a böngészőnk közt titkosított és hitelesített a kapcsolat. Ez még nem elegendő ok a bizalomra, de a BKK webshopja például már itt elbukik: arról tájékoztat minket a böngésző, hogy az oldal nem hiteles forrásból próbál szkripteket betölteni.
Amint engedélyezzük a szkriptek futását, a böngésző máris pirosra vált, és arra figyelmeztet minket, hogy a kapcsolat már nem biztonságos. A feliratra kattintva láthatóvá válik egy jó tanács:
Oké, most a BKK külön figyelmeztet minket arra, hogy a szolgáltatása átmenetileg nem üzemel, de az oldal nagyon jól szemlélteti, hogy mire kell odafigyelni minden jövőbeli online vásárlás során az összes online boltban.
És még a zöld lakattal sem tudtunk meg mindent arról, hogy az adott weboldalban mennyire bízhatunk meg, hiszen ez a jelzés csak azt mutatja, hogy van megbízható titkosítás - is. Ez a kurta "is" pedig nagyobb figyelmet érdemel. A BKK webshopjában korábban megmutattunk egy sérülékenységet, hogy a szerver elavult titkosítási megoldást is használt, és ez kibertámadást tehet lehetővé.
„A BKK weboldalán többféle titkosítási algoritmus elérhető, és ezek közt megtalálható volt az RC4. Ez mára teljesen elavult, és bár jelentős kockázatot nem jelent, a tiltása mindenképpen ajánlott, sőt, elvárt egy igényes szerver konfiguráció esetében” - mondta el nekünk Székely Tamás, a kiberbiztonsággal foglalkozó Kancellár.hu szakértője.
Az 1987-ben megtervezett RC4-et a legtöbb böngésző aktuális verziója nem is képes használni. A Google, a Microsoft és a Mozilla közösen döntött úgy 2015-ben, hogy egységesen megszüntetik a böngészőikben az RC4 támogatását.
Hiába frissített
Titkosítási protokollok időrendben
SSL 1.0 - nem jelent meg, hibás volt
SSL 2.0 - 1995
SSL 3.0 - 1996
TLS 1.0 - 1999
TLS 1.1 - 2006
TLS 1.2 - 2008
TLS 1.3 - még készül
A böngésző védelmi mechanizmusa úgy működik, hogy az mindig a szerveren elérhető legerősebb titkosítási módot választja ki, ezzel folytatja a kommunikációt. Így ha a felhasználó mindig naprakészen tartja a böngészőjét, az nyilvánvalóan nem RC4-en fog kapcsolatba lépni a webshopok szerverével.
Mégsem szabadna bekapcsolva hagyni a szervereken elavult titkosítási módszereket, fejtette ki Székely Tamás, mert bizonyos esetekben akkor is feltörhető a titkosított kommunikáció, ha a webshopra belépő vevő modernebb, erős titkosítási algoritmust használ.
A DROWN támadás nagyon durva
- foglalta össze velősen a Kancellár.hu szakértője, amikor szóba került a BKK webshopjában korábban fellelt sérülékenység. Ez a támadás az RC4-nél valamivel modernebb, de még mindig 90-es évekbeli SSL2 protokollra épül, és ma már ezt sem lenne szabad használni. Már csak azért sem, mert a megléte teszi lehetővé a DROWN támadást. Ez a módszer akkor is működik, ha a felhasználó böngészője komoly védelmet nyújtó TLS titkosítást használ. A támadónak elég lehallgatnia az áldozat és a szerver kommunikációját, és közben SSL2-n néhány speciális csomagot küldeni, hogy rendkívül gyorsan feltörje az SSL2-nél jóval erősebb kriptográfiát.
Ezeknek a sérülékenységeknek meglétét tudtuk ellenőrizni a Qualys publikus webes eszközével, amit webfejlesztők is előszeretettel használnak. Ha a BKK vagy a T-Systems is használt volna ilyesmit, nagyon gyorsan észrevették volna az SSL-ben lévő biztonsági rést, és azt pillanatok alatt betömhették volna. Mint megtudtuk, ezek nem is fejlesztői hibák, hanem üzemeltetési hiányosságok, és nagyon egyszerű befoltozni őket: a szerver konfigurációs fájljában pár karakter beírásával tiltani az elavult protokollokat.
A Kancellár.hu szakértőinek az a tapasztalata, hogy a fentieknél sokkal súlyosabb hibák vannak a magyar weboldalakon. Ezek már olyan biztonsági rések, amelyekre nem derül fény egy weben bárki számára elérhető nyilvános eszköz futtatásával.
Az egyik legrosszabb az, amikor nem korlátozzák a felhasználói bevitelt, és a weboldal látogatója bevihet rosszindulatú kódokat adatbekérő mezők kitöltésekor. Ha sérülékenység van a felhasználói bevitel alapján lekérdezéseket előállító (pl. PHP) kódban, akkor a szerverről akár teljes adatbázisokat lehúzhatnak a támadók. Előfordul az is, és ez nagyon súlyos következményekkel jár, hogy nem korlátozzák a parancsok futtatását.
Van, hogy a szerveren szabadon lehet feljebb lépkedni a könyvtárstruktúrában, esetleg pár (akár az URL-ben egyszerűen látható) paraméter módosításával olyan adatok válnak elérhetővé, amelyekhez a látogatónak nem szabadna hozzáférni. Ahol pedig fájlokat lehet feltölteni, gyakran nem vizsgálják meg ezeket az állományokat, kihagyják a víruskeresést, és így káros fájlok is feltölthetők az áldozat szerverére. Ha rosszul állítják be a webszervert, a támadó kívülről le is futtathatja a kódot.
A leggyakoribb hibát a felhasználók munkamenet-kezelésével követik el. Amikor egy felhasználó belép a jelszavával egy weboldalra, kap egy munkamenet-azonosítót. Ennek az azonosítónak a generálása szokott túlságosan egyszerű lenni, például az egyik felhasználó kap egy X számot, a következő belépő pedig X+1-et. Vagy túlságosan egyszerű, kitalálható a véletlenszám-generátor működése. Aki kitalálja egy másik felhasználó munkamenet-azonosítóját, az meg tudja nézni egy idegen felhasználó aktuális munkakörnyezetét. Mondjuk belép a weben tárolt adatlapjára, és ellesi az ott tárolt személyes adatait.
Szólni kéne, na de kinek?
Ha a hazai webshopok és weboldalak biztonsága nőne, sokkal nyugodtabb szívvel vásárolhatnánk online, tudva azt, hogy a weben megadott személyes adataink biztonságban lesznek. Éppen ezért nemcsak a webfejlesztőknek, a szerverek üzemeltetőinek javasolják a szakértők a Qualys elemzőeszközének használatát, hanem webfejlesztést megrendelő cégeknek is, hogy kicsit jobban lássák, mit kaptak a pénzükért.
Van tehát egy nyilvánosan eszköz, amellyel akár teljesen laikus amatőrök is megtalálhatnak bizonyos biztonsági hibákat (még ha nem is mindet). A profibb eszközöktől már tartózkodni kell, mert a felhatalmazás nélküli biztonsági tesztelés büntetőjogi kategória. Az viszont korántsem egyértelmű, hogy a felfedezett résekről kinek kell, és kinek lehet szólni. A BKK esetében az e-jegy rendszert üzemeltető T-Systems rögtön feljelentett a rendőrségen egy lakossági bejelentőt, márpedig senki sem akar bilincset a csuklójára, csak mert egy webes cég vadidegen alkalmazottja elrontott valamit.
Az IT-biztonság javát szolgálná, ha a webes szolgáltatók transzparensebbek lennének, és ellenőrizhetővé tennék a biztonságukat. Ez csak egy légből kapott ötlet, de valamelyik hatóság is közzétehetne ilyen eszközt, vagy hogy ne csak sejteni, hanem tudni lehessen, hogy milyen a webshopjaink aktuális biztonsági szintje.
A segítő szándékú szakértők és a webshopok közti kommunikációt gördülékenyebbé tenné, ha mindegyik webes szolgáltató egyértelműen jelezné, melyik emailcímre és milyen formában várja az IT-biztonsággal kapcsolatos bejelentéseket. Egy kereskedőnek, aki csak megrendelt egy webes fejlesztést, valószínűleg kínaiul hangzik bármilyen informatikai bug leírása, úgyhogy célszerű olyan kommunikációs csatornát megadni, amely egyenesen a fejlesztőhöz is eljuttatja az IT-biztonsági jelzéseket.
A nagyobb üzemeltetőknek pedig felelősséggel kell kommunikálni a nagyközönséggel, főleg amíg az IT-biztonsági etika nem kötelező iskolai tananyag. Jó példa erre a német Deutsche Telekom (a magyar T-Systems tulajdonos anyacége), amely a weboldalán proaktívan oktatja a látogatóit. Nagy fokú profizmusról árulkodik, hogy részletesen előre jelzik az elvárásaikat a bejelentésekkel kapcsolatban.
Már a spájzban vannak
Kibervédelmi körökben szállóigévé vált, hogy kétféle cég létezik:
Folyamatosan arról érkeznek a hírek, hogy mekkora kiberhadsereggel rendelkeznek egyes országok, micsoda akciókat hajtanak végre kémkedő hekkerek, és hogy a digitális korszak bűnözői ellopott személyes és banki adatok millióit adják-veszik a web sötét bugyraiban. Közérdek lenne tehát, hogy mindenki többet tegyen a hazai kiberbiztonságért, hogy legalább ne lépten-nyomon, és lehetőleg minél később hekkeljék atomjaira a web magyar szegletét.
A tipikus webes sérülékenységek listája
- A felhasználói bevitel ellenőrzésének hiányából adódó leginkább tipikus sérülékenységek, mint az SQL injection és a Cross-Site Scripting (XSS)
- A biztonsági szempontból kritikus alkalmazás logika nem működik megfelelően (pl. ne engedjen a rendszer utalni, csak a felhasználó saját számláiról, stb.)
- A munkamenet kezelés gyengesége, mint például a jogosultság kezelés logikai hibája, vagy amikor az egyik felhasználó egy paraméter átírásával látja a másik munkamenetét, esetleg gyenge, kitalálható a munkamenet azonosítója
- Megkerülhető a hitelesítési rendszer (bejelentkezési felület)
- Egy felhasználó elérhet olyan erőforrásokat, amihez eredetileg nem kéne, hogy jogosultsága legyen
- Szótáralapú vagy brute force eszközökkel könnyen meghatározható jelszavak
- Az esetleges jelszó emlékeztető funkciók biztonsági hiányosságai
Forrás: Kancellár.hu
Borítókép: Németh Sz. Péter / Index.