recently, a report went out stating that Public Key Infrastructure (PKI) is vulnerable to trust subversion. I'll spare the gory details, as they are all in the original report - but basically MD5 collisions are used to make a certificate appear as though it is signed by a trusted Certificate Authority (CA). This is a major flaw, but don't be discouraged. After all, the internet ended a while ago, remember...

Why is this Rogue CA attack important to know about?

Well, from the research that was done and the proof of concept that was demonstrated, an attacker can create a certificate for any domain. This certificate will appear to be signed by a trusted CA. Thus, you will see that the site's cert is trusted and you will never get any notification to the contrary.

Normally, a trusted CA will issue and sign a certificate and then if the browser trusts the signing CA, you will see a padlock in the GUI and you will often times see a message that lets you know that the certificate of the web site is trusted. If the CA is not trusted, you are shown a message that the certificate is not signed by a trusted party and you are given the option to leave or continue. This is PKI in a nutshell. The entire system relies on trust of the CAs and the CAs in turn provide reputable and responsible operation. This works very well, until you can subvert that trust.

What is trust subversion?
(no it's not a book about a doctor)

Any time a security measure is based on trust, an attacker has the ability to subvert that trust and use it to his advantage.

What I call "trust subversion" is any act that takes advantage of a relationship of trust between two parties. This encompasses specific spoofing attacks, masquerading, Man-in-the-middle (mitm) and other attacks. By appearing as a trusted party, an attacker can gain important leverage over a situation and can often gain confidential information (phishing/sniffing) or even infect a target computer with malware.

Real World Attack Vectors

DNS Cache Poisoning
You may be aware of the DNS cache poisoning attack that was all the rage in 2008. Well, if a user can use this type of attack to make a DNS server redirect a request for a trusted site to a rogue site and that rogue site is also signed with a rogue CA, then there is nothing that the user will be able to see under normal operating conditions to alert him (assuming the site is a good knock-off of the original and not obviously fake). This is probably the most common attack vector that will be reported.

Phishing Emails
Of course there is the ubiquitous phishing email. If you receive an email that appears to be from a bank or anywhere for that matter, DO NOT CLICK on anything (this should be ingrained into all our heads by now). You may be forwarded to an HTTPS site and think all is well, but with this attack, you can be owned.

Of course there are endless possibilities, but any way an attacker can redirect a user to a fake trusted site with a rogue cert, there lies the ability for subversion.

What should I do to prevent this?

Recommendations are in detail in the original report under "Countermeasures."

There are a few things to be aware of. First, if you are an end user, there is nothing that you can do in your normal browsing habits that will easily detect subversion. You can, however, go out of your way to inspect each certificate for subversion (details in report).

As website owners/admins, there is more that we can do, though. If you have a certificate that is hashed with the MD5 algorithm, ask your CA if they can issue you a new one signed in another algorithm (SHA-1 or SHA-2 for instance). Also, although this is not listed in the report, you can check into Extended Validation Certificates (EV Cert) - I'm not a researcher, but it stands to reason that these types of certs may prevent this type of subversion by forcing more validation checks of the certificate. I would be interested in finding out if this is indeed the case - your CA may have tested this and would be a good resource to ask.

This post is brought to you by the letter W...

Before getting started, I would like to mention that this argument uses some generalities. I still feel that it is a good starting point to figuring out what makes a Security Practitioner different than and Network or Systems Admin.

Note that a Security Practitioner in this case is more of an adviser to an admin than someone that does implementation. Once a security solution needs to be implemented, if the same person that designed the security implements the solution, then the person changes roles at that point.

The technology field is largely a problem solving field, More so than most fields. When dealing with a problem that you have to solve you will invariably have to ask one or more questions about the problem in order to formulate a solution. Most problems have several solutions and the solution that is chosen is largely dependent on the probing questions that were asked of the problem. I believe that the difference between a Security Practitioners and Systems/Network Admins happens to be the different questions that are asked. Specifically that Security Practitioners ask Who, What, When, Where and Why [the Ws] and Systems/Network Admins ask How.

Here's a scenario to hammer home my point:
You have a small office with cubicles on one floor and a network closet on the same floor. The employees have a mix of laptops and desktops and they all run various versions of Windows. You need to deploy a new File Server.

The Systems Admin would be inclined to start with "How do I install a file server and make it available to the office?" He might then think "How do I secure the file server?" The experience of being a security specialist allows the Security Practitioner to start with "Why do you need a file server - is there anything that can be done more securely?" Then, when his boss says "Just make the file server!" he will think:

• "Who needs access to the file server?"
  
• "What will be stored on the file share?"
  
• "When will it be accessed?"
  
• "Where will the requests be coming from?"

The answers to all of these questions have a direct impact on the solution.

Now that we know this...

You're right, this isn't exactly research, nor does it seem relevant to doing your job on a day-to-day basis. It is relevant when working in a team environment, though. Delegating jobs to people that have a certain thought process - or better, teaching people that a certain thought process is how we, as a group, like to do things - is important to make a fundamentally secure environment.

To the admins that have the responsibility of making everything works, monitoring, securing and making sure the boss has coffee, thinking about the Ws first will make a more secure environment. It may bring things into focus that just don't make sense ("Why does the support staff need write access to the financial share?").

Even to the Pen Testing argument, this is valid. Everybody seems to take a side on Pen Testing. There are especially some that think that the client does not understand the reason for Pen Testing. It may help to know the thought process of the client in this case and find a way to advise for or against it as a security issue. For instance, you do a Pen Test, then you report the results. You answer the W questions. The first question that you will be asked is "How would something exploit the vulnerabilities that you just presented?" As a security practitioner, it doesn't matter. It has been proven by someone as an attack vector, therefore it must be secured.

Even in terms of a Security Researcher, you wouldn't think "How do I leverage this bug I just found?" You would say, "I have found a bug, what happens when I do this..." You would go through a series of trial and error. If you start thinking through a scenario starting with the question how, it always ends up a dead end - unless someone already answered all the Ws.

The exception that I can think of to this line of thought is when doing incident response. Someone has already answered the Ws of your network and has already proven that. You need to find out how that exploit did its thing - that way you can work through mitigating it in the future by answering the Ws of your network.

Especially the Flu...

Recently my wife and I both came down with a bit of the flu (luckily our 12-month-old son didn't). I spent one day trying to tough it out at work and while I was there I got a call about someone who had just heard about the Microsoft IE 0-day on Dec 9. I guess it had just hit Yahoo! and had made it to this gentleman (who may not have read post #2, otherwise he'd have heard about it on the 9th). Since I was sick, I was at least happy that this admin was not going to let any computer be in my shape on his watch. On that day I wanted nothing else than to eradicate all viruses.

What's in a name...
We ran into a problem, though. I knew the threat as "THE Microsoft/IE 0-day (for right now)" and he knew the threat by what Trend Micro had caught on another admin's network. We do not use Trend Micro, so I could not use that name while searching our signatures. I looked for all different forms of Microsoft/IE that I could think of, still no dice. The other major AV vendors have similarly customized names for the same threat that I couldn't easily find. The downside to Virus Total is that you have to find an example of the vulnerability as a file or hash. This can sometimes be risky. More on this in future posts :o)

The various vendors didn't even classify the threat as the same type, some had it as phishing, some as virus some as trojan, etc... This is why I keep calling it "the threat".

Enter CVE...
Common Vulnerabilities & Exposures.

The way that we were able to track the threat is by its CVE number. CVE is basically a standardized naming convention system that is in use to track various types of threats. Major vendors and mailing lists use the CVE so that you can quickly find exactly which threat you are searching for. Once a threat is established in CVE, various groups take that and run. You can use the CVE number to cross reference various databases, from AV vendors to Internet Security watchdogs.

the CVE number for the threat in question is CVE-2008-4844. This was even published in Microsoft's security bulletin.

Now we know the name, who does what with it?

A great resource for techs that are trying to compare different AV vendors or network admins that have various AV engines in deployment is Virus Total. Virus total simply spits out which of it's systems recognized the file as malicious. Of course, the one drawback to this is that you have to trust Virus Total to give you up-to-date analysis and valid results. I do for the purpose of double checking patterns, but I would never take this over deploying an actual security solution.

You can always consult the website of your vendor as well. Most vendors, if not all, post bulletins on various threats on their sites. This is more complete than the virus total results, but can be harder to track down.

Sometimes it's ok to have a honeypot-like machine for testing. Make sure that the machine is COMPLETELY segregated from the network. Try to infect it beyond your defenses. If it makes it, assess further and find a solution to the problem. Then try again until you routinely see it defeated 100%. This is a good security stance. Just make 100% certain that this test environment is in no way in danger of infecting your production network.

Pen Testing...
No, not making sure your Bic has ink.

Penetration Testing is the art of compromising someone's system(s) at their request and showing them the results in hopes that something will be done about it. There is a lot of debate about what really happens before during and especially after this test is done. Many professionals have weighed in, including Marcus Ranum (Tenable Network Security) and HD Moore (Metasploit). You can hear a great podcast about Penetration testing at Risky Business.

There are tools that a penetration tester uses to find vulnerabilities in systems (and sometimes other things, such as trash). Once a vulnerability is found, there is another step and this one is more controversial - and where the arguments lie. Once a vulnerability is found, the tester actively exploits it and provides proof that the system is "PWNED". The third step is deciding what to do with the info. If the test results get dusty, then why do this in the first place? Make sure that if you have a test done, you act to secure your systems.

I would like to weigh in.

I read an article that prompted both my last post and this post. In the article Penetration Testing: Dead in 2009 (CSO online) you will see the following:

The concept as we know it is on its death bed, waiting to die and come back as something else. That doesn't mean pen testers will suddenly be unemployed, he said. It's just that they "won't be as cool" as they've been in more recent years.

Customers are clamoring more for preventative tools than tools that simply find the weaknesses that already exist, he said. They want to prevent holes from opening in the first place.

[...]

Kevin Riggins, a senior information security analyst for a company in the Des Moines, Iowa, area, said it's hard to argue with Chess' premise that the goal should be fewer failures. But he doesn't believe that sentiment has anything to do with the need for or the use of penetration testing. Furthermore, ... production monitoring and measuring and penetration testing do not address the same issue.

Let's pick this apart a little bit.

Mentioned in the quote is Brian Chess, co-founder and chief scientist of business software assurance (BSA) vendor Fortify Software Inc. Chess' aguement appears in the first two paragraphs of the quote

I agree with Chess, but would like to revise the manner in which it is stated. Penetration testing is prudent when you have limited resources for assessment. From my official schooling as a teacher, I know that the terms testing and assessment have two very different connotations.

• Testing is a pressure situation in which a "snapshot" is taken of the state of the subject being tested (what do you know about the events of The War of 1812?).
  
• Assessment is an ongoing trend in which an assessor takes many "snapshots" into account (Do you understand the overall concepts of war in the 19th century?).
  
• Assessors are usually people that have regular dealings with that which is being assessed and provide a better insight into the person/thing being assessed. (from this, you can also tell that I find the term "Vulnerability assessment" a bit erroneous in most cases

I agree with the Mr. Riggins except for that "he doesn't believe that sentiment has anything to do with the need for or the use of penetration testing." Following the previous paragraph, I hope that more IT personnel will realize that paying an outsider to test your environment is detrimental to the overall understanding of your environment in that it makes your staff's priority to fix holes that they are handed (an excercise that fosters automated thought rather than real critical thinking) rather than continually assess the systems for possible exposures. Just make sure your task has the training and motivation to do a great job.

If assessment is done on a regular basis, I predict that FOI will decrease and systems will be more secure overall.

-Tim

Recently, a lot of attention was given to an off the cuff comment by Jack Daniel in response to a Return On Investment (ROI) conversation via Twitter - "The only viable measurement in security is failure." The reason that this comment got so much traction is that it is a new way of thinking through your security scheme.

The newest topic seems to be "Is Penetration Testing dead?" - The answer is not straightforward and may need FOI to give some much needed clarity.

First there was ROI...
Will I Make A Profit?

Return On Investment is a valuable metric to the IT industry (as well as business community) as a whole. It answers the question "If I buy this thing, will I make money in the end?"

The Idea is that if you purchase something, it should at least earn you an equal amount of money back that you spent and can probably earn you more. This should also happen in a reasonable amount of time. For example, if you need to buy a firewall, it will help to know what that firewall will be doing. You can then calculate - "If I buy a firewall for $d then in t (weeks, months or years), I will see a return on my investment and everything earned beyond t is profit" At that point, It will have paid for itself (or you can use it in reverse to say that you shouldn't buy something because the ROI is either at a loss or too slow). This makes a lot of sense when you need to make sure your boss looks good when doing the budget ;)

Then There Was TCO...
How Much Will It Cost?

Total Cost Of Ownership (TCO) came into play during the original converstation. TCO is a predictive metric that tries to take into account everything that must be spend for something to be invested upon through its life.

For instance, the firewall that my boss needs, he won't look good if I google "cheap firewall" and then tell him that the firewall will cost $100 (it's a really cheap firewall). I will need to take into account the cost of software, hardware that is not included, any monthly fees, my bonus for making him look good and ANYTHING else conceivable. This is the Total Cost of Ownership. That firewall is not making my boss look good :(

Then there was FOI...
What is lssass.exe?

Before I begin, Jack had an accessory after the fact, namely Andy, IT Guy. Andy, helped Jack by really defining FOI.

FOI is even easier to define than ROI and TCO, but harder to inject into a real life scenario. FOI is not a predictive measurement, but is a mantra that can be used to make sure you are taking due care to ensure things are working as they should.

If something is allowed to fail, then the investment was not worth it in the beginning. (What do you expect from a $100 firewall?) One of the tenets of FOI is if something does fail and funds are either spent or lost as a result, then it better not happen again.

As far a security is concerned, if I have a security device, and it fails then something is compromised, even if you haven't found it yet. We now need to find and fix what happened. This will take time, salary dollars and you may need to hire outsiders, not to mention that you may have lost some revenue by an outage or data leak already. This is where FOI kicks in.

Something has failed, my boss is angry. He says "This is bad, we are stuck in this investment thanks to you. Will it happen again?" My answer is, of course, no. It is now a much higher priority of mine to keep that firewall from failing.

This is the essense of the argument. Why was it such a low priority and allowed to fail in the first place. There are many answers that I won't get in to. Although the "it's not my fault" argument may be valid (but it won't save your job, necessarily) if the vendor failed to notify or patch an existing known vulnerability. So, vendors, watch out there.

Hope these three metrics shine some light on what to do with your IT budget and IT staff.

Tim

To start off the blog, I would like to present some resources for finding great information. If you are ever stumped, a lot of times you can find what you need to get going again.

Humor...
Find all your buddies laughing at a joke that you don't get? Laugh anyways to save face, but look up what they were laughing about, there's a lot of information to be gained by doing this.

Search...
Use your favorite search engine liberally. If you have a log entry that you can't decipher, put a portion of it into a search engine. You'll be amazed at what you find. Don't be afraid to use the search engine to broaden your horizons about a variety of subjects.

Forums...
Find a forum and start searching and posting. A lot of times you'll find that someone has already gone through your current situation. If there aren't any that have, post a new thread and ask for some help! Good people will help a lot - don't get discouraged by "flamers" and "trolls"

Get linked...
Since you are reading this blog, you know that keeping up with the times is important. Here are some great resources for keeping up with current events in the technology field.

• Your favorite magazine: Read CSO, Information Week, The Register? Just find a good daily and stick with it.
• Read the actual standards (make sure you're awake enough) http://www.faqs.org/rfcs/. This site is also a great resource for FAQs and HOW-TOs for all kinds of subjects
• Wikipedia (use with caution) - A lot of scientific/technical information on Wikipedia is accurate. Just be careful.

Get Secure...
Here are some authorities on security.
http://www.cert.org/cert/
http://csrc.nist.gov/
http://www.sans.org/

Listen in...
Podcasts are a great way to get information. Find all sorts of great audio files in various formats.
I am currently a listener of
*Security Now with Steve Gibson and Leo Laporte (TWiT network - www.grc.com/securitynow)
*Risky Business with Patrick Grey (itradio.com.au)
*PaulDotCom's podcast with Paul and Larry (www.pauldotcom.com)
(And NPR, but that's not related)

And of course, BLOGS!!

-Tim

The mission of this blog is to provide the technology community with lucid, easy-to-understand breakdowns of information security topics from the viewpoint of a security newcomer.

In my short time as an engineer for an internet security vendor, I have noticed that a lot of systems administrators are thrust into positions in which they did not prepare themselves or are confronted with issues that they did not anticipate. Technology is a broad industry, after all. I am creating this blog as a guide to information security concerns targeted at the "do-it-all" systems administrator that may not have had a chance to specialize in security. I hope that even the most seasoned security professional will gain a new outlook on these topics as well.

Please stay posted as this blog becomes full of useful content!

-Tim