There is no privacy without security.
First, I would like to scare everyone a little bit in order to have people appreciate the extent of this statement.
As the figure that opens the post indicates, there are thousands of vulnerable Owncloud/NextCloud instances out there. It will surprise many just how easy is to detect those by trying out common URL paths during an IP sweep.
But let’s hear all this from NextCloud creator himself
It certainly is a good amount of work keeping your system secure and up to date, but we have to think that we risk exposing our most private data.
Let our analysis begin.
At the end of the day, NextCloud is a web service that needs to be run on a system. This means that the system needs to be secure as well as the web application. I will use NextCloudPi as an example, but many things will apply to other installations.
Let’s see how NextCloudPi deals with this
- Unattended security updates: NextCloudPi automatically applies the latest security patches.
- Fail2Ban brute force protection: not only for NextCloud but also for SSH
- HTTPS by default: any attempt to use HTTP will be redirected to HTTPS
- HTTP Strict Transport Security (HSTS)
- Let’s Encrypt CA signed trusted certificates.
- ModSecurity WAF: web application firewall configured to work with NextCloud
- TLSv1.2: NextCloudPi only accepts modern cryptographic protocols.
- Strong Forward Secrecy: ECDH based CipherSuites.
We will explain these more in the last section.
From the NextCloud developers side, they already do quite a bit.
They use secure configurations whenever they can. We can see how they try to protect the user in different places of their code. More on that later.
They also provide very nice documentation on hardening your system, and warn the user whenever an update is available, and perform really helpful checks in the admin page.
One thing that they have yet to improve, as they admit in the video, is the ability to roll out automatic security updates for NC the in the way WordPress already does. That is challenging but if properly done, it would definitely help deal with the current situation of so many outdated installations.
I understand those people. It is the third time I upgrade my personal cloud and it is really time consuming. It is one of the reasons I came up with NextCloudPi, as I have automated the process not only for myself, but for other people.
Other nice security features were added to NC 11, such as two step verification, CSRF protection, built-in brute force protection and more. You can check them out in this article.
For a list of vulnerabilities you can check this database.
NextCloud Security Scan
However, not everything is under the control of the developers. The system where NC runs is not, for example, and that is why they have come up with an online service where you can assess how vulnerable your NC installation is.
I resurrected an old OwnCloud 8 instance that I had lying around and compared to the latest NextCloudPi based on NC 11.0.2. Let’s see the results, and we will explain some of the vulnerabilities in the last section.
Good job, NC developers!
SSL Labs provides an amazing free service to test the security of your server.
NextCloudPi passes with flying colors! We will discuss some of the vulnerabilities and protections in the last section.
We can harden the security even more by specifying that we only allow TLSv1.2. We can do so by using the following line of configuration
SSLProtocol -all +TLSv1.2
The implication of this is that older browsers will not be able to access our cloud. In my opinion that is just fine, because we benefit from having a smaller attack surface not only for known vulnerabilities, but also for potential new ones that can be discovered for the older protocols.
If this is not desireable, for instance because your phone is Android < 4.4, it is okay to leave it as
SSLProtocol all -SSLv2 -SSLv3
The compatibility with older clients is now greatly expanded.
Finally, we can see what other vulnerabilities are present in our system
These are other free services where you can have your website security evaluated.
If you would like to know a little bit more about some of the weird acronyms and concepts that have been appearing throughout this post, a brief explanation follows.
First, let’s look at the response headers from our NextCloud instance related to security
- Strict-Transport-Security, abbreviated HSTS, is a security mechanism where the server tells the browser that only HTTPS can be used. The browser will refuse to connect if the certificate can’t be trusted or through normal HTTP, and will automatically convert any link that uses HTTP to HTTPS.
- The server signature is hidden, through the use of ModSecurity as explained in this post.
- X-Frame-Options: “SAMEORIGIN”, specifies that only frames originating in your cloud can be rendered. This is a protection against clickjacking.
- X-XSS-Protection: “1; mode=block”, configures Internet Explorer to block any XSS attempt, which means that only scripts hosted in your cloud will be executed.
- X-Content-Type-Options: “nosniff”, disables MIME type sniffing in Internet Explorer which is an unsafe feature that can be subject to attacks by specially crafted downloads of resources.
- X-permited-cross-domain-policies: “none”, disallows embedding of your content in other media, such as PDF and Adobe Flash. The server will refuse such requests.
- content-security-policy, also known as CSP, is a mechanism where the server instructs the browser what types of data are going to be served. The client will whitelist those and refuse all others.
- X-Firefox-Spdy: “h2”, indicates HTTP/2, which de facto only works with HTTPS, as major browsers decided only to serve HTTP/2 over HTTPS.
Most of these security headers are put in place by NextCloud, and only HSTS, hiding server signature and using HTTP/2 are part of the server configuration of NextCloudPi.
Also, NextCloud has protection against cross site request forgery (CSRF) attacks. Places like lib/base.php and core/ajax/update.php provide same site cookies and checks for the validity of the requests.
CSRF are attacks that take advantage of the fact that you are logged in and NC trusts you, so for instance they can insert a malicious URL in an image in another tab in another website that performs an authenticated operation on your system, say changing the admin password.
As soon as you open the tab and the browser tries to load the image at that URL the malicious operation triggers, because you have an active session cookie in the same browser.
The most straightforward way to prevent this is to create random session token and to require it in every request. The code in the malicious tab has no way of knowing it because it was not served by the legitimate web server.
TLS fallback attacks
The encryption protocol that the web uses nowadays is TLS. TLS is the replacement for the older SSL, which is around 20 years old and still around on some clients.
I will quote this excellent source
There are five protocols in the SSL/TLS family: SSL v2, SSL v3, TLS v1.0, TLS v1.1, and TLS v1.2:
SSL v2 is insecure and must not be used. This protocol version is so bad that it can be used to attack RSA keys and sites with the same name even if they are on an entirely different servers (the DROWN attack).
SSL v3 is insecure when used with HTTP (the POODLE attack) and weak when used with other protocols. It’s also obsolete and shouldn’t be used.
TLS v1.0 is also a legacy protocol that shouldn’t be used, but it’s typically still necessary in practice. Its major weakness (BEAST) has been mitigated in modern browsers, but other problems remain.
TLS v1.1 and v1.2 are both without known security issues, but only v1.2 provides modern cryptographic algorithms.
TLS v1.2 should be your main protocol because it’s the only version that offers modern authenticated encryption (also known as AEAD). If you don’t support TLS v1.2 today, your security is lacking.
A TLS fallback attack occurs when the a MITM tricks the browser and server into using a legacy insecure protocol in order to exploit it, so it can bypass TLSv1.2.
It is a downgrade attack caused by browsers not being strict in the protocol negotiation and allowing vulnerable protocols to go through. There is good information on this page, but it sums up to “browsers decided they prefer to render all pages rather than refusing to work with buggy servers”. This is browsers wars for you.
The mechanism to deal with this situation is TLS Fallback Signaling Cipher Suite Value (SCSV), which allows the browser to signal a server that it indeed supports the newest protocol while at the same time, saying that it supports the old suite for the old buggy servers to accept it. A modern server that is able to read this extra information will act in consequence and refuse the protocol downgrade.
There is a number of important attacks based on this, like
You can see that NextCloudPi is protected against those in the SSL labs report, as the openSSL version that ships with NextCloudPi supports TLS_FALLBACK_SCSV.
This is easy to test. Let’s try to connect using TLSv1.1 but adding the extra info that we support TLSv1.2 with the TLS_FALLBACK_SCSV mechanism.
$ openssl s_client -servername 192.168.0.128 -connect 192.168.0.128:443. -fallback_scsv -tls1_1
140092628760216:error:1409443E:SSL routines:ssl3_read_bytes:tlsv1 alert inappropriate fallback:s3_pkt.c:1493:SSL alert number 86
140092628760216:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:659:
We can see how the server refuses the illegal downgrade.
Another option I recommend is to disable SSL2 and SSL3 altogether. Like I said before, there is not enough level of paranoia for your personal cloud.
This would be long to explain properly, but let’s just say that even if somebody cannot decrypt your communications right now, it does not mean that they cannot store them and wait until they can somehow get hold of your encryption keys and then be able to read the stored contents.
If your key negotiation protocol provides protection against this situation it is said to provide forward secrecy.
The classic way of key negotiation is the RSA-key exchange mechanism which does not provide forward secrecy, but is still used by the majority of sites because it requires less CPU power. Should the server’s private key ever be compromised, all stored communication with that server would be instantly available.
Key negotiation based on the Diffie-Hellman key exchange mechanism does provide forward secrecy because the keys are negotiated, used and then disposed of. Single use disposable keys.
NextCloudPi uses Cipher Suites based on DH key exchange and that is why the suites in the test results above all start with TLS_ECDHE_.
DH stands for Diffie-Hellman. EC stands for Elliptic Curve Cryptography, which is a mathematical method for only using keys that are intrinsically stronger (require less bits for the same amount of computing power required to break it). Put it altogether and you get Elliptic Curve Diffie Hellman Exchange.
So hopefully by now you have a grasp of what the security for your self hosted data implies. The TL;DR takeaway message from this post is
Use NextCloudPi, activate all security extras and update NextCloud whenever you receive an alert to do so
There is always more to be done, but this is currently where we are sitting at.
Suggestions and corrections are very welcome.