by mradamdavies in
Security

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, full data exfiltration, and more. JavaScript using a simple Java extension means hackers are limited by their imagination, nothing less! If a bad guy can inject arbitrary HTML, CSS, and JavaScript into your website they can embed a Java Applet and bypass all sorts of restrictions which would otherwise be in place.

A recent example of effective XSS leverage “in the wild” was Anonymous using a JavaScript version of LOIC to sucessfully 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 an attack vector and 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 intergrated business directory.

Arbitrary code including HTML, CSS, JavaScript and Java is stored in the database without any validation.

What is the problem?

The implementation is simple and lasting. The attack vector is classed as a “persistent XSS” or “stored XSS” exploit and is found in many input fields of the dashboard.scoot.co.uk subdodomain. 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 main culprit 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:

"></a>XSS HERE<a title="

For reporting purposes I used the following:

"></a><img src=x onerror=prompt(/XSSPOSED/)> <a title="

The image below shows the entry point.

Several Newspapers Hacked!

Below are examples of the Scoot XSS vulnerability passing the insecure data onto….

The Sun
The Independent
TouchLocal
And Scoot themselves

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 thier 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 2012. Initial email ignored.
  • 01 June 2013. Confused but lengthy phone call. Ignored.
  • 01 December 2014. Two phone calls ignored. Reply was “we will look into it”
  • 17 April 2015. Final email to Scoot. Public disclosure.
  • 19 April 2015. Reply from developer. Issue being worked on.
  • 23 April. Fix implemented by developer. Bounty received.

Share Post:

Related Posts

No Comments

Leave a Reply