WebDAV Api Authentication Bypass using Pre-Signed URLs

[cs35]

Hello everyone,

I’ve seen a CVE recently about WebDAV Api Authentication Bypass using Pre-Signed URLs
I’m not sure if it’s been fixed in a recent ownCloud server version, I couldn’t find a changelog related to this threat.
Is it already fixed in a specific version ? Will it be fixed soon ? Is there any way to circumvent this threat now, maybe some nginx/apache rules to forbid specific access ?

Thanks.

[alfredb]

Not sure, but I think this was addressed in 10.13.1.

ownCloud Server 10.13.1 released: Critical security fixes included

Please find below the changes and known issues in ownCloud Server 10.13.1 that need your attention. You can also read the full ownCloud Server changelog for further details on what has changed. Critical Security Updates - Upgrade As Soon As Possible This release and the updated apps below include critical security fixes which require your immediate attention. Please upgrade as soon as possible. Open in Web Improvements The “Open in Web” feature for direct editing of office documents now proper…

Fix: disallow pre-signed url access if the signing key is not initialized. #40962

[rusty]

As Alfred mentioned, it looks like there’s a fix in 10.13.1, implemented by including a check for an empty signing-key in lib/private/Security/SignedUrl/Verifier.php.

I’ve added this to Verifier.php on our installation (v10.8), and everything looks like it’s still working (so far…), but I was wondering whether anyone knew of a way to test the fix using CURL (or similar)?

I tried the following, but it gives the same result whether the fix is in place or not:

curl -X PROPFIND -H “Depth: 1” “https://server.domain.com/remote.php/dav/files/userid?OC-Credential=userid&OC-Verb=GET&OC-Signature=f9e53a1ee23caef10f72ec392c1b537317491b687bfdd224c782be197d9ca2b6”

Gives

<?xml version="1.0" encoding="utf-8"?>

<d:error xmlns:d=“DAV:” xmlns:s=“sabre/dav”>
<s:exception>Sabre\DAV\Exception\NotAuthenticated</s:exception>
<s:message>No public access to this resource., No ‘Authorization: Basic’ header found. Either the client didn’t send one, or the server is misconfigured, Invalid url signature</s:message>
</d:error>

The same URL (minus query parameters) works with curl -u userid, which suggests I’m getting something wrong with the query parameters.

Is there any documentation covering the use of pre-signed keys with the webdav API? I found an introduction to webdav here, but couldn’t see anything about using pre-signed keys.

Working back from the code in Verifier.php, it looks like each user would need to have an entry in oc_preferences with appid=‘core’ and configkey=‘signing-key’, but I wasn’t sure what format configvalue would take? Is it similar to an RSA private key? Is it something users could add themselves via the WebUI, or something admins could generate for them via occ, or by directly creating entries in oc_preferences?

Once a user has a signing-key, how would it be used? Are keys passed directly as the OC-Signature query parameter, or (as the name suggests) are they used to sign something else? In other words, what would someone need to share with a third party in order for the third party to use a pre-signed URL?

If we did generate signing-keys for all our users, would that have any implications for existing client connections (desktop sync client, etc - presumably not since they’re using password authentication?)

Many thanks

[tom42]

Hey,

@rusty

on our installation (v10.8)

it is not answering the question but i think this is generally a too old ownCloud version (released nearly 2 1/2 years ago) and personally i wouldn’t even start thinking to patch such an outdated version and update directly to the known fixed version 10.13.1 to be on the safe side.

[rusty]

Thanks Tom - you’re right of course, but I just wanted a quick fix until I get chance to update!

I’d still be interested to understand more about using/testing pre-signed URLs as the webdav API isn’t something I’m very familiar with.

[dahamsta]

The proposed “action taken” on CWE-665 is incredibly obtuse. What actually needs to be done to mitigate against this vulnerability?

[tom42]

Hey,

@dahamsta

What actually needs to be done to mitigate against this vulnerability?

i think it has been already mentioned in this thread that ownCloud needs to be updated to version 10.13.1 to mitigate this vulnerability.

Maybe we could also let the ownCloud people to know (unfortunately not sure where :-() to add this info to the advisory itself?

[rusty]

I wasn’t sure what the Action Taken (“Deny the use of pre-signed urls if no signing-key is configured for the owner of the files”) meant either, but after a bit of searching, I think it’s only possible to do this by modifying the code. As far as I can see there’s no way it can be done though existing admin interfaces (WebUI, occ, etc).

That means the only options are to update to 10.13.1 (the best option), or to add a couple of lines of code to Verifier.php. The code you need to add is available here (with the caveat that this was written for 10.13.1 and might not work/might break things in other versions. I’m using it with 10.8 and it doesn’t seem to be causing problems).

Another option would be to add signing-key values to the oc_preferences table for all your users. I don’t think there are any constraints on the signing key values, they can be string, although you’d probably want to choose a reasonable length value. The signing key values are eventually passed to the php function hash_pbkdf2 as the salt parameter and used to calculate a hash of the URL (by default, hash_pbkdf2(“sha512”, <URL>, <Signing key>, 10000, 64, false))

[tom42]

Hey,

i also think that the Action Taken actually is referring to the actions taken by the ownCloud people to mitigate this vulnerability and not to the actions which needs to be done by the users like us. Otherwise i think the wording would be different (e.g. Actions which needs to be taken).

[hodyroff]

Correct. The proper action is to upgrade to 10.13.3 immediately. That is the newest version we are currently shipping.