Bundestag Hack: Possible Backgrounds and Defense Methods

Here at Univention, we are of course also concerned by the attack on the German parliament’s IT infrastructure, better known as the “Bundestag hack”. To recap: It appears that there were some bogus e-mails there including links to malware. A number of the Windows PCs in the Bundestag’s “Parlakom” network were or may still be infected with the malware, which is alleged to have searched for and copied certain confidential Word documents. According to a report in the Tagesspiegel (German) newspaper, this allowed the hackers to gain “administration rights for the infrastructure”. The attack was conducted as an “advanced persistent threat” or “APT attack” for short: in other words, a complex, multi-phase attack on the German parliament’s “Parlakom” IT network.

How IT systems can be taken over

There are a whole host of “classic” approaches for taking over IT systems, such as the exploitation of security vulnerabilities in the software, the interception or guessing of passwords (brute force attacks) and the cracking of password hashes. These methods are well known and it is comparatively simple to reduce the risk of such attacks’ being successful. The requisite measures are: regular, comprehensive and rapid installation of updates, encryption of sensitive data and network communication using state-of-the-art encryption standards, the use of sufficiently long passwords, logging of failed login attempts and blocking of user accounts with too many failed attempts, the use of salted password hashes (the salt converts two identical passwords into different hashes), iteration of the hash functions (rounds) and changing passwords regularly.

However, there are also advanced hacking methods which are not as blatant (as a brute-force attack) and do not require massive computational efforts to crack password hashes. The SANS institute published a white paper on the topic with the apt name “Why crack when you can pass the hash?”.

Is the same hacking scenario as the Bundestag hack also possible with Univention Corporate Server?

As you can read here, for example, we now know that the German parliament employs OpenLDAP and Active Directory as central directory services. OpenLDAP is also the central directory service in UCS and Active Directory services are provided in UCS by the Open Source software Samba. Consequently, we were forced to ask ourselves whether the same type of attack could have been successful if UCS were used and what protective security measures would have been required. This poses the question of if there are known attack scenarios against Active Directory, whether they also apply for UCS and Samba and what security measures could be implemented if necessary.

Pass the hash

Pass the hash is an example of a hacking method which exploits a design flaw in the authentication protocol rather than a specific security vulnerability in the code itself. In this way, a password hash (and not the actual password) is used to log in to a remote Windows system.

A hack might occur as follows:

1. The hacker starts by acquiring local administrator rights on a domain system (usually Windows clients), for example by identifying a security vulnerability or via a phishing e-mail as may have been the case in the Bundestag hack.

2. Password hashes are then read out, usually from the internal memory, but also possibly from local files. The known successful hacks to date restricted themselves to LM and NTLM hashes.

3. These password hashes can also be used to log in to server services which permit NTLM authentication. Tools are also available which can generate a forged Kerberos ticket from an NTLM hash.

4. A domain can be fully compromised if the password hash of the KRBTGT user can be read out on an AD/Samba DC, as this can be used to generate as many Kerberos tickets as you like (keyword: “golden ticket”.

All in all, it is extremely unpleasant and allows a hacker to establish a presence for himself in an Active Directory for a long period of time. These attacks are known as advanced persistent threats (APTs).

At present, there are no known possibilities for an unprivileged user to gain access to the password hash of the KRBTGT user on Samba AD DC servers.
In contrast, a privileged user can easily gain access to the KRBTGT user’s password hash, as the system is actually designed with this in mind. In Univention Corporate Server this requires root access, whereas a domain administrator is sufficient for a Windows AD DC. Attacks such as pass the hash utilise this feature by exploiting other security vulnerabilities to procure the rights of the privileged accounts.

This can be complemented by security vulnerabilities such as MS14-068, which describes how the Microsoft Kerberos KDC implementation signatures are not correctly checked for validity and thus allow authentication data contained in Kerberos service tickets to be forged. As far as we know, Samba was not affected by this vulnerability.

The general risk can only be reduced with corresponding, organisation-wide security measures – the operative word here is “defense in depth”.

So what form can effective defense take?

The basic requirement for pass the hack attacks is a local administrative access to a domain computer. As such, it needs to be made as difficult as possible for the hacker to gain access to the domain systems. If that has already happened, he shouldn’t have any possibility of reading out the truly relevant password hashes.
As the attack patterns for Microsoft AD and Samba AD are identical in this respect, the analyses and white papers dealing with pass the hack attacks on Microsoft AD should also be consulted.

Are there any differences between the way Active Directory is implemented by Samba in UCS and by Microsoft Windows?

As already mentioned, the basic attack possibility is no different. To be compatible with Microsoft Active Directory, the existing design flaw there also needs to be implemented in Samba. The only difference is the way in which access to a domain computer can be acquired and which user accounts and hashes can be read out.
In Microsoft Windows, a local admin access is the basic requirement for this type of attack in order to be able to intercept a user’s NTLM hash initially. An equivalent in UCS/Linux would be the root access.

The standard caching of passwords in Microsoft Windows – even after the users have logged out again – does not occur on UCS systems, either for the root user or for domain users.

As pass the hash attacks require there to be unsalted password hashes (generally LM or NTLM) on the attacked systems, it is important to know where these hashes (insofar as there are any) are saved.

• On UCS DCs, all (NTLM) password hashes are in OpenLDAP and on Samba DCs additionally in SAM.ldb. For this reason, these systems require particular protection.
• On UCS systems permitting interactive user logins, there may be Kerberos credential caches under /tmp.
• Host credentials readable for root are found on all UCS systems (/etc/machine.secret, /etc/krb5.keytab).
• On all Windows DCs, the password hashes of the domain users are stored in Active Directory – in the %SystemRoot%\NTDS\Ntds.dit file to be specific.
• Local users are stored in the SAM database on Windows systems (%SystemRoot%/system32/config/SAM) – this can also be accessed via the registry.
• In addition, there are also tools available which access password hashes in the internal memory in Windows and can read them out. This makes it possible to acquire the password hash of a (previously) logged-in domain administrator on a compromised client, even though his password hash is not stored locally.

Attack vector: Lateral server hopping with the local administrator.

In Windows systems, the local administrator’s password hash can generally also be used to access further Windows systems if the same password is used there. The UCS or Linux equivalent of the local administrator is “root” and this is not a Samba/Kerberos user. As such, it is not possible to log in to a remote UCS system using a simple hash. The locally saved password hash of the root password is salted, which makes cracking the password using rainbow tables much more difficult. Nevertheless, it is recommended not to use the same root passwords on all of the systems. It is generally also practical to disable root passwords and just use sudo instead.

Alternatively/additionally, you can use SSH keys with a stronger, host-specific passphrase.

Attack vector: Lateral server hopping with a domain user’s hash.

In contrast to Windows systems, it is not possible to log in to a remote UCS system with just an NTLM hash.

However, similarly to with Windows, it is also possible in UCS to use a user’s or UCS host’s Kerberos credential cache to authenticate oneself on kerberised services of other UCS systems. The restriction of the authorisation is then decisive (e.g., via the UCR variables auth/.*/restricted and auth/.*/ ).

Attack vector: Reading out of hashes via LDAP from the Samba directory service.

In principle, this is only possible via a local socket, not via the LDAP port. It requires a local root access. The joining of an additional Samba AD or Microsoft AD DC as an attack medium represents an exception here, as AD DCs receive all password hashes via DRS replication. This requires domain administrator credentials, e.g., Kerberos hashes.

Attack vector: Reading out of hashes via LDAP from OpenLDAP.

This is protected by LDAP ACLs. By default, in addition to domain admins, all UCS DCs can also read out the hashes for LDAP replication. Since UCS 3.0, access to OpenLDAP has always required authentication. However, it must be checked whether the authentication has not been manually disabled for backward compatibility reasons (ldap/acl/read/anonymous and ldap/acl/read/ips). The replication is performed via TLS-encrypted connections.

Further elements of a defense in depth strategy

With no claim to being exhaustive:

• If Microsoft Windows clients and file servers are joined in a UCS domain, then all Microsoft recommendations apply for these systems, in particular http://blogs.microsoft.com/cybertrust/2012/12/11/new-guidance-to-mitigate-determined-adversaries-favorite-attack-pass-the-hash/ and https://technet.microsoft.com/en-us/dn785092.aspx . Windows 8.1 and Windows Server 2012 R2 also improve the security of the local login services, see http://blogs.microsoft.com/cybertrust/2014/07/08/new-strategies-and-features-to-help-organizations-better-protect-against-pass-the-hash-attacks/.
• Prevent access for regular users on DCs. This is already the standard configuration for many UCS services (UCR variables auth//restrict).
• In addition, targeted separation of the different types of accounts should also be considered.
  Disabling of the domain admin “Administrator” and use of a personalised admin account.
  Introduction of DC domain admins – who can only log in on the domain controllers.
  Introduction of client domain admins – who can only log in on the member servers and clients
  The administrators only use the admin accounts for administration, i.e., both the users and the admins perform their day-to-day work with unprivileged accounts.
• Regular, rapid and comprehensive installation of security updates.
• Full disk encryption
• Password-protected BIOS/UEFI
• Virus scanners with corresponding reporting
• Firewalls with corresponding reporting
• Intrusion detection systems with corresponding reporting
• Firewall regulations: No client-to-client communication; clients may only communicate with the requisite servers.
• Regular rotation of all passwords
• Ensure that, insofar as this is possible, only strong encryption methods/hashes are used and accepted.
• Ensure that local users (e.g., Administrator/root) cannot log in to another system remotely – especially not with the same password.
• Ensure that Windows does not cache the password hashes for longer than is absolutely necessary, especially not after the user has logged out.

Conclusion for the Bundestag hack

The same thing applies to IT security: There is no such things as 100% secure – not even in UCS. There are, however, a whole range of measures that can be taken and that, in the case of a critical infrastructure such as that of the German parliament, surely also need to be taken. Whether they really were or not will be revealed by the recently instigated enquiry.

And another thing is clear: The only thing to offer maximum transparency is Open Source software, which can be checked for possible flaws and backdoors by both the developer and the user as well as by independent third parties. This is what makes it an essential component of a highly efficient, sustainable IT security strategy.

Photo source “Deutscher Bundestag”: Groman123 / CC BY-SA 2.0