WhiteHat Security Blog

As anyone in Web security will confirm, there’s no shortage of vulnerabilities in custom Web applications. On the average website, WhiteHat Security identifies at least dozens, more often hundreds, of custom Web application vulnerabilities per year. Any one of these vulnerabilities may lead to total or partial system compromise, user account takeover, data loss, fraud, and so on. When such a vulnerability is found, the next task is getting it fixed. The task of vulnerability remediation has proved to be a rather large challenge for many organizations.

Often an organization will want to fix their vulnerable code, but they’re development team is oversubscribed delivering revenue generating features. Diverting their attention is just not an option. Given the choice, the organization may prefer to pay for the problem to go away. In short, to pay someone to come in and fix their vulnerable code for them.

Generally speaking, penetration-testing, vulnerability assessment, source code reviews, etc. whether speaking of tools or service providers, only FIND the vulnerability, they don’t FIX the code. They provide guidance on HOW they recommend the issue is fixed, but not the code fix itself. That’s the organizations responsibility.

Fortunately there are an increasing number of firms who are ready and willing to perform vulnerability remediation services. They’ll actually show up and fix your code! I’ve been building a list of them (see below) because people ask me about this all the time.

It is very important that this list is NOT considered an official endorsement of any kind as I only have personal experience with a few. If you need a recommendation and/or an introduction, just send me an email directly and I’d happy to help out: jeremiah -at- whitehatsec.com.

1. Accuvant
2. AhnLab
3. Aspect Security
4. AsTech Consulting
5. Asterisk Information Security
6. BCC Risk Advisory
7. Cigital
8. Denim Group
9. Foundstone
10. Gotham Digital Science
11. iSEC Partners
12. KPMG (Australia)
13. Security Compass

Please forgive the title, but today’s topic is something to be wary of if you write (or use) any access control / authorization type code in Web-based J2EE apps: HTTP URL path parameters. Many people are unfamiliar with HTTP URL path parameters (and they are uncommon), but they are something you should be aware of. A simple description of url path parameters can be found here. Essentially, path parameters are the bit of a url path that immediately follows a semi-colon (a semi-colon is the most popular path parameter delimiter). So, here’s an example of 2 urls, each with an http path parameter:

http://www.mysite.com/admin/UpdateUserServlet;jsessionid=OI24B9ASD7BSSD

http://www.mysite.com/admin/UpdateUserServlet;/user/HomeServlet

We’ve all probably seen the first example, where a jsessionid gets attached to our url, many times. However, take a look at the second example. Pay very close attention to what is being presented here: The request is going to the administrative UpdateUserServlet, but with a path parameter of /user/HomeServlet. Now, what problems could this create? Well, in most cases there are actually two issues that must be dealt with.

Issue 1 – The Server Product and Version

The first issue is how your servlet container/app server product and version handle certain request APIs. That’s because different products – and even versions – apparently deal with http path parameters in different ways. (I have yet to do the work that determines which servers and versions are affected, but you should do that in your own environment, as even configuration changes can apparently cause slightly differing behavior. These variations are caused by – read “blamed on” – a lack of clarity in the servlet spec regarding path parameters.)

This first problem can be observed when using certain API calls from the HttpServletRequest object, and then seeing how those APIs handle path parameters. Two of the affected methods are getContextPath() and getServletPath(), where there are variations between whether or not these calls actually strip out any path parameters depending on server product and version. Again, this is testing that you will need to do on your own. The alternative to testing is to make assumptions, and you’ll see below what can happen when those assumptions are wrong.

Issue 2 – Your Code

Here is where the actual security problem really shows up…when we use these APIs. One of the most common uses of the Request URL related APIs is for writing access control / authorization code. Many access control frameworks or internal codebases use a url mapping concept of some kind. These concepts vary widely in how they are implemented, but a simple example might be: Anything with “/admin/” in the path requires the admin role, or anything that ends in “UpdateServlet” requires the manager role. Let’s use the “ends with” example and walk through some code.

String uri = request.getRequestURI();   //note getRequestURI will always return the full path with path parameters but not request parameters
if (uri.endsWith(“UpdateServlet”)) {
//require the manager role here
} else {
//just require standard user role
}

Although this is a very trivial piece of code, it will be similar in spirit to what is in lots of access control code in j2ee apps. In this example the developer was expecting the user to send a request that looked like:

http://www.mysite.com/app/UserUpdateServlet

when they were trying to get to the update servlet. But what happens if the user sends a request like:

http://www.mysite.com/app/UserUpdateServlet;/app/UserReadServlet

THIS IS THE PROBLEM! Now that the app code has checked the URI, and sees that it ends with ReadServlet, and not UpdateServlet, the app code requires only the standard user role, and the access control check passes. However, the app server/container sees that the ACTUAL request is going to UserUpdateServlet, and allows the user to go there. Now we have an access control bypass issue! The user has been able to circumvent your “protection.”

DOH! Ok, now what…?

Fixing the Problem

There are several ways you can address this issue, and each way varies in difficulty and correctness.
1. You can whitelist all of your allowed requests and compare them to pre-determined acceptable urls, but that could become cumbersome with a very large app.
2. You can perform some cleansing (stripping) of the url path parameters, but that can be an issue if your app server allows various path parameter delimiters.
3. You can compare from the start of the URI or path, instead of checking the end. This would likely have the same limitations as the whitelist option.
4. You should definitely check your app server/container (on every upgrade, as well) to see what its actual behavior is regarding path parameters.
5. You may be able to perform your access control check at the beginning of a request handling piece of code, like a servlet, or action. That way, you know the code that is actually being executed, so it’s the url you should be verifying. However, this method lacks centralized control over your checking process.

There are certainly more options than those methods listed here, and you know best what will work in your code, but hopefully these five options will help as a starting point.

References

As an example of applicability, there was a relatively recent important bug in the Spring Security (formerly Acegi) project that was caused by the path parameter issue discussed here. More information can be found at the following 2 urls:

http://www.springsource.com/security/cve-2010-3700

http://seclists.org/fulldisclosure/2010/Oct/437

During RSA Dave Aitel, CEO of Immunity, asked me a statistics question relating to website security. Dave asked, “What percentage of websites is WhiteHat seeing as vulnerable to SQL Injection — without needing to authenticate?” That last detail is important, especially in the era of mass blast SQL Injection worms and prolific bad-guy-scanner-use searching for victims of opportunity.

I didn’t have the number off the top of my head, would have to look it up in the WhiteHat Sentinel database to be certain, but my first impression was it’s probably around 5%. I thought so was because we’re currently tracking about 14% of all websites having had at least one SQL Injection vulnerability (slide 13). Restricting to non-auth would obviously drag the number down.

To Dave’s surprise, 5% was what he is measuring as well, as was as one other he asked. I asked WhiteHat Security’s resident data scientist, Bill Coffman, to provide the real figures.To first understand our data scope, WhiteHat Sentinel is used to perform continuous vulnerability assessments on thousands of publicly facing websites. 500+ companies in all, large and small, and across industries such as financial services, retail, healthcare, energy, etc. The large majority our vulnerability assessment are conducted in a logged-in state.

Fortunately, we offer a service line named Baseline Edition (BE), which does not authenticate. BE is generally for customers who only require a “baseline” level of testing comprehensiveness, usually deployed broadly across their entire website portfolio. So, Bill restricted our data set to only a BE covered websites, which ended up encompassing many hundreds.

Of all BE websites, created under WhiteHat Sentinel before March 2011, yielded 5%. That is, 5% of websites have had at least 1 SQL Injection vulnerability without needing to login!

We restricted the sampling to a year back to ensure the websites had all their scans properly configured and had enough time to complete over a long enough period. Newer sites are not in a stable state to be statistically representative.

There is one potential caveat in the data, which we can’t properly account for that is likely to move the percentage up. Just because an assessment is conducted in a logged-in state does not mean the URL that’s vulnerable to SQL Injection can’t be exploited while NOT logged-in — an authentication / authorization issue, which should up on our statistics report top ten.

So, those are our numbers. If you are in the website vulnerability assessment business, what are yours?

 

 

Following my TEDxMaui presentation, a great many every day people have been emailing, Facebook’ing, and Tweet’ing me asking for tips on how to keep themselves safe online. Safe from malicious software attacks, safe from their online account getting taken over, and safe from their PC getting hacked. This post is for them.

No one wants to end up like the guy on Flickr who had five years worth of photos deleted, like the woman whose personal email box was hacked and held for ransom, like the thousands on Facebook whose accounts have been taken over and friends scammed for cash thinking they are helping you out of a jam when really some miscreant is assuming your identity. Perhaps worst of all like the people whose computers were hacked into and an intruder quietly flipped on their video camera to record their most intimate moments and proceeded to toy with their lives.

Poor economic conditions being what they are, perhaps having your online bank account liquidated by organized criminals may not be all that bad relative to these poor people — even with no guarantee you’ll get your hard earned money back. The reality is all these things and more are painfully common and go largely undetected.

Don’t be fooled for a second into thinking antivirus companies are going to save you, nor a corporation’s generic we-take-security-very-seriously-we-promise-policy, and certainly not law enforcement. These guys get hacked just like everyone else and are completely overwhelmed by billions of dollars lost every year due to online fraud already. They are very unlikely to understand, help, or even investigate your particular situation.

The undisputable fact is you, and you alone, are the best defense against getting hacked and getting taken advantage of. Keep in mind that getting hacked is not act of nature like a flood, earthquake, or tsunami. Getting hacked can be avoided. The steps to do exactly I’m going to share with you are simple, won’t cost you a dime, are sometimes a little unconventional, but they are most definitely effective. These are the same things security pros do to protect themselves. There is no reason why you can’t use them too!

 

Must-Have Software

 

1) Upgrade Microsoft Windows or Mac OS X

Outdated software is the enemy of online safety and security. Fortunately this process is easy and you should do this right now, even before reading the rest of this article.

If you use Microsoft Windows…

Fire up your Internet Explorer web browser and visit Microsoft Update. Just follow the instructions on the screen to update your system with the latest software. Next download and install Microsoft Security Essentials, which is their free antivirus software package.

If you use Mac OS X…

All you have to do is click the Apple logo in the top left of your screen, select “Software Update…”, and then follow along.

 

2) Install a modern Web browser. Better yet, pick two!

You do know what a Web browser is right? Not everyone does. A Web browser is the software you use to surf the Web and visit websites like Facebook, Gmail, and Amazon. Chrome, Firefox, and Internet Explorer are all solid and speedy Web browsers. The choice between them is largely personal preference.

If you already use one of these browsers, great, just make sure you are running the very latest version. Nothing brings a smile to a malicious hackers face like a victim with an ancient browser, such as Internet Explorer 6. It’s like a professional car thief walking up to a car without any anti-theft devices installed, gone in sixty seconds.

If you are a Windows and Internet Explorer user, and you performed step 1, you are all set. If you use Chrome, click the wrench in one of the browser windows and select “About Google Chrome.” If you need to update, the “Update Now” button will allow you to click it. For Firefox, it’s the same process as Chrome. Go to the “About Firefox” window, and if you need to update a button to press will be there.

Next, install a different browser from the recommended list, because you’ll need two for the safest browsing experience.

 

3) Install ad blocking extensions

If you’ve chosen Chrome or Firefox as one of your Web browsers, you are going to absolutely love ad blocking extensions like Adblock and Adblock Plus. These extensions allows you to surf the Web without ads, which also has a powerful benefit of increasing security and privacy automatically.

Malicious software often infects computers through viewing or clicking of online advertisements. When you actually want to see ads, don’t worry, it is really easy to turn on and off when you want.

For extra privacy, consider installing either Disconnect or Ghostery extensions. Essentially all online advertisements are “trackers,” which stalk you around the Web profiling your online habits, but not all “trackers” are advertisements. Disconnect and Ghostery block these invisible trackers and aid in protecting your online privacy.

 

Online Street Smarts

Think of the Web like an inner city. There are some really great places to visit, enjoy nice meals, and hang out with friends. However, as in any inner city with over one billion people, there will be some shady characters lurking around trying to scam and rob you. You have to keep your guard up. The problem is the digital world makes it tough to see and therefore avoid dangerous street corners. I’ll show you how.

 

4) Your weekend browser and your commuter browser

Many people drive one car every day to work and keep a nicer one in the garage ready for the weekends or a night on the town. Your two browsers should be used the same way. Choose one, your commuter browser, for every day surfing. Read news, play games, watch YouTube, whatever. Just don’t login to anything you consider really important! That is what the other browser is for.

When you bank, upload photos, check your WebMail, trade stock, or buy anything — fire up your weekend browser. This is the browser you protect by going directly to a website, typing the address into the location bar or using a bookmark, and nowhere else. Close it down when you are done.

Then if anything, or anyone, attacks your commuter browser when you are exploring the Web, it is no problem because you’ve never done anything important with it. You don’t take your weekend car down to a bad part of town right?

 

5) Be careful of what you download and paranoid of what you install

After going through all the trouble of making sure you have the latest software, and compartmentalized your risk with two browsers, don’t go and install something evil that will ruin everything. Downloads are like narcotics peddled by drug dealer. Just say no! They might make you feel good temporarily, but long term the effects are deadly.

The bad guys are extremely clever too. They actually disguise their “product” as antivirus software to help protect your computer. HAH! The also might say you need to install a special codec or something to watch the latest celebrity sex tape. Don’t fall for that. Go to YouTube, Break, or some other major video sharing site instead. Email attachments also need to be treated with paranoia, especially from people you know, because they might not have been as cautious as you.

 

6) Make your passwords hard to guess

You wouldn’t have the same key for your home, car, office, safe, etc. For the same reason you shouldn’t use the same password for all your online accounts. Pick passwords that are hard to guess, not found in the dictionary, six characters or more in length, and sprinkle in a number or special character for good measure. Something like: y77Vj6t or JX0r21b

Anything more than having two or three passwords like this gets to hard to remember, so you have a choice to make.

a) Write down your password on a piece of paper

Use a small sheet of paper that fits in your wallet or maybe index cards locked in a desk drawer. It is much easier and safer for people to protect physical paper than data on a computer. Keep two copies around just in case one is lost. Unfortunately storing passwords on paper is not terribly convenient, so you might consider a password manager instead…

b) Use a password manager

Password managers, like LassPass or 1Password, are software that stores your passwords in a safe place on and encrypts the data. Not as secure as writing them down, but that’s the trade-off you make. The password managers that are built into the Web browsers are not terribly safe or secure, at least not nearly as much as their desktop cousins.

 

7) BACKUP! Your computer, blog, email, photos — everything

Sh*t happens. Technology is imperfect, we all make mistakes, computers crash, and bad guys sometimes get lucky.  Hope for the best, but prepare for the worst. Keep copies of your photos, email, blog posts and other treasured digital possessions on a CD/DVD, thumb drive, or even local hard drive. Disk space is way cheap these days so there is no reason not to make the investment.

If you are an Apple fan like me the Time Capsule (DSL Router / Backup device) and MobileMe are excellent choices. There are also several other solid and inexpensive online backup providers including Mozy, Backblaze, and Dropbox. One cannot stress the importance of backups. Should disaster strike, you be really glad that you took the time.

 

Summary

That’s it! You have your survival kit of everything you need to keep your information safe. The cyber criminals out there on the Internet mean business. They are in it for the money, your money. They pride themselves on being well informed and ahead of the curve, which is exactly what is needed to NOT become a victim to online fraud and other nastiness. Being just a little bit safer and secure than the rest of the masses doing little to nothing to protect themselves makes all the difference.