暴力攻击是如今仍能在互联网上见到的最古老且最常见的攻击类型之一。倘若你有一台在线服务器，它很有可能正在遭受这种攻击。这种攻击可能会通过像SSH或FTP一样的协议进行。当然，如果它是一台Web服务器，这可能会通过基于Web的暴力测试对你任何的CMS进行攻击。
这些攻击往往并不复杂，在理论上很容易缓解并阻止，但它们依然会发生并且能够成功。这主要是因为人们在选择一个较好的密码时都会犯糊涂，或者并没有一个良好的访问控制习惯。简单来说，暴力攻击不太好的地方在于它使得攻击者太过暴露了。习惯上，若想尝试500个不同的密码，攻击者需要进行500次不同的登陆尝试。每一次向服务器发送的请求都代表了攻击者与尝试登陆之间一对一的关系。通过设计登陆过程，攻击者的每一次登陆尝试都会被记录，一旦尝试次数过多就会被阻止登陆，这大大简化了攻击缓解方法。
暴力放大
假如攻击者可以隐藏得更好会怎么样？假如攻击者能够使他和众多登陆尝试之间存在一对多的关系会怎样呢？试想一下，一次请求就能够尝试500个密码的情况。
想象这样一个世界，在这个世界里攻击者以某种方式将暴力攻击放大导致传统的缓解策略失效。不必去请求500次登陆尝试，攻击者可以将尝试次数减小到20或50次，同时能够保证在一次请求中测试了500个甚至上千个密码。正如你所想的，这可能让现有的缓解策略难以奏效。
这有点类似于我们在新闻中听到的DDoS放大攻击，一台单一的服务器可以利用像DNS或NTP协议响应放大的方法来让自身的攻击力提高50或者100倍以上。
任何类型的放大方法都会让攻击者更容易地发动这样的攻击。
通过WordPress的XML-RPC进行暴力放大攻击
XML-RPC中的一个隐藏的特性就是你可以使用system.multicall方法在一次请求中执行多个方法。这是非常有用的，因为它允许应用程序在一次HTTP请求中传递多个命令。
“XML-RPC是一个简单的、可移植的、通过HTTP协议进行远程过程调用的方式。它可用于Perl，Java，Python，C，C++，PHP等多种编程语言。WordPress，Drupal等多数内容管理系统都支持XML-RPC。”
但要记住，任何被用于便利的特性，都有可能在某些地方被用来搞破坏。
这就是XML-RPC发生的事情。
实际上，我们在这几个星期（第一次攻击发生在2015年9月10日）一直在跟踪，这种攻击方式变得越来越流行。攻击者并不针对wp-login.php（它可以很容易地通过.htaccess进行阻止或者保护），他们也不是通过xmlrpc进行单一的密码破解，取而代之的是他们利用system.multicall方法在一次HTTP请求中就能够尝试数以百计的密码。
是的，在一次HTTP请求中就能够进行数以百计的登陆尝试。想想在你的Log文件中看到了这样的情况（你没看错，就这一条）：
194.150.168.95 – – [07/Oct/2015:23:54:12 -0400] "POST /xmlrpc.php HTTP/1.1" 200 14204 "-" "Mozilla/5.0 (Windows; U; WinNT4.0; de-DE; rv:1.7.5) Gecko/20041108 Firefox/1"你会猜到这样的日志是在进行着数百次的密码尝试吗？仅有3个或者4个HTTP请求，攻击者就能够尝试上千个密码，这绕过了旨在发现并阻止暴力攻击的安全工具。
我们看到了大多数攻击者都是利用wp.getCategorie方法进行攻击。这个方法需要提供用户名和密码。请求看起来像这样：
<methodCall><methodName>system.multicall</methodName>
<member><name>methodName</name><value><string>wp.getCategories</string></value></member>
<member><name>params</name><value><array><data>
<value><string></string></value><value><string>admin</string></value><value><string>demo123</string></value>
..
<member><name>methodName</name><value><string>wp.getCategories</string></value></member>
<member><name>params</name><value><array><data>
<value><string>admin</string></value>
<value><string>site.com</string></value>如果有任意一条帐号/密码组合成功，WordPress（XML-RPC）就会做出相应的回应（在这个例子中，攻击者尝试了admin/demo123和admin/site.com密码组合）：
[{‘faultCode': 403, ‘faultString': ‘Incorrect username or password.‘}, {‘faultCode': 403, ‘faultString': ‘Incorrect username or password.‘}, {‘faultCode': 403, ‘faultString': ‘Incorrect username or password.’}, {‘faultCode': 403, ‘faultString': ‘Incorrect username or password.’}, {‘faultCode': 403, ‘faultString': …
[[{‘url': ‘http://site.com/wordpress/’, ‘isAdmin': True, ‘blogid': ‘1’, ‘xmlrpc': ‘http://site.com/wordpress/xmlrpc.php’, ‘blogName': ‘wpxxx’}]]]
尽管我们只看到了wp.getCategories方法，任何需要认证的方法都可以被使用，只是wp.getCategories方法不会对攻击者做过多的限制。这里有一份需要身份认证方法的列表：
wp.getUsersBlogs, wp.newPost, wp.editPost, wp.deletePost, wp.getPost, wp.getPosts, wp.newTerm, wp.editTerm, wp.deleteTerm, wp.getTerm, wp.getTerms, wp.getTaxonomy, wp.getTaxonomies, wp.getUser, wp.getUsers, wp.getProfile, wp.editProfile, wp.getPage, wp.getPages, wp.newPage, wp.deletePage, wp.editPage, wp.getPageList, wp.getAuthors, wp.getTags, wp.newCategory, wp.deleteCategory, wp.suggestCategories, wp.getComment, wp.getComments, wp.deleteComment, wp.editComment, wp.newComment, wp.getCommentStatusList, wp.getCommentCount, wp.getPostStatusList, wp.getPageStatusList, wp.getPageTemplates, wp.getOptions, wp.setOptions, wp.getMediaItem, wp.getMediaLibrary, wp.getPostFormats, wp.getPostType, wp.getPostTypes, wp.getRevisions, wp.restoreRevision, blogger.getUsersBlogs, blogger.getUserInfo, blogger.getPost, blogger.getRecentPosts, blogger.newPost, blogger.editPost, blogger.deletePost, mw.newPost, mw.editPost, mw.getPost, mw.getRecentPosts, mw.getCategories, mw.newMediaObject, mt.getRecentPostTitles, mt.getPostCategories, mt.setPostCategories以下是我们已经看到专门针对XML-RPC的system.multicall方法的攻击图例，这些均属于暴力攻击尝试。请记住，每一次请求都可以表示100次的攻击，而不仅仅是1,000次的帐号/密码暴力尝试。通过一些简单的计算，你就会明白攻击的规模和其潜在的影响。
保护自己
我曾建议人们阻止任何对xmlrpc.php的访问，但这会影响一些插件的功能（尤其是JetPack）。考虑到这一点，如果你没有用到JetPack插件或者任何使用到XML-RPC的插件，阻止外界对它的直接访问可能是一个很好的办法。
如果你不能对XML-RPC做限制，你若是在用着WAF的话，我十分建议在WAF中阻止对system.multicall的请求。这个方法很少被外界调用，阻止它会保护你的应用免受这些放大方法的攻击。
请注意，我们的WAF用户已经受到了保护。因此，如果你在用着CloudProxy，你的应用就是安全的。
文章原文链接:https://www.anquanke.com/post/id/82677
