Bugtraq mailing list archives
Use of Akamai hosts to circumvent SSL server authentication
From: Kevin Fu <fubob () MIT EDU>
Date: Thu, 19 Oct 2000 01:31:54 EDT
-----BEGIN PGP SIGNED MESSAGE----- Use of Akamai hosts to circumvent SSL server authentication Reported to vendor: September 18, 2000 Vendor responded: September 18, 2000 Vendor fixed: October 18, 2000 ****** NOTE ****** ****** READ ME FIRST ****** This document discusses a security concern with Akamai hosts BEFORE the vulnerability was closed. As far as I know, all the vulnerabilities listed below have been fixed. This document aims to serve as an educational anecdote about end-to-end server authentication and how proxies can break the assumptions of popular trust models. ****** NOTE ****** ****** READ ME FIRST ****** Summary of vulnerability: ========================= Some Akamai hosts allowed anyone to proxy SSL connections through them. That is, anyone could freely "Akamaize" their own SSL Web server [6]. 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. 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. The problem: ============ 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's a simple example to demonstrate the danger. Because Akamai fixed the vulnerability, this should no longer work though. 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 also 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 fake press releases, fake credit card fill-out forms, etc. One could easily spoof a fake press release as was done against Emulex [1]. 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 the page was signed by a valid Verisign certificate issued to Akamai Technologies. In the general case, Akamai hosts would always proxy SSL connections. We found one exception. Akamai hosts reported "HTTP/1.0 503 Service Unavailable" when an origin server had an expired SSL certificate. The solution: ============= Although Akamai did not discuss details of their solution with me, 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 [6]. 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 to learn 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. Although I am biased, one alternative to authenticate read-only content on untrusted replicas is the Self-Certifying Read-Only File System [7]. 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 [2]? 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 [0] states that "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. Full disclosure: ================ The full disclosure debate has heated up in recent months. You can judge whether my choice to delay the report was appropriate. I met with engineers from Akamai on September 18. They actually contacted me before I contacted them because of a suspected information leak. Akamai was already aware of the problem from internal review and had planned to fix the vulnerability. My discovery stepped up the priority. I agreed to delay my security alert by one month so that Akamai could implement a fix. The meeting was very friendly. However, I did not get a free T-shirt. :-) In retrospect, I feel that I asked Akamai the wrong questions before agreeing to a release date. I should have asked how much time they needed and why. For at least one month, SSL Server authentication had limited meaning. On the other hand, the delay of the report was partially due to not having time to write a thorough report until now. However, I do believe that some delay in full disclosure is appropriate for such centralized systems. Because Akamai has administrative control of its hosts, it has the ability to close the vulnerability. This is not the case for decentralized systems. If a Web browser company finds a vulnerability, even fixing the hole is not good enough. They have no way to guarantee deployment on millions of decentralized clients. Acknowledgments: ================ For their comments and suggestions, I would like to thank the MIT Network Security Team (especially Matt Power and Bob Mahoney). I also thank Andy Ellis and everyone behind the scenes at Akamai for responding quickly and making sure the vulnerability got fixed. References: =========== [0] Verisign Use of Certificates. http://www.verisign.com/repository/CPS1.2/CPSCH8.HTM [1] The Anatomy of a Bogus Press Release http://www.thestreet.com/_yahoo/comment/wrong/1055303.html [2] Verisign Subscriber Agreement. http://www.verisign.com/repository/gs_agree.html [3] Akamai caught in Net filtering cross fire. http://news.cnet.com/news/0-1005-200-2586200.html [4] CERT Report. Inconsistent Warning Messages in Netscape Navigator http://www.cert.org/advisories/CA-2000-08.html [5] CERT Report. Inconsistent Warning Messages in Internet Explorer http://www.cert.org/advisories/CA-2000-10.html [6] Using Akamai to bypass Internet censorship http://www.peacefire.org/bypass/Proxy/akamai.html [7] Self-Certifying Read-Only File System http://www.fs.net/sfs/new-york.lcs.mit.edu:85xq6pznt4mgfvj4mb23x6b8adak55ue/pub/sfswww/sfsro.html - -------- Kevin E. Fu (fubob () mit edu) PGP key: https://snafu.fooworld.org/~fubob/pgp.html -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQEVAwUBOe6G0EWdEt/g/SWJAQGTXQf9FowulAKm0Z0ouZr0a0+Vy1ghOKwYbhr8 iJBuewH0i4sf8AA3QhbbQRnvR3pVogSl2tCsMeRCowwpOvMRPbnpjGXy4Jreqiru x5nfStG6hGeJnaz0aUuf13FopCz14xs0TpuHRhUho4Vn7OpmNAMuVI8Ue/wTYi6z IuiIf2GqgqmNk7cQqggZ+0yqL+E/1KEPvQ53Wbjkle16+UXPI/Yf21gK0hqRdmXZ P4kw/STrRkbMcxUuyM6aCwRFxhdI2P1NwFm3u36N7RHxIqxxvNQV1U+Qt+mJOnWT y4Gf2RFtXTXw98RN+i9gXd/yprNd5WfmCjp0wkvvs+tcliqyAdOKyA== =s9JR -----END PGP SIGNATURE-----
Current thread:
- Use of Akamai hosts to circumvent SSL server authentication Kevin Fu (Oct 19)