Penetration testing

[tomdickson]

Hi,

I was just wondering if any penetration testing has been done with userspice 4.0.

Looking at the code, it appears that the validation is triggered by a javascript (onclick event) which then triggers the jquery call to the server-side validation. If I spoof the registration form and tinker with the client-side javascript, it seems possible to make database entries in the user table with no server side validation.

When I get a bit of time, I'd be happy to have a go and show the results. I'm no expert on php coding though, so I don't know if I'd be able to offer a fix. Also, I could be wrong.

Anyone looked into this?

T.

[tomdickson]

Hi, a little update, I spoofed the form and managed to get entries into the DB without validation.

I haven't managed to do any SQL injection, since I'm not a coder, but I did manage to fill the username field with everything (/ \ * ?) except for double quotes which were entered as ". I can't say this has caused much harm, but I can't help wonder if a more skilled and malicious person could do something.

The method was by removing all the ID='username', ID='fname', and then generate a real csrf and copy it to the spoof form.

Some suggestions might be to:

1. set the field length in the MYSQL database to match the allowable character limit set by userspice. Currently, most DB fields allow 255 chars. This could be reduced for the username and password fields at least.

2. change the submit function so the validation doesn't depend on any client-side stuff (i.e. javascript).

Hope that helps you out in some way.

T.

[mudmin]

That is extremely helpful... I am definitely going to look into that.

There has been no "official" penetration testing of userspice, but I've been doing a lot of testing on the classes and methods as have others because they are way more popular than userspice itself. I'll be looking into this ASAP and get back to you.

[mudmin]

My gut says that you would only be able to do that on your own machine due to the fact that all browsers have a strict "same origin policy" and if you tried to do that as a man in the middle, you wouldn't have the anti-CSRF token so the page would automatically be killed upon submission...but it's definitely something I need to take a hard look at.

In general, the philosophy is that if the client machine itself is pwned by some malware or an attacker has the ability to run arbitrary code on the client... it's game over anyway. The question I need to look into is if you could manage to get code into the db if it was not running on your local machine.

You're welcome to try the attack on http://userspice.org/demo and see what happens!

[tomdickson]

Hi,

Thanks for looking into it, and so promptly.

I have had a go in a live environment. First I had a go on the demo site. I had trouble signing up normally (no reaction when I'd hit register on a fully completed form?), so I decided to set up my own live test environment.

I was able to do the same exploit.

1. created spoof form and directed it to the live joinThankyou.php file
2. I removed all the ID=username, ID=other_field_names...
3. Then I edited the script with the Jquery to remove the if(data=success) condition.
4. I generated a real csrf from a live form, then copied it into my spoof form.

After that, I chucked a bunch of characters into the username field and hit submit. That bypassed the validation and entered the database. It was good to see that the quotes I entered were all escaped as either

Code:

&quote

or & # 039.

Hope that helps in some way.

T.

[mudmin]

It helps a lot. There are two of us looking into this right now to figure out what's up. I may have mentioned, I just moved and my development pc is not set back up yet, but I guarantee we will look into this and hopefully create a better patch. Thank you!

[mudmin]

I'm still really interested to see if this would work on http://userspice.org/demo/

UserSpice has not been formally pen tested, but I invite any white hatter to try it. I want to make this product better for everyone.

It's one of those things where I would want to see if someone could enter arbitrary code when they don't have access to the php or the db because that's a real life scenario.

[brian]

As already discussed in the PMs but mentioning here for others, the client side JS/jQ code is helpful, but shouldn't be relied upon because it is easily bypassed/disabled. There is other US code that protects the database from dangerous inputs so SQL based attacks should be pretty unlikely.

The server side validation for input sanity should be fairly solid (and can be expanded if needed). What appears to be the weakness is how that validation is called. So the intention of the code may be vulnerable, but the DB and server side code seems to be pretty safe.

As Mudmin said, these issues are important to be addressed, and none of us is too proud to accept constructive criticism.

[tomdickson]

Hi, thanks for taking a look at this.

I'm happy to have a go at the demo site, but wondered if it is working? I'm having trouble trying to register normally.

(really sorry for being a pain!)

T.

[mudmin]

I will reinstall the demo...the 4.0.0a is an old version. I'll see if I can get one up soon. I'll keep you posted.