When running the desktop client for the first time, users can click the “Register with a provider” button to sign up for a Nextcloud account with a Nextcloud cloud provider. Clicking “Register…” opens a web page in a Nextcloud desktop client window with content from https://nextcloud.com/register.
However, the desktop client doesn’t appear to validate the SSL certificate for nextcloud.com. An attacker between the user and nextcloud.com could replace the certificate with their own invalid cert and conduct a man in the middle attack. The attacker could control the page content displayed to the user.
This appears to affect Windows and Linux Nextcloud desktop clients. I don’t have a Mac so haven’t tested the Mac client.
If you have Burp HTTP proxy, set the Nextcloud client to proxy traffic through Burp. Click “Register with a provider”; Burp should receive the request. This demonstrates vulnerability presence because the Nextcloud client should alert on Burp’s self signed certificate, but doesn’t.
Otherwise, I wrote a quick python script to demonstrate the vulnerability. You will need at least 1 Linux machine to run the script on. You can run Nextcloud desktop on it too or on another device.
I’ve attached a screenshot of what the Nextcloud client should show after clicking “Register with a provider” if the reproduction steps worked.
Tested Nextcloud desktop client version 2.6.4stable (build 20200303) on Ubuntu 18.04 and Windows 10. If I can provide further information please let me know. Thanks!
An attacker can serve untrusted HTML, Javascript, etc in the trusted context of the desktop client. A typical user is likely inclined to trust what is shown to them in the Nextcloud app compared to a web browser page; they won’t even know it’s web content necessarily and may assume it’s native to the Nextcloud client.
A likely attack vector would be to replace the content with a fake login page and try to get the user to login. If the user clicks “Register with a provider”, a window asking them to “Sign in with Google/Facebook/Apple to access your new Nextcloud account!” or similar might net the attacker something useful. Such an attack would probably have a decent success rate given the circumstances.
If an attacker just passively eavesdrops on the user’s traffic, near as I can tell the attacker can collect the user’s email as it gets POSTed to nextcloud.com during the registration process. A user’s email is private, but the usefulness to an attacker seems limited without other associated user information.