I was fortunate to spend a bit of time with Wade recently and we got talking about BeEF, as you do, because .. you know.. we like BeEF. Since that time I’m happy to see that there’s been some movement in BeEF land. I now know that there is a Google Code for the project, and a brand new developer mailing list (which if you’re at all interested in browser exploitation or security should join).

In case you weren’t aware BeEF is a Browser Exploitation Framework, designed to demonstrate the power of browser vulnerabilities. It does this by providing a command & control interface, and a small piece of HTML/Javascript that you can then get a browser to call for them to be “zombified” and become accessible within the C&C. There are a bunch of videos available from here and here if you want to see it in action. It’s a really powerful tool to highlight to your business the impacts of not plugging those XSS or injection holes.

I’m hoping to right more about the framework in the future, but thought I should post a quickie whilst I had the opportunity!

A good friend of mine, lets call him Mikey G, shared this article via Google Reader the other day and it’s probably the first time I’ve gotten interested in the work going on in the HTML spec, as far as security is concerned. The feature in particular is the “sandbox” attribute for the <iframe> tag.

The sandbox attribute, when specified, enables a set of extra restrictions on any content hosted by the iframe.
…
When the attribute is set, the content is treated as being from a unique origin, forms and scripts are disabled, links are prevented from targeting other browsing contexts, and plugins are disabled.

The article lists these privileges as being reduced for “sandboxed” iframes:

• They cannot access the DOM of the parent page
• They cannot run scripts
• They cannot embed their own forms, or manipulate forms via scripts
• They cannot read or write cookies, local storage or local SQL databases

At first when I read this I imagined a world free of unsuspecting webizens getting their machines compromised due to drive-by-downloads from ads being served out of iframes, or malicious session-injecting javascript within iframes. This imaginary world was no more than a glimmer of hope as a few truths became apparent:

• With the universal acceptance of javascript and web2.0isms in our browsing lives, there will always be a technical means for attackers to make our browsers do something untowards – it’s always just a matter of time
• This functionality will have to be implemented by browser manufacturers (I believe latest dev versions of Chrome already implement this functionality) and people who are falling victim to these attacks today are more than likely running out-of-date version of browsers (*cough* IE6 *cough*) so this won’t help them anyway
• The parent page can provide options to over-ride the controls, in case the 3rd party ad-provider requires scripts, which of course they all will

The blog makes it clear that this attribute, when it finally gets implemented*, is not the only thing your developers will have to do to provide areas for untrusted content. They will have to continue doing all the existing security “stuff” they’re doing now. I’m relieved to know that on top of all the pretty new features they’re putting into the new HTML specs (audio, video, ria, local storage, bling bling) that they are also looking to make inroads into making peoples browsing experience safer too.

*NB: This includes implementing the sandbox attribute, the text/html-sandboxed MIME type, and the srcdoc attribute – which could be quite a long way away.

A few weeks ago, whilst trawling some interesting logs, I came across a bunch of HTTP traffic coming from f###-###.opera-mini.net. Performing a few more queries uncovered a bunch more traffic coming from other derivatives of this source. Until that point I hadn’t heard of Opera Mini, but according to their website, it’s “The world’s most popular mobile Web browser with over 20 million users”. So what is Opera Mini?

Opera Mini is a compact web browser released by Opera Software that is designed for mobile devices, in particular, mobile phones. One of the primary features of the browser is its incredible speed. Opera boast more than 30% speed improvements for users in the US. But how exactly is a web browser able to boast such an incredible speed enhancement? Flux capacitor? FTL drive? No. Opera Mini is able to improve the speed of accessing websites by pulling them to their servers first, that then compress the content, before sending the content onto your phone (see press release). This provides a few benefits:

1. Your browsing is faster over your traditionally slow mobile phone Internet connection
2. Your browsing is potentially cheaper, because instead of having to download a page that is 200KB in size, perhaps it’s only 100KB

Another “feature” of Opera Mini, in the never-ending quest to provide an awesome browsing experience on a mobile phone, is that their servers will keep track of your cookies set by websites. This is so that if you visit a site that uses cookies, the Opera Mini server will submit it again for you (see Privacy under the faq).

So does using this browser introduce any security or privacy risks to the user? I believe the simple answer is “yes”. Trying to expand on this to understand the potential impacts and likelihoods of these impacts is a little more complicated, and whilst I was going to take a FAIR approach to this, I don’t know enough of the internal controls to do it justice.

First of all what am I worried about, what assets are at risk? We all understand that your cookies, either in their short active lifetime or perhaps even beyond, hold some value to us users and generally we don’t want to share them with other people – so for this exercise I’m going to focus on cookies as the primary asset. Why is this? Primarily because cookies are often used as the mechanism to help provide state on an otherwise stateless protocol (thanks a lot HTTP). What this means is that, when you’re visiting facebook.com or yourbank.com, when you keep on hitting new pages the only way those web servers know who you are is because your requests often include a “session” identifier. Some web apps put that in the URL, but most will track your state through your cookies. I’m not going to put an actual dollar figure on what it would cost a user if those cookies are disclosed to a malicious, unauthorised third party, but let’s say it’s somewhere between all the personal information you store in your facebook profile and perhaps 10% of the money you have in your bank account. (this of course is entirely subjective – you may only ever use your Opera Mini browser to visit youtube.com?)

There are a handful of scenarios that may occur in which your cookies may be disclosed. Someone could compromise one of the multiple Opera Mini servers and milk them of their juicy, cookie information. Perhaps there’s a fault with the software running on those servers and Opera Mini users accidentally start seeing cookies from other users. Or perhaps an administrator of one of those servers has a bad day and decides to have a peek in their systems. To my knowledge (which I’m going to admit isn’t all that deep) none of these have occurred.

So what are Opera doing to prevent these sorts of issues? Well publicly they talk about encryption, and lots of it. According to the faq the current version of the software will always encrypt data sent between their servers and your browser. This is actually a step above normal browsing, which would only encrypt traffic if the website is configured to use SSL/TLS (HTTPS). Of course, they also put in their faq:
Can Opera Software see my passwords and credit card numbers in clear text? What is the encryption good for then?
The encryption is introduced to protect the communication from any third party between the client (the browser on your handset) and the Opera Mini transcoder server. If you do not trust Opera Software, make sure you do not use our application to enter any kind of sensitive information.
The last statement certainly got me worried. They aren’t making any assurances on ensuring that your data is protected, even whilst being processed or stored on their infrastructure.

So what can you do? Well, I believe there is a balance between the benefits and potential negative impacting risks of this kind of service. Sure, if you’re only using Opera Mini to search Google and look up the weather then perhaps the browser is fine and doesn’t pose any risk to you. If on the other hand you want to ensure that no third party has access to cookies which are used to maintain your state with yourbank.com then maybe you use a different browser for those situations. The decision is mostly personal. For example, regardless of how much I enjoy browsing with Chrome, I still find myself only ever performing online banking with Firefox+NoScript, and often clearing out all settings after I’m done.