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!

Twitter Wipe Addressbook CSRF Vulnerability

I disclosed a CSRF vulnerability with Twitter, that could allow a malicious attacker to wipe the address book of an unsuspecting user. I reported the vulnerability in the beginning of March and they fixed it on the 22nd! I wouldn’t want to comment on the process and internal business logic that they follow, but honestly that was a a pretty long period for them to come up with a fix.

Anyways, getting to the vulnerability, the issue was that a user could delete his own address book with a single click URL, which is alright as long as the user wishes to do so himself. However, with the server not verifying whether the request was sent by the user himself or was the user was tricked into sending the request, the application allowed an attacker to generate a request on behalf of a logged in user from the user’s browser and perform the action (deletion of the address book).

The normal process would be as follows:
1. A user logs into mobile.twitter.com
2. If he wants to delete ALL his previously imported contacts, he would click on “Remove Contacts” under Settings.
3. Upon clicking, a GET request is sent to “https://mobile.twitter.com/settings/wipe_addressbook”
4. A message is presented that the the user’s contacts have been removed.

An attacker could take advantage of the absence of any security tokens (CSRF tokens) that would allow the server to authenticate the request and setup a page (and host it on xyz.com/index.html) similar to the following:

An attacker could then be made to navigate to xyz.com/index.html (via email or some other means) and his address book would be deleted!
 

The form that would make the final request has now been protected with a ‘authenticity_token’ which is random and changes on every login and without which the request is not processed on the server. An attacker would need to know this value to attack the application via CSRF.



This was my ticket to the Twitter Hall of Fame for Security researchers at http://twitter.com/about/security!