The Most Important CWEs and CAPECs to Pay Attention to When Building Software
On July 28th, 2021, a joint Cybersecurity Advisory was released by the U.S. Cybersecurity and Infrastructure Security Agency (CISA), the Australian Cyber Security Centre (ACSC), the United Kingdom’s National Cyber Security Centre (NCSC), and the U.S. Federal Bureau of Investigation (FBI) that covered the top routinely exploited vulnerabilities. These were listed by their Common Vulnerability Enumeration (CVE) number in the report.
This led me to think, what are the vulnerabilities’ underlying weakness types? Moreover, what attack patterns exploit these weakness types? If you are making software, make sure that you include checks for these weaknesses in your development process to prevent these kinds of vulnerabilities.
1. Manage your access control issues such as authentication and authorization. (CVE-2019–11580, CVE-2019–5591, CVE-2020–0688, CVE-2020–12812, CVE-2021–22893, CVE-2021–22894, CVE-2021–22900, CVE-2021–26855, CVE-2021–26858, CVE-2021–27065, CVE-2021–27103) Over a third of the entire Top 30 Vulnerabilities List deals with authentication issues. Many of these are tricky, such as preventing activities after a process should no longer have rights, server-side request forgery and things like code injection. (CAPEC-122, CAPEC-233, CAPEC-58, CAPEC-664, CAPEC-242). The key is not to write your own code unnecessarily and authenticate often. (CWE-285, CWE-287, CWE-306, CWE-798, CWE-862, CWE-914, CWE-94)
2. Neutralize risky inputs. (CVE-2018–7600, CVE-2019–0604, CVE-2019–18935, CVE-2020–15505, CVE-2021–21985. CVE-2021–22899, CVE-2021–26857, CVE-2021–27101, CVE-2021–27102, CVE-2021–27104) The second most frequent weakness type (about a third) deals with processing input. Make sure that you are sanitizing input against SQL injection,(CWE-89) and OS command injections (CWE-78) This should be done with tested frameworks that properly encode or escape output before it is sent to other components like database engines or the shell. Please don’t try to build your own. In addition, deserialization errors came up as an issue in two CVEs. Programs should check data to make sure it has not been tampered or replayed (when and how? May be helped by linking to CWE entry) and making sure object fields for deserialization transient to prevent this. Lastly, (CWE-20, CWE-502, CWE-77, CWE-78, CWE-89) (CAPEC-153, CAPEC-267, CAPEC-586, CAPEC-66, CAPEC-248, CAPEC-88)
3. Manage your paths. (CVE-2018–13379, CVE-2019–11510, CVE-2019–19781, CVE-2019–3396) Be careful when allowing your software to access file or location paths. This is related to about a quarter of the CVEs in the list and consists of items like file paths, search paths, and how systems reach out to include functions from other areas. It is hard to stop the multiple ways of bypassing path traversal controls. (CAPEC-126, CAPEC-38, CAPEC-159, CAPEC-154) Don’t do this yourself. Use a well-tested, well-used library. Also, build tests to abuse these paths, especially when you have code that does things like pull a widget from another site. (CWE-22, CWE-427, CWE-829)
4. Manage your memory when accepting input. (CVE-2017–11882, CVE-2021–22894) Over the last 15 years, memory issues have garnered a lot of attention, so you would think memory weaknesses would be higher on the priority list. One of the two vulnerabilities highlighted a stack buffer overflow dealing with a null terminated string for the font name, so appropriate input management might also catch this. The second vulnerability talks about a maliciously crafted meeting room (CAPEC-100, CAPEC-135, CAPEC-153, CAPEC-538). While there is no additional detail, my guess is that ensuring the parsing of input data on a meeting room definition correctly would manage this issue. It is important to use proper string libraries that handle all memory issues or use strings of a fixed length (e.g. strncpy). Null terminated strings only lead to sadness (even in certificate names from 2009). (CWE-119, CWE-120)
5. Make sure that you know when you need random numbers and test that they are random. (CVE-2020–1472) One of the top CVEs was the notorious ZeroLogin vulnerability, where an initialization vector was not sufficiently random. Making sure you test that your random number generators work properly is important. Most of the time this is an issue in handling keys or some business logic. A current example is a DEFCON 29 talk on poor random number generation in IoT devices addressing the creation of initialization vectors. It is tough to know when random numbers are properly random. Make sure you are using cryptographically secure pseudo random number generators (CPRNG) in software (CAPEC-112, CAPEC-20, CAPEC-97). Don’t use hardware random number generators directly from hardware as it is very difficult to recover when you get an error (CWE- 330 and CWE-1241).
