0

On a sizeable site, for the third time now, we're seeing this type of attack:

  1. A request to GET /rest/V1/cmsBlock/search to find out some block IDs.
  2. A few minutes later there is PUT /rest/V1/cmsBlock/123 to insert some script into a block.

These steps come from the same IP address which is not seen for any other request so how are they authenticating? Each attack is a new IP address so an IP filter will not be enough.

To mitigate we've removed all integrations so it should not be possible to access without logging in as an admin first. 2FA is enabled. All passwords have been reset each time. User roles have been restricted a bit but we cannot lock down CMS completely or else the admin staff won't be able to do their job. Magento version is 2.4.6-p6. The newer version has a fix for remote execution but this looks more like a CSRF problem so upgrading to p7 might not help here.

I'm using rewrite rules to deny certain paths but can already think of plenty of workarounds that might occur. I cannot simply block all paths that start with /rest/ because that would break the site. Are there ways to control API use without turning off entire parts?

Improve this question
2
  • It's a CosmicSting attack using a previously stolen crypt key. You should invalidate your old keys and run a malware scanner to get proper visibility in the scope of the incident.
    – Willem
    Commented Sep 26 at 6:59
  • Thanks for the additional suggestion. It was Sansec that alerted us to the new script which was one of those typical card skimmer types. Sansec didn't make it clear what caused the intrusion. Our upgrades are always in the pipeline so it would have gotten patched eventually but clearly we're a bit slow this time.
    – clockworkgeek
    Commented Sep 26 at 11:45

1 Answer 1

Reset to default
1

A few points and ideas to respond to your question:

a) The patch P7 for 2.4.6 has a lot of security issues that might solve your problem. see Security bulletin as most part are access control fixes. This patch also forces the changes on the access tokens and keys for any external applicatión. This might be helpful to try to solve the problem.

b) You could use the webapi.xml configuration into an new module to restrict the access to the endpoints you like. Just define the entry for the route they are using and specify that the resource should be <resources><resource ref="Magento_Customer::group"/></resources> for only registered customers as example. This way you can limit the access to the specific endpoint while you investigate further the other surface of attack.

c) The main concern here should be to know which method of authentication they use to make the calls, so you know how to attack the problem. This can be done checking the headers sent on the request. If you can modify your access.log registries to get that info (don't know if you use nginx or apache), would bring clarity to know which authentication method they are using. See for apache or nginx

d) The requests to cmsBlock is typical of a CosmicString attack. The fix requires either upgrading or patching, followed by rotating the site's crypt key. The whole process only takes a few minutes.

Improve this answer
3
  • See this article also which has a lot of info. But basically, change your encryption key and investigate how they get access to your encryption key
    – Serfe
    Commented Sep 25 at 15:48
  • You should have led with that extra info. Or maybe summarise it as point d) since it fits everything.
    – clockworkgeek
    Commented Sep 25 at 18:00
  • I think that my last comment is more important that the answer itself. Will take that into consideration for the next answer.
    – Serfe
    Commented Sep 25 at 18:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.