Attackers exploit the WordPress XMLRPC vulnerability to exploit the vulnerability.

Attackers exploit the WordPress XMLRPC vulnerability to exploit the vulnerability.
Violent attacks are one of the oldest and most common types of attacks on the Internet. If you have an online server, it is likely to be under such attacks. This attack may be performed through protocols like SSH or FTP. Of course, if it is a Web server, it may attack any of your CMS through Web-based brute force testing. These attacks are often not complex and theoretically easy to mitigate and prevent, but they still happen and can succeed. This is mainly because people are confused when choosing a better password, or they do not have a good access control habit. To put it simply, the bad thing about a violent attack is that it exposes attackers too much. Traditionally, To Try 500 different passwords, attackers need to perform 500 different login attempts. Each request sent to the server represents a one-to-one relationship between the attacker and the attempted login. By designing the login process, attackers can log every login attempt. Once too many attempts are attempted, the login will be blocked, which greatly simplifies the attack mitigation method. Brute force amplification what If attackers can hide better? What if an attacker could have a one-to-many relationship with multiple login attempts? Think about the situation where 500 passwords can be tried in one request. Imagine a world in which attackers may, in some way, scale up violent attacks, leading to ineffective traditional mitigation policies. You do not have to request 500 login attempts. Attackers can reduce the number of attempts to 20 or 50, and ensure that 500 or even thousands of passwords are tested in one request. As you think, this may make the existing mitigation strategy ineffective. This is a bit similar to the DDoS amplification attack we heard in the news. A single server can use methods like DNS or NTP protocol to increase its attack capability by 50 or more times. Any type of amplification method makes it easier for attackers to launch such attacks. One of the hidden features in the XML-RPC of WordPress's brute force amplification attack XML-RPC is that you can use the system. multicall method to execute multiple methods in one request. This is very useful because it allows an application to pass multiple commands in an HTTP request. "XML-RPC is a simple, portable, Remote Procedure Call method over HTTP. It can be used in Perl, Java, Python, C, C ++, PHP, and other programming languages. Most content management systems such as WordPress and Drupal support XML-RPC ." However, remember that any feature used for convenience may be used for damage in some places. This is what happens to XML-RPC. In fact, we have been tracking for the past few weeks (the first attack occurred in September 10, 2015), and this attack method has become increasingly popular. Attackers are not targeting wp-login.php (it can easily pass through. htaccess is blocked or protected). Instead of using xmlrpc to crack a single password, they use system. the multicall method can try hundreds of passwords in an HTTP request. Yes, hundreds of login attempts can be made in an HTTP request. Think about the situation you see in your Log file (if you have not read the error, this one): 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 "would you have guessed that this log was being used for hundreds of password attempts? With only three or four HTTP requests, attackers can try thousands of passwords, bypassing the security tools designed to detect and prevent brute-force attacks. We can see that most attackers use the wp. getCategorie method to launch attacks. This method requires the user name and password. The request looks like this:

<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>

If any account/password combination is successful, WordPress (XML-RPC) will respond accordingly (in this example, the attacker tried the admin/demo123 and admin/site.com password combination ): [{'defaultcode': 403, 'defaultstring': 'increct username or password. '}, {'faultcode': 403, 'faultstring': 'recordct username or password. '}, {'faultcode': 403, 'faultstring': 'recordct username or password. '}, {'faultcode': 403, 'faultstring': 'recordct username or password. '}, {'faultcode': 403, 'faultst Ring ':... [[{'Url ':' http://site.com/wordpress/ ', 'Isadmin': True, 'blogid': '1', 'xmlrpc ':' http://site.com/wordpress/ Xmlrpc. php', 'blogname': 'wpxxx'}] Although we only see wp. getCategories method, any method that requires authentication can be used, only wp. the getCategories method does not impose too many restrictions on attackers. Here is a list of authentication methods: 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. get UserInfo, 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 below is the system we have seen specifically for XML-RPC. the attack legends of the multicall method are all brute force attack attempts. Remember, each request can represent 100 attacks, not just 1,000 brute-force attempts to account/password. Through some simple calculations, you will understand the scale of the attack and its potential impact. WarrantyProtect yourself I once suggested that people block any access to xmlrpc. php, but this will affect some plug-in functions (especially JetPack ). With this in mind, it may be a good way to prevent external direct access to the JetPack plug-in or any plug-in that uses the XML-RPC. If you can't limit your XML-RPC, if you're using WAF, I strongly recommend that you block requests to system. multicall in WAF. This method is rarely called by the outside world. Blocking it will protect your application from these amplification methods. Please note that our WAF users are protected. Therefore, if you are using CloudProxy, your application is secure.