Secret leaks often occur when a sensitive piece of authentication data is stored with the source code of an application. Considering the source code is intended to be deployed across multiple assets, including source code repositories or application hosting servers, the secrets might get exposed to an unintended audience.
In most cases, trust boundaries are violated when a secret is exposed in a source code repository or an uncontrolled deployment environment. Unintended people who don’t need to know the secret might get access to it. They might then be able to use it to gain unwanted access to associated services or resources.
The trust issue can be more or less severe depending on the people’s role and entitlement.
SSH private keys are used for authentication and secure communication in SSH (Secure Shell) protocols. They are a form of asymmetric cryptography, where a pair of keys is generated: a private key and a corresponding public key. SSH keys provide a secure and efficient way to authenticate and establish secure connections between clients and servers. They are widely used for remote login, file transfer, and secure remote administration.
When an SSH private key is leaked to an unintended audience, it can have severe consequences for security and confidentiality. One of the primary outcomes is unauthorized access. The unintended audience can exploit the leaked private key to authenticate themselves as the legitimate owner, gaining unauthorized entry to systems, servers, or accounts that accept the key for authentication. This unauthorized access opens the door for various malicious activities, including data breaches, unauthorized modifications, and misuse of sensitive information.
Revoke the secret
Revoke any leaked secrets and remove them from the application source code.
Before revoking the secret, ensure that no other applications or processes is using it. Other usages of the secret will also be impacted when the secret is revoked.
Analyze recent secret use
When available, analyze authentication logs to identify any unintended or malicious use of the secret since its disclosure date. Doing this will allow determining if an attacker took advantage of the leaked secret and to what extent.
This operation should be part of a global incident response process.
Depending on the information system the key is used to authenticate against, the audit method might change. For example, on Linux systems, the system-wide authentication logs could be used to audit recent connections from an affected account.
Use a secret vault
A secret vault should be used to generate and store the new secret. This will ensure the secret’s security and prevent any further unexpected disclosure.
Depending on the development platform and the leaked secret type, multiple solutions are currently available.
String key = """
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW
QyNTUxOQAAACDktj2RM1D2wRTQ0H+YZsFqnAuZrqBNEB4PpJ5xm73nWwAAAJgJVPFECVTx
RAAAAAtzc2gtZWQyNTUxOQAAACDktj2RM1D2wRTQ0H+YZsFqnAuZrqBNEB4PpJ5xm73nWw
AAAECQ8Nzp6a1ZJgS3SWh2pMxe90W9tZVDZ+MZT35GjCJK2uS2PZEzUPbBFNDQf5hmwWqc
C5muoE0QHg+knnGbvedbAAAAFGdhZXRhbmZlcnJ5QFBDLUwwMDc3AQ==
-----END OPENSSH PRIVATE KEY-----""";
String key = System.getenv("SSH_KEY");