[CKAN-Security] CKAN security vulnerabilities

Wed Apr 27 12:37:03 UTC 2016

Hi Mark,

I've added to the repo members now so you should be able to access the
issues and create new ones:

https://gitlab.com/ckan/ckan-security/issues

The best way is probably to create the issues on this repo and discuss
implementation details in there as comments.
We've created a couple of them from your report to get started, feel
free to create additional ones as needed.

Looking forward to some patches!

Adrià

On 27 April 2016 at 02:03, Mark Gregson <mark.gregson at linkdigital.com.au> wrote:
> Thanks Adrià. For the moment, that person can be me.  My gitlab.com username
> is mgregson486
>
> 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 26 April 2016 at 20:19, Adrià Mercader <adria.mercader at okfn.org> wrote:
>>
>> Hi Mark,
>>
>> Apologies for this, this was definitely raised in the dev meeting at
>> some point (and agreed that someone from Link Digital should have
>> access).
>> Can you or whoever is best placed on your side create a user on
>> gitlab.com and send me the user name? I'll add it as a collaborator on
>> the repo so he or she has access.
>> On today's dev meeting (staring in 40 min) we'll go through the issues
>> and discuss the high level approach for each.
>>
>> Best,
>>
>> Adrià
>>
>> On 26 April 2016 at 06:29, Mark Gregson <mark.gregson at linkdigital.com.au>
>> wrote:
>> > Hi Adrià and Ian
>> >
>> > Just following up on this.  We've been asked by our client to provide
>> > some
>> > recommended changes to mitigate the identified security vulnerabilities
>> > and
>> > timeline. I'd very much prefer I can get back to them with technical
>> > approaches discussed agreed with the CKAN tech team.  The next step from
>> > my
>> > point of view is access to the security issue git repo. Has the tech
>> > team
>> > had an opportunity to discuss this yet?
>> >
>> > Kind regards
>> > 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 12 April 2016 at 10:27, Mark Gregson
>> > <mark.gregson at linkdigital.com.au>
>> > wrote:
>> >>
>> >> 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:
>> >>
>> >> Prevention of password re-use
>> >> Prevention of passwords with dictionary words or user's name/email
>> >> Some form of account lockout to foil brute force attacks
>> >>
>> >> There are a couple of Drupal modules (Password Policy, and 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
>> >>
>> >>
>> >
>
>