An Introduction to Common Weakness Enumeration (CWE) for CIO and CISO - Part 1 | Lucideus Research

Common Weakness Enumeration (CWE), is a classification of weaknesses which can either be a faulty configuration in the hardware or vulnerabilities present in the software, according to where they are and how they harm different IT assets in possession of an organization. The official website[1]  states the following:


“CWE™ is a community-developed list of common software security weaknesses. It serves as a common language, a measuring stick for software security tools, and as a baseline for weakness identification, mitigation, and prevention efforts.”

Why CWE?

According to the records of National Vulnerability Database, and statistics presented therein, in 2017 there were 14,647 vulnerabilities reported which accounted for a bare 0.57% of the total data possessed by them, while in 2016 this number was 6447. The database is large and the number of vulnerabilities contained within are rising exponentially. It might not be feasible to test every piece of hardware and software, in possession of an organization with sensitive data, for all of these vulnerabilities. The problem becomes further complicated because of the time it takes to keep the security tools updated with the latest updates in the database itself. To cope up with this, one needs to turn to tools which are intelligent enough to reprogram themselves to accommodate the updated data within the database providing the functionalities utilizing the most updated knowledge available. These intelligent tools requires the knowledge on how to distinguish one vulnerability from other and how to tackle the weaknesses when encountered. 

They will also require the knowledge on how to categorize the similar type of vulnerabilities together into categories so as to facilitate the identification, mitigation, and prevention efforts as is stated above. The mitigation and prevention efforts would require the inter-relationship between these weaknesses to acquire the ability to fully understand and if possible simulate the attack paths that the attacker can take to reach from an entry point to a desired target exploiting a series of assets in between, and whether they will be able to reach such paths. This type of attack will also help identify the critical attack assets that can facilitate the largest number of attack paths, and to identify the required “zero-day vulnerabilities” to be present in a sequence of asset to turn it into an attack path. For any intelligent tool CWE is a way to learn to understand what are the different types of weaknesses that can be exploited by the attackers to intrude and exploit the IT stack of any organization. Thus, understanding this, these tools would be able to bring in the intelligence into the domain of cybersecurity. 

What are the features offered by CWE?

The weaknesses as described by Mitre in CWE schema[2] is, “...a mistake or condition that, if left unaddressed, could under the proper conditions contribute to a cyber-enabled capability being vulnerable to attack, allowing an adversary to make items function in unintended ways.” 

The CWE schema is basic outline of how the data about weaknesses is present in different form. The content related to the weaknesses is as shown in the following snippet taken from the CWE schema directly.

This snippet about the weakness includes the following properties to be attached to the weaknesses:

1. Description
2. Extended_Description
3. Related_Weaknesses
4. Weakness_Ordinalities
5. Applicable_Platforms
6. Background_Details
7. Alternate_Terms
8. Modes_Of_Introduction
9. Exploitation_Factors
10. Likelihood_Of_Exploit
11. Common_Consequences
12. Detection_Methods
13. Potential_Mitigations
14. Demonstrative_Examples
15. Observed_Examples
16. Functional_Areas
17. Affected_Resources
18. Taxonomy_Mappings
19. Related_Attack_Patterns
20. References
21. Notes
22. Content_History

The content present here, at a sufficiently matured state, will provide a user the basic understanding of the interrelationship between different weaknesses that can be exploited in combination or in sequence to produce the desired result. Through this information, one would also be able to identify automatically the assets which are vulnerable, what are the sources of the weaknesses, what might be the possible consequences on attacks, what are the possible mitigations that can be applied to mitigate the associated risk among other things. A few of these features might be used directly into the security tools for their basic functioning. 

One of the listed weaknesses here is “Improper Restriction of Excessive Authentication Attempts” placed in CWEs at id CWE-307. Let us explore the data provided for this weakness here in details:

CWE-307: Improper Restriction of Excessive Authentication Attempts

Description

The data on mitre’s website starts with following description on their website for this weakness:

“The software does not implement sufficient measures to prevent multiple failed authentication attempts within in a short time frame, making it more susceptible to brute force attacks.”

This weakness, according to mitre page itself, was first listed in 2008-07-01 and the weakness is among the most prominent of the weaknesses considering its 21st rank in the “CWE/SANS Top 25 Most Dangerous Software Errors” and how it is still an issue considering this report from November 2016. 

Relationships

It is not easy to describe all of the weaknesses as a list of independent weaknesses with no relationship between each other at all, because doing that impediment the usability of such characterisation because some of the categories becomes too specific and others too broad making it difficult for us to put them into different footing. Therefore, we categories the weaknesses as we perceive as humans and try to interrelate them. That is what is done by the creators of CWEs and is what we see in the section called Relationships for the different CWE instances marking them as ChidOf, ParetOf, and MemberOf of other CWEs. For CWE-307 under consideration here the mappings are as follows:

Improper Restriction of Excessive Authentication Attempts is basically a way of Improper Control of Interaction Frequency as the former is just a way to restrict the excessive interactions which can be exploited in brute force attacks. It is also Improper Authentication protocol as authentication which require more than a fixed number of attempts should require alternative authentication protocol because the secret sharing should not require more than a fixed number of attempts. 

Lastly, Improper Restriction of Excessive Authentication Attempts is a member of the category called Authenticate Actor because it is a characteristic of the members of that category.

Mitre is not identifying anything else in terms of relationships over here making these three node the minimal one is required to refer to for achieving the basic understanding of this weakness. 

Modes of IntroductionMitre points out that this particular weakness is introduced into the products in the Architecture and Design phase of the Software Development Life Cycle(SDLC). It further states that the weakness refers to an incorrect design related to an architecture security tactic.

Through this information it is clear that the stage where one needs to pay more attention to is Architecture and Design phase of the SDLC if one is looking to avoid this kind of weaknesses. Also, using this information an intelligent program will know that it needs to segregate this type of weaknesses to that particular phase for the correction. Another thing an intelligent application would require is to judge the platforms in which the weakness might occur. This is addressed by the following section of mitre:

• Applicable Platform : For this particular weakness, CWE-307, the applicable platforms is marked in the class “Language-Independent”. This implies the weakness might be discovered in any software written in any language. Thus indicating that the automation tools should check for this weakness in all the softwares.
  
• Common Consequences : A weakness cannot be addressed as such without mentioning the consequences that it might inflict upon exploitation. The section called common consequences addresses this side of the weakness in terms of three factors:
  - Scope: scope talks about the general scope of the security area which is violated
  - Impact: is the negative tecnihical impact that would result upon exploitation of the weakness, and
  - Likelihood: indicates the likelihood of the occurrence of the specific consequence against others in the list.

Of course, as the title indicates the common consequence is a list of consequences as opposed to a single one.

For CWE-307, the indicated consequence is just one with Scope as Access Control, indicating that the weakness is in the Access control which is the control to protect the access rights of one user against other. The technical impact is indicated as Bypass 

Protection Mechanism, along with a description “An attacker could perform an arbitrary number of authentication attempts using different passwords, and eventually gain access to the targeted account.” This aptly describes what an attacker is able to do when exploiting this weakness. 

As this is the only weakness in the category, the likelihood factor is left blank. 

Demonstrative Examples

In this section, mitre gives the examples to demonstrate the weakness by sighting real life examples, or code snippets that demonstrates the occurrences of the weaknesses. For CWE-307 mitre has given 5 examples as follows:

• Twitter Example, wherein an attacker was able to gain administrative access to a twitter server in January 2009, because the server did not restrict the number of login attempts. [twitter]
  
• A bad Java Example, where the requested username and password is directly passed into the authentication method without any restriction on number of times it can do so.
  
• A bad PHP example, where an attempt is made to resolve the weakness by introducing a sleep process which is unfortunately not capable enough to avoid parallel connections and hence not effective enough to increase the amount of time an attacker needs to complete the attack.
  
• A bad C/C++ example, where a method called validate User is created that will continuously check for a valid username and password without any restriction on the number of authentication attempts made.
  
• The final example is a good C/C++ method which limits the number of authentication attempts made to prevent brute force attack by keeping a counter which is allowed to go only upto a “MAX_ATTEMPTS”. 

Observed ExamplesThis sections provides a list of vulnerabilities found in the National Vulnerabilities Database with Common Vulnerability Enumeration(CVEs) listed with CWE-307 as weakness as follows:

• CVE-1999-1324
• CVE-1999-1152
• CVE-2001-1291
• CVE-2001-0395
• CVE-2001-1339
• CVE-2002-0628

This is a list of six products reported to have the weakness CWE-307 reported in the years between 1999-2002. This is helpful in keeping a track of all the products which were found to be vulnerable to this weakness.

Potential MitigationWhen talking about a weakness one should also be worried about the mitigation approaches and that is what is addressed in this section along with the phase where they can be implemented.

Mitre states that the CWE-307 can be mitigated only in the Architecture and Design Phase either directly by one of the following:

1. Disconnecting the user after a small number of failed attempts,
2. Implementing a timeout,
3. Locking out a targeted account, or
4. Requiring a computational task on the user’s part. Or by depending on a “Strategy: Library or Frameworks”, i.e. to use a library with authentication capabilities such as OpenSSL or the ESAPI Authenticator.

Detection MethodsAnother factor to be considering the discussion about a weakness is the talk on Detection Methods, i.e. how one can detect the presence of the given weakness in a system. This sections often refers to the procedures mentioned in IDA’s State-of-the-Art Resources(SOAR) for software vulnerability detection, test, and Evaluation[SOAR]. For CWE-307, the detection methods given by mitre are as follows:

Other major sections describe the relationship of the specific CWEs with the memberships that they have in other such enumerations or taxonomies.

Conclusion The effectiveness of the common weakness enumeration cannot be questioned. It provides ample of data describing all the aspects that can describe a weakness and its related factors. If one is to construct a knowledge base for an intelligent system then they can use this information to teach the system to “understand” weaknesses, and employ the knowledge thus gained to strategize against them and if possible mitigate them. The effectiveness of this system can be seen through the discussion on the CWE-307: Improper Restriction of Excessive Authentication Attempts. The knowledge provided by mitre on this particular weakness is ample enough for one to prepare against this weakness. Within these pages one can find the description of the weakness, consequences on exploitation, demonstrative examples, observed examples, potential mitigation measures, and detection methods among other things. The weakness described here is simple enough to occur but highly impactful on exploitation. It is easy to see that a developer with proper awareness would always be able to create protective mechanisms which are at least free of this weakness.