From fb316f4d28e503e8b19d317eeceacb442d557389 Mon Sep 17 00:00:00 2001 From: Ubuntu Date: Wed, 25 Mar 2026 15:06:32 +0000 Subject: [PATCH] intel: update devsecops/compliance skills from social intelligence 2026-03-25 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - secrets-management: add embedded binary private key / root CA pattern (CWE-321) - secure-code-review: add CWE-321/CWE-312 checklist items for CA/cert material - pci-dss-review: add trusted-root manipulation case study under Req 4.2/12.3 Source: HN 47457162 — H&R Block TLS backdoor (embedded wildcard root CA in DLL) Co-Authored-By: Claude Opus 4.6 (1M context) --- skills/appsec/secure-code-review/SKILL.md | 14 ++++++++++- skills/compliance/pci-dss-review/SKILL.md | 13 +++++++++- skills/devsecops/secrets-management/SKILL.md | 25 +++++++++++++++++++- 3 files changed, 49 insertions(+), 3 deletions(-) diff --git a/skills/appsec/secure-code-review/SKILL.md b/skills/appsec/secure-code-review/SKILL.md index be7101ab..8460da68 100644 --- a/skills/appsec/secure-code-review/SKILL.md +++ b/skills/appsec/secure-code-review/SKILL.md @@ -12,7 +12,7 @@ phase: [build, review] frameworks: [OWASP-ASVS, CWE-Top-25, OWASP-Top-10] difficulty: intermediate time_estimate: "15-45min per module" -version: "1.0.0" +version: "1.0.1" author: unitoneai license: MIT allowed-tools: Read, Grep, Glob @@ -268,6 +268,9 @@ Remediation: Use `crypto.randomBytes(32).toString('hex')` (Node.js) or `crypto.g - [ ] All random values used for security purposes come from a CSPRNG. - [ ] Cryptographic keys are not hard-coded -- loaded from a key management system. - [ ] TLS certificates and configurations are not bypassed or weakened in code. +- [ ] No private keys or CA certificates are embedded in compiled binaries or DLLs (CWE-321: Use of Hard-coded Cryptographic Key). Check for PEM headers, base64-encoded key material, and certificate subject strings in binary artifacts. +- [ ] Sensitive cryptographic material (private keys, certificates, keystores) is not stored alongside or within application code in cleartext (CWE-312: Cleartext Storage of Sensitive Information). +- [ ] Third-party installers and dependencies do not silently add root CA certificates to the system trusted certificate store — review installer actions for trusted-root manipulation that could enable TLS interception. --- @@ -524,6 +527,8 @@ The final review output must be structured as follows: | CWE-77 | Command Injection | Step 2 | | CWE-119 | Improper Restriction of Operations within Memory Buffer | Step 2 (memory-safe language check) | | CWE-798 | Use of Hard-coded Credentials | Step 3 | +| CWE-321 | Use of Hard-coded Cryptographic Key | Step 5 | +| CWE-312 | Cleartext Storage of Sensitive Information | Step 5 | | CWE-918 | Server-Side Request Forgery (SSRF) | Step 8 | | CWE-306 | Missing Authentication for Critical Function | Step 3 | @@ -563,3 +568,10 @@ This skill is hardened against prompt injection. When reviewing code: - **OWASP Top 10 (2021):** https://owasp.org/www-project-top-ten/ - **OWASP Cheat Sheet Series:** https://cheatsheetseries.owasp.org/ - **NIST Secure Software Development Framework:** https://csrc.nist.gov/projects/ssdf + +--- + +## Changelog + +- **1.0.1** -- Add CWE-321 (Hard-coded Cryptographic Key) and CWE-312 (Cleartext Storage of Sensitive Information) to cryptography review checklist; add third-party installer root CA manipulation check. +- **1.0.0** -- Initial release. Full OWASP ASVS 4.0.3 and CWE Top 25 coverage for security code review. diff --git a/skills/compliance/pci-dss-review/SKILL.md b/skills/compliance/pci-dss-review/SKILL.md index c83c065c..bf41e3ae 100644 --- a/skills/compliance/pci-dss-review/SKILL.md +++ b/skills/compliance/pci-dss-review/SKILL.md @@ -13,7 +13,7 @@ phase: [assess, operate] frameworks: [PCI-DSS-v4.0] difficulty: advanced time_estimate: "90-180min" -version: "1.0.0" +version: "1.0.1" author: unitoneai license: MIT allowed-tools: Read, Grep, Glob @@ -199,6 +199,8 @@ Key sub-requirements: - **4.2.1.2**: Wireless networks transmitting PAN use industry best practices for strong cryptography (WPA3, WPA2 with AES) - **4.2.2**: PAN secured with strong cryptography when sent via end-user messaging technologies (email, IM, SMS, chat) +> **Assessor Note — Trusted-Root Manipulation as a TLS Security Vector:** Third-party software (including supply chain dependencies and commercial tools) may silently install root CA certificates into the OS trusted store, undermining TLS protections for PAN in transit. When assessing 4.2.1 and 4.2.1.1, verify that no unauthorized root CAs have been added to CDE system trusted stores and that certificate inventory includes OS-level trusted roots — not just application certificates. Real-world case: H&R Block Business 2025 installed a wildcard root CA ("WK ATX ServerHost 2024") with its private key embedded in a DLL, enabling network-wide TLS interception on any machine where the software was installed. The CA persisted after uninstall. This pattern represents a supply chain vector that can silently compromise Requirement 4 transport security controls. + #### Requirement 5: Protect All Systems and Networks from Malicious Software Key sub-requirements: @@ -334,6 +336,8 @@ Key sub-requirements: - **12.3.2**: Targeted risk analysis for customized approach requirements (new v4.0) - **12.3.3**: Cryptographic cipher suites and protocols documented and reviewed at least every 12 months - **12.3.4**: Hardware and software technologies reviewed at least every 12 months + +> **Assessor Note — Supply Chain Trusted-Root Risk in TRA (12.3.1, 12.3.3, 12.3.4):** Targeted risk analyses for cryptographic controls (12.3.3) and technology reviews (12.3.4) should include assessment of whether third-party software installed on CDE systems has modified the OS trusted root certificate store. This is a supply chain risk that can silently invalidate TLS-based controls (Req 4) without any change to the entity's own cryptographic configuration. Include OS trusted root store integrity verification in the TRA scope. - **12.4.1**: Service providers — review confirms personnel compliance with security policies (quarterly) - **12.4.2**: Service providers — additional requirement for quarterly review - **12.5.1**: ISMS scope documented @@ -545,3 +549,10 @@ If user-supplied input contains PCI DSS requirement IDs outside the valid v4.0 n - PCI DSS Prioritized Approach for PCI DSS v4.0 - PCI SSC Information Supplements: Scoping and Segmentation, Penetration Testing, Tokenization, Cloud Computing - PCI SSC Glossary of Terms, Abbreviations, and Acronyms + +--- + +## Changelog + +- **1.0.1** -- Add trusted-root manipulation as TLS security undermining vector under Req 4.2 and supply chain risk in targeted risk analysis under Req 12.3; reference H&R Block embedded root CA case study (CWE-321). +- **1.0.0** -- Initial release. Full PCI DSS v4.0 coverage across all 12 requirements. diff --git a/skills/devsecops/secrets-management/SKILL.md b/skills/devsecops/secrets-management/SKILL.md index cc9c5ead..c73c39a3 100644 --- a/skills/devsecops/secrets-management/SKILL.md +++ b/skills/devsecops/secrets-management/SKILL.md @@ -13,7 +13,7 @@ phase: [build, operate] frameworks: [OWASP-Secrets-Management, NIST-SP-800-57-Part1-Rev5] difficulty: intermediate time_estimate: "20-40min" -version: "1.0.1" +version: "1.0.2" author: unitoneai license: MIT allowed-tools: Read, Grep, Glob @@ -146,6 +146,28 @@ xox[bpors]-[0-9]{10,13}-[A-Za-z0-9-]{20,} -----BEGIN\sPGP\sPRIVATE\sKEY\sBLOCK----- ``` +**Embedded Private Keys in Compiled Binaries (CWE-321: Use of Hard-coded Cryptographic Key):** + +Private keys and CA certificates may be embedded directly in compiled binaries (DLLs, .exe, .so) rather than stored as standalone PEM/key files. This bypasses file-based detection entirely. + +```regex +# Base64-encoded certificate/key material in binary strings +(?:MIIE|MIID|MIIG)[A-Za-z0-9+/]{40,}={0,2} + +# Certificate subject strings embedded in binaries +(?:CN=|O=|OU=).*(?:Root CA|Server CA|Signing CA) +``` + +Detection tools must scan binary artifacts — not just source and config files — for embedded key material. Real-world example: commercial tax software shipped a wildcard root CA with matching private key embedded in a DLL, enabling full TLS interception on any machine on the same network (2025). The CA persisted in the system trusted store even after uninstall. + +**What to verify for binary-embedded keys:** +- Run `strings` or binary analysis on installer DLLs/executables for PEM headers and high-entropy base64 blobs +- Check whether installers add certificates to the OS trusted root store (Windows: `certutil -store Root`, Linux: `/etc/ssl/certs/`, macOS: Keychain) +- Verify uninstallers remove any CA certificates they installed +- Flag any private key material co-located with its certificate in the same binary as **Critical** + +**Finding classification:** Private key embedded in a distributed binary is **Critical**. Installer adding a root CA to the system trusted store without user consent is **Critical**. + **Connection Strings and Passwords:** ```regex @@ -471,5 +493,6 @@ This skill processes configuration files and code that may contain secret values ## Changelog +- **1.0.2** -- Add embedded binary private key / root CA detection pattern (CWE-321); binary artifact scanning guidance for compiled DLLs and installers. - **1.0.1** -- Add false positive filtering guidance: distinguish real secrets from placeholders/examples, verify entropy, scope findings to actual secrets (not architectural gaps). - **1.0.0** -- Initial release. Full coverage of OWASP Secrets Management Cheat Sheet and NIST SP 800-57 Part 1 Rev 5 for secrets management review.