A pingback is one of four types of linkback methods for Web authors to request notification when somebody links to one of their documents. This enables authors to keep track of who is linking to, or referring to their articles. Some weblog software and content management systems, such as WordPress, Movable Type, Serendipity, and Telligent Community, support automatic pingbacks where all the links in a published article can be pinged when the article is published. Other content management systems, such as Drupal and Joomla, support pingbacks through the use of addons or extensions.
Essentially, a pingback is an XML-RPC request (not to be confused with an ICMP ping) sent from Site A to Site B, when an author of the blog at Site A writes a post that links to Site B. The request includes the URI of the linking page. When Site B receives the notification signal, it automatically goes back to Site A checking for the existence of a live incoming link. If that link exists, the pingback is recorded successfully. This makes pingbacks less prone to spam than trackbacks. Pingback-enabled resources must either use an X-Pingback header or contain a <link> element to the XML-RPC script.
In March 2014, Akamai published a report about a widely seen exploit involving pingback that targets vulnerable WordPress sites.[6] This exploit led to massive abuse of legitimate blogs and websites and turned them into unwilling participants in a DDoS attack.[7] Details about this vulnerability have been publicized since 2012,[8] with Akismet reporting in 2013 that "almost 100% of trackbacks and pingbacks are spam".[9]
The pingback attacks consist of "reflection" and "amplification": an attacker sends a pingback to a legitimate Blog A, but providing information of the legitimate Blog B (impersonation).[10] Then, Blog A needs to check Blog B for the existence of the informed link, as it's how the pingback protocol works, and thus it downloads the page off Blog B server's, causing a reflection.[10] If the target page is big, this amplifies the attack, because a small request sent to Blog A causes it to make a big request to Blog B.[10] This can lead to 10x, 20x, and even bigger amplifications (DoS).[10] It's even possible to use multiple reflectors, to prevent exhausting each of them, and use the combined amplification power of each to exhaust the target Blog B, being by overloading bandwidth or the server CPU (DDoS).[10]
WordPress changed a bit how the pingback feature works to mitigate this kind of vulnerability: the IP address that originated the pingback (the attacker address) started being recorded, and thus shown in the log.[11] Notwithstanding, in 2016, pingback attacks continued to exist, supposedly because the website owners don't check the user agent logs, that have the real IP addresses.[11][10] If the attacker is more than a script kiddie, he will know how to prevent his IP address being recorded, by, for example, sending the request from another machine/site, so that this machine/site IP address is recorded instead, and the IP logging then, becomes less worthy.[12] Thus, it's still recommended to disable the pingbacks, to prevent attacking other sites (although this does not prevent being target of attacks).[11]
See also
Weblogs.com, an earlier XML-RPC interface for weblogs to send pingbacks.
Webmention, a modern re-implementation of Pingback using HTTP and x-www-urlencoded POST data.
Linkback, the suite of protocols that allows websites to manually and automatically link to one another.
Refback, a similar protocol but easier than pingbacks since the site originating the link doesn't have to be capable of sending a pingback.
Trackback, a similar protocol but more prone to spam.
^ abcdefKrassi Tzvetanov (May 4, 2016). "WordPress pingback attack". A10 Networks. Retrieved 2 February 2017. This issue arises from the fact that it is possible for an attacker A to impersonate T's blog by connecting to R's blog and sending a link notification that specifies T's blog as the origination of the notification. At that point, K will automatically attempt to connect to T to download the blog post. This is called reflection. If the attacker were careful to select a URL that has a lot of information in it, this would cause amplification. In other words, for a relatively small request from the attacker (A) to the reflector, the reflector (R) will connect to the target (T) and cause a large amount of traffic. [...] On the reflector side for the 200-byte request, the response can easily be thousands of bytes – resulting in a multiplication that starts in the 10x, 20x and more. [...] To avoid overloading the reflector, multiple reflectors can be employed to scale up. Thus, the target will have their outgoing bandwidth, and possibly compute resources, exhausted. [...] Another point to consider is the compute resources tied to the target side. If considering a page that is computationally expensive to produce, it may be more efficient for the attacker to overload the CPU of a system versus the bandwidth of the connection. [...] This is not the first time a CMS, and in particular WordPress, has been used for DDoS or other malicious activity. To a very large extent, this is because WordPress appeals to users that do not have the resources to manage their websites and they often use WordPress to make their job easier. As a result, many users do not have an adequate patch management program or proper monitoring to observe irregularities in their traffic.
^ abcDaniel Cid (February 17, 2016). "WordPress Sites Leveraged in Layer 7 DDoS Campaigns". Sucuri. Retrieved 2 February 2017. Starting in version 3.9, WordPress started to record the IP address of where the pingback request originated. That diminished the value of using WordPress as part of an attack; the platform would now record the attackers original IP address and it would show up in the log user agent. [...] Despite the potential reduction in value with the IP logging, attackers are still using this technique. Likely because website owners rarely check the user agent logs to derive the real IP address of visitors. [...] Although it is great that WordPress is logging the attacker IP address on newer releases, we still recommend that you disable pingbacks on your site. It won't protect you from being attacked, but will stop your site from attacking others.
^Tim Butler (25 Nov 2016). "Analysis of a WordPress Pingback DDOS Attack". Conetix. Retrieved 2 February 2017. One enhancement WordPress added to the pingbacks in 3.7, which at least tracked the originating IP of the request. While this doesn't solve the problem, it at least allows you to trace where the calls are coming from. Unless the attacker is very, very naive however, this IP will simply trace back to another infected machine or site. Generally these requesting systems are part of a botnet to mask and distribute the requests. [...] The pingback tool within WordPress still remains an exploitable system for any WordPress site which hasn't explicitly stopped it. From a web host's perspective, this is quite frustrating.
