Insufficient Granularity of Access Control in GAEN Notification Server

Vulnerability

The Exposure Notifications Verification Server, part of Google's COVID-19 Exposure Notifications system, contains an access control vulnerability in versions prior to 1.1.2 [1][2]. The server provides verification codes (short numeric codes or longer SMS codes) that expire quickly (usually under one hour for short codes, up to 24 hours for SMS codes) [2]. The vulnerability occurs in the code expiration functionality: users or API keys with permission to expire verification codes could expire codes belonging to another realm if they guessed the UUID of that code [3][4]. This is due to insufficient granularity of access control — the server did not properly scope code expiration requests to the caller's realm [4].

Exploitation

An attacker needs to have a user account or API key with the permission to expire verification codes [3][4]. The attacker must also know or guess the 64-bit UUID of a verification code belonging to another realm [4]. No other authentication or user interaction is required beyond having the relevant permission and the UUID. The attack can be carried out by sending a code expiration request with the targeted UUID, which the server will process without verifying that the code belongs to the caller's realm [3][4].

Impact

A successful attacker can prematurely expire a verification code that belongs to a different realm, making that code unusable [1]. This prevents the patient associated with that code from uploading their Temporary Exposure Keys (TEKs) to generate exposure notifications [1][4]. The impact is a denial of service (availability) on the exposure notification process for the affected patient. There is no indication of exploitation in the wild [4], and verification codes are valid for very short periods, which limits the window of opportunity and makes UUID guessing more difficult [4].

Mitigation

The vulnerability is fixed in version 1.1.2 of the Exposure Notifications Verification Server, released on an unspecified date [3][4]. Users should upgrade to v1.1.2 or greater [1][3][4]. There are no workarounds available [4]. The project has since been archived (as of July 2023) [2], but affected instances still in use should apply the patch. This CVE is not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog.