REPOST: What's more valuable than my money?

Repost from my dead blog, 2006-09-01

When I talk to most home PC users, they’re very concerned about their own stuff, as they rightly should be. If I ask “what’s the worst thing that could happen if an attacker got your machine,” the response is generally that the attacker could get passwords, personal documents, or identity information.

I’m going to make a very unpopular statement here. That’s not the worst thing that could happen.

While yes, identity theft happens all the time, the most severe of attacks lately don’t target individual people. It takes time to write custom processors to find sensitive information in various types of files. It takes time to manually go through the information on your machine with no context and determine what’s of value.

What’s more important that your computer can provide is anonymity. If an attacker gains access to your machine, they’ve just gained access to a resource that can be used for a distributed attack against a single entity (with a multitude of people who use it). Spyware’s goal now is not to get YOUR information, but to use YOUR machine to get EVERYBODY’s information by using websites with a large number of users. A single machine attempting a brute-force attack against Paypal will take a very long time. But 20,000 machines attempting the same brute-force attack will take a much shorter time to find many more accounts.

So at a personal level, don’t think that the line stops at keeping really sensitive information off your machine. Be sure that the FBI CAN and WILL use your machine to find the real attacker if they can.

At a professional level, data classification is not the holy grail we once thought it was. A resource with no sensitive informaton is still a resource that can be used to gain access to sensitive information.

REPOST: Six Dumbest Ideas (part 2)

Repost from my dead blog, 2006-04-15

As I said in the last post, they were completely off the mark on some. And I won’t go in the order I had originally decided - I kept making references to Anna Kournikova and Phishing, so I’d better explain what that was about.

One of the “dumb” ideas is User Education. The idea is that we should make systems secure so that user’s don’t have to be responsible for managing their own security.

I do agree partially - we expect our automobiles to have security features built in (like you can’t take the key out unless the car is in park) so that we don’t shoot ourselves in the foot. Hooray for us writing secure code!

But the example they give of things that DON’T work are the Anna Kournikova virus. The Anna Kournikova virus was one of the first (and easily the most wide-spread) of the “VBS with some other extension” type of viruses. When Windows Script Host became popular (read - was installed and turned on by default on most Windows machines), attackers started sending viruses in attachments with names like “annakournikova.jpg.vbs” or even “annakournikova.jpg .vbs” where they were counting on your system not showing filename extensions (so you’d only ever see “annakournikova.jpg”).

Well, the antivirus companies were a little slow (like the author of the post said - people are more than happy to click a link of a naked almost-celebrity) to get a definition out, and IT professionals were even slower to get the definitions installed.

And this isn’t unusual. And ultimately, this virus is fixed by the same practice as stopping phishing. If users are educated not to click links (including attachments) in emails, the outbreak wouldn’t have been nearly so bad. The reason it was so bad is because nobody has EVER started a wide-spread recommendation that people never open an attachment unless they first know who it’s from and what it is. And another bit of security would have helped this - using S/MIME or (preferably) PGP - if I know that you always PGP sign your messages before you send them, and I know you take care of your private key, I can trust that if I receive a message from you that is properly signed, that any attachments you sent, you intended to make it to me.

Saying we shouldn’t educate users to protect themselves is like saying we should make cars have foam bumpers so that our kids don’t have to look both ways before crossing the street. It’s like saying we should make knives that aren’t sharp so that we can’t cut ourselves. It’s like saying we should make cigarettes that don’t cause cancer instead of telling people that smoking causes cancer - the whole benefit of the thing we’re trying to make safe is also the inherent danger.

I’m not making my argument very clear, but their premise is that we shouldn’t allow attachments in the first place, thereby removing the problem of viruses. I agree to a point, but they contradict themselves because viruses are only part of the problem - phishing doesn’t have to do with attachments, it has to do with the fact that we don’t train users to never trust an email at all. Phishing is becoming more and more sophisticated - a little breach of security can allow a malicious user to enumerate email addresses of real customers, and then the phishing becomes targetted.

The same sort of rules apply to instant messaging, and the oh-so-Web-2.0 practice of reading blogs (have you followed a link off of any of my posts yet?)

REPOST: Six Dumbest Security Ideas (part 1)

From my dead blog, 2006-04-15

I thought I was going to make one really long post, but I change my mind.

To preface, there’s an article (http://www.ranum.com/security/computer_security/editorials/dumb/) entitled “The Six Dumbest Ideas in Computer Security”. And like the OWASP Top 10, I think they’re spot on with a couple of them. But they’re completely off the mark on a few. I’ll start this post with where’re they’ve gone right.

Default Permit:

Of course this is a dumb security practice. It’s completely against the Principle of Least Privilege.

Enumerating Badness:

This is where security practitioners seem to fall into two camps. The first camp is like plugging holes in a dam - when we find a problem, fix it - this has been the basic approach to security for years, and it simply doesn’t work (see a later post on Anna Kournikova and phishing). The second camp is to make secure systems where regardless of the type of hole that might come up, the system is able to deal with it anyhow.

An example of the second camp would be to create system policies that allow only certain types of attachments into the email system - PDF and picture type files would be good examples - the aim is to reduce the “surface area” of attachment viruses. The traditional approach to the problem of attachment viruses is to install antivirus on the mail server and/or client to remove viruses that we KNOW about. There have been a huge number of failures when a definition doesn’t exist for a new type of virus (see Anna Kournikova).

Another example of this is training developers to write secure systems from the ground up, rather than finding flaws in the system once it goes to production. It’s offensively expensive to fix a problem (regardless of type) once the code is in production - and much less expensive to code the thing properly from the beginning. Ultimately, the money saved by writing secure applications and securing code during development will offset the cost of the training involved to get developers to understand how to write it secure from the beginning.

More on the article later.

REPOST: Delete your root certs!

Repost from my dead blog. 2006-02-27

I promise, this will be a long one. But I’m venting on something I’ve known to be an issue for awhile.

First, look at Schneier’s blog on the phishing attack.

For a couple of years, I’ve been telling folks to delete their root certs from their browser. And this phishing attack is precisely why.

For the non-technical, when you visit an SSL site, part of the process involves your browser determining that the site belong to whom it is purported to belong to. In fact, channel encryption is a by-product of this verification process. During this exchange, the server sends your browser its certificate, which may or may not be digitally signed by a Certificate Authority (CA). A CA’s responsibility when signing a certificate is to verify the identity of the entity requesting the signature on the certificate. So if you’re getting a certificate for myreallycoolcompany.com, they have to do some work to verify that you’re actually the proper owner of myreallycoolcompany.com.

Notice what I DIDN’T say they do. I DIDN’T say that they check to make sure the site is not a knock-off of a legitimate site (nor should they), nor do they ask if you intend to use the certificate for fraudulent purposes (nor should they), nor do they verify any kind of association between the name of the website (myreallycoolcompany.com) and the name of the company requesting the certificate (My Parent Company, Inc.), nor should they. They DO check the registration information for the site in the registrar with information you send to the CA. Usually, this whole process involves sending a certificate signing request (CSR), and out-of-band sending the CA a piece of letterhead - this PROVES beyond any doubt whatsoever that you indeed own the company (tongue in cheek) - and a substantial wad of cash.

Now, when your browser visits myreallycoolcompany.com and goes to the SSL portion, the site sends their certificate, and your browser checks the signature chain to see if a CA that the browser trusts has signed the cert. Once the signature is found, your browser assumes that you the user indeed trusts the site. So you get the cool little padlock that tells you the connection is secure and that you can trust this company with all your personal and financial information.

But again, the CA only checks identity. Somebody (Botswana Holding Company) in Botswana could easily register thestranahtans.com (misspelling deliberate). Then they send their letterhead (for Botswana Holding Company) and the CSR to a CA. They get their cert, and almost every browser on earth will transparently trust anything that comes from the site. So then, they send out their phishing attack, make it look just like thestranathans.com, and everybody who is savvy enough to LOOK for the SSL icon and knows vaugely what a CA is implicitly trusts the site as thestranathans.com because the URL looks right (it’s as easy to mis-read misspellings as it is to type them that way) and some CA says that the site is “safe”.

In addition to my three rules for using the internet, on occasion when using a new machine, I’ll delete all the CA certificates from my browser. There are cases where this simply doesn’t work - some tools (like Windows EFS if you have it or use it) have to have certain root certs installed. But in Firefox, I’ll delete all my root certificates. Then I’ll manually visit the SSL sites I visit most - my ISP, mail provider, bank, credit card holder, etc. The first time, the browser will complain because you don’t trust the site because the CA that signed the cert can’t be found. So you carefully review the URL you typed in and the information in the certificate. But it protects you in two ways:

1) If you mistype a URL or (heaven forbid!) click a bad link in a phishing email and you go to a site that looks like the legitimate one, your browser will complain because you don’t trust the certificate. So you get a visual red flag not to interact with the site, or at least to see 2)

2) YOU become in control of trusting the sites you want to trust. Without deleting your root certificates, you’re implicitly trusing any website the CA says you should trust - which happens to be exactly the subset of websites with owners who have the $400 to spend per year on a certificate. Hackers usually have a lot more than $400 when they stand to gain more than that in return.

And just to continue the rant, Verisign intends to add another tier to their signing offering. If you pay them twice as much, they will do twice the work to verify your identity. But they still do absolutely zero (as they should) to verify your INTENT. And what they hope will happen is what Microsoft intends to do wth Vista - you don’t get a yellow address bar unless the site is REALLY secure (meaning that whoever bought the cert was REALLY rich, meaning they’re prolly twice as malicious).

See, all this time, you thought SSL meant “safe”. That somehow SSL wasn’t allowed to the bad guys. Or that you couldn’t sign code if you were a bad guy.

Just trying to protect the browsing public.