[Forgot Password]
Login  Register Subscribe

30479

 
 

423868

 
 

248268

 
 

909

 
 

195051

 
 

282

Paid content will be excluded from the download.


Download | Alert*
CWE
view XML

Reliance on Security Through Obscurity

ID: 656Date: (C)2012-05-14   (M)2022-10-10
Type: weaknessStatus: DRAFT
Abstraction Type: Base





Description

The software uses a protection mechanism whose strength depends heavily on its obscurity, such that knowledge of its algorithms or key data is sufficient to defeat the mechanism.

Extended Description

This reliance on "security through obscurity" can produce resultant weaknesses if an attacker is able to reverse engineer the inner workings of the mechanism. Note that obscurity can be one small part of defense in depth, since it can create more work for an attacker; however, it is a significant risk if used as the primary means of protection.

Applicable Platforms
Language Class: All

Time Of Introduction

  • Architecture and Design
  • Implementation
  • Operation

Related Attack Patterns

Common Consequences

ScopeTechnical ImpactNotes
Confidentiality
Integrity
Availability
Other
 
Other
 
The security mechanism can be bypassed easily.
 

Detection Methods
None

Potential Mitigations

PhaseStrategyDescriptionEffectivenessNotes
Architecture and Design
 
 Always consider whether knowledge of your code or design is sufficient to break it. Reverse engineering is a highly successful discipline, and financially feasible for motivated adversaries. Black-box techniques are established for binary analysis of executables that use obfuscation, runtime analysis of proprietary protocols, inferring file formats, and others.
 
  
Architecture and Design
 
 When available, use publicly-vetted algorithms and procedures, as these are more likely to undergo more extensive security analysis and testing. This is especially the case with encryption and authentication.
 
  

Relationships

Related CWETypeViewChain
CWE-656 ChildOf CWE-907 Category CWE-888  

Demonstrative Examples   (Details)

  1. The design of TCP relies on the secrecy of Initial Sequence Numbers (ISNs), as originally covered in CVE-1999-0077. If ISNs can be guessed (due to predictability, CWE-330) or sniffed (due to lack of encryption, CWE-311), then an attacker can hijack or spoof connections. Many TCP implementations have had variations of this problem over the years, including CVE-2004-0641, CVE-2002-1463, CVE-2001-0751, CVE-2001-0328, CVE-2001-0288, CVE-2001-0163, CVE-2001-0162, CVE-2000-0916, and CVE-2000-0328.

Observed Examples

  1. CVE-2006-6588 : Reliance on hidden form fields in a web application. Many web application vulnerabilities exist because the developer did not consider that "hidden" form fields can be processed using a modified client.
  2. CVE-2006-7142 : Hard-coded cryptographic key stored in executable program.
  3. CVE-2005-4002 : Hard-coded cryptographic key stored in executable program.
  4. CVE-2006-4068 : Hard-coded hashed values for username and password contained in client-side script, allowing brute-force offline attacks.

For more examples, refer to CVE relations in the bottom box.

White Box Definitions
None

Black Box Definitions
None

Taxynomy Mappings
None

References:

  1. Jerome H. Saltzer Michael D. Schroeder .The Protection of Information in Computer Systems. Proceedings of the IEEE 63. Published on September, 1975.
  2. Sean Barnum Michael Gegick .Never Assuming that Your Secrets Are Safe. Published on 2005-09-14.

© SecPod Technologies