Brute Force Amplification Attacks Against WordPress XMLRPC
Brute Force Amplification Attacks Against WordPress XMLRPC
Brute Force attacks are one of the oldest and most common types of attacks that we still see on the Internet today. If you have a server online, it’s most likely being hit right now. It could be via protocols like SSH or FTP, and if it’s a web server, via web-based brute force attempts against whatever CMS you are using.
Imagine a world where an attacker could amplify their Brute Force attacks in such a way that traditional mitigation strategies fall short. Instead of 500 different login attempts, the attackers could reduce their login attempts to say 20, or 50 and still try 500 or even thousands of passwords to each request. As you might imagine, this begins to make your mitigation strategy a bit harder to employ.
One of the hidden features of XML-RPC is that you can use the system.multicall method to execute multiple methods inside a single request. That’s very useful as it allow application to pass multiple commands within one HTTP request.
XML-RPC is a simple, portable way to make remote procedure calls over HTTP. It can be used with Perl, Java, Python, C, C++, PHP and many other programming languages. WordPress, Drupal and most content management systems support XML-RPC. Read original article here….
When administering a busy multi user WordPress or WordPress multisite blog or website, it is vital to monitor content changes to ensure the integrity of the content, the website’s reputation and also to ensure that no malicious hacker is tampering the content with malicious code and malware.
Reading between the lines, the truth of the matter is that the vast majority of holes in the CMS code base, whichever platform you look at, have been found and fixed over the years. Kolochenko actually reckons that 99% of exploitable vulnerabilities in core CMS code fall into this category. So, CMS usage is pretty safe now then? Well, yes, but not 100% so and admins are partly to blame here. Weak passwords and password reuse are right up there at the top of the insecurity tree, along with social engineering attacks against CMS administrators. The compromise crown has to be placed upon the head of XSS vulnerabilities in plugins, made effective because of both the previous weaknesses.
