Category Archives: Aladdin

The oracle strikes again – “Browser OS” threats start to appear

Moving on from the social networking issues we outlined in the past couple of weeks, after following the predictions, and their materialization (here, here, here in the announcement of Gmail offline, here, and here), we can already see the “Browser OS”, as we dubbed it in our annual threat and predictions report, begin to materialize as well.

As per a recent Register article, threats related to Google Gears™ have started to appear – taking advantage of the extended capabilities granted to the browser – just like we predicted in our report. We named Google’s Gears, Adobe’s Air and Microsoft’s Silverlight as the prominent technologies that would be the enabler for the “Browser OS” and would be scrutinized for their security implications.

As always, we are not here to say “nay” to every new technology – just the opposite these technologies are the future, and they enable businesses and individuals alike to be more productive and have a better web experience. The only claim here is that more focus should be put on measures that take these technologies into account when implying to provide internet and web security, and enough forward looking vision to execute on it.

Social networking threats – the “hacker” story

As the social networking threats angle is picking up a lot of traction lately <pat_on_own_back>,  the folks at Netragard have posted a great write-up on using social networks as an attack tool – involving both social engineering as well as technical exploits. The post can be found here, and I just want to quote a couple of sections that I feel very strongly about:

“The social reconnaissance enabled us to identify 1402 employees 906 of which used facebook. We didn’t read all 906 profiles but we did read around 200 which gave us sufficient information to create a fake employee profile” … “After the payload was created and tested we started the process of building an easy to trust facebook profile. Because most of the targeted employees were male between the ages of 20 and 40 we decided that it would be best to become a very attractive 28 year old female. We found a fitting photograph by searching google images and used that photograph for our fake Facebook profile. We also populated the profile with information about our experiences at work by using combined stories that we collected from real employee facebook profiles.”

Needless to say that the newly created fake profile, which could just as well have been hijacked, went a long way in terms of enabling the attackers (who were commissioned to perform a penetration test this time) to gain access to internal company resources quite easily.

Blocking Facebook? Not popular, and not effective

OK, so we know that social networking sites have their issues and threats associated with them, we’ll be the first to admit it. But on the same note, we also know that just blocking/censoring them (pick the more politically correct term) is not working either. This is in light of the Maryland general assembly’s decision to block Facebook and MySpace from their computers.

It’s a lose-lose situation. You lose the added value of using social networking to leverage business, you lose the “popular” vote when your employees expect access to such sites, and you lose on the security front as simply blocking certain sites is not effective.

The solution as we see it here is to enable access to social networking sites, while stripping out any malicious content that may end up there, and control what functionality is permitted while browsing social networking sites.

Fighting an infection vector with new standards – ClickJacking

If you haven’t heard yet, the newest version of Microsoft’s Internet Explorer 8 (RC1) have been endowed with support for “Anti-Clickjacking” (for more background on clickjacking, check out: http://ha.ckers.org/blog/20080915/clickjacking/).

This new feature is basically an implementation for a new header (X-FRAME-OPTIONS) that is returned from a server which defines the scope of “netsing” that is allowed for a specific site. This means that sites can potentially have control over whether their content is allowed to be rendered inside an IFrame element – and where (on pages from 3rd party sites, only on pages within the site itself, or not at all).

The solution that is being proposed here is nice, but time will tell if or when sites would start adopting it. Nevertheless, while playing around with the new feature behavior, I noticed that without much PR, Firefox is also supporting the same functionality.

cj
Image 1: blocking the inclusion of a site in an IFRAME where the site returned a header X-FRAME-OPTIONS: DENY

cj2
Image 2: Firefox blocking the included IFrame, and showing the actual header returned from the site.

Now with only Chrome and Opera to jump on the bandwagon, we might actually have a chance to see some changes in the web security landscape (as you may remember – most of the web borne attacks are delivered through the inclusion of an invisible IFrame hosting malicious code). That isif only this protocol could have been reversed to define that no IFrames should be rendered ON a said site, thus preventing injected IFrame elements from being delivered to the users of a compromised site.

BlueHat post on the state of web security

I’ve been asked to contribute once again to the Microsoft BlueHat blog, and have written a quick “state of the web security” post. Check it out, and as always, feel free to comment or discuss whether in agreement or not.

The post is located here.
Cheers.