WordPress xmlrpc. php Pingback defects and SSRF attacks

Two days ago, I got down because of web2hack.org and analyzed the reason. At that time, I had some ideas and wanted to keep track of them, but it was not clear. Later I found that WordPress was released in the latest version 3.5.1, I 've seen several security issues officially fixed (http://codex.wordpress.org/zh-cn:3.5.1_%E7%89%88%E6%9C%AC), one of which caught my attention:

Server-side request forgery (SSRF) and remote port scanning implemented through Pingback. This vulnerability was fixed by the Wordpress security team.

Tracking down, found this WordPress vulnerability at least a few months ago was widely used, was reported, in the latest release of 3.5.1 version fixed: https://bugzilla.redhat.com/show_bug.cgi? Id = 904120.

The Acunetix WVS Team described this vulnerability in a blog post in last December, which is very clear: http://www.acunetix.com/blog/web-security-zone/wordpress-pingback-vulnerability /.
This blog post shows how to prove whether the vulnerability exists. I used the Composer component of fiddler to simulate the vulnerability. However, the test was incomplete and did not achieve the desired effect, to better understand why the test was like this, I found the WordPress XML-RPC Pingback API: http://codex.wordpress.org/xml-rpc_pingback_api, and there is also a document dedicated to the Pingback 1.0 standard: Release.
There is also a POC written in ruby. The source code is clearer once again. I didn't actually run it. Maybe there are bugs: https://github.com/firefart/wordpresspingbackportscanner.

As for the derived SSRF attacks, Alexander's papers is good:
Https://docs.google.com/document/d/1v1TkWZtrhzRLy0bYXBcdLUedXGb9njTNIJXa3u9akHM/edit #
Http://www.slideshare.net/d0znpp/ssrf-attacks-and-sockets-smorgasbord-of-vulnerabilities
SSRF: this vulnerability can be exploited to send forged requests from the vulnerability server to the target service. The target service can be an Intranet Service and different protocols can be used, and determine whether the attack is successful Based on the echo (if the attack is blind, the echo is not needed :)).

Looking back, this time my SAE yundou was thoroughly refreshed (negative value). Is it the responsibility of SAE as a cloud service vendor? Tens of RMB is useless. Although the vulnerability is WordPress, SAE does not have enough default warning services or security services (Note: Default) and emergency response services, I assume responsibility for this. I guess N more WordPress may have been attacked like this. I initially determined that this type of attack is not targeted, but a large-scale attack, logs exposed by SAE cannot know the specific payload (POST request) of the attack.

If SAE technical personnel see this article, contact me? Http://weibo.com/evilcos.

Update: I know that the chuangyu security research team followed up on this issue in early January, but I did not pay enough attention to it. This time I was engaged and I paid more attention to it :(
Continue update: The head of the team gave me the sample payload for this large-scale attack, which will allow the target server to request the huge iso and directly cause DoS:

POST http://xxxx.com/xmlrpc.php HTTP/1.0 Host: xxxx. comConnection: closeUser-Agent: xmlrpclib. py/1.0.1 (by www.pythonware.com) Content-Type: text/xmlContent-Length: 384 <? Xml version = '1. 0'?> <MethodCall> <methodName> pingback. ping </methodName> <params>... It is not publicly available now... </params> </methodCall>

By knowing the cosine of chuangyu Security Research Team