Subject: [websec] #34: HSTS cache manipulation and misuse by server enabled by wildcard cert

From: "websec issue tracker" <[email-masked]>
Date: Sun, 15 Jan 2012 02:52:19 -0000

#34: HSTS cache manipulation and misuse by server enabled by wildcard cert

 See..

 The Double-Edged Sword of HSTS Persistence and Privacy --  by Mikhail
 Davidov
 http://haxsys.net/2011/04/the-double-edged-sword-of-hsts-persistence-and-
 privacy/

 summary:

 This technique allows a web app on one domain to surreptitiously send a
 message to another web app on another domain via manipulation of the HSTS
 cache...

 If server wields a wildcard cert, eg for "*.example.com", then example.com
 can create any number of subdomains of example.com, with any subdomain
 name, and then direct user agents to fetch resources from these
 subdomains. If HSTS Policy is returned for each of these subdomains, and
 includeSubDomains is not used, then any number of entries will be created
 in in the user agent's HSTS store. E.g., an web page like the below would
 accomplish this..

   [img]https://charcount-5.example.com/setbit.png[/img]      -- this
 stores the char count of the msg

   [img]https://0-H.example.com/setbit.png[/img]
   [img]https://1-E.example.com/setbit.png[/img]
   [img]https://2-L.example.com/setbit.png[/img]
   [img]https://3-L.example.com/setbit.png[/img]
   [img]https://4-O.example.com/setbit.png[/img]

 These entries can be read back by some other web application under some
 other domain name by causing the user agent to send HTTP requests to
 example.com in order to brute-force the character count subdomain name --
 the server responds whether the name is available over just http -- which
 means it is a miss, or over HTTPS, which is a hit..

   http://charcount-1.trackingexampledomain.com/getbit.png [ Server: HTTP ]
   http://charcount-2.trackingexampledomain.com/getbit.png [ Server: HTTP ]
   http://charcount-3.trackingexampledomain.com/getbit.png [ Server: HTTP ]
   http://charcount-4.trackingexampledomain.com/getbit.png [ Server: HTTP ]
   http://charcount-5.trackingexampledomain.com/getbit.png [ Server: HTTPS!
 ]   -- msg char count is 5

 Then the web app can brute force each character of the message in a
 similar fashion.

 the original message-sending domain web app can clear the cached message
 by causing the user agent to re-request resources from the same dubdomains
 and returning a HSTS header for each with max-age=0.

 For a resolution, Mikhail suggests..

 "My proposal is to amend the draft to force the includeSubDomains flag on
 wildcard certificates. This would limit them to only one entry in the
 browsers HSTS database and make the technique above prohibitively
 expensive to non-CA owners as a separate signed SSL certificate would be
 needed for every bit of information stored and limit encoding options."

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-websec-strict-transport-
  jeff.hodges@…          |  sec@…
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  strict-      |    Version:
  transport-sec          |   Keywords:
 Severity:  Active WG    |
  Document               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/websec/trac/ticket/34>
websec <http://tools.ietf.org/websec/>

---

From: Yoav Nir <[email-masked]>
Date: Sun, 15 Jan 2012 09:13:23 +0200

Interesting. 

But I don't see how subdomains help. If I have a website called charcount-5.example.com, and I use a wildcard *.example.com certificate, the HSTS entry is still written for charcount-5.example.com. Adding subdomains would affect *.charcount-5.example.com, not 0-H.example.com.

I wouldn't want to force the includeSubdomains, as there may be valid reasons to have a subdomain of example.com that is HTTP, whereas the decision on buying a wildcard certificate is a matter of cost and convenience.

Yoav

On Jan 15, 2012, at 4:52 AM, websec issue tracker wrote:

> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec
> IƧ��[�(^rC�{S�֥I�.�+r�^��

---

From: Adam Barth <[email-masked]>
Date: Sat, 14 Jan 2012 23:51:39 -0800

Why not just postMessage of the HTML <form> element?  If you want be
more sneaky about it, you can just the HTTP cache.  Anyway, web sites
are allowed to send messages to each other.

Adam