diff --git a/rules/S6706/secrets/rule.adoc b/rules/S6706/secrets/rule.adoc index 260e7d9b43..c41afdc3a6 100644 --- a/rules/S6706/secrets/rule.adoc +++ b/rules/S6706/secrets/rule.adoc @@ -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 diff --git a/rules/S7203/metadata.json b/rules/S7203/metadata.json new file mode 100644 index 0000000000..2c63c08510 --- /dev/null +++ b/rules/S7203/metadata.json @@ -0,0 +1,2 @@ +{ +} diff --git a/rules/S7203/secrets/metadata.json b/rules/S7203/secrets/metadata.json new file mode 100644 index 0000000000..1d1d04fbca --- /dev/null +++ b/rules/S7203/secrets/metadata.json @@ -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" +} diff --git a/rules/S7203/secrets/rule.adoc b/rules/S7203/secrets/rule.adoc new file mode 100644 index 0000000000..38dbd7965f --- /dev/null +++ b/rules/S7203/secrets/rule.adoc @@ -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 diff --git a/shared_content/secrets/fix/store_separatly.adoc b/shared_content/secrets/fix/store_separatly.adoc new file mode 100644 index 0000000000..51345f2b51 --- /dev/null +++ b/shared_content/secrets/fix/store_separatly.adoc @@ -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. diff --git a/shared_content/secrets/impact/private_key_disclosure.adoc b/shared_content/secrets/impact/private_key_disclosure.adoc new file mode 100644 index 0000000000..f3c6be217f --- /dev/null +++ b/shared_content/secrets/impact/private_key_disclosure.adoc @@ -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. \ No newline at end of file