CSRF in Echosim.io

Echosim.io is a nice experimental site which puts a virtual Amazon Echo in your browser!

You give the site access to your microphone, and then full control over your Alexa account (which it will keep indefinitely as you are guaranteed to forget you did this), and then you speak your Alexa questions and commands to Echosim.io. It works pretty damn well actually. Props to its developers at @iquariusmedia.

Well, it turns out there’s no CSRF defences (the lord giveth props, and the lord taketh props away). This means you can just trick users into uploading your own voice commands to Echosim.io and do whatever you damn well please on their Amazon/Alexa account.

Considering the site is predominantly for use by developers and in Beta, i was reasonably forgiving… but then i took a few moments to look into what you can do exactly with full access to Alexa. Turns out, its lots.

To demonstrate, I’ve made my own version of the classic Rick-Roll, entitled the ‘Rick (and morty) Roll’. Its a simple HTML page which uploads audio samples of my voice to Echosim.io in secession to do the following:

  • If you have an Amazon Fire device, it plays Rick and Morty on Netflix (your TV turns on if it supports CEC).
  • Changes all connected smart lights to a nice R&M ‘portal green’.
  • Orders 54 Rolls of Andrex Supreme Quilts Toilet Tissue (yes, you will need to cancel these rolls).

You can find that delightful experiment here:

https://hiburn8.org/experiments/rickandmortyroll.html

Now, all Echosim.io need to do is throw up a ‘same-site’ cookie policy, and the issue goes away. But what i found quite interesting about making that page was learning that chained-interactions (Alexa interactions which require more than one command… for example ordering a product from Amazon.com – which requires a ‘yes’ confirmation), do not have the level of security measures in place I just assumed they would.

I expected, that chained-events like ordering a product or paying a bill would be strung together with a series of tokens, each validating the next request. This would be done to keep the order of events in check, avoid potential race-conditions, and basically just provide an additional level of security and integrity for more complex interactions. Well apparently it doesn’t work like that… third-party controlling apps at-least, authenticate via an API key, and that key can do anything. The end. There is no contextually aware security; asking the time has the same security as asking to disable your burglar alarm.

Ordering 54 rolls of toilet paper, as the experiment page does, is achieved by first uploading audio of me saying “Order Andrex Supreme Quilts Toilet Tissue, 54 Rolls” followed shortly-after by my ‘Yes’ confirmation. I really expected this ‘Yes’ request to require some shared secret from the previous response, but nope… just the API key is fine. The order is placed.

I think the whole authentication and authorisation model of Smart Home Assistants is going to need a pretty good facelift in the next few years, or mine will be going out the window. It feels very much like the days of the WWW before the concept of the Same Origin Policy. In the mean time, be sure you are careful with those 3rd-party apps!

-Daniel

Guided Access Mode Bypass

As a penetration tester who specialises in mobile apps, I get good visibility of how the enterprise is adopting/using/misusing various iOS capabilities and MDM features. One trend I’ve seen increasingly, is the use of ‘Guided Access Mode‘ to lock down devices.

Guided-Access Mode (GAM), for the unfamiliar, locks the device into a single app. It’s typically considered a handy feature for parental guidance, but the official documentation also suggests its effectively the same as the more enterprisey ‘Single App Mode‘; which is true. ‘Single App Mode’ (SAM) does exactly the same thing, but can only be enabled via MDM on a device which is in ‘Supervised’ mode. So it makes sense that organisations which cant easily manage devices use GAM instead. Although many just don’t know that Single App Mode exists.

I’ve seen GAM in the medical, financial, industrial, and retail sectors now. I know that it’s being used to protect highly sensitive data from prying eyes and, in certain scenarios (industrial), I would not be surprised to hear that GAM is defending against life-threatening incidents. That’s a lot of pressure for a parental guidance feature.

I recently performed a penetration test for a prototype self-checkout kiosk/POS solution which used an iPad as the kiosk’s display. Long story short, the solution used Guided Access Mode and, yet again, I was foiled in my attempts to get around it. The test finished a few weeks ago and, not one to give up, i’ve been testing Guided Access mode in my own time. Here’s the bypass 😉:

Continue Reading “Guided Access Mode Bypass”

High Performance Web Brute-Forcing 🕸🐏

Finding and exploiting unique attacks on web applications is, of-course, satisfying. But I also find that performing the most basic of attacks, but as efficiently and effectively as possible, can also pose a decent mental challenge that’s equally rewarding.

In this short post i’ll show you how writing just a few lines of code can have immense gains on web request brute-force attacks, versus using the tools you would probably reach for right now (let’s be honest, it’s Burp).

Continue Reading “High Performance Web Brute-Forcing 🕸🐏”

Kinda LIKE SQL Injection

TLDR: This post is about some late 90’s level hacking. But the fact is, that there just doesn’t exist a decent explanation of this vulnerability anywhere on the internet.. and yesterday, in 2018, I found another application vulnerable to it (to quite serious effect). I’m afraid that was the straw that broke the camel’s back. So now we’re doing this… we’re making the blog-post that should have been made 20 years ago. There is a simple zipped-up MySQL/PHP lab at the bottom of this post, feel free to skip to that if you are so inclined.

Continue Reading “Kinda LIKE SQL Injection”

Gotta Captcha’m All – Automating Image (and Audio!) Captchas.

A captcha serves one purpose. To ensure that a human has performed a task, and not a machine.
In web applications, they attempt to prevent attackers from creating automated bits of code to brute-force forms, fuzz user input or cause a denial of service.
Its very much a non-trivial task these days to differentiate the man from the machine using these image ( and sometimes audio ) “challenges”, as the logical steps a human brain takes to decipher characters from a captcha can almost always be replicated, often more effectively, in code. The types of people you deploy a captcha to shield yourself against are unlikely to be thwarted by something that can be programatically broken. You’re often just adding another hurdle with a captcha. Some people like hurdles.
With this in mind, if you have chosen to use a captcha to protect a mission-critical application from attack… I am of the opinion you’re already a little bit screwed. A captcha is suitable for stopping a casual WordPress blog like this from being overrun by spam comments from knock-off Barbour jacket merchants, nothing more.
On a recent test, a mission critical application for a bank was indeed vulnerable to a nasty DoS, caused by using the ‘RadCaptcha‘ captcha system, which is built into the commercial ‘Telerik’ .net framework. Its a particularly crappy captcha. A previous pentest from another company had already highlighted this, but without demonstrating how it could be broken the bank were reluctant to swap it out.
For the rest of this post, I’ll detail some of the steps I took, and tools I used, to create a PoC for bypassing Telerik RadCaptcha. At the end of it you should have a reasonable idea of how to incorporate captcha-beating functionality into your own scripts. The secondary take-home should be to not use RadCaptcha. Continue Reading “Gotta Captcha’m All – Automating Image (and Audio!) Captchas.”

"Bypassing" CSP’s Data-Exfiltration Protections

A long time ago now, I tweeted a challenge to see of anyone knew what the following URL would attempt to do:

Don’t worry, I don’t expect you to stare at that monstrosity. Instead I’ll just tell you;
So a friend of mine was competing in WhiteHatRally last year, which is a sort of “solve the clues to figure out where to go”-style car race for charity, and he realised that it might be possible to stalk the other competitors, who were displaying there progress on FB via GPS tracking site insta-mapper.com, in order to determine where they were going and beat them there. So initially we looked at spending a weekend making an app to cheat at a charity race by scraping the other contestant’s locations in semi-real-time… we’re that cool. But I ended up spending the weekend learning the ins and outs of Content Security Policy (CSP) instead, which actually is quite cool. In this post I’ll explain what a learned about CSP that stopped our attack, and how we were still able to ‘bypass’ it and skin the cat a different way. Continue Reading “"Bypassing" CSP’s Data-Exfiltration Protections”