altering the host header on requests

[James Kettle]

Does anyone know of a way to alter the Host header used in a HTTP request without breaking it? Zap appears to use the host header to work out which IP to send the request to, so altering it triggers an error:

For example, sending the following request to 192.168.1.73 via org.parosproxy.paros.network.HttpMessage paros.network.HttpRequestHeader

GET /joomla/?foo=bar&cachebust=1405888831.78 HTTP/1.1

Host: ndz27s.192.168.1.73
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Cookie: tz_offset=3600; acopendivids=swingset,jotto,phpbb2,redmine; acgroupswithpersist=nada; d5a4bd280a324d2ac98eb2c0fe58b9e0=ahufhedqrq6atgh9lp81ogg3p6
Referer: http://192.168.1.73/
DNT: 1
Connection: keep-alive
Cache-Control: no-cache

triggers the following error:

javax.script.ScriptException: java.net.UnknownHostException:  java.net.UnknownHostException: ndz27s.192.168.1.73 in <script> at line number 58

The relevant code looks roughly like:

headers = org.parosproxy.paros.network.HttpRequestHeader(headers_shown_above)
attack = org.parosproxy.paros.network.HttpMessage(headers, body)
as_helper.sendAndReceive(attack, True, True)

Any suggestions?

(The background is that I'm currently porting ActiveScan++)

Cheers,

James

[thc...@gmail.com]

Hi.

Unfortunately, that's not currently possible.

Could you please raise an issue [1]?


[1] https://code.google.com/p/zaproxy/issues/entry

Thank you.
Best regards.

--
You received this message because you are subscribed to the Google Groups "OWASP ZAP Developer Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zaproxy-devel...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[James Kettle]

Sure, done: https://code.google.com/p/zaproxy/issues/detail?id=1318

[kingthorin+owaspzap]

From the machine running ZAP does nslookup or host for ndz27s.192.168.1.73 return 192.168.1.73?

[James Kettle]

No, the ndz27s prefix is randomly generated so the hostname doesn't resolve. The vulnerability this code is testing for relies on sending a poisoned host header that does not resolve to the target server's IP.

[Colm O'Flaherty]

Like a shared hosting environment? What's the actual vulnerability?

--

[kingthorin+owaspzap]

I don't think this is a valid test then.

If the network stack can't find an IP for the communications of course it's going to fail, though perhaps it should fail more gracefully.

A more valid test would be to put that host into your host file and give it an IP other than the server/service you're trying to test, at least that way the name would resolve to an IP. Even if that IP then refuses to serve anything.

[James Kettle]

The actual vulnerability is password reset poisoning & cache poisoning - see my post at http://www.skeletonscribe.net/2013/05/practical-http-host-header-attacks.html for further details on the technique.

It isn't really practical to alter the user's hosts file every time they run a scan. As I mention in the bug report, what would really help here is a setRemoteAddr() method on org.parosproxy.paros.network.HttpMessage that lets me set the target IP and takes precedence over the host header. That's roughly how I've implemented it in burp suite.

[thc...@gmail.com]

Thanks!

Best regards.

[kingthorin+owaspzap]

Can you confirm that manually changing your host file does allow you to test as you expected? (Or inserting a static setRemoteAddr() in org.parosproxy.paros.network.HttpMessage) [Just as a PoC.]

Excellent blog post.

[James Kettle]

Heh, glad you like the post. I've just confirmed manually setting an override in the hosts file works.

[James Kettle]

I have found one case where manually editing the hosts file doesn't work:

GET http://192.168.1.73/joomla/index.php?cow=foo&cachebust=1408977611.1 HTTP/1.1
Host: taint.192.168.1.73
...

When I try to issue this, ZAP silently changes the host header to match the host in the request line, so it becomes:

GET http://192.168.1.73/joomla/index.php?cow=foo&cachebust=1408977611.1 HTTP/1.1
Host: 192.168.1.73

On Tuesday, 19 August 2014 13:18:58 UTC+1, kingthorin+owaspzap wrote: