XSS vulnerability in ThirtyBees

[asteinhauser]

Please, see video with the exploitation:
thirtybees.zip

[Dh42]

I saw this earlier, I am not sure on how much of a risk this actually is.

[asteinhauser]

The risk is diminished, because planting the exploit probably requires administrator account, but otherwise it has all the consequences of an XSS attack:
https://www.dionach.com/blog/the-real-impact-of-cross-site-scripting
Moreover, thirtybees uses inconsistent sanitization of the baseURL value - sometimes the value URL is sanitized and sometimes not - see the source code:

so there already are mechanisms how to prevent it, they are just skipped sometimes and that allows the exploitation.

[Dh42]

You are correct about that. We were actually talking about removing the bsql from the backend this week since once backend access is gained that whole shop is considered lost.

[asteinhauser]

Losing an administrator account is usually not as dangerous as the possibility of continuous, concealed and unrestricted execution of malicious JavaScript in all client's and administrator's browsers. Manipulation with data and manipulation with code are generally two different things. But the evaluation of security risks in your application is your choice in the end. I'm not aware of the peculiarities of thirtybees and how you deal with code/data separation. If you don't care about it anyway, than keeping the flaw in there is probably not a big difference.

[Dh42]

Let me start by saying I value your contribution and it will make it into the next version, especially since it is a simple change.

But with that being said, once the admin account is lost, You have to assume everything is lost. Since we are a plugin / module type software, like most, once you have an admin account you have unfettered access to the database and file system. While a persistent XSS attack is bad, there are actually much worse attacks. I have seen some that started off in the back office where people "upgrade" a payment module a full version, but have added code to send them all of the credit card numbers while still charging things like normal. Because they manipulated the touch times using a shell script, no telling how long they had been in place.

We do value security at thirty bees, not just for our end users, but also the customer data they collect as well. But you have to be prepared for the reality once someone gets back office access a complete system audit needs to take place.

[asteinhauser]

OK, that makes sense. Thanks for the explanation - the possibility to add plugins with code makes it clear to me.

[Dh42]

Yeah, while anything is that is executed through the system is sanitized, the plugins can have files that are meant to be directly accessed, like say someone compiles a plugin with a shell script file. That will give the uploader of the plugin read / write access on the whole server. There is nothing we can really write in to stop that.

[Traumflug]

Moreover, thirtybees uses inconsistent sanitization of the baseURL value - sometimes the value URL is sanitized and sometimes not - see the source code:

Thought about this immediately. A vulnerability in the installer is harmless, because the installer goes away right after installation, but what about all the password fields elsewhere?

A customer entering a malicious password or user name and a merchant looking up this user is certainly a risk.

[asteinhauser]

Here I have two others:
thirtybees2.zip
The first one works only for minority of browsers (I exploited it with Epiphany), while the second one works universally.

[asteinhauser]

Here are five more:
prestashop3.zip

[asteinhauser]

Here are the last two:
thirtybees4.zip

[Traumflug]

Let me express a big THANK YOU, even if I can't move this into the code right now. Great work!

[getdatakick]

I believe all reported issues were fixed by commits listed above. Closing