Create rule S7203: Java Keystore files should not disclose cryptographic private keys (#4685)
This commit is contained in:
github-actions[bot]
GitHub
parent
c3d5e7ae01
commit
df5229c7be
@ -6,31 +6,7 @@ include::../../../shared_content/secrets/rationale.adoc[]
|
||||
|
||||
=== What is the potential impact?
|
||||
|
||||
A cryptographic private key is a piece of sensitive information that is used in
|
||||
asymmetric cryptography. They are used in conjunction with public keys to secure
|
||||
communications and authenticate digital signatures.
|
||||
|
||||
Private keys can be used to achieve two main cryptographic operations,
|
||||
encryption or digital signature. Those operations are the basis of multiple
|
||||
higher-level security mechanisms such as:
|
||||
|
||||
* User authentication
|
||||
* Servers authentication, for example in the X509 trust model
|
||||
* E-mail encryption
|
||||
|
||||
Disclosing a cryptographic private key to an unintended audience can have severe
|
||||
security consequences. The exact impact will vary depending on the role of the
|
||||
key and the assets it protects.
|
||||
|
||||
For example, if the key is used in conjunction with an X509 certificate to
|
||||
authenticate a web server as part of TLS communications, attackers will be able
|
||||
to impersonate that server. This leads to Man-In-The-Middle-Attacks that would
|
||||
affect both the confidentiality and integrity of the communications from clients
|
||||
to that server.
|
||||
|
||||
If the key was used as part of e-mail protocols, attackers might be able to send
|
||||
e-mails on behalf of the key owner or decrypt previously encrypted emails. This
|
||||
might lead to sensitive information disclosure and reputation loss.
|
||||
include::../../../shared_content/secrets/rationale.adoc[]
|
||||
|
||||
== How to fix it
|
||||
|
||||
|
||||
2
rules/S7203/metadata.json
Normal file
2
rules/S7203/metadata.json
Normal file
@ -0,0 +1,2 @@
|
||||
{
|
||||
}
|
||||
61
rules/S7203/secrets/metadata.json
Normal file
61
rules/S7203/secrets/metadata.json
Normal file
@ -0,0 +1,61 @@
|
||||
{
|
||||
"title": "Java Keystore files should not disclose cryptographic private keys",
|
||||
"type": "VULNERABILITY",
|
||||
"code": {
|
||||
"impacts": {
|
||||
"SECURITY": "BLOCKER"
|
||||
},
|
||||
"attribute": "TRUSTWORTHY"
|
||||
},
|
||||
"status": "ready",
|
||||
"remediation": {
|
||||
"func": "Constant\/Issue",
|
||||
"constantCost": "30min"
|
||||
},
|
||||
"tags": [
|
||||
"cwe",
|
||||
"cert"
|
||||
],
|
||||
"defaultSeverity": "Blocker",
|
||||
"ruleSpecification": "RSPEC-7203",
|
||||
"sqKey": "S7203",
|
||||
"scope": "All",
|
||||
"securityStandards": {
|
||||
"CWE": [
|
||||
798,
|
||||
259
|
||||
],
|
||||
"OWASP": [
|
||||
"A3"
|
||||
],
|
||||
"CERT": [
|
||||
"MSC03-J."
|
||||
],
|
||||
"OWASP Top 10 2021": [
|
||||
"A7"
|
||||
],
|
||||
"OWASP Mobile Top 10 2024": [
|
||||
"M1",
|
||||
"M2",
|
||||
"M10"
|
||||
],
|
||||
"PCI DSS 3.2": [
|
||||
"6.5.10"
|
||||
],
|
||||
"PCI DSS 4.0": [
|
||||
"6.2.4"
|
||||
],
|
||||
"ASVS 4.0": [
|
||||
"2.10.4",
|
||||
"3.5.2",
|
||||
"6.4.1"
|
||||
],
|
||||
"STIG ASD_V5R3": [
|
||||
"V-222642"
|
||||
]
|
||||
},
|
||||
"defaultQualityProfiles": [
|
||||
"Sonar way"
|
||||
],
|
||||
"quickfix": "unknown"
|
||||
}
|
||||
77
rules/S7203/secrets/rule.adoc
Normal file
77
rules/S7203/secrets/rule.adoc
Normal file
@ -0,0 +1,77 @@
|
||||
include::../../../shared_content/secrets/description.adoc[]
|
||||
|
||||
== Why is this an issue?
|
||||
|
||||
include::../../../shared_content/secrets/rationale.adoc[]
|
||||
|
||||
=== What is the potential impact?
|
||||
|
||||
include::../../../shared_content/secrets/impact/private_key_disclosure.adoc[]
|
||||
|
||||
include::../../../shared_content/secrets/impact/supply_chain_attack.adoc[]
|
||||
|
||||
If a third party gets access to a keystore containingan Android upload key or app signing key, this person could sign and distribute malicious apps under the same identity as the original app.
|
||||
|
||||
== How to fix it
|
||||
|
||||
include::../../../shared_content/secrets/fix/store_separatly.adoc[]
|
||||
|
||||
include::../../../shared_content/secrets/fix/revoke.adoc[]
|
||||
|
||||
In most cases, if the key is used as part of a larger trust model (X509, PGP,
|
||||
etc), it is necessary to issue and publish a revocation certificate. Doing so
|
||||
will ensure that all people and assets that rely on this key for security
|
||||
operations are aware of its compromise and stop trusting it.
|
||||
|
||||
include::../../../shared_content/secrets/fix/recent_use.adoc[]
|
||||
|
||||
include::../../../shared_content/secrets/fix/vault.adoc[]
|
||||
|
||||
=== Code examples
|
||||
|
||||
==== Noncompliant code example
|
||||
|
||||
[source,shell,diff-id=1,diff-type=noncompliant]
|
||||
----
|
||||
keytool -genkey \
|
||||
-keystore release.jks \
|
||||
-alias release \
|
||||
-keyalg RSA \
|
||||
-keysize 2048 \
|
||||
-validity 1000 \
|
||||
-dname "CN=com.example" \
|
||||
-storepass release # Noncompliant, keystore password is easy to guess
|
||||
----
|
||||
|
||||
==== Compliant solution
|
||||
|
||||
Keychain files whould created using a strong password.
|
||||
|
||||
[source,shell,diff-id=1,diff-type=compliant]
|
||||
----
|
||||
echo $STRONG_PWD | keytool -genkey \
|
||||
-keystore release.jks \
|
||||
-alias release \
|
||||
-keyalg RSA \
|
||||
-keysize 2048 \
|
||||
-validity 1000 \
|
||||
-dname "CN=com.example"
|
||||
----
|
||||
|
||||
Files containing cryptographic key should not be commitied with the application codebase and should be distributed separatly.
|
||||
|
||||
//=== How does this work?
|
||||
|
||||
//=== Pitfalls
|
||||
|
||||
//=== Going the extra mile
|
||||
|
||||
== Resources
|
||||
|
||||
include::../../../shared_content/secrets/resources/standards.adoc[]
|
||||
|
||||
* OWASP - https://owasp.org/www-project-mobile-top-10/2023-risks/m1-improper-credential-usage[Mobile Top 10 2024 Category M1 - Improper Credential Usage]
|
||||
* OWASP - https://owasp.org/www-project-mobile-top-10/2023-risks/m2-inadequate-supply-chain-security[Mobile Top 10 2024 Category M2 - Inadequate Supply Chain Security]
|
||||
* OWASP - https://owasp.org/www-project-mobile-top-10/2023-risks/m10-insufficient-cryptography[Mobile Top 10 2024 Category M10 - Insufficient Cryptography]
|
||||
|
||||
//=== Benchmarks
|
||||
4
shared_content/secrets/fix/store_separatly.adoc
Normal file
4
shared_content/secrets/fix/store_separatly.adoc
Normal file
@ -0,0 +1,4 @@
|
||||
**Store cryptographic keys separately**
|
||||
|
||||
Store private key separately from the main codebase, even if they are in a password protected format.
|
||||
It will avoid unecessary exposure and mitigate the risk of private key being leaked if the password is compromised.
|
||||
27
shared_content/secrets/impact/private_key_disclosure.adoc
Normal file
27
shared_content/secrets/impact/private_key_disclosure.adoc
Normal file
@ -0,0 +1,27 @@
|
||||
==== Cryptographic private key disclosure
|
||||
|
||||
A cryptographic private key is a piece of sensitive information that is used in
|
||||
asymmetric cryptography. They are used in conjunction with public keys to secure
|
||||
communications and authenticate digital signatures.
|
||||
|
||||
Private keys can be used to achieve two main cryptographic operations,
|
||||
encryption or digital signature. Those operations are the basis of multiple
|
||||
higher-level security mechanisms such as:
|
||||
|
||||
* User authentication
|
||||
* Servers authentication, for example in the X509 trust model
|
||||
* E-mail encryption
|
||||
|
||||
Disclosing a cryptographic private key to an unintended audience can have severe
|
||||
security consequences. The exact impact will vary depending on the role of the
|
||||
key and the assets it protects.
|
||||
|
||||
For example, if the key is used in conjunction with an X509 certificate to
|
||||
authenticate a web server as part of TLS communications, attackers with network access will be able
|
||||
to impersonate that server. This leads to Man-In-The-Middle-Attacks that would
|
||||
affect both the confidentiality and integrity of the communications from clients
|
||||
to that server.
|
||||
|
||||
If the key was used as part of e-mail protocols, attackers might be able to send
|
||||
e-mails on behalf of the key owner or decrypt previously encrypted emails. This
|
||||
might lead to sensitive information disclosure and reputation loss.
|
||||
Loading…
x
Reference in New Issue
Block a user