Tuesday, December 30, 2008

Creating a rogue CA certificate

by Alexander Sotirov

We have identified a vulnerability in the Internet Public Key Infrastructure (PKI) used to issue digital certificates for secure websites. As a proof of concept we executed a practical attack scenario and successfully created a rogue Certification Authority (CA) certificate trusted by all common web browsers. This certificate allows us to impersonate any website on the Internet, including banking and e-commerce sites secured using the HTTPS protocol.

Our attack takes advantage of a weakness in the MD5 cryptographic hash function that allows the construction of different messages with the same MD5 hash. This is known as an MD5 "collision". Previous work on MD5 collisions between 2004 and 2007 showed that the use of this hash function in digital signatures can lead to theoretical attack scenarios. Our current work proves that at least one attack scenario can be exploited in practice, thus exposing the security infrastructure of the web to realistic threats.

This successful proof of concept shows that the certificate validation performed by browsers can be subverted and malicious attackers might be able to monitor or tamper with data sent to secure websites. Banking and e-commerce sites are particularly at risk because of the high value of the information secured with HTTPS on those sites. With a rogue CA certificate, attackers would be able to execute practically undetectable phishing attacks against such sites.

The infrastructure of Certification Authorities is meant to prevent exactly this type of attack. Our work shows that known weaknesses in the MD5 hash function can be exploited in realistic attack, due to the fact that even after years of warnings about the lack of security of MD5, some root CAs are still using this broken hash function.

Co-authored by Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de Weger

Further details:

Colliding certificates:

This work was presented at the 25th Chaos Communication Congress in Berlin on December 30, 2008.

For press or general inquiries, please contact the team at md5-collisions@phreedom.org

Friday, September 26, 2008

The Definition Of Security

There is much debate about how to define security - as in digital or IT security.

All too often IT security is spoken of as a "cost to the business". On a broader level I believe IT security is a responsibility management has it its stakeholders. That's not a definition of IT security, simply what it is.

Keeping with the concept of what IT security is - well it is not a cost to the business; rather, it is an investment by the business. It only becomes a cost to the business AFTER an exploit has taken place and digital information has been compromised or stolen.

Another fallacy I hear in my travels is that an investment in IT security is nothing more than an insurance policy; i.e. insurance that the digital information will remain safe if the proper investment is made to protect it.

A businesses' investment in IT security is not an insurance policy. An insurance policy pays the insured to compensate for a covered loss. Certainly, there are various types of business insurance a company can buy for data loss, but that is missing the point, because we're talking about IT security, not insurance.

So what then is the definition of IT security?

By Daniel Miessler on September 3rd, 2008

The process of maintaining an acceptable level of perceived risk.

There are a few things to like about this definition.

  • Process. i.e. it doesn't end.
  • Acceptable. This alludes to the fact that the organization's upper management decides-based on the entity's goals as a whole-how much risk to take on. The crucial piece here is that this isn't for security professionals to decide.
  • Perceived. In short, "you don't know what you don't know". And this is where security professionals come in. Their entire job is to ensure that management is making informed decisions.
  • Risk. As we all know, it's not a good idea to use words with disputed definitions as part of another definition. And since risk is one such word, I'll clarify briefly how I define risk. In general, I prefer NIST's description from NIST Publication SP 800-30:
Risk is a function of the likelihood of a given threat-source's exercising a particular potential vulnerability, and the resulting impact of that adverse event on the organization. To determine the likelihood of a future adverse event, threats to an IT system must be analyzed in conjunction with the potential vulnerabilities and the controls in place for the IT system.

This reveals a few primary components: likelihood, threat-source, vulnerability, and impact. The word "function" used in the definition is pivotal; it reveals that if any of the values increase or decrease, the total risk does as well. I also prefer to add asset
value to the equation, and this is a popular choice.

Ultimately, however, the definition of risk can be reduced to a much more usable, less academic form, and this is the way you are going to be most successful communicating it with those who are not security professionals.

A risk is a chance of something bad happening.

Too simple? Not really. It's instantly understandable to virtually everyone, but at the same time it does not contradict the more complex definitions.

So when should you use one definition vs. the other?

In general, use the simple version. Getting entangled in the infinite number of ways risk can be calculated is something to avoid. It drains time and rarely accomplishes anything when broken down much farther than is described above.

So, written out (i.e. without the word "risk") we arrive at:

Security is the process of maintaining, based on what we know, an acceptable level of likelihood that something bad will happen to the organization.

…and once again, in it's more succinct and elegant form:

Security is the process of maintaining an acceptable level of perceived risk.

Wednesday, September 17, 2008

Hackers defaced collider site, say reports

Hackers defaced collider site, say reports
Published: 2008-09-12

UPDATED: A group of online vandals compromised the security of a server at the Large Hadron Collider (LHC) this week, putting up a Web page mocking the site's security but not the experiment, according to reports in two U.K. newspapers.

The attacks, which appear to have compromised a server at the European Organization for Nuclear Research (CERN), which runs the LHC, resulted in a server portal for one of the science teams being defaced by a group calling itself the Greek Security Team, according to an article in the U.K.-based Daily Telegraph. The defaced page mocked the security of the site, calling the IT staff "school kids," according to an article in the Times Online.

"We don’t know who they were but there seems to be no harm done," James Gillies, a spokesman for CERN, told the Times. "It appears to be people who want to make a point that CERN was hack-able."

CERN, the largest particle collider in the world, made history this week when the giant $8-billion machine was activated and its first beam of particles completed the 27 kilometer circuit underground. The two test beams created so far have been dumped, as the technical teams calibrated and check the performance of the large experiment. Eventually, the collider will smash two beams of particles into each other in an attempt to detect elementary particles not present since the Big Bang and gain insight into the nature of gravity.

The hackers targeted a server hosting the portal for the science team responsible for the Compact Muon Solenoid Experiment (CMS) at CERN. The organization's press office did not immediately return an e-mailed request for comment.

UPDATE: Two readers who have translated the Greek Web site have disagreed with the newspaper reports of the incident. The defaced Web page does not belittle the LHC's security, but appears to make fun of other hackers in the Greek Internet underground scene, the readers maintain. More can be found on this security researcher's blog.

If you have tips or insights on this topic, please contact SecurityFocus

Wednesday, August 6, 2008

Jerry Tabeling quoted in recent BBC News article

In light of the biggest identity theft case ever prosecuted in America, the spotlight is being turned on just how secure is our credit and debit card information?

Mr. Tabeling was interviewed by the BBC for his thoughts.

Read about it here: http://news.bbc.co.uk/2/hi/technology/7544313.stm

Tuesday, August 5, 2008

Final Word on DNS Chatter

Unless something of significant interest occurs, this will be my last post on the DNS flaw that everyone has been talking about for the past several weeks.

Before I leave the subject I'd like to throw out two valuable links.

1) Determine if your ISP has installed the proper patches - http://www.doxpara.com/ (click the "Check My DNS" button)

2) IntoDNS - http://www.intodns.com This site provides a very nice snapshot of your ISP's DNS configuration. Just enter your domain name and click on the report tab.

Saturday, August 2, 2008

Most Security Breaches Go Unreported

InformationWeek

Most Security Breaches Go Unreported

An RSA survey found the e-mail-borne malware and phishing that affected 69% of respondents' companies, may not have led to serious consequences in every instance.

By Thomas Claburn, InformationWeek
Aug. 1, 2008
URL: http://www.informationweek.com/story/showArticle.jhtml?articleID=209901208

More than 89% of security incidents went unreported in 2007, according to survey of about 300 attendees at this year's RSA Conference.

Security incidents, as defined by the study, represent "an unexpected activity that brought sudden risk to the organization and took one or more security personnel to address."

Some of the security incidents, such as the e-mail-borne malware and phishing that affected 69% of respondents' companies, may not have led to serious consequences in every instance. But 29% of those answering the survey said their organizations experienced customer or employee data leakage. Twenty-eight percent reported insider threats or theft and 16% reported intellectual property theft.

"With 29% of respondents stating that they experienced the leakage of employee or customer data in 2007, it is alarming to see that only 11% of those types of incidents went reported," said Tim Mather, chief security strategist for RSA Conference, in a statement. "Security professionals need to remain cognizant of the regulations that their organizations must comply with and ensure they are taking steps to properly report the security incidents that are required by law -- whatever they may be."

Such findings echo a recent a study of over 500 data breach forensic investigations conducted by Verizon Business Security Solutions. According to Bryan Sartin, VP of investigative response at Verizon, the publicly reported breaches are "just the tip of iceberg." He said that less than 5% of the more than 500 cases covered in the Verizon study involved some form of disclosure.

In short, companies appear to be far more insecure than they acknowledge. The RSA survey indicates that 46% of companies experienced no security incidents in 2007, 19% experienced 1 to 2, 14% experienced 3 to 5, 7% experienced 6 to 10, 3% experienced 11 to 20, and 13% experienced more than 20 security incidents.

The top security challenge, according to respondents, is lost or stolen devices (49%), followed by non-malicious employee error and employee education (tied at 47%), budgetary constraints (44%), external hacking threats (38%), executive buy-in (26%), and malicious insider threats (22%).

Wednesday, July 30, 2008

The Impact of Dan’s DNS Debacle on Internet Risk

Blogger: Pete Lindstrom

On July 8th, Dan Kaminsky of IOActive announced a major DNS “vulnerability” in conjunction with a number of major DNS vendors. The announcement was off the charts in fanfare and attention, but what was the real impact on risk?

First, it is worth noting that this “bug” is more properly classified as a new attack technique invented by Dan. It combines two vulnerabilities that have been well-known for some time – the ability to guess non-random transaction IDs and the use of Additional RRs to insert new entries into the DNS cache. A fix against either of these vulnerabilities also negates the attack itself.

The fundamental question that determines the risk impact revolves around whether it is reasonable to expect fewer or more incidents that use this technique when comparing the period prior to disclosure -- or, more properly, before the date of Dan’s invention of the technique (this also assumes prior art) – with the period after invention/disclosure and into the future. If the disclosure reduces the number of those incidents, then risk is reduced; if the disclosure increases the number of those incidents, then risk is increased.

With that litmus test as our guideline, it is useful to break down the functional elements of risk and look at the impact on threats, vulnerabilities, and consequences (we will cover consequences, then vulnerabilities, and finally threat).

Consequences
Though the consequences are the same before and after disclosure, it is worth discussing the impact here, given that the implication was that the “entire web” could be taken down. The nature of the attack requires the following:

  1. An attacker must convince/trick a user into making a DNS request for a domain that doesn’t already exist in their DNS server’s cache. The expectation here is that s/he can be easily tricked into doing this.
  2. Then, the attacker must simultaneously attack the DNS server by guessing the transaction ID. According to Kaminsky, the request/attack phase can be done reliably in about 10 seconds.
  3. The attack is DNS server-specific. Only users on the same DNS server are affected.
  4. Propagation: once the cache is poisoned, anyone requesting that domain will be routed to a malicious server.

Without combining this attack with other attack techniques, there can be three results:

  1. Spoofing of a single website for multiple, perhaps many, users using the same DNS server. Presumably, this would be followed by more traditional phishing and malware attacks.
  2. Denial-of-service by rerouting traffic from a legitimate site thereby taking potential customers or “eyeballs” away.
  3. Denial-of-service be rerouting traffic from a legitimate high volume site to a legitimate low-volume site thereby overloading the servers on the low-volume site.

Because of the point-to-point (user-to-website) nature of the attack, to do something that constitutes “taking over the entire web” is infeasible by a longshot.

The bottom line analysis for the effect on risk due to a change in consequences from pre-invention to post-invention: no change, and therefore no impact.

Vulnerabilities
These vulnerabilities have existed for years, and there have been workarounds for years. Along with this announcement, new patches were introduced in all major DNS server solutions. It is reasonable to assume that many DNS server implementations have been patched, though public accounts have suggested that number is in the 66%-75% range.

Bottom line analysis: the vulnerability level has been reduced, probably significantly, and the affect is positive for risk reduction. If 100% of DNS servers were patched, then overall risk would be reduced for this attack (assuming that there were actual attacks using this technique in the past.)

Threats
The real question regarding risk impact comes in the arena of the less-controllable manipulation of threat. The general threat equation revolves around an attacker’s willingness to attack, based on his/her own cost/benefit analysis that compares the cost to attack to the expected benefits, tempered by the potential for being caught and penalized.

Cost to attack – prior to disclosing the invention, there were likely few, if any attackers with “prior art” that mirrored this technique. It is anybody’s guess how many potential attackers might have figured it out eventually, but they would have had to come from the pool of folks with enough expertise to do so – I am going to guess 500,000 people.

After the disclosure, the hints provided in the press release, the podcast, the sorted stories, and the blog entries made it much easier to figure out. Let’s guess that 5 million people could execute the attack. With automated tools, that number goes up to 50 million.

These numbers are estimates that illustrate the nature of the exercise. You are welcome to fill in your own estimates and come to your own conclusions.

Bottom line analysis: a significant increase in threat and corresponding risk.

Net Effect
The risk manager's challenge is to weigh the decrease in vulnerable systems compared with the corresponding increase in threat, within the context of number of incidents and anticipated future incidents. Given the sheer size differential, it is difficult to conceive of a situation where risk is not increased.

Sometimes it "feels" like someone is taking action for the greater good, when that action actually creates a negative impact for all. For example, it is common for people to believe that raising prices of scarce resources during times of trouble (e.g. gasoline in the hurricane Katrina aftermath) is unconscionable even though a majority of economists recognize that raising prices actually provides for the greater public good. Vulnerability discovery and disclosure, and attack inventions, might feel like the right thing to do, but the net result is almost always a negative impact.