onlangs informatie over kwetsbaarheden is vrijgegeven die werden gevonden in de standaardbibliotheken van de talen Rust en ga, welke zijn gerelateerd aan verkeerd gebruik van IP-adressen met octale cijfers in adresanalysefuncties.
Er wordt vermeld dat eMet deze kwetsbaarheden kunt u verificaties van geldige adressen enn toepassingen, bijvoorbeeld om de toegang tot loopback-interface-adressen of intranet-subnetten te organiseren wanneer server-side request spoofing-aanvallen worden uitgevoerd.
De kwetsbaarheden in deze twee talen IP-adresreeksen hebben realisatie in de specificatie op nul gebaseerd, aangezien u in theorie moeten ze worden geïnterpreteerd als octale getallen, maar het probleem dat deze glitches veroorzaakt, is dat veel bibliotheken dit negeren en gewoon de nul weggooien, dus ze behandelen de waarde uiteindelijk als een decimaal getal.
Om bijvoorbeeld te begrijpen hoe IP-adressen in deze bugs worden geïnterpreteerd, is het getal 0177 in octaal 127 in decimaal en waarmee een aanvaller een bron kan opvragen met de waarde "0177.0.0.1", die, aangezien het niet wordt ingenomen als octaal is de decimale notatie hiervoor "127.0.0.1".
Dit is waarom in het geval van het gebruik van een van de problematische bibliotheken, de toepassing zal het voorkomen van het adres niet detecteren 0177.0.0.1 in het subnet 127.0.0.1, maar in feite kan bij het verzenden van een verzoek het adres "0177.0.0.1" worden aangeroepen, wat door een verkeerde interpretatie door de netwerkfuncties wordt verwerkt als 127.0.0.1. Evenzo kan toegang tot intranetadressen worden misleid en geverifieerd door verschillende waarden op te geven, die de aanvaller zal evalueren op mogelijk misbruik.
Aan de kant van Rust, het probleem bleek te vallen onder de standaardbibliotheek "std ::net" en die al is gecatalogiseerd onder "CVE-2021-29922". Het beschrijft dat de IP-adresparser van deze bibliotheek negeert een nul voor de waarden van het adres, maar alleen als er niet meer dan drie cijfers zijn opgegeven, bijvoorbeeld, "0177.0.0.1" wordt geïnterpreteerd als een ongeldige waarde en als reactie wordt een onjuist resultaat geretourneerd.
Incorrecte validatie van octale string-invoer in de rust-lang standaard "net"-bibliotheek stelt niet-geverifieerde externe aanvallers in staat om onbepaalde SSRF-, RFI- en LFI-aanvallen uit te voeren op veel programma's die afhankelijk zijn van rust-lang std ::net. De octetten van het IP-adres worden gestript in plaats van te worden geëvalueerd als geldige IP-adressen.
Er wordt ook vermeld dat toepassingen die de std ::net :: IpAddr-bibliotheek bij het ontleden van gespecificeerde adressen door gebruiker zijn mogelijk vatbaar voor SSRF-aanvallen (spoofing van verzoeken aan de serverzijde), RFI (externe bestandsopname) en BIA (inclusief lokale bestanden). Evenzo kan een aanvaller 127.0.026.1 invoeren, wat in feite 127.0.22 is
Een aanvaller die bijvoorbeeld een IP-adres naar een webtoepassing stuurt die is gebaseerd op std ::net :: IpAddr, kan SSRF veroorzaken door octale invoergegevens in te voeren; Een aanvaller kan exploiteerbare IP-adressen verzenden als het octet 3 cijfers heeft, met het minimaal exploiteerbare octet 08 dat leidt tot denial of service en het maximale exploiteerbare octet 099 dat ook leidt tot denial of service.
Als je meer wilt weten over deze kwetsbaarheid in Rust, u kunt de details bekijken In de volgende link. Er wordt ook vermeld dat de kwetsbaarheid is verholpen in de Rust 1.53.0-tak.
Zodra aan het probleem dat van invloed is op to Go, wordt vermeld dat dit onderworpen is aan de standaardbibliotheek «net» en het staat al vermeld onder CVE-2021-29923. In de beschrijving staat dat: stelt niet-geverifieerde externe aanvallers in staat SSRF-, RFI- en LFI-aanvallen uit te voeren onbepaald in veel programma's die afhankelijk zijn van de ingebouwde net.ParseCIDR-functie van golang. Individuele CIDR IP-octetten worden verwijderd in plaats van ze te evalueren als geldige IP-octetten.
Een aanvaller kan bijvoorbeeld de waarde 00000177.0.0.1 doorgeven, die, wanneer aangevinkt in de net.ParseCIDR-functie, wordt geparseerd als 177.0.0.1/24, niet als 127.0.0.1/24. Het probleem manifesteert zich ook op het Kubernetes-platform. De kwetsbaarheid is verholpen in Go-versie 1.16.3 en bètaversie 1.17.
Je kunt er meer over leren over deze kwetsbaarheid In de volgende link.