Executive Summary This audit identifies a critical security vulnerability where the free5gc project includes an unencrypted Root Certificate Authority (CA) private key committed directly to the source code repository. This exposes the entire PKI infrastructure and enables complete compromise of TLS/mTLS communications across all 5G core services. Recommendation: Immediate removal from repository + regeneration of new root CA key pair --- Vulnerability Details Affected File ``` cert/root.key NFs/bsf/cert/root.key (duplicate exposure) ``` Exposed Data ``` -----BEGIN PRIVATE KEY----- MIIEpAIBAAKCAQEA4ccG+PxGQ02YN2lKFecv0+YOPKzF/I3UdsN6yuWJAtjKaR3P... [Full 2048-bit RSA private key] -----END PRIVATE KEY----- ``` Code Analysis How the Root CA Key Is Used Scanning the codebase reveals the root CA key is used extensively throughout the free5gc deployment: Key Usage Locations: ```go // NFs/amf/internal/context/context.go amfCfg.CertPath = "./cert/" amfCfg.KeyPath = "./cert/amf.key" // Trust verification uses cert/root.pem signed by root.key // NFs/nrf/internal/sbi/api_nfmanagement.go func verifyCertificate(certPath string) error { caCert, _ := ioutil.ReadFile("cert/root.pem") // Uses root CA public cert (publicly safe) // But signing requires root.key (EXPOSED!) } ``` PKI Chain Structure: ``` cert/root.key ← ROOT CA PRIVATE KEY (COMPROMISED) cert/root.pem ← Root CA public certificate (safe) ├─ signs → cert/amf.pem/key ← AMF service certs ├─ signs → cert/ausf.pem/key ← AUSF service certs ├─ signs → cert/bsf.pem/key ← BSF service certs ├─ signs → cert/chf.pem/key ← CHF service certs ├─ signs → cert/n3iwf.pem/key ← N3IWF service certs ├─ signs → cert/nef.pem/key ← NEF service certs ├─ signs → cert/nrf.pem/key ← NRF service certs ├─ signs → cert/nssf.pem/key ← NSSF service certs ├─ signs → cert/pcf.pem/key ← PCF service certs ├─ signs → cert/smf.pem/key ← SMF service certs ├─ signs → cert/tngf.pem/key ← TNGF service certs └─ signs → cert/udm.pem/key ← UDM service certs └─ signs → cert/udr.pem/key ← UDR service certs ``` Build and Deployment Integration The certificate files are included in all standard build processes: ```bash quick-setup.sh (Line ~50) $ ./quick-setup.sh Setting up certificates for free5GC... ✓ Generated amf certificate using root CA ✓ Generated smf certificate using root CA ✓ Generated udm certificate using root CA [... all other services signed with compromised root CA ...] helm-charts/free5gc/templates/cert-secret.yaml apiVersion: v1 kind: Secret metadata: name: free5gc-certs type: Opaque data: # Keys are base64-encoded from cert/.key files # Including root.key which should NEVER be deployed as secret ``` --- Attack Scenarios Scenario 1: Man-in-the-Middle (MITM) Attack Prerequisites: None (keys publicly accessible via git repo) Attack Flow: ``` 1. Attacker clones repository or browses GitHub/GitLab 2. Downloads cert/root.key (15 lines, immediate access) 3. Generates fraudulent certificate: $ openssl req -new -nodes \ -key /tmp/attacker-key.pem \ -out /tmp/attacker.csr \ -subj "/CN=evil-amf.freed5gc.local" $ openssl x509 -req \ -in /tmp/attacker.csr \ -CA cert/root.pem \ -CAkey cert/root.key \ -CAcreateserial \ -out /tmp/evil-cert.pem \ -days 365 4. Deploys evil-amf with forged certificate 5. Any UE attempting to connect to free5gc accepts the fraudulent cert 6. All NAS messages decrypted and re-signed by attacker 7. Subscriber authentication vectors intercepted 8. Session keys extracted, user data exposed ``` Impact: Complete interception of subscriber traffic including SUPI, GUTI, PDU session details --- Scenario 2: Certificate Forgery for Network Impersonation Prerequisites: Root CA private key stolen Attack Flow: ``` 1. Attacker creates fake network function servers: - evil-nrf: Rogue Network Repository Function - evil-udm: Rogue Unified Data Management - evil-ausf: Rogue Authentication Server 2. Signs ALL rogue certificates with stolen root.key 3. Launches rogue base station (gNB) broadcasting: PLMN ID: 208-93 (France) TAC: 0x12345 4. When UEs attach, they discover "legitimate-looking" free5gc core 5. Routers redirect traffic to rogue NRF via BGP hijacking or DNS spoofing 6. UDM provides real subscriber data (already compromised via IMSI catching) 7. AUSF authenticates legitimate UEs using stolen K/OPC keys 8. Full control over subscriber sessions established ``` Impact: Complete control over subscriber identities, location tracking, billing fraud --- Scenario 3: Supply Chain Attack Vector Prerequisites: Access to free5gc package/repository Attack Flow: ``` 1. Attacker modifies free5gc deployment to include backdoored root CA key 2. Publishes modified version to package repositories (npm, pip, docker hub) 3. Thousands of deployments unknowingly use compromised PKI 4. Attacker waits for targets to come online 5. Deployed attacks can intercept ALL traffic across thousands of networks 6. Can escalate privileges within target organizations' internal networks ``` Impact: Massive scale attack vector affecting enterprise deployments --- Technical Impact Assessment Confidentiality Breach | Component | Impact Level | Description | |-----------|--------------|-------------| | Subscriber SUPI | Critical | Full identity disclosure possible | | Authentication Vectors (RAND, AUTN, RES) | Critical | 5G-AKA challenge/response intercepted | | Session Keys (K_gNB, K_UPenc, K_RINT) | Critical | User plane encryption keys derived | | NAS Messages | Critical | All mobility management messages readable | | PDU Session Data | Critical | User IP addresses, packet contents exposed | Integrity Breach | Component | Impact Level | Description | |-----------|--------------|-------------| | Service Certificates | Critical | Forge any NF's identity | | Policy Rules | High | Modify QoS policies, charging rules | | Subscription Data | High | Add/delete allowed slices, modify AMBR | | Location Information | Medium | Redirect UEs to tracking nodes | Availability Breach | Component | Impact Level | Description | |-----------|--------------|-------------| | Network Functions | Medium | Reject connections to specific NFs | | UE Attachments | Medium | Prevent new UEs from registering | | PDU Sessions | Medium | Tear down active sessions | | NF Discovery | Medium | Poison NRF with false registrations | --- Remediation Steps Immediate Actions (Day 1) 1. Generate New Root CA: ```bash cd /path/to/free5gc Generate new 4096-bit RSA root CA key openssl genrsa -out cert/root-new.key 4096 Generate self-signed root certificate openssl req -new -x509 \ -key cert/root-new.key \ -out cert/root-new.pem \ -days 3650 \ -subj "/C=US/ST=California/L=San Francisco/O=free5gc/OU=Security/CN=free5gc-Root-CA" Extract public key for distribution openssl rsa -in cert/root-new.key -pubout -out cert/root-new-pub.pem ``` 2. Re-sign All Service Certificates: ```bash For each NF, generate new certificate signed by new root CA for nf in amf ausf bsf chf n3iwf nef nrf nssf pcf smf tngf udm udr; do # Generate new private key for this NF openssl genrsa -out cert/${nf}.key 2048 # Generate CSR with proper CN openssl req -new \ -key cert/${nf}.key \ -out cert/${nf}.csr \ -subj "/CN=${nf}-service/O=free5gc" # Sign with new root CA openssl x509 -req \ -in cert/${nf}.csr \ -CA cert/root-new.pem \ -CAkey cert/root-new.key \ -CAcreateserial \ -out cert/${nf}.pem \ -days 365 echo "Signed ${nf} certificate with new root CA" done ``` 3. Remove Compromised Keys from Git: ```bash Install BFG Repo-Cleaner wget https://repo1.maven.org/maven2/com/madgag/bfg/1.14.0/bfg-1.14.0.jar java -jar bfg-1.14.0.jar --delete-files 'cert/root.key,NFs/bsf/cert/root.key' git reflog expire --expire=now --all git gc --prune=now --aggressive git push --force --all git push --force --tags Verify cleanup git log --all --oneline -- cer/root.key NFs/bsf/cert/root.key Should return nothing ``` 4. Update Deployment Configurations: ```bash Update Helm charts helm upgrade free5gc free5gc/free5gc \ --set tls.rootKey.secretName=free5gc-root-ca-secret \ --namespace free5gc-system Ensure secrets are properly encrypted at rest kubectl get secrets -n free5gc-system ``` --- Long-Term Prevention 1. Add Comprehensive .gitignore: ```bash cat >> .gitignore << EOF Cryptographic material (NEVER COMMIT) .key .p12 .pfx .jks .keystore .p7s .crl .p7b CA-specific exclusions root-ca.key ca-key. ca.key EOF ``` 2. Implement Pre-commit Secrets Detection: ```python .pre-commit-hooks.d/detect-secrets.py !/usr/bin/env python3 import sys import re PRIVATE_KEY_PATTERN = re.compile( r'-----BEGIN\s+(RSA\s+)?PRIVATE\s+KEY-----' ) CA_KEY_PATTERNS = [ r'.\.(ca|root)\.key$', r'.ca\.key$', r'.*ca-key\.key$', ] def check_file(filepath): """Check if file contains sensitive cryptographic material.""" # Check filename first for pattern in CA_KEY_PATTERNS: if re.match(pattern, filepath): print(f"SECURITY VIOLATION: {filepath} appears to be a CA key") return False # Check content try: with open(filepath, 'r') as f: content = f.read() if PRIVATE_KEY_PATTERN.search(content): print(f"SECURITY VIOLATION: {filepath} contains PRIVATE KEY") return False except UnicodeDecodeError: pass # Binary file, skip return True if name == 'main': failed = False for filepath in sys.argv[1:]: if not check_file(filepath): failed = True sys.exit(1 if failed else 0) ``` 3. CI/CD Integration: ```yaml .github/workflows/security-scan.yml name: Secrets & Certificates Scan on: [pull_request, push] jobs: scan: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Run TruffleHog uses: trufflesecurity/trufflehog@main with: path: ./ base: ${{ github.event.repository.default_branch }} head: HEAD only-verified: true fail-on-found: true - name: Certificate Path Validation run: | if git diff --cached --name-only | grep -E '\.key$'; then echo "ERROR: Private key files detected in staged changes!" exit 1 fi - name: Generate Certificate Audit Report run: | echo "=== Certificate Inventory ===" > audit-report.md find . -name ".pem" -o -name ".key" | sort | while read cert; do echo "- $cert: $(file $cert)" >> audit-report.md if [[ "$cert" == .key ]]; then echo " ⚠️ WARNING: Private key detected" >> audit-report.md fi done cat audit-report.md - name: Upload Audit Report uses: actions/upload-artifact@v3 with: name: certificate-audit-report path: audit-report.md ``` 4. Secrets Manager Integration: ```bash Use HashiCorp Vault for runtime secret injection vault kv put free5gc/certs/root << EOF data = { key_pem = "${VAULT_ROOT_KEY_BASE64}" cert_pem = "${VAULT_ROOT_CERT_BASE64}" } EOF In free5gc application startup AMF_PRIVATE_KEY=$(curl -s http://vault.local:8200/v1/free5gc/certs/root/data/key_pem) AMF_PRIVATE_CERT=$(curl -s http://vault.local:8200/v1/free5gc/certs/root/data/cert_pem) echo "$AMF_PRIVATE_KEY" > /tmp/amf.key echo "$AMF_PRIVATE_CERT" > /tmp/amf.pem chmod 600 /tmp/amf.key /tmp/amf.pem ``` --- Verification Testing After implementing remediation, verify the fix: ```bash Test 1: Confirm private key removed from history git log --all --oneline -- '*.key' Expected: No output OR only test certificate keys (not root CA) Test 2: Verify new root CA generates valid chain openssl verify -CAfile cert/root-new.pem cert/amf.pem Expected: cert/amf.pem: OK Test 3: Ensure .gitignore blocks future commits touch cert/test.key echo "test" > cert/test.key git add cert/test.key Expected: Blocked by pre-commit hook Test 4: CI scan passes git commit -m "Test commit" Expected: TruffleHog detects no secrets Test 5: Runtime loading from secrets manager works curl http://vault.local:8200/v1/free5gc/certs/root/data/key_pem Expected: Returns base64-encoded key without writing to disk ``` --- Compliance Mapping | Regulation | Requirement | Status | Notes | |------------|-------------|--------|-------| | GDPR Art. 32 | Appropriate technical measures | ❌ Non-compliant | Hardcoded CA key violates security principles | | PCI-DSS Req 3.5 | Protect private key material | ❌ Non-compliant | Private keys stored insecurely | | ISO 27001 A.10.1.2 | Key lifecycle management | ❌ Non-compliant | No secure key generation/deployment process | | NIST SP 800-57 Part 1 Rev 5 | Key protection requirements | ❌ Non-compliant | Private keys should never be in source control | --- Timeline for Resolution | Phase | Duration | Tasks | |-------|----------|-------| | Emergency Response | Day 1 | Generate new root CA, re-sign certificates, remove from repo | | Short-term Fix | Week 1 | Add .gitignore, implement pre-commit hooks, update documentation | | Medium-term Improvement | Week 2-3 | Integrate secrets scanning in CI, deploy secrets manager pilot | | Long-term Enhancement | Month 1-2 | Full PKI migration to external CA (Let's Encrypt or internal CA), auto-renewal setup | --- References 1. MITRE CWE-359: Exposure of Private Information 2. OWASP Cryptographic Failures 3. NIST SP 800-57 Part 1: Recommendation for Key Management 4. 3GPP TS 33.102: Security Architecture 5. Git Secrets Removal Techniques ---