Improper Access Control in mautic/mautic

Valid

Reported on

Feb 3rd 2022


Description

I couldn't find a suitable vulnerability type for this kind of issue, so this may be incorrect

the default .htaccess file has some restrictions in the access to PHP files.

    # Deny access via HTTP requests to all PHP files.
    <FilesMatch "\.php$">
        Order deny,allow
        Deny from all
    </FilesMatch>

    ...

    # Except those whitelisted bellow.
    <FilesMatch "^(index|index_dev|filemanager|upgrade)\.php$">
        Order allow,deny
    </FilesMatch>

The intention seems to be to only allow specific PHP files to be executed in the root of the application (hence the ^ in the beginning).

This logic isn't correct, as the regex in the second FilesMatch only checks the filename, not the full path.
So this actually allows you to execute any php file in the docroot named index.php, index_dev.php, filemanager.php or upgrade.php

Following files are present:

./app/assets/scaffold/files/index.php
./index.php
./vendor/sparkpost/sparkpost/examples/debug/index.php
./vendor/rector/rector/vendor/symfony/http-client-contracts/Test/Fixtures/web/index.php
./vendor/symfony/http-client-contracts/Test/Fixtures/web/index.php
./vendor/mrclay/minify/min_unit_tests/HTTP_Encoder/index.php
./vendor/mrclay/minify/min_unit_tests/HTTP_ConditionalGet/index.php
./vendor/mrclay/minify/min/index.php
./vendor/mrclay/minify/min/builder/index.php

./index_dev.php
./app/assets/scaffold/files/index_dev.php

./app/assets/scaffold/files/upgrade.php
./upgrade.php

Proof of Concept

execute following script on a vanilla Mautic 4.1.2

curl http://mautic.local/vendor/symfony/http-client-contracts/Test/Fixtures/web/index.php
curl http://mautic.local/vendor/mrclay/minify/min/index.php?f=media/css/libraries.css

Impact

Any PHP file in the docroot named index.php, index_dev.php, filemanager.php or upgrade.php can be executed. Depending on the Mautic version or extra dependencies in vendor, this may allow execution of scrips.

A vanilla Mautic 4.1.2 has some files that are actually executable (see PoC), other versions may contain way more impactful files in te application or dependencies of the application.

We are processing your report and will contact the mautic team within 24 hours. a year ago
mollux submitted a
a year ago
Ruth Cheesley
a year ago

Maintainer


Thanks for the report, we'll review and get back to you. Tracking under MST-32.

We have contacted a member of the mautic team and are waiting to hear back a year ago
We have sent a follow up to the mautic team. We will try again in 7 days. a year ago
We have sent a second follow up to the mautic team. We will try again in 10 days. a year ago
Ruth Cheesley validated this vulnerability a year ago
mollux has been awarded the disclosure bounty
The fix bounty is now up for grabs
We have sent a fix follow up to the mautic team. We will try again in 7 days. a year ago
Ruth Cheesley
a year ago

Maintainer


I think that this should actually be https://cwe.mitre.org/data/definitions/284.html

mollux
a year ago

Maintainer


correct, I could't choose that one, as there was already another one I filed with the sae type

Ruth Cheesley marked this as fixed in 4.2.0 / 3.3.5 with commit cd998b a year ago
mollux has been awarded the fix bounty
This vulnerability will not receive a CVE
.htaccess#L133 has been validated
.htaccess#L113 has been validated
Jamie Slome
a year ago

Admin


Switched from CWE-840 to CWE-284 👍

to join this conversation