Nextcloud releases security scanner to help protect private clouds


Our job is to help you stay in control over your data. Nextcloud is designed to be the easiest, most secure private cloud available. To keep it safe, it is important to keep your server up to date and we introduce the Nextcloud Private Cloud Security Scanner to help you with that. The results of our analysis have been covered in an article you might have seen on Der Spiegel.

We help you keep your data yours

Last year, Dropbox lost data from 68 Million accounts, and Yahoo famously had data from no less than 1 billion accounts compromised. People who run a private cloud server like Pydio, ownCloud or Nextcloud presumably do so to keep their data from prying eyes. Sadly, privacy means little without security and it is not trivial to keep a server secure.

Frequently, security researchers find new ways to break cryptographic systems or mistakes are found in the software you run. Where many software companies tend to try to hide security issues in their software, only to be exposed when massive dumps of user data are found on the dark web (Yahoo kept its breach secret for 3 years!), Nextcloud strives to be transparent while developing new, innovative security capabilities. The reality is that any complex piece of software has security issues and finding and fixing them is a more effective way of dealing than the Ostrich Method. We pay security researchers up to USD 5000 rather than sueing them or letting their reports fall on deaf ears, a tactic that has been proven to work well. A result is frequent updates with security related fixes.

To help you keep your system up to date, Nextcloud made updating Nextcloud servers super easy. Our new updater notifies system administrators of new versions and once started by them, automatically checks if all dependencies are there, makes a backup and then replaces the files on your server with the new version. We know updating still requires a bit of work and attention, so we keep working on lowering the barrier to an up to date and secure system.

Introducing the Private Cloud Security Scanner

From what people tell us at events and online, we know many servers still are not kept updated. That often comes with big security risks. Some problems in older versions enable an attacker to take over a server completely; others allow unauthorized downloading of some or all of the data on the server! It is the nature of security in software development that running old, un-updated versions is a risk. Also a legal risk, as Europe has strict General Data Protection Regulation.

To help you assess the security of your private cloud server, Nextcloud has developed the Private Cloud Security Scanner. By entering the URL of your server, you can learn if there is a newer version of your private cloud software and what vulnerabilities exist in the one you are currently running. A few simple checks are also done to assess other security settings on your server.

Please note that the scanner merely does a very simple, basic check, inquiring from the server what version it runs and analyze the response. No ‘hacking’ attempt is made, and there are many other things which can be broken that this minimal scan does not see.

Looking on the web

While developing the security scanner we had a look at the state of security of private cloud servers online. Many administrators might not be aware how easy it is to get a list of servers on the web! Services like shodan.io provide the ability to search for specifics and it is simple to get a list of tens of thousands of instances and look at them.

We quickly realized a VERY large percentage was insecure. Many hundreds of servers had such severe vulnerabilities they could be taken over entirely. Data from thousands can be downloaded trivially and tens of thousands more are vulnerable with only a little bit of work on part of the attacker, like obtaining a sharing link. About two-thirds of the servers we looked at were vulnerable. With an estimated 200K-300K servers out there it extrapolates to a scary large number. We did not feel any better looking at the specific URLs, seeing political parties, hospitals, universities, large corporations and governments in the list of insecure servers.

At this point, we decided we should warn the administrators of these instances. Of course, a blog or tweet would not make much difference as some had not upgraded for years. And publicity could encourage people with more nefarious goals to look at these servers and try to break in. The events around a Drupal vulnerability have shown that, within hours of public disclosure, it might already be too late to patch servers.

Instead, we alerted security organizations in various countries like the BSI in Germany and SWITCH in Switzerland and discussed what to do. They decided to reach out to users with a personal warning, including the results of the scan. We made sure the security scan would not expose any private data, using unique IDs instead of URLs to present them the results and we kept as quiet as possible on our communication channels about this matter.

Results

The effort has been quite successful. Of the tens of thousands server owners who were informed, over 5% had upgraded already in the first ten days. We noticed that especially the administrators of the more active and heavily used servers responded by upgrading, securing a large number of user accounts.

But we could only see and contact a subset of the total number of servers out there. Despite our significant efforts, we estimate that there are at least another 100.000 insecure private cloud servers out there we have not been able to warn. This is where, among other things, this blog post comes in: we hope to enlist the community in our efforts to reach out and get as many private cloud servers upgraded as soon as possible to the latest release of whatever software they run, explaining to system administrators how important this is. If needed, you can use information from this blog by Lukas to explain the dangers. And, of course – the article on Der Spiegel.

Future

Nextcloud has been working hard on making it easier to keep your system up to date. We rewrote the update tool for Nextcloud 10, making it easy to use it from the command line in Nextcloud 11 and Nextcloud 12 will no longer disable apps when doing a security update, making the updates less intrusive. More improvements are being worked on. Our ultimate goal is to make updates so seamless they can be done fully automatic without any administrator involvement or downtime. At this moment, we have achieved this on the Nextcloud Box, using Canonical’s Snap technology which automates updates entirely. You can read more about that in this whitepaper.

We also plan to improve the security scan. From today you can use it to scan your own server and see what the security state is, and we have already invited other open source private cloud projects to work with us and make it possible to scan their software as well. ownCloud has responded by creating their own scan.

More information

If you are wondering what the dangers are of using an outdated private cloud server, Lukas has written a great analysis of the risks and Spiegel Online has a more political view on what this kind of issues can mean for our society.

If you currently run a private cloud server like ownCloud or Nextcloud you can follow our extensive instructions on how to get updated to a secure release!

If you want to know what this entire private cloud thing is all about, read this article on CIO.com

Thanks

We would like to thank everybody who has been helping us reach out to server owners, including Der Spiegel and other press, both for keeping this quiet to give server owners time to upgrade and for helping explain the risks now.

Notable Replies

  1. Is it possible to perform this scan with NAT closed environments? :slight_smile:

  2. Haven't you just :slight_smile:

  3. ah i am stupid... I've written http.// instead of https://

  4. Hi,

    This tool look awesome, is there some kind of API ?
    I explain myself: I'm administrating several Nextcloud instances and I would be very usefull for me either to run a script that check that each instance is up to date and safe or run the scanner on each server periodically and receive a report by e-mail if something should be done.

  5. Hello!

    I get the same error as @jakobssystems but hopefully without doing a typo.
    I have tried with and without https:// and scan.owncloud.com works.

    URL:
    https://nextcloud.mydomain.com
    Version:
    11.0.1.2
    Issues:
    No vulnerabilities
    Thank you for being up to date and caring about ownCloud security. To keep you informed you might want to sign up to our newsletter.

    I followed @riegerCLOUD install guide and I use geoip and nginx. Is the server located in Germany? DE should be allowed and I tried to disable geoip but it does not work. Any idea?

  6. One of our hosting providers for the scanner doesn't support IPv6 at the moment. Thus the scanner won't be able to detect IPv6 hosts.

  7. Did you try to call them and ask for IPv4? I just moved my server from IPv4 only provider to IPv6+DS-Lite, found out about all the problems related to it, called them and instantly got switched to dual stack :smiley:.

  8. The results don't match for many clients i support. Neither the shown URL nor the domain host_prefix fit.
    Most results are obsolete, so my question is how to force a rescan?
    If I press the icon for rescan and wait for more than the suggested 5 minutes nothing changed since days.
    I would really appreciate any kind of assistance. Thanks in advance. Carsten

  9. Soko says:

    After the rescanning, you need a reload (strg + F5)...

    By my first try, the Url wich should be https://mycloudsname.com was shown as https://mycloudsname.com/owncloud

    In my apache conf I had
    Alias /owncloud "pathToTheCloudDir"

    After commenting this entry out, the test showed me the right url...

    So I think the test seeks for "known" urls and the first of it is shown, also if this is not the url of the cloud...

  10. Hi Soko, unfortunately STRG+F5 doesn't solve this behaviour. Nextcloud is based on NGINX and doesn't point to any subdir since weeks. NGINX and REDIS were restarted several times ... what might help?

  11. Soko says:

    Yes, I can reproduce your issue, don't have a solution.

    Trying with https://nc.c-rieger.de/login makes a new scan and ends with no Installation found error...

    Scan failed! The scan for the specified domain failed. Either no Nextcloud or ownCloud can be found there or you tried to scan too many servers.

    Think nextcloud have to delete the scan from 17/02/20 out of their cache...

    @LukasReschke ???

  12. husky says:

    Suggestion:
    I set X-Frame-Options to ALLOW-FROM because of Collabora - maybe the scanner could report the returned header instead of simply complaining that it isn't set to SAMEORIGIN?

  13. mannp says:

    Great idea, thanks for this!

    I've made the tweaks and want to rescan, but its remembering me :frowning:
    How can I rescan please?

    Is their an option to clear cache the same as the ssl test website :slight_smile:

    Edit: Requested rescan and waited for a while, seemed more than 5 mins, but it didn't seem to rescan in front of my eyes but in the background? Maybe I am wrong there, but the rescan did occur and an A+

    Hopefully there will be some reminders in the gui to rescan if it hasn't been done for x period of time, so I don't forget to keep checking it in the future :slight_smile:

    Thanks

  14. I solved the rescan issue by disabling geoip in NGINX.
    After having restarted NGINX and pressed the icon for rescan, the new results were shown after few minutes.

    Nextcloud's scan-server seems to be located out of germany and out of US, that's why it failed for me regarding geoip.

  15. It solved my problem too. I don't know why it did not work last time when I changed geoip to "default yes;".

  16. sorry, the rescan only happens after about 8 hours I believe... It is a resource usage limitation.

  17. mannp says:

    Ok sure, but in my case the rescan seemed to happen automatically in the background in 10 minutes.

    Likely I was just lucky.

    Thanks :slight_smile:

  18. well, yeah, or maybe I'm wrong :wink:

  19. I understand that this scanner works by querying domain.com/status.php (and also searching for it in a couple of other locations). I applaud any efforts to increase security, as a large portion of my day job is IT security and this is a great initiative. However I have a few questions.

    1) The idea of having a /status.php page which can be queried by anyone un-nerves me a little. And in fact I've blocked public access to it on my server for now. Is there a better way of providing the information to the scanner. A POST request from the nextcloud server to the scanner could provide the same information and would not be leaking information. You could simply provide a Scan button in the admin interface, or a regular cron job.

    2) If status.php is required by clients (as suggested elsewhere), should it not be visible only after authentication?

    3) As well as the version info provided by status.php is there any other info assessed by the scan service to give the grade ( I'm guessing the presence of SSL is one element, perhaps some of the SSL parameters as well ... and ....what else?). Maybe we could figure out how to get those back to the scan server too.

  20. Asked the same thing and it essentially boils down to public APIs. At some point you need to know which APIs to access. You can ofc run requests against all your endpoints and see if they 404 but that's inefficient. You can ofc use a version in your API url or pass a version token. The issue with that is that it's a pain for forwards compatibility because you never know which new features you can use from an API standpoint.

    To solve that you could add an API call that tells you which API subversion you are dealing with and now you have arrived at the current status :smiley:

    Apart from that the version is not really an issue since automated attacks usually just brute force all vulnerabilities. Personally I'd also ignore the status.php since its more work to parse the version than just to try all known vulnerabilities starting with the latest one

  21. To remove your results please contact cloud-security-scan(at)nextcloud(dot)com.

    Nice avatar by the way :wink:

  22. I have my firewall locked down pretty tight and the scanner cannot seem to access my Nextcloud instance. This is likely due to the ip addresses used by the scanner being blocked by my server. Is there any chance you could post the ip addresses that the scanner is using or even which hosting provider it would be coming from so that I could unblock it.
    Thanks.

  23. Shouldn't this be "Nextcloud 10.0.3"?

    Rating
    A

    Running Nextcloud 9.1.3.2

    NOT on latest patch level

    Major version still supported

    Scanned at 2017-03-26 09:10:00

  24. Why not put the link to the scan also on the admin settings page?

  25. Yeah and also do the scan and show results in admin panel as part of the other checks that are done there anyway. It is important enough in my view to include this directly obvious into nextcloud than "just" give the link here that people might or might not recognize.

    But of course thanks for the scan anyway, this was/is already a great step. Would be just the consistent next step to make nextcloud even better in lifting security as topic into the view of every admin :slight_smile:.

  26. I just checked my apache log as regular task and found attempts from an france ip to access status.php in my webserver root (nextcloud is on a total different location), which fails, because no status.php in webroot :wink:.
    The attempt occurs every ~6 hours ~10 times at once for the whole time, my apache logs remain (~1 week now).

    This was discussed much and I agree that for security reasons there is a benefit to collect statistical data about clouds security and give webhosts with lack a hint. But this looks little aggressive, inefficient and floods my apache log quite much.

    Okay, this checks should not cost much server performance or traffic and therefore it should not matter much how unnecessary often they are done. But to not annoy admins too much, couldn't there be some intelligent sorting done somehow? I.e. usually the IPs change once a day by ISP, if no static IP is there. So I guess doing the check once (really once, stop after 1 error (file not found)) a day should be totally enough. For me it is done ~50 times a day...
    If there are static IPs known, there could be checked way less often. In my case I have a fix domain which I also used on scan.nextcloud.com.
    In such cases domains could be collected and IPs they are pointing to could be also excluded from the check, respectively they could be checked way less often, once a month or just after every nextcloud upgrade.

    Yaa, just some ideas, if this is actually under control of Nextcloud GmbH, maybe this is done totally external with no easy way to influence. However I will ban the related IP (was the same since beginning of log) now, taking care about my security myself, including running scan.nextcloud.com regularly :wink:.

  27. Just found the current ip address of the scans. They come from France: 51.15.140.197
    In regards to the problems some are having with being scanned too often, I think I'll just leave this address blocked in my firewall and unblock it whenever I do a major upgrade and want to scan security.

Continue the discussion The Nextcloud forums

6 more replies

Participants