Troubleshooting and Researching a Security Breach

Discover and troubleshoot a security breach of your application.

One of the most stressful things that can happen to an ecommerce business is to discover that your site has been hacked or otherwise compromised. Webscale offers protection to known attacks right out of the box, but there are additional steps you can take to increase the security of your site and prevent future attacks. These are accomplished through the usage of Web Controls. There are also some common steps you can take to find out if the site has already been compromised.

General Instructions

Some common steps you can take to protect your sites from attack include the following:

  • Use Web Controls to immediately block access to known vulnerable URLs or files. Example:
    Web Control for bad URLs
  • Add known bad IPs to the Blacklist and good IPs to the Whitelist.
  • Protect your admin site with Web Controls, leveraging the whitelist or blacklist features.

If you suspect a breach or hack has taken place, you can use Traffic Viewer to verify the attack vector used. Some useful columns to filter on include:

  • delivery_status: Identifies which part of the system responded to the traffic. Greater than -1 shows all status results. A result of 0 proxied means the request went to the backend application servers - anything else is served by the proxy.
  • request_path: Path to the files used in the exploit.
  • request_method: POST or GET (most common).
  • status_code: The http status code the request received.
  • request_address: The address of the requestor - mainly used to check against whitelist or blacklist.

Example traffic viewer query:

delivery_status > - 1 and request_path ~ /downloader* and request_address not in whitelist and status_code = "403"

Example traffic viewer result:

Traffic Viewer filter results

Magento 1 instructions

Here are a few of the security measures Webscale uses to protect M1 applications from exploits as part of our Magento 1 EOL Support:

  • Web controls to immediately block access to the downloader.
  • Real-time CSP alerting and blocking to ensure only pre-approved domains are executing scripts.
  • Web controls to protect admin page access, with whitelisting and multi-factor authentication.

Whether you have Magento 1 EOL Support or not, you can use Web Controls as explained above to protect your site from known exploits, and in many cases any exploit. Please Contact Support to learn more about Magento 1 EOL Support.

Magento 1 CardBleed exploit

A recent use-case for these techniques is the Magento 1 CardBleed exploit. Attackers used the /downloader path in Magento 1 to attack a large number of Magento 1 storefronts. This attack may look like the following, in your access logs:

Magento 1 CardBleed attack vector

A traffic viewer query checking for requests to downloader.php should reveal quickly whether your site was compromised or not.

Example traffic viewer query:

delivery_status > - 1 and request_path ~ /downloader*

Example traffic viewer result:

Magento 1 CardBleed traffic viewer graph

As you can see, on about September 3rd there was an uptick in requests that match our query. Thankfully in this case the requests ended up with a 403 http response, which means the site was protected from this exploit.

However, any results that show a delivery_status other than 9 denied show that the file may have been successfully accessed. An http code of anything other than 403 is also suspect. You can use a Web Control to block all traffic to this file (which should no longer need to be used anyway) to protect against this attack as well as other exploits using the downloader.php file.

Further Reading

Have questions not answered here? Please Contact Support to get more help.


Last modified September 16, 2020