Getting the CSSLP

I am pleased to report that I'm now a Certified Secure Software Lifecycle Professional, or CSSLP. This is an (ISC)² certification introduced late last year. The name doesn't exactly roll off the tongue, but my employer was kind enough to pay the $550 fee (normally $650) for me to go through the gauntlet required to get this cert. Actually, it wasn't that bad. Up until March 31, 2009, CSSLP candidates are not required to take and pass an exam. Instead, you have to submit and pass the CSSLP Experience Assessment. Essentially, this consists of submitting your current resume, writing four essays of 250-500 words each, and getting an endorsement from an (ISC)² credential holder.

The four essays are not difficult if you have the right experience, but they were time consuming for me. I spent about an hour on each one. The essays must describe your professional experience in 4 of 7 different topic areas:

1. Applying Security Concepts To Software Development
2. Software Requirements
3. Software Design
4. Software Implementation/Coding
5. Software Testing
6. Software Acceptance
7. Deployment,Operations, Maintenance And Disposal

I have experience in all of these areas, but I chose #1, #3, #4, and #5 for my essays. These topic areas correspond to the domains that represent the CSSLP Common Body of Knowledge (CBK). I'm looking forward to using my experience and knowledge in this area more as time goes on. There seems to be a nascent trend in the industry to be more proactive about developing secure applications, hence a new cert like CSSLP. I believe assessments and penetration testing will continue to be important, but introducing security elements earlier in the process is bound to pay off in more secure software. Hopefully, my new certification will pay off my company and for me.

DirBuster Shoots and Scores!

There's a new tool I'm using as part of my security assessments and it is DirBuster. Developed by James Fisher and now available from OWASP, DirBuster's purpose is to sniff out the existence of directories and files on a server. Nothing more and nothing less. I did not have high expectations when grabbing a copy of DirBuster from the OWASP site. I was shocked at how many features it provides and how well it performs! Don't let the version number of 0.12 fool you. It's a very capable and polished tool.

DirBuster is written in Java (requires v1.6 or above), and the user interface is simple and intuitive. Even the look and feel is top-notch - much better than WebScarab or Burp Suite, for example, which use the default Swing look and feel. James wisely chose to use JGoodies, an open source library designed to make a more esthetically-pleasing Java user interface.

Once you start a scan, DirBuster goes to work. It lists directories and files as they are found. Since some servers don't return 404/Not Found for non-existent directories and files, DirBuster identifies positive hits by comparing each response to a base response for a known, non-existent resource.
Some of the bells and whistles in DirBuster include:

• configurable number of threads and ability to throttle up or down while a scan is running
• ability to scan for directories, files, or both
• file checks are done using extension(s) of your choice
• ability to narrow a scan to a particular subdirectory
• ability to do recursive scanning
• ability to load payloads from a file or to configure pure brute forcing
• customizable request headers
• support for basic, digest, and NTLM authentication
• fuzzing capability for resources that are referenced by URL parameter
• ability to send traffic through a proxy
• an informative scan status screen
• report generation (text files)
  
• automatic update feature

For being so polished, DirBuster has some quizzical misspellings. Another small quibble is that the tool's "advanced options" are not saved after you close it down. The author told me there is a new version in the works, and both of these issues will be addressed.

CSRF in Novell GroupWise WebAccess

Adrian Pastor found some nasty CSRF issues in Novell GroupWise WebAccess. The one that is truly evil genius is being able to use CSRF to create a forwarding rule in the victim's email settings, allowing an attacker to get a copy of every email the victim receives. Imagine if an executive in a company fell victim. Talk about information leakage!

The point about CSRF that many people do not understand is that you can fall victim

• without knowing it has happened
• without clicking a malicious link
• without JavaScript enabled in your browser
• with your company having an iron-clad perimeter firewall

The vulnerabilities were responsibly disclosed and Novell has a patch available. It'd be nice to know how the remediation was done. Alas, I do not have a GroupWise system into which I could dive.

Keeping Your RapidRez Number Safe... Not!

I went through a web application for enrolling in Budget's Fastbreak service not too long ago. Upon completing the process, they gave me a special number, called my "RapidRez" number. The final page displayed my RapidRez number and gave a warm and fuzzy message stating that "for security reasons" they won't send me an email confirmation with my number. The page looks like this:

Let's ignore the fact that the HTML is screwed up, which causes the "NTRA end" comment to be visible in Firefox. Inspection of the HTML source revealed something much more interesting and somewhat disturbing.

As you can see, my RapidRez number, which is so sensitive that Budget does not want to send it to me via email, was sent to a server called adfarm.mediaplex.com. I have no idea what if anything Mediaplex does with all the RapidRez numbers they are collecting. My personal opinion is that Budget should not tout the sensitive nature of these numbers and then proceed to send them to a third party. At least don't make it so obvious! If sensitive data needs to be sent to business partners, I would suggest doing it a different way, such as a nightly batch process over a secure channel.

IE Developer Toolbar Incompatible with HttpOnly Cookies

Today I discovered that the Microsoft Internet Explorer Developer Toolbar is not able to "see" cookies marked as HttpOnly. This is illustrated in the figures below.
Essentially, this behavior tells me that the tool accesses the cookies using JavaScript (or client-side script of some sort). Since Microsoft originated the concept of HttpOnly, you would think their tool would be able to handle it. Unfortunately, it does not, and I'm running the latest version (1.00.2188.0).

The Firefox Web Developer Toolbar, a great extension created by Chris Pederick, suffers from no such problems. Below are some screen shots to illustrate. Although it wasn't created for web application security professionals, it is an unbelievably useful tool and I highly recommend it. I often use it during application assessments to manipulate cookies, inspect forms, view all JavaScript, switch form actions from POSTs to GETs, and much more.

Netflix CSRF Revisited

A little more than two years ago, I notified Netflix about CSRF vulnerabilities on their web site. They fixed the most serious issues, such as using CSRF to change account name and shipping address or to change email address and password. I confirmed this with my testing at that time. However, I also noticed they had not implemented protection for using CSRF to add movies to a user's rental queue. I thought it strange and decided it was purposefully not done for business reasons.

I decided to revisit the issue this week by trying my original proof-of-concept CSRF attacks where any movie of an attacker's choice could be added to the top of the victim's queue. Sure enough, nothing has changed on that front. I think Netflix is risking reputation damage by not adding CSRF protection to the URL that invokes the "add movie" action.

Let's say you're logged into your Netflix account and are surfing around the Web. If you happen to encounter a page where someone has created HTML like the following, you will fall victim to a CSRF attack and have a potentially embarrassing movie arrive in your mailbox.

<html>
<head>
<script language="JavaScript" type="text/javascript">
function load_image2()
{
var img2 = new Image();
img2.src="http://www.netflix.com/MoveToTop?movieid=70110672&fromq=true";
}
</script>
</head>
<body>
<img src="http://www.netflix.com/JSON/AddToQueue?movieid=70110672" width="1" height="1" border="0">
<script>setTimeout( 'load_image2()', 2000 );</script>
</body>
</html>

Now, if you are a Netflix subscriber and want to see this sucker in action, here's your chance!

First, make sure you're logged into your Netflix account. Next, click the following link and then go check the top of your Netflix rental queue.

click here if you're logged into Netflix and want to fall victim to CSRF

Happy New Year

Happy New Year! It is 2009 and I've decided to celebrate by joining the 21st century and starting up a new blog on application security. It remains to be seen how often I will post, but hopefully it will prove interesting and/or useful to people.