What Happened
South Korea's Modu-ui Changup platform, run by the Ministry of SMEs and Startups, leaked personal information and startup business ideas for about 5,000 applicants. The cause was an encryption key exposed through an API endpoint. Once attackers found this key, they could decrypt the protected data. Authorities later identified 39 IP addresses that accessed the leaked information.
This wasn't a sophisticated attack. The encryption key was simply accessible via API.
Timeline
The public timeline is limited, but the sequence of failures is clear:
- Developers implemented encryption for sensitive applicant data.
- The encryption key was made accessible through an API endpoint.
- Attackers discovered the exposed key.
- Using the key, attackers decrypted protected records.
- Ministry officials detected unauthorized access from 39 IP addresses.
- The breach was disclosed publicly.
The gap between exposure and detection is unknown, indicating a monitoring problem.
Which Controls Failed or Were Missing
Key Separation: The platform stored or exposed encryption keys in a location accessible to the same systems that held encrypted data. If both the locked box and the key are accessible via the same API, encryption offers no protection.
API Access Controls: The API endpoint exposing the key lacked proper authentication, authorization, or even rate limiting to flag unusual access patterns. If an encryption key is retrievable via API call, your access control layer has failed.
Secrets Management: Hard-coded keys, keys in configuration files, or keys returned in API responses violate basic secrets hygiene. The platform treated the encryption key as configuration data rather than a credential needing its own protection.
Detection and Monitoring: With 39 IP addresses accessing the leaked data, there should have been alerts. Either monitoring wasn't configured to flag bulk data access, or alerts were ignored.
What the Relevant Standard Requires
PCI DSS v4.0.1 Requirement 3.6.1 states: "Cryptographic keys are managed in accordance with the following." It details that keys must be protected against unauthorized access and that access to cleartext keys must be restricted to the fewest number of custodians necessary. Exposing a key through an API violates this requirement completely.
PCI DSS v4.0.1 Requirement 3.6.1.2 specifically requires: "Access to cleartext cryptographic key components is restricted to the fewest number of custodians necessary." An API endpoint isn't a custodian. It's a public-facing service that, without proper controls, becomes an access point for anyone.
ISO/IEC 27001:2022 Annex A.8.24 (cryptographic controls) requires organizations to define and implement rules for the effective use, protection, and lifetime management of cryptographic keys. Making keys retrievable alongside the data they protect fails this control.
NIST 800-53 Rev 5 SC-12 (cryptographic key establishment and management) requires organizations to establish and manage cryptographic keys using automated mechanisms. This includes protecting keys from unauthorized disclosure. An exposed API key represents both a process failure and a technical control failure.
For SOC 2 Type II audits, this breach would trigger findings under the Confidentiality criteria (C1.1 and C1.2), which require that information designated as confidential is protected to meet the entity's objectives. If your encryption keys are exposed, you haven't met confidentiality objectives, regardless of whether the data itself was encrypted.
Lessons and Action Items for Your Team
Separate Your Keys from Your Data: Use a dedicated key management system (KMS). AWS KMS, Google Cloud KMS, Azure Key Vault, or HashiCorp Vault provide services that keep keys in a separate security boundary. Your application requests decryption operations; it never receives the raw key. This separation means compromising your application doesn't automatically compromise your keys.
Audit Your API Responses: Scan every API endpoint your application exposes. Look for secrets, keys, tokens, or credentials in response bodies. This should be part of your pre-deployment checklist. If you're returning a value that could decrypt data, you've built a vulnerability into your API contract.
Implement Envelope Encryption: Don't use a single key to encrypt all your data. Use a master key (stored in KMS) to encrypt data encryption keys (DEKs), and use DEKs to encrypt individual records or data sets. Even if a DEK leaks, it limits exposure to a subset of data, not your entire database.
Monitor Key Access Patterns: Your KMS should log every decrypt operation. Set alerts for unusual patterns: bulk decryption requests, requests from new IP ranges, or requests outside normal business hours. These logs also provide forensic evidence if you need to determine what was accessed.
Test Your Key Rotation Process: Can you rotate encryption keys without downtime? Do you have a documented procedure? Test it quarterly. If you discover an exposed key, you need to rotate immediately. That's not the time to figure out whether your rotation process works.
Review Your Secrets Management: Scan your repositories, configuration files, and environment variables for hard-coded keys. Use tools like git-secrets, TruffleHog, or GitHub's secret scanning. Better yet, implement pre-commit hooks that block commits containing potential secrets.
Map Your Encryption Inventory: Document what's encrypted, which keys protect it, where those keys are stored, and who has access. If you can't answer "where are our encryption keys?" in under 60 seconds, you don't have adequate key management.
The Modu-ui Changup breach wasn't inevitable. It resulted from treating encryption keys as configuration data rather than as credentials requiring their own security controls. Your encryption is only as strong as your key management. If attackers can retrieve the key, you haven't encrypted anything. You've just added processing overhead.
