AntiXSS is an open source .NET assembly available for download from Microsoft (source here).  This library provides much more flexible XSS protection in .NET applications than the built-in Server.HTMLEncode() approach, as it adds support for XML and LDAP filter encoding in addition to HTML encoding.  By allowing flexible and secure encoding and decoding of strings for these types of data, application developers can breathe a little easier when accepting data across trust boundaries.

Libraries such as AntiXSS that perform string processing are incredibly useful for developers, for several reasons.  First, they are maintained separately from your code base, so any updates to the string processing functions for emerging threats can be applied without much hassle.  Second, by using a code library with a wide user base and is regularly maintained with updates from the developers, the risk of a security hole from a bad implementation is much lower.  Finally, it’s free – and your time developing custom string processing code is not!

You may have seen Ben’s post earlier this week on Firesheep. I am running a Mac and I use FileVault, as I recommend most people do in order to protect their sensitive files.  Unfortunately the current release of Firesheep does not support FileVault.  That didn’t stop me, here is what you need to get Firesheep running on Firefox 3.6.x on a Mac running FileVault from start to finish.

1. Download the Firesheep .xpi file here.
2. Drag the .xpi file into your Firefox browser window to install it, then quit Firefox.
3. Move the extension folder from your user account to the application folder.  The /Users/[youraccount]/Library/Application Support/Firefox/Profiles/[yourprofile]/extensions/firesheep@codebutler.com folder should be moved into the /Applications/Firefox.app/Contents/MacOS/extensions folder.
4. Relaunch Firefox, and you should be good to go.  If you receive an error related to “–fix-permissions”, make sure you moved the folder (and didn’t copy it), and if it still didn’t work try running once as root (sudo /Applications/Firefox.app/Contents/MacOS/firefox-bin).

Enjoy. Use responsibly. And encourage your local coffee shop owner to turn on WPA2 to limit its usefulness.

Here at Security Musings, we occasionally discuss some fairly technical topics. Like most speciallized subjects, there is a plethora of disorganized information, and occasional spatterings of highly organized resources on the Internet that help widen one’s knowledge and expertise in any given area.

One such spattering I recently came across is the online version of the Handbook of Applied Cryptography (not to be confused with the other book of similar appellation that is more-frequently used in college classes around the country).

Although it can get pretty nitty gritty at times with regard to the math and science involved in cryptography, sometimes that is exactly what you need to get the full picture and/or fill in the blanks that other resources gloss over in the interest of comprehensibility.

And best of all, the publishing company has released the chapters for free electronic distribution: http://www.cacr.math.uwaterloo.ca/hac/

Keep in mind, the last printing was in 2001, so some of the information may be a little aged. But if you’ve ever read any of our posts regarding public key encryption (Ch. 8, pdf), hash functions (Ch. 9, pdf), or digital signatures (Ch. 11, pdf), and wish we went a little further with the technical details, this just might satiate your thirst for knowledge.

By the time you read this, we may have run out of IPv4 addresses. If we haven’t, it’s coming soon; almost certainly by the end of 2010, though extreme measures may yet continue into 2011.

The obvious solution is to adopt IPv6, hermit crab-like, moving to the bigger, better shell.

But is IPv6 better?

Obviously, it has more address space. Far more address space. And features, oh the features.

Which is something of a problem, really…

IPv6 is chock-full of features, especially security. Which is great, except that these take up space. The fixed part of the header alone is 320 bits, about twice the size of an IPv4 header, and roughly as large as a typical IPv4 packet. Add in other extensions, and you’ve got a pretty gargantuan packet.

Now, it’s possible to work with a big packet; sometimes a really big packet is even a good idea. Other times, not so much. It’s an awful lot of overhead for the tiny packets which comprise the majority of packets sent…

But the real problem is one of philosophy. IPv6 tries to do too many things, to provide too many features. This doesn’t, as a general rule, work out well. The tools which stand the test of time aren’t intelligent, feature-rich toys. They’re simple, streamlined creatures which do one thing Very Well. Consider: does your VoIP phone use MGCP? Of course not; they use SIP. When was the last time you wrote code in Algol? But lo, COBOL is still in use today. And think about HTTP: one of the most commonly used protocols, and it has only been updated once since it was introduced. In each and every case, the simple, limited option has outlasted or supplanted the heavy, feature-laden one.

What does this all mean? Well, we’re going to go with IPv6. Slow as adoption has been, there has been major investment into it, and there aren’t any viable alternatives. But we’re going to outgrow the IPv6 features. We’re going to reach the point where its security is inadequate, the routing techniques it aids are obsolete, and there are new concepts which need to be addressed. IPv6 is going to become obsolete. Maybe it’ll be around a while, but it won’t be long. And yet the simple protocols will still be around. Maybe when we design the next version of IP, we’ll keep that in mind.

The big news of the week, emanating from Toorcon 12, is the release of Firesheep. This tool makes SideJacking – that is, “hijacking an engaged Web session with a remote service by intercepting and using the credentials that identified the user/victim to that specific server” – painfully simple for anybody to use. How easy? Well, let’s see… you download and install Firefox… and then you download and install the Firesheep extension to Firefox… and then you restart Firefox and run the tool to start hijacking sessions… that’s it! Simple enough for ya?

SideJacking is not a new concept, nor is the existence of tools. Robert Graham of Errata Security made a bit of a splash with his tool Hamster back at Black Hat 2007 (also see “Wi-Fi SideJacking opens eyes at BlackHat“). And, really, the concept of intercepting and hijacking sessions is even older than that. Poor session management continues to be on the OWASP Top 10 list, as does the lack of adequate transport layer protection (that is, SSL/TLS for web sites).

Read the rest of this entry »

When did password cracking get so hard? Remember LM hash? Obsolete since Windows NT, until Windows Vista it was on by default for backward compatibility. Even back in the day an external hard drive easily had enough room for a full set of rainbow tables and generating them only took a few days at most, depending on your computer speed. That is to say, brute forcing was actually possible. Even your moderately security conscious types who actually paid attention to complexity rules could fall victim to a password attack if their account was on any machine with LM hashes turned on.

Now it’s all NTLM hashes in the Windows world, and frankly brute forcing NTLM just isn’t feasible for your average me. The basic weaknesses in LM hashes such as 7 character chunks and all caps are no longer present. I was going to write some sort of analogy for how much space you would need to store just rainbow tables for alpha numeric characters with a maximum length of 10, but it started to give me a headache and I stopped. This leaves me with the word list option, to make an educated guess about what the password might be over and over again until either I am successful or I get a job as a street musician.

It’s been 15 years since Hackers the movie came out, and love, sex, secret, and god, won’t get you as far as they used to in password guessing. On a domain and even locally, administrators can set complexity and length requirements for passwords. Additionally user awareness is up. No doubt Password1 will still get you a few accounts within an organization, but more users, particularly the IT people, the ones with administrator accounts, are moving to the $frdh$OI!6G@ side of the spectrum (The downside of this of course is that $frdh$OI!6G@ is probably on a post-it somewhere). With letter, number, and symbol rainbow tables, I could crack $frdh$OI!6G@ in LM hash effortlessly, but it’s not going to be in any wordlist anywhere.

So why do I want to crack your password anyway? Password hashes are pretty well protected. If I can get the hashes, chances are I’ve successfully compromised the machine in question. However the one thing no hashing algorithm or security policy can fix is a user’s propensity to use the same password for multiple accounts. If I have the plaintext of your password for one machine or domain, it is very likely I will be able to authenticate on another.

It seems like dumping hashes isn’t as exciting as it used to be. I guess someone is doing something right.

Pen-testing as a job is quite boring compared to learning it or doing it for fun. Why is that? You have to be meticulous about logging every packet that goes between your machine and your client’s. You have to keep logs of everything you’ve tried and what worked and what didn’t. So, when the client comes back and says you crashed their servers, you can show them why/how you crashed them, or you can show that you weren’t doing anything that should have crashed their servers (aka, their servers are broke). You can also use those logs to find things that didn’t stick out at you initially. When you’re doing it for fun, you don’t have to worry about this kind of stuff – and it certainly adds to the time it takes to do things.

There are many tools you can use to get these logs. Almost all pen-testing tools have such logging built in, because the developers knew you’d need that functionality. If the tool doesn’t have logging built in, you can use a few command line tools (for command line testing tools) to record everything. ttyrecord and date are two of my favorites. ttyrecord records (like a video) in binary format all typing, commands, and responses that you type into a tty (aka terminal). It covers anytime you’ve logged in remotely to another system as well. It comes with ttyplay to play that information back and to make it human readable again. Typing date before and after any commands also shows your system’s clock so you can precisely time what you did when.

On GUI systems, the easiest is screencasting software, even if it’s large and uses way too much space. On Windows – screenshots are about the only option you’ve got as an alternative to screencasting, but then you have to remember to take screenshots, then order/reorder them according to what you did and what time it was.

Any other tools that you can use to capture these kinds of logs?

Facebook recently introduced some interesting functionality that’s being touted as an “opt-in security feature.” When I first heard that they were incorporating one-time passwords (OTP), I figured it was probably a pretty good idea. In theory, OTP seems straightforward to implement, and can offer some substantial benefits when done correctly.

However, after learning how Facebook expects people to request the one-time passwords (via mobile SMS), a potentially negative side-effect becomes apparent. Passwords are often the first line of defense encountered by an attacker. But in this case, OTPs actually undermine the benefit of the original password by creating a temporary token that can be used instead. This creates a security tradeoff, whereby the benefit of a secret password is sacrificed for protection against an untrusted system (kiosk, library computer).

This tradeoff isn’t inherent to OTP systems, and only exists for Facebook because the person requesting the access token is not required to prove their ownership of the respective account each time. Access to the mobile phone linked to the account is all that is required to access the goodies. In the time it takes to send a text message, an attacker could essentially hijack an account.

Curiosity and a few minutes alone with someone’s phone might be all you need to turn Facebook’s shiny new “security feature” into another privacy misstep.

OWASP’s AppSecDC 2010 is less than a month away, running at the Washington Convention Center November 8-11. The first two days provide attendees and locals with an excellent opportunity to attend high-quality training for very little money. In particular, Gemini Security will be delivering KRvW Associates‘ “Software Security Best Practices” curriculum. This course is a 2-day program that only costs $1,495! The curriculum is hands-on in nature, portable to most code bases, and builds on the successes of the OWASP Top 10 list, OWASP Live CD, and several years of quality curriculum from KRvW Associates.

We hope that you’ll be able to attend the conference and also take advantage of this, or other, training programs. Sign-up today!

Once upon a time, the Web was filled with static pages of text, hyperlinks, and the occasional image. Security problems existed even back then, but the pages themselves were generally innocuous. As the years went by, however, the Web became a platform for all sorts of communications and services. In time, the mild-mannered web page became a delivery mechanism for large-scale, dynamic applications. Even mobile browsers now include engines for loading powerful object-oriented programs. As the capabilities of websites expanded, the problem of HTML injection, or cross-site scripting (XSS), became a significant threat. Check any recent research on web-based threats, and you’ll find that this type of vulnerability is widespread online. And if the past few weeks are any indication, we can expect more trouble in the future.

HTML injection itself is hardly a recent issue, but current trends make it more common and more dangerous. In particular, the rise of user-generated content and “mashups” has led to far more data being shared across security contexts in real-time. One example made headlines last week after a few Twitter users discovered they could manipulate the site’s system for parsing links within a post to add custom HTML. Several tweets crafted to exploit this issue spread virally, as an action as simple as moving your mouse could trigger code that would post the same tweet under the victim’s account. Twitter’s entire product relies on user-generated content, but a simple filtering problem led to the rapid spread of XSS worms. Fortunately, none of these cases appeared to be that malicious.

In the realm of mashups, many sites are adding code to integrate with Facebook, providing users a single sign-on experience. A few websites have access to “instant personalization,” a feature that lets the sites identify Facebook users when they first visit rather than after clicking a login button. Soon after Facebook announced this program, a security researcher discovered that one of the partners, restaurant review hub Yelp, had an HTML injection vulnerability. With the addition of Facebook’s code, Yelp’s hole could be exploited to let an attacker automatically identify Facebook users as well. More recently, two new partners were added to the program: Rotten Tomatoes and Scribd. Soon after the announcements, similar problems were found in each of these sites. Ironically, Rotten Tomatoes’ pages were generally secure against HTML injection, but a third-party widget loaded by the site introduced a vulnerability.

HTML injection on one site threatens information and actions available to users of that site. But with so many websites sharing data between users and other companies now, one vulnerability may allow access to multiple services. And the problems don’t stop with the browser – injected code can try exploiting other issues that lead to compromising a user’s operating system. Meanwhile, the spread of mashups shows no signs of slowing. In fact, this past week Facebook’s COO Sheryl Sandberg predicted that within a few years, nearly all websites will automatically adapt to a visitor’s interests. Yet that sort of functionality requires identifying a visitor’s interests somehow, and Facebook’s instant personalization is one example of how that’s possible.

Securing a Web with so much data getting passed around is not an easy task. Douglas Crockford, a leader in the JavaScript community, has recently advocated that browser makers stop work on HTML5 and instead focus on building a more secure framework for handling scripts. Yet it’s more likely we’ll see a universally personalized Web before we see such functionality become mainstream, meaning web developers need to keep paying close attention to possible HTML injection issues. Preventing such vulnerabilities in an application would require more than a simple blog post, but fortunately many resources exist online, and the team at Gemini is ready to help you secure your code. In the meantime, I hope that the buzz about Twitter’s worms and problems with instantly personalized sites help draw more attention to HTML injection as the Web continues to expand. Hopefully future developers will learn from these stories and reduce their frequency in the future.