To provide transparency into our ongoing efforts to protect your privacy and security on the Internet, we are releasing a security audit of Mozilla VPN that Cure53 conducted earlier this year.
The scope of this security audit included the following products:
- Mozilla VPN Qt5 App for macOS
- Mozilla VPN Qt5 App for Linux
- Mozilla VPN Qt5 App for Windows
- Mozilla VPN Qt5 App for iOS
- Mozilla VPN Qt5 App for Android
Here’s a summary of the items discovered within this security audit that were medium or higher severity:
- FVP-02-014: Cross-site WebSocket hijacking (High)
- Mozilla VPN client, when put in debug mode, exposes a WebSocket interface to localhost to trigger events and retrieve logs (most of the functional tests are written on top of this interface). As the WebSocket interface was used only in pre-release test builds, no customers were affected. Cure53 has verified that this item has been properly fixed and the security risk no longer exists.
- FVP-02-001: VPN leak via captive portal detection (Medium)
- Mozilla VPN client allows sending unencrypted HTTP requests outside of the tunnel to specific IP addresses, if the captive portal detection mechanism has been activated through settings. However, the captive portal detection algorithm requires a plain-text HTTP trusted endpoint to operate. Firefox, Chrome, the network manager of MacOS and many applications have a similar solution enabled by default. Mozilla VPN utilizes the Firefox endpoint. Ultimately, we have accepted this finding as the user benefits of captive portal detection outweigh the security risk.
- FVP-02-016: Auth code could be leaked by injecting port (Medium)
- When a user wants to log into Mozilla VPN, the VPN client will make a request to https://vpn.mozilla.org/api/v2/vpn/login/windows to obtain an authorization URL. The endpoint takes a port parameter that will be reflected in a <img> element after the user signs into the web page. It was found that the port parameter could be of an arbitrary value. Further, it was possible to inject the @ sign, so that the request will go to an arbitrary host instead of localhost (the site’s strict Content Security Policy prevented such requests from being sent). We fixed this issue by improving the port number parsing in the REST API component. The fix includes several tests to prevent similar errors in the future.
If you’d like to read the detailed report from Cure53, including all low and informational items, you can find it here.
More information on the issues identified in this report can be found in our MFSA2021-31 Security Advisory published on July 14th, 2021.