It's not what you know!

(Actually, that’s exactly what it is!)

Monitoring eCommerce sites for compromise

DotSec knows that securing eCommerce sites properly can be tricky. Various best-practice guides to securing eCommerce software such as Magento do exist (see [1], [2] below) but despite the efforts of all concerned (including system owners, third-party providers, developers and administrators) system compromises are fairly common.

Furthermore, the consequences of a compromise are generally serious, and can include loss of Personally Identifiable Information (PII), site defacement, and loss of cardholder/payment details.

As you’ll have seen from previously publicised site compromises, one of the key shortcomings that allows an attack to be successful is the lack of visibility and awareness on the part of the site owner. In many recent attacks, the target site has been compromised for weeks or months before the site-owner becomes aware of the damage. Consider just a couple of recent examples:

This is the kind of advertising that money can’t buy! 

Had the owners/operators of these (and dozens of other compromised) sites been aware of what was happening, the magnitude and consequences (including international publicity and fame!) of the attacks would have been far less. But constantly watching for small (and relevant) signs of malicious activity is hard work: And that is why one of the key components of DotSec’s managed, secure-hosting services is pro-active logging, reporting and alerting!

DotSec provides fully-managed, highly available, hosting that addresses relevant requirements from the PCI DSS, for a number of leading Australian National retailers. Our customers’ marketing and web-dev teams need to operate autonomously as they organise new product catalogs, sale events and new marketing tools and features. DotSec can not (and should not) interfere with those operations since the business depends upon their timely completion, but DotSec can keep an eye on things and alert the marketing and web-dev teams when their changes make the shopping site vulnerable to a bit of credit card swiping. Here are just a few examples of how we work.

Case #1 – The Russians are coming here!

Now this was one of the more interesting incident identification and response cases for a long while! Some time back, DotSec notified one of our managed-services customers that a desktop within the customer internal network was probably compromised with malware; the malware appeared to be logging user activities, and sending logs of those activities to overseas attackers.

The customer in question only uses our Web Application Firewall (WAF), so we don’t have a complete MDR/SIEM/SOAR infrastructure in place on the customer’s computing environment. None the less, the WAF does it’s job well and the logs that the WAF generated showed some interesting activity:

  • The WAF logs indicated that on multiple occasions, a user within the customer’s internal network was making requests to a very specific URL inside of the administrator interface of Magento. By way of example, here is one of the requested URLs:

/index.php/secureadmindrs3d222ff32f/order_order/detailreport/orderId/12237/incrementId/13f43358/storeId/19/key/c1d9aadf...[etc]...92623f0523daa93f344a704d

  • All requests (irrespective of their source) to the customer’s web site go through the WAF and so we could determine that a couple of days after a request to the admin URL was made from the internal desktop, a Russian-based IP address made the exact same request! As you can see above, the keys within the URL are essentially random, so it is highly unlikely (let’s say, as-good-as impossible) that someone in Russia could simply “guess” the URL correctly.

  • To add to the unlikely nature of someone in Russia guessing the URL, the Russian-based addresses always duplicated a request that was made by the internal desktop, and always a couple of days after the desktop had made first made the request.

The patterns that emerged over a couple of days indicated that an internal desktop had become infected with some kind of monitoring malware, and malicious attackers were retrieving (or being sent) data from that desktop whenever it requested sensitive (admin) URLs.

The following chart depicts the occasions where a Russian-based IP address requested a Magento administrator URL that was previously requested by a user within the customer’s internal network.

The WAF had been configured to only allow access to the Magento administrator interface from a white list of source IP addresses, so the requests from the Russian-based IP addresses were blocked and the repeated attack attempts were unsuccessful.

While it’s good that the attacks failed, the logs that were generated by the attack attempts were still valuable however, because they illustrated the fact that a desktop on the internal network was compromised. Having realised this fact, DotSec could alert the customer to the compromise, and ensure that the desktop in question was investigated and addressed immediately. And we could recommend a more comprehensive MDR/MSIEM service to help us to understand the details of systems outside of those that the WAF protected.

Case #2:  Just take my creds!

As required by PCI, and because we are genuinely curious, DotSec was performing routine log analysis, looking for any anomalies in web requests to one of our customer’s web sites. A couple of examples of things that we like to check for when performing log analysis of our customer sites are:

  • Requests for unusual files. This is may include files with “unusual” file extensions (such as .zip, .backup, ,.sql, .xml, .txt, and even .php to try and catch any shells).
  • An unusually high number of, or unusual pattern of:
    • HTTP GET requests for pages or files.
    • HTTP POST requests to any given URL.
    • Requests from overseas based clients.
    • Distinct clients requesting a single URL.
    • Distinct clients making multiple requests over an extended period of time.

While performing our log review, DotSec was alerted to the fact that an attacker had crafted a request that was designed to exploit a vulnerability in a plugin that was used by the web-dev and marketing team; the aim of the exploit was to allow the attacker to download the local.xml configuration file for the Magento application.

The local.xml configuration file contained credentials for the production database and so when we saw what the attacker was attempting, DotSec promptly alerted the customer’s web-development team to the issue.

Furthermore, DotSec took immediate action by restricting access to the plugin via the WAF, re-issuing new credentials, and conducting an investigation using Splunk to determine if/how the vulnerable component had been abused in the past; these activities prevented exploitation of the vulnerable component while the web-dev team worked on a longer-term fix.

Case #3:  Oh, you brute!

On a separate occasion we were analysing various HTTP POST requests made to a customer’s web server, and we began to see some unusual patterns emerge. Namely, a handful of foreign IP addresses were making hundreds of HTTP POST requests to various API endpoints, such as:

 https://site/index.php/api/v2_soap
 https://site/downloader/
 https://site/api/xmlrpc/
 https://site/index.php/rss/

The logs indicated that attackers (well, probably attack bots rather than humans) were attempting to brute-force user credentials via these endpoints. We analysed the traffic to determine whether or not there were any “valid” requests to these endpoints (which there weren’t) and locked down access to the endpoints using Splunk and our WAF.

Had these requests not been noticed then the attacker could have continued their brute-force attempts forever… or at least until they had managed to achieve their goal and recover one of the target passwords. Once that was done, the real attack would have taken place, with much more dire consequences!

Summary

You cannot defend against the unknown and so awareness is key!  Further more, most frameworks and standards such as the PCI DSS and ISO 27001 state that formalised procedures need to be followed in order to detect and respond to anomalous and threatening events in a timely and effective manner.

DotSec provides MDR/MSIEM log collection, aggregation, analysis, reporting and alerting services as part of our managed information security practice. In the examples above, we’ve described how we were able to assist our retail customers by detecting and preventing malicious activity using our logging and monitoring, and incident-response services. Please contact us today if you would like a hand setting up and/or managing a logging, reporting and alerting platform for your own eCommerce site.

References
[1] https://magento.com/security/best-practices
[2] http://docs.magento.com/m1/ce/user_guide/magento/magento-security-best-practices.html