18 jaar oude beveiligingsfout in Firefox en Chrome misbruikt in aanvallen
Een kwetsbaarheid die 18 jaar geleden werd onthuld, genaamd “0.0.0.0 Day”, stelt kwaadaardige websites in staat om de beveiliging in Google Chrome, Mozilla Firefox en Apple Safari te omzeilen en te communiceren met diensten op een lokaal netwerk.
Het moet echter worden opgemerkt dat dit alleen invloed heeft op Linux- en macOS-apparaten, en niet werkt op Windows.
Bij getroffen apparaten kunnen dreigingsactoren dit lek misbruiken om op afstand instellingen te wijzigen, onbevoegde toegang te krijgen tot beschermde informatie en, in sommige gevallen, uitvoering van externe code te bereiken.
Ondanks dat dit probleem in 2008, 18 jaar geleden, werd gemeld, blijft het onopgelost in Chrome, Firefox en Safari, hoewel alle drie het probleem hebben erkend en werken aan een oplossing.
Bron: Oligo Security
Onderzoekers van Oligo Security melden dat het risico niet alleen aanvallen theoretisch mogelijk maakt, maar meerdere dreigingsactoren hebben waargenomen die de kwetsbaarheid exploiteren als onderdeel van hun aanvalsketens.
De 0.0.0.0 Day fout
De 0.0.0.0 Day kwetsbaarheid komt voort uit inconsistente beveiligingsmechanismen in verschillende browsers en het gebrek aan standaardisatie dat openbare websites in staat stelt om te communiceren met lokale netwerkdiensten met behulp van het “wildcard” IP-adres 0.0.0.0.
Gewoonlijk vertegenwoordigt 0.0.0.0 alle IP-adressen op de lokale machine of alle netwerkinterfaces op de host. Het kan worden gebruikt als een tijdelijke adres in DHCP-verzoeken of geïnterpreteerd als localhost (127.0.0.1) wanneer gebruikt in lokaal netwerk.
Kwaadaardige websites kunnen HTTP-verzoeken sturen naar 0.0.0.0 gericht op een dienst die draait op de lokale machine van de gebruiker, en vanwege het gebrek aan consistente beveiliging worden deze verzoeken vaak gerouteerd naar de dienst en verwerkt.
Bestaande beschermingsmechanismen zoals Cross-Origin Resource Sharing (CORS) en Private Network Access (PNA) kunnen deze riskante activiteit niet stoppen, legt Oligo uit.
Van nature voorkomen webbrowsers dat een website verzoeken doet aan een website van derden en de ontvangen informatie gebruikt. Dit werd gedaan om te voorkomen dat kwaadaardige websites verbinding maken met andere URL’s in de webbrowser van een bezoeker waarop ze mogelijk zijn geauthenticeerd, zoals een online bankportaal, e-mailservers of een andere gevoelige site.
Webbrowsers introduceerden Cross-Origin Resource Sharing (CORS) om websites toegang te geven tot gegevens van een andere site als ze daar expliciet toestemming voor hebben.
“CORS is ook geweldig, en maakt internet al veel veiliger. CORS voorkomt dat de reacties de aanvaller bereiken, zodat aanvallers geen gegevens kunnen lezen bij het maken van ongeldige verzoeken. Bij het indienen van een verzoek, Als de CORS-headers niet aanwezig zijn in de reactie, zal de Javascript-code van de aanvaller de inhoud van de reactie niet kunnen lezen.
CORS zou de reactie alleen stoppen voordat het de JavaScript bereikt, maar ondoorzichtige verzoeken kunnen worden verzonden in modus “no-cors” en succesvol de server bereiken—als we ons niet bezighouden met de reacties.”
❖ Oligo
Bijvoorbeeld, als het doel van een dreigingsacteur simpelweg is om een HTTP-eindpunt te bereiken dat draaide op een lokaal apparaat dat kan worden gebruikt om een instelling te wijzigen of een taak uit te voeren, dan is de output niet noodzakelijk.
Oligo legt uit dat de beveiligingsfunctie Private Network Access (PNA) het iets anders doet dan CORs door elk verzoek te blokkeren dat probeert verbinding te maken met IP-adressen die als lokaal of privé worden beschouwd.
Maar het onderzoek van Oligo onthulde dat het speciale IP-adres 0.0.0.0 niet is opgenomen in de lijst van beperkte PNA-adressen, zoals 127.0.0.1 bijvoorbeeld is, dus de implementatie is zwak.
Dus, als een verzoek in “no-cors” modus wordt gedaan aan dit speciale adres, kan het PNA omzeilen en toch verbinding maken met een webserver-URL die draait op 127.0.0.1.
Actief geëxploiteerd
Helaas is het risico niet alleen theoretisch. Oligo Security heeft verschillende gevallen geïdentificeerd waarin de “0.0.0.0 Day” kwetsbaarheid actief wordt geëxploiteerd in het wild.
Het eerste geval is de ShadowRay-campagne, die dezelfde onderzoekers afgelopen maart hebben gedocumenteerd. Deze campagne richt zich op AI workloads die lokaal draaien op machines van ontwikkelaars (Ray clusters).
De aanval begint met het slachtoffer dat klikt op een link die via e-mail is verzonden of op een kwaadaardige site die JavaScript activeert om een HTTP-verzoek te sturen naar ‘http://0[.]0[.]0[.]0:8265’, meestal gebruikt door Ray.
Die verzoeken bereiken het lokale Ray-cluster, waarbij scenario’s van willekeurige code-uitvoering, reverse shells en configuratiewijzigingen ontstaan.
Bron: Oligo Security
Een ander geval is een campagne gericht op Selenium Grid, ontdekt door Wiz afgelopen maand. In deze campagne gebruiken aanvallers JavaScript op een openbaar domein om verzoeken te sturen naar ‘http://0[.]0[.]0[.]0:4444.’
Die verzoeken worden gerouteerd naar de Selenium Grid-servers, waardoor de aanvallers code kunnen uitvoeren of netwerkverkenning kunnen uitvoeren.
Bron: Oligo Security
Tenslotte werd het “ShellTorch” kwetsbaarheid gemeld door Oligo in oktober 2023, waarbij het TorchServe webpaneel standaard was gebonden aan het 0.0.0.0 IP-adres in plaats van localhost, waardoor het blootgesteld werd aan kwaadaardige verzoeken.
Reacties van de ontwikkelaars van browsers
Oligo meldt een plotselinge toename in het aantal openbare websites die communiceren met 0.0.0.0 sinds vorige maand, wat nu ongeveer 100.000 heeft bereikt.
Bron: Oligo Security
In reactie op de onthulling van deze activiteit door Oligo, beginnen de ontwikkelaars van webbrowsers eindelijk actie te ondernemen:
Google Chrome, ’s werelds populairste webbrowser, heeft besloten actie te ondernemen en de toegang tot 0.0.0.0 te blokkeren via een geleidelijke uitrol die loopt van versie 128 (aankomend) tot versie 133.
Mozilla Firefox implementeert geen PNA, maar het is een hoge ontwikkelingsprioriteit. Totdat PNA is geïmplementeerd, is een tijdelijke oplossing in gang gezet, maar er werden geen uitroldatums verstrekt.
Apple heeft extra IP-controles geïmplementeerd op Safari via wijzigingen in WebKit en blokkeert de toegang tot 0.0.0.0 in versie 18 (aankomend), die wordt geïntroduceerd met macOS Sequoia.
Totdat de browserfixes arriveren, adviseert Oligo dat app-ontwikkelaars de volgende beveiligingsmaatregelen implementeren:
- Implementeer PNA-headers.
- Controleer HOST-headers om te beschermen tegen DNS-rebinding-aanvallen.
- Vertrouw niet op localhost—voeg autorisatie toe, zelfs lokaal.
- Gebruik HTTPS waar mogelijk.
- Implementeer CSRF-tokens, zelfs voor lokale apps.
Het belangrijkste is dat ontwikkelaars moeten onthouden dat totdat fixes zijn uitgerold, het nog steeds mogelijk is voor kwaadaardige websites om HTTP-verzoeken te routeren naar interne IP-adressen. Daarom moeten ze deze beveiligingsoverweging in gedachten houden bij de ontwikkeling van hun apps.
Opzoek naar de laatste updates uit onze securitylog?
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----