Examkin

Question

Difficulty: Very hardCryptographic and Security Control Weaknesses

During a comprehensive enterprise security architecture assessment of a cloud-native platform, an auditor identified several critical cryptographic and security control deficiencies across different operational subsystems. Match each identified security deficiency on the left with its corresponding root cause vulnerability or architectural flaw on the right.

  • A legacy API gateway accepting incoming TLS 1.0 connections using 3DES in cipher block chaining (CBC) mode with SHA-1 signatures.Cryptographic algorithm weakness susceptible to collision attacks and Sweet32 block size birthday paradox exploits.
  • An internal identity provider accepting JWT authentication tokens signed with asymmetric public keys evaluated under symmetric HMAC algorithms.Algorithm confusion vulnerability leading to signature bypass and unauthorized token forgery.
  • A microservices application cluster relying exclusively on corporate IP subnet filtering for service-to-service access without end-to-end identity checks.Implicit trust boundary defect relying on perimeter controls rather than continuous cryptographic verification.
  • An enterprise certificate authority storing root private keys directly on a standard server OS filesystem protected only by local DACLs.Insecure key management lacking Hardware Security Module (HSM) protection and tamper-resistant storage.

Answer

The 3DES TLS gateway matches the Sweet32 collision weakness; the identity provider key mismatch matches the algorithm confusion vulnerability; the IP subnet microservices restriction matches the implicit perimeter reliance defect; and the Root CA key on filesystem matches the insecure key management lacking HSM protection.
Each security weakness is mapped to its underlying technical vulnerability: 3DES CBC and SHA-1 suffer from collision flaws (Sweet32); JWT public key verification under HMAC leads to algorithm confusion forgery; IP-based microservice boundaries suffer from perimeter-reliance defects; and software filesystem storage of Root CA keys represents weak key management lacking HSM protection.

Step-by-Step Solution

1
Analyze the cryptographic cipher flaws in the legacy TLS configuration.
Identify that 3DES uses 64-bit blocks vulnerable to Sweet32 collision attacks and SHA-1 is cryptographically broken.
64-bit block ciphers in CBC mode expose session keys to collision attacks after approximately 32 GB of data.
2
Evaluate the authentication token key misconfiguration.
Recognize key confusion where public keys are treated as symmetric secrets to forge signatures.
In algorithm confusion attacks (e.g., RS256 swapped to HS256), the receiver verifies an HMAC using the public key, enabling signature forgery.
3
Examine the network segment access control strategy for microservices.
Identify perimeter reliance and failure to enforce Zero Trust microsegmentation and mutual TLS (mTLS).
Subnet IP checks create implicit trust zones susceptible to IP spoofing and lateral movement.
4
Review the PKI root private key storage mechanism.
Classify software-based private key storage without hardware isolation as inadequate key protection.
Root CA private keys require specialized cryptographic hardware (HSMs) to prevent unauthorized exfiltration.

Key Concept

Cryptographic and Security Control Weaknesses
Rate this question

Topics

Cryptographic and Security Control Weaknesses

More questions from this topic