Mozilla har tillkännagivit slutförandet av en oberoende granskning av klientprogramvara för anslutning till Mozilla VPN-tjänst. Granskningen inkluderade en analys av en fristående klientapplikation skriven med Qt-biblioteket och tillgänglig för Linux, macOS, Windows, Android och iOS. Mozilla VPN drivs av mer än 400 servrar från den svenska VPN-leverantören Mullvad, som finns i mer än 30 länder. Anslutning till VPN-tjänsten görs med hjälp av WireGuard-protokollet.
Granskningen utfördes av Cure53, som vid ett tillfälle granskade projekten NTPsec, SecureDrop, Cryptocat, F-Droid och Dovecot. Granskningen omfattade verifiering av källkoder och inkluderade tester för att identifiera möjliga sårbarheter (problem relaterade till kryptografi beaktades inte). Under revisionen identifierades 16 säkerhetsfrågor, varav 8 var rekommendationer, 5 tilldelades en låg risknivå, två tilldelades en medelnivå och en tilldelades en hög risknivå.
Men bara ett problem med en medelsvårhetsnivå klassificerades som en sårbarhet, eftersom det var det enda som kunde utnyttjas. Det här problemet resulterade i läckage av VPN-användningsinformation i den infångade portalens upptäcktskod på grund av okrypterade direkta HTTP-förfrågningar som skickades utanför VPN-tunneln, vilket avslöjar användarens primära IP-adress om angriparen kunde kontrollera transittrafiken. Problemet löses genom att inaktivera detektionsläget för captive portal i inställningarna.
Det andra problemet med medel svårighetsgrad är förknippat med bristen på korrekt rengöring av icke-numeriska värden i portnumret, vilket tillåter läckage av OAuth-autentiseringsparametrar genom att ersätta portnumret med en sträng som "[e-postskyddad]", vilket gör att taggen installeras[e-postskyddad]/?code=..." alt=""> får åtkomst till example.com istället för 127.0.0.1.
Det tredje problemet, flaggat som farligt, tillåter alla lokala program utan autentisering att komma åt en VPN-klient via en WebSocket bunden till localhost. Som ett exempel visas hur, med en aktiv VPN-klient, vilken webbplats som helst kan organisera skapandet och sändningen av en skärmdump genom att generera händelsen screen_capture. Problemet klassificeras inte som en sårbarhet, eftersom WebSocket endast användes i interna testbyggen och användningen av denna kommunikationskanal endast planerades i framtiden för att organisera interaktion med ett webbläsartillägg.
Källa: opennet.ru