Veszélyeket rejtenek a Google új .zip és .mov domain végződései

Még idén májusban jelentette be a Google, hogy elérhetővé váltak új TLD (Top Level Domain) címei, mint például a .zip, .mov. Ezekkel a cég szerint a weboldal tulajdonosok jobban meg tudják határozni az oldal funkcióját. A .zip TLD-t használó oldalakat például így hirdeti:

Természetesen az IT-sec szakemberek egyből megkongatták a vészharangot, de nagyon úgy látszik, hogy egyelőre kevés sikerrel, mivel a Google még mindig megvásárlásra hirdeti a veszélyes domaineket. Ezekkel a TLD-kkel ugyanis az a probléma, hogy a támadó könnyedén alakíthat ki olyan domain struktúrát, amely bár látszólag legitimnek tűnik, valójában ártalmas kódot tartalmazó oldalra továbbíthatja a felhasználót.

Domain faragás

Első ránézésre vajon meg tudja-e az olvasó mondani, hogy a két link közül melyik fogja letölteni a számítógépére az evil.exe állományt?

https://github.com∕kubernetes∕kubernetes∕archive∕refs∕tags∕@v1271.zip

https://github.com/kubernetes/kubernetes/archive/refs/tags/v1.27.1.zip

Azok tippeltek jól, akik az elsőt választották.

A magyarázat

Ha lebontjuk az URL-t, akkor a protokol és a @ közötti részben a felhasználó azonosítására szolgáló részt találjuk, és minden ami a @ jel után áll az azonnal hostnévként kerül feldolgozásra.

Vegyük példának az alábbi URL-t: https://google.com@bing.com, azonnal átfog minket vinni a bing.com oldalra. Viszont, ha elkezdünk / jeleket tenni az URL-be, akkor a @ utáni részt teljesen figyelmen kívül hagyják a böngészők, és átvisz minket a google.com domainre. Például: https://google.com/search@bing.com

A hiba

Akkor mégsem jelent ez akkora problémát? Gondolhatnánk, csakhogy egy 2016-os hibajegyből kiderül, hogy a böngészők elfogadják az URL-ben az U+2044 (⁄) és az U+2215 (∕) unicode karaktereket is. Így viszont a támadó már tud olyan, látszólag biztonságnak tűnő domaint felépíteni, amelyben kombinálva a @ jelet és az unicode karaktereket valósnak tűnő, de ártalmas domainre tudja vinni az áldozatot.

Tehát, ha megfelelően formázzuk meg a

https://google.com∕gmail∕inbox@bing.com

,az valójában a bing.com-ra fog elvinni minket, mivel a @ előtti rész a felhasználó azonosítására szolgál.

Egy konkrét támadási lehetőség bemutatása

A bejegyzés elején említett két domain példáján keresztül megnézünk, egy esetleges támadás forgatókönyvét. Ehhez a Github-on megtalálható Kubernetes repo könyvtárat fogjuk használni. A felhasználók normál esetben az alábbi URL-en érik el a legújabb csomagot:

https://github.com/kubernetes/kubernetes/archive/refs/tags/v1.27.1.zip

Ám ha megcsináljuk a domain manipulációkat, lecserélve a / jeleket az unicode karakterre és a legvégén írunk egy @ jelet a zip fájl neve elé, máris kész a látszólag megbízható, de hamis URL-ünk.

https://github.com∕kubernetes∕kubernetes∕archive∕refs∕tags∕@v1.27.1.zip

Tehát a v1.27.1.zip lenne a fenti esetben a domain nevünk. Mivel az 1.zip már foglalt, ezért némi trükkhöz kell folyamodnunk, és lefoglaljuk a v1271.zip domaint, $15 összegért.

Ezután felpattintunk egy EC2-t az Amazonnál, egy egyszerű Python Flask applikációval, amely a v1271.zip-re mutat, a DNS rekordok pedig a mi EC2-nkre. A Flask app minden beérkező kérésre ugyanazt az evil.exe-t fogja visszaválaszolni.

Ezt követően nincs más dolgunk, mint a kártékony URL-t elküldeni az áldozatnak e-mail-ben.

https://github.com∕kubernetes∕kubernetes∕archive∕refs∕tags∕@v1271.zip

Mit tehetünk?

Mivel egyelőre a Google nem jelentett be erre semmilyen megoldást, így sajnos nekünk kell figyelmesebbnek lennünk.

• A @ jel egy domainben elég árulkodó tud lenni.
• Mindig legyünk körültekintőek az e-mail-jeinkkel kapcsolatban, és ne kattintsunk reflexszerűen a másoktól küldött linkekre!

Forrás [medium.com]

Forrás [wired.com]