miniBB ®  
miniBB Support Forums
 | Forums | Register | Search | Statistics | Manual |
Bugs miniBB Support Forums / Bugs /   

Possible CSRF vulnerability in administration file

Author dominos
Registered
#1 | Posted: 29 Apr 2012 22:37 | Edited by: dominos 
Hi!

I was reading through the source code of minibb and found a potential CSRF vulnerability in bb_admin.php. At the moment, there are no checks for http referer header correctness or csrf tokens matching in this file. At the same time, in index.php both of these checks have been implemented to make the software more secure.

In the installation guide, it is advised to change the name of bb_admin.php to something else. This would indeed make it more difficult to exploit this as the attacker would need to guess the new name first. However, it seems that not all sites are following this practice... I had a quick look around minibb forums installed and found about 50% have not bothered to rename the default file.

The consequences of this kind of attack could be quite dire, if carried out on some forum. It would be possible to delete all forums and users. Therefore I think an extra layer of protection would not be too much. So, even if an attacker finds a default admin panel name or somehow guesses the new name, he could not take down the forums.

The most affected functions are those, that are irreversible - i.e. deletions. In this case both removeuser2 and editforum3.
Removeuser2 requires 3 parameters: action, userID and removemessages, which all can be obtained by the attacker quite easily.
Editforum3 takes 7 parameters: forum_name, forum_desc, forum_icon, forum_group, deleteforum, action and forumID. These can also be set / obtained.

So, a typical attack would look like this:
1. Attacker finds a forum with default admin panel name or guesses / obtains the name somehow
2. Attacker creates a special website, which sends requests to delete forums / users automatically upon opening
3. Attacker posts the link to this website with a good enough story so that admin would open it

To test if this indeed works I tried it against my own installation (version 3.0) and the public installation (version 2.5 I think). In both cases I was logged in as admin and I clicked a special link, which contained the following html:

minibb.com/forums/storage/screenshots/attack1.png

The result was that user 3 was gone, without admin knowing anything.

On my own installation I also tried to delete some forums with it. So, I went to a link, which contained the following html:

minibb.com/forums/storage/screenshots/attack2.png

And forum 5 with all of its contents was gone.

To try to fix this, I edited bb_admin.php, admin_editforum2.html and admin_removeuser1.html.
In the file bb_admin, I added the following lines:

if(isset($_COOKIE[$cookiename.'_csrfchk'])) $csrfval = $_COOKIE[$cookiename.'_csrfchk']; else $csrfval = '';
if (isset($_POST['csrfchk'])) $csrfchk=$_POST['csrfchk']; elseif (isset($_GET['csrfchk'])) $csrfchk=$_GET['csrfchk']; else $csrfchk='';

Now, I edited both forms to also include the csrf token:
<input type="hidden" name="csrfchk" value="{$csrfval}" />

And back in bb_admin.php, after both editforum3 and removeuser2 cases, I put this:
if($csrfchk=='' or $csrfchk!=$csrfval) die('Can not proceed: possible CSRF/XSRF attack!');

Now, when I tested these two cases again, the users or forums were not deleted even when the admin visited the attacker's site. Guessing this csrf value or intercepting unencrypted pages going to client is still possible but at least carrying out this kind of attack should be harder now than before.

I hope this information was useful and you can use my examples to try and fix this in some later version. In case this solution breaks something else, I guess I could also try some other ways of solving the problem (checking referer header could also work for example).

If you were already aware of this, then sorry. I just felt I had to report this problem.

Author Paul
Lead Developer
#2 | Posted: 30 Apr 2012 10:12 | Edited by: Paul 
1. Attacker finds a forum with default admin panel name or guesses / obtains the name somehow
2. Attacker creates a special website, which sends requests to delete forums / users automatically upon opening
3. Attacker posts the link to this website with a good enough story so that admin would open it

Let's not forget, that besides of it all,

4. the admin must be logged in to the site.

It seems for me, there are too many conditions and too small chances to break the site such way. Almost zero chances.
However I'll take your suggestions in consideration while working out the final miniBB 3. There are no limits to perfection :)
Thank you.

Author Paul
Lead Developer
#3 | Posted: 20 Feb 2013 19:39 | Edited by: Paul 
While working out the miniBB 3 final these days (yet... finally!), I've discovered that the solutions suggested regarding the nature of this trouble, are a bit wrong.

It's a weak point to provide {$csrfval} as the value of the hidden field on the form. This hidden field should be formed dynamically on the fly, using a JavaScript function, i.e. they should be get from client-based cookie and then sent back to the server, when they are verified with the server-side cookie. This is at least how this basic protection works in other areas. If it would be just kept on the live form, that would mean no protection at all, as they could be easily read (but you can't easily read the cookie value from the domain which it was not set up from).

Hopefully, miniBB 3 final will provide the most proper solution regarding these issues.

(fixed)

Bugs miniBB Support Forums / Bugs / Possible CSRF vulnerability in administration file Top
This topic is closed. New replies are not allowed.
 
miniBB Support Forums Powered by Forum Software miniBB ® Features  Requirements  Demo  Download  Showcase  Gallery of Arts
Compiler  Premium Extensions  Premium Support  License  Contacts
  Extend your miniBB-forums, attaching the images and files,
get the File and Picture Attachments add-on!
Galleries / Attachments Addon for miniBB