JS crypto goto fail?

tldr; A long, passionate discussion about JS crypto. Use slides for an overview.

Javascript cryptography is on the rise. What used to be a rich source of vulnerabilities and regarded as "not a serious research area", suddenly becomes used by many. Over the last few years, there was a serious effort to develop libraries implementing cryptographic primitives and protocols in JS. So now we have at least:

• SJCL - some crypto primitives
• Forge - a TLS implementation
• OpenPGP.js - OpenPGP implementation
• End-To-End - OpenPGP + other crypto primitives

On top of that, there's a lot of fresh, new user-facing applications (Whiteout.IO, Keybase.io, miniLock to name just the fancy ones on .io domains).  JS crypto is used in websites, browser extensions, and server side-applications - whether we like it or not. It is time to look again at the challenges and limits of crunching secret numbers in Javascript.

When you don't have 0days. Client-side exploitation for the masses

Yesterday me and @antisnatchor gave a talk at Insomni'hack entitled "When you don't have 0days. Client-side exploitation for the masses". We described different tricks that one can use during a pentesting assignment to achieve goals without burning any of those precious 0days.

The tricks included the new Chrome extension exploitation tools ported recently to BeEF (by yours truly and @antisnatchor), HTA (HTML applications), Office macros, abusing UI expectations in IE, and some tricks with Java applets running on older Java. Mosquito was also demonstrated. Without further ado, here are the slides:

When you don't have 0days: client-side exploitation for the masses from Michele Orru

All the video links for the demos are on the slides, the code is public and landed in BeEF in tools/ subdirectory. The gist of the Chrome extensions part: you can now clone an arbitrary Chrome extension, add any code to it, and publish it back as your extension by doing:

$ cd beef/tools/chrome_extension_exploitation/
$ injector/repacker-webstore.sh <original-ext-id> zip 
repacked.zip evil.js “evil-permissions”
$ ruby webstore_uploader/webstore_upload.rb repacked.zip publish

Enjoy!

XSSing with Shakespeare: Name-calling easyXDM

tl;dr: window.name, DOM XSS & abusing Objects used as containers

What's in a name?

"What's in a name? That which we call a rose

By any other name would smell as sweet"
(Romeo & Juliet, Act II, Scene 2)

While Juliet probably was a pretty smart girl, this time she got it wrong. There is something special in a name. At least in window.name. For example, it can ignore Same Origin Policy restrictions. Documents from https://example.com and https://foo.bar are isolated from each other, but they can "speak" through window.name.

Since name is special for Same Origin Policy, it must have some evil usage, right? Right - the cutest one is that eval(name)is the shortest XSS payload loader so far:

• create a window/frame
• put the payload in it's name
• just load http://vuln/?xss="><script>eval(name)</script>.

But that's old news (I think it was Gareth's trick, correct me if I'm wrong). This time I'll focus on exploiting software that uses window.name for legitimate purposes. A fun practical challenge (found by accident, srsly)!