-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
What is Jackhammer 1.2?
Jackhammer 1.2 ( sometimes called Jackhammer 2.0 ) was developed in 2003 by Mike Parniak ( Archon ) from TheBlackHand / Cafe Counterintelligence in response to CCISecurity script he released that blocked attacks from Jackhammer 1.0
Jackhammer is a MS Windows only, layer 7 attack application that also allows attackers to use multiple anonymous proxies to distribute the perceived point of origin of an attack across as many proxies as an attacker desires or is able to use, therefore masking the originating IP address of the attacker.
Attackers are able to choose from a number of attack strategies allowing them to tweak the exact type of attack that Jackhammer performs as well as optimising the overall data transfer, i.e 10,000 proxies x 0.1 ms = 1 request per 1000 seconds per proxy.
While Jackhammer is an old application, it’s attack method is still very relevant today as it was in 2003. With the advent of flood protection services such as Cloudflare, Jackhammer attacks are easily thwarted, but without employing such services, webservers are still quite vulnerable to the attacks that can be delivered via Jackhammer.
Jackhammer 1.2 Connection Strategies:
* Disconnect after Response Code: On this setting, Jackhammer only reads the first 12 bytes of the webserver’s response, in order to get it’s HTTP response code. This is mostly used in conjunction with the “Disable proxies on Bad Response Code” option. It lets Jackhammer detect if a proxy has been banned (403 code) or similar, and thus disable now-useless proxies during a flood.
* Disconnect on any data received: As soon as data is received from the proxy server, indicating a response to Jackhammer’s request, Jackhammer destroys the socket to avoid further data (minimizing received data, but ensuring that the proxy is responding).
* Hold connection until disconnected: This setting has Jackhammer sit on the socket and not disconnect it. Only if Jackhammer needs to create a new socket and is maxed out, or if the remote host disconnects it, will Jackhammer destroy a socket. This setting is often best used in conjunction with a slow speed to run a webserver out of connections.
* Disconnect after data sent: A low-bandwidth lifesaver. This option causes Jackhammer to disconnect immediately after successfully sending all the header data to the proxy. Tests have shown that the proxy will still deliver the request to the target server before disconnecting. This means it is a good option to use against scripts, but a poor option against large files.
* Incremental List Segments: If an attacker has a large list of proxies, and are worried that the website they are flooding may ban the proxies they use as they’re flooding… attackers can have it only use pieces of the proxy list at a time.
* Get and use initial cookies: One of the other powerful options on Jackhammer is the ability to get and store the cookies that websites return, and pass them along on future connections. If an attacker enables this option then the first time each proxy performs a request, Jackhammer waits for the full response header and records all the cookies. From this point on, it adds a cookie: line with those cookies to all requests from that proxy.
* Get, use, and keep cookies updated: This option only works if the attacker also has the above option enabled. Instead of just waiting for the first set of cookies, Jackhammer will always read the full header and update the cookies accordingly.
An attacker can use these combinations of attacks to simulate expected traffic but at such a scale as to cause a denial of service condition, and in some cases, with little bandwidth consumption.
Example Low Bandwidth GET Request Attack:
For example where a CMS creates and database stores guest cookie sessions in this manner:
$guesthash = sha1( $_SERVER[ 'HTTP_USER_AGENT' ] . $ip );
Attack Method: Disconnect after data sent
GET http://attackvictim.com/?%%ALPHANUM[4,10]%%=%%ALPHANUM[4,10]%% HTTP/1.1
Accept: */*
Host: %%HOST%%
User-Agent: Mozilla/4.0 %%ALPHANUM[4,10]%%
X-Forwarded-For: %%IP%%
Then the above attack request method would quickly fill a database with junk guest sessions and in many cases overwhelming the database with very little data sent due to the ability to customise the user-agent with every request.
Add to that the ridiculously shitty way for example in which vBulletin determines the real IP address of a visitor in its fetch_alt_ip() function ( includes/class_core.php ), it is even possible to spoof the IP address with every request as well.
Resource Intensive Request Attacks:
Because Jackhammer allows for custom HTTP header requests, an attacker will often look for the most CPU/memory intensive, and/or bandwidth intensive request as their choice of attack.
POST Requests: these are cpu intensive and the favourite of attackers. Unprotected forms are the usual target and a flood attack of even a few requests per second can overwhelm a webserver.
Especially forms that result in an email, or emails being sent, can also result in both a servers resources being overwhelmed as well as a bandwidth attack as mass amounts of emails are generated from each POST request.
However there are other POST requests that can overwhelm a server even without a waiting form.
For example versions of PHP earlier than 5.4 were very susceptible to blind post request attacks where the post data generates a large multidimensional array:
i[]=1&i[]=2&i[]=3&i[]=4....i[]=1000
GET Requests: often targeted at site features like search functions where a search request results in a database intensive request which repeated in quick succession can quickly overwhelm a database server resources.
Example GET request of a search function using wild cards:
GET http://attackvictim.com/?search=a*&%%ALPHANUM[4,10]%%=%%ALPHANUM[4,10]%% HTTP/1.1
Accept: */*
Host: %%HOST%%
User-Agent: Mozilla/5.0
Client-IP: %%IP%%
GET request attacks targeting large files can also result in a bandwidth attack sufficient enough to cause a denial of service request condition.
Mitigation:
How to mitigate Jackhammer type attacks ( in this example using PHP and optionally javascript ) without ceding to the likes of Cloudflare, or other captcha services/methods:
One approach to mitigate an attack from tools like Jackhammer is to enumerate the ways in which these tools fail to emulate a standard browser as a means of detecting them as the source of an HTTP request.
Most layer 7 HTTP request attack tools cannot interpret javascript so therefore it is possible then for a server to ask a complex javascript initiated question that a standard browser with javascript enabled would be able to answer.
For example you could write a piece of javascript to set a session which a standard web browser would have no trouble completing but an attack tool like Jackhammer could not.
Javascript though for some web admins is not preferable.
The usual method is to set a session based IP management to count requests per a period of time and restrict IP addresses that break these rules.
A Jackhammer attack is often mistaken as a botnet attack because Jackhammer allows an attacker to deploy multiple proxies.
An attacker with a very large proxy list can deliver a sizeable attack even against rate-limiting algorithms because of the time it would take for Jackhammer to toggle through a very large list.
The time between the first and second request from a specific proxy IP address of an attacker employing say 10,000 anonymous proxies could be 5 minutes.
Combined with javascript as noted above, will very likely prevent an attack from proceeding.
Lastly it is important to prevent direct access to large files on a server, and it is preferred to pipe a file via session based access which are subject to the same browser emulation requirements stated above.
Download Jackhammer 1.2 for testing purposes only: https://mega.nz/#!fII2BKpZ
Decryption key: !CEFrXPHEbzFD2XdxIbpRRdhJjCHd1AifiCc256LwB3I
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJX+K8+AAoJEL7YCbL0gxCTWL8P/3p3ElE9GWK+V2qQ5g0tr6Hf
aDqckNs2mKDcDJuBMnyfH//xeDSQJSAPmlwmV/1NINrvNSJsxb9kuIm8Z44arThB
wduEilbzeQZkbeVIoXT5n/XiT9PbVo5hsdaMmjCYtOtDQZ2xXcwiYUXVdhdjSxOa
GQdt9d9s/BwJem8T4QXAY594PxGMynGi2zpFWqEkxsaM5c9RN3loFpNpsQkoPHha
uAEIYfN7zoAafPzRZ6qdI1oXoaJWFpyQbEZjXBRvWyonJMzuWCs3zWA+3sQXNz9o
XbJTqmYmq2wqmdZK1ruGEJaourUatMTz1zOx+bkxzvLITeVJ/0xftLcIX5H2YDx9
poavS7cS7neFXTBrc1X0aisK5chA/glz9zQZ4qsHJmQirfCOJqN0UgilKNi34Ntu
Nts6e90JglKN40+6qqcp0/vDXkBsc3KqG1Rl42Fw9XOpciBJHmbNKg/dRvR+01dp
YqO+l6TEH2IVHBZfAjvxagjOSZhbP5ctu6kj2R1BYvLmdo4NHGyQwFKWjj9D8rOX
RGCkkoBOctpRx2FblyrPvqeG2MEzvbHJZ+mMnbl4aKAhzRuVDyXxbv8p8lP0UzSz
PepGmLXW5kV02uo6Jzw73kYr7IPo3AErr3kpcsmhcFHJPqU9NZqCqqoXfkE+h48g
2T+GwXOKAu98Z8u+AZ1T
=0wyT
-----END PGP SIGNATURE-----