(nem hivatalos e-kormányzati témájú oldal)
| Mottó: I'm gonna send him to outer space, to find another race. /The Prodigy: Out of Space/ | ||
| 2024. február 29. | ||
| sPACE Attack: német eSzemélyi okmány, CVE-2024-23674, eIDAS | ||
| A CVE-2024-23674 sérülékenység leírása 2024-02-15-én került nyilvánosságra "sPACE Attack: Spoofing eID’s Password Authenticated Connection Establishment - A Critical Man-in-the-Middle Vulnerability in the German eID Scheme" címmel, amire az ember egyből felkapja a fejét több okból is: egyrészt a magyar eSzemélyi okmány a német mintájára készült, ezért ilyen esetben meg kell vizsgálni, hogy a hazai ökoszisztéma érintett-e; másrészt a PACE protokoll jellege hasonlít az SSL/TLS-éhez, csak nem a web server és a client alkalmazás (pl. browser) között jön létre a rejtjelezett kommunikációs csatorna, hanem a laptop/desktop környezetben futó pl. eSzemélyi kliens és az eSzemélyi okmány chipjén levő JavaCard applet között. A részletes tanulmányt elolvasva az látszik ugyan, hogy sok munka van a támadás kivitelezése mögött, azonban az is kiderül, hogy nem a PACE protokollban találtak sérülékenységet, illetve nem magában a német eSzemélyi okmányban. A sérülékenység kihasználására, azaz jelen esetben a közbeékelődéses - Man-in-the-Middle - támadás kivitelezésére a német eSzemélyi okmányt kezelő mobil alkalmazás - AusweisApp - rossz konfigurációja ad lehetőséget. A mobil alkalmazást a felhasználó bizonyos linkekre kattintva is el tudja indítani ugyanúgy, mint amikor egy mobil alkalmazásban egy geolocation linkre kattint valaki és az operációs rendszer felkínálja erre megjelenítésre a Google Maps és Google Chrome alkalmazást is, amelyek közül a felhasználó tud választani. Ez a lehetőség - feliratkozás egy linkre - egy URL megadásával/regisztrálásával állítható be a mobil alkalmazásban, azonban erre több mód létezik, és ezek mögött eltérő szintű biztonsági ellenőrzést hajt végre az operációs rendszer. A Google Android esetében a legmegengedőbb URL a "Deep Link", ami bár ránézésre közönséges hivatkozásnak tűnik, de a séma az elején nem "http" vagy "https", hanem "custom" (a térképes példánál maradva lehet pl. "geo"). A "Web Link" típusú URL-eknél már a webes sémákat lehet csak használni, azaz a "http" vagy "https" kerülhet a hivatkozásba, amiket az operációs rendszer böngészővel nyit meg. Az "App Link" típusú URL-eknél is "http" vagy "https" sémákat lehet használni, viszont itt lehetőség van más mobil alkalmazásban megnyitni, de fontos különbség a "Deep Link" típusú URL-ekhez képest, hogy a háttérben lezajlik egy összetett ellenőrzési folyamat, amely lefedi az URL-ben megadott domain-hez való hozzáférést és a mobil alkalmazáson levő "code signing" aláírás ellenőrzését is.
A CVE-2024-23674 sérülékenység leírása tehát egy általánosabb jelenségre hívja fel a figyelmet, de azzal, hogy a német eSzemélyi okmányt kezelő AusweisApp mobil alkalmazással (és éles bankszámlanyitással) mutatta be, mindenképpen hangsúlyosabbá teszi. Az eset tanulságos, azaz jó (negatív) példával szolgál a mobil fejlesztők számára, hogy az ilyen funkciókat miképp (ne) konfigurálják be! De akkor miképp kellene konfigurálni ezt? Miért biztonságosabb az "App Link" típusú URL a "http" vagy "https" sémákkal? A kérdés megválaszolásához el kell merülni a kriptográfiában is egy kicsit. A Google Android operációs rendszer a biztonságosabb, "App Link" típusú URL-ek visszaellenőrzése során...
VII. POTENTIAL COUNTERMEASURESA mobil alkalmazáson levő aláírás ellenőrzésénél azért van olyan lépés, ami nem szokványos: a tanúsítvány(lánc) ellenőrzése, azon belül is a megbízható pontig való visszavezethetősége nem a pl. Android mobil operációs rendszer "trusted CA store"-ja alapján történik, hanem a fejlesztő által megadott URL-en tárolt adatok alapján (mint a mobil alkalmazás aláírásához használt fejlesztői tanúsítvány lenyomata). Azaz a kriptográfiai ellenőrzés alapja egy domain-hez, illetve ahhoz rendelt web server-hez való hozzáférés bizonyítása. De ez még így is magasabb biztonsági szintet jelent a "Deep Link" típusú URL-ekhez képest, amelyeknél semmilyen visszaellenőrzés sem történik operációs rendszer szinten, így egy közbeékelődéses támadás végrehajtásához szükséges - az eredetit emuláló másik ("fake") - mobil alkalmazás könnyebben telepíthető. A magyar eSzemélyi okmány a német eSzemélyi okmány mintájára készült, bár pont az eltérő közigazgatási modell miatt nálunk nem lenne szükséges annyi adatot tárolni a kártyán, hiszen a központosított adatforrásokból azok lekérdezhetők (szemben a német tartományi modellel, ahol alapvetően nem központosítva, hanem tartományi szinten elérhetők a különböző adatforrások, így nem helyi ügyeknél célszerű, ha maga a kártya kerül felhasználásra, mint adatforrás, adathordozó). A kommunikáció folyamata is megegyezik a német és magyar rendszernél, ami védett kérés-válasz üzeneteket használ (aláírás, rejtjelezés az OIDC - OpenID Connect Core - leírása szerint). Fontos azonban megjegyezni, hogy egy központi szerver általi ellenőrzés is be van iktatva ebbe a folyamatba (ez csak az eID applet-nél van így, azaz az ePASS és eSIGN applet "offline" is tud működni), ami miatt többen felvetettek privacy-kérdéseket, hiszen így a kormányzat láthatja, hogy az állampolgár milyen rendszereket használ és számukra milyen adatokat ad ki. És pont a privacy-kérdések voltak azok is, amelyek a wallet fogalmat (European Digital Identity Wallet) bevezető új eIDAS rendelet vitájánál is előkerültek. Az Európai Parlamentben végül 2024-02-29-én megszavazták a javaslat elfogadását, de az 556 képviselőből 190 - azaz a harmaduk - ellenezte. Ki tudja?! Még az is lehet, hogy a privacy-kérdések felemlegetőit befolyásolhatta a szavazás előtt két héttel publikált, német eSzemélyi okmányos probléma...
Kapcsolódó anyagok: | ||
| vissza | ||
info@ugyfelkapu.info
