[INFO] HTTPoxy Vulnerability may impact to web servers

mustafaramadhan · July 2016

Read https://www.kb.cert.org/vuls/id/797896 dan https://httpoxy.org/

This vulnerability may impact for all web servers.

Run 'wget -S --header="Proxy: 1.2.3.4:8080" https://yourdomain.com' for testing. If return something like 'ERROR 403: Forbidden' that mean website is 'safe'.

M66B · July 2016

How to mitigate: https://httpoxy.org/#fix-now

mustafaramadhan · July 2016

@M66B said:
How to mitigate: https://httpoxy.org/#fix-now

Yes. Kloxo-MR 7.0 already fixed this issue for all webservers (apache, lighttpd, nginx and hiawatha).

iBot · July 2016

Running nginx 1.4.1/php-fpm and behind cloudflare, inserted the code in the website conf but it's getting through.

Fusl · July 2016

iBot said: Running nginx 1.4.1/php-fpm and behind cloudflare, inserted the code in the website conf but it's getting through.

Wait, wha. CloudFlare does not filter that by now? If that's really true...bwahahaha, and THEY claim to keep away bots and hackers from websites? Wow.

GCat · July 2016

@iBot said:
Running nginx 1.4.1/php-fpm and behind cloudflare, inserted the code in the website conf but it's getting through.

I'm sure they'll have that filtered eventually

Amitz · July 2016

Cloudflare filters it for me here.

mustafaramadhan · July 2016

@Amitz said:
Cloudflare filters it for me here.

Do you mean support.lowend.io ?

sin · July 2016

Fusl said: Wait, wha. CloudFlare does not filter that by now? If that's really true...bwahahaha, and THEY claim to keep away bots and hackers from websites? Wow.

Cloudflare actually does a pretty good job. I use just their free plan and it's pretty amazing on how much it cleans up logs (going from logs full of tons of exploit scans and bots hitting to practically nothing with Cloudflare enabled).

Amitz · July 2016

@mustafaramadhan said:

@Amitz said:
Cloudflare filters it for me here.

Do you mean support.lowend.io ?

No, one of my own websites behind Cloudflare.

iBot · July 2016

works with google.com as well.

@Amitz Right now on "High" mode but it ain't working here.

It also goes through lowendtalk.com.

Not sure why but I've set the nginx fastcgi parameters as suggested, even if it did go through cloudflare, why is my server not mitigating it.

mustafaramadhan · July 2016

Test for my own website:

[root@sk1 /]# wget -S --header="Proxy: 1.2.3.4:8080" https://hostspectra.com/
--2016-07-21 14:46:30--  https://hostspectra.com/
Resolving hostspectra.com... 62.210.181.21
Connecting to hostspectra.com|62.210.181.21|:443... connected.
HTTP request sent, awaiting response...
  HTTP/1.0 403 Forbidden
  Date: Fri, 22 Jul 2016 14:44:02 GMT
  Server: Hiawatha v10.3
  Accept-Ranges: bytes
  Connection: keep-alive
  X-Hiawatha-Cache: 5
  Strict-Transport-Security: max-age=2592000;preload
  X-Supported-By: Kloxo-MR 7.0
  Access-Control-Allow-Origin: *
  X-Frame-Options: SAMEORIGIN
  X-XSS-Protection: 1;mode=block
  X-Content-Type-Options: nosniff
  Content-Length: 857
  Content-Type: text/html
2016-07-21 14:46:31 ERROR 403: Forbidden.

[root@sk1 /]#

And test for this forum:

[root@sk1 /]# wget -S --header="Proxy: 1.2.3.4:8080" https://www.lowendtalk.com/
--2016-07-21 14:49:06--  https://www.lowendtalk.com/
Resolving www.lowendtalk.com... 104.20.16.33, 104.20.17.33
Connecting to www.lowendtalk.com|104.20.16.33|:443... connected.
HTTP request sent, awaiting response...
  HTTP/1.1 200 OK
  Date: Fri, 22 Jul 2016 15:05:47 GMT
  Content-Type: text/html; charset=utf-8
  Connection: close
  Set-Cookie: __cfduid=d095cfa5f2ef53ab4583e398aeda032411469199947; expires=Sat, 22-Jul-17 15:05:47 GMT; path=/; domain=.lowendtalk.com; HttpOnly
  Set-Cookie: Vanilla=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/
  Set-Cookie: Vanilla=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/
  P3P: CP="CAO PSA OUR"
  X-Garden-Version: Vanilla 2.1.12p3
  X-Frame-Options: SAMEORIGIN
  Expires: Fri, 22 Jul 2016 15:06:47 GMT
  Cache-Control: max-age=60
  Cache-Control: public
  Server: cloudflare-nginx
  CF-RAY: 2c67caf7cf8803dc-DFW
Length: unspecified [text/html]
Saving to: “index.html”

    [ <=>                                   ] 69,665      --.-K/s   in 0.01s

2016-07-21 14:49:06 (4.98 MB/s) - “index.html” saved [69665]

eva2000 · July 2016

probably testing wrong target as it's for php-fpm/cgi for some folks and their web apps

test with php file httpoxy.php

<?php
if (isset($_SERVER['HTTP_PROXY']) && $_SERVER['HTTP_PROXY'] == 'vulnerable') {
  echo 'Vulnerable!';
}

and

curl --header "Proxy: vulnerable" http://example.com/httpoxy.php

if returns back empty = not vulnerable

FYI php 5.5.38, 5.6.24 and 7.0.9 have been released with native fixes for HTTPoxy too

eva2000 · July 2016

for PHP https://access.redhat.com/solutions/2442861

iBot · July 2016

@eva2000 said:
curl --header "Proxy: vulnerable" http://example.com/httpoxy.php

if returns back empty = not vulnerable
FYI php 5.5.38, 5.6.24 and 7.0.9 have been released with native fixes for HTTPoxy too

It returns empty while using https (cloudflare flexible) ~~but on http I get moved permanently html (probably my php app)~~

Secondly, I did notice all the php and it's module updates while performing an update (centos remi repo)

yomero · July 2016

So, let's me clarify this. Because fixing this bug doesn't seem like a big priority to me.

If I understand correctly, this can create troubles only if your software uses the HTTP_PROXY environment variable to make requests somewhere else. Otherwise, it will work just fine without issues.

Edit: Something like this... https://github.com/httpoxy/php-fpm-httpoxy-poc Guzzle apparently trusts the HTTP_PROXY environment variable to make requests

Correct me if I am wrong, thanks.

JustAMacUser · July 2016

iBot said: Not sure why but I've set the nginx fastcgi parameters as suggested, even if it did go through cloudflare, why is my server not mitigating it.

Inheritance issue maybe? If you set the fastcgi_param in http { }, for example. Then in a server section have something like location \.php$ { } with more fastcgi_params in it, even if the location's fastcgi_params are not the same, Nginx throws out all the fastcgi_params declared higher up. So it's best to include this workaround in a general file (e.g. Debian's fastcgi_params file, or something).

tr1cky · July 2016

Nobody read the CloudFlare blog post about this? They are only blocking harmful requests, not all requests on the free plan and if you wish, you can block all requests via a WAF rule that you can enable.

Fusl · July 2016

@sin said:

Fusl said: Wait, wha. CloudFlare does not filter that by now? If that's really true...bwahahaha, and THEY claim to keep away bots and hackers from websites? Wow.

Cloudflare actually does a pretty good job. I use just their free plan and it's pretty amazing on how much it cleans up logs (going from logs full of tons of exploit scans and bots hitting to practically nothing with Cloudflare enabled).

CloudFlare actually does a pretty good job in disabling domains when they get attacked if you don't use their Business or Enterprise plans.

sin · July 2016

Fusl said: CloudFlare actually does a pretty good job in disabling domains when they get attacked if you don't use their Business or Enterprise plans.

Right, but they're not disabling domains over some bot/exploit scans. They do that when you're getting heavy DDoS attacks.

NetworkPanda · July 2016

Not seeing the "403" error on a web site when you send a Proxy header, doesn't always mean that it isn't protected.
If you use the method to block the Proxy header by adding this into your Apache configuration:

RequestHeader unset Proxy early

Then the server removes the Proxy header, the site returns a normal HTTP 200 response and you are protected, as the Proxy header is now removed and will not reach your PHP/CGI application.

You see a 403 error only if you block the Proxy header with a ModSecurity rule and you have not already added the above line into your Apache configuration. If you add both the above line into Apache configuration and a ModSecurity rule, you see again a 200 response, because Apache removes the Proxy header before it reaches ModSecurity.

So, assuming that a site that does not return a 403 error is unsafe is not always correct. Also, CloudFlare removes the Proxy header (we tested it on several sites behind CloudFlare, the Proxy header was not there in the request that reached the server) so you are still safe behind CloudFlare even if it doesn't return a 403 error.

Howdy, Stranger!

Categories

In this Discussion

[INFO] HTTPoxy Vulnerability may impact to web servers

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

[INFO] HTTPoxy Vulnerability may impact to web servers

Comments