Reliance on Security Through Obscurity
Draft Class
Structure: Simple
Description
The product 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.
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.
Common Consequences 1
Scope: ConfidentialityIntegrityAvailabilityOther
Impact: Other
The security mechanism can be bypassed easily.
Potential Mitigations 2
Phase: 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.
Phase: 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.
Demonstrative Examples 1
ID : DX-168
The design of TCP relies on the secrecy of Initial Sequence Numbers (ISNs), as originally covered in CVE-1999-0077 [REF-542]. If ISNs can be guessed (due to predictability, Use of Insufficiently Random Values) or sniffed (due to lack of encryption during transmission, Cleartext Storage of Sensitive Information), 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 4
CVE-2006-6588Reliance 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.
CVE-2006-7142Hard-coded cryptographic key stored in executable program.
CVE-2005-4002Hard-coded cryptographic key stored in executable program.
CVE-2006-4068Hard-coded hashed values for username and password contained in client-side script, allowing brute-force offline attacks.
References 3
The Protection of Information in Computer Systems
Jerome H. Saltzer and Michael D. Schroeder
Proceedings of the IEEE 63
09-1975
ID: REF-196
Never Assuming that Your Secrets Are Safe
Sean Barnum and Michael Gegick
14-09-2005
ID: REF-544
RFC: 793, TRANSMISSION CONTROL PROTOCOL
Jon Postel, Editor
Information Sciences Institute
09-1981
https://www.ietf.org/rfc/rfc793.txt(2023-04-07)
ID: REF-542
Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Modes of Introduction
Architecture and Design
Implementation
Alternate Terms
Never Assuming your secrets are safe
Related Weaknesses
CanPrecede:
Use of Hard-coded Password (CWE-259)
CanPrecede:
Use of Hard-coded Cryptographic Key (CWE-321)
Notes
RelationshipNote that there is a close relationship between this weakness and Use of Client-Side Authentication (Use of Client-Side Authentication). If developers do not believe that a user can reverse engineer a client, then they are more likely to choose client-side authentication in the belief that it is safe.