What you need to know about HTTP Verb Tampering

June 4, 2008 – 7:29 PM

Recently Arshan Dabirsiaghi, Director of Research of Aspect Security, published a white paper entitled “Bypassing URL Authentication and Authorization with HTTP Verb Tampering”. Initially there was a lot of confusion about what exactly was being explained or claimed. Including, is it real? Is it novel? Is it dangerous? What is this? Most will get lost in the semantics of the debate and only care if it impacts them in some way. So I hope to get to the relevant bits, borrow from Arian Evan’s summaries, and make things a bit easier to understand.

1) No one is claiming the HTTP Verb (GET/POST/HEAD) manipulation is new. Manipulating what type of HTTP request a webapp is expecting to receive, such changing GET to POST and POST to GET, has been done for years. Our websites should only be using the types of requests we expect to receive and no more. What is interesting here is when it can be used and for what purpose.

2) HTTP Verb tampering is generally used in conjunction with syntactic (XSS, SQLi, etc.) and semantic (bypass authentication/authorization controls) attacks as way to bypass certain defense measures. Arshan’s work on implementation details focus on the semantic version.

3) In syntactic attacks you can use verb manipulation to get malicious data (‘ DROP TABLE …’) in a session object that might now have otherwise been allowed. i.e. Query string parameters were sanity checked, but the attacker used POST placing the data in the message body where it was overlooked by the application. This can lead to SQLi, XSS, and several other common technical vulnerabilities.

4) To protect yourself from syntactic HTTP verb manipulation attacks, make sure you only include user-supplied data from where it’s expected to be received (Query string or POST data), or sanity check them both the same if necessary. Also only include the parameter names in the session object you expect to receive. Don’t allow attackers to add arbitrary name/value pairs.

Read the rest of this story…

A Tour of Risky Web Sites

June 4, 2008 – 10:22 AM

Just over 4% of all Web sites are dangerous, according to a new report. But all bad sites aren’t created equal: Cyber bad guys are more likely to build their sites where it’s easy to do so.

The report out today from McAfee, a tech-security company that’s trying to position itself as the Internet’s guardian angel, ranks so-called domains — the letters at the end of an Internet address like .com, .org, or .uk – by the percentage of risky sites they contain. Web sites are considered risky if they have files that, if downloaded, could give a hacker control of a visitor’s computer, or if filling out a form on the site resulted in a bombardment of spam emails.

McAfee found that 5% of addresses that ended in .com are risky, which is about average. The real risk comes from Web sites within more obscure domains, like .info, where 12% of the sites are risky. Also, sites registered in different countries have different degrees of risk. Nineteen percent of sites that end in .hk, the domain for Hong Kong, are risky, according to the report. Among the reasons: In order to encourage people to register .hk sites, Hong Kong allowed people to sign up for multiple sites at a time without filling out multiple applications, offered a two-for-the-price-of-one sale on .hk sites, and promoted the .hk domain overseas.

The Pacific island Tokelau, which offers the .tk domain, once allowed people to sign up for Web sites anonymously, and for free. It was able to reduce the number of risky sites by 86% by changing its policies, McAfee found. McAfee also reports that countries such as Japan (.jp), and Australia (.au) that have restrictive policies for registering domain names also have fewer riskier sites.

One other piece of good news: Web sites that automatically install malicious software on a visitor’s computer account for just .07% of all sites. That means that most risky sites still require visitors to download a file or fill out a form.

Source: The Wall Street Journal

How to Harden Your Mac

June 4, 2008 – 9:44 AM

If you’re a quasi-sophisticated Mac user and have been looking for advice on how to better safeguard your machine from hackers or local prying eyes, look no further: Apple has released a massive, 240-page guide that describes various methods for securing the operating system.

According to SecurityFocus.com, the manual includes an overview of the Mac OS X’s security architecture and advice on hardening the operating system against external attackers. It also includes information on locking down the system to protect against unauthorized access by people with physical access to the system.

Before you delve into this guide, you might want to familiarize yourself with Apple’s “Terminal,” the text-only command line interface for the Mac: The guide relies heavily on this tool, and Apple warns readers that only technically-adept users should use the guide.

Source: Washington Post Blog

Pandora Desktop Beta

June 4, 2008 – 6:25 AM

We’ve always wanted to find a simple way to deliver Pandora as a desktop application — it’s probably been on our to do list longer than any single feature. Today we’re dipping our toe into those waters for the first time with the release of a Beta version of Pandora Desktop.

Truth is, this little guy is pretty simple. It’s just a way to pull Pandora out of a browser window and make it accessible with a single click from the Windows tray or Mac dock. We’ve built in quick access to common Pandora features from the tray/dock menu (pause, change stations, etc). If nothing else it ensures that you’ll never accidentally browse away from Pandora and lose your stream.

One big caveat: it’s important to understand that at Pandora we have big licensing and streaming bills to pay and from the beginning we’ve been working hard to figure out that piece of the puzzle. That means that advertising is an integral part of the Pandora experience and in an effort to keep the advertising as unobtrusive as possible we’ve focused on graphical ads rather than audio ads. The one downside to that is that we need lots of pixels to run the ads, so one thing you’ll find with the desktop app is it’s not some tiny little widget. As nice as that would be, it would make it basically impossible for us to cover our costs with advertising. So, at least for now, the main window of Pandora Desktop (which you can minimize) looks pretty much exactly like the Pandora.com home page.

One little caveat: this is a Beta and we’re asking you to take a look and send us your thoughts and feedback to [email protected]. We’re interested in everything from bug reports, to feature requests, to commentary about the general utility of the application.

The application is built using Adobe AIR, which should automatically install if you don’t already have it. If you have trouble with that step, there are links for a two-step manual install too.

Known issues: performance of the Mac version is more CPU intesive than we’d like it to be. This seems to be an Adobe AIR issue and we’re working with Adobe to understand what we might be able to do to improve the situation.

To get started, visit this page: http://www.pandora.com/desktop and don’t forget to send us your feedback.

Source: Pandora Blog

Making The Move To Multiple Browsers

June 3, 2008 – 6:19 PM

For a while now I’ve been using different web browsers to compartmentalize my risk. Most of my primary browsing is in one browser, but I use another for potentially risky activities I want to isolate more. Running different browsers for different sessions isolates certain types of attacks. For example, unless someone totally pwns you with malware, they can’t execute a CSRF attack if you’re on the malicious site in one browser, but using a totally separate browser to check your bank balance. Actually, to be totally safe you shouldn’t even run both browsers at the same time.

Last night I was talking with RobertRsnakeHansen of SecTheory about this and he finally convinced me to take my paranoia to the next level.

Here’s the thing- what I’m about to describe may be overkill for many of you. Because of what I do for a living my risk is higher, so take this as an example of where you can take things, but many of you don’t need to be as paranoid as I am. On the other hand, Robert is at even higher risk, and takes even more extreme precautions. I also purposely use a combination of virtualization and browser diversity to further limit my exposure. In all cases there are completely different applications, not just instances of the same platform.

My web browsers break out like this. I won’t list which specific browsers I use except in a few cases:

  1. Everyday browsing: low risk, low value sites. I use one of the main browsers, and even use it to manage my low value passwords.
  2. Everyday browsing 2: slightly higher risk, but even lower value. Basically, it’s the browser in my RSS reader.
  3. Blog management: a third browser dedicated to running Securosis. This is the bit Robert convinced me to start. I use it for nothing else.
  4. Banking: Internet Explorer running in a Windows XP virtual machine. I only use it for visiting financial sites. To be honest, this is as much a reflection of my bank’s web app as anything else. I can deposit using my scanner at home, but only in IE on Windows.
  5. High risk/research: a browser running in a non-persistent Linux virtual machine. Specifically, it’s Firefox running off the Backtrack read-only iso. Nothing is saved to disk, and that virtual machine doesn’t even have a virtual hard drive attached.

This setup isn’t really all that hard to manage since it’s very task-based. Now the truth is this only protects me from certain (yet major) web based attacks. If my system is compromised at the OS level, the attacker will just capture everything I’m doing and totally own me. It doesn’t prevent the browser from being that vector, so, like everyone, I take the usual precautions to limit the possibility of malware on my system (but no AV, at least not yet).

For you average users I recommend the following if you don’t want to go as far as I have:

  1. One browser for everyday browsing. I like Firefox with NoScript.
  2. Another for banking/financial stuff.
  3. If you go to “those” sites, stick with a virtual machine. Oh don’t pretend you don’t know what I’m talking about.

Source: Securosis