Stork 1.15.1 and https vulnerabilities

A serious HTTPS vulnerability prompted us to check on the security of communications between Stork agents and the Stork server. We found a significant vulnerability, which we fixed in Stork version 1.15.1 and disclosed with CVE-2024-28872.

The changes we made in Stork 1.15.1 limit access to gRPC commmunications to applications that have been previously authorized.

OVERVIEW: An attacker can pretend to be a new Stork agent, send a Certificate Signing Request to the Stork server and then use the certificate generated by the server to attack legitimate agents by using the general HTTP/2 vulnerability covered by VU-421644. Furthermore, the attacker can send any commands to Kea, via the agent, including disruptive changes (e.g. config-write, config-set, shutdown).

DETAILS: Stork uses gRPC for communication between the Stork server and the Stork agents. This connection is secured with TLS. The communication between the server and the agents is unidirectional. The servers initiate the connections to the agents. The agents do not initiate connections to the server over gRPC. The Stork server should be the only application able to connect to the agents. The agents must refuse connections via gRPC from any source other than the Stork server.

The Stork server generates two sets of certificates: the Certificate Authority (CA) certificate and the server certificate. The former is used to sign the signing requests (CSR) from the registering agents. The latter is used to communicate between the server and the agents. The server certificate is signed with the CA certificate.

In Stork 1.15.1 we fixed a security vulnerability whereby an attacker could generate and send a CSR to the Stork server to obtain a certificate signed with the Stork server’s CA certificate, and subsequently use this certificate to communicate with other registered agents over gRPC. The attacked agents didn’t properly recognize that the communication was established by an attacker rather than the Stork server.

The code fix involves several code changes. The most significant change is that when a registering agent sends the CSR to the server to sign its certificate, the server, besides the signed agent certificates, returns a fingerprint computed from the server’s certificate. The agent stores this fingerprint and compares it with the fingerprints computed from the certificates of the parties trying to connect to it over gRPC. If the fingerprints don’t match, the agent rejects the connection. It means that only the Stork server can effectively connect to the agents. Any other party trying to connect to the agent would present a different certificate with a different fingerprint.

The fixed version also puts some additional requirements on the certificates used in the gRPC communication. Specifically, the server sets the Extended Key Usage extensions to serverAuth and clientAuth in the generated server certificate. The presence of these extensions in the certificate presented by the Stork server is verified by the Stork agents. The agent certificates signed by the server include the serverAuth extension, whose presence is verified by the Stork server. Finally, the CA certificate must include the following Key Usage extensions: keyCertSign, digitalSignature, and the following Extended Key Usage extensions: clientAuth and serverAuth. Due to these new requirements, the existing server certificates are regenerated after the upgrade to the new Stork release. The agents must be re-registered to obtain the certificates signed using the regenerated server certificate and to obtain the server certificate fingerprint. Any externally generated server certificates that don’t meet the aforementioned requirements must be manually regenerated and imported to Stork using the stork-tool program.