Security "Best" Practices

Do you think that just following security best practices will keep you and your users safe? Think again.

Recently, I've found 2 examples where following security best practices can actually expose you to security vulnerabilities, if you won't put your mind to it.

Example no. 1 - NoScript

Everybody who use Firefox and concerned about its own security and privacy uses NoScript. Unfortunately, for the customers of the PhishMe.com service, using NoScript will actually expose their private login credentials.

According to an eWeek article: "PhishMe, a new security SAAS offering from the Intrepidus Group, enables companies to launch mock phishing attacks against their own employees in the name of improving e-mail security...PhishMe does not collect sensitive information...JavaScript on the Web site overrides anything users actually input into fields during tests."

So, basically, using NoScript will disable JavaScript on the user's browser and will actually send over the sensitive information of the user.

Now, both of the teams here play fair in this game. Intrepidus Group follows some kind of privacy best practices by changing the HTML form to not send the user's private information over the network, and NoScript does it's own security best practice by disabling JavaScript on an unknown website.

But combined together, the PhishMe.com service will try to phish users' credentials using pages which are not in the trusted domain, NoScript will then disable the JavaScript on the fakephishing page and the phished users of the fake phishing attack will eventually expose their private credentials.

Example no. 2 - Plain Text Emails

From "forgot my password" to "Johnny Depp wants to be added to your friends list", many services today send notification emails to their users. Security best practices wave a big "no, no" on HTML emails, and suggest that you read your email messages in plain text. There are services which already do the job for you and send their messages in plain text.

Unfortunately, what most of those services forget is that on a plain text email, a text which begins with either a URL protocol handler (e.g. http://, https://, etc) or "www.", will automatically transform itself to a clickable link, on most if not all mail clients.

This becomes a big issue when the plain text message contains a user generated content. The exact problem is described in an advisory over the TwitPwn website.

Twitter sends their users a notification, each and every time a different user has started following them on twitter. This email contains the following template:

Hi, *Your full name*. *Follower's full name* (*Follower's username*) is now following your updates on Twitter. Check out *Follower's username*'s profile here: http: //twitter.com/*Follower's username* You may follow *Follower's username* as well by clicking on the "follow" button. Best, Twitter

Now, both the Follower's username and full name can be alerted by the attacker, as it is save in his own profile. The username was restricted to alphanumeric characters, and therefore cannot be used for the attack. But, the full name was only restricted by the size, around 25 characters, enough to put the attacker's malicious http://www.evil.com link. All the attacker had to do was to run a bot which automatically follow people, and just wait for the victims to click on the links in the mails that were sent by twitter.

This vulnerability was fixed by twitter, and now you cannot use the dot character in the full name.

Conclusion

This post was not intended to get people to stop following security "best" practices. On the contrary, I encourage you all to follow them. All I'm saying is that following those and other security "best" practices will not make you and your users bullet-proof safe. You will now need to be more careful and think about other vectors too...

Enterprise organizations must patch the Kaminsky DNS flaw NOW!!!

If you haven't heard about the current DNS vulnerability, here is a Reader's Digest-like summary. Security guru Dan Kaminsky found a vulnerability that could give the bad guys a relatively easy way to redirect Internet traffic. For example: You might think you are logging on to Bank of America's Web site. But instead, some hacker may have just exploited a domain name system vulnerability and is now in control of your identity.

Kaminsky deserves credit for finding this flaw and alerting the Internet community so it could fix the problem. This effort is well under way, but according to an article in yesterday's New York Times, Kaminsky believes that 41 percent of all DNS servers are still vulnerable, meaning that no one has patched these systems with new software that closes this gaping security hole.

The danger here is that most of the world will shrug its collective shoulders, dismissing this as a technology problem. The truth is that this is the Internet equivalent of a bridge collapse on Interstate 35W in Minneapolis. This disaster demonstrated that a critical piece of infrastructure was badly in need of repair. Unfortunately, the same is true of DNS, a critical but rickety technology.

Clearly the folks who control most of the Internet infrastructure get this. Comcast and Verizon have already patched their DNS servers, while AT&T is in the process of doing so. Great, but what about all of the companies with a large Internet presence? This is where the Internet may be most vulnerable, folks. According to ESG Research, 48 percent of large organizations (i.e. 1,000 employees or more) experienced at least one DNS outage in the past 12 months. What's more, 42 percent of these companies consider patching and upgrading DNS a time-consuming operational process. Given these statistics, my guess is that a lot of enterprises believe that the DNS problem doesn't really impact them, that it is really an Internet infrastructure problem. This is a misguided and dangerous perspective.

DNS anchors all Internet communications, thus it should be considered critical infrastructure. It's time that enterprise organizations realized this and started treating it accordingly. Hopefully Kaminsky's discovery will act as a change agent to fix the problem. Otherwise, we could all be in trouble.