Ez a bejegyzés a „0.0.0.0 Day” sérülékenység technikai részleteit és potenciális hatásait tárgyalja, amely egy kritikus hiba, és a népszerű webböngészőket – Chrome, Firefox és Safari – érinti, helyi hálózati kérések kihasználásával.

Az Oligo Security kutatója, Avi Lumelsky által felfedezett sérülékenység a macOS és Linux rendszereket érinti, komoly biztonsági kockázatot jelentve. A probléma gyökere a különböző webböngészők eltérő szintű biztonsági végrehajtásában, valamint a böngészőiparban hiányzó egységes szabványban rejlik. Ez az eltérés lehetővé teszi a máskülönben ártalmatlan 0.0.0.0 IP-cím fegyverként való felhasználását támadók által, amely egy kaput nyit a helyi szolgáltatásokhoz való hozzáféréshez. Ezek a szolgáltatások magukban foglalhatják a fejlesztési környezetek, operációs rendszerek és akár belső hálózatok szempontjából fontosakat is.

A 0.0.0.0 Day sérülékenység hatásai kiterjedtek, kockázatot jelentve mind az egyéni felhasználókra, mind pedig egész szervezetekre. Az olyan sérülékenység-kihasználási kampányok, mint a ShadowRay, legutóbbi azonosítása kiemeli a szükségességét a sérülékenység gyors és hatékony mérséklésének.

A 0.0.0.0 Day sérülékenység felfedezése és jelentése

Avi Lumelsky, az Oligo Security munkatársa, kulcsszerepet játszott a 0.0.0.0 Day sérülékenység azonosításában. A kutatásuk, amelyet egy blogbejegyzésük részletez, egy hibát fedett fel abban, ahogyan a böngészők feldolgozzák a 0.0.0.0 IP-címre irányuló kéréseket – egy különleges cím, amely az összes hálózati interfészt jelöli.

Ez a cím, ahelyett hogy megfelelően lenne elszigetelve, elérhető volt a szokásos böngésző mechanizmusokon keresztül, ami a helyi hálózati szolgáltatások kihasználásához vezetett.

Az Oligo felfedezése egy logikai hibát tár fel, amely az összes nagyobb böngészőt érinti, beleértve a Chromium-ot, Firefox-ot és Safari-t és a rá épülő böngészőket, így a Chrome-ot és az Edge-t is érinti. Ez a sérülékenység lehetővé teszi a külső weboldalak számára, hogy kapcsolatba lépjenek és potenciálisan kihasználják a helyben futó szoftvereket MacOS és Linux rendszereken. Figyelemre méltó, hogy a Windows nem érintett ebben a kérdésben.

Technikai áttekintés

A sérülékenység mechanizmusa

A 0.0.0.0 Day sérülékenység kihasználja a 0.0.0.0 IP-cím böngészők általi kezelésének sajátosságait. Íme egy lebontás arról, hogyan működik ez a sérülékenység:

• IP-cím kezelése: A 0.0.0.0 cím hagyományosan arra szolgál, hogy a hálózati szolgáltatásokat az összes elérhető interfészhez kötődjön. Ez azt jelenti, hogy bármely erre a címre küldött kérés a gazdagépen futó szolgáltatások által kerül feldolgozásra, amelyeket korlátozni kellene a külső hozzáférés elől.
• Böngésző kérések kezelése: A böngészők nem teljesen szigorúan izolálják a 0.0.0.0 címre küldött kéréseket. Ez a figyelmetlenség lehetővé teszi a weboldalak számára, hogy kéréseket küldjenek a helyi szolgáltatásoknak, megkerülve a Same-Origin Policy (SOP) elvét, és feltárva a belső hálózati szolgáltatásokat.
• Példa kérési folyamatra:
  • Kezdeti kérés: Egy rosszindulatú weboldal HTTP kérést küldhet a http://0.0.0.0 vagy hasonló címre.
  • Szolgáltatás feltárása: Ha a helyi hálózati szolgáltatások ehhez a címhez kötődnek, válaszolhatnak a kérésre, potenciálisan érzékeny információkat tárva fel.
  • Adat kiszivárogtatása: A támadó elfoghatja és elemezheti a válaszokat, hozzáférve belső adatokhoz vagy szolgáltatásokhoz.

Mi az a 0.0.0.0 IP?

A 0.0.0.0 cím számos célt szolgál. Felismerhetjük néhány gyakori felhasználási módját: „minden IP ezen a gazdagépen,” „minden hálózati interfész ezen a gazdagépen,” vagy egyszerűen „localhost.”

Az RFC 1122 szerint a 0.0.0.0 a {0,0} jelöléssel azonosított: a szabvány korlátozza a cím célcímként való használatát az IPv4-ben, csak forráscímként engedélyezve bizonyos helyzetekben, például a DHCP kézfogás (handshake) során, amikor először rendelik hozzá egy IP-címet egy DHCPDISCOVER csomaggal.

Ezenkívül a 0.0.0.0 néha használatos az /etc/hosts fájlokban bizonyos domainek blokkolására, reklámblokkolóként funkcionálva, vagy hálózati szabályzatokban, ahol a CIDR blokk 0.0.0.0/32 az összes IP-cím engedélyezésére szolgál.

Weboldalak felhasználóinak ujjlenyomat-vétele

Az „ujjlenyomat készítés” egy jól ismert technika különböző célokra, leggyakrabban a visszatérő látogatók felismerésére. Azonban a rosszindulatú szereplők is kihasználhatják ezt adathalászatra és más rosszindulatú tevékenységekre.

A weboldalak gyakran gyűjtenek jelentős mennyiségű információt egy látogatóról anélkül, hogy az valaha is bejelentkezne. Egyes oldalak még tovább mennek, JavaScript segítségével átvizsgálják a látogató helyi portjait (localhost, 127.0.0.1) közvetlenül az oldal betöltésekor.

Ez a technika egy egyedi ujjlenyomatot hoz létre, amely alapján a felhasználó böngészője azonosítható. A helyi portok átvizsgálása során az ujjlenyomat készítője megkülönbözteti az érvényes válaszokat (jelezve, hogy valami fut egy porton) és a HTTP hibákat (jelezve, hogy nincs ott semmi).

A böngészőknek ideálisan blokkolniuk kellene az ilyen kéréseket, mivel már egyetlen kérés is kihasználáshoz vezethet. Azonban évekig ez a gyakorlat az interneten elterjedt volt, figyelmen kívül hagyva, amíg nem vált világossá, hogy ez biztonsági résekhez vezethet. Mikorra ezt felismerték, addigra ez a viselkedés mélyen beágyazódott a böngészők funkcionalitásába, ami megnehezítette a hiba javítását.

2006-ban már dokumentálták a rosszindulatú JavaScript használatot, amelyek kifejezetten otthoni routereket céloztak meg. A szabványosítás hiánya nagyban hozzájárult ehhez a problémához, hangsúlyozva az egységes biztonsági keretrendszer iránti sürgető szükségletet minden böngésző esetében.

Az olcsó szélessávú routerek népszerű módot kínálnak arra, hogy az emberek belső, és néha vezeték nélküli hálózatot hozzanak létre otthonaikban. Egy ilyen router megvásárlásával és csatlakoztatásával néhány másodperc alatt felállítható egy hálózat. Sajnos, egy rosszindulatú weboldal meglátogatásával a felhasználó akaratlanul is támadásnak teheti ki a routerét; a router beállításai megváltoztathatók, beleértve azokat a DNS szervereket is, amelyeket a gyorsan létrehozott belső hálózat tagjai használnak.

Egyértelmű igény volt egy olyan szabványos megközelítésre, amely kiterjeszti a Cross-Origin Resource Sharing (CORS) szabványt, hogy a böngészők meg tudják különböztetni a helyi, privát és nyilvános hálózatokat. A Google határozottan válaszolt erre az igényre, bevezetve a Private Network Access-t (PNA).

Még a nem-böngésző alkalmazások is gyakran töltenek be erőforrásokat külső domainekről, például a Google Analytics és hasonló kliens-oldali SDK-k használatával, vagy szkriptek és videók beágyazásával.

A böngészők mindig is biztonsági célpontok voltak, és a böngészőfejlesztőket áttörő biztonsági koncepciók bevezetésére ösztönözték, mint például a sandboxing (homokozó) és a HTTPS-ONLY sütik, vagy olyan szabványok megvalósítására, mint a CORS (Cross-Origin Resource Sharing), hogy biztosítsák a szervereket és a végfelhasználókat a rosszindulatú weboldalak általi CSRF (cross-site request forgery - kereszt-webhely kéréshamisítás) támadásoktól, amelyek a felhasználók privát adatait, belső hálózatait és helyi alkalmazásait veszélyeztetik.

A böngészők tervezésükből adódóan szinte bármelyik HTTP szerverhez küldhetnek kérést JavaScript segítségével. Amikor egy kereszt-eredetű választ kezelnek, a böngésző biztonsági mechanizmusai döntenek a teendőről:

• Érvényes: A válasz adatait a JavaScript kontextusába továbbítja (siker).
• Érvénytelen: Maszkolt választ ad vissza, vagy speciális hibát jelez (CORS, SOP, stb.).

De néha a válasz nem számít egyáltalán. A 0.0.0.0 Day sebezhetőséggel egyetlen kérés is elegendő lehet a károkozáshoz. Mielőtt részleteznénk, érdemes egy kis háttérinformációval kezdeni.

A 0.0.0.0 Day hatása messzemenő, egyaránt érinti az egyéneket és a szervezeteket. Az aktív kihasználási kampányok, mint például a ShadowRay felfedezése tovább hangsúlyozza a sérülékenység kezelésének sürgető szükségességét.

A ShadowRay tetszőleges kódfuttatást tett lehetővé, amikor véletlenül kitették az internetre, és közel egy évig nem fedezték fel. A Ray nagy rajongóiként gyakran használtuk helyi fejlesztésre. Ezt szem előtt tartva feltettük magunknak a kérdést: „Ki tudna-e használni egy nyilvános weboldal egy localhoston futó Ray fürtöt?”

A válasz sajnos igen. A 0.0.0.0 Day sebezhetőséget felhasználva a támadó szándékuak Javascript segítségével olyan kéréseket küldhettek a helyi hálózaton futó szolgáltatásokhoz, amelyek lehetővé tették a belső rendszerek kihasználását. Egy jelentős példa erre az, hogy a böngészőkben régebbi, 18 éves hibákat használtak ki, amelyek lehetővé tették, hogy támadók távoli szerverekről parancsokat küldjenek belső hálózati eszközökre.

Ez a sebezhetőség lehetővé tette, hogy egy egyszerű weboldal, amit a felhasználó meglátogat, kéréseket küldjön a felhasználó belső hálózatán található eszközökre (például routerekre), ami komoly biztonsági kockázatot jelentett. A Google által bevezetett Private Network Access (PNA) szabvány célja volt ennek a fajta kihasználásnak a megszüntetése, de kiderült, hogy bizonyos IP címekre még mindig lehetett kéréseket küldeni a böngészőn keresztül, ami újabb támadási felületet jelentett.

Ez a kampány tehát nem csak az AI infrastruktúrát, hanem a webböngészők biztonsági gyengeségeit is kihasználta, hogy a támadók mélyebb hozzáférést nyerjenek a rendszerekhez​

A ShadowRay kampány főbb jellemzői:

• Célzott áldozatok: Az áldozatok zömmel amerikai pénzügyi intézmények, kormányzati ügynökségek, egészségügyi szolgáltatók, egyetemek és magánszemélyek voltak.
• Nagy hatás: A kampány célzott támadásokat hajtott végre, érzékeny adatokat lopva, rendszereket kompromittálva és pénzügyi veszteségeket okozva.
• Technikai kifinomultság: A támadások különböző módszereket alkalmaztak, beleértve a social engineeringet, phishinget, és a helyi hálózatokba való beszivárgást.

2020 májusában egy érdekes szalagcím jelent meg a médiában. Egy másik érdekes esetet is ennek tulajdonítanak, az Ebay-jel kapcsolatban. Ebben az esetben az Ebay látszólag megpróbálta portszkennelni a látogatót, amint a weboldal betöltődött. Ezt a technikát használva a weboldal Javascript segítségével szkennelte a localhost (127.0.0.1) portjait, ami egy érdekes és egyedi ujjlenyomatot eredményezett.

A 0.0.0.0 Day jelentősége

Ez az incidens rámutatott a böngészőbiztonsági protokollok egységesítésének szükségességére, hogy megakadályozzák a hasonló biztonsági rések kihasználását. A sérülékenység hatásának minimalizálása érdekében a böngésző fejlesztőinek gyorsan be kell vezetniük javításokat, és a felhasználóknak folyamatosan frissíteniük kell böngészőiket a legújabb verziókra.

A felhasználók és szervezetek számára kritikus fontosságú a helyi hálózati szolgáltatások védelme, a hozzáférési szabályzatok szigorítása és a biztonsági bevált gyakorlatok betartása, hogy csökkentsék az ilyen típusú támadások kockázatát.

Javítás folyamatban: A böngészők hamarosan blokkolják a 0.0.0.0 címet

A felelősségteljes közzétételt követően a HTTP kérések a 0.0.0.0 címre most bekerülnek a biztonsági szabványokba egy Request for Comment (RFC) segítségével, és néhány böngésző hamarosan teljesen blokkolni fogja a 0.0.0.0 elérését. A 0.0.0.0 nem lesz többé engedélyezett cél IP-ként a Fetch specifikációban, amely meghatározza, hogyan kell a böngészőknek viselkedniük HTTP kérések esetén.

Javítási állapot böngészőnként

2024 április elején az Oligo közzétette ezeket a sérülékenységeket a főbb böngészőkért felelős biztonsági csapatoknak. A böngészőcsapatok minden cégnél elismerték a biztonsági hibát, és dolgozni fognak a kapcsolódó szabvány módosításán, valamint böngészőszintű mérséklő intézkedéseket vezetnek be. Végül minden böngésző blokkolni fogja a 0.0.0.0 címet, de ugyanakkor a piac közös szabványt követel.

A sérülékenység természete és a böngészők közötti javítás összetettsége miatt továbbra is kihasználható, lehetővé téve a külső webhelyek számára, hogy kommunikáljanak a helyi hálózat szolgáltatásaival.

A szabványosított megközelítés hiánya eltérő megvalósításokhoz vezetett a különböző böngészőkben. Ez azt jelenti, hogy ma minden böngésző másképp kezeli a belső vagy helyi hálózat(ok) felé irányuló HTTP kéréseket.

Google Chrome (és Chromium alapú böngészők, mint az Edge)

A Google által vezetett PNA (Private Network Access) kezdeményezés tovább fejlődik és javul. Azonban a 0.0.0.0 sebezhetőség megkerülte a PNA mechanizmust a Chromiumnál, amely blokkolja a webhelyek hozzáférését a 127.0.0.1, localhost és más privát IP-khez JavaScript segítségével, amikor azokat nyilvános webhelyekről töltik be.

Jelentésük után a Chrome blokkolja a 0.0.0.0 címet (Finch Rollout) a Chromium 128-tól kezdve. A Google fokozatosan vezeti be ezt a változást a következő kiadások során, és a Chrome 133-tól kezdve az IP cím teljesen blokkolva lesz minden Chrome és Chromium felhasználó számára.

Apple Safari

Az Apple-alapú böngészők, köztük a Safari, a „WebKit” nevű nyílt forráskódú szoftveren alapulnak. Jelentésük után az Apple jelentős változtatásokat hajtott végre a WebKit-ben, amelyek blokkolják a 0.0.0.0 elérését. Ennek a változásnak a részeként ellenőrzik a célállomás IP-címét. Ha az nullákból áll, a kérés blokkolva lesz. A konkrét változtatások itt találhatók: https://github.com/WebKit/WebKit/pull/29592/files

Mozilla Firefox

Jelenleg nincs azonnali javítás a Firefoxban. Bár a javítás folyamatban van, a Firefox soha nem korlátozta a Private Network Access-t, tehát technikailag mindig is engedélyezett volt. Ebből a szempontból „nincs mit javítani”, mivel a PNA nincs bevezetve az első helyen.

Jelentésuk után a Mozilla módosította a Fetch specifikációt (RFC), hogy blokkolja a 0.0.0.0 címet. A Firefox prioritást élvez a Private Network Access bevezetése, de még nem valósították meg. A jövőben egy meghatározatlan időpontban a 0.0.0.0 blokkolva lesz a Firefoxban, és nem függ majd a PNA bevezetésétől.

Egy 18 éves hiba?

A helyi és belső szolgáltatások mindig is a támadók célpontjai voltak. Egy különösen érdekes biztonsági problémát jelentettek a Mozillának, amely visszavisz minket 2006-ba, még a Chrome első 2008-as megjelenése előtt: A 18 éves hiba bejelentés, ami még mindig nyitott.

Ebben a hibajelentésben egy felhasználó azt állította, hogy nyilvános weboldalak támadták meg az otthoni hálózaton belüli routerét, és úgy gondolta, hogy a weboldalaknak nem lenne szabad ezt megtenniük. Abban az időben a belső hálózatok (és az internet általában) nem biztonságosra voltak tervezve: sok szolgáltatásnál hiányzott az autentikáció, nem is beszélve az SSL tanúsítványokról és a HTTPS-ről, amelyek nem voltak mindenhol elérhetők. A weboldalakat biztonság nélküli HTTP-n keresztül töltötték be, és a támadók folyamatosan túljártak a böngészők eszén rosszindulatú céljaik eléréséhez.

2006 óta számos támadási kampány kihasználta azt a tényt, hogy a kérések még mindig elküldésre kerülnek, míg a böngészők a válaszokra összpontosítanak. Például egy támadó által irányított weboldalon található rosszindulatú Javascript segítségével a támadók megváltoztathatják otthoni vagy irodai routere konfigurációját.

Tizennyolc év telt el, több száz hozzászólással, de a hiba még mindig nyitva van. Ezen 18 év alatt a probléma lezárásra került, majd újranyitották, újra súlyos vagy kritikus prioritásúvá nyilvánították, miközben még a világban is kihasználták.

A karbantartóknak nehéz dolguk volt megegyezni a hiba természetéről:

• Ez egy „sebezhetőség”?
• Kifejezetten a Firefoxra jellemző?
• Fejlesztési kérés?

Néhány Firefox fejlesztő azt állította, hogy ez sem hiba, sem funkció. A hibajelentést lezárták, újranyitották, majd prioritásba helyezték—és most nyitva marad, amíg a Firefox be nem vezeti a PNA-t. Egyetlen HTTP kérés elég volt a hiba kiváltásához—a válasz nem számított. Már 2006-ban dokumentálták a vadon kihasznált rosszindulatú script címkéket, amelyek otthoni routereket céloztak meg:

A szabványosítás hiánya volt az összes fájdalom fő forrása—nyilvánvalóvá téve az igényt egy alapvető biztonsági mechanizmus kifejlesztésére minden böngészőben. A világ vágyott egy szabványosításra, amely kiterjeszti a Cross Origin Resource Sharing (CORS) funkciót minden nagyobb böngészőben, lehetővé téve számukra, hogy megkülönböztessék a helyi, privát és nyilvános hálózatokat.

A Google merészen lépett be a szakadékba a Private Network Access (PNA) segítségével.

Mi az a PNA (Private Network Access)?

Sokáig nem volt világos, hogyan kellene a böngészőknek viselkedniük, amikor helyi vagy belső hálózatokhoz kérnek hozzáférést kevésbé privát kontextusból. Az olyan domaineknek, mint az attacker.com, nem szabadna kapcsolatba lépniük a localhost-tal — nem egy ideális világban.

Minden nagyobb böngésző a CORS-ra támaszkodott. A CORS sokat segít, de teljesítménye a válasz tartalmától függ, így a kérések még mindig elküldésre kerülnek és továbbíthatók. Ez egyszerűen nem elég jó. A történelem bebizonyította, hogy egyetlen HTTP kérés is megtámadhat egy otthoni routert—és ha ez minden, amire szükség van, minden felhasználónak képesnek kell lennie megakadályozni, hogy ez a kérés egyáltalán elküldésre kerüljön.

Szerencsére mindannyiunk számára a Chrome bevezette a PNA-t (Private Network Access).

Ez az új szabvány kiterjeszti a CORS-t azáltal, hogy korlátozza a weboldalak képességét, hogy kéréseket küldjenek privát hálózatok szervereire. A PNA azt javasolja, hogy különbséget tegyenek a nyilvános, privát és helyi hálózatok között. A kevésbé biztonságos kontextusból betöltött oldalak nem tudnak kommunikálni a biztonságosabb kontextusokkal. Például az attacker.com nem tud kapcsolatba lépni a 127.0.0.1 vagy a 192.168.1.1 címmel, mert ezek az IP címek privátabbnak tekinthetők. Forrás: https://developer.chrome.com/blog/private-network-access-update

A PNA különbözik a CORS-tól. Míg a CORS csak a nem szándékolt tartalom betöltését védi nem biztonságos kontextusban, ezt a válasz szintjén teszi. A válasz által használt erőforrások maszkolva vagy eldobásra kerülnek. A PNA erősíti ezt a képességet azáltal, hogy bevezeti annak lehetőségét, hogy megakadályozza a kérés elküldését egyáltalán.

A 0.0.0.0 tesztelése: a PNA megkerülése

Az aktuális PNA specifikáció szerint az alábbi IP szegmensek tekintendők privátnak vagy helyinek:

A kutatók észrevették, hogy a "0.0.0.0" nem szerepel ezen a listán. Úgy gondolták, hogy a PNA részeként a weboldalak nem küldhetnek kéréseket a 0.0.0.0 címre. A specifikáció szerint nem szabadna célként használni. Ennek kiderítése érdekében egy dummy HTTP szervert futtattak a localhoston (127.0.0.1). Ezután megpróbálták elérni egy külső domainen keresztül Javascript segítségével, a 0.0.0.0 cím használatával.

Ez ... egyszerűen működött. A kérés elérte a szervert.

Mi történt itt?

1. A böngésző nyilvános domain (.com) alatt elküldte a kérést a 0.0.0.0 címre.
2. A dummy szerver a 127.0.0.1 címen hallgat (csak a loopback interfészen, nem minden hálózati interfészen).
3. A localhoston lévő szerver megkapja a kérést, feldolgozza és elküldi a választ.
4. A böngésző a válasz tartalmát blokkolja, hogy ne propagálódjon a Javascriptbe a CORS miatt.

Ez azt jelenti, hogy a nyilvános weboldalak hozzáférhetnek bármely nyitott porthoz a gazdagépen, anélkül, hogy látnák a választ.

Megértettük, hogy ez a jelenlegi PNA implementáció megkerülése és egy belső hiba a böngészőkben. Amit találtak, azt jelentették az összes böngészőnek, felelősségteljes közzétételt követően, de szükségük volt egy valós fenyegetésre és egy valós támadási vektorra, hogy bizonyítsuk állításukat.

Sebezhető helyi alkalmazások keresése

Először is, egy alkalmazást kellett találni, amely potenciálisan problémás lehet—és bőven volt választási lehetőségünk. Sok alkalmazást érinthet a 0.0.0.0 Day sebezhetőség.

Amikor a szolgáltatások localhostot használnak, feltételeznek egy korlátozott környezetet. Ez a feltételezés, amely hibás lehet (mint ebben az esetben is), biztonságtalan szerver implementációkat eredményez. Például sok alkalmazás kihagyja a CSRF token kihívásokat és kompromisszumokat köt az autorizáció vagy autentikáció terén, mert feltételezik, hogy egy szigorúan ellenőrzött hálózati környezetben futnak.

Bizonyos esetekben semmilyen autorizációra vagy autentikációra nincs szükség, vagy nincs ellenőrzés a CSRF tokenek tekintetében. Amikor az alkalmazás azt látja, hogy biztonságos környezetben vagy egy megbízható, elszigetelt hálózatban fut, engedélyezi a POST HTTP útvonalakat, amelyek hiányoznak az autorizációs vagy CSRF tokenek, és hozzáférést biztosít az erőforrások és konfigurációk írásához — ami kódfuttatást tesz lehetővé. Mág egyetlen HTTP kérés is elegendő lehet ahhoz, hogy hozzáférjen a portjaihoz.

Ahhoz, hogy megtaláljanak egy helyi alkalmazást, amely sebezhető lehet a böngészőből, először szükségük volt egy HTTP szerverre, amely egy helyi porton (localhost hálózati interfészen) fut. Ahhoz, hogy teljes mértékben kihasználják ezt a sebezhetőséget távoli kódfuttatás eléréséhez, szükségük volt egy szolgáltatásra, amely rendelkezik HTTP eléréssel, amely képes fájlokat és konfigurációkat írni, módosítani vagy finomítani. Ismét bőven volt választási lehetőségük: a valós alkalmazásoknak sok végpontjuk van, és a helyi szolgáltatások valóban megteszik ezeket a biztonsági kompromisszumokat, ami nagyszerű hír a támadók számára.

Így válik kihasználhatóvá, ezt az elsőre ártalmatlannak tűnő hiba. Az Oligo kutatócsoportja által nemrégiben felfedezett kritikus sebezhetőséget nagy hatása lehet, hiszen az összes nagyobb webböngészőt érinti. Lehetővé teszi a támadók számára, hogy behatoljanak a helyi hálózatokba. Ezt a felfedezést „0.0.0.0 Day”-nek nevezték el, amely egy alapvető hibát tár fel abban, ahogyan a böngészők kezelik a hálózati kéréseket, potenciálisan hozzáférést biztosítva a rosszindulatú szereplők számára a helyi eszközökön futó érzékeny szolgáltatásokhoz.