OmniSpace, from automated 0day XSS to RCE

While you're reading this article, we assume you have a clear understanding of Patrowl's automation. However, the subsequent example effectively demonstrates how the combination of Patrowl along with our automated Pentest-as-a-Service methodology, enables us to navigate the extensive expanse of our client's exposed surfaces. This approach helps us to identify the specific assets that require special attention.

I would like also to thanks OmniSpace / Agora-project administrators, an open-source project which have very quickly patched and acknowledge the vulnerabilities sent by Patrowl.

Patrowl does continuous pentestings for internet exposed assets and driven by a singular goal: outpacing potential attackers, be faster than attackers! Patrowl amasses millions of unique findings automatically analyzed, contextualized and prioritized. When advanced actions are required, offensive analysts take the lead to focus only on juicy area, holding strategic value from an attacker's perspective. When the asset is a new one, emerging from Patrowl's discovery, it promptly triggers an increased alert within our Patrowl Arsenal system. This alert comes with a heightened degree of qualification and so high degree of confidence regarding the asset's significance for an attacker.

One of the clues found by Patrowl's automation involves a validated cross-site scripting (XSS) vulnerability within an unauthenticated parameter. This insight was correlated with the observation that numerous other XSS vulnerabilities had already been disclosed for the same product in 2017: https://www.cvedetails.com/vulnerability-list/vendor_id-16180/product_id-36153/year-2017/opxss-1/Agora-project-Agora-project.html

Oh, that became intriguing. Why?

First of all, the published CVE affected 4 parameters: targetObjIdChild, action, ditObjId, msgNotif[]. Surprisingly, all of these parameters are not automatically collected and examined for common XSS vulnerabilities by all web application scanners available in the market, but this will change after they read this article 😉.

The presence of four vulnerable parameters in 2017 serves as a strong indication that there might be additional vulnerabilities awaiting discovery. Naturally, you wouldn't be engaged with this article if this weren't the case. Despite the product being in an updated version and the previously disclosed XSS vulnerabilities being unexploitable, the scrutiny must extend to all newly introduced parameters.

Once more, Patrowl's automation will systematically collect all accessible parameters through continuous web application crawling. Furthermore, it will examine widely recognized variables that are prone to be exploitable.

And there it is: our recently identified susceptible notify[] variable has been flagged as susceptible to an XSS vulnerability (requiring just a bit of encoding to exploit), and here is the exploit: https://x.x.x.x/index.php?disconnect=1&notify[]=%3ci%3eiii%3c%2fi%3e68617%22)%3balert(1)%2f%2f869

With complete automation and validation in place, what comes next? Patrowl's findings encouraged us to dig deeper, and as always, it proved to be the right direction.

Presently, an unauthenticated XSS holds inherent intrigue, particularly when encountered on an external login page. Such a vulnerability could potentially facilitate an account takeover or streamline phishing attacks.

Yet another finding flagged by our automation has managed to capture our focus: a cookie labeled AGORAP_PASS which appears to be a simple SHA1 hash. Given that the installed program is open-source, let's further investigate by digging into a laboratory version for deeper analysis of that strange hash.

Obtaining the most recent version accessible during the testing phase (23.5.0) revealed that the application has deprecated the use of the AGORAP_PASS, with the usage of a modern authentication mechanism. Furthermore, any sessions older than a year are automatically purged each time a user connects or disconnects from the platform.

However, the version installed for our client (23.2.3) create the cookie with the SHA1:

In the previous version (< 23.4.1), this makes the XSS vulnerability quite hazardous. Now, an attacker with the ability to hijack a user's cookie will be able to:

• Execute a Pass The Hash attack on the application, employing it for a span exceeding 10 years

• Retrieve a user's password by cracking the SHA1-hashed password of the user and re-using it on other applications, access...

The cookie is deleted and not created anymore in version > 23.4.1. However, it could be used and exploit for an attacker for all authentication < Year.

Upon successful login, a swift examination of the user interface reveals a vulnerability in the admin's ability to change a user's password. This action is susceptible to Cross-Site Request Forgery (CSRF) and has not been appropriately implemented:

• The process of changing a user's password does not require the user to input their old password. This oversight enables an attacker to easily craft malicious links. All the attacker needs to know is the user-ID of the targeted users, which can be readily obtained if they belong to the same space:

• The application also accepts POST parameters as GET parameters, simplifying the process of crafting malicious links for an attacker

• No CSRF protections are implemented

Then, an attacker could simply forge a link which will change the user’s password in one click, even more fun, he could send the malicious link through the internal messaging:

Example of link, with just the user-ID to change:

The vulnerability will not be patched for the moment, the developer has indicated that changing password without the old one is a specific function needed by administrators.

With the capability to effortlessly pilfer an account on the platform and understanding its usage for document sharing, it's evident what our next course of action entails: uploading a malicious PHP file and attempting remote code execution.

The upload functionality is quite classic:

• Once files are uploaded, a quick check is made on the client-side to restrict some specific files
• A first call to ?ctrl=file&action=UploadTmpFile&tmpFolderName= tmpUploadFolder5333858564d63b8dd3e32 is made, this will create the file within the DATAS/tmp/tmpUploadFolder5333858564d63b8dd3e32 web directory, where tmpUploadFolder5333858564d63b8dd3e32 could be set arbitrary
• Then, a direct call to index.php POST request and action AddEditFiles which is storing the file within the database and deleting it from the /tmp folder.

Indeed, avoiding the direct storage of uploaded files on the web server is a sound security practice. However, an attacker, given the ability to directly access the UploadTmpFile function, can circumvent the AddEditFiles call. Consequently, they can bypass the file deletion process within the temporary folder.

Well, armed with our astounding hacking prowess and a dash of analytical finesse, let's take a stab at the request. Our quest? To modify the content-type like a magician and proudly retain our beloved PHP extension:

Bingo! The file is stored within DATAS/tmp/azerty/hack.php:

Ok, now let’s try to reach it, with a little bit of luck, could be reach directly?

Nop, let’s check the default .htaccess file:

We have to find another way.

The vulnerability has been patched in the 23.7.1 version.

Now that we've got our hands on a PHP file nestled within the web server, our next mission is to access it. How? Well, let's go on a quest to find a way where users can control which files are included. With a bit of luck, we might just stumble upon an opportunity to include any PHP file we want, which could lead us to achieve Remote Code Execution (RCE).

Few research leads us directly to an interesting parameter: curTrad, the source code is quite interesting:

No need to search deeper, the curTrad is directly taken from curTrad parameter from users, and then sent kindly to a require_once(). We now know how to include our malicious PHP file:

• https://127.0.0.1/?curTrad=../../DATAS/tmp/azerty/hack.php *

No need to search deeper, the curTrad is directly taken from curTrad parameter from users, and then sent kindly to a require_once(). We now know how to include our malicious PHP file:

• https://127.0.0.1/?curTrad=../../DATAS/tmp/azerty/hack.php *

Bingo! RCE.

Adding to the intrigue, the curTrad is accessible without authentication, and the inclusion process works seamlessly. If we were rewinding to 2010, I'd be sharing the trick about crypto utilizing a Null Byte extension to exploit this vulnerability and gain access to crucial files that weren't uploaded and weren't PHP scripts – like perhaps finding hidden gems such as database backups. But for now, let's assume we're all in agreement that PHP versions older than 5.3 are history (https://svn.php.net/viewvc?view=revision&revision=305507)

As evident, the series of chained vulnerabilities could pose significant consequences for companies that deploy such software in their external attack surface. To summarize this kill chain:

• Account takeover via XSS (CVE-2023-40228), Cookies (CVE-2023-40227) or CSRF (CVE-2023-40230)
• Unrestricted file upload (CVE-2023-40229)
• And arbitrary PHP file inclusion (CVE-2023-40226)

Leads to Remote Code Execution.

Fortunately, the Agora-Project teams have demonstrated quick and thorough responses. Most critical vulnerabilities were promptly patched. Now, I trust you grasp the importance of External Exposure Management with EASM combined with PTaaS approach. This precisely mirrors the methodology an attacker would employ, albeit at a slower pace, of course.

Timeline:

• Discover of flaws: 06/17/2023
• Editor warned: 06/20/2023
• Response of the editor : 06/24/2023
• First patch release 23.7.1 : 07/17/2023
• CVE/MITRE request : 08/08/2023
• CVE-2023-40226, CVE-2023-40227, CVE-2023-40228, CVE-2023-40229, CVE-2023-40230 reserved: 08/11/2023

Ref:
https://github.com/xech/agora-project/releases