October 7, 2014 at 09:43Check your host for Shellshock vulnerability
Due to the “discovery” of the Shellshock vulnerability that has been widely discussed recently (for example, here and here ), as well as pursuing the good goal of eliminating the possible unpleasant consequences of using this vulnerability, the HostTracker site monitoring service provides the ability to instantly detect the presence of this very vulnerability on Linux servers and installed web server (checking the result through http).
The algorithm is very simple. We sequentially make 4 requests to the server:
1. Normal request.
2. The request, taking advantage of the vulnerability, is trying to place a cookie on the server being tested, which will lead to a 2-second delay in the execution of our special http request.
3. The request, taking advantage of the vulnerability, is trying to place a cookie on the server being tested, which will lead to a 4-second delay in the execution of our special http request.
4. The same as in paragraph 3.
Verification is carried out by trying to place cookies, using the vulnerability. The cookie delays the processing of the http request, first by 2, and then by 4 seconds. Then the result is compared. There are 3 options here:
1. There is a vulnerability if there is a difference in response time of 2 seconds between a request without a cookie and a request with a cookie causing a 2 second delay, as well as between a 2 second cookie and a 4 second one. That is, our requests managed to exploit the vulnerability and place the cookie.
2. There is no vulnerability - all requests receive a response in approximately the same time. That is, the cookie could not be placed.
3. Uncertain situation. It can occur if the server is under heavy load, and the response time constantly jumps. It is not possible to record whether the delay difference is the result of the operation of a quasi-harmful cookie, or of a short-term peak in the load on the server. To check this situation, we make two consecutive requests with the same delay - the 3rd and 4th. If their result is very different, then the delay is random and does not depend on our cookie (which may not have been recorded at all). In this case, our method cannot determine the existence of a vulnerability.
Our scan cannot damage the server. All you risk is the appearance of one “extra" cookie on the server. This cookie is used only during our test request, and it cannot cause any delays for working sites.
How it works?
The algorithm is very simple. We sequentially make 4 requests to the server:
1. Normal request.
2. The request, taking advantage of the vulnerability, is trying to place a cookie on the server being tested, which will lead to a 2-second delay in the execution of our special http request.
3. The request, taking advantage of the vulnerability, is trying to place a cookie on the server being tested, which will lead to a 4-second delay in the execution of our special http request.
4. The same as in paragraph 3.
What do we have as a result?
Verification is carried out by trying to place cookies, using the vulnerability. The cookie delays the processing of the http request, first by 2, and then by 4 seconds. Then the result is compared. There are 3 options here:
1. There is a vulnerability if there is a difference in response time of 2 seconds between a request without a cookie and a request with a cookie causing a 2 second delay, as well as between a 2 second cookie and a 4 second one. That is, our requests managed to exploit the vulnerability and place the cookie.
2. There is no vulnerability - all requests receive a response in approximately the same time. That is, the cookie could not be placed.
3. Uncertain situation. It can occur if the server is under heavy load, and the response time constantly jumps. It is not possible to record whether the delay difference is the result of the operation of a quasi-harmful cookie, or of a short-term peak in the load on the server. To check this situation, we make two consecutive requests with the same delay - the 3rd and 4th. If their result is very different, then the delay is random and does not depend on our cookie (which may not have been recorded at all). In this case, our method cannot determine the existence of a vulnerability.
Security Checks
Our scan cannot damage the server. All you risk is the appearance of one “extra" cookie on the server. This cookie is used only during our test request, and it cannot cause any delays for working sites.