|
|
Design Principle Violation: Reliance on Security through Obscurity Status: Draft Weakness ID: 656 (Weakness Base)Description Summary The strength of a security mechanism depends heavily on its obscurity, such that knowledge of its algorithms or key data is sufficient to allow the mechanism to be compromised. 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. Alternate Terms Never Assuming your secrets are safe Weakness Ordinalities Primary (where the weakness exists independent of other weaknesses) Causal Nature Implicit Common Consequences Confidentiality Integrity Availability The security mechanism can be bypassed easily. Potential Mitigations 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. 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 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. ReferencesJon Postel, Editor. "RFC: 793, TRANSMISSION CONTROL PROTOCOL". Information Sciences Institute. September 1981. <http:/ Observed Examples
Other Notes Note that there is a close relationship between this weakness and CWE-603 (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. References Jerome H. Saltzer and
Michael D. Schroeder. "The Protection of Information in Computer Systems". Proceedings of the IEEE 63. September, 1975. <http:/ Sean Barnum and
Michael Gegick. "Never Assuming that Your Secrets Are Safe". 2005-09-14. <https:/ Relationships
Applicable Platforms Languages All Time of Introduction  Architecture and Design Implementation OperationContent History Submissions Pascal Meunier. Purdue University. 2008-01-18. (External Submission) Modifications Eric Dalci. Cigital. 2008-07-01. (External) updated Time_of_Introduction CWE Content Team. MITRE. 2008-09-08. (Internal) updated Common_Consequences, Description, Relationships, Other_Notes, Weakness_Ordinalities |
|
|
|||
