-----

Amit szerintem elsősorban meg kell érteni egy laikusnak, hogy az interneten egy bűncselekmény elkövetője tökéletesen el tud bújni, ezért a "bűnüldöző" logika nem működik, csak a "bűnmegelőző".

A második amit kontextusként meg kell érteni, hogy egy szolgáltató aki mások adatait kezeli az felel minden felhasználó adatainak biztonságáért. Ha őt feltörik, akkor azzal nem csak a saját biztonsága kompromittálódik, hanem a felhasználók biztonsága is.

Ebben a kontextusban menjünk végig a hibákon:

--- 50 forintos bérlet ---

Adott egy termék ára. A szerver megmondja a böngészőmnek, hogy mennyibe kerül a bérlet, a böngészőm pedig megmondja a banknak, hogy mennyit szeretne fizetni. Senki nem ellenőrzi, hogy ugyanazt a számot mondtam, amit nekem mondtak. Hasonlatnak azt tudom mondani, hogy ez olyan mintha a közértben a hentes lemérne a kért felvágottat, majd megmondaná nekem, hogy mennyit kell majd a kasszánál fizetnem, de nem írja fel sehova. Ez után a kasszás pedig minden további nélkül elhiszi amit mondok árnak, akkor is ha azt mondom 1 forint. Ha csupa becsületes ember lenne a világon, akkor ezzel nem lenne gond, csak hát az internet tele van kevésbé jó szándékú emberekkel is.

--- Plain text jelszavak ---

Minden szolgáltatónál előfordul, hogy minden erőfeszítés ellenére mégis bejutnak támadók az adatbázisba. Ilyen esetben az egyik legfontosabb megvédendő információ a felhasználók jelszava. Sajnos sokan ma is ugyanazt a jelszót használják több oldalon is (akár például a net bankjukhoz is), így ha kikerülnek a jelszavak, az különösen nagy baj.

Erre az iparági szabvány az, hogy a jelszavakat nem tároljuk, hanem egy úgynevezett egy irányú függvénnyel titkosítjuk. Így ha egy támadó hozzájut ezekhez a jelszavakból készített úgynevezett hash-ekhez, akkor még nem tudja megmondani az eredeti jelszót. (Annyi számítási kapacitás kellene hozzá, hogy ha a világ összes gépe ezen dolgozna, akkor is évekbe telne visszafejteni a jelszavakat.) Amikor valaki megadja a jelszavát, akkor arra újra kiszámítjuk a hash-t, és azt hasonlítjuk össze a tárolt hash-el.

Ezt az amúgy törvényben is előírt szabványt nem követte a T-systems fejlesztő csapata, ezzel veszélybe sodorva a felhasználókat.

A hasonlat az, mintha rám bíznák egy falu összes házának kulcsát, és én azokat a kocsimban hagynám jól látható helyen. Persze fel kell törni az autómat, hogy valaki hozzájusson, de csak az én autómat kell feltörnie, és akkor mindenki kulcsához hozzájut.

Amúgy azt nem tudjuk, de sejthetjük, hogy a többi adatot sem titkosítva tárolták. Így például a személyi igazolvány számokat sem. Tehát ha valakinek sikerül feltörni az adatbázist, akkor hozzájut több ezer ember olyan személyes adataihoz titkosítatlan formában amivel akár jelzálog hitelt is felvehet, vagy másként élhet vissza az emberek személyazonosságával.

--- E-mail-ben visszaküldött jelszó ---

Ez az előzőhöz annyiból kapcsolódik, hogy emiatt derült fény rá. Az e-mail-ről érdemes tudni, hogy eredetileg egyetemen belüli kommunikációra tervezték kísérlet képen, csak aztán véletlen elterjedt. Ezzel az a baj, hogy egyáltalán nem tervezték biztonságosra, út közben bárki elkaphatja, elolvashatja, sőt módosíthatja. (Ezért érdemes érzékeny információkat GPG alkalmazással titkosított formában küldeni ha e-mail-t használunk.)

Magyarul elküldeni valakinek egy jelszót e-mail-ben olyan mintha valakinek a lakás kulcsát egy átlátszó borítékban adnád fel, abban reménykedve, hogy a postás nem másolja le, és nem adja el utána betörőknek a másolatot a címmel együtt. (Megint csak fontos megjegyezni, hogy az emberek általában több helyen is használják ugyanazt a jelszót...)

--- Nyiltan elérhető profil adatok ---

Itt annyi történt, hogy el kérhetem a saját adataimat a rendszertől, de ehhez meg kell mondanom a nevem. A rendszer viszont nem ellenőrizte, hogy aki be van jelentkezve az azonos azzal a személlyel, akinek a profilját kérte a bejelentkezett felhasználó. Épp ezért bármely másik felhasználó adataihoz hozzá lehetett férni.

Magyarul egy személy azonossággal visszaéléshez szükséges adatokat bármely felhasználóról meg lehet tudni programozási ismeret, vagy az adat bázis feltörése nélkül. Szinte bárki megszerezhetett nyomok nélkül ilyen adatokat, és azzal akár - kedvenc példámnál maradva - jelzálog kölcsönt is felvetett volna.

--- Ellenőrizetlenül törölt regisztráció ---

Ez már a hackerkedésnek egy olyan területe, ami laikusoknak is könnyen érthető. Úgy nevezett social engineering. Ilyenkor arra apellálsz, hogy az ügyfél szolgálatos nincs felkészítve megfelelően és nem ellenőrzi a személyazonosságod mielőtt adatot ad ki, vagy teljesíti egy kérésedet. Ezzel gyakorlatilag úgy lehet kiszúrni valakivel, hogy regisztrálsz egy hasonló e-mail címet mint az övé (mondjuk kovacs.istvan@gmail.com helyett k0vacs.istvan@gmail.com) és a nevében kéred a regisztráció törlését. Legközelebb mikor utazni próbál a bérletével azt fogja tapasztalni, hogy már nem elérhető. Ez persze inkább gyerekes csíntevésre jó, de azért bosszantó tud lenni.

Sokkal aggasztóbb, hogy adott esetben elképzelhető, hogy hasonló social engineering technikával érzékeny adatok megadására sikerül rávenni az ügyfél szolgálatost.

--- SSL DROWN sérülékenység ---

Ez az egyetlen hiba, amire azt tudom mondani, hogy nem számít amatőr hibának. Nehéz is lenne laikusok számára érthetően részletezni mi a hiba. A lényeg az egészben, hogy a böngésző és a szerver közötti titkosított kommunikáció volt nem megfelelően beállítva, emiatt az lehallgatható volt. Itt is a jelszavak és személyes adatok kerülhettek rossz kezekbe, ha valakinek sikerül ezt kihasználva lehallgatni egy kommunikációt.

--- A BKK és a T-systems reakciója ---

Fontos megérteni, hogy a webes világban semmilyen körülmények között nem apellálhatunk a felhasználók jóindulatára, különösképp olyan esetben, mikor érzékeny adatokat tárolunk. Hibákat azonban mindenki elkövet. Éppen ezért a webfejlesztők között az a kultúra alakult ki, hogy ha megsejtünk egy sérülékenységet a másik rendszerében, akkor ellenőrizzük, hogy a sejtésünk helytálló-e (reprodukáljuk a hibát) és amennyiben igen, akkor azonnal értesítjük a szolgáltatót.

Ezt követően szoktunk időt adni a szolgáltatónak a hiba javítására, vagy legalább arra, hogy jelezze, hogy tudomásul vette a hibát, és javítani fogja mielőbb. Amennyiben azonban a szolgáltató nem reagál akkor nyilvánosságra szokás hozni a sérülékenység tényét, annak érdekében, hogy ha szolgáltató nem jár el felelősségteljesen (nem javítja a hibát) akkor a felhasználók tehessék meg a szükséges óv intézkedéseket. (Például jelen esetben indokolt az összes jelszó lecserélése, és új személyi igazolvány igénylése ha valaki regisztrálva volt a BKK oldalán.)"