Mozilla ettevõte teatas, et on lõpetanud iseseisva auditi klientrakendusele, mis ühendub Mozilla VPN teenusega. Auditi käigus analüüsiti isoleeritud klientrakendust, mis on kirjutatud Qt raamatukogu abil ja mida tarnitakse Linuxi, macOS, Windowsi, Androidi ja iOS-i jaoks. Mozilla VPN-i teenust toetab üle 400 serveri Rootsi VPN-teenuse pakkuja Mullvad, mis on paigutatud rohkem kui 30 riiki. Ühendus VPN-teenusega toimub WireGuard protokolli kaudu.
Auditi viibis Cure53, kes on varem auditeerinud projekte nagu NTPsec, SecureDrop, Cryptocat, F-Droid ja Dovecot. Audit oli suunatud allika koodide kontrollimisele ja sisaldas teste, et tuvastada võimalikke haavatavusi (krüptograafia seotud küsimusi ei käsitletud). Kontrollimisel tuvastati 16 turvaprobleemi, millest 8 olid soovitused, 5 hinnati madala riskiga, 2 keskmise riskiga ja 1 kõrge.
Sel juhul seostati keskmise ohtlikkusega probleem ainult ühe haavatavuse kategooriaga, kuna just see oli ärakasutatav. Antud probleem põhjustas VPN-i kasutamise informatsiooni lekkimist koodi kaudu captive portaali määramiseks, kuna edastati krüpteerimata otseühendusi HTTP kaudu, mis toimusid väljaspool VPN-tunnelit ja paljastasid kasutaja põhiettevõtte IP-aadressi juhul, kui ründaja suudab hallata ülekandeteed. Probleem lahendatakse captive portaali määramise režiimi väljalülitamisega seadistustes.
Teine, keskmise ohtlikkuse probleem on seotud mittearvuliste väärtuste puuduliku puhastamisega portsali numbris, mis võimaldab korraldada OAuth autentimisparameetrite lekkimist, asendades portaali numbri stringiga nagu «1234@example.com», mis toob kaasa sildi seadistamise <img src="»http://127.0.0.1:1234@example.com/?code=…»" alt="»»">, mis viitab example.com-le asemel 127.0.0.1.
Kolmas probleem, mida peetakse ohtlikuks, võimaldab igal kohalikul rakendusel, ilma autentimiseta, pääseda VPN-kliendile läbi WebSocketi, mis on seotud localhostiga. Näiteks on näidatud, kuidas aktiivse VPN-kliendi korral võis iga veebisait korraldada ekraanipildi loomise ja saatmise ekraanipildi genereerimise sündmuse kaudu. Probleem ei kuulu haavatavuste kategooriasse, kuna WebSocketi kasutati ainult sisemistes testversioonides ja selle suhtluskanali rakendamine oli plaanitud tulevikus brauserilaiendi koostööks.
Allikas: opennet.ru
