As a security consultant with exposure to many large enterprises I admit I’m biased to RSA SecurID tokens. During penetration tests, our company has cracked tens of thousands of passwords. When I’m standing in front of a customer explaining why their password policies failed, they want to believe that changing this policy will help them. Secretly I know that humans will defeat the spirit of any password policy and that the best approach is to take the responsibility of password composition away from the end user. (When you stare at thousands of clear text passwords you develop a cynicism.)

August2007, you’ve been a good password, but it’s time I move on to owning enterprises with September2007.

The other day a friend asked me if there are any other products like SecurID he should be evaluating for his company as part of their plan to introduce two-factor authentication. Apart from SecurID the only other device that left me thinking “Hey this thing works” is Vasco’s Digipass. Any two factor system worth its weight in salt should provide authentication hooks to the popular services. If you plan to use the solution with custom web applications, you may need to dig a little deeper…maybe a lot deeper. Most solutions have hook-in APIs, but it takes some effort to piece it all together.

If you are evaluating two factor authentication devices make a list of the top services you need authentication for:

• Network devices
• Windows authentication
• Unix authentication
• VPN users
• Wireless user authentication

If a solution can cover 80% of your authentication needs and is cost effective, go with it. 80% coverage is 80% better than letting humans pick passwords; chances are with a little effort and creativity you can put something together to rein in the residual 20%. If you don’t have a two-factor solution, evaluate Vasco with the others.

-higB

Security conscious developers, world over, look to the OWASP Top Ten as their do’s and dont’s guide. The importance of this list, to the application development and security communities, cannot be exaggerated. Have a look at these impressive statistics from one of Jeff Williams’ recent presentations:

Thus, a Top Ten vulnerability should be one that occurs most commonly and has a high potential impact; something that developers should be made aware of. Based on this premise, session fixation should bull doze into the OWASP Top Ten.  Over 90% of all Java web applications that we have reviewed in the last couple of years have been susceptible to this attack. Combined with a little phishing, this attack can result in users’ accounts on vulnerable websites being hijacked. Let’s take a little detour and understand how this attack most often works.

• The attacker requests the home page of the vulnerable website
• In response the attacker’s browser is provided a jsessionid. Note: No authentication has occurred
• The attacker extracts the jsessionid from the response and constructs a legitimate URL with the jsessionid in it as follows:

https://www.vulnerablesite.com/login.jsp;jsessionid=<insert the extracted token here>

• The attacker then emails this link to a potential victim – a legitimate user of the website
• The victim does not find anything “phishy” with the URL. It actually points to the SSL website; no phony subdomains, suspicious IP addresses, illegible URL encoding, etc.
• The user clicks the link and is presented the login page. What the user doesn’t know is that his or her session is associated to the jsessionid in the clicked URL.
• The jsessionid continues to be associated with the user’s session post-login too.
• Now, the attacker can browse to any restricted page of the website by merely appending the jsessionid in question to the request. The application believes that the attacker is the victim and will readily provide the former access to the victim’s profile- think bank account.

Due to the default behavior of most Java application servers, web applications using the jsessionid for authorization, are often rendered vulnerable. Don’t get me wrong – I am not recommending against the use of jsessionid as an authorization token. I am only calling for the issue to be brought to the fore front by the foremost application security community – OWASP. Especially because it has an easy fix; developers should invalidate the session after critical events like login and re-issue a session ID.

session.invalidate();
session=request.getSession(true);

Also, disable URL re-writing in web.xml.

Some may argue that session management is  included in “A7 – Broken Authentication and Session Management” of the OWASP Top Ten. Yes, it is. However, just like cross site scripting and injection flaws got their own spots and were not clubbed under input validation, session fixation too demands the spotlight.    

-Rohyt 

The Defcon 15 schedule has been posted and I’m glad to have the 7pm time slot on Friday. I’ve presented about automatic outbound covert channels using untraditional hardware in the past but this year my DefCon presentation is for the gear heads.

Short summary: This presentation is about a modern cars ECU and how reflashing it can net you more power. It’s a super ambitious topic to cover in 75 minutes. There are tomes of information about performance tuning theory so it won’t be possible to make everyone an expert in the matter. What I can do is show the tools of the trade, explain some of the basics of tuning and data acquisition, and highlight some of the opensource projects dedicated to the subject. http://www.enginuity.org/ http://www.openecu.org

I’d like to give special thanks to Intrepidus Group for letting me present on the topic and for graciously donating some cool giveaways that will be handed out during the presentation.

-higB

This morning the story that caught my eye was a Slashdot link about CallerID Spoofing to be Made Illegal.

`(1) IN GENERAL- It shall be unlawful for any person within the United States, in connection with any telecommunications service or IP-enabled voice service, to cause any caller identification service to transmit misleading or inaccurate caller identification information, unless such transmission is exempted pursuant to paragraph (3)(B).’

You can read the full text about it here: http://thomas.loc.gov/cgi-bin/bdquery/z?d110:s.00704:

During the last couple years I’ve made use of the Telespoof.com’s caller ID spoofing service during telephonic social engineering engagements. Spoofing caller ID is something a motivated attacker will do to look more legitimate. I’ve also seen an occasion where spoofing the caller ID could fool certain PBX systems into direct access into voice mail boxes.

Do I wish it was technologically impossible to spoof caller ID? You bet I do, it would make avoiding political fund raiser calls much easier. I know better, the bad guys will still spoof caller ID knowing that it will be virtually impossible to get caught. This means my customers who want authentic social engineering phone calls won’t get the total package and won’t know their true risk.

The downside to this law is only the bad guys will be spoofing caller ID. This will also put companies like telespoof.com out of business.
The upside is that it looks like Skype will be legally obliged to transmit caller ID. This is good news for people who have purchased Skype-IN phone numbers and whish it would transmit something other than +000000

More about Skype and caller ID here: http://share.skype.com/sites/en/2007/05/caller_identification_for_skyp.html

-higB

Windows password complexity can often be misleading. A “complex” password may be hard to guess without reaching the account lockout threshold, but not necessarily hard to crack. On a recent engagement, I found that the password complexity policy and account lockout policies were set as recommended. The passwords had to be 8 characters long (at a minimum), alphanumeric and have at least one special character. With an account lockout threshold of 3, that’s a hard to guess password.

Now, crackability is a different issue. I ran into a 12 character long domain administrator password – alphabets, numbers, special characters, et al. How hard do you think that was to crack? It took the better part of 5 minutes. Let me caveat the following discussion by saying that the Windows domain in question did support LM hashes, making the job considerably easier.

I ran the password through ophcrack, using the built-in alphanumeric Rainbow Table. 20 seconds later, I had the first 7 characters of the password staring me in the face.

LM hashes can be cracked as two separate 7 character chunks. The first 7 characters in this case had no special characters – 1 numeral and 6 characters, and so the rainbow table got ‘em.

Next, I took this 7 character password segment and fed it into the dictionary file for John the Ripper and let it rip. On returning from a short bathroom break I found that the other 5 characters had cracked even though they had 2 special characters in them.

I know the weakness created by supporting LanMan hashes isn’t news to security pros, but to date I still see it supported in nearly every organization I assess.

The point I’m trying to drive home is a 12 character “complex” password may be hard to guess, but not necessarily hard to crack depending on its composition and hashing algorithm. Since LM hashed passwords behave like 2 separate passwords, when setting Windows passwords make each 7 character chunk complex with special characters, numbers and alphabets. Or even better don’t support LM hashes; set the HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LMCompatibilityLevel registry key to a value greater than 1. The counter argument to the second countermeasure is “But I have Windows 9x machines to support (that need LM)”. If that is the case DSClient.exe, from Microsoft can alleviate that problem. Better still get rid of those antiquated machines.

A fantastic book about passwords by Mark Burnett: Perfect Passwords

A great book on Windows security by Roger Grimes: Professional Windows Desktop and Server Hardening (Programmer to Programmer) (Don’t let the title fool you, this is a book for administrators, not programmers.)

–Rohyt