Check your hoster for Shellshock vulnerability
Due to the “discovery” of the Shellshock vulnerability that has been widely discussed recently (for example, here and here ), and also with the good goal of eliminating the possible unpleasant consequences of exploiting this vulnerability, HostTracker’s site monitoring service provides an opportunity to instantly determine whether this vulnerability exists on Linux servers and installed web server (the result is checked through http).
The algorithm is very simple. We consistently make 4 requests to the server:
1. Normal request.
2. The request, taking advantage of the vulnerability, tries to place a cookie on the scanned server, which will lead to a 2-second delay in the execution of our special http request.
3. The request, taking advantage of the vulnerability, tries to place a cookie on the scanned server, which will lead to a 4-second delay in the execution of our special http request.
4. The same as in p.3.
')
Validation is carried out by trying to place cookies, taking advantage of the vulnerability. Cook causes a delay in processing the http request, first for 2 and then for 4 seconds. Then the result is compared. Here there are 3 options:
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, and also between a 2-second cookie and a 4-second delay. 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 equal time. That is, the cookie could not be placed.
3. Uncertain situation. It may occur if the server is under heavy load, and the response time is constantly jumping. It is not possible to record whether the difference in delay is the result of the activity of a quasi-harmful cookie, or a short-term peak load on the server. To verify 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 presence of a vulnerability.
Our check can not cause damage to the server. All that you risk is the appearance of one “extra” cookie on the server. This cookie is used only for our test request, and it can not cause any delays for work sites.
How it works?
The algorithm is very simple. We consistently make 4 requests to the server:
1. Normal request.
2. The request, taking advantage of the vulnerability, tries to place a cookie on the scanned server, which will lead to a 2-second delay in the execution of our special http request.
3. The request, taking advantage of the vulnerability, tries to place a cookie on the scanned server, which will lead to a 4-second delay in the execution of our special http request.
4. The same as in p.3.
')
What do we have as a result?
Validation is carried out by trying to place cookies, taking advantage of the vulnerability. Cook causes a delay in processing the http request, first for 2 and then for 4 seconds. Then the result is compared. Here there are 3 options:
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, and also between a 2-second cookie and a 4-second delay. 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 equal time. That is, the cookie could not be placed.
3. Uncertain situation. It may occur if the server is under heavy load, and the response time is constantly jumping. It is not possible to record whether the difference in delay is the result of the activity of a quasi-harmful cookie, or a short-term peak load on the server. To verify 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 presence of a vulnerability.
Security check
Our check can not cause damage to the server. All that you risk is the appearance of one “extra” cookie on the server. This cookie is used only for our test request, and it can not cause any delays for work sites.
Source: https://habr.com/ru/post/239137/
All Articles