Internet Safety for Parents

A friend asked me about Internet safety including how parents can protect children from the nasty stuff that's out there. I replied by describing what I do at home. It's probably not the perfect system, but it seems to work for me.

If you know nothing about Internet safety, start by visiting the resources listed here. Educate yourself about Internet dangers and the kinds of protection available.

In terms of filtering, I recommend using the Windows Vista built-in parental controls. You can select age-appropriate access level, define time restrictions, view logs of sites visited, etc. Each user must have their own login on Vista (no sharing accounts!). If you're not using Vista, please think seriously about upgrading. The parental controls feature alone is worth the money. However, at this point in time you should probably upgrade to Windows 7 since its release date is near. I assume it has the same or even better parental controls.

Defense in depth applies in protecting children too. So for better protection, I also recommend using BlueCoat's K9 Web Protection (available for free). It is not as flexible (all users have the same filter level), but it catches some stuff that Vista doesn't. If you are currently stuck on Windows XP, use K9 at least. Just remember it is not perfect.

Finally, if you don't want a hacker opening a reverse shell and taking over your computer, make sure you check for software updates at least weekly! Or, have it done automatically if possible. These updates should include not just Windows and Anti-Virus software, but also Internet Explorer, Adobe Reader, Flash Player, Firefox, Thunderbird, Java, iTunes, etc.

Session Fixation Example

I usually see session fixation vulnerabilities with Java web applications. Just recently I found a ColdFusion application vulnerable to session fixation. This nasty security hole greatly increases the risk that users will have their sessions hijacked. Once an attacker has hijacked a session, he can view any data or perform any action that the legitimate user can. 

Both HP WebInspect and Burp Pro's active scanner failed to find this vulnerability. Testing for session fixation is quite easy to do, so I ran a quick test for it manually.

When testing for session fixation, I normally use two different browsers: IE and Firefox in this example. If the login page for an application is https://someapp.com/login, testing for session fixation consists of the following steps:

1. Launch Firefox and navigate directly to the login page.

2. Inspect the cookie(s) assigned by the application. For a Java web app, a JSESSIONID cookie will normally be set. In the case of ColdFusion, you normally see CFID and CFTOKEN cookies.

3. Copy the session ID from the cookie.

4. Construct a special URL that contains the session ID.
For Java, it looks like this:
https://someapp.com/login.jsp;jsessionid=[sessid]
For ColdFusion, it looks like this:
https://someapp.com/login.cfm?cfid=[cfid]&cftoken=[cftoken]

5. Open IE and configure it to run through a proxy (Burp, Paros, Fiddler2, etc.).

6. Paste the special URL into the IE address bar and hit Enter (this step simulates a victim clicking on a link in an email or Internet post).

7. Observe the HTTP response from the server. Is there a "Set-Cookie" header? If so, what is the session ID? You have a problem if it's the same value that's in the URL. On the other hand, you're probably okay if the value is different.

The ColdFusion site I tested was handling the situation even more poorly than usual. It was not necessary to visit the site initially to obtain legitimate session IDs from the server, so steps 1-3 above weren't even needed. An attacker could make up *any* 6 digit value for "cfid" and *any* 8 digit value for "cftoken", then embed these made-up values in the malicious URL, and the application happily accepted them.

The server responded by assigning CFID and CFTOKEN cookies based on the made-up values as illustrated below.

The URL of the request was:
https://someapp.com/login.cfm?cfid=999555&cftoken=29292929

And the HTTP response contained the following headers:
Set-Cookie: CFID=999555; path=/; Secure
Set-Cookie: CFTOKEN=29292929; path=/; Secure

Who Has the Answers to Your Security Questions?

I'm back after a summer that was crazy busy for me. Recently, I had two eye-opening occurrences where other people viewed the answers to my personal security questions - you know, those questions that web sites ask in case you forget your password. These incidents weren't security breaches, just normal business processes that appear to be more prevalent than I thought.

In the first incident, I got a new cell phone for my daughter at a retail store of one of the major providers. I gave the clerk my cell number so he could look up my account and he then asked for my "PIN". I didn't know it. I knew my password for their site, but that's not what he wanted (I wouldn't have told him anyway). Since I didn't know my PIN, the clerk followed up by asking me "What's the model of your first car?". Whoa. I proceeded to answer the question. He looked at his monitor and said "okay, good".

The other incident involved Vanguard again. I got locked out of their site (not just unrecognized like last time). The darn thing wouldn't even allow me to answer my security questions. Forced to call Vanguard customer service, I explained to the CSR that I was completely locked out. Wouldn't you know the CSR simply asked me to answer two of my security questions? I provided the correct answers, and he immediately unlocked my account allowing me to log in again.

Moral to the story: These answers are not simply being used programmatically or being treated as confidential data. Realize that the answers to your personal security questions could be viewed by other people in many cases.

Vanguard.com Doesn't "Recognize" Me

I upgraded the hard drive on my home computer. The first time I tried to log into my Vanguard account online, it asked me to answer a security question. No problem I thought to myself. The site just doesn't recognize me since I have a new drive. It wants extra information to be sure I'm me. This is part of PassMark "sitekey" functionality. I typed in the answer to the question and was promptly told "sorry, invalid answer". Weird. I tried again. same result. I was 95% sure I was entering the correct answer, but each time I tried, it didn't work. Eventually I got an email telling me I disabled my ability to log in from an unrecognized computer due to repeated wrong answers. Nice. The web site didn't inform me of this - only the email. The email also stated I could now only log in if I used a recognized computer. To log in from an unrecognized computer, I would have to reset my security questions or call Vanguard customer service. Great.

Luckily, I had logged into Vanguard from my work computer, meaning it was "recognized" and I wasn't asked a security question. Using my work computer, I logged in and reset my security questions and answers as required. Now back to my home computer. I was quite confident facing a security question this time. But again, failure! Why does it not accept my answer? I was 100% sure it was correct this time. I just reset them for cryin' out loud.

At this point I concluded that it was a bug in Vanguard's site. Do I call their customer support? Ugh. Instead I took the approach of trying to get the site to "recognize" my home computer. Long story short, I copied a single file from my work computer to my home computer and solved the problem. I knew the PassMark/sitekey solution uses a Flash local shared object to determine whether a computer is recognized. It does not use a persistent cookie as you might first guess. Anyway, I found the shared object file "PassMark.sol" in the following directory on my work computer:

C:\Documents and Settings\[user]\Application Data\Macromedia\Flash Player\#SharedObjects\xxxxxxxx\vanguard.com\passmark\flash\pmfso.swf

where "xxxxxxxx" changes for different users. I copied PassMark.sol over to the corresponding directory on my home computer and it worked like a charm! Vanguard's site suddenly recognized my home computer and I got logged in.

This episode was very frustrating and got me wondering how normal users feel. After all, I was only able to solve the problem with:

• Luck - I had another computer that was recognized
• Esoteric knowledge - Vanguard's site uses Flash shared objects to recognize a computer

The vast majority of users are not web application security experts. They must be going crazy, and on the phone with support a lot.

Patent Abuse?

This is not strictly an application security post, but I just read an amazing article about a security/tech company here in Dallas. I had never heard of DeepNines, Inc. even though I live in DFW and work in the information security field. Based on the article, my first impression of DeepNines is not good. Apparently they won an $18 million settlement against McAfee because McAfee violated their patent. Their patent is "for detecting attacks on a site in a communications network and for taking actions to reduce and/or redirect such attacks". Not satisfied with their windfall, they are suing again, this time Secure Computing, which was just acquired by... McAfee. Now McAfee has to deal with them all over again!

This looks like an egregious case of patent trolling to me. How could a patent be granted for such a thing? Patents are supposed to be "nonobvious to a person having ordinary skill in the area of technology related to the invention" (ref). It's highly questionable that's true here. It's like patenting a steering wheel as "the process of taking an action to cause the rotation about a vertical axis the front-most wheels of a vehicle causing said vehicle to turn in a rightward or leftward direction."

One of my previous employers is dealing with something very similar. It's too bad there are companies that don't like to compete on the merits of their technology or customer service. They find it easier to acquire questionable patents and then sue the pants off anyone they see as a threat. For some companies, patent trolling actually seems to be the true business model.

Simultaneous Sessions for a Single User

It's a common request or recommendation that a web application not allow a user to have more than one session active at a time. In other words, after a user logs into an application, he should not be permitted to open a different type of browser (or use another computer) to log in again until his first session has ended. I've recommended this myself, but it's always been kind of muddy as to why this should be done. It is not trivial to implement this feature in the code. Recently, one of our clients wanted to better understand the reasons behind this recommendation. I was given the task of explaining.

The bottom line is that I could not find one strong, clear-cut reason for disallowing simultaneous sessions for a single user. There are a number of scenarios where it might help. Listed below are the reasons I came up with for implementing this feature. Please let me know if you have other ideas on this subject.

• An application has a licensing scheme that allows only a limited number of concurrent users or requires users to pay for access or premium content. A technical control to prevent simultaneous sessions for a single user ID would limit the financial harm caused by users sharing login credentials.
• It is out of the ordinary for a user to be logged in from more than one location (or more than one type of browser) for a given point in time. Anything out of the ordinary should be assumed to be a potential security risk.
• An attacker somehow steals a user's credentials (perhaps by sniffing unencrypted HTTP traffic) while the user was authenticating to the application. The attacker immediately tries to log in with the stolen credentials. The application sees that the user is already logged in and returns an error to the attacker, thus temporarily protecting the account.
• An attacker shoulder surfs to obtain a valid username (but not the password). He then immediately proceeds to run a password guessing or dictionary attack hoping to determine the password. If his attack happens to be successful during the time the legitimate user is logged in, it would prevent the attacker from gaining access.
• An attacker and a victim log in such that their sessions overlap. The application displays an error message that alerts the victim that someone else is using his account. The victim may contact the site owner, spurring an investigation, which might uncover a compromised account.
• It could help ensure data integrity and non-repudiation. A user may have multiple authenticated sessions at the same time, and one of the sessions might be used to make a critical change. If a user claims he never made such a change, it could be a problem for the logs to show that two authenticated sessions existed and the user claims he was logged in only once.
• It could help defend against a malicious user who wishes to overload the server memory by creating an excessive number of authenticated sessions. Authenticated sessions typically use much more memory on the server than unauthenticated sessions. With valid credentials and no limit to simultaneous sessions, a user could potentially create a denial-of-service condition.

After my research, I came to the conclusion that disallowing simultaneous sessions often does not increase an application's security posture enough to justify the required development and implementation cost. Obviously there are some special situations, like the licensing issue, where it could make sense.

This feature may actually introduce new problems. Let's say a user logs into an application and his machine crashes or the power goes out. A few minutes later, when trying to log in again, the user is denied access and told he's already logged in. Of course, it's true from the server's perspective (his session is still active), but now there's an angry user shouting profanities at his computer. Unless the user knows his previous session ID (fat chance), there's nothing for him to do but wait until the session expires due to inactivity or call your customer service department and complain.

The Importance of Case-Sensitive Passwords

It is rare that I encounter a web application that doesn't support case-sensitive user passwords. But it still happens. In my experience this often occurs not because the application developers weren't cognizant of security, but because the authentication is actually processed by an old, backend system that doesn't support case-sensitive passwords. Let's review why implementation of case sensitive passwords is so important.

At first you might think that having case-sensitive passwords would double the number of possible passwords. Of course, that is not how it works. Let's say a user decides he wants a password of "orange7". Without case sensitivity, the number of possible passwords for this user is exactly one. But with a case-sensitive password, the user can choose from sixty-four possible passwords:

orange7 Orange7 oRange7 orAnge7 oraNge7 oranGe7
orangE7 ORange7 OrAnge7 OraNge7 OranGe7 OrangE7
oRAnge7 oRaNge7 oRanGe7 oRangE7 orANge7 orAnGe7
orAngE7 oraNGe7 oraNgE7 oranGE7 ORAnge7 OrANge7
OraNGe7 OranGE7 OrAnGe7 OrAngE7 OraNgE7 ORaNge7
ORanGe7 ORangE7 oRANge7 oRaNGe7 oRanGE7 oRAnGe7
oRAngE7 orANGe7 orAnGE7 orANgE7 oraNGE7 oRaNgE7
orANGE7 oRaNGE7 oRAnGE7 oRANgE7 oRANGe7 OraNGE7
OrAnGE7 OrANgE7 OrANGe7 ORanGE7 ORaNgE7 ORaNGe7
ORAngE7 ORAnGe7 ORANge7 oRANGE7 OrANGE7 ORaNGE7
ORAnGE7 ORANgE7 ORANGe7 ORANGE7

So, having case-sensitive passwords vastly increases the universe of possible passwords and sets the bar significantly higher for hackers running brute force or dictionary attacks on a web application. For example, 64 passwords must be checked versus only one in the scenario presented here.

As an end-user, be sure to take advantage of case sensitivity to strengthen the security of your account. Use a mixture of upper and lower case letters, plus numbers. It may prevent a lazy or time-crunched attacker -- who checks lower case passwords only -- from compromising your account.

IE Developer Toolbar Follow-Up

In an earlier post, I had commented on the fact that the IE Developer Toolbar has a problem in that it doesn't report cookies that are marked with the "HttpOnly" attribute. Well, as they said in the movie Independence Day, that's not entirely accurate (clip). There is an exception. The exception is when the cookie is a persistent cookie. The tool apparently doesn't utilize JavaScript in that case, and correctly reports the existence of the cookie. It's not actually a situation that would occur very often. Applications normally only need to mark *sensitive* cookies with HttpOnly, and sensitive cookies should not be persistent in the first place.