[CKAN-Security] CKAN security vulnerabilities

[Ian Ward]

On Sat, Apr 9, 2016 at 2:35 AM, Mark Gregson
<mark.gregson at linkdigital.com.au> wrote:
> A client of ours has recently had some penetration testing conducted on a
> couple of CKAN 2.4.1 applications we've been working on.  Here is the
> summary of the issues reported by the security consultants that I think
> relate to core CKAN, along with some of the suggestions to mitigate these
> risks.  I haven't tested that these vulnerabilities exist in later versions
> of CKAN or whether issues have already been logged.

CKAN 2.4.1 is no longer supported. please upgrade to 2.4.4 as soon as possible.

> The risk ratings were provided by the security consultants based on their
> own calculation of the CVSSv2 score.
>
> I'm happy to provide more info from the consultant's report if you wish but
> I should probably check this with our client first.
>
> I'm also happy to log these in the private security issue repo if you grant
> me access.

We'll discuss this at our next meeting. I think giving you access to
the security repo would be the easiest way to track these issues.

> What we don't know yet, is which issues we will have to resolve prior to our
> launch date in 1-2 weeks. We're assuming the high rated issues and
> potentially some medium issues. We're happy to implement fixes but tech team
> direction to help with general solutions would be great.
>
> Cheers
> Mark
>
>
> High
>
> Resource Proxy server-side request forgery - the resource proxy can be used
> to return results from within the server's local network, or other networks
> it has access to. Protection can come from configurable protocol and port
> restriction, and a configurable blacklist with appropriate defaults (e.g.,
> block localhost). A configurable whitelist may be useful in some use cases,
> including ours. There is a Python library that wraps requests, called
> Advocate, that is designed to prevent SSRF attacks.

This one hasn't been reported before. I've added it to our security
repo as issue #18. I believe this will only affect some ways of
deploying CKAN.

> No restriction of uploaded files types - allowing upload of HTML or SWF with
> client-side script, malware, etc.  May be able to easily mitigate this
> somewhat with file type check but adding malware/virus scanning would grant
> greater protection.

We are aware of this one, our security issue #1. We've discussed using
server headers to force download of any uploaded files, but noone has
submitted an implementation yet.

>
>
> Medium
>
> Cross-site-request forgery - user tricked into browsing to a malicious HTML
> page could be used to access restricted functionality in the site, e.g.,
> user privilege elevation

We're aware of this one too, our security issue #5. This one will take
quite a bit of work to fix.

> JSONP Cross-Site Script Inclusion (XSSI) - user tricked into visiting a
> malicious HTML page could extract user's API key. Prevent user_list and
> user_show from returning the API key.

This one should be fixed in more recent CKAN releases (certainly 2.4.4)

> API accepts cookie authentication - makes the API vulnerable to the CSRF and
> XSS attacks.

We're aware of this one as well and it has been discussed as part of
security issue #5. When CSRF protection is added we can update the API
to only accept cookie auth when the CSRF token is sent as well.

> Weak Password and Account Lockout Policy

Would you make some specific suggestions for improvements?

> Third-Party JavaScript Library Inclusion

Would you go into more detail on this one?

>
>
> Low
>
> Ineffective Session Termination - as tested, cookies from terminated
> sessions could be successfully re-used later. * Possibly our implementation
> with ckanext-saml2

Yes, our cookies can be improved, we have discussed this before. One
of my colleagues may be spending some time on this one soon.

>
> Cacheable HTTPS Responses

Would you give some more detail on this one?

>
> Concurrent Logins Allowed - allows multiple logins for a single user,
> including from multiple IP addresses * Possibly our implementation

I see that as a feature. :-) Some users (like me) will be proxied
through a range of IP addresses or want to be logged in from multiple
devices.

>
>
> Info
>
> Insufficient defence against clickjacking

Would you provide some more detail on this one?

> Application Reverted to HTTP upon Successful Authentication * Possibly local
> implementation

Would you give some more detail here? We would like to enable secure
cookies for sites that always serve over HTTPS, is that what you mean?

> Self-Registration Allows Registration of Reserved Usernames - "register" and
> "reset" were not blocked from users registering these usernames, suggestion
> is also to block authoritative sounding usernames such as "admin" and
> "administrator" which could facilitate social engineering techniques.

Yes, this is a problem. I've added this as security issue # 19

> API Exposes Hashed Email Address

We've discussed this before. The gravatar icon service uses these
hashes and they are necessarily part of the page when using gravatar.
If you've removed gravatar from your theme it would be nice to hide
the hashed emails I suppose.

>
>
>
>
> MARK GREGSON  |  DEVELOPMENT TEAM LEAD
> Link Digital
>
> www.linkdigital.com.au
> p: 02 6111 2907 | f: 02 6248 5582
> GPO Box 199 Canberra ACT 2601
> 5/32 Lonsdale Street Braddon ACT 2612
>
> _______________________________________________
> CKAN security
> https://lists.okfn.org/mailman/listinfo/security
> https://lists.okfn.org/mailman/options/security/ian%40excess.org
>
> Repo: https://github.com/ckan/ckan-security