CVE-2023-32803

Executive Summary

CVE-2023-32803 is a trust-store integrity vulnerability in the Amazon Linux 2 (AL2) ca-certificates package. Versions prior to ca-certificates-2021.2.50-72 fail to properly remove certain TrustCor root certificates from the system root certificate store. The flaw stems from an incomplete/incorrect remediation of CVE-2022-23491, meaning systems that were believed to be remediated may still trust deprecated and potentially untrusted TrustCor CAs. Because the affected component is a root of trust, the impact is a full compromise of TLS certificate validation integrity (CVSS 7.5, Integrity: High) — enabling adversary-in-the-middle (AiTM) interception of TLS traffic for any host whose certificate chains to a retained TrustCor root.

The issue is not exploited in the wild per current data (no CISA KEV listing, no public PoC, EPSS 0.00183 / 8.1th percentile). The impact is architectural: trust-store drift on a widely deployed enterprise Linux distribution. Any AL2 system that applied only the earlier (incomplete) fix remains exposed and will silently accept certificates issued by the affected CA should it issue or be coerced into issuing them.

Technical Analysis

The ca-certificates package maintains the Operating System's root certificate trust store — the set of CA certificates against which all TLS/SSL validation chains are ultimately anchored. Trust is binary and transitive: any leaf certificate that chains to a trusted root is accepted by default by OpenSSL, GnuTLS, curl, Python ssl, Java, and virtually every TLS client on the host.

TrustCor Systems is a certificate authority that has been the subject of public scrutiny regarding ownership and operational ties. The remediation for CVE-2022-23491 sought to remove TrustCor roots from the Mozilla/OS trust store (root removal is propagated downstream into distributions). CVE-2023-32803 documents that the AL2 remediation was incorrect: the package before ca-certificates-2021.2.50-72 "does not properly remove certain TrustCor root certificates from the root store."

This is a classic partial-remediation defect (weakness class CWE-669 — Incorrect Resource Transfer Between Spheres). The security control (removal of an untrusted root of trust) was applied to some but not all TrustCor root certificates present in the bundle. Operationally, this means:

• The trust anchor set on the host still contains one or more TrustCor roots that should have been deleted.
• TLS clients on the host will continue to accept certificate chains terminating at those retained roots.
• The "fixed" advisory state (system appears patched at the package level) creates a false sense of security — the administrator believes the untrusted CA is gone.

The vulnerability does not require the attacker to exploit a memory-safety bug or inject code into the target. It is a misconfiguration/defect in the trust store content that converts into a cryptographic trust bypass. The attack surface is therefore any TLS connection initiated from or accepted by the affected AL2 host.

Notably, the NVD description does not specify which TrustCor root(s) remained, the exact certificate filenames retained, or the precise packaging logic that failed. Those implementation details are not available in the provided intelligence and must not be assumed; remediation should be verified empirically against the live trust store (see Mitigation below).

Exploitation Scenarios

No public PoC available; attack chain is inferred from the vulnerability class (misapplied trust-store remediation / untrusted root retention).

1. Reconnaissance / Target Identification. The adversary identifies Amazon Linux 2 hosts and determines their ca-certificates package version. AL2 version strings are frequently visible in default HTTP responses, SSH banners, package metadata exposed by misconfigured mirrors, or via authenticated host inventory. The goal is to find hosts still running a ca-certificates build below 2021.2.50-72 — i.e., systems where a TrustCor root remains trusted.

2. Triggering the Flaw-Class Condition. The adversary positions itself where it can present a certificate chain that terminates at the retained TrustCor root. Because the host's trust store still anchors that root, the clients on the host (curl, wget, openssl s_client, application TLS stacks, package managers over HTTPS, etc.) validate the presented chain as trusted rather than rejecting it.

3. Payload / Execution Method (vulnerability-class level). This is an adversary-in-the-middle / TLS-interception class of attack, not remote code execution. The attacker intercepts traffic to a victim domain and presents a certificate chain anchored to the still-trusted TrustCor root. The precise method by which an attacker obtains a leaf signed by the retained root (e.g., abuse of the CA if it is still operational, mis-issuance, or a subordinate CA the attacker controls) is not described in the available data and is not asserted here. The core mechanic is simply: the retained trust anchor causes certificate validation to succeed when it should fail.

4. Post-Exploitation Impact. Successful chain validation enables decryption, replay, and modification of TLS-protected traffic for affected endpoints — credential theft, session hijacking, injection of malicious update payloads, and interception of API tokens. The integrity subscore (CVSS I:H) reflects that all confidentiality- and integrity-dependent application behavior crossing those TLS sessions can be subverted. The host itself is not "owned" by this flaw; the trust relationships the host relies upon are.

Impact Assessment

• CVSS base score: 7.5 (High) — AV:N (network reachable), AC:L (low complexity), PR:N (no privileges required), UI:N (no user interaction), S:U (unchanged scope), C:N, I:H, A:N.
• Integrity is the dominant impact. The trust store only affects whether certificate validation succeeds or fails; the confidentiality impact is scored None at the base metric because the flaw itself does not directly disclose data — the secondary impact of AiTM interception is a consequence, not the vector's direct scoring.
• Blast radius: Every Amazon Linux 2 instance that applied the incomplete CVE-2022-23491 fix and did not subsequently upgrade to ca-certificates-2021.2.50-72+. In enterprise terms, this is grouped by fleet: build agents, CI/CD runners, egress proxies, container base images derived from AL2, and application servers.
• Fleet-level concern: AL2 is common in AWS-hosted workloads and Amazon EKS container base images. A "patched but not really" state is insidious: vulnerability scanners keying purely on the package version string of the earlier advisory may have previously reported clean. Detection should verify the actual trust-store contents, not just the RPM version.
• EPSS 0.00183 (8.1th percentile) indicates low, but non-zero, observed exploitation probability — consistent with a supply-chain trust issue requiring an active interception capability, rather than an opportunistic worm-like exploit.
• No CISA KEV listing and no public PoC: this is an intelligence-hygiene and hardening concern more than an active emergency for most organizations, but it is a prerequisite for TLS intercept, which many advanced threats (surveillance, financial fraud, nation-state collection) do opportunistically chain with.

Detection Guidance

Because no public exploit code exists and the flaw is configuration-level, detection focuses on (a) trust-store content drift on AL2 hosts and (b) evidence of AiTM interception (unexpected certificate chains anchored at TrustCor). The network rules below key on the "TrustCor" identifier in certificate subjects/issuers.

Sigma Rule

title: Amazon Linux 2 ca-certificates TrustCor Root Retention (CVE-2023-32803)
id: 7f2c1a9e-3b64-4d2a-9c11-cve202332803
status: experimental
description: Detects AL2 ca-certificates versions below ca-certificates-2021.2.50-72 that fail to remove TrustCor root certificates, and detects TrustCor strings in local trust-store files.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2023-32803
author: valtersit.com Threat Intelligence
date: 2023/01/01
logsource:
  product: linux
  service: rpm
detection:
  selection_pkg:
    CommandLine|contains:
      - "ca-certificates"
  selection_query:
    CommandLine|contains:
      - "rpm -q"
      - "rpm -qa"
      - "dnf list installed"
      - "yum list installed"
  filter_trustcor:
    CommandLine|contains:
      - "grep -Ri TrustCor"
      - "TrustCor"
  condition: selection_pkg and (selection_query or filter_trustcor)
falsepositives:
  - Legitimate administrative inventory queries
level: high

YARA Rule

rule CVE_2023_32803_AL2_TrustCor_Truststore_Retention
{
    meta:
        author = "valtersit.com Threat Intelligence"
        description = "Detects TrustCor root CA references persisting in local trust store bundles on Amazon Linux 2 (CVE-2023-32803)"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2023-32803"
        date = "2023-01-01"
        cve = "CVE-2023-32803"

    strings:
        $trustcor = "TrustCor" ascii nocase
        $root_sys = "/etc/pki/ca-trust/source/anchors/" ascii
        $pem_hdr = "-----BEGIN CERTIFICATE-----" ascii
        $org = "TrustCor Systems" ascii nocase

    condition:
        filesize < 5MB and
        (
            ($trustcor and $pem_hdr) or
            ($org and $pem_hdr and $root_sys)
        )
}

Suricata IDS Rule

alert tls any any -> any any (msg:"CVE-2023-32803 TrustCor Root CA Certificate Presented in TLS Chain (AL2 trust-store drift)"; flow:established,to_client; tls.cert_subject; content:"TrustCor"; nocase; threshold:type limit, track by_src, count 1, seconds 3600; classtype:policy-violation; reference:cve,2023-32803; reference:url,nvd.nist.gov/vuln/detail/CVE-2023-32803; sid:2023328031; rev:1;)

Note: Suricata tls.cert_subject matching for issuer/subject strings is version-dependent; where supported, supplement with tls.cert_issuer to match both directions of the chain.

Elastic Detection

// Detect AL2 hosts whose ca-certificates version is below 2021.2.50-72
// (indicates incomplete TrustCor root removal — CVE-2023-32803)
process where event.type == "start" and
  process.name in ("rpm", "dnf", "yum") and
  process.command_line : "*ca-certificates*"

// Detect TrustCor references persisting in the local trust store
process where event.type == "start" and
  process.name in ("grep", "openssl", "trust") and
  process.command_line : "*TrustCor*" and
  process.command_line : ("*ca-trust*" or "*ca-certificates*" or "*/etc/pki/*")

Splunk SPL Query

index=os sourcetype=linux_secure OR sourcetype=osquery OR sourcetype=linux_rpm
| search ca_certificates_version=* OR command_line="*ca-certificates*"
| eval vuln = if(match(ca_certificates_version, "^2021\.2\.50-(6[0-9]|7[01]).*") OR ca_certificates_version="<2021.2.50-72", "VULNERABLE_CVE-2023-32803", "OK")
| where vuln="VULNERABLE_CVE-2023-32803"
| stats count min(_time) as first_seen max(_time) as last_seen by host, ca_certificates_version
| sort -count

index=os sourcetype=linux_audit OR sourcetype=osquery
| search command_line="*TrustCor*" AND command_line=("*ca-trust*" OR "*/etc/pki/trust*" OR "*/etc/pki/ca-trust*")
| table _time, host, user, command_line

Wazuh OSSEC Rule

<group name="amazon_linux,pkg,vulnerability,cve_2023_32803,">
  <rule id="100523" level="10">
    <decoded_as>json</decoded_as>
    <field name="package.name">ca-certificates</field>
    <field name="package.version">^2021\.2\.50-(6[0-9]|7[01])</field>
    <description>CVE-2023-32803: Amazon Linux 2 ca-certificates $(package.version) retains TrustCor root certificates (trust-store integrity risk)</description>
    <mitre>
      <id>T1553.004</id>
    </mitre>
  </rule>

  <rule id="100524" level="12">
    <decoded_as>json</decoded_as>
    <field name="command">\.*TrustCor.*</field>
    <field name="command">\.*ca-trust.*</field>
    <description>CVE-2023-32803: TrustCor reference observed in local CA trust configuration</description>
    <mitre>
      <id>T1553.004</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). Although the advisory explicitly references a fixed build (ca-certificates-2021.2.50-72), no tracked source in the provided intelligence set (OSV packages, vendor fix metadata, patch-source list) confirms the artifact or its hash. Treat remediation as version-targeted but verify empirically, since this CVE exists precisely because a prior remediation was incorrect.

1. Immediate mitigations

   • Inventory: on every AL2 host, run rpm -q ca-certificates and compare against 2021.2.50-72. Flag anything lower.
   • Verify actual trust-store contents rather than trusting the version string: search the trust anchor store (e.g., under /etc/pki/ca-trust/ and the merged bundle) for any remaining TrustCor entries. If any are found, the host is still vulnerable.
   • Where TrustCor roots are found, manually remove the offending anchor files and run update-ca-trust (AL2 trust tooling) to regenerate the merged bundle. Confirm the removal then re-scan.
   • For hosts that cannot be upgraded immediately, treat all TLS trust decisions as untrusted: pin critical endpoints, enforce certificate pinning in critical applications, and terminate sensitive traffic through a hardened proxy whose own trust store is verified clean.

2. Patch / upgrade steps

   • Upgrade to ca-certificates-2021.2.50-72 or later via yum/dnf on Amazon Linux 2. Because the earlier CVE-2022-23491 fix was incomplete, do not assume a host that "already has the CVE-2022-23491 fix" is remediated — explicitly confirm the version equals/exceeds 2021.2.50-72.
   • Rebuild container base images and any golden AMIs that derive from AL2. Rebuild is required; patching a running container ephemerally does not fix the source image.
   • Re-run trust-store verification post-upgrade (rpm -q, plus a direct search for TrustCor in the trust store).

3. Long-term hardening

   • Establish certificate-pinning / CT-log monitoring for high-value endpoints so that any certificate chaining to an unexpected or deprecated root is alerted, regardless of the OS trust store state.
   • Treat root-store contents as a monitored configuration baseline: periodically diff the trust anchor set and alert on unexpected trusts.
   • Adopt a transitive-supply-chain verification posture: when a vendor advisory says "fixed," independently verify the trust artifact changed as expected rather than relying on the advisory version.
   • Feed root-CA deprecation events (Mozilla CA program changes, TrustCor removal, etc.) into a change-management workflow that reaches all Linux distributions and container images you operate, not just the platform where the CA program is documented.
   • Limit egress TLS termination points and apply consistent, verified trust stores across them to shrink the AiTM window this class of flaw represents.

References

1. NVD — CVE-2023-32803: https://nvd.nist.gov/vuln/detail/CVE-2023-32803
2. Amazon Linux Security Center — ALAS advisories for ca-certificates (Amazon Linux 2): https://alas.aws.amazon.com/ (search ca-certificates / ALAS2023)
3. CVE-2022-23491 (antecedent, incorrectly fixed issue): https://nvd.nist.gov/vuln/detail/CVE-2022-23491
4. MITRE ATT&CK — T1553.004 Subvert Trust Controls: Install Root Certificate: https://attack.mitre.org/techniques/T1553/004/
5. CWE-669 — Incorrect Resource Transfer Between Spheres: https://cwe.mitre.org/data/definitions/669.html

Exploit-in-the-wild / threat actor campaigns: No known campaigns. No PoC, no Nuclei template, no exploit code, and no CISA KEV listing are associated with this CVE in the provided intelligence. Any act of exploitation would require an active adversary-in-the-middle capability plus a leaf certificate chaining to a retained TrustCor root; no such campaign is publicly attributed at the time of writing.