Post exploitation on management interfaces

Once an attacker successfully gains admin access to a particular element of the management infrastructure, what is possible? In traditional networks, the compromise of an ‘Enterprise admin’ or ‘root’ would be a worst case scenario. Using this account, an attacker could logon to servers, delete accounts and data/policies and affect services running on those servers. Although without pre-defined scripting, all the actions would need to be done manually on each server, which of course would have time implications. The attack would be effective, but once identified, action could be taken on uncompromised servers and machines not connected on the network by a domain trust would remain unaffected.

Now consider a fully virtualised environment that is fully managed by a single management interface (which, from the author’s experience, is not uncommon). Should an attacker obtain admin access to a management interface, then the implications are much greater.

Data centre management system (vCenter, SCOM)

If an attacker was to gain admin access to the management software that controls the environment, the implications from a defensive point are devastating. From inside the console they would be able to delete configurations, virtual switches and even full machines from both a management and disk perspective. What is often done in large environments is to create a disaster recovery environment in another location of the campus/business, so in the event of a loss of service in one location, the mirror environment could be used. It is not uncommon for both locations to be managed by the same management software as it allows increased replication and failover. While this may increase availability and functionality, it also means that gaining access to the one system could potentially allow an attacker to erase an entire site including any recovery environment.

While it may not have the same initial impact, there are also a number of other actions that could be completed by the attacker once access to a management interface is gained. Misconfigurations in the way the hardware performs could go unnoticed for a long period of time, but still cause huge disruption to services that may be harder and more time consuming to identify. There are also persistent attacks that could be configured for snooping, such as placing switches into promiscuous mode in order to preform undetected information gathering. It is also possible from the interface to copy full machines offline and boot them up using consumer tools such as VMware Player (VMware, 2012) for analysis and offline attacks (Siebert, 2011).

Storage interfaces

While there are only so many actions that can be done as a result of gaining access to the interfaces that manage the storage, they are equally disruptive. Entire disk arrays can be

remotely wiped, resulting in the loss of multiple servers and data stored on that storage in one action. Disks could also be misconfigured to affect performance on all machines operating on that array

Hardware management (iLO, DRAC, RSA, On-board Administrator)

With access to the hardware management interface an attacker would be able to perform physical actions on the infrastructure remotely. These control the hardware that manages the hardware of the hypervisors, the interface fabric, power and cooling on blade systems. Although most of the actions from here are reversible, they still present a single targetable area that has the potential to severely affect service for a considerable period of time.

 

Siebert, E., 2011. Five VMware security breaches that should never happen. [Online] Available at: http://searchvmware.techtarget.com/tip/Five-VMware-security-breaches-that-should-never-happen