code16: RCE via XSS - Horde 5.2.19

This time I decided to sit for a while with Horde Groupware (5.2.19). “Ready to go” virtual machine we can find at Bitnami’s webpage (big thanks!) so using for example VirtualBox – you can set all things up very quickly. Below you will find few publicly disclosed bugs found during last few days...

After machine was ready I decided to create another (let's say "normal/registered") user ('tester').

Here we are, we are logged in as tester (p:tester) and from this stage we will (re)start our testing.

(In the middle of time you can also check source code of Horde. It's available at /opt/bitnami/apps/.

You will see few interesting directories but we will take care of it a little bit later.)

For now, we are here:

01. Go to Calendar -> New Event. In the new window, click to switch to URL tab, then
as an URL add something like: http://localhost/xss.

Save it.

Now new event is created.

When you will click on it, XSS will be triggered.

Now let's back to the console. You should be able to easily spot the url parameter in the code. For example:

Or here:

So it doesn't realy matter where you will use that param. It (afaik) will be 'vulnerable' anyway.

02 - 'Resources'

So here the story was a little bit different because after adding payload in one place, it was executed in other section of webapp, during some other 'scenario'. Check it out:

Let's create new Resource:

In next window we will set a Name for our Resource. Like this:

I expected that it will be a persistent XSS. It was not...

... where I expected it to be. :] When (now) you will try to add new "Resource Group", XSS indeed will be triggered, see below:

My next question was: how this parameter looks like in the source?

I found that this (Name) parameter is 'declared' in the same way as 'few' ;] other parameters:
(red frame is for part when you will edit/add new resource):

It looks like we need to verify if this is true or false.

03 - description in the /nag/:

We are here:

Let's focus on this part of the screen now:

Now quick example:

At this stage I had a new question: if there is a way to escalate from XSS to some nice CSRF?

When I was playling with admin-part-of-webapp I found that when we are logged-in (user:bitnami for default VM) we will be able to access 'PHP Shell' (available defaultly from admin-user). I decided that it will be a good place to preform our CSRF challenge. Below you will find few details:

To verify this "possibility" I used the bug described above as '02 - Resources'. So...

When I was preparing a 'good payload' to use for an attack I found that "somehow", injected code, is not properly sent to webapp. After a while I decide to 'bypass' it a little bit - and that's how I used unescape() function.

TL;DR - our "payload" looks like this:

We will add the code as an input for the bug#02 ("Resources") but before that, we need to prepare it to use the value in unescape(). To do that I used Burp:

Now when the code ('new resource') is added - we can trigger it in the same way as the bug described above (#02). But the case here is invite the admin-user to click (at his "panel") in 'Resources Group'. Then our payload (with admin's privileges) will be executed (and this is how we'll achieve remote code exec on Horde's box ;]) Check it out:

Payload is added (persistent XSS), now we'are waiting for the admin and...

(some small 'debug message' in payload - just for me ;))

Here we are:

Cheers

P.S. After I received some feedback, the post will be (below) updated because few of described bugs are still (21:38 30.01.2018) available in version 5.2.22 (afaik 'the latest'), so:

Thanks to Bitnami we are able to test it in virtual environment: