Pingback

Pingback — это один из четырёх методов уведомления веб-авторов, когда кто-либо ссылается на их документ. Это даёт авторам возможность проследить, кто делает ссылку или ссылается на их статьи. Движки некоторых веб-блогов, таких как Movable Type, Serendipity, WordPress, и Telligent Community, поддерживают автоматические pingback’и, то есть все ссылки в опубликованной статье могут быть «запингованы» после публикации статьи. Ряд продвинутых систем управления контентом поддерживают pingback через аддоны или расширения, например Drupal и Joomla.
В общих чертах, pingback — это XML-RPC запрос, отправленный с одного сайта на другой, когда автор блога на первом сайте написал сообщение в котором ссылается на второй сайт. Чтобы это сработало, требуется также гиперссылка. Когда второй сайт получает подтверждающий сигнал, он автоматически идёт на первый сайт и проверяется существование внешней ссылки. Если эта ссылка существует, pingback успешно записывается. Это делает pingback менее подверженным спаму, чем trackbacks. Источники, которые поддерживают pingback, должны использовать или заголовки X-Pingback или содержать элемент <link> в скрипте XML-RPC.

Достижения править

В марте 2014 года Akamai опубликовал отчет о широко распространенном эксплойте с участием Pingback, который нацелен на уязвимые сайты WordPress^[1]. Этот эксплойт привел к массовому злоупотреблению законными блогами и веб-сайтами и превратил их в нежелательных участников DDoS-атак^[2]. Сведения об этой уязвимости публикуются с 2012 года^[3].

Атаки pingback состоят из «отражения» и «усиления»: злоумышленник отправляет pingback в законный блог A, но предоставляет информацию о законном блоге B (олицетворение)^[4]. Затем блог А должен проверить блог B на наличие информированной ссылки, это то, как работает протокол pingback, и, таким образом, он загружает страницу с сервера блога B, вызывая отражение^[4]. Если целевая страница большая, это усиливает атаку, потому что небольшой запрос, отправленный в блог А, заставляет его сделать большой запрос в блог B^[4]. Это может привести к 10x, 20x, и ещё большим усилениям (DoS)^[4]. Даже возможно использовать множественные рефлекторы, предотвратить вымотывать каждое из их, и использовать совмещенную силу амплификации каждого вымотать блог Б цели, перегружающий ширину полосы частот или К. п. у. сервера (DDoS)^[4].

Wordpress немного изменил, как работает функция pingback, чтобы смягчить такую Уязвимость: IP-адрес, который инициировал pingback (адрес атакующего), начал записываться и, таким образом, отображался в журнале^[5]. Несмотря на это, в 2016 году атаки pingback продолжали существовать, предположительно потому, что владельцы веб-сайтов не проверяют журналы агента пользователя, которые имеют реальные IP-адреса^[5]^[4]. Следует отметить, что если злоумышленник-это больше, чем скрипт кидди, он будет знать, как предотвратить его IP-адрес записывается, например, отправив запрос с другой машины/сайт, так, что этот IP-адрес машины/сайта записан вместо этого, и регистрация IP тогда, становится менее достойной^[6]. Таким образом, по-прежнему рекомендуется отключать pingback’и, чтобы предотвратить атаку на другие сайты (хотя это не мешает быть мишенью атак)^[5].

См. также править

Примечания править

↑ Brenner, Bill Anatomy of Wordpress XML-RPC Pingback Attacks (неопр.). The Akamai Blog, March 31, 2014 5:42 AM. Дата обращения: 7 июля 2014. Архивировано 8 августа 2018 года.
↑ Cid, Daniel More Than 162,000 WordPress Sites Used for Distributed Denial of Service Attack (неопр.). Sucuri Blog, March 10, 2014. Дата обращения: 7 июля 2014. Архивировано 12 июля 2014 года.
↑ Calin, Bogdan WordPress Pingback Vulnerability (неопр.). Accunetix, December 17, 2012 - 01:17pm. Дата обращения: 7 июля 2014. Архивировано 14 июля 2014 года.
↑ ¹ ² ³ ⁴ ⁵ ⁶ Krassi Tzvetanov. WordPress pingback attack (неопр.). A10 Networks (4 мая 2016). — «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.» Дата обращения: 2 февраля 2017. Архивировано 4 декабря 2017 года.
↑ ¹ ² ³ Daniel Cid. WordPress Sites Leveraged in Layer 7 DDoS Campaigns (неопр.). Sucuri (17 февраля 2016). — «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.» Дата обращения: 2 февраля 2017. Архивировано 8 августа 2018 года.
↑ Tim Butler. Analysis of a WordPress Pingback DDOS Attack (неопр.). Conetix (25 ноября 2016). — «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.» Дата обращения: 2 февраля 2017. Архивировано 8 августа 2018 года.

Ссылки править

Documentation: Trackbacks / Pingbacks in Serendipity
WordPress Codex specifications
Pingback Specifications Архивная копия от 5 декабря 2020 на Wayback Machine

[1] Brenner, Bill Anatomy of Wordpress XML-RPC Pingback Attacks (неопр.). The Akamai Blog, March 31, 2014 5:42 AM. Дата обращения: 7 июля 2014. Архивировано 8 августа 2018 года.

[2] Cid, Daniel More Than 162,000 WordPress Sites Used for Distributed Denial of Service Attack (неопр.). Sucuri Blog, March 10, 2014. Дата обращения: 7 июля 2014. Архивировано 12 июля 2014 года.

[3] Calin, Bogdan WordPress Pingback Vulnerability (неопр.). Accunetix, December 17, 2012 - 01:17pm. Дата обращения: 7 июля 2014. Архивировано 14 июля 2014 года.

[A10_2016-4] ¹ ² ³ ⁴ ⁵ ⁶ Krassi Tzvetanov. WordPress pingback attack (неопр.). A10 Networks (4 мая 2016). — «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.» Дата обращения: 2 февраля 2017. Архивировано 4 декабря 2017 года.

[Sucuri_2016-5] ¹ ² ³ Daniel Cid. WordPress Sites Leveraged in Layer 7 DDoS Campaigns (неопр.). Sucuri (17 февраля 2016). — «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.» Дата обращения: 2 февраля 2017. Архивировано 8 августа 2018 года.

[Conetix_2016-6] Tim Butler. Analysis of a WordPress Pingback DDOS Attack (неопр.). Conetix (25 ноября 2016). — «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.» Дата обращения: 2 февраля 2017. Архивировано 8 августа 2018 года.

[1]

[2]

[3]

[4]

[5]

[6]