Risk factor WordPress vulnerability CVE-2022-3590

It was actually a Monday morning like any other today when I suddenly received an unexpected call for help and subsequently stumbled upon the risk factor WordPress vulnerability CVE-2022-3590. A company hosted by an external service provider had been hacked, and the hack had caused it to start sending large amounts of spam. While subsequently waiting to receive the formal security order in writing, I first checked the site via an external scan and found an unpatched WordPress vulnerability. Within minutes, I came across three things going horribly wrong without having access to the compromised system. Since I like it when complex issues are broken down as small as possible and thus made understandable, I thought I’d explain what’s wrong in a blog post. But one after the other:

Risk error: Incorrect handling of spam

A hack is a serious issue to begin with, not only because of the potential damage to the company’s reputation, but also because of the risk to other organizations. In such cases, the impact of the security breaches must be quickly assessed and remediated before further damage can be done. On the part of the external service provider, unfortunately, damage limitation consisted only of blocking all outgoing mail and keeping the affected website online.

However, blocking outbound emails and keeping a compromised website running at the same time can be problematic for several reasons:

• Data loss: If a website has been compromised and the attacker has gained access to sensitive data such as customer information or proprietary corporate data, they may attempt to exfiltrate that data via email. Blocking outbound emails may prevent the attacker from successfully sending the data, but it does not fix the underlying problem of the compromised website. As long as the website remains online, the attacker can continue to access the data and potentially steal more data.
• Damage to reputation: If a company’s website has been compromised and the attacker is able to access and exfiltrate sensitive data, this can seriously damage the company’s reputation and lead to a loss of trust among customers. Even if outgoing emails are blocked, the fact that the website has been compromised and possibly exploited could become public knowledge, resulting in negative publicity and possible financial losses.
• Legal consequences: Depending on the type of data that has been compromised, a company may face legal consequences for not properly securing its website and protecting sensitive information. For example, if a company’s website stores personal information about customers, such as names, addresses, and credit card numbers, and that information is compromised, the company may be held liable for failing to adequately protect the information.

Therefore, in the event of a compromise, it is important for organizations to not only block outbound email, but also take steps to secure their website and prevent future attacks. This includes fixing vulnerabilities, implementing stringent security measures, and regularly monitoring suspicious activity.

Risk errors: Open vulnerabilities

During the scan, I came across a security vulnerability that WordPress had known about for years in itself, but never cared enough to fix. However, this vulnerability is now assigned a CVE (CVE-2022-3590) to it. Computer vulnerabilities or “CVEs” (Common Vulnerabilities and Exposures) are weaknesses in software or hardware that can be exploited by attackers to gain unauthorized access to a system or steal confidential information. When a vulnerability is discovered, it is assigned a unique identifier and added to the CVE database maintained by MITRE Corporation.

Open and unpatched vulnerabilities can pose a serious problem to a company’s reputation, as they can be exploited by attackers to compromise the security of the company’s products or services. The compromised data then regularly surfaces on the dark web. This can have serious consequences, such as data breaches, identity theft, and financial losses. If a company’s products or services are found to have open and unpatched vulnerabilities, it can damage the company’s reputation and lead to a loss of trust among customers.

Open vulnerabilities and WordPress

Risk factor WordPress vulnerability CVE-2022-3590

Risk Factor WordPress Vulnerability CVE-2022-3590[/]WordPress is now used by nearly 40% of all websites on the Internet and the software is a huge open source success story. However, an open vulnerability in such a popular system leads to an interesting dilemma. To protect their reputation and the security of their products and services, some companies have security rules that block applications with open CVEs, regardless of how severe the vulnerabilities actually are. These security rules are designed to prevent the use of potentially vulnerable applications within the organization to reduce the risk of attacks. By blocking applications with open CVEs, organizations can ensure that their employees and systems are protected from known vulnerabilities that could be exploited by attackers.

What will happen next if WordPress does not close the vulnerability?

Risk Factor WordPress Vulnerability CVE-2022-3590: Unauthenticated Blind SSRF via DNS Rebinding

Now to the actual technical aspects. The WordPress vulnerability CVE-2022-3590 is classified as an unauthenticated blind SSRF via DNS rebinding. But what are DNS rebinding attacks and what is an unauthenticated blind SSRF?

DNS rebinding attacks

The CVE-2022-3590 vulnerability is a DNS (Domain Name System) rebinding attack. DNS (Domain Name System) rebinding is a type of cyberattack that exploits vulnerabilities in the way web browsers and other Internet-based applications resolve domain names into IP addresses. In a DNS rebinding attack, the attacker exploits the fact that these applications are designed to trust DNS responses from the server they originally communicated with.

To understand how DNA rebinding works, let’s use an analogy:

Imagine you are trying to send a letter to a friend who lives in another city. You know your friend’s name, but you don’t know his address. So ask the local post office for help. The post office will look up your friend’s name in a directory and give you the correct address. With this address you then send the letter to your friend.
Similarly, if you type the domain name of a website (for example, “google.com”) into your web browser: Your computer sends a request to a DNS server to determine the corresponding IP address. The DNS server responds with the correct IP address, and your browser uses this address to connect to the website.

In a DNS rebinding attack, the attacker makes your computer send a request to a DNS server that he controls. The attacker’s DNS server responds with a spoofed IP address pointing to another server that the attacker also controls. This server can then send malicious instructions to your computer pretending to be the legitimate website you wanted to access.

Unauthenticated blind SSRF

Server-side request forgery (SSRF) is a type of cyberattack in which an attacker exploits vulnerabilities in a server or application to send malicious requests on behalf of the server or application. SSRF attacks can be used to gain access to internal networks, steal sensitive data, and perform other malicious actions.

Unauthenticated blind SSRF is a special type of SSRF attack in which the attacker does not need to authenticate (i.e., provide a username and password) to perform the attack, and the attack is “blind” because the attacker does not receive a response from the server or application. This makes it more difficult for the attacker to determine the success or failure of the attack, and it also makes it more difficult for the defenders to detect the attack.

Unauthenticated blind SSRF attacks can be particularly dangerous because they can be launched from anywhere on the Internet and because they may leave no visible sign of the attack (e.g., log entries or error messages). Therefore, it is important for organizations to implement stringent security measures to protect against this type of attack, such as validating and filtering input and regularly auditing and monitoring their servers and applications.

An interim solution for WordPress CVE-2022-3590

By the way, in the case of the risk factor WordPress vulnerability CVE-2022-3590 there is a Fix, which is not based on better coding, but at least fixes the symptom. Once again, the problem lies in XML-RPC.

XML-RPC (Extensible Markup Language Remote Procedure Call) is a protocol that allows applications to communicate with each other over the Internet. XML-RPC is used by many popular software applications, including WordPress.

XML-RPC attacks are a type of cyberattack that exploit vulnerabilities in the way XML-RPC is implemented in WordPress and other applications. These attacks can be used to perform a variety of malicious actions, such as creating new users, deleting content and even taking over the entire website.

XML-RPC attacks on WordPress have a long history. In these attacks, hackers used automated tools to search the Internet for WordPress websites with open XML-RPC interfaces, and then exploited vulnerabilities in those interfaces to gain unauthorized access to the websites.

In the years since those initial attacks, WordPress has implemented a number of security measures to protect against XML-RPC attacks, such as disabling the XML-RPC interface by default and asking users to manually enable it when necessary. However, WordPress websites that have not properly secured their XML-RPC interfaces may still be vulnerable to this type of attack.

To protect against XML-RPC attacks, it is important for WordPress users to keep their software updated with the latest security patches and to be cautious when enabling and using the XML-RPC interface. You should also regularly monitor your website for suspicious activity and implement strict security measures such as strong passwords and two-factor authentication.

In this specific case, the vulnerability is on the XML-RPC pingback function.

Vulnerability: XML-RPC Pingback Function

In WordPress, a pingback is a type of linkback that is automatically generated when one WordPress blog links to another WordPress blog. When a WordPress blog posts a link to another WordPress blog, the linked blog receives a notification, called a pingback, telling it that the link has been added. The linked blog can then decide whether to display the pingback as a comment or link on their site to acknowledge the link and stimulate discussion.

Pingbacks can be a useful feature for WordPress users, as they allow bloggers to easily follow links to their site and participate in discussions with other bloggers. However, pingbacks can also be used by attackers for pingback spam attacks, where they send a large number of pingbacks to a WordPress blog to flood the site with spam comments or links.

To protect against pingback spam attacks, WordPress provides a number of built-in security measures, such as rate limiting (which limits the number of pingbacks that can be received from a single source) and spam filtering. WordPress users can also take additional measures to protect their site from pingback spam, such as disabling pingbacks and trackbacks or using a plugin to further filter and monitor incoming pingbacks.

A proof of concept (PoC) has been announced for the third week of January. A PoC in IT security is a demonstration that shows how a vulnerability or exploit can be used to compromise a computer system or network. In this way, researchers can prove that a particular vulnerability or exploit exists and can be exploited without actually performing an attack.

So in the meantime, unfortunately, the easiest fix is to disable the very helpful pingback.ping on the XML-RPC endpoint, for example by adding the following code to the functions.php file in the theme directory:

add_filter('xmlrpc_methods', function($methods) {

});
By now it’s Monday evening, the contract documents are still not through, but I hope at least to have given some insights to one or the other reader and also to have contributed to the fact that not yet another XML-RPC vulnerability will be exploited en masse soon.