hathimsh
commented
2 months ago Incorporating the CVE-2022-29464 vulnerability into a DDT can be an unnecessarily complex and time-consuming endeavour, as the vulnerability has been resolved in all of the most recent software releases from WSO2. Furthermore, it is difficult to locate and install older, vulnerable versions of WSO2 due to the fact that the software providers have either removed or updated these versions from their official channels. The following is a comprehensive explanation of the reasons why it would be challenging and time-consuming to integrate this CVE into your toolkit:
- Vulnerability Patching
The CVE-2022-29464 vulnerability, which impacted WSO2 products, enabled remote code execution (RCE) on the server by allowing attackers to upload malicious files without appropriate validation. Nevertheless, this vulnerability was promptly rectified by WSO2 developers in April 2022. WSO2 promptly implemented updates that resolved this matter, distributing upgrades for all affected products, including: • WSO2 API Manager • WSO2 Identity Server • WSO2 Enterprise Integrator
Updates to mitigate this vulnerability had been implemented in all supported versions of WSO2 by mid-2022. The likelihood of confronting an unpatched version in a production environment is minimal, as WSO2 promotes the maintenance of up-to-date installations.
To install a vulnerable version into DDT, it is necessary to intentionally locate an outdated, unpatched version. Nevertheless, the modified versions are the sole versions that are currently available for download in all official WSO2 repositories. The vulnerability is no longer present, rendering it impossible to directly exploit CVE-2022-29464 without the need for additional manual intervention to downgrade or modify the software, if you attempt to install the most recent release of WSO2 on your pentesting system.
- It is Difficult to Acquire Older Versions
It is not a simple task to identify unpatched versions of WSO2 that are susceptible to CVE-2022-29464. WSO2, like the majority of reputable software vendors, promptly removes prior versions of its software from official distribution channels upon the discovery and patching of critical vulnerabilities. The company is committed to the security of its consumers and, as a result, actively discourages the use of outdated, insecure versions. • Official Channels: WSO2 exclusively offers access to the most recent, secure versions of its software through its official download pages and repositories. Their website does not contain outdated, vulnerable versions. • Third-Party Sources: While certain third-party websites may offer older versions of WSO2 software, downloading from unverified sources is both hazardous and unreliable. These versions may be incomplete, patched, or tampered with, and may not contain the vulnerabilities you are pursuing. • Archived Versions: It is highly probable that an archived version of WSO2 from an unofficial source has been updated, as the vulnerability has already been patched, particularly if it was downloaded after mid-2022.
Malware and compromised versions can be camouflaged as older versions, introducing an additional layer of risk when searching for these versions through unofficial channels. This poses a substantial threat to your own system. Furthermore, the time and effort expended in the search for these versions may not produce the desired results, as it is possible to obtain a version that has already been corrected.
- The Efforts Obligated to Bypass Fixes
It can be complex and time-consuming to work around the patches and remedies in order to make WSO2 function in a controlled pentesting environment, even if you are able to locate a version of WSO2 that contains the vulnerability. • Compatibility Issues: The installation of older versions of WSO2 products on modern operating systems or with updated dependencies may result in compatibility issues. The WSO2 platform may necessitate the use of newer versions of Java, system libraries, or frameworks, which may not be compatible with these older software versions. • Testing Environment Setup: The establishment of a testing environment that is both reproducible and dependable, allowing for the exploitation of this vulnerability, may necessitate additional setup. In order to ensure the stable operation of prior versions of the software, it may be necessary to address other related vulnerabilities, resolve configuration issues, and downgrade dependencies.
There are numerous additional vulnerabilities in other platforms that may be more valuable to include in a DDT. These vulnerabilities, which are more likely to be found in enterprise environments, are either unpatched or more recent. Rather than devoting time to a vulnerability that has already been resolved, we can concentrate on the creation of tools that address more pertinent or persistent vulnerabilities.
Certain WSO2 products allow unrestricted file upload with resultant remote code execution. The attacker must use a /fileupload endpoint with a Content-Disposition directory traversal sequence to reach a directory under the web root, such as a ../../../../repository/deployment/server/webapps directory. This affects WSO2 API Manager 2.2.0 and above through 4.0.0; WSO2 Identity Server 5.2.0 and above through 5.11.0; WSO2 Identity Server Analytics 5.4.0, 5.4.1, 5.5.0, and 5.6.0; WSO2 Identity Server as Key Manager 5.3.0 and above through 5.10.0; and WSO2 Enterprise Integrator 6.2.0 and above through 6.6.0.