Mozilla announced the completion of an independent audit of client software for connecting to the Mozilla VPN service . The audit analyzed a stand-alone client application written using the Qt library and delivered for Linux, macOS, Windows, Android and iOS. Mozilla VPN is powered by over 400 servers from Swedish VPN provider Mullvad in over 30 countries. The connection to the VPN service is made using the WireGuard protocol .
The audit was carried out by Cure53, which at one time audited NTPsec, SecureDrop, Cryptocat, F-Droid and Dovecot projects. The audit involved the verification of the source code and included testing to identify possible vulnerabilities (issues related to cryptography were not considered). During the audit, 16 safety problems were identified, 8 of which were of the nature of recommendations, 5 were assigned a low level of danger, two – medium, and one – high.
However, only one problem with a medium severity level was categorized as a vulnerability, since it was the only one that was exploitable. This issue leaked VPN usage information in the code for defining the captive portal by sending unencrypted direct HTTP requests outside the VPN tunnel that expose the user’s primary IP address if an attacker can control transit traffic. The problem is solved by disabling the captive portal detection mode in the settings.
The second problem of medium severity is related to the lack of proper cleaning of non-numeric values in the port number, which allows leaking OAuth authentication parameters by replacing the port number with a string like “firstname.lastname@example.org”, which will lead to the setting of the tag <img src = “http: //127.0.0.1:email@example.com/?code = … “alt =” “> accessing example.com instead of 127.0.0.1.
The third issue, flagged as dangerous, allows any local application, without authentication, to access the VPN client over a WebSocket bound to localhost. As an example, it is shown how, with an active VPN client, any site could organize the creation and sending of a screenshot by generating the screen_capture event. The problem is not classified as a vulnerability, since WebSocket was used only in internal test builds and the use of this communication channel was only planned in the future to organize interaction with the browser add-on.