Http Proxy Attack Threat Analysis

Case Study

I had a very good incident security response case before, the process of that resolution is really smooth. However, there have been some problems in the reproduction of the environment that time and the usage of this vulnerability in the penetration test. It has been studied intermittently for several days before the analysis is completed.

Let me talk about this incident security case. It happened in the afternoon of the same day. However, I received the call only at about 9:30 PM. Then the customer pulled all of the project team and the major leaders to explain the seriousness of the incident in the group, and ask for full support, then the technicians at the first line dumped the access.log of the problematic Apache server and transferred it to me. Then they told me that the server hacked has two phenomena:

1. The Apache server access.log log yielded a lot of abnormal logs;
2. The efficient of the server is degraded and the memory usage is unusually high.

After getting the screenshot of the access log, a lot of abnormal third-party domain names which do not belong to the local legal domain name set from this access.log can be detected. And most of these responses show that the status code is 200. Some of the status codes are 404 for that the website is actually inaccessible.

At first, I thought the strange log record means that hacker exploit URL redirect vulnerability. The access tests on these third-party domain names are basically some gambling websites or some daily entertainment sites, some live broadcast. Basically, the attacker’s purpose should be to conduct a kind of attack which leads the advertisement traffic and earn traffic fees. Such kind of performance is usually considered as black industry in the domain of cybersecurity. When I focused on the source IP of the log record and found it to be an intranet IP address 10.x.x.x, and then I fell into meditation. Is this attacker stupid? Since he has already got permission to control the intranet server, shouldn't he indirectly access it from another intranet server? However, based on the facts after, the idiot is me at all : (

From my erroneous analysis, the analysis above is contradictory. What has been ensured is that the target of hackers is to perform a kind of black industry action to gain fees but what experience told me that these kinds of actions always exploit vulnerabilities which have two key attributes: high-risk and portable, such as struts2. This attacker does not willing to spend much of time on difficult penetration test.

Then I compared this file with the normal access log and find that the requests log records in normal access log does not contain the HTTP protocol header and domain name fields but only the URL path. At this time, I discovered that things are not in a easy way.

After another analysis, it was discovered that this is an event that hackers use the proxy function of the middleware to conduct a malicious proxy attack. This means that the Apache server is used as an intermediate proxy to let hacker access other sites from the current website. Such performance causes the abnormal logs.

Basically, the motivation of the hackcers has been found but there is still a problem left, that is why the source IP of these requests is 10.x.x.x? Before asking to the customer engineers I do a guess that the IP might be a machine that acts as a reverse proxy, and it is probably a WAF in the DMZ zone and it is nine of ten Apache. And it is, actually.

Here is a brief conceptual narrative of the four deployment methods of WAF.

There are four deployment methods for WAF:

1. Tandem deployment. The most common deployment method which increases the capability of the load of WAF but problems easily encounter in the condition of P2P;
2. Bypass deployment. It requires traffic lead between Layer 2 or Layer 3. The deployment is complex but the load of WAF can be reduced and so that the utilization efficiency is improved. Only Web-related traffic can be forwarded under this kind of deployment.
3. Reverse proxy deployment. The communication between the client and the server is opaque. The external IP is the public IP address of the WAF. After receiving the request, the WAF will replace the request source IP address with its own IP address and initiate a request forwarding to the intranet part.
4. Mirror monitor deployment. It can only detect whether the service is attacked without producing protection of the customer business;

The actual network architecture of the case and the attack path analysis of the attacker are as shown in the following figure:

After painting this picture, I felt that there was a problem I missed up. Scroll the chat history with the customer and I found the problem is that I can only trace the source to see why there is a strange log. On the contrary, the degradation and high memory usage of the server cannot be clarified. I have never encountered before this kind of malicious proxy attack but I have encountered and actually manually operated another attack mode using the same form, that is CC (Challenge Collapsar) attack.

CC attack is to use multiple zombies to perform multi-threaded HTTP proxy servers to launch a large number of real HTTP requests to the target server, which consumes a large number of concurrent resources and results in denial of service attack (DoS). However, in the general CC attack, we often only focus on the attacked victim but those zombies which actually face the same resource consumption problem, and their memory will be consumed, too. Those who haven't done the actual CC attack may think that those zombies really need a proxy server getshelled. In fact, the actual operation of CC attacks is often to obtain server IP from the platform on the Internet. The list containing IP and port of a large number of proxy servers are updated every day and released for users. The CC attack is often launched by hackers from dumping directly these proxy IP ports and loaded into the List module of the CC attack tools.

Type of Proxy

What usually results in this kind of HTTP proxy attack is forward proxy. Hackers can access another website using the middleware as passing way. Except for the forward proxy, reverse proxy and transparent proxy are well-known as well.

Fix it!

1. Turn off the swtich of the forward proxy.

Configure module mod_proxy of Apache in a safe way. Revise the value of the ProxyRequets to value off in the file http.conf to turn off the function.

2. After turning off the forward proxy, the test results show that it can only help to forbid some of the requests via proxy. What needs to be done is to configure the file .htaccess as well. Make it possible in a two-pronged approach.

File .htaccess

RewriteEngine on //Enable rewrite engine.

RewriteBase / //Set Base address, / is the root directory.

RewriteCond %{HTTP_HOST} example.com [NC]

//Set a whitelist of domain names. Set flag to NC which means allow these domain names can be forwarded.

RewriteRule ^(.*)$ <http://www.example.com/>$1 [NC]

//Set the regex of the URL address. Set flag to L,R=301 which means that if the status code was 301, the request would be redirected.

RewriteCond %{HTTP_HOST} <www.example.com> [NC]

RewriteRule ^(.*)$ <http://www.example.com/>$1 [NC]

RewriteRule ^(.*)$ - [F]

//Set regex to match all because of sequential match so that the regex will match all of the illegal domain names. Set flag to F which measn 403 Forbidden.

Enable .htaccess.

A) Enable mod_rewrite

LoadModule rewrite_module modules/mod_rewrite.so

B) Set AllowOverride None to AllowOverride All

# AllowOverride controls what directives may be placed in .htaccess files.

# It can be "All", "None", or any combination of the keywords:

# Options FileInfo AuthConfig Limit

C) Configure vhost and add some cnfigurations of Option to the directory of the web server like following

<VirtualHost *:80>

ServerName sf2.aonola.com

DirectoryIndex app.php

DocumentRoot /www/sf2_aonola_com/web //main directory

`<Directory " /www/sf2_aonola_com/web">

\# Options Indexes FollowSymLinks

\# Options -Indexes IncludesNOEXEC -ExecCGI FollowSymLinks

Options FollowSymLinks

AllowOverride All

Order allow,deny

Allow from all

</Directory>

</VirtualHost>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

Forbid unsafe HTTP method. In principle, GET method and POST method are only allowed to be enabled. Specifically, it is essential to cancel CONNECT method.

Restart the server to enable all above strategies.

Of course, all of the above operations are considered as temporary resorts because these the requests via proxy are forbidden by setting status code to 403. It cannot figure out the problem of high load of the server.

Terminal Solution: WAF, of course!

Penetration Test

5 types of penetration test have been analyzed. The following article will focus on the nse script of nmap and the rb script of Metasploit.

1. nmap script test ( on the platform of Windows)

Analyze the HTTP proxy test using script http-open-proxy which is the script file http-open-proxy.nse in the file of /nmap/scripts.

When open this NSE file it shows us how the nmap script in the code run and achieve the scanning purpose.

From the simple description in the first part of the script, we can see that this script is used to test whether the HTTP proxy is open. When paying attention to the detailed description, it shows that the script also tests whether the HTTP proxy can access Google, the response code is not limited to 200, 301 and 302. Chinese friends will have some trouble using it. However, carefully research the following code and find that it is not only Google to be the test site, but also the official website of Wikipedia and Computer history. Unfortunately, visits from China are either inaccessible or slow in network status.

But nmap takes this into account as well. In the description of @usage, we see that it added in addition to the basic nse usage method, which is --script http-open-proxy, which is updated in 2009-05-14. Joao Correa added a parameter scheme for custom proxy.url for us.

So in the global code, we see two basic functions, one is custom_test() and the other is default_test(). From the parameter acquisition, we can see that function custom_test () requires the supplied value of host, port, test_url, pattern, and default_test () requires the host and port provided, fully in line with the description in the usage.

Since the basic test form is the same, the only difference is that the function default_test() has fixed url and pattern parameters as default values. So we only analyze the implementation of the function custom_test() here.

First, the function defines two return values ​​needed to be fed back to the user, lstatus and response. Initialize lstatus to false, and finally assign the value to true as long as HTTP proxy is open. Then initialize the various entry parameters, such as hostname, port, test_url, etc. The user input value passed in test_url is also processed. If the user input does not add http://, the protocol header will be automatically added to the parameter.. Then start to execute the program body, call the proxy property method, use the get proxy request method, the head proxy test method and the connect channel proxy method to test, and use the response code of repsonse to determine whether it is valid.

Since the difference between the three methods is only the type of HTTP method. So the following article will only use the test_get() method as an example to analyze. Trace the function test_get(). Since it is a property method belonging to the function proxy, go to the definition of the function proxy and search for it. Locate the proxy.lua and find the function test_get().

First, we locate the function connectProxy() and find that it is actually a simple socket connection, and the socket connection here is a different type of connection through the proxyType specification and returns the results to function custom_test(). It is found that all three test functions specify the proxyType as "http" type, so there is no need to test the sock4 and sock5 test methods here. And the test method constructs a simple request to send a request, the status code can be used as a value to judge whether the proxy is turned on. In fact, the key to establishing a socket process are porxy parameters.

Though the script function matches its name. There must be another script for the HTTP proxy test since the socks proxy connection is defined here, there must be a test script for the socks proxy. And yes, it is socks-open-proxy.

The basic method of socks-open-proxy is the same as http-open-proxy. It is also the function custom_test() and the function default_test(), so it is also possible to customize the test URL. As with the previous analysis, the only difference is proxyType covering socks4 and socks5.

Summary produces the testing command:

nmap 192.168.1.1 --script http-open-proxy socks-open-proxy --script-args proxy.url=www.baidu.com

2, the auxiliary/scanner/http/open_proxy module of metasploit

Let's take a look at the simple description of the msf interface: HTTP Open Proxy Detection, which basically has the same starting point as the script function of nmap.

First call this module to see the options belonging to the user input category.

It can be seen that the module of msf also supports customize checkurl, and provides custom test tags, namely status code and matching mode. It also supports verify the practical of CONNECT channel proxy method. So you can see that from the user-defined perspective, msf is more user-friendly than nmap. But basically it is similar to nmap, why do you say that because hmmm...

Then an analysis of the module's method implementation, the first part is an initialization method, in fact, that is the value assignment which is similar to the previous contents of options.

The second function is run_host() which contains the custom user input. The function verify_target() of the execution body calls the function send_request_cgi() to get the response used to process to determine whether the proxy is open. Judging that there are 3 points in total: there is no response to judge whether there is any proxy; It is only judged by the status code or the matching pattern in the response data; the existence of CONNECT channel proxy is only judged by the status code.

In fact, the focus of the body is on the function send_request_cgi(). Check the global include to determine whether function Msf::Exploit::Remote::HttpClient is included. Locate the implementation script of this function: /opt/metasploit-framework /embedded/framework/lib/msf/core/exploit/http/client.rb. Well, actually it can be located by the command grep.

What has been found in the body part of the function send_request_cgi() is in the following figure. So in the next step, we need to locate the function connect() and figure out what the purpose of usage of the parameter request_cgi.

The function connect() will judge the SSL protocol first and then connect the remote HTTP server. It shows that the parameter opt is actually the value of the address of remote host, that is the value transferred by parameter check_url.

Trace to the function request_cgi() in the path /opt/metasploit-framework/embedded/framework/lib/rex/proto/http/client.rb, the nature of this function is to definite the parameter and connected by the client.

The overall code structure of this client.rb is similar to the previous one but it is more detailed. You can see that 8 parameter values are imported in the function connect() in the body of function initialize(). In fact, this architecture of the script is also a layer of socket connection giving its proxy parameters. Theotically it is similar to nmap.

3. Practical Tools

Needs to be run as administrator.

4. Online Test

http://web.chacuo.net/netproxycheck

5. The file httpd.conf and other related security configuration file need white box testing before the deployment (baseline review) .