|
|
|
|
| |
| Some Akamai hosts allowed anyone to proxy SSL connections through them. That is, anyone could freely "Akamaize" his or her own SSL Web server (see: http://www.peacefire.org/bypass/Proxy/akamai.html). Because popular browsers (e.g., Netscape and IE) implicitly trust Verisign CA certificates, a malicious SSL server could spoof SSL certification via Akamai's use of Verisign server certificates. The effect was that simply checking a site for the existence of a Verisign server certificate had no meaning. Anyone would have been able to use a Verisign server certificate (specifically, one issued to Akamai) for signing arbitrary content. |
| |
Credit:
The information has been provided by Kevin Fu.
|
| |
Implications:
A user could not be certain that a server is who it claims to be. If a malicious server also spoofs DNS, then it can pretend to be any server (e.g., your bank or favorite shopping site). Simply using SSL does not guarantee end-to-end authenticity.
Details:
Akamai customers have the option to require SSL server authentication on their origin servers. That is, Akamai could configure their servers to reject origin servers that do not have the appropriate Verisign certificate. However, the default was not to check for origin server authenticity. Therefore, any host on the Internet could have proxied SSL Web pages through Akamai. Presumably, some customers did not want to pay Verisign to authenticate low-security content such as banner ads.
Example:
Here is a simple example to demonstrate the danger. Because Akamai fixed the vulnerability, this should no longer work. Direct your browser to https://snafu.fooworld.org/. Because your browser does not trust snafu.fooworld.org's self-signed certificate, the browser will warn you. This is expected behavior. Visit:
https://a248.e.akamai.net/n/248/1777/aks20001011.0/img.etrade.com/images/tab_none.gif .
This is legitimate content served through Akamai and is expected behavior.
Now direct your browser to:
https://a248.e.akamai.net/v/248/1777/365d/snafu.fooworld.org/.
Before the vulnerability was fixed, the browser would give no warning. This is unexpected and misleading behavior. At the time of writing, one unauthorized URL still existed in some Akamai caches. For instance,
https://18.7.0.13/n/248/1777/aks20001011.0/snafu.fooworld.org/
Where 18.7.0.13 corresponds to a248.e.akamai.net. Note that you cannot add new unauthorized content any more.
Now consider a malicious example based upon a real-world incident from a couple months ago. A malicious person wanting to cheat the stock market posts this URL in a chat room:
https://a248.e.akamai.net/v/248/1777/365d/WWW.AKAMAITECHN0L0GIES.NET/q4.html
Note the '0' (zero) characters in the word "technologies". Another possibility might be:
https://a248.e.akamai.net/v/248/1777/365d/akamaiinvestorrelations.com/q4.html
Such a URL would enable authentic-looking pages for things like faking press releases, fake credit card fill-out forms, etc. One could easily spoof a fake press
release as was done against Emulex (see: http://www.thestreet.com/_yahoo/comment/wrong/1055303.html). The difference is that victims will now have the pad lock icon at the bottom of their browser. Even security-conscious users might mistakenly trust the Web page as authentic. In particular, a Netscape Navigator user who clicks on the pad lock and selects "View Certificate" will see that a valid Verisign certificate issued to Akamai Technologies signed the page.
In the general case, Akamai hosts would always proxy SSL connections. There was one exception. Akamai hosts reported "HTTP/1.0 503 Service Unavailable" when an origin server had an expired SSL certificate.
Solution:
Although Akamai did not discuss details of their solution, they appear to have implemented some kind of access control. That is, origin servers must be explicitly granted access. Akamai is not limiting HTTP origin servers, however.
With permission to redistribute publicly, Andy Ellis from Akamai says:
"Pursuant to our conversation on September 18th, Akamai has recently changed its policies and business practices with respect to instant Akamazaition. Effective October 18th, 2000, Akamai will limit the use of its FreeFlow(SM) SSL service to authorized users (primarily customers and potential customers). Akamai will no longer allow Akamaized SSL service to entities that Akamai has not identified as an authorized user of the Akamai SSL service."
What can be learned from this vulnerability:
This problem is not unique to Akamai or Verisign. There are probably many other sites which unintentionally proxy SSL in this manner. Akamai just happens to be a very large instance. Any SSL Web server that transparently proxies arbitrary SSL connections by re-wrapping requests is vulnerable.
The crux of the problem is that SSL proxying in this manner defeats end-to-end security. Browsers traditionally make all authentication decisions. Because the Akamai hosts re-wrapped unauthentic, arbitrary content with an authentic Verisign certificate, the browser was unable to determine authenticity.
Open questions and issues:
* Could Verisign issue certificates for Akamai servers that use the Key Usage Extension or Certificate Policy Extension to explicitly note that the certificate is provided solely for use in a proxy-server role in which arbitrary untrusted data is intentionally signed using this certificate?
Users should not assume that data signed by a site's certificate is necessarily data being provided by the operator of that site. They should instead consult other information provided by the site operator to determine whether the digital signature is intended to convey some specific meaning, or no meaning at all.
* Does this violate Verisign's terms of use? (see: http://www.verisign.com/repository/gs_agree.html.) For instance, one can now get SSL pages certified by Verisign for origin servers in Cuba, Iran, Iraq, Libya, Montenegro, North Korea, Serbia, Sudan, and Syria (section 4.3 U.S. subsidiary). Furthermore, Verisign's Certification Practice Statement states "In order to verify a digital signature, it is necessary to know precisely what data has been signed." This is inconsistent with Akamai's practice of signing any arbitrary data that is located on any Internet site that uses the HTTPS protocol.
References:
Verisign Use of Certificates.
http://www.verisign.com/repository/CPS1.2/CPSCH8.HTM
Akamai caught in Net filtering crossfire.
http://news.cnet.com/news/0-1005-200-2586200.html
CERT Report. Inconsistent Warning Messages in Netscape Navigator
http://www.cert.org/advisories/CA-2000-08.html
CERT Report. Inconsistent Warning Messages in Internet Explorer
http://www.cert.org/advisories/CA-2000-10.html
Self-Certifying Read-Only File System
http://www.fs.net/sfs/new-york.lcs.mit.edu:85xq6pznt4mgfvj4mb23x6b8adak55ue/pub/sfswww/sfsro.html
|
|
|
|
|
|
|
|
|
|
