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

Adam Barth <ietf@adambarth.com> Sun, 15 January 2012 07:52 UTC

Return-Path: <ietf@adambarth.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E5121F8468 for <websec@ietfa.amsl.com>; Sat, 14 Jan 2012 23:52:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.732
X-Spam-Level:
X-Spam-Status: No, score=-2.732 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+CIHo0lzJrr for <websec@ietfa.amsl.com>; Sat, 14 Jan 2012 23:52:12 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4F51A21F8464 for <websec@ietf.org>; Sat, 14 Jan 2012 23:52:12 -0800 (PST)
Received: by iaae16 with SMTP id e16so7330027iaa.31 for <websec@ietf.org>; Sat, 14 Jan 2012 23:52:12 -0800 (PST)
Received: by 10.50.77.226 with SMTP id v2mr5065212igw.12.1326613931828; Sat, 14 Jan 2012 23:52:11 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id or2sm13748301igc.5.2012.01.14.23.52.10 (version=SSLv3 cipher=OTHER); Sat, 14 Jan 2012 23:52:10 -0800 (PST)
Received: by iaae16 with SMTP id e16so7329985iaa.31 for <websec@ietf.org>; Sat, 14 Jan 2012 23:52:10 -0800 (PST)
Received: by 10.50.160.131 with SMTP id xk3mr3231935igb.19.1326613930155; Sat, 14 Jan 2012 23:52:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.62.139 with HTTP; Sat, 14 Jan 2012 23:51:39 -0800 (PST)
In-Reply-To: <070.daef625ac2bff2b5e11ec0521f0bc368@trac.tools.ietf.org>
References: <070.daef625ac2bff2b5e11ec0521f0bc368@trac.tools.ietf.org>
From: Adam Barth <ietf@adambarth.com>
Date: Sat, 14 Jan 2012 23:51:39 -0800
Message-ID: <CAJE5ia9tqGBtN8vCCV2vgy8QC5Mevdh1P8X91WJGTvuKB0R_=g@mail.gmail.com>
To: websec issue tracker <trac+websec@trac.tools.ietf.org>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Cc: websec@ietf.org, draft-ietf-websec-strict-transport-sec@tools.ietf.org
Subject: Re: [websec] #34: HSTS cache manipulation and misuse by server enabled by wildcard cert
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Jan 2012 07:52:14 -0000

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


On Sat, Jan 14, 2012 at 6:52 PM, websec issue tracker
<trac+websec@trac.tools.ietf.org> wrote:
> #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/>
>