CosmicSting attacks have started hitting major stores

API Abuse

As CosmicSting enables attackers to read any file, attackers can steal Magento's secret encryption key. This encryption key can generate JSON Web Tokens with full administrative API access.

The Magento REST API offers various endpoints for attackers to abuse. For example, fraudulent orders may be placed via POST /V1/orders and customer PII can be stolen via GET /V1/customers/{id}. However, as we have learned from recent attacks in the wild, the /V1/cmsBlock endpoints are even more appealing to attackers.

Merchants often use CMS blocks to update information across their store without requiring a developer or requiring a redeployment. Very common CMS blocks are those that are added to the header or the footer, such as contact information, footer menus, promotional messages, etc. These blocks are ideal targets for attackers as they are loaded on every page, including the checkout.

Attack

Sansec has discovered widespread abuse of this attack in the wild:

1. CosmicSting is used to read the encryption_key from app/etc/env.php.
2. The encryption key is used to generate a JWT.
3. A list of existing CMS blocks is obtained via GET /V1/cmsBlock/search.
4. All CMS blocks are updated via PUT /V1/cmsBlock/{id} to include malicious scripts at the bottom of each block.

At time of writing, 3 to 5 stores are being infected every hour. We expect these numbers to go up in the next couple of days.

Mitigation

Upgrading is Insufficient

As we warned in our earlier article, it is crucial for merchants to upgrade or apply the official isolated fix. At this stage however, just patching for the CosmicSting vulnerability is likely to be insufficient.

The stolen encryption key still allows attackers to generate web tokens even after upgrading. Merchants that are currently still vulnerable should consider their encryption key as compromised. Adobe offers functionality out of the box to change the encryption key while also re-encrypting existing secrets.

Important note: generating a new encryption key using this functionality does not invalidate the old key. We recommend manually updating the old key in app/etc/env.php to a new value rather than removing it.

Audit Logging

We recommend merchants to set up a database trigger log, so that updates to CMS blocks can be audited. Any changes to CMS blocks will be logged in a separate table. This is provided as-is and without warranty.

Create Table

CREATE TABLE `sansec_log_cms_block` (
  `timestamp` DATETIME DEFAULT NULL,
  `block_id` smallint(6) NOT NULL,
  `user_id` bigint(21) unsigned NOT NULL DEFAULT '0',
  `user` varchar(64) NOT NULL,
  `old_content` mediumtext DEFAULT NULL,
  `new_content` mediumtext DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Sansec CMS Block Logging';

Create Trigger

CREATE TRIGGER sansec_log_cms_block_changes
    AFTER UPDATE ON cms_block
    FOR EACH ROW
    INSERT INTO sansec_log_cms_block
    SET
        timestamp = NOW(),
        block_id = NEW.block_id,
	user_id = connection_id(),
        user = user(),
        old_content = OLD.content,
        new_content = NEW.content;

Testing

Modify any CMS block using the Magento Backend. Then run the following query:

SELECT * FROM sansec_log_cms_block \G

Rollback & cleanup

To clean the logging table, run:

DELETE FROM sansec_log_cms_block;

To remove the trigger, run:

DROP TRIGGER sansec_log_cms_block_changes;

We recommended to temporarily deactivate the trigger when installing Magento upgrades.

Indicators of Compromise

Merchants should be suspicious of any newly added content added to existing CMS blocks. Sansec monitors the global internet and publishes all CosmicSting related attack vectors.

Read more

• Thousands of Adobe Commerce stores hacked in competing CosmicSting campaigns
• CosmicSting attack & defense overview
• Persistent backdoors injected on Adobe Commerce via new CosmicSting attack
• Polyfill supply chain attack hits 100K+ sites
• CosmicSting attack threatens 75% of Adobe Commerce stores