CERT VU#435052 - intercepting proxy vulnerability

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

CERT VU#435052 - intercepting proxy vulnerability

Mark Nottingham-4
See:
   http://www.kb.cert.org/vuls/id/435052

 From an HTTP perspective, there are a number of potential reactions;

1) intercepting proxies are bad; we told you so!

2) we should accommodate intercepting proxies in HTTPbis, because  
they're a reality.

2a) we should note this type of attack in Security Considerations, and  
more strongly recommend that clients send an absolute URI on the  
request-line, even when not using a configured proxy.

Just food for thought...

Cheers,

--
Mark Nottingham



Reply | Threaded
Open this post in threaded view
|

Re: CERT VU#435052 - intercepting proxy vulnerability

Roy T. Fielding
On Feb 23, 2009, at 3:42 PM, Mark Nottingham wrote:

> See:
>   http://www.kb.cert.org/vuls/id/435052
>
> From an HTTP perspective, there are a number of potential reactions;
>
> 1) intercepting proxies are bad; we told you so!
>
> 2) we should accommodate intercepting proxies in HTTPbis, because  
> they're a reality.
>
> 2a) we should note this type of attack in Security Considerations,  
> and more strongly recommend that clients send an absolute URI on  
> the request-line, even when not using a configured proxy.
>
> Just food for thought...

3) This report blames intercepting proxies for reading and acting
upon the HTTP stream instead of blaming browsers for sending an
HTTP message that contradicts its routing via TCP/IP.  I would think
that the fix is to plug the apparent (unconfirmed) security hole in
the browsers that allows plug-ins to set the value of Host independent
of the requested URI.  What's up with that?

Expecting an intercepting proxy to have access to the TCP/IP
information (as believed by the client) and be able to compare it
to the DNS records of the Host (as believed by the proxy) doesn't
seem likely to work given what we know about DNS.

Fixing the browser bug, OTOH, would work.

....Roy


Reply | Threaded
Open this post in threaded view
|

Re: CERT VU#435052 - intercepting proxy vulnerability

David Morris-4


On Mon, 23 Feb 2009, Roy T. Fielding wrote:

> On Feb 23, 2009, at 3:42 PM, Mark Nottingham wrote:
>
>> See:
>>  http://www.kb.cert.org/vuls/id/435052
>>
>> From an HTTP perspective, there are a number of potential reactions;
>>
>> 1) intercepting proxies are bad; we told you so!
>>
>> 2) we should accommodate intercepting proxies in HTTPbis, because they're a
>> reality.
>>
>> 2a) we should note this type of attack in Security Considerations, and more
>> strongly recommend that clients send an absolute URI on the request-line,
>> even when not using a configured proxy.
>>
>> Just food for thought...
>
> 3) This report blames intercepting proxies for reading and acting
> upon the HTTP stream instead of blaming browsers for sending an
> HTTP message that contradicts its routing via TCP/IP.  I would think
> that the fix is to plug the apparent (unconfirmed) security hole in
> the browsers that allows plug-ins to set the value of Host independent
> of the requested URI.  What's up with that?
>
> Expecting an intercepting proxy to have access to the TCP/IP
> information (as believed by the client) and be able to compare it
> to the DNS records of the Host (as believed by the proxy) doesn't
> seem likely to work given what we know about DNS.
>
> Fixing the browser bug, OTOH, would work.

>From the CERT report, it wasn't clear to me that the vulnerability was
much larger with a subverted browser than it would be with a program which
simulates a browser and sends the out of sync host: values.

I think the additional exposure would be if the nasty site managed to
redirect the user to an intranet server (intercepting proxy uses an
internal DNS and resolves the intranet host name) which then engages in an
authentication dialog with the user who just happens to have been
subverted AND doesn't recognize the diversion to an unexpected dialog AND
has credentials for that intranet server.  Even than while I'm willing,
for this dicussion, to stipulate that the poorly written browser allows
active content to set the host: value, I don't understand how the repeated
tweaking of the host value and URI is accomplished as the authentication
process occurs, etc. Pretty unlikely.

This whole attack vector can be blocked with proper protection of the
interception proxy so that it can't be used to connect to an internal
server it isn't supposed to. The CERT message pretty much covered all
the necessary steps. At most, we could add a security note that indicates
that if the host: value is used to route the proxied connection, the value
must be validated to insure it can only resolve to one of the IPs already
authorized for the invisible redirection.

Dave Morris

Reply | Threaded
Open this post in threaded view
|

Re: CERT VU#435052 - intercepting proxy vulnerability

Joe Orton-2
In reply to this post by Roy T. Fielding
On Mon, Feb 23, 2009 at 05:53:15PM -0800, Roy T. Fielding wrote:
> 3) This report blames intercepting proxies for reading and acting
> upon the HTTP stream instead of blaming browsers for sending an
> HTTP message that contradicts its routing via TCP/IP.  I would think
> that the fix is to plug the apparent (unconfirmed) security hole in
> the browsers that allows plug-ins to set the value of Host independent
> of the requested URI.  What's up with that?

This is a fun case of "chinese whispers".  The problem is purely a
browser/plugin issue, as you say, and was first reported in 2006:

http://www.securityfocus.com/archive/1/441014

and it goes round and round until someone clueless at CERT decides it
must be a security bug in proxies.  I believe all the actual security
bugs have been long since fixed, e.g. Flash:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6245

Regards, Joe

Reply | Threaded
Open this post in threaded view
|

Re: CERT VU#435052 - intercepting proxy vulnerability

Amit Klein
Actually, a slightly different manifestation of the exact same
underlying issue is

http://www.webappsec.org/lists/websecurity/archive/2006-08/msg00047.html

On Wed, Feb 25, 2009 at 1:10 PM, Joe Orton <[hidden email]> wrote:

> On Mon, Feb 23, 2009 at 05:53:15PM -0800, Roy T. Fielding wrote:
>> 3) This report blames intercepting proxies for reading and acting
>> upon the HTTP stream instead of blaming browsers for sending an
>> HTTP message that contradicts its routing via TCP/IP.  I would think
>> that the fix is to plug the apparent (unconfirmed) security hole in
>> the browsers that allows plug-ins to set the value of Host independent
>> of the requested URI.  What's up with that?
>
> This is a fun case of "chinese whispers".  The problem is purely a
> browser/plugin issue, as you say, and was first reported in 2006:
>
> http://www.securityfocus.com/archive/1/441014
>
> and it goes round and round until someone clueless at CERT decides it
> must be a security bug in proxies.  I believe all the actual security
> bugs have been long since fixed, e.g. Flash:
>
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6245
>
> Regards, Joe
>
>