MD5 considered harmful today

[HURST]

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.

As a result of this successfull attack, we are currently in possession of a rogue Certification Authority certificate. This certificate will be accepted as valid and trusted by all common browsers, because it appears to be signed by one of the root CAs that browsers trust by default. In turn, any website certificate signed by our rogue CA will be trusted as well. If an unsuspecting user is a victim of a man-in-the-middle attack using such a certificate, they will be assured that the connection is secure through all common security indicators: a "https://" url in the address bar, a closed padlock and messages such as "This certificate is OK" if they chose to inspect the certificate.

http://www.win.tue.nl/hashclash/rogue-ca/

[Rmus]

Note an update today in the article:

Verisign, the owner of the RapidSSL brand, has immediately responded when our work became public. See the announcement "This morning's MD5 attack - resolved" by Tim Callan. Some interesting quotes from this blog:

• "We applaud security research of this sort and are glad that white hats like the "MD5 Collision Inc." group make a point of investigating online security."
  
  
• "We have discontinued using MD5 when we issue RapidSSL certificates, and we've confirmed that all other SSL Certificates we sell are not vulnerable to this attack. We'll continue on our path to discontinue MD5 in all end entity certificates by the end of January, 2009."
  
  
• "... any customer who would like to do so can replace any MD5-hashed certificate free of charge."

I and a friend discussed this article yesterday, and agreed that it afforded an opportunity to review some security procedures. So, while the crypto experts are hashing over the mathematical intricacies of all of this, here is a pertinent statement we home users can ponder:

description of how our attack scenario may be used to impersonate an existing website.

When a user wants to visit the secure website, the web browser will look on the Internet for the genuine web server. There exist "redirection attacks", by which the communication from the browser can be redirected to the rogue website.

It's evident that their attack scenario is one that has been in use for many years: redirect to the rogue site. Two basic methods for redirect have been labeled as phishing and pharming.

The common way to exploit phishing is to trick the user into clicking on a link in an email or on a website which takes them to a different site than they expected.

(We can eliminate the Google redirect here, since people don't normally use Google to get to their financial web sites.)

By hiding the rogue URL in html code, the URL that displays will appear to be legitimate, but will reveal the rogue URL when hovering the mouse over the link:

Paypal scams were common awhile back:

The obvious prevention is to never click on a link to go to a site to login where you transact business. The financial sites I deal with emphasize this in their security measures.

The other method is pharming, where hackers are able to redirect to a rogue site by assigning a different Internet Protocol (IP) address to the URL you think you are using, by hacking into the Domain Name System (DNS) server where the URL name is resolved into a number (IP address).

If your_bank.com has an IP address of 123.45.678 and the hacker is able to change that to the rogue site address of say, 213.45.32, then even if you type your_bank.com into your browser, you can be led directly to the rogue site which may use an exact replica of your site's logos, etc. You can search for examples of exploits using this method, and evidently the attack scenario described in the article would make use of this method.

How to prevent? We like to trust our DNS servers, but some people take preventative measures against pharming by using their firewall as a filter.

This is accomplished by putting the IP addresses of your sites where you transact business into a Custom Address Group, such as:

Since these are usually secure sites - https via port 443 - you can create a rule to permit connection only to those addresses in your custom address group:

Now, if you type your_bank.com into the browser and it is redirected to a different IP address, your firewall will alert:

One person I know has a rule as above which includes *any* port, to take care of a redirect to a port other than port 443. Before going to a financial site, she opens a fresh instance of the browser, invokes that firewall rule, then navigates to the site using a bookmark. When finished, she closes the browser, clears the cache, then reverts back to the normal firewall rule.

Overly cautious? Perhaps, but part of security is keeping one's peace of mind.

There may be other ways of dealing with pharming that someone would like to mention.

EDIT: On another forum it was brought out that Man In the Middle Attacks at WiFi hotspots presents a problem different from that of classic pharming. For one example, see:

http://en.wikipedia.org/wiki/Evil_tw...eless_networks)

----
rich

[HURST]

Rich,

once again, thanks for sharing your knowledge.

[aigle]

Yes, very nice.

[raakii]

Can u tell about SHA and RIPEMED regarding the securityas MD5 is insecure.

[Rmus]

Thanks, HURST and aigle for your comments.

The article HURST posted has been added to the Notes in the wiki article on MD5:

http://en.wikipedia.org/wiki/MD5

The Versign response indicated that the researchers did not notify Verisign, one of the Certification Authorities, before their presentation.

Verisign's comment:

VeriSign is itself a white-hat security research firm (through our widely respected iDefense Labs), and we understand the concept of "ethical hacking." We're disappointed that these researchers did not share their results with us earlier, but we're happy to report that we have completely mitigated this attack.

________________________________________________________________________________________________

Originally Posted by raakii

Can u tell about SHA and RIPEMED regarding the securityas MD5 is insecure.

You can start here for some background on SHA and then search for other articles:

http://en.wikipedia.org/wiki/SHA1


----
rich