Become Part of our Team and Push Digital Sovereignty
- Teamleader IT / Project Manager (m/f/x)
- IT Consultant (m/f/x)
- Outbound Sales Represantative (m/f/x)
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.
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?”.
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 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”.
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.
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.
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.
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/.*/ ).
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.
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.
With no claim to being exhaustive:
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
Michael began his training as an IT specialist for system integration at G&M IT-Systeme GmbH in 2007. There, he subsequently provided support for small and medium-sized enterprises in the Support, Administration and IT Security departments. He also completed further training as an IT security manager. In 2013, he joined Univention’s Professional Services Team as an Open Source Software Consultant.