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 sent large amounts of spam after a security incident. The article uses this as a case study; it does not establish a causal link to CVE-2022-3590. 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 found a known WordPress vulnerability that appeared to be unpatched at the time. 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-3590WordPress 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 in Pingback
Now to the actual technical aspects. CVE-2022-3590 affected WordPress’s pingback function and was described as unauthenticated blind SSRF. This does not imply that generic DNS-rebinding configurations are affected.
Understanding blind SSRF
In blind SSRF, a server sends a request on an attacker’s behalf without returning the response directly. CVE-2022-3590 concerned the WordPress pingback function. Validate inputs, restrict outbound connections and keep WordPress patched.
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
A fix was published for CVE-2022-3590; the affected path was the XML-RPC pingback function. 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) {
unset($methods['pingback.ping']);
return $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.
Historical case, current practice
CVE-2022-3590 belongs to the 2022 WordPress release cycle. The safe lesson remains current: verify the affected version with the vendor advisory, patch or upgrade from trusted sources, and treat an already compromised site as an incident rather than assuming that a patch removes persistence.
- Capture logs and a known-good backup before cleanup.
- Rotate credentials and application secrets after containment.
- Have the hosting provider verify outbound mail, scheduled tasks and administrator accounts.
An external scan can reveal an exposed condition, but it cannot prove that the server is clean.
0 Comments