[CKAN-Security] CKAN security vulnerabilities

Wed Apr 27 01:03:36 UTC 2016

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
> >>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.okfn.org/mailman/private/security/attachments/20160427/f6b7787a/attachment-0001.html>