Hi Achim,
Thanks for clarifying the SERVER_NAME. I now understand that this is set
on the webserver itself.
How best to proceed to develop the 4 tests below and any others that may be
needed?
Will the open relay qualification be applicable for the HTTP Host Header
exploit or another?
Thanks!
On Mon, May 20, 2013 at 12:02 PM, Achim Hoffmann <webse...@sic-sec.org>wrote:
> Hi Vint,
>
> see my comments/answers inline.
>
> Achim
>
>
> Am 16.05.2013 18:12, schrieb Vint Surf:
> > Responses in-line. Thanks!
> >
> >> I'm thinking in order to determine if HTTP host header can be exploited,
> > we
> >> would need to:
> >> A) determine if SERVER_NAME, HTTP_HOST, or both have values
> >> B) verify the URI to see if the SERVER_NAME and HTTP_HOST match?
> >> C) Determine if there are wildcard entries for SERVER_NAME
> >
> >> Lets move one step back, what do you mean by SERVER_NAME?
> >
> > SERVER_NAME would be the server included in the POST command?
>
> no!
> SERVER_NAME ist the name as defined by the web server's configuration.
> I.e. in apache's httpd.conf the ServerName variable, if not set it contains
> what the Host: header contains.
>
> > i.e. POST https://addons.mozilla.org/en-US
>
> > So maybe send a POST with the valid server_name but with a random HOST
> > header and see if a response is returned? If so, I guess this can be
> > exploited?
>
> Yes, that's a test for that.
> But keep in mind that different web servers may behave different here.
> Unfortunately I don't have more details.
> You need at least 4 tests:
> 1. non-malicious one
> POST http://good.tld/path
> Host: good.tld
>
> 2. malicious
> a) POST http://good.tld/path
> Host: evil.tld
>
> b) POST http://evil.tld/path
> Host: good.tld
>
> c) POST http://evil.tld/path
> Host: evil.tld
>
> BTW, if such a POST request works, it's also an open relay.
>
> Other web servers may use different configurations (see apache above) and
> behave different.
>
>
> >> Also, is HTTP_HOST the host header send in a request? If so, we
> > control that and we can set it or not.
> >
> > Yes, I was referring to the malicious host also sent in a request.
> >
> >> I believe a curl request can be created to verify the above?
> >
> > Lets forget about the how for a while, first lets understand the
> > problem and the algorithm to identify it,
> >
> >
> >
> >> I apologize if this is not the right solution, but would appreciate any
> >> assistance. Thanks!
> >
> > No reason to apologize! We all need to learn about these new
> > vulnerabilities,
> >
> > PD: Can we take this conversation back to w3af-develop ?
>
>
>
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> _______________________________________________
> W3af-develop mailing list
> W3af-develop@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/w3af-develop
>
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
W3af-develop mailing list
W3af-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/w3af-develop
