12

If for example I have Magento-eCommerce and WordPress installed on the same server. Both have a database each with a different database username/password and both have different login details to the admins.

If there was a serious vulnerability in a Magento plugin that allows Magento to be attacked, can that vulnerability be so bad that an attacker can use that vulnerability in Magento to attack WordPress?

Anders
  • 64,406
  • 24
  • 178
  • 215
  • 2
    If you've set your permissions right, you should be fine. Please, for the love of everything holy, disable root! – Martijn Oct 25 '15 at 23:31
  • 3
    For an extreme real-life example, read up on "drupageddon" - in 2014 the php-based CMS Drupal had an SQL injection vulnerability which enabled unlimited database access, and due to the existence of (amongst other things) a module that runs arbitrary command line PHP from database entries, hackers were able to make all sorts of wide-sweeping server-level changes including installing backdoors. – user56reinstatemonica8 Oct 26 '15 at 09:36

4 Answers4

24

If the Magento vulnerability led to a shell, then that shell could be used to get root access by a privilege escalation vulnerability. When that happens, the attacker has complete control over the system.

psmears
  • 900
  • 7
  • 9
RL.AdmiralX
  • 422
  • 4
  • 6
  • 4
    Or in more sophisticated attacks, if Magneto has a root access vulnerability then that could be used to execute commands as root directly using the `exec()` syscall. – slebetman Oct 26 '15 at 03:43
2

The short answer is a qualified "Yes." Especially if the software systems are running in the same file system space and memory space. If an attacker gets root, the system is pwned. Having said that, there are a couple of configurations that would make the pwnage much more difficult and the HIDS should have time to raise alarms about the activity.

The most common is to have each application run in its own chroot jail. It should be possible to lock things down tightly enough with something like SELinux or RBAC on Windows or Solaris. They are not airtight, the intruder would be making so much noise trying to figure out how they are configured and how to grant him/herself privileges necessary to continue the attack, again, by this time the HIDS would have given the game away.

An even safer configuration is to have each application run on its own virtual machine. If the virtual machines are running on top of an operating system, the attacker would have to break completely out of the virtual machine on which the vulnerable application was running and break into the other one. Assuming that the virtual machines and the host machine are each running its own HIDS, the alarm(s) will go off way before the attack on the second machine is completed. If they are running on bare metal, I think it's safe to say that whomever would attack that system does not have the resources to complete the attack.

IMHO, having each application run in it's own virtual machine is a good idea anyway. It should do the job and the implementation is far and away the easiest to implement and manage . . .

gwc
  • 21
  • 1
  • I think the question is more focused on if/how a cross-app vulnerability can occur than on coming up with an architecture to avoid the problem. – Neil Smithline Oct 26 '15 at 04:52
  • I appreciate your optimism about how privilege escalation attacks will surely be detected because they are so noisy... but personally, I am nowhere near as confident. Chroot is so far from perfect -- it only protects the filesystem, and has many gotchas. In addition it does nothing to prevent kernel-level privilege escalation attacks. – D.W. Oct 26 '15 at 17:53
1

Yes, usually it works in reverse. Wordpress has an insecure plugin installed that allows a php script to be uploaded and executed. This can be used to attack the Magento side of things including downloading the Magento database credentials, injection of custom administrator accounts into the Magento database, installing the Magepleasure file administration module and card information harvesting scripts.

Of course this is a two way street, if Magento is, for example, unpatched for the shoplift bug, the attacker can use a POST transaction to directly inject an administrator account into the Magento database without having Magento credentials, fire up the Magento downloader and then install the Magepleasure file administration module and once again, do anything they wish on the user account.

Totally depends on what the attacker wants to do, computer infection probably is best accomplished through a popular blog, though the last hit on Magento was using previously injected SUPEE-5344 shoplift bug created admin accounts or Magento installations still not properly patched for the various vulnerabilities to inject the GuruIncSite infection package into Magento's footer. Magento is of course of direct interest for plain old customer and credit card info theft.

To reiterate, if a plugin module for EITHER Wordpress or Magento is vulnerable to attack, then both applications can be compromised.

Fiasco Labs
  • 1,557
  • 10
  • 12
1

Or if you just use OpenSSL prior to heartbleed you would have been vulnerable, it's important that the whole Stack be secured, any loose component can give a hacker the foothold to attack the whole system.

Reference http://heartbleed.com/

I think the best solutions involve high levels of isolation (virtualization, private memory spaces, separate machines?)

drew.ray
  • 11
  • 2