Enumeration of Threats | Hunting Security Bugs

Before you jump in and spend time and resources testing, it s a good idea for you to finish developing your threat model so you have a clear, organized approach to testing. The next key part of developing a threat model is to make an actual list of threats associated with the functionality being modeled . The list of entry points can be used as a starting point. You need to think about all of the data that enters the functionality, how it is used, and how it might be maliciously used to cause undesirable results. Because testers break software as part of their job, with practice, they often come up with some of the better threats against an application.

Tips for identifying threats

Gain knowledge. Gain as much knowledge as possible about the functionality being modeled. Knowledge goes a long way. Security bugs are often found in small implementation details.
Think maliciously. Think maliciously about every detail of the system you are threat modeling. Attackers will, and you should, too. (See Chapter 1 for more details on thinking maliciously.) Follow the data as it enters the application from untrusted sources and as it is used throughout the application. Following are a few questions that are useful to ask when you are thinking maliciously about the application:
- What specifically can the attacker include in the data?
- When the application makes a decision, can the attacker s data influence the decision?
- What assumptions about the validity or format of the data are being made by the application? Can the attacker violate those assumptions?
- Is the data stored somewhere and later read? It is helpful to think of attacker-controlled data as a disease ”any code that touches the untrusted data is potentially a carrier.

Understand related threat models and bugs. It is worthwhile to study threat models and descriptions of bugs for functionality similar to the one you are threat modeling. This can highlight some direct threats that apply to the target application and can give you additional ideas for threats.
Understand that attackers aren t always anonymous. Often, authenticated users are perceived as trusted and are not treated as potential attackers. Certainly, authenticated users are more trusted than anonymous users, but threat models should also include threats in which the attacker has some level of access to the machine or application.
Practice defense in depth. Security shouldn t be built like a house of cards ”when one small item fails, the security of the entire application crumbles. A good threat model should include threat scenarios in which some components are abused or compromised. Although it is important to think about these scenarios, it is also important to assume core components of the target computer are not compromised. For example, if any user can write to the local machine section of the registry because the operating system has been compromised, your application won t have a chance of running securely. At that point, the entire machine has been compromised. The threat model should assume an attacker cannot write to this part of the registry. It is worthwhile to state assumptions like this in the threat model.

Use the STRIDE threat categories. While brainstorming threats, it is important to think about the different threat categories. STRIDE is an acronym that stands for the six threat categories documented in Howard and Leblanc s Writing Secure Code . STRIDE stands for the following:
- Spoofing Can the software or end user be tricked into seeing some data as something other than what it actually is? Examples include packet spoofing and user interface spoofing. This topic is covered in detail in Chapter 6, Spoofing.
- Tampering with data Can someone that shouldn t have access to modifying or deleting the data do so?
- Repudiation Is it possible to prove which actions a user has taken? For example, are important actions logged and are the logs accurate?
- Information disclosure Is only necessary information given to users? Can the additional information reveal information about the target system or users? This is covered in more detail in Chapter 7, Information Disclosure.
- Denial of service Is an attacker able to prevent legitimate users from accessing the application? Read more on this in Chapter 14, Denial of Service Attacks.
- Elevation of privilege Is an attacker able to perform actions that only higher-privileged users should be allowed to perform?

Although we could fill several pages with threats against the e-mail Web page functionality mentioned earlier, we mention only a few here:

Spam A malicious user inserts an advertisement in the message body (the area intended for a user to enter a brief message for the recipient) sent to the recipient, enabling the malicious user to spam arbitrary e-mail addresses.
Mail bomb A malicious user makes many requests to send e-mail to the same address in hopes of flooding the recipient s mailbox.
Sender repudiation The recipient of the e-mail message is unable to determine who requested that the e-mail message be sent.
Information disclosure through e-mail E-mail sent to the recipient contains information about the internal network hosting the feature.
Information disclosure through HTTP response The HTTP response contains information about the internal network hosting the feature.
Denial of service through malformed requests A malformed HTTP request crashes the server.
Arbitrary code execution through malformed requests A malformed HTTP request allows arbitrary code execution ”for example, buffer overflow, integer overflow, or format string vulnerability.

Important

It is important for you to list all threats, regardless of whether they have been mitigated, so that you can later generate test cases where necessary. If you don t document all threats, they ll get lost and you won t have test cases for them.