Monthly Archives: January 2015

Ghost – Buffer Overflow in glibc Library

Posted on by
1

In the early hours of 28th January GMT+0 2015, news started to go mainstream about vulnerability in the open source glibc library. The issue has been given the vulnerability marketing term “Ghost” (the name derives from the fact that the vulnerability arises because of an exploitable bug in the gethostbyname() function).

The buffer overflow vulnerability has been given the CVE reference CVE-2015-0235.

glibc is not a program as such. It’s a library that is shared among one or more programs. It is most commonly found on systems running some form of Linux as an operating system.

Redhat mention on their site that DNS resolution uses the gethostbyname() function and this condition has supposedly been shown to be vulnerable. This makes the Ghost issue much more critical than many are claiming.

As with most things in security, the answer to the question “is it dangerous for me” is “it depends” – sorry – there is no simple binary yes or no here. Non-vulnerable versions of glibc have been available for some time now, so if the installation of the patch (read the last section on “Mitigation” for details) is non-disruptive, then just upgrade.

Most advisories are recommending the immediate installation of a patch, but read on…

Impact

glibc is a core component of Linux. The vulnerability impacts most Linux distributions released circa 2000 to mid-2013. This means that, similar to Heartbleed, it affects a wide range of applications that happen to call the vulnerable function.

Giving credit to the open source dev team, the bug was fixed in 2013 but some vendors continued to use older branches of glibc.

If the issue is successfully exploited, unauthorised commands can be executed locally or remotely.

To be clear: this bug is remotely exploitable. So far at least one attack vector has been identified and tested successfully. Exim mail server uses the glibc library and it was found to be remotely exploitable thru a listening SMTP service. But again – its not as simple as “I run Exim therefore I am vulnerable”. The default configuration of Exim is not vulnerable.

Just as with Shellshock, a handful of attack vectors were identified immediately and more began to surface over the following weeks. The number of “channels”, or “attack vectors” by which the vulnerability may be exploited determines the likelihood that an attack may be attempted against an organisation.

Also, just as with Shellshock, it cannot be said with any decisiveness whether or not the exploit of the issue gains immediate root access. It is not chiselled in stone that mail servers need to run with root privileges, but if the mail server process is running as root, then root will be gained by a successful exploit. It is safer to assume that immediate root access would be gained.

More recent versions of Exim mail server on Ubuntu 14 run under the privileges of the “Debian-exim” user, which is not associated with a command shell, but also default Ubuntu installations will be easy for moderately skilled attackers to compromise completely.

So there is a possibility that remote, unauthenticated access can be gained with root privileges.

Just as with Shellshock, we can expect there to be automated BOT – initiated scanners that look for signs of exploitable services on the public Internet and attempt to gain local access if a suitable candidate is found.

At the time of writing, Rapid 7 have said they are working on a Metasploit test for the condition, which as well as allowing organisations to test for their vulnerability to Ghost, also of course permits lower skilled attackers to exploit the issue.

Another example of an exploitable channel is Rapid 7’s own tool Nexpose, which if running on an Ubuntu 12 appliance, will be vulnerable. However this will not be remotely exploitable.

Redhat mention on their site that DNS resolution also uses the gethostbyname() function and “to exploit this vulnerability, an attacker must trigger a buffer overflow by supplying an invalid hostname argument to an application that performs a DNS resolution”. If this is true, then the seriousness of Ghost increases exponentially because DNS is a commonly “exposed” service thru Internet-facing firewalls.

A lot of software on Linux systems uses glibc. From this point of view, its likely there could be a lot more attack vectors appearing with Ghost as compared with Shellshock. Shellshock was a BASH vulnerability and BASH is present on most Linux systems. However, the accessibility of BASH from a remote viewpoint is likely to be less than that of Ghost.

Risk Evaluation

There is “how can it be fixed?” but first there is “what should we do about it?” – a factor that depends on business risk.

When the information security community declares the existence of new vulnerability, the risks to organisations cannot categorically be given even base indicators of “high”, “medium”, or “low”, mainly because different organisations, even in the same industry sector, can have radically differing exposure to the vulnerability. Factors such as network segmentation can have mitigating effects on vulnerability, whereas the commonplace DMZ plus flat RFC 1918 private space usually vastly increases the potential financial impact of an attack.

Take a situation where a vulnerable Exim mail service listens exposed to the public Internet, and exists in a DMZ with a flat, un-segmented architecture, the risk here is considerable. Generally with most networks, one host falls on a network, and then others can fall rapidly after this.

Each organisation will be different in terms of risk. We cannot even draw similarities between organisations in the same industry sector. Take a bank for example: if a bank exposes a vulnerable service to the Internet, and has a flat network as described above, it can be a matter of minutes before a critical database is compromised.

As always the cost of patching should be evaluated against the cost of not patching. In the case of Ghost, the former will be a lot cheaper in many cases. Remember that increasing numbers of attack vectors will become apparent with time. A lot of software uses glibc!! Try uninstalling glibc on a Linux system using a package manager such as Aptitude, and this fact becomes immediately apparent.

Mitigation

Ubuntu versions newer than 12.04 have already been upgraded to a non-vulnerable glibc library. Older Ubuntu versions (as well other Linux distributions) are still using older versions of glibc and are either waiting on a patch or a patch is already available.

Note that several services may be using glibc so patching should not take place until all dependencies are known and impacts evaluated.

The machine will need a reboot after the upgrade of glibc.

Skeleton Key – A Worthy Name?

Posted on by
Reply

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/