headers
Mini IT | 1 Jun 2011 17:21

Admin csrf vulnerability

Out of curiosity why is this not an issue?
I would think the ability to reconfigure and execute arbitrary commands 
on a server is a pretty big issue even if the chance of it happening is 
slim..

http://seclists.org/fulldisclosure/2011/Jun/0
"Vendor response: "This isn't an issue."

Problem: the cherokee server admin configuration web interface is
vulnerable to csrf.

Impact: if an admin is logged into the cherokee admin interface and
visits a site which runs "bad tm scripts" cherokee can be reconfigured
to run as $user and set log handlers(hooks) to execute arbitrary
commands (on error and on access)."
Permalink | Reply | 6 comments |
headers
MoròSwitie | 1 Jun 2011 19:06
Picon

Mysql AUTH sub-domain specific

I want to setup 1 virtual server
and have it map to the document root based on Domain name.

This is working correctly.
Now I also want to make password protect a special directory.
This is also working correctly.

Now I was wondering if the following is possible.
I would like to authenticate the user based on subdomain.

In order to do that I need to have the following vars available to the
mysql query
${domain}
${tld}
${domain_no_tld}
${subdomain1}
${subdomain2}

Currently only ${user} is available if I'm correct, I couldn't find
anythings in the documentation?
Permalink | Reply | 3 comments |
headers
Stefan de Konink | 1 Jun 2011 19:12
Picon
Gravatar

Re: Admin csrf vulnerability


So to summarize the problem is as follows:

If a user uses cherokee-admin, a remote page, given the remote page
knows that cherokee-admin runs at 127.0.0.1:9090, could grab or push
content to cherokee-admin.

Correct?

Stefan
Permalink | Reply | 0 comments |
headers
Jędrzej Nowak | 1 Jun 2011 19:16
Picon
Favicon

Re: Admin csrf vulnerability

The attack is not that easy as it looks like:
#1 you need to have admin on localhost:9090 (or any other known combination)
#2 you need to visit infected page (from the same browser - because
there is user/password protection)
#3 you need to submit 2 forms (with fake data) => one for changing
values, second for 'apply'.
#4 you need to know the current cherokee structure (otherwise
cherokee-admin will refuse it)

Greetings,
Jędrzej Nowak

On Wed, Jun 1, 2011 at 5:21 PM, Mini IT <miniit <at> rileys.com> wrote:
> Out of curiosity why is this not an issue?
> I would think the ability to reconfigure and execute arbitrary commands on a
> server is a pretty big issue even if the chance of it happening is slim..
>
> http://seclists.org/fulldisclosure/2011/Jun/0
> "Vendor response: "This isn't an issue."
>
> Problem: the cherokee server admin configuration web interface is
> vulnerable to csrf.
>
> Impact: if an admin is logged into the cherokee admin interface and
> visits a site which runs "bad tm scripts" cherokee can be reconfigured
> to run as $user and set log handlers(hooks) to execute arbitrary
> commands (on error and on access)."
> _______________________________________________
> Cherokee mailing list
> Cherokee <at> lists.octality.com
(Continue reading)

Permalink | Reply | 4 comments |
headers
Mini IT | 1 Jun 2011 19:41

Re: Admin csrf vulnerability

So it's a none issue because an attacker will not have the correct 
information?
Social engineering falls into "not my problem" for the developers?

On 6/1/2011 11:16 AM, Jędrzej Nowak wrote:
> The attack is not that easy as it looks like:
> #1 you need to have admin on localhost:9090 (or any other known combination)
> #2 you need to visit infected page (from the same browser - because
> there is user/password protection)
> #3 you need to submit 2 forms (with fake data) =>  one for changing
> values, second for 'apply'.
> #4 you need to know the current cherokee structure (otherwise
> cherokee-admin will refuse it)
>
>
> Greetings,
> Jędrzej Nowak
>
>
>
> On Wed, Jun 1, 2011 at 5:21 PM, Mini IT<miniit <at> rileys.com>  wrote:
>> Out of curiosity why is this not an issue?
>> I would think the ability to reconfigure and execute arbitrary commands on a
>> server is a pretty big issue even if the chance of it happening is slim..
>>
>> http://seclists.org/fulldisclosure/2011/Jun/0
>> "Vendor response: "This isn't an issue."
>>
>> Problem: the cherokee server admin configuration web interface is
>> vulnerable to csrf.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Tony Zakula | 1 Jun 2011 19:44
Picon

Re: Admin csrf vulnerability

C'mon already.  If you are sys admin and you create the scenario
below, you deserve to be hacked.

Tony Z

On Wed, Jun 1, 2011 at 12:41 PM, Mini IT <miniit <at> rileys.com> wrote:
> So it's a none issue because an attacker will not have the correct
> information?
> Social engineering falls into "not my problem" for the developers?
>
> On 6/1/2011 11:16 AM, Jędrzej Nowak wrote:
>>
>> The attack is not that easy as it looks like:
>> #1 you need to have admin on localhost:9090 (or any other known
>> combination)
>> #2 you need to visit infected page (from the same browser - because
>> there is user/password protection)
>> #3 you need to submit 2 forms (with fake data) =>  one for changing
>> values, second for 'apply'.
>> #4 you need to know the current cherokee structure (otherwise
>> cherokee-admin will refuse it)
>>
>>
>> Greetings,
>> Jędrzej Nowak
>>
>>
>>
>> On Wed, Jun 1, 2011 at 5:21 PM, Mini IT<miniit <at> rileys.com>  wrote:
>>>
(Continue reading)

Permalink | Reply | 1 comment |
headers
MoroSwitie | 1 Jun 2011 19:53
Picon

Re: Mysql AUTH sub-domain specific

On Wed, Jun 1, 2011 at 7:06 PM, MoròSwitie <moroswitie <at> gmail.com> wrote:

>
> Currently only ${user} is available if I'm correct, I couldn't find
> anythings in the documentation?

I just had a quick try, but the mysql logs shows that those vars are
not being parsed.
Permalink | Reply | 2 comments |
headers
Mini IT | 1 Jun 2011 20:06

Re: Admin csrf vulnerability

Fair enough, I was just poking a bit with that comment.
I know it's like blaming the gun for killing someone instead of the 
person who pulled the trigger...

But as a last little nudge:
Sony's situation right now would be a good case about how sys admins can 
mess up big with simple things like patching or divulging information...

On 6/1/2011 11:44 AM, Tony Zakula wrote:
> C'mon already.  If you are sys admin and you create the scenario
> below, you deserve to be hacked.
>
> Tony Z
>
>
> On Wed, Jun 1, 2011 at 12:41 PM, Mini IT<miniit <at> rileys.com>  wrote:
>> So it's a none issue because an attacker will not have the correct
>> information?
>> Social engineering falls into "not my problem" for the developers?
>>
>> On 6/1/2011 11:16 AM, Jędrzej Nowak wrote:
>>> The attack is not that easy as it looks like:
>>> #1 you need to have admin on localhost:9090 (or any other known
>>> combination)
>>> #2 you need to visit infected page (from the same browser - because
>>> there is user/password protection)
>>> #3 you need to submit 2 forms (with fake data) =>    one for changing
>>> values, second for 'apply'.
>>> #4 you need to know the current cherokee structure (otherwise
>>> cherokee-admin will refuse it)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alvaro Lopez Ortega | 1 Jun 2011 21:16
Favicon
Gravatar

Re: Admin csrf vulnerability

Hello there,

On Wed, Jun 1, 2011 at 7:41 PM, Mini IT <miniit <at> rileys.com> wrote:
So it's a none issue because an attacker will not have the correct information?

Nobody said that.
It is a problem indeed, although it is a highly unlikely issue - I'd dare to say almost theoretical.

I'll check it out anyway. Let's see what we can do.

--
Greetings, alo
http://www.octality.com/
_______________________________________________
Cherokee mailing list
Cherokee <at> lists.octality.com
http://lists.octality.com/listinfo/cherokee
Permalink | Reply | 0 comments |
headers
MoroSwitie | 3 Jun 2011 12:18
Picon

Re: Mysql AUTH sub-domain specific

On Wed, Jun 1, 2011 at 7:53 PM, MoroSwitie <moroswitie <at> gmail.com> wrote:
> On Wed, Jun 1, 2011 at 7:06 PM, MoròSwitie <moroswitie <at> gmail.com> wrote:
>
>>
>> Currently only ${user} is available if I'm correct, I couldn't find
>> anythings in the documentation?
>
> I just had a quick try, but the mysql logs shows that those vars are
> not being parsed.
>

Should I make a feature request for this, or is this something that is
not likely to be implemented?
Permalink | Reply | 1 comment |

Gmane