Operation n

A friend of mine came and showed me a text message she had received around Valentines day. The message was titled “b my valentine”, followed by a web link to http://69844.cc/wp/md2.aspx?m=someid.

We have obviously heard of mobile worms and viruses, but it made me think around phishing attacks using text messages. The general public are alot more aware of email phishing attacks, but would they expect it to come from a text message? A number of banks provide a text messaging alert service for cash withdrawals etc. Text phishing although more targetted is an interesting attack vector which I haven’t heard of before.

This paper includes some of my thoughts (’request for comments’) regarding minimizing the affects of client-side related browser attacks using the Trusted Computing Solution. It includes some of my initial thoughts.

Restrictions & Limitations: The semantic web is a security nightmare and certainly will not agree with these ideas. Right lets get on with it..brainstorming…

As always with security, our attempt here is not to solve every problem but rather to mitigate and complicate matters for the attacker, thus, discouraging these attacks.

Trusted Browser Security Model (TBSM):

In case your wondering or googling for this name, I made it up for the purpose of this blog entry.

TBSM for starters works towards 3 goals:

• Defines supported Client-Side technologies (i.e. JavaScript)
• Defines trusted 3rd party applications (i.e. Adobe, Quicktime)
• Defines cross-site access on both the client-side and more logically on the server-side.

In application:

Basic idea of how this works:

1. Both the client and server have XML defined security rules. These rules include what browser functionality, and 3rd party applications will be allowed to communicate with our currently selected domain name. Furthermore, we may define cross-site policies which allow us to allow or restrict which sites may be accessed from our current location.
2. The files are signed using TPM and exchanged with the client (i.e. SSL-type negotiation).
3. If the security rules are met on both sides the client is permitted to access the site. This means the client’s set of security rules are met, and the server-side security rules are adopted for the duration of the visit.

Note: Steps 2&3 can quite easily be done at the browser level without the requirement of the TPM.

Simplified:

Like any firewall, both simplified and complex rulesets exist. The TBSM idea is a shared access control list between the client and server. We pre-determine what is allowed for the duration of our session. At some point TBSM can be expanded to stateful application inspection, permitting only specific functions for browser langauges such as JavaScript.

Our major challenge at the moment is that the browser world is like the pre-firewall days. Our default rule is to ACCEPT just about anything. Such an implementation would have been to far fetching before, but with TPM now being implemented as a standard, I think this area has potential to be expanded into the browser security frontier.

Implementing this model will mitigate XSS, CSRF and client-side vulnerabilities (i.e. Universal PDF vulnerability). This will also greatly mitigate AJAX worms utilising Cross-Site vulnerabilities. With the future of TPM, we can have so much more control over what we allow and don’t allow. We can deny access by country, city or even processor type if we really wanted :)

I have been fascinated by Guninski’s work. I feel he fathered client-side attack vectors, laying the foundation for what we see today. We will come back to this in a minute.

Its an interesting question and one that I have thought quite alot about:
“What can one actually do with XSS?”

At the moment XSS attack vectors seem to be primarily limited to the browser. Even RSnake’s exponential-xss-attacks blog entry seems to dwell solely on exploiting the browser.

Guninski’s work was focused on exploiting not just the browser but to explore all avenues. He exploited MS Office packages, Internet Explorer, Microsoft Outlook and Windows Media Player to name a few. Awesome, awesome stuff.

pdp and I took this work further by exploiting similar vulnerabilities in Quicktime, Flash, PDF, Images etc. We are just scratching the surface here.

In short, browser exploitation is all well and fine but with projects like Adobe’s new Apollo all hell is going to break lose. Web technologies will be seamlessly integrated with the desktop environment. XSS scratches the surface.

Yes, as RSnake said you can completely own the browser. Yes, XSS is powerful and bad! however, with a little creativity you can completely own the user’s cyberlife through G-CSH “Generic Client-Side Hacking” vulnerabilities. The focus needs to get out of the browser. There are so many possibilies here! We have only touched on what there is to find.

Nuff said, its bedtime.

This post isn’t really security related or is it?

Sean Patrick Kane wrote a JavaScript speed tester which I thought was really cool. It performs and times the following tests:

• Try/Catch with errors
• Layer movement
• Random number engine
• Math engine
• DOM speed
• Array functions
• String functions
• Ajax declaration

The results were that Opera whipped Firefox and IE hands down. Sean does mention that these results are relative; however, interesting nonetheless.

I do not know enough about the browser internals (of the above listed) to know why Opera is so much faster in parsing and executing JavaScript but it is definately interesting to note. I am sure we can apply this to security in some way… :)