National Security Agency Warns of Cyber Risk with the use of Wildcard Certificates

Written by Gokcen Tapkan
Edited by Haley Williams

ALPACA Threatens TLS Connections

Wildcard certificates are often used across different applications and domains within an enterprise. While their use is legitimate, they extend  the security risk of other servers. A recent study has shown how wildcard certificates could be misused through an ALPACA [1] attack. No, this is not about the cute alpacas. ALPACA (Application Layer Protocols Allowing Cross-Protocol Attack) is a cross-protocol attack that uses a series of techniques, including network redirection, stored XSS, and credential theft. The NSA has issued a recommendation stating that  “NSS, DoD, and DIB administrators ensure their organization’s wildcard certificate usage does not create unmitigated risks, making their web servers vulnerable to ALPACA techniques.” ^[3]

TLS and X.509 Certificate Primer

As a starting point, TLS has the advantage of being application protocol-free. Higher-level protocols, such as HTTP, FTP,  SMTP, POP3, can be transparently layered on top of the TLS protocol. TLS certificates are not just about a key and assigned server name, a.k.a CN (common name). There are many fields in a TLS certificate, such as key usage, SAN, and SNI. For example in the SAN extension, the digital certificate contains one or more hostnames or wildcard patterns for which the certificate is valid. Since TLS can offer security on top of  Layer 4 (hence its name- Transport Layer Security), any data below Layer 4, such as IP and ports, are not protected at all.

Identifying Wildcard Certificates

A wildcard certificate is denoted with an * (asterisk) before the domain name as seen below. For example, a company with a main domain address of example.com might have many public-facing servers and subdomains, such as www.example.com and smtp.example.com. In this case, a wildcard certificate assigned to *.example.com can represent all three of the  domains/subdomains, namely example.com, www.example.com, and smtp.example.com. However, this feature does not come for free, it bears inherent cybersecurity risks. A compromised server might put the security of other servers at risk. In this case, a wildcard certificate becomes a single point of failure.

Possible Cyberattacks on Wildcard Certificates

The well-known vulnerabilities of employing wildcard certificates are predicated on the breach of any one server that utilizes the certificate, or a connection downgrade exploit of any single server, which would place all other servers that that certificate can represent at risk. A malicious cyber actor who obtains control of a wildcard certificate’s private key will be able to impersonate any of the sites represented and gain access to legitimate user credentials and protected information.

A Generic Attack to Wildcard Certificates

A generic attack to wildcard certificates starts with:

1. 1. A malicious actor, man-in-the-middle (MITM), gains control of a vulnerable web server at vulnerable.example.com.

1. 1. When an enterprise user requests an application of  an internal server at enterpriseapp.example.com through TLS, the malicious actor redirects the request to vulnerable.example.com.

1. 1. Since both vulnerable.example.com and  enterpriseapp.example.com share the same certificate, the handshake completes.

1. 1. If the connection includes login credentials, the malicious actor will gain access to them and leverage them to access enterpriseapp.example.com, masquerading as the user.

How Malicious Actors Conduct ALPACA Attacks

ALPACA stands for Application Layer Protocols Allowing Cross-Protocol Attack and involves a series of complex cyberattack techniques. The reader is referred to the whitepaper for full details [1], [2]. A summary of the attack:

1. 1. The MITM attacker tricks the user into clicking an HTTPS-enabled link, for example: www.bank.com:443 crafting an FTP payload. This click triggers a cross-origin HTTPS request.

1. 1. Using the network manipulation technique, the attacker directs the connection ftp.bank.com:990. Both www.bank.com and ftp.bank.com use the same certificate through a wildcard certificate.

1. 1. The non-HTTP service (an FTP server or SMTP server) tries to process the HTTP request. However, this will create an error message in the response with the malicious payload crafted by the attacker.

1. 1. Since the same certificate signs the response, the user’s browser will accept the response, thinking it came from www.bank.com while it is actually communicating with ftp.bank.com. What does the specifically crafted FTP payload include, and what is the technique? It might be through an FTP upload or download attack. For the FTP-upload attack, the threat actor inserts any secret cookies in the header stored on the FTP server and reads access.  For the FTP-download attack, the threat actor initially prepares a valid HTTP response with a malicious JavaScript payload and stores it on the FTP server. The response is returned to the client in the download attack. ^[2]

1. 1. The malicious javascript runs within the context of www.bank.com. This process gives the malicious script access to user data and cookies for www.bank.com within the browser.

From this step on, the malicious actor has access to everything running in the user’s browser.

Recommendations to evade ALPACA and Wildcard-related Cyberattacks

While the use of wildcard certificates is legitimate, one should remember that there are always risks involved. Simply, wildcard certificates can create a  single point of failure. The NSA and Black Kite recommendations to evade the attack:

• • Administrators should evaluate their environment to verify that their certificate usage, particularly the use of wildcard certificates, does not pose an undue risk. It is best to separate the certificate for unrelated applications and protocols.

• • Use WAF. Most WAFs can filter traffic by SNI (Server Name Indication). A client may specify the server name in the SNI extension. However, if two different services run under the same SNI, then this won’t work.

• • Use ALPN extension for the servers; if the client also supports the ALPN extension, it will send only the ALPN identifiers for the designated protocols. If the server’s and client’s ALPN don’t match, the handshake aborts, making the attack unsuccessful.

• • Use DNSSEC to prevent DNS-related redirection attacks.

Black Kite checks if DNSSEC is enabled for customers’ DNS records.

• • Monitor SSL/TLS Strength for each of the digital assets.

Black Kite continuously monitors the SSL/TLS Strength for an entity. There are over 40 controls in this category ranging from the validity of a certificate, some certificate fields, and the strength of encryption and authentication suites.

Black Kite’s SSL/TLS Strength Category

The SSL/TLS Strength category carefully examines each digital certificate field, for ex: whether the URI matches with the common name (incl wildcard), the expiration date, CRL/OCSP URIs, the SAN field, etc. Below is a shortlist of some controls that  Black Kite examines on the certificates:

1. 1. The SSL certificate has expired: As the name suggests, a certificate has a validity interval. When either the “Not valid before” or “Not Valid After” fields are not satisfied, the Black Kite control yields “SSL certificate has expired.”

1. 1. Certificate No SAN, browsers are complaining: SAN extension Certificates allow you to secure a primary domain (the name indicated in the CN field) and then add additional domains to the Subject Alternative Name field of the certificate. For example, you can secure all these domains with a single SAN Certificate.

1. 1. Certificate failed (chain incomplete): A certificate is signed by a Certificate Authority (CA) to attest to its validity. A certificate chain (or Chain of Trust) is a list of certificates that start from a server’s certificate and terminate with the root certificate. In between, there are intermediate CAs. A trusted SSL certificate must have been issued by a CA, included in the trusted store of the connected device.  If an intermediate (or root) CA is not directly embedded in your web browser, the certificate cannot be explicitly trusted.

1. 1. Certificate Neither CRL nor OCSP URI provided: There are two ways to ensure whether a certificate is revoked or not. Through the Online Certificate Status Protocol (OCSP), or CRLs , where the client checks to see the revoked status of the certificate. CRLs are distributed by CAs. While OCSP – as its name suggests, is an online request-response protocol, CRLs are files that can be cashed and have intervals. Both methods have URIs indicated in a certificate’s extension fields.

1. 1. Certificate does not match supplied URI (same w/o SNI): The Common Name (a.k.a. CN) represents the server name protected by the SSL certificate. The certificate is valid only if the requested hostname matches the certificate’s common name. Most web browsers display a warning message when connecting to an address that does not match the common name in the certificate. In the case of a single-name certificate, the common name consists of a single hostname (e.g., example.com, www.example.com) or a wildcard name in the case of a wildcard certificate (e.g., *.example.com).

---

References

^[1] https://i.blackhat.com/USA21/Wednesday-Handouts/us-21-ALPACA-Application-Layer-Protocol-Confusion-Analyzing-And-Mitigating-Cracks-In-TLS-Authentication.pdf ^[2] https://alpaca-attack.com/ALPACA.pdf ^[3] https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/2804293/avoid-dangers-of-wildcard-tls-certificates-the-alpaca-technique/