When you are getting the “WP <= 6.1.1 – Unauthenticated Blind SSRF via DNS Rebinding” error you might get exhausted or have a panic attack how to tackle that error?
Let me make myself clear it sounds like a big issue but it’s not you can consider this a false alarm. This vulnerability is a low priority, according to the WordPress.org security team.
The group is debating whether this problem could be resolved publicly as a general hardening approach.
Blind SSRF
Moving forward direct towards blind SSRF. It’s an attack that occurs when we are not receiving any feedback from the application on whether the changed URL was accepted or not.
Or we can say that on the server side when you cannot get the desired response is called blind SSRF
As a result, most three cases returned displaying HTTP response, showing a specific message about the state of the request or HTTP Status Code
An unauthenticated blind SSRF makes WordPress vulnerable.
Yes, WordPress is vulnerable to an unauthenticated blind SSRF, As an attacker easily connects to internal hosts. WordPress was informed of this vulnerability on January 21, however, a solution
is not yet available. Another researcher initially brought up this problem in January of 2017—roughly six years ago—and many more have since.
On WordPress, pingbacks are automatically enabled.
Pingbacks are an alert that other bloggers receive when you link to their website or blog. The notification feature depends upon whether the other blogger has their pingback enabled.
Due to the significance of social and community features when it comes to personal blogging, pingbacks are still enabled by default on WordPress instances.
The XML-RPC API of WordPress supports the pingback functionality. Using pingback. ping, we have two arguments pagelinkedfrom “represent the address of the article” and pagelinkedto “that generate a local instance of an existing article”. The next step is URL validation which implements multiple checks on the URL.
Now here is the important part that needs to be understood pingback implementation is done Url validation is done now’s the HTTP clients side that handles pingback requests.
PHP request library has Requests_Transport_cURL and Requests_Transport_fsockopen.
Now the user has to create an HTTP request manually With The URLparaing using parse_url().
And host part is used to create a destination compatible with API.
This will create a new stream with stream_socket_clientidentify the host’s IP to send the packets at the transport level.
Now here comes the problem the HTTP client must parse the URL and resolve the hostname again to send the request, A hacker might modify the domain to redirect to a different address than the one that had previously been verified!
Another name for this bug class is Time-of-Check-Time-of. Use: A resource is approved but changes may be made before its actual use. Such flaws are frequently included in mitigations for Server-Side Request Forgeries (SSRF).
How to resolve unauthenticated blind SSRF
Although WordPress is facing unauthenticated blind SSRF it can be resolved by disabling Pingbacks and XML-RPC.
- If you are using iThemes Security click Security ->Settings -> Advanced -> WordPress Tweaks -> use the dropdown to turn off XML-RPC.
- You can also install and activate the Disable XML-RPC plugin.
- Add PHP code to your function.php file
add_filter('xmlrpc_enabled', '__return_false');
Even though this problem is not serious, you should nonetheless act quickly to protect your website from attackers.
The Mute vulnerability button cannot be seen due to security measures in browsers like Chrome and Safari. Mute vulnerability option visible once SSL certificate is installed.
Summary
Unauthenticated Blind SSRF is considered a little risky for WordPress. You’re already secured if XML-RPC is disabled on your website. Pingbacks are a legacy feature of WordPress that, while occasionally beneficial, is not commonly used by contemporary websites.