I am an SEO engineer at heart. Always on the lookout for opportunities from which links and/or citations can be gleaned. Often, while looking for link placements, I find sites with security vulnerabilities. I always try to work with affected sites to help secure the attack vector with mixed results. More often than not the sites get patched and everyone is happy.
Sometimes I get ignored.
Sometimes I get a generic "we will fix it" reply but the exploit gets ignored. The site in question passes the information stored on its site onto several authoritative websites in the UK, some of which are the biggest news organisations we have…
XSS Is Bad
Cross-Site Scripting attacks (often abbreviated to XSS) are bad. They use to be nothing more than annoying popups or adverts inserted into target websites. Technology has since moved on and now the same security flaw can lead to colaborative resource management such as portscanning, data exfiltration, and much more. JavaScript has evolved to such a powerful language and now means hackers are limited by their imagination, nothing less!
A recent example of effective XSS leveraged "in the wild" was Anonymous using a JavaScript version of LOIC to successfully DDOS government targets. Simply asking supporters to visit unrelated but infected sites conducted the attack. The end-user was still culpable but focus shifted from the initial, very small scale hack.
XSS cookie stealers are another popular method of implementing XSS as a way to hijack an account. Their use is increasing due to the popularity of JavaScript.
XSS in Scoot.co.uk
There are multiple vulnerabilities in dashboard.scoot.co.uk subdomain. Scoot then passes this easily exploited information onto many other website, some of which include the most popular UK news services. This data passes, unvalidated, through sites to which they offer an integrated business directory.
Arbitrary code including HTML, CSS, JavaScript and Java is stored in the database without any validation.
I know what you're thinking; how can injecting HTML into a website be bad?
Well, imagine if you could add a page to an American Army website to recruit terrorists.
That could be pretty bad.
Javascript is far more powerful than simple HTML and CSS. A proficient hacker could use it to steal accounts, use system resources, or use it to attack other targets.
What is the problem?
This attack is classed as a "persistent XSS" or "stored XSS" exploit and is found in several input fields of the dashboard.scoot.co.uk subdomain.
The website contains many vulnerabilities but this article focuses on the stored XSS problem. The attack flow is simple: create a free business listing, add a gallery image, insert your malicious code, wait 2-3 minutes and it’s live.
An easy way to obfuscate the code is to use the second gallery image as the exploit will be hidden from initial view is present in the page source, being executed as a result.
The culprit in this example is an unvalidated title attribute for the gallery images. The input field allows arbitrary code to be inserted.
Below is a proof of concept code:
Instead of using a text description for the image, I'll use an following javascript:
"></a><img src=x onerror=prompt(/XSSPOSED/)> <a title="This data will be saved to the Scoot database.
It will then be displayed on multiple websites.
Newspapers Hacked!
The Fix, Using Responsible Disclosure
Preventing XSS exploits is simple and can be done in one line of code. Using htmlentities with ENT_QUOTES to encode quotes and UTF-8 to convert text.
This was a stored XSS vulnerability on one site, which then passed the exploit on to several large UK newspaper websites. Getting it fixed was important to me!
I have emailed, called, and begged Scoot to fix this issue as I use their services. Each time I was told "we will look into it", or "it's a feature" from confused sales staff. Several attempts to contact the relevant person about this situation have gone unresolved. It appears they care more about up-sales than security.
Disclosure Timeline
- 14 December 2012Initial contact — ignored.
- 1 June 2013Followed up by phone — no resolution.
- 1 December 2014Multiple calls, met with a vague response.
- 17 April 2015Final disclosure email sent, going public shortly after.
- 19 April 2015A developer finally responded; a fix is underway.
- 23 April 2015Vulnerability patched, and a bounty paid.