Hey! I hope you enjoy this post. As usual, you can contact me at any of the following:

How I managed to get stored XSS on Skype due to people not understanding the risks and danger of free-form XML

  • Target: Skype
  • Vulnerability: Stored XSS
  • Severity: 7
  • Status: Patched
  • Bounty (if applicable): Hall of Fame & a year of Visual Studio Enterprise ($2,999/yr)

Hey! Welcome to my latest blog post, titled "How I managed to get stored XSS on Skype due to people not understanding the risks and danger of free-form XML". In this post I will tell you how both organisations, and individuals underestimate and/or defraud the risks and dangers involved with free-form XML, and a demonstration of this on community.skype.com.

In this specific post, I will be talking about how I abused cross-site scripting vulnerabilities via SVG files. SVG (Scalable Vector Graphics) is an XML-based image vector format for 2D graphics - SVG images are defined in XML files. Most, if not all, common & major browsers being used now-a-days support SVG rendering. XML's ancestor, SGML, required all elements and attributes to be documented with declarations in the document type definition - SVG gets rid of this by allowing free-form XML. With free-form XML, a document has hardly any syntax rules to follow. In free-form XML, you can choose the name of any element - it doesn't have to be some sort of vocabularly like in HTML.

With this being said, people serve these files as plain images, or animations - and quite frankly, this is disastrous. Since image files are complex and need to be parsed and rendered before they can be displayed by a browser, it comes as no surprise that the images can have security implications.

Being historically an XML-based language, processing of SVG documents has been quite different from the way browsers process their classic HTML websites. For instance, a slight violation of the XML syntax, such as missing closing tags or attribute value quotations, typically can cause SVG processors to exit with an error. However with the intergration of SVG capabilities into modern browsers, this strict parsing approach got amalgamated with their more tolerant way of processing HTML, CSS and JavaScript.

When uploading an SVG file, you can easily bypass validation filters & upload a SVG containing JavaScript - this is due to blacklist-based filter approaches for XSS; but this is useless with a missing MIME type.

I don't really know why I typed all that out - it's old news to most people and it's fairly common now-a-days - however, that doesn't stop huge organisations and such, overlooking it.

This said, here is a demonstration performed on community.skype.com, showing a stored XSS I performed by uploading an SVG file, containing the following:

<svg xmlns="http://www.w3.org/2000/svg" version="1.1" xmlns:xlink="http://www.w3.org/1999/xlink">


tl/dr; I managed to get stored XSS on community.skype.com due to people not understanding what exactly you can put inside them, and how they're handled in browsers. The main risk was the ability to take over community moderator accounts via cookie stealing.

I'm aware I rambled on about a lot of crap that is unrelated - but oh well.

Disclosure timeline

  • 2/26/2017 - Reported to Microsoft Security Response Center
  • 2/27/2017 - Vulnerability verified & case number assigned
  • 4/21/2017 - Vulnerability patched & case closed
  • 4/21/2017 - Contacted by Microsoft regarding Visual Studio Enterprise Subscription & MSDN
  • 5/21/2017 - MSDN & Visual Studio subscription code arrive

Hey! Welcome to my first blog post. On this blog you can expect to see me ramble on about my research and findings, aswell as other peoples research and adding on where I can! I may ramble on a bit, but I hope you enjoy. If you have any questions or suggestions, please email me at d@daley.cc :)

How I owned the BBC with a simple misconfiguration due to human laziness

  • Target: BBC - Twitter Facebook Website
  • Vulnerability: Misconfiguration
  • Severity: 10
  • Status: Patched
  • Bounty (if applicable): $10 (Not joking - I wish I was)

Hey! Welcome to the first post on my blog, titled "How I owned the BBC with a simple misconfiguration due to human laziness". In this post I will run through, and explain how I managed to breach the BBC's developer portal and have full control of 2500 API's, ranging from mobile applications, to websites (including the news - bbc.co.uk & bbc.com) and all the way to the radio.

Enough rambling, let's jump into the post, shall we?!

It all started one day when I was bored, and as curious as always. I was taking part in some bug bounty programs the day before with my friend Derp, where we had managed to perform some subdomain takeovers. That being said, I decided to see if I could takeover any BBC subdomains.. I started by enumerating subdomains for bbc.co.uk by using a script coded by Ahmed Aboul-Ela (@aboul3la) called Sublist3r, which is publicly downloadable, here: https://github.com/aboul3la/Sublist3r.

With Sublist3r being an amazing script, it goes very in-depth regarding looking for subdomains - just to list a few things it does: it searches in public search engines such as Yahoo, Google, Bing etc.. and searches in DNSdumpster, Virustotal, ThreatCrowd & more. This being said, there was bound to be alot of results, so I just straight-up ran the list of 730~ bbc.co.uk subdomains through SubJack but I got no results. It was not possible to take over any of the domains - after realizing this, I decided I'd do some manual auditing, and try find vulnerabilities running on these sub-domains themselves.

What I did first was run the list of subdomains through a script made by my good friend Corben, called alive-host which is a simple bash script that uses nmap to verify whether a host is alive or not - doing this narrowed down what subdomains are alive, saving me from wasting a tonne of time trying to browse to dead subdomains.

After browsing quite a few of the sub-domains, I came across a few that were outputting errors in JSON. This got me intrigued. What were they doing? After some research of the error message below, I found out they were using a 3rd-party API management software & analytics predicter, named APIgee. I decided it was time to look deeper.

{"fault":{"faultstring":"Unable to identify proxy for host: default and url: \/v1\/","detail":{"errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"}}}

I started fresh with all the sub-domains that were outputting these JSON errors. I searched and I searched, I scanned and I scanned, I waited and I waited.. nothing. I could find nothing vulnerable on these subdomains, they were running literally nothing. So, it was time to test the final sub-domain running this what seemed to be API management software - I ran tonnes of scripts, hoping to find something.. anything.. nothing. I stared at the error message again..

{"fault":{"faultstring":"Unable to identify proxy for host: default and url: \/v1\/","detail":{"errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"}}}

What caught my eye was the following:

 default and url: \/v1\/

It would seem the server was configured to have a proxy run to the directory /v1/ - but this was not setup. This error intrigued me so I decided to browse to /v1/ to see what was displayed.. when I browsed to /v1/, the server replied with the following data:

[null,"Basic YXBpQGJiYy5jby51azpEVmM3VG5MSm9Z[REDACTED]="]

The data the server replied with is clearly a Base64 string which when decoded, is:


I said to myself: 'surely not'. I browsed to APIGee and tried logging in with the details.. what'd you know? The login was successful and I'm logged into the administrator account with control over all of the BBC's API's due to a simple misconfiguration, which I'm assuming came down to human laziness to setup a simple proxy. Due to this tiny misconfiguration caused by human laziness, thousands of employee developer's full names, personal email addresses, employee ID's, private products & applications and more were exposed.

Inside the dashboard:

I will not be talking about disclosure timeline

That's all for this post unfortunately! I know it was a bad post due to it not being very techincal nor showing off what I'm capable of but I thought it was worth blogging about regardless - a company this gigantic should not let this happen.

Until next time..