All posts tagged ‘Security’

File Under: Web Basics
Oct
1
2008

A Look at the ‘Clickjacking’ Web Attack and Why You Should Worry

By

noscript logoThere’s a nasty new security threat making waves on the web. Actually, clickjacking, as this attack is known, isn’t entirely new, but because no one has yet come up with an effective solution, it remains a serious threat. And clickjacking is the worst sort of security risk — it’s transparent to the unwitting user, simple to implement and difficult to stop.

The basic idea is that an attacker loads the content of an external site into the site you’re visiting, sets the external content to be invisible and then overlays the page you’re looking at. When you click a link you see on the current page, you are in fact clicking on the externally loaded page and about to load pretty much whatever the attacker wants.

To complicate matters, clickjacking is also a really cool, potentially effective user design tool. For an example of a benign case of clickjacking, consider the NoScript website, which uses the technique for positive ends.

NoScript is a Firefox plugin that stops JavaScript from running in your browser. The plugin is available through the Firefox add-ons site or through developer Giorgio Maone’s dedicated site. Now, as Firefox users know, when you try to load an add-on through a third-party site, the browser will block the attempt and show you a warning.

In the case of Maone’s site, it means an extra step is required for users to install the NoScript plugin. So Maone simply loads the Firefox add-on page in an iFrame, sets the content of the iFrame to visible:0 and then positions the frame over his own download button. The result is that while the user thinks they are clicking the download button on the current page, they are in fact clicking the download button from the Firefox add-ons page.

Because the Firefox add-ons page is a trusted source, Firefox doesn’t block the download, and users are able to get the plugin installed in a single click. While you could argue that this is still somewhat sneaky, it does make for a better UI experience on Maone’s site.

However, it isn’t hard to see how this could be used for much more nefarious ends. And it’s worth pointing out that an iFrame isn’t the only means of attack, clickjacking can work by loading Flash files, Silverlight, Java and more. To make matters worse, using JavaScript, an attacker could make the invisible target constantly follow the mouse pointer, intercepting a user’s first click no matter where it happens on the current page.

Developer Mark Pilgrim, who has been blogging over at the WHATWG blog, recently posted about clickjacking and outlines a number of possible solutions, none of which is ideal. One option would be to add a cross-domain permissions setup similar to what Flash uses, but even that model has problems. As Pilgrim writes:

This last approach moves us down a slippery slope towards site security policies for IFRAMEs and embedded content, similar to the Flash security model that allows trusted sites to access cross-domain resources. In practice, Flash crossdomain.xml files have a number of problems, and such an approach would still only cover a fraction of the possible use cases.

In the end, there doesn’t appear to be a an easy, or even complete, solution to the issue. As we typically point out when it comes to injection threats, using Firefox with NoScript is one of the best solutions (though in this case, even that isn’t 100 percent). For those using other browsers, Maone recently posted some suggestions for protecting against clickjacking, but unfortunately the usability consequences are pretty severe.

It will require some changes on the part of browser manufacturers to defeat clickjacking, but so far there’s no consensus on how to solve the problem. We’ll be sure to keep you posted.

See Also:

Tags: ,
File Under: Software & Tools
Sep
29
2008

Scripting Attacks Plague Even the Web’s Largest Sites

By

phishing.jpgTwo security researchers have released details on some very scary Cross-Site Request Forgery (CSRF) attacks that affect some of the largest sites on the web. The sites detailed in the report from security experts Ed Felten and Bill Zeller are ING Direct, YouTube, MetaFilter and the New York Times. The most disturbing is the ING Direct attack, which allowed attackers to transfer funds out of your bank account.

It used to be that most online threats could be avoided by the technically savvy — those of us not fooled by phishing e-mails and fake websites. But that isn’t true anymore, CSRF attacks are nearly transparent to the user and can come from sites you’d normally be inclined to trust. To perform a CSRF attack, the attacker places a bit of code in a web page (usually a chat board or forum) that initiates an action at a different website where you’re already authenticated. So, if you have a local cookie stored that automatically logs you into your banking website, for example, the attacker can effectively pose as you and request fund transfers without you ever knowing about it, or even clicking on anything.

The details in the report make it clear that CSRF attacks are no longer something confined to the dark corners of the internet, but could in fact be lurking on nearly any page.

Fortunately, Felten and Zeller reported all the vulnerabilities to site administrators and the holes have been patched. Well, except for the New York Times flaw, which was reported over a year ago and still hasn’t been fixed. Apparently the Gray Lady moves rather slowly when it comes to security.In the case of the Times site, the attack is primarily useful for gather e-mail address; Felten and Zeller write:

An attacker can forge a request to active the “Email This” feature while setting his email address as the recipient. When a user visit’s the attacker’s page, an email will be sent to the attacker’s email address containing the user’s email address. This attack can be used for identification (e.g., finding the email addresses of all users who visit an attacker’s site) or for spam. This attack is particularly dangerous because of the large number of users who have NYTimes’ accounts and because the NYTimes keeps users logged in for over a year.

Perhaps the most interesting note in the post is the takeaway where Felton and Zeller write, “if you’re in charge of a website and haven’t specifically protected against CSRF, chances are you’re vulnerable.”

In other words, unless you’re taking active steps to secure your site against CSRF attacks, your users have no reason to trust you.

If you’re worried about CSRF attacks on your favorite sites, one of the best ways to avoid them is to use the Firefox browser with the No Script add-on, which prevents such scripts from ever loading. Also, always choose the Log Out option when you leave a website. Furthermore, if you’re a site owner who uses persistent cookies on your website, your users are at risk. We’d recommend you start by reading the full report and the CSRF Wikipedia page, which goes into greater detail.

[via Simon Willison]

See Also:

Tags:
File Under: Software & Tools
Sep
29
2008

Yahoo Mail Security Flaw Exposes Passwords

By

ZimbraA hacker working on a way to access Yahoo Mail via IMAP, recently discovered that Yahoo’s desktop e-mail client is sending your password as plain text. That’s bad news for those of you using the desktop client over public wifi connections, where just about anyone with the know-how can see your unencrypted traffic.

Zimbra, creators of what is now the Yahoo Mail desktop client, responded to the news by assuring users that a fix is already in the code and just needs to be pushed out. The problem however seems to be primarily on Yahoo’s end, since the IMAP servers appear to refuse secure connections.

A Zimbra employee writes on the company’s forum site:

This issue has been addressed from Yahoo mail server side and the patches have just been rolled out to all servers. We added related support in desktop client code and it’s in the next release. Once we roll out the next release, server will phase out the old way of authentication. The new way of authentication will not send password over clear channels.

In the mean time we would suggest sticking with the web-based e-mail client when you’re working on public or otherwise insecure internet connections.

See Also:

Tags: ,
File Under: Software & Tools
Aug
20
2008

Flash Attack Hijacks Your Clipboard

By

FlashiconNoticed anything strange in your clipboard lately? There’s a new Flash-based attack percolating across the web that can inject potentially dangerous URLs into your clipboard, which you might then inadvertent paste into your browser’s URL bar.

Adobe has acknowledged the attack and says it is investigating a fix. In the mean time, exercise caution when copying Flash data to your clipboard.

It would appear that the attacks are apparently quite sophisticated. Security research firm Sophos reports that, “if the professional looking sites that are being used to distribute this fake alert malware are anything to go by, the criminals behind it are very organized.”

The company goes on to say that the attackers are “using aggressive techniques to infect victims as well — for example large spam campaigns and compromised web sites.”

That means just because you trust the site, doesn’t mean it hasn’t been compromised.

We’ll be sure to let you know when a fix or Flash upgrade is available.

See Also:

Tags: ,
File Under: Software & Tools, Web Basics
Aug
19
2008

Why You Should Turn Gmail’s SSL Feature On Now

By

Let’s talk security and why you should take advantage of Gmail’s recent SSL feature, and why you might want to be careful using other non-SSL webmail services.

But first, make sure your connection is secured using SSL.

How do you know a connection is secured by SSL? The handy “s” after “http” will tell you. For example, https://mail.google.com is encrypted while http://mail.google.com is not. You can force an encryption by adding the “s” yourself, or by turning on “Always use https” from the Browser Connection settings of your Gmail account.

Why? Because without it, anyone can easily hack someone’s account and in two weeks it is going to get even easier. Mike Perry, a reverse engineer from San Francisco, announced his intention to release his Gmail Account Hacking Tool to the public. According to a quote at Hacking Truths, Perry mentioned he was unimpressed with how Google presented the SSL feature as less-than-urgent. It is urgent, and here’s why.

Before Gmail released the ability to automatically encrypt your Gmail connections, your browser/server interactions went something like this:

Your Browser: Hey there Gmail, I want in. Here’s my encrypted login.

Gmail Servers: Hey there, browser. I see your encrypted login fits what I have here. If you want to keep talking to me, I will need to see proof of your login, but don’t bother encrypting it for me. Here is your unencrypted email.

Your Browser: Great. I want to read this particular email, my Gmail login is: webmonkey@wired.com and my password is: monkeylove. My name is John Hanks Doe and my social security number is 123-45-6789.

Gmail Servers: Sure, here you go. I see you are leaving for vacation with the house unlocked this weekend. Say, is this your credit card information?

Guy packet sniffing your wi-fi from Starbucks: Cool!

It’s a little more complex than that (and a little less goofy and dramatic), but the theory is sound. Using encryption at login only is the equivalent of setting up a toll booth in the desert.

Here’s the exploit: All it takes to steal someone’s Gmail login account is to intercept any transaction since every single one, even images, pass a cookie which contains the session information.

Spoof the session, and you get free reign to the account — including the ability to change your password. Every non-SSL session is in plain text. With a little determination, any bored, disaffected youth could read your email and change your password within a day. Is it really that easy? Here’s a useful tutorial we found via Google search. When the Gmail Account Hacking Tool is eventually released, it couldn’t be any easier.

With SSL, however, the interaction looks something like this:

Your Browser: xz6RV-BRJViqzNJROECslw

Gmail Servers: jx3iC96D3kuZ_IWNrK461w

Your Browser: PxIryG_P3_3_vRENZdWxMQ

The real thing would be even longer in length, and perfectly unreadable. SSL requires a key generated on your end and on the Gmail server’s end. There’s no way for the local guy at Starbucks to get those keys and unencrypt the data by packet sniffing.

Makes you feel a little vulnerable knowing all your public information was so nakedly exposed over the past few years, huh? Did Google know about this?

It turns out they were well aware of it. The reason Google didn’t grant users the SSL feature before, according to Perry, was because SSL is expensive. It takes a lot of bandwidth and time on both the receiver and transmitter sides to generate keys and encrypt data. Slower data connections would experience a lagging Gmail experience.

Packet sniffing for session information is not a new thing, and is bound to get even more familiar due to how easy it is. Keep in mind, it is not just Gmail which passes account information outside of SSL encrypted connections. There are many sites around the internet that are still vulnerable to this exploit. Protecting your wifi connection with WEP isn’t foolproof either. Your best bet is to use SSL whenever you are transferring information valuable to you, and to avoid sites that don’t use it at all.

[Thanks to Hacking Truths for the tip.]

See Also:

Tags: , , , ,
« OLDER POSTS