GitHub's system enables organizations to install various applications that automate processes and access selected repositories. However, a noteworthy risk arises from the private keys these apps employ for authentication; they can remain operational for extended periods unless actively revoked. Recent findings by GitGuardian revealed an alarming number of 474 valid GitHub App private keys among 4,802 that have been publicly exposed since 2019.
If compromised, these keys can grant malicious actors full administrative rights over an organization’s GitHub account. GitGuardian highlighted that 72% of the exposed apps could read private repository content, and 207 apps had the ability to write to private repositories. This could enable an attacker to leverage a single leaked key for a complete organizational takeover, as detailed by GitGuardian researcher Gaetan Ferry.
A notable example involved the “Access Tokens for GitHub Actions” app, which accidentally exposed its private key in January 2024 due to a repository miscommit. This blunder could impact around 300 organizations, including major companies like Civica and Sierra Nevada Corp.
Other affected applications included BuildBuddy, Crusher.dev, and a private app linked to the US Centers for Disease Control and Prevention, underscoring the broadened implications of such security flaws.
Exploiting Vulnerable Keys
Agnidipta Sarkar, chief evangelist at security software provider ColorTokens, indicated that exploiting these vulnerabilities can be alarmingly simple. Attackers need just the valid private key and its corresponding App ID to execute their plans. The potential for damage amplifies as perpetrators might inject malicious code into repositories. This becomes particularly problematic when deployed code endangers other users or production environments.
Moreover, attackers could modify CI/CD runner configurations, allowing them to execute arbitrary code within the internal network of an organization, thereby posing an even greater threat.
Following the discovery of these leaks, GitGuardian took prompt action by notifying the owners of the affected applications and highlighted its own secret-scanning services, which utilize a GitHub App for continuous monitoring of leaks.
Varied Access Among Leaked Apps
The access rights associated with these exposed keys vary significantly. GitGuardian reported that 40 affected apps could manage self-hosted runners, 98 had control over workflows, and 44 possessed organization-level administration privileges. This level of access allows an attacker to install themselves as an organization owner, effectively locking out legitimate administrators and taking complete control.
Among the identified apps, some had extensive installations—one app boasted 303 installations—while a significant number of others had only one, indicating a tendency for private use. Ferry emphasized that such internal tools often fall off the radar, remaining operational even when forgotten by their creators, which allows their associated keys to remain valid indefinitely.
Compounding this issue, GitGuardian identified 156 instances where a leaked private key appeared in unrelated repositories, making it difficult to trace their association back to the original GitHub App.
Ferry stressed the grave implications of these leaks: the impact rolls out beyond the owner of the app to all organizations that have installed it, as well as to every downstream user connected through its supply chain.
The Importance of Key Rotation
Despite GitHub's guidelines warning that private keys do not automatically expire, the reality is many organizations neglect the need to revoke or delete outdated keys, often due to misconceptions around their operational mechanics. When a GitHub App is installed, it generates a private key used to sign JSON Web Tokens (JWTs), which GitHub recognizes for issuing short-term installation access tokens with predefined permissions.
These JWTs have short lifespans of mere minutes, alongside installation tokens valid for just an hour, creating a misleading perception of low risk regarding lost keys. Yet, with access to the private key, anyone could create an infinite number of JWTs, enabling continuous generation of fresh installation tokens as long as the key remains valid.
Sarkar remarked that this design choice may be an intentional trade-off prioritizing operational simplicity, leaving the responsibility of key rotation solely on app developers. GitGuardian advocates for frequent key rotation or revocation as best practices to mitigate long-term risks, emphasizing that keys linked to forgotten applications can linger indefinitely, as exemplified by keys committed in 2020 still holding significance today.
However, Sarkar pointed out that manual revocation of keys is rarely practiced until there's a security incident, audit, or a crucial operational change necessitates it. It brings to light a critical gap in security awareness and management within many organizations.
This article first appeared on InfoWorld.
