Page 1 of 2 12 LastLast
Results 1 to 20 of 24

Thread: httpoxy vulnerability

  1. #1

    httpoxy vulnerability

    Hello,

    Apache has released a vulnerability report with regards to the Proxy header.
    http://www.gossamer-threads.com/lists/apache/dev/460590
    https://httpoxy.org/

    In short, we just need to filter out the Proxy header from all requests, as it should only be used internally.


    Testing:

    I've created this script to help you check if you're affected (which everyone most likely is):
    http://files1.directadmin.com/servic...oxy_header.php

    Download it to any website/domain, and run it through your browser.
    It will give you a good or bad output.

    It makes a call to itself via curl (so make sure your domain works from within your server), and passes the "Proxy" header in the curl call.
    The output of that internal call will return "good" or "bad" depending on if the internal call received the Proxy header.



    How to fix:

    The fix varies per setup, but custombuild can do this for you.
    Type:
    Code:
    cd /usr/local/directadmin/custombuild
    ./build update
    ./build version
    ./build rewrite_confs
    so the configs are updated that filter out the Proxy header.
    Note that the change only exists on files1, so the other mirrors may take a few hours before the update.

    Ensure that in the "./build version" output, you see "rev 1564" or newer.
    rev 1563 does not have the changes in the configs.
    If not, you may want to do the fix manually, unless you want to wait for the mirrors to sync up.
    If you have CustomBuild 1.1/1.2, manually check the files below to ensure the changes are added, and test with the above testing script.

    Verify by running the testing php script again to ensure it says "Good!" in the output.

    ------------

    Manual Fix:

    However, if you just want to do this surgically, these are the changes:

    Apache

    Edit
    Code:
    /etc/httpd/conf/extra/httpd-default.conf
    and add:
    Code:
    <IfModule mod_headers.c>
            RequestHeader unset Proxy early
    </IfModule>
    to the bottom, and restart httpd, then check again with the above test script.


    Nginx & Nginx/proxy

    Edit
    Code:
    /etc/nginx/nginx_limits.conf
    and add this code to the bottom
    Code:
    fastcgi_param HTTP_PROXY "";
    and restart nginx, then check again with the above test script.

    John

  2. #2
    Join Date
    Sep 2005
    Posts
    372
    Is it possible to force a sync in the future? Especially in cases like this it helps if all mirrors are up to date.

  3. #3
    They're all pulls from servers we don't manage.
    If you want, just use one of ours, eg:
    Code:
    ./build set downloadserver files.directadmin.com
    as we have those set to 4 hour rsyncs.
    But after you're done, we recommend finding the fastest one again:
    Code:
    ./build set_fastest
    John

  4. #4
    Join Date
    Sep 2015
    Location
    Arnhem, NL
    Posts
    402
    Thanks for the quick update in the default configs. Everything is patched now without any problems. files6 (amsterdam) is already synced (syncs at GMT +1)

  5. #5
    Join Date
    Nov 2010
    Posts
    350
    What is the priority of this issue? Should I immediately fix it or can it wait a few days?

  6. #6
    Join Date
    Oct 2004
    Location
    London, UK
    Posts
    6,758
    As for every vulnerability, i would say to do that immediatly

    Regards
    SeLLeRoNe - Andrea Iannucci
    Head of Managed Service - Senior DevOps Engineer
    If you need my support write me an E-Mail to Support@CrazyNetwork.it

  7. #7
    Join Date
    Apr 2009
    Posts
    2,173
    Quote Originally Posted by Petertjuh360 View Post
    What is the priority of this issue? Should I immediately fix it or can it wait a few days?
    RedHat/CentOS is calling it a "Important" update: https://rhn.redhat.com/errata/RHSA-2016-1422.html - also they say a "remote attacker", wich make it very serious in my eyes:

    A remote attacker could possibly use this flaw to redirect HTTP requests performed by a CGI script to an attacker-controlled proxy via a malicious HTTP request.

  8. #8
    Join Date
    May 2008
    Location
    The Netherlands
    Posts
    1,182
    PHP

    Whether you are vulnerable depends on your specific application code and PHP libraries, but the problem seems fairly widespread
    Just using one of the vulnerable libraries, while processing a user’s request, is exploitable.
    If you’re using a vulnerable library, this vulnerability will affect any version of PHP
    It even affects alternative PHP runtimes such as HHVM deployed under FastCGI
    It is present in Guzzle, Artax, and probably many, many libraries
    Guzzle versions after 4.0.0rc2 are vulnerable, Guzzle 3 and below is not.
    Another example is in Composer’s StreamContextBuilder utility class

    So, for example, if you are using a Drupal module that uses Guzzle 6 and makes an outgoing HTTP request (for example, to check a weather API), you are vulnerable to the request that plugin makes being “httpoxied”.
    So if you got a server with clients and you don't know exactly what they got in their code, you'd better run the fix. As you can see a standard CMS could be using something in a simple plugin that is vulnerable.
    ~ Arieh

  9. #9
    Join Date
    Mar 2014
    Location
    Australia, Sydney
    Posts
    94
    I've done the manual patch to apache and the script was still showing "Bad..."

    Then, I've done the:
    Code:
    cd /usr/local/directadmin/custombuild
    ./build update
    ./build version
    ./build rewrite_confs
    and the script still shows "Bad..."

    The CB is 2.0.0 (rev: 1564)
    Last edited by dugalex; 07-19-2016 at 01:58 PM.

  10. #10
    Join Date
    Oct 2004
    Location
    London, UK
    Posts
    6,758
    Did apache restarted? Have you tryed to manually restart it?

    Regards
    SeLLeRoNe - Andrea Iannucci
    Head of Managed Service - Senior DevOps Engineer
    If you need my support write me an E-Mail to Support@CrazyNetwork.it

  11. #11
    Join Date
    Mar 2014
    Location
    Australia, Sydney
    Posts
    94
    yes, the first time manually, the second time it restarted by itself after rewrite_confs

  12. #12
    @dugalex:
    If you're running a basic apache setup, confirm you see the mentioned code in the httpd-default.conf file.

    John

  13. #13
    Join Date
    Mar 2014
    Location
    Australia, Sydney
    Posts
    94
    Yes, the code is there.

    I've tried running the script using https and it showed "Good..." but on refresh it's back to "Bad..."
    Might be Firefox cache, but chrome is showing the same.

  14. #14
    Another way to check, would be from the command line, eg:
    Code:
    curl 'http://www.domain.com/test_proxy_header.php?check=yes' -H 'Proxy: evil'
    where the output will be simpler, just "good" or "bad" (without any newlines, so will likely show up to the left of the next prompt). Not sure beyond that.. unless the httpd process didn't get a full restart.., like "killlall -9 httpd" to nuke it, then start it again.

    Another possibility would be if you don't have mod_headers.c in httpd? Check:
    Code:
    /usr/sbin/httpd -l | grep mod_headers
    where we should see it listed.

    John

  15. #15
    Join Date
    Mar 2014
    Location
    Australia, Sydney
    Posts
    94
    curl check returned "Bad" as well and "mod_headers.c" are present.
    I've rebooted the whole system and now it's all good.
    I guess the httpd didn't restart fully for some reason.

    Thank you all for the help.

    Alex

  16. #16
    Join Date
    Oct 2004
    Location
    London, UK
    Posts
    6,758
    Ok, in case next time try:

    Code:
    killall -9 httpd
    service httpd restart
    Regards
    SeLLeRoNe - Andrea Iannucci
    Head of Managed Service - Senior DevOps Engineer
    If you need my support write me an E-Mail to Support@CrazyNetwork.it

  17. #17
    Join Date
    Sep 2008
    Location
    London UK
    Posts
    1,652
    Quote Originally Posted by dugalex View Post
    I've rebooted the whole system and now it's all good.
    Should not need to reboot - even with Kernel updates (Kernelcare).

    top - 12:20:54 up 305 days, 11:35, 1 user, load average: 0.31, 0.40, 0.33
    Regards, Peter
    UK Web Hosting - Professional & Reliable Shared and VPS Hosting! Offering DirectAdmin licences on our VPS's

  18. #18
    Join Date
    Oct 2004
    Location
    London, UK
    Posts
    6,758
    Peter, matter of couriousity, how do you update a kernel without reboot without using rebootless external systems?

    Regards
    SeLLeRoNe - Andrea Iannucci
    Head of Managed Service - Senior DevOps Engineer
    If you need my support write me an E-Mail to Support@CrazyNetwork.it

  19. #19
    Join Date
    Apr 2005
    Location
    GMT +7.00
    Posts
    12,400

  20. #20
    Join Date
    Oct 2004
    Location
    London, UK
    Posts
    6,758
    Yep, i know about that, that's why i asked without external system.. actually services would be more correct

    Regards
    SeLLeRoNe - Andrea Iannucci
    Head of Managed Service - Senior DevOps Engineer
    If you need my support write me an E-Mail to Support@CrazyNetwork.it

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •