Skeleton Key – A Worthy Name?

Vulnerabilities have been announced in recent months with scary names like Shellshock , which came after Heartbleed. Also “Evil Twin” (used to describe a copy-cat wifi rogue AP deployment). This is a new art form so it seems, one which promotes vulnerabilities in a marketing sense. No doubt those vulnerabilities were worthy of attention by organisations, but the initial scare factor was higher than justified based on the technical analysis. “Evil Twin” is a genuine concern as a very easy and very effective means of capturing personal data from wifi users, but the others had the potential of impactful exploit across a smaller percentage of organisations.

With both Shellshock and Heartbleed there were misleading reports and over-playing on the risk element. Shellshock was initially touted by some as an exploit that completely compromised the target from a remote source, with no authentication challenge! It was far from that. With Skeleton Key, i dare say there will be reports that suggest that immediate remote access by any user to anything under Active Directory will be gained easily. Again – this is not the case. Far from it. But once inside a network, Skeleton Key does as it says – it does unlock everything that uses Active Directory for authentication for those who know a specific password.

So “Skeleton Key”? Yes, but as with any key, you have to have possession of it first – and this is the tricky part. It is not the case that the doors are all unlocked.

As a very brief summary:

  • Admin rights are first needed to deploy Skeleton Key, but once deployed, unfettered access to all devices under Active Directory (AD) are granted.
  • Any AD account can be used, but the NTLM hash that was used in the deployment is the password. This must be known by anyone looking to take advantage of a successful deployment.
  • The malware is not persistent – once a DC is rebooted (such as after a patch install) it needs to be re-deployed
  • IDS/IPS doesn’t help. Detective controls around logging are the only defence currently

A 12th January report by Dell’s SecureWorks Counter Threat Unit gives some details on a new malware pattern, one that appears to allow complete bypass of Active Directory authentication.

Skeleton Key is not a persistent malware package in that the behaviour seen thus far by researchers is for the code to be resident only temporarily. A restart of a Domain Controller will remove the malicious code from the system. Typically however, critical domain controllers are not rebooted frequently.

The Dell researchers initially observed a Skeleton Key sample named ole64.dll on a compromised network. But they then found an older version msuta64.dll on a host that was previously compromised by (probably) the same attackers on a staging system.
ole.dll is another file name used by Skeleton Key. Windows systems include a legitimate ole32.dll file, but it is not related to this malware.

The malware is not compatible with 32-bit Windows versions or with Windows Server versions beginning with Windows Server 2012 (6.2).

Note it is not the case that any user can authenticate as any user for AD environments under Skeleton Key influence. The NTLM hash of the password configured by the attackers has to be known, but this password can be used to authenticate under any user account. Normal user access happens in the same way – there is no impact on existing user accounts and passwords.

Impact

To be clear, administrative rights are required for this malware to be introduced in the first place. But once in place, any service that uses Active Directory can be bypassed if it only uses single-factor authentication. Such services as VPN gateways and webmail will be freely accessible.

Most compromises of systems result in a listening service on a higher port, or a connection initiated out to a remote host. Skeleton Key succeeds in removing the controls implemented by a central authentication and user management system, thereby opening a whole network to unauthorised access with one step. In this way Skeleton Key could be seen as a kind of Swiss Army Knife for remote attackers, who could trick users or administrators into installing malicious software, then gain admin rights, then completely bypass Active Directory controls with only the second or third major step in their attack attempt.

In the case of the investigation that unearthed Skeleton Key, a global company headquartered in London, was found infected with a Remote Access Trojan (RAT), in order to give attackers continued access.

Mitigation

Two-factor authentication clearly resolves remote unauthorised connection issues, but at the time of writing this is the only ready-made preventative control.
Detection is possible, but not from the network perspective. IDS/IPS isn’t going to be helpful because the behaviour of Skeleton Key does not involve network-based activity.
A YARA signature is given in the researchers write-up of the investigation. Aside from this, knowledge of the malware propagation behaviour can be used to configure Windows auditing, hopefully to improve the odds of detection. More details on the behaviour, particularly in the use of psexec.exe, are given in the Dell researchers’ verdict. Other signs can be:

• Process arguments that resemble NTLM hashes
• Unexpected process start/stops
• Domain replication issues

Compared with Heartbleed, Shellshock.

There is a similarity with Shellshock in that the initial attack vector isn’t as easy for attackers to deploy as was first publicised, but the effects of a successful first attack step can potentially be devastating. In the case of Skeleton Key though, it is more impactful in that an entire Windows domain can be compromised easily. In the case of Shellshock, local shell access is gained only on the machine that is compromised but the privileges of the shell are only that of the process that was compromised.

The main difference is that with Skeleton Key, administrator rights needs to be gained on one system in the domain first. No such requirement exists with either Heartbleed or Shellshock. Heartbleed needed no privileges for a successful exploit but the results of the exploit were unlikely to mean the immediate compromise of the network.

References

The Dell researchers’ detailed write-up:
• http://www.secureworks.com/cyber-threat-intelligence/threats/skeleton-key-malware-analysis/
SC Magazine’s coverage:
• http://www.scmagazine.com/skeleton-key-bypasses-authentication-on-ad-systems/article/392368/

Share This:

What’s Next For BYOD – 2013 And Beyond

There are security and business case arguments about BYOD. They cast different aspects and there’s peta-bytes of valid points out there.

The security argument? Microsoft Windows is still the corporate OS of choice and still therefore the main target for malware writers. As a pre-qualifier – there is no bias towards one Operating System or another here.

Even considering that in most cases, when business asks for something, security considerations are secondary, there is also the point that Windows is by its nature, very hard to make malware-resistant. Plenty of malware problems are not introduced as a result of a lack of user awareness (for example, unknowingly installing malware in the form of faked anti-virus or browser plug-ins), plus plenty of services are required to run with SYSTEM privileges. These factors make Windows platforms hard to defend in a cost-effective, manageable way.

Certainly we have never been able to manage user OS rights/privileges and that isn’t going to change any time soon. There is no 3rd party product that can help. Does security actually make an effective argument in cases where users are asking for control over printers and Wifi management? Should such functions be locked anyway? Not necessarily. And once we start talking fine-grained admin rights control we’re already down a dark alley – at least security needs to justify to operations as to why they are making their jobs more difficult, the environment more complex and therefore less reliable. And with privilege controls, security also must justify to users (including C-levels) as to why their corporate device is less usable and convenient.

For the aforementioned reasons, the security argument is null and void. I don’t see BYOD as a security argument at all, mainly because the place where security is at these days, isn’t a place where we can effectively manage user device security – the doesn’t change with or without BYOD, and this is likely to be the case for some years to come yet. We lost that battle, and the security strategy has to be planned around the assumption that user subnets are compromised. I would agree that in a theoretical case where user devices are wandering freely, not at all subject to corporate controls, then the scope is there for a greater frequency of malware issues, but regardless, the stance has to be based on an assumption that one or more devices in corporate subnets has been compromised and the malware is designed to connect ingress and egress.

How about other OS flavors, such as Apple OS X for example? With other OS flavors, it is possible to manage privileges and lock them down to a much larger degree than we can with Windows, but as has been mentioned plenty of times now, once another OS goes mainstream and grows in corporate popularity, then it also shows up on the radars of malware writers. Reports of  malware designed to exploit vulnerabilities in OS X software started surfacing earlier in 2012, with “The Flashback Trojan” given the widest coverage.

I would venture that at least the possibility exists to use technical controls to lock down Unix-based devices to a much larger degree, as compared with MS Windows variants, but of course the usability experience has to match the needs of business. Basically, regardless of whether our view is utopic or realistic, there will be holes, and quite sizable holes too.

For the business case? Having standard build user workstations and laptops does make life easier for admins, and it allows for manageability and efficiency, but there is a wider picture of course. The business case for BYOD is a harder case to make than we might have at first thought. There are no obvious answers here. One of the more interesting con articles was from CIO Magazine earlier in 2012: BYOD: If You Think You’re Saving Money, Think Again and then Cisco objectively report that there are plenty in the pro corner too: Cisco Study: IT Saying Yes To BYOD.

So what does all this bode for the future? The manageability aspect and therefore the business aspect is centered around the IT costs and efficiency analysis. This is more of an operational discussion than an information risk management discussion.

The business case is inconclusive, with plenty in the “say no to BYOD” camp. The security picture is without foundation – we have a security nightmare with user devices, regardless of who owns the things.

Overall the answer naturally lies in management philosophy, if we can call it that. There is what we should do, and what we will do….and of course these are often out by 180 degrees from each other. The lure of BYOD will be strong at the higher levels who usually only have the balance sheet as evidence, along with the sales pitches of vendors. Accountant-driven organisations will love the idea and there will be variable levels of bravery, confidence, and technical backing in the IT rationalization positions. Similar discussions will have taken place with regard to cloud’ing and outsourcing.

The overall conclusion: BYOD will continue to grow in 2013 and probably beyond. Whether that should be the case or not? That’s a question for operations to answer, but there will be plenty of operations departments that will not support the idea after having analyzed the costs versus benefits picture.

Share This: