From zero to Enterprise Administrator through the Network Device Enrollment Service (NDES) - and what can be done about it

In the following, I would like to present a highly dangerous PKI configuration, perhaps not necessarily known to the general public, which can probably be encountered quite frequently in this way in corporate networks.

I show how, by exploiting various unfortunate circumstances in the Windows PKI, it is possible to elevate privileges from mere network access to complete Active Directory takeover.

The initial point of attack in this example is the Network Device Enrollment Service (NDES).

The following steps should never be performed in a production environment. The demonstration performed here is not a guide to breaking into computer systems; rather, it is intended to highlight the security risk so that countermeasures can be initiated.

The Network Device Enrollment Service (NDES) provides a way for devices that do not have an identifier in Active Directory (for example, network devices such as routers, switches, printers, thin clients, or smartphones and tablets) to request certificates from a certification authority. For a more detailed description, see the article "Network Device Enrollment Service (NDES) Basics„.

The initial situation

The surroundings

The attacked company operates a network device enrollment service (NDES). This is configured so that certificate requests Without password can be used, because according to the system operators the end devices cannot handle a challenge password (or this is too much work for them).

The NDES server is accessible via port 80 and 443 (with SSL) can be reached from the network. The URL for the certificate request is:

http://{NDES-Server}/certsrv/mscep

This address can also be accessed with a browser.

There is no indication in the presented HTML response whether the NDES requires a password or not. If one attempts a certificate request against an NDES server that requires a password, without a password or with the wrong password, the Event no. 29 logged on the NDES server, which triggers or should trigger an alarm.

The certificates applied for by the NDES and issued by the certification authority contain the extended key usage for "Client Authentication" because the end devices use it to log on to the network or establish a VPN tunnel and authenticate themselves with the certificate.

According to the default settings, the certification authority is integrated into the NTAuthCertificates object in Active Directory been recorded.

The Domain controllers are equipped with appropriate certificates to enable LDAP connections via SSL, among other things. Since the domain controller certificates correspond to the default settings, the environment is thus also suitable for Smartcard Login activated.

The attacker

The attacker has gained access to the network, for example, by physically accessing a network port, connecting via Wifi, or by initially infecting an internal computer.

As software he only needs a regular computer and a regular client for the SCEP-protocol. Under Windows this can be for example the integrated certreq.exe or the PSCertificateEnrollment PowerShell module, under Linux the sscep Package.

The attack

For illustrative purposes, the PSCertificateEnrollment PowerShell module was used. To be on the safe side, this procedure could be performed with any other client for the SCEP protocol.

Request certificate

The attacker applies for a certificate via the NDES server.

Since neither NDES nor the certification authority behind it checks the requested identity, the user specifies the user principal name (UPN) of an administrative account (in this example, the predefined administrator account is used).

Get-NDESCertificate `
-PrivateKeyExportable `
-ComputerName "ndes.adcslabor.de" `
-Upn "Administrator@intra.adcslabor.de"

Maybe the port 80 for certificate request is restricted to the specific IP addresses to be used, so that no certificate request via HTTP is possible. However, maybe the server has an SSL certificate and can be reached via port 443?

He is issued a corresponding certificate by the certification authority via the NDES server.

To be able to cover his tracks better at this point, the attacker could also specify a supposedly legitimate subject string, which would be displayed in the certification authority database. The Subject Alternative Name, which contains the identity of the Active Directory account, is not indexed in the certification authority database.

Log in as Enterprise Administrator

The attacker can now log on to the network as an administrator using this certificate, e.g. via Import of the certificate into a smart card.

Since the domain controllers accept the "Client Authentication" extended key usage for smartcard logins (by default, the extended key usages are not even validated at all), logging in with the certificate is possible without any problems.

Already now, the attacker has complete control over the environment. However, the certificate used for logging in is still in the certification authority database, where it could still be discovered (although not easily).

The attacker could therefore now log on directly to the certification authority with the administrative identity. He could then obtain a new certificate directly through Use of the private key of the certification authority.

Since this signature bypassed the certification authority software and the key storage provider was accessed directly, this certificate cannot be found in the certification authority database. Likewise, no Audit event about a certificate issue generated.

Ultimately, the attacker could still use the certificate originally applied for via NDES to Delete from the certification authority database.

Provided auditing is enabled, deleting a certificate from the certification authority database would not change the Event no. 4896 trigger. However, the attacker could (which would again trigger an event) also delete the audit log on the certification authority.

From this point on, at the latest, the attacker would be able to move around the corporate network almost unnoticed.

Countermeasures

In principle, it should be avoided to operate an NDES server without a password. Rather, it should be evaluated whether it is not possible to (in case of doubt at least daily) to use changing passwords. However, one should not be lulled into a false sense of security, even with password "protection". authentication via SCEP is still very superficial.
If possible, NDES servers should never be exposed to the entire network. Rather, access should be restricted as much as possible.
It makes sense to regularly evaluate the certificates issued by certification authorities to which an NDES server is connected and to search for deviations. In order to be able to realize this, however, the rule case (permissible certificate contents) must already be defined before the NDES server is put into operation.
A restriction of the allowed certificate content can be achieved by using the TameMyCerts Policy module on the certification authority.
Certification authorities to which an NDES server is connected should always be excluded from the NTAuthCertificates object in Active Directory to be removed.
If no smart card registration is used, the domain controller certificates should also not contain corresponding extended key usages.
For the events of the Certification Authority and of the Network Device Enrollment Service monitoring of suspicious events should be set up, and an alert should be triggered.

From Zero to Enterprise Administrator through Network Device Enrollment Service (NDES) - and What to Do About It