4

A few days ago this new story has been published:

Researchers have found that the HTML feature called hyperlink auditing, or pings, is being used to perform DDoS attacks against various sites. This feature is normally used by sites to track link clicks, but is now found to be abused by attackers to send a massive amount of web requests to sites in order to take them offline.
[…]
In new research by Imperva, researchers have found that HTML pings are being utilized by attackers to perform distributed denial of services attacks on various sites.

The article goes on describing the attack that basically executed some JS to add a link with ping attribute and automatically ”click every second”. It goes on in the same usual way describing that attackers are supposed to have “used social engineering and malvertising to direct users to pages hosting these scripts”.

Strangely it does not mention the victims, but just says these were “gaming companies”.


The question now is, especially considering they have used JS anyway, why did not they just use any other form of requests?

I admin, usual AJAX requests may have been problematic, as the attacked websites likely do not have CORS headers set, so they would have been blocked by the browser as they violate the same origin policy, but usually CORS does not apply to <img tags e.g.… So they could just have used that.

Why did they choose the ping attribute for that, and are they thus more dangerous than other (common) methods for DDoSing?

4
+50

There are some potential benefits of using <a ping>, but they are not unique to <a ping>. It is not outside the realm of possibilities that the attackers simply chose any working method to trigger network requests.

  • <a ping> works when JavaScript is disabled. But in this case the attack started with JavaScript. Even if JavaScript were to be disabled, there are many other ways to trigger a request to an external site, e.g. embedding images and stylesheets.
  • <a ping> requests are background requests. When the user leaves a page, the ping request will not be aborted. In this case, the attack relies on the page being around in order to send a ping every second, so this is probably not the main reason.
  • <a ping> requests' response body is ignored; the browser is allowed to immediately end a connection when a response body is sent by the server. This allows the attacker to carry out the attack with a low impact on the data usage, to make it less likely for the user to notice that their network is being abused.
  • <a ping> responses are not cached, so every ping will result in a request to the server. There are many other cache busting techniques to do so. The fetch API literally has an option to ignore the cache.
  • <a ping> requests are POST requests (and therefore not cached, see the previous point). This allows the same URL to be used. If random URLs were used (as a cache buster), then these may stand out in access logs. However, being a POST request is already somewhat unusual. Besides, these requests are uniquely identifiable by the "Ping-From" and "Ping-To" request header, as well as the more generic "Origin" header for cross-origin requests.

When I saw your question a few days ago, my first thought is "Why would there be a specific reason for doing so?". In the absence of any other probable answers, I guess that the answer is that there is no unique feature that the method provides. As said before, there are other methods with the above benefits, e.g. CSP violation reports, navigator.sendBeacon, fetch. There is nothing special about <a ping>.

The reason why you think that there may be something special to it is because a security firm posted an article about it, with a catchy headline and interesting write-up. Their final paragraph also mentions that these requests can be filtered, and of course they have a product that does it:

Fortunately, web site and application operators have some control. If you are not expecting or do not need to receive ping requests to your Web server, block any Web requests that contain “Ping-To” and/or “Ping-From” HTTP headers on the edge devices (Firewall, WAF, etc.). This will stop the ping requests from ever hitting your server. (Note: Imperva DDoS Protection is already updated to prevent ping functionality abuse targeted at your sites.)

-2

Browsers aren't allowed to cache POST requests per RFC-2616. If the target had If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range headers, this attack wouldn't work with a GET request as the attacking browsers would serve cached content rather than continually hitting the server. A POST vector avoids this limitation.

This is a relatively durable way to ensure that repeated requests to the same URL from the same browser result in new connections to the target, rather than the browser serving cached content to a GET request (as from an <img> tag or similar).

  • It is not. It is actually a full HTTP POST request, and as we know HTTP uses TCP. See the (older) spec for the ping attribute, also see why it is unpopular. – rugk Apr 17 at 21:28
  • Browsers aren't allowed to cache POST requests per RFC-2616. If the target had If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range headers, this attack wouldn't work as the attacking browsers would serve cached content. A POST vector avoids this limitation. – ConsideredHarmful Apr 18 at 16:18
  • Okay, makes sense. Then please do re-write your answer/add a new answer, as the current one comparing it to an udp attack is not really correct… – rugk Apr 19 at 11:54
  • The revised answer is still not a probable answer to the question. One could append a random value to a URL as a cache buster to bypass the cache. – Rob W Apr 20 at 10:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.