When it comes to dealing with security issues with Magento websites or other types of websites, we can’t emphasize enough the value of bringing in someone with more security expertise to help deal with it. We recently were brought in to help upgrading a Magento website, where there also was an ongoing issue with a form of carding. The carding here involved someone testing if stolen credit cards were valid by making zero dollar authorizations through the website to PayPal. We were asked if we could help with that as well.
The carding had been going on for weeks when we were contacted. A lot of things had been attempted to address this. What hadn’t been done is where we always start when brought in with something like this. Figuring out what was the attacker was actually doing. That allowed us to quickly implement a solution instead of doing more things that didn’t actually have an impact.
There had been a lot of focus on trying to make changes to the normal checkout process to stop the carding, but the attacker wasn’t using that. Instead, once we were provided with the IP addresses of recent authorization, we found that in the logging all of them corresponded with a single request to the website. An example of that was this:
73.231.56.2 [redacted[ – [18/Oct/2024:16:59:54 +0000] “POST /graphql HTTP/1.1” 200 196 “https://[redacted]/checkout/” “Mozilla/5.0 (Windows NT 6.0; Trident/5.0; EIE60;ENUSMSN; rv:40.0) like Gecko” | TLSv1.2 | 0.834 0.834 0.835 – 0 NC:000000 UP:SKIP_CACHE_SET_COOKIEDT
The important detail in that a POST request was being the URL /graphql on the website. A POST request involves additional data being sent with the request. The data wasn’t logged, so what we had to go on was that the URL. That is the URL for requests being sent to Magento’s GraphQL API. That is an API to allow data to be sent to and from the website.
Because the website isn’t using the GraphQL API, the quick solution without having to make any changes to Magento was to block access to the URL used for that. That instantly stopped the carding.
We haven’t yet gotten access to more data on the requests being sent, which would likely explain better why the attacker could use the GraphQL API, but the quick solution has dealt with the issue for now.