Vidar’s Musings

Yesterday I got an email from Atlassian, the makers of applications such as Confluence and JIRA, that said that their own hosted customer site had been hacked and that my password was possibly compromised. Apparently, some passwords were stored in clear text in the database and that the hackers had gotten hand on these (See Atlassian’s blog post about the incident).

One thing is that the perpetrators could use this information to get details about my relationship with Atlassian, among other things my license keys for Atlassian products. Even worse is that they could try and use the passwords to get into my accounts at other sites. That would be successful if I used the very usual and very baaad practice of reusing the same (user name and) password on several sites and applications. Luckily I don’t.

Here is what Atlassian states about why this could happen:

During July 2008, we migrated our customer database into Atlassian Crowd, our identity management product, and all customer passwords were encrypted. However, the old database table was not taken offline or deleted, and it is this database table that we believe could have been exposed during the breach

Trying to act as a responsible company, Atlassian goes on to list what they have learned from the incident. Among other things, they state that

The legacy customer database, with passwords stored in plain text, was a liability. Even though it wasn’t active, it should have been deleted. There’s no logical explanation for why it wasn’t, other than as we moved off one project, and on to the next one, we dropped the ball and screwed up.

I am sorry, but I find it hard to believe that this is the entire truth. Yesterday afternoon (European time) I went to their site and on the login screen I used their “Forgot my password” functionality. Can you guess what happened? They sent me an email with my password in clear text! So, I would indeed say that this “legacy database” is indeed active…

Later on the day yesterday, I also got an email from the Apache Software Foundation that their JIRA instance also have been hacked. See their blog entry about the issue. According to the blog entry, the situation is a bit better than it is at Atlassian. They state that

If you are a user of the Apache hosted JIRA, Bugzilla, or Confluence, a hashed copy of your password has been compromised.

JIRA and Confluence both use a SHA-512 hash, but without a random salt. We believe the risk to simple passwords based on dictionary words is quite high, and most users should rotate their passwords.

At least, the password was not stored in clear text, which is of course much better than having it in clear text. However, the compromised passwords could still be useful for an attacher because they are not salted. It allows an hacker to compare hashes of other accounts with hashes of a known password which would allow a dictionary attack (as is stated).

This is not security for the crowds (pun intended).

I just came across Ken Schaefer’s blog, and I found that he has posted a series of excellent posts concerning various aspects of getting Integrated Windows Authentication / Kerberos to work on IIS:

• IIS and Kerberos. Part 1 – What is Kerberos and how does it work?
• IIS and Kerberos. Part 2 – Service Principal Names
• IIS and Kerberos. Part 3 – A simple scenario
• IIS and Kerberos. Part 4 – A simple delegation scenario
• IIS and Kerberos Part 5 – Protocol Transition, Constrained Delegation, S4U2S and S4U2P
• IIS and Kerberos Part 6 – New in IIS 7
• IIS and Kerberos Part 7 – A simple cross Forest scenario
• IIS and Kerberos Part 8 – a simple cross Forest/Domain delegation scenario
• IIS and Kerberos Part 9 – Cross Forest Delegation scenario with UPN suffix routing

Simply a great source of information!

When developing an ASP.NET solution for a customer, I run the application locally on my laptop (IIS 5.1, Win XP). For a realistic test scenario I had set up a separate host name for my local computer in my hosts file. I then enabled my application for Integrated Windows Authentication, and was a bit puzzled by why it did not work.

Internet Explorer did not automatically authenticate me when wisiting the web application. The problem turned out to be that there was no Service Principal Name registered in Active Directory that associated the hostname with my computer. Hence, the client could not request a Kerberos service ticket for my web application.

The solution was to run the setspn.exe tool (available in the Windows Server 2003 Support Tools package) to create the desired SPN entry in Active Directory. For example:

setspn -A HOST/my.fake.hostname.com MYCOMPUTER

(where MYCOMPUTER is the network computer name for my workstation). You have to be a domain administrator to run this command.

The effect of running this command is that ‘HOST/my.fake.hostname.com’ will be added to the multi value field ‘servicePrincipalName’ on my computer’s entry in Active Directory.

I was at a presentation about Windows CardSpace a couple of days ago. Beautiful technology it might be, but I cannot help questioning the adoption of CardSpace in the real world. I cannot say I have ever come across any site that supports it. Have you? (If so, please let me know). On the other hand, OpenId seems to get quite a bit of momentum being supported by some of the big Internet companies out there (Yahoo!, Google, AOL to name a few).

OK, CardSpace and OpenId do not offer exactly the same solution, and are in some respects not comparable. Biggest difference would be OpenId’s reliance of passwords as authentication mechanism (which is one of the reasons for its lack of phishing attack protection), while CardSpace solves this problem using cryptography. However, there are a lot of similarities:

• Both offer a distributed model that accepts various Identity providers (the user can choose from a number of IdPs)
• Both address the challenge with maintaining several user account/password for different Internet services

“OpenId is no good because it isn’t secure”

When asking the presenter about the adoption of CardSpace versus the adoption of OpenId, this was his response. I think that this is a gross oversimplification that serves no other purpose than spreading FUD about security.

First of all, if OpenId is good enough for Yahoo! and the like, it will probably be good enough for 80% of the Internet sites out there. I can think of a lot more sites out there that require “less security” than Yahoo! out there, than sites  that require a higher security level.

Secondly, security is not binary (secure – not secure). There are different levels of security. Saying that one solution is secure and another one isn’t, is being ignorant towards the field of security. Basically, security (as everything else) come at a cost. In the case of CardSpace, the cost is maintenance of your cards and the corresponding public/private key infrastructure. I do not know CardSpace in detail, but a main challenge here I suspect will be exactly the same as for other public/private key based solutions: how do you bring your keys with you? For instance, if you created a card in a CardSpace on your workstation at work, how do you bring them with you when you want to log in from your home computer or from an Internet café? Having them on a USB stick would probably be a choice, but even that limits the usage quite a lot. Passwords, on the other hand, you carry with you in your head (at least, that’s the idea ).

I ran my demo at OOPSLA today entitled ‘Security Testing with Selenium’. You may find the presentation slides here.

My second day at OOPSLA consisted of two security related workshops. The first one as entitled “Security Patterns and Secure Software Architecture” and was presented by Munawar Hafiz. Security patterns seems to be an interesting topic and will perhaps be an important tool for security professionals.

The second tutorial was “Software Security: Building Security in” by Gary MacGraw. Although I have read a couple of his books, I found the tutorial very interesting. Many good insights (and some funny ones) were touched upon.

Perimeter defense does not work

One of the important things is that making an insecure application secure by putting up a firewall in front of it is flawed for many reasons. Trying to shield the application from the world is kind of the opposite of what we want to do. We want to be on the net, hence we should make the applications secure accordingly. Furthermore, it will not prevent attacks from insiders.

Security people’s job is to say “no”!

I can honestly say that this has crossed my mind one or few times. Although I am often involved with security, my job is not to say no, so hence I can deduce that I am not a “security person”.

Does the choice if programming language matter for security?

According to Gary MacGraw, it certainly does. For security, keep away from C and C++. In general, you should select a language that offers type safety. (This excludes C and C++). Furthermore, a question is if a statically typed language is better for security than a dynamically typed language. In my opinion, the answer here is not clear, although the presenter would probably go for a statically typed language.

More code – more bugs

This holds true for any bugs, not only those related to security. Hence, this is a fact that all people dealing with software development should be aware of. When your codebase grows, your number of bugs grow. Simple as that. You should honestly work on reducing your codebase as much as possible.

Security is not a feature or a function

Security is more of a quality aspect rather than a feature. I think this makes very much sense, and in fact I think that is reflected in Microsoft’s notion of “trustworthy computing”.

One-pager architecture

A good starting point for doing a security review of the architecture is to start with a one-page logical overview of the application as a starting point for discussion. I guess this is not only a practice related to security.

Penetration testing has limited use

I guess this can be summarized as follows: Penetration testing cannot verify that your code is good. It can only verify that your code stinks. The thought here is that penetration testing can only discover the uttermost serious problems, and running penetration testing is alone not enough to conclude that your application is secure.

Attackers use same tools as software people do

Attackers use compilers, decompilers, static analysis tools, coverage tools the same way as software developers do. Hence, developers who are familiar with these tools should learn how attackers use them so that they can defend against it. Network people would not know a compiler if it bit them.

Time and state will be biggest problem in the future

Today, proper input handling is regarded as the biggest security problem in applications. Looking into the crystal ball, time and state will probably move up to be the most important one since we see applications getting more distributed all the time and keeping track of time and state across locations will be more important.

Norwegian tabloid Dagbladet revealed yesterday that several commercial and non-commercial sites can be exploited to perform identity theft.

In Norway, all persons get assigned a unique number (‘fødselsnummer in Norwegian), similar to the US Social Security Number. Altough law restrictions apply, several sites use this number for uniquely identifying a person.

In this particular case, a hacker created a tool that could reveal identity information by collecting information from several sites, including the following steps:

• Generate a random identifier. The format and the algorithm for creating one is publicly known.
• Use site 1 to test whether the generated identifier is in use. This is possible because site 1 uses the number as user name. The logon procedure acts differently depending on whether the user name exists.
• Use site 2 to get personal details about the person to which the generated identifier belongs. (Surname, given name, address)

This is of course possible because the sites are designed poorly and leak information (OWASP Top Ten vulnerability #6). Second mistake is that site number two use the unique number for authentication.

I just read Scott Granneman’s article on Security Analogies on SecurityFocus.com. He argues that the use of analogies is essential when explaining security to users. He makes a very good point. I think that in general, techies like myself should make more effort when explaining technical stuff to “ordinary” users. Analogy is an effective tool in that respect.

Came as a surprise to me. I came to suspect this as I was unsuccessful in connecting with ADSI EDit, while successful using LDP. I got a confirmation in this post on Microsoft Technet.

I have been unsuccessful of finding any documentation on this, while the documentation does state that “ADAM ADSI Edit does not support Secure Sockets Layer (SSL) connections”. I would be OK if it also pointed out the limitation when it comes to binds…

I came across this very good article discussing web services security: Security Concepts, Challenges, and Design Considerations for Web Services Integration. It discusses concepts and design in a very straightforward manner.