[CKAN-Security] CKAN security vulnerabilities

Thu Apr 28 01:49:37 UTC 2016

I can get it, that's great, thanks.  I'll have a look and log new issues,
comment, etc.

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 27 April 2016 at 22:37, Adrià Mercader <adria.mercader at okfn.org> wrote:

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