Adobe Flash is no stranger to security issues, but this post isn’t about stack overflows, bypassing ASLR, or sandbox escaping – it’s about building practical exploits against poor use of crossdomain.xml.

For those unfamiliar with cross-domain policies in Flash, check out my previous post here. I’ve also built a nice tool for testing cross-domain requests in Flash which can be found here.

For archival purposes I’m posting this talk that me and Mike Brooks (a.k.a. Rook) did at Blackhat USA 2015. While we danced around the vendor in the talk description, we can now disclose that that vendor was indeed Akamai – see their blog post about the issue here. Luckily Akamai was super helpful throughout the whole process (which is more than can be said for many vendors!). If any of you find any other vulnerabilities in Akamai, hit them up at [email protected] This vulnerability chain allowed us to achieve a full Same Origin Policy bypass on many of the internet’s most popular sites (Facebook, Verizon, Microsoft, etc).

Recently WebRTC has been in the news as a way to scan internal networks using a regular webpage. We’ve seen some interesting uses of this functionality such as The New York Times scanning your internal network to detect bots. The idea of a random webpage on the internet being able to scan your internal network for live host is a scary one. What could an attacker do with a list of live hosts on your internal network? It gets a bit scarier when you’ve experienced pentesting an internal network. Many internal networks are cluttered with devices stocked with default credentials, a list of CVEs that would make Metasploitable look secure, and forgotten devices that were plugged in to never be configured. However, despite WebRTC being a scary feature of many browsers I haven’t seen any framework for developing exploits using it.

LastPass, a popular password management service with addons for Firefox, Chrome, and Internet Explorer suffered from a clickjacking vulnerability which can be exploited on sites without the proper X-Frame-Options headers to steal passwords. The password auto-fill dialogue can be overlayed with a deceptive page to trick users into copying and then pasting their password into an attacker’s site.

Update: After disclosing with the Lastpass folks via their support system and getting a very quick and helpful response this issue is now fixed for all the latest versions of Lastpass on Chrome & Internet Explorer. Kudos to the Lastpass guys for being so quick on patching! The only patch that is not available is for Mozilla Firefox due to Mozilla’s unwillingness to approve the update in a reasonable amount of time. See below for full details.

For the proof of concept example we’ll use Tumblr, which makes use of JavaScript to prevent clickjacking. The protection is ineffective however, as the site can be framed with an HTML5 iframe sandbox to prevent the page from executing JavaScript:

Recently I took a stab at auditing a popular Firefox addon NoScript, which is fairly well known among the netsec and privacy community due to its bold functionality of blocking active content such as Flash, Java, and JavaScript on all sites by default. My goal was simply to bypass the addon when it’s been installed with the default configuration. This is partially because so many people put a lot of trust into NoScript and also because I hear a lot of people snubbing exploits because “I use NoScript when I browser the internet and am therefore safe from all web exploits!“. This attitude is annoying so having a bypass to pull people back into sanity sounded nice.

So, where to start?