[CKAN-Security] Two more security issues

[David Miller]

Hi Adria,

I can't currently see the Gitlab issues - am I trustworthy enough for
access? :)

Re 1. Broadly, I'm happy to tell our pentesters "Can you come up with a
scarier exploit please" and see if they come up with anything.

I'm going to assume that the API endpoint that exposes SQL as a parameter
has been really really thoroughly pentested already though ? ;)

Are details of the results of such reports available anywhere?

Re 2. the pentesters certainly thought that you could get it to execute -
they sent me a screenshot of an alert box - they've not left the proof of
concept on our instance though, I can ask them what the exact parameter was.

HTH

Best,

David Miller
Open Health Care

On Mon, 10 Aug 2015 at 12:46 Adrià Mercader <adria.mercader at okfn.org> wrote:

> I've added my comments to the security repo
>
> Tl;DR: they look superscary in a pentest report but the actual effects on
> CKAN don't seem to be as severe.
>
> In any case there might be something that I'm missing and we'll discuss
> them among all core devs tomorrow on the dev meeting. I'll keep you posted
> of any decision.
>
> Here are my comments, if you can provide additional details that would be
> great:
>
> 1. SQL Injection
>
> The datastore_search_sql endpoint obviously accepts an SQL string as
> parameter. Is this the concern raised or is there a specific SQL statement
> that they think presents a threat?
>
> This is the statement on the screenshot (in case someone doesn't want to
> type it again!):
>
> (SELECT (CHR(113)||CHR(106)||CHR(107)||CHR(100)||CHR(113))||(SELECT (CASE WHEN (2110=2110) THEN 1 ELSE 0 END))::text||(CHR(113)||CHR(97)||CHR(106)||CHR(104)||CHR(113)))
>
> As far as I can tell, as scary as this looks like is only generating a
> string from the character codes supplied, with a 1 in the middle for good
> measure:
>
>
> http://demo.ckan.org/api/action/datastore_search_sql?sql=%28SELECT%20%28CHR%28113%29||CHR%28106%29||CHR%28107%29||CHR%28100%29||CHR%28113%29%29||%28SELECT%20%28CASE%20WHEN%20%282110=2110%29%20THEN%201%20ELSE%200%20END%29%29::text||%28CHR%28113%29||CHR%2897%29||CHR%28106%29||CHR%28104%29||CHR%28113%29%29%29
> <http://demo.ckan.org/api/action/datastore_search_sql?sql=%28SELECT%20%28CHR%28113%29%7C%7CCHR%28106%29%7C%7CCHR%28107%29%7C%7CCHR%28100%29%7C%7CCHR%28113%29%29%7C%7C%28SELECT%20%28CASE%20WHEN%20%282110=2110%29%20THEN%201%20ELSE%200%20END%29%29::text%7C%7C%28CHR%28113%29%7C%7CCHR%2897%29%7C%7CCHR%28106%29%7C%7CCHR%28104%29%7C%7CCHR%28113%29%29%29>
>
> The current user and the current database they might have got using #10
> <https://gitlab.com/ckan/ckan-security/issues/10>
>
> #10 refers to the ability to run internal functions like
> current_database() (
> http://demo.ckan.org/api/action/datastore_search_sql?sql=select%20current_database%28%29
> )
>
> The consensus among devs is that although it would be nice to prevent
> these calls they are actually not giving away that much details that eg
> couldn't find consulted on publicly available deployment scripts on most
> instances. And most importantly, the datastore_search_sql endpoint runs on
> a connection that uses a read-only user, so even if people could craft an
> statement that affected the db they wouldn't have the permissions to run it.
>
> Of course, all this needs to be explained somewhere in the docs or in a
> statement.
>
>
>
>
> 2. XSS on description group
>
> It does end up like <script>alert(1)</script> but AFAICT it doesn't get
> interpreted?
>
> http://i.imgur.com/YwAldvR.png
>
>
>
> On 7 August 2015 at 11:43, Ross Jones <ross at servercode.co.uk> wrote:
>
>> Hi,
>>
>> David (CC'd) has kindly allowed me to check out the pentest that was
>> performed on his/our CKAN instance, and so I'm adding the two top-level
>> items so that we can discuss them - I'll add them to the gitlab issues list
>> today so that we can track them.
>>
>> 1. SQL Injection
>>
>> Problem: It was found that one of the API pages used in your application
>> accepts SQL statements as a GET parameter which can allow an attacker to
>> run arbitrary database queries (we sort of knew this ;) ).
>>
>> Result: SQLMap found it was possibly (with a rather convoluted query) to
>> obtain the name of the database, and the name of the user that is
>> connecting to the database.  SQLMap does this as a PoC, but shows that it
>> is possible to bypass any checking that is performed to obtain information
>> that isn't really public.
>>
>> 2. XSS on description field in group
>>
>> Problem: It was found that when the application displays descriptions of
>> collections which may be created by users, it does not correctly filter
>> special characters such as HTML tags (<).
>>
>> Result: This vulnerability could enable users who unwittingly click on a
>> malicious link to leak private information to attackers. This information
>> typically includes cookies which provide access to the user’s account and
>> session.
>>
>> I'm pretty worried by 1, so will be adding a PR soon to allow admins to
>> disable this functionality if they wish.  I haven't checked this specific
>> code, is anyone confident that it *can* be fixed to be secure? Seems like
>> the type of code that everyone will be chasing down edge cases on forever.
>>
>> Cheers
>>
>> Ross.
>>
> _______________________________________________
>> 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/20150810/f787bdfd/attachment-0001.html>