[17272] in bugtraq
Use of Akamai hosts to circumvent SSL server authentication
daemon@ATHENA.MIT.EDU (Kevin Fu)
Thu Oct 19 14:37:19 2000
Message-Id: <200010190531.BAA16861@tiramisu.lcs.mit.edu>
Date: Thu, 19 Oct 2000 01:31:54 EDT
Reply-To: Kevin Fu <fubob@MIT.EDU>
From: Kevin Fu <fubob@MIT.EDU>
To: BUGTRAQ@SECURITYFOCUS.COM
-----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-----
