Wednesday, 1 October 2014

The anatomy of a Shellshock attack in the wild

Wednesday, 1 October 2014

It’s six days since I wrote about Shellshock and the response has been massive. There’s clearly a lot of interest in this bug and indeed there have been some pretty dire warnings about the impending “Bashpocalypse” which ultimately, hasn’t really happened. I’m sure it’s made life tricky for some sysadmins and I’m also sure there have been many servers that have suffered from what by all objective measures, remains a pretty serious bug.

It’s probably a bit early to speculate about the true cost of Shellshock, but what I can do – and in a very objective fashion – is decompose a typical Bash bug attack. I can do this because I had one hit my logs just a couple of days ago.

As I’ve written before, I use the rather awesome Raygun.io for error tracking events from Have I been pwned? (HIBP) which means they send me courtesy emails for previously unseen errors. Errors like this:

Raygun.io error log

Read more

Monday, 29 September 2014

TestTalks Podcast: Hack Your API-Security Testing

Monday, 29 September 2014

Did I mention that we have some terrible security flaws with our APIs behind rich client apps? Pretty sure I did’; oh and I did just write a Pluralsight course that shot to the top of the charts so yeah, there’s that!

There are a few reasons why vulnerabilities in APIs are the new black:

  1. They’re that much less obvious than vulnerabilities in browser-based apps; you don’t see the URL, you don’t get browser warnings and it’s harder for a casual observer to probe away at them (but only just…)
  2. Mobile apps are proliferating at a crazy rate. Well in excess of one million each in Apple and Google stores is a good indicator of astronomical growth in a short timeframe. In the rush to market, security is often one of the first things to be neglected. Speaking of “things”…
  3. The “Internet of Things” – IoT – is a rapidly emerging new technology sector that’s already producing a heap of vulnerable “things”. When your toothbrush talks to an API, that API needs to be secured in the same way as your non-toothbrush things.
  4. Many developers don’t realise just how easy it is to intercept API traffic from a mobile device. And inspect it. And probe it. And make it do things it’s not meant to do. Lack of awareness it a really, really serious risk.

Joe Colantonio from the TestTalks podcast took my latest Pluralsight course, evidently enjoyed it and asked me to come on the show for a talk. I really enjoyed the chat, it’s an interesting topic not least because of all the times I see the light bulb go on for developers – “Oh, you mean other people can see all the comms between my app and the API?!”

The episode is over on the TestTalks website or accessible directly via the audio player below:

Thursday, 25 September 2014

Everything you need to know about the Shellshock Bash bug

Thursday, 25 September 2014

Remember Heartbleed? If you believe the hype today, Shellshock is in that league and with an equally awesome name albeit bereft of a cool logo (someone in the marketing department of these vulns needs to get on that). But in all seriousness, it does have the potential to be a biggie and as I did with Heartbleed, I wanted to put together something definitive both for me to get to grips with the situation and for others to dissect the hype from the true underlying risk.

To set the scene, let me share some content from Robert Graham’s blog post who has been doing some excellent analysis on this. Imagine an HTTP request like this:

target = 0.0.0.0/0
port = 80
banners = true
http-user-agent = shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)
http-header = Cookie:() { :; }; ping -c 3 209.126.230.74
http-header = Host:() { :; }; ping -c 3 209.126.230.74
http-header = Referer:() { :; }; ping -c 3 209.126.230.74

Which, when issued against a range of vulnerable IP addresses, results in this:

Ping requests from vulnerable Bash hosts

Put succinctly, Robert has just orchestrated a bunch of external machines to ping him simply by issuing a carefully crafted request over the web. What’s really worrying is that he has effectively caused these machines to issue an arbitrary command (albeit a rather benign ping) and that opens up a whole world of very serious possibilities. Let me explain.

Read more

Tuesday, 23 September 2014

Your Azure website CPU is going nuts and it’s not your fault

Tuesday, 23 September 2014

This is not what you want to see on your Azure website:

Azure CPU usage fluctuating wildly

Ok, so what are we looking at here? CPU goes up and up and up and then… dramatically down. There are even some additional coloured lines in the middle of that graph indicating that there were more instances put on just to deal with the load. So it must have been some pretty serious load, right? Not so much:

Requests avering 133 per minute over a 24 hour period

Huh, only a couple of requests a second. Clearly I’ve broken it.

Read more

Monday, 22 September 2014

First impressions: 3 things I love and 3 things I hate about the iPhone 6 Plus

Monday, 22 September 2014

No, I didn’t camp out the front of the Apple store with my sleeping bag and frankly, I think those that did perhaps have what we refer to down here as “a couple of kangaroos loose in the top paddock”. Queues stretching hundreds of metres and adults in tears aren’t really my things (incidentally, crying over queue position is not something you do once you have your grown up pants on).

Instead, I went down to my local Telstra store (our local big telco) and stood behind 3 other people while I caught up on my email backlog for a couple of hours. They had a red carpet. There was free coffee – proper coffee! They even had a violinist playing in the store for crying out loud. 20 minutes after that I was out with a shiny new iPhone 6 Plus. No queuing around the block and no tears.

So now, with the light of several days of real world use behind me, what do I actually think if it? Is a 6 Plus all it’s cracked up to be? Or is it just too big and too clunky? A bit of both, here’s what I reckon:

Love 1: It’s big

It fits a heap more content on the screen (yeah, I know, who’d have thunk it), but what it means in real terms is less scrolling and more consuming actual stuff. For example:

Evernote on the 6 Plus with an extra note over the 5 Evernote on the 5 with less content showing

Here I’ve got a heap of extra space that gives me more content on the screen to read. The physical size of the text is almost identical (in this example the 6 Plus fonts are actually about 3% larger), but I’ve just got more of it. Clearly this is always going to be the value proposition for a larger phone but the significance of that isn’t always clear up until you actually use it for everyday tasks.

Tags:

Read more

Tuesday, 16 September 2014

Introducing paste searches and monitoring for “Have I been pwned?”

Tuesday, 16 September 2014

I’ve got 174,451,409 breached accounts in Have I been pwned? (HIBP) as of today which probably sounds like a lot, but it’s not. Why is it not a lot? Because whilst that list spans a lot of the big breaches I could get my hands on, as of the middle of this year (now a couple of months ago already), there were over half a billion accounts breached in just six months. That’s just nuts and as that article explains, its set us on a track that will make 2014 the most hacked year to date by a fairly significant margin over last year which was the previous most hacky year.

Every time a major breach occurs (and frequently after smaller ones too), I go through the process of seeking any publicly dumped data (which frequently can’t be found, it remains in the attackers’ hands) then verifying the legitimacy of the breach and when it checks out, publishing the data to HIBP. It can be time consuming and labour intensive if I want to avoid any false-positives then combine that with the fact that only a small portion of breaches ever see the light of day and you realise that despite my best efforts, I’m really only scraping the surface of pwned data.

But along with those massive, sporadic public dumps, there’s another channel by which we very frequently see breached accounts appear and that’s “pastes”. As it turns out, there are literally tens of thousands of email address appearing in pastes every day unbeknownst to the rightful owner. Also unbeknownst to them is that alongside their email address is often their password and other personal data, all on public display for anyone who cares to look.

But I’m getting ahead of myself here, let me explain what a paste is and the relevance to HIBP.

Read more

Monday, 15 September 2014

10 things I learned about rapidly scaling websites with Azure

Monday, 15 September 2014

This is the traffic pattern that cloud pundits the world over sell the value proposition of elastic scale on:

Sessions going from barely anything to almost 12k an hour almost immediately

This is Have I been pwned? (HIBP) going from a fairly constant ~100 sessions an hour to… 12,000 an hour. Almost immediately.

This is what happened last week when traffic literally increased 60-fold overnight. September 10 – 2,105 sessions. September 11 – 124,036 sessions. Interesting stuff happens when scale changes that dramatically, that quickly so I thought I’d share a few things I learned here, both things I was already doing well and things I had to improve as a result of the experience.

Oh – why did the traffic go so nuts? Because the news headlines said there were 5 million Gmail accounts hacked. Of course what they really meant was that 5 million email addresses of unknown origin but mostly on the gmail.com domain were dumped to a Russian forum along with corresponding passwords. But let’s not let that get in the way of freaking people out around the world and having them descend on HIBP to see if they were among the unlucky ones and in the process, giving me some rather unique challenges to solve. Let me walk you through the important bits.

Read more

Monday, 8 September 2014

Solving the tyranny of HTTP 403 responses to directory browsing in ASP.NET

Monday, 8 September 2014

You may not know this, but an HTTP 403 response when browsing to an empty directory is a serious security risk.

What the?! You mean if I go to my website which has a “scripts” folder where I put all my JavaScript and I have directory browsing disabled (as I rightly should) and the server returns a 403 “Forbidden” (which it rightly should), I’m putting my internet things at risks of being pwned?!

Yes, because it discloses the presence of a folder called “scripts” which is a common directory.

Well of course there’s a bloody folder called “scripts”, all my HTML source which you can see references it! I could call it “i-love-drunken-elephants” and you could still see it so what’s the point?!

But it would still return a 403 which would confirm the existence of the resource and pose a directory enumeration risk.

But you can discover the presence of the directories anyway! Ok, in today’s modern apps like ASP.NET MVC they might actually be routes that don’t translate through into physical paths but still, this is just being pedantic!

Your site can’t go live until you fix it.

Uh, let me just fix that for you…

Read more

Friday, 5 September 2014

What the f*** were they thinking?! Crazy website biases exposed by naughty words lists (the NSFW version)

Friday, 5 September 2014

I’ve long held the view that passwords should consist of as many crazy things as the owner deems fit. If I want to create a password that looks like a dog just ate the keyboard and threw up all the keys, then good for me. (Chances are that Fido is going to cough up a pretty unique password too but before PETA gets on my case, try using a password manager like 1Password instead.)

Now I’m used to seeing all sorts of ridiculous limits on passwords – no “special” character, limit of 12 chars, no spaces, can’t use letters “q” or “z”, can’t use letters at all – but the banning of specific words is something else altogether. I don’t mean words like “select” or “drop” either, you know, the kind that shows someone has done a sloppy job of their SQL injection mitigations, I mean words like these:

A jar of Extreme Nut Butter

I’ll come back to the impact of passwords named after this particular sandwich spread. Banning certain words is one thing, but inadvertently publishing the entire list is quite another and it discloses some very interesting biases on behalf of the site.

Biases implied by the words a site allows versus those it blocks doesn’t need to remain the domain of passwords alone. There are other cases where words are blocked and again, the list is exposed publicly for (assumedly unintentional) scrutiny. When I say “biases”, I’m talking about everything from religious views to gender equality to which animals zoophilia may be off limits for. Yep, it’s that weird and it all begs the question – what the fuck are they thinking?! (Get used to the language, the title of the post warned you!)

Read more

Thursday, 4 September 2014

Hack Your API First – learn how to identify vulnerabilities in today’s internet connected devices with Pluralsight

Thursday, 4 September 2014

A few years ago I was taking a look at the inner workings of some mobile apps on my phone. I wanted to see what sort of data they were sending around and as it turned out, some of it was just not the sort of data that should ever be traversing the interwebs in the way it was. In particular, the Westfield iPhone app to find your car caught my eye. A matter of minutes later I had thousands of numberplates for the vehicles in the shopping centre simply by watching how this app talked over the internet:

Four photos of vehicles matching the search results

In line with my personal views on disclosure, I published the blog mentioned above and a media furore followed; how on earth can a company be so careless with our personal data?! Why wasn’t this identified earlier?

The thing is, this sort of thing is both very common and very easily identified in your apps or anyone else’s apps for that matter and that’s exactly what I set out to show you in my latest Pluralsight course Hack Your API First.

Read more