[CKAN-Security] CKAN security vulnerabilities

Tue Apr 12 00:27:04 UTC 2016

Thanks Adrià and Ian.  I didn't receive Ian's response directly for some
reason.

I've been given permission by OEH to disseminate the report with the tech
team; it is attached.  The password for the report is LqZr4f$z3m The report
is well written and should provide any of the additional detail including
suggested fixes.

We've also been advised that OEH doesn't wish to hold up our launch, which
is great as it gives us time to develop good solutions.

Responses to some of Ian's questions:

*Third-Party JavaScript Library Inclusion*

The issue is just that if the 3rd party was malicious, they could provide
any code that will run in the same origin. This could potentially happen
also if the 3rd party was compromised. Our site is loading from ShareThis
and Google (via ckanext-googleanalytics).  Personally I think it is
sufficient to mitigate this by being selective about when to do this. I
don't have any particular concerns about these two.

*Weak Password and Account Lockout Policy*

Length and complexity requirements and password expiry seem to be common
elements of corporate security policies we see. I think this would be the
basic requirement.  Additional features might be include:

   1. Prevention of password re-use
   2. Prevention of passwords with dictionary words or user's name/email
   3. Some form of account lockout to foil brute force attacks

There are a couple of Drupal modules (Password Policy
<https://www.drupal.org/project/password_policy>, and Password Strength
<https://www.drupal.org/project/password_strength>) that take slightly
different approaches to password complexity that might be useful references.

*Concurrent Logins*

Perhaps this could be configurable so it can be set according to
organisational policy.

*Application Reverted to HTTP upon Successful Authentication*

For this client we've set up an HTTPS-only CKAN. Tracking the sequence of
requests that occur during login, CKAN twice redirects from HTTPS to
"/user/logged_in" over plain text HTTP. I haven't investigated so I'm not
sure whether this happens because of some misconfiguration in our
application or because that's how CKAN does it however I have reproduced it
with CKAN 2.4.3 without ckanext-saml2. We've mitigated it with
Strict-Transport-Security headers and correct cookie configuration. I'll
provide more detail about config once it's logged if required.

Cheers
Mark

*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

On 11 April 2016 at 18:47, Adrià Mercader <adria.mercader at okfn.org> wrote:

> Thanks Mark,
>
> Nothing to add to what Ian said, just clarify that the latest 2.4.x
> release is 2.4.3
>
> Will discuss these on tomorrow's meeting.
>
> Cheers,
> Adrià
>
>
> On 9 April 2016 at 19:04, Ian Ward <ian at excess.org> wrote:
> > 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
> > _______________________________________________
> > CKAN security
> > https://lists.okfn.org/mailman/listinfo/security
> >
> https://lists.okfn.org/mailman/options/security/adria.mercader%40okfn.org
> >
> > Repo: https://github.com/ckan/ckan-security
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.okfn.org/mailman/private/security/attachments/20160412/b378c0f2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NCCGroup_34921_201603_OEH_Open OEH Pre-Launch and API Security Testing_Report_v1.0.pdf
Type: application/pdf
Size: 1863931 bytes
Desc: not available
URL: <https://lists.okfn.org/mailman/private/security/attachments/20160412/b378c0f2/attachment-0001.pdf>