CHAPTER 5

Vulnerabilities and Impacts

In this chapter, you will

•  Explore the sources and types of vulnerabilities

•  Explain the impact associated with types of vulnerabilities

Vulnerabilities are the source of virtually all security concerns. Vulnerabilities are specific characteristics of a system that an attacker exploits to violate the security posture of the system. When an attacker exploits a vulnerability, the impact can vary from minimal to disastrous. This chapter examines the technical source and business impact of the types of vulnerabilities commonly found in systems.

Certification Objective   This chapter covers CompTIA Security+ exam objective 1.6, Explain the impact associated with types of vulnerabilities.

EXAM TIP    Per exam objective 1.6, be prepared for questions that require you to identify the impact associated with a specific vulnerability. Vulnerabilities open or expand risk, which can result in impact to an organization. The key is in tracing the problem to how it affects the enterprise in terms of impact or cost.

Race Conditions

A race condition is an error condition that occurs when the output of a function is dependent on the sequence or timing of the inputs. It becomes a bug when the inputs do not happen in the order the programmer intended. The term race condition relates to the idea of multiple inputs racing each other to influence the output first. Race conditions can occur in multithreaded or distributed programs when the sequence or timing of processes or threads is important for the program to operate properly. Race conditions are very difficult to detect, for they are typically transient or nondeterministic and may depend upon other processes running on a system, even if not connected programmatically. The impact of a race condition is usually the failure of a system in the form of a crash. Race conditions can be combated with reference counters, kernel locks, and thread synchronization. Reference counters are structures in the kernel that detail whether a resource is actively being used or not at the current moment. Locking the kernel was an early method, but it causes performance issues. Thread synchronization prevents threads from accessing the shared data at the same time.

EXAM TIP    Race conditions can be used for privilege elevation and denial-of-service attacks. Programmers can use reference counters, kernel locks, and thread synchronization to prevent race conditions.

System Vulnerabilities

Systems can have a wide range of vulnerabilities, many of which are related to specific components. But other vulnerabilities are associated with the whole system, including end-of-life issues, embedded system issues, and issues caused by lack of vendor support. It is important to understand these major vulnerabilities and have mitigation plans to protect the system from risk due to these conditions.

End-of-Life Systems

All systems eventually reach an end-of-life stage. End-of-life is defined as when the system has reached a point where it can no longer function as intended. End-of-life status can be reached for many reasons, such as lack of vendor support, a failure to instantiate on newer hardware, or incompatibility with other aspects of a system. Old software systems are frequently referred to as legacy systems, especially when they are still in use post end-of-life.

After software has reached end-of-life and the original vendor no longer supports it with updates and patches, security becomes an issue because the vendor will no longer fix newly discovered vulnerabilities. If an organization decides to continue to use end-of-life software, it must implement external controls to prevent access to the vulnerability. When the hardware is also end-of-life, the organization must have a substantial investment in spare hardware/parts, and in many cases newer hardware systems will not run old software. Incompatibilities between newer, current systems and old systems require intermediate patch layers to be built to allow communications to and from the old systems. All of these efforts increase costs and risk associated with end-of-life software and systems. In most cases in which an organization continues to use end-of-life software, the organization has determined that the software is critical to its operations and that replacing it is too expensive in terms of the capital costs, time, and resources.

The decision to continue using Windows XP represents a common example of end-of-life problems. Microsoft has discontinued Windows XP and has stopped its vendor support, such as updates, patches, and drivers. The effect is that Windows XP machines are vulnerable to new forms of attack. Many institutions, from manufacturing plants to hospitals, and a whole host between, find themselves trapped with the legacy Windows XP OS because of cost, compatibility, and/or legacy issues associated with moving to a newer OS. Recent ransomware attacks have plagued older OS’s that are no longer being patched, making them easy targets.

Embedded Systems

Embedded systems are systems that are included within other systems. This term can apply to a stand-alone, single-purpose system designed to provide specific functionality to an overall system. It can also be used to refer to some module or component of a larger system that comes from another source. One of the risks of embedded systems comes from the software that is in the system yet separate from any update/patch methodology. The software includes any inherent vulnerabilities that exist as a part of its build but are separate from the overall system build. Old versions of Linux and software libraries have known vulnerabilities. When these programs are part of an embedded system, if they are not updated/patched, they can bring hidden vulnerabilities into the overall system.

Lack of Vendor Support

Lack of vendor support can become an issue at several different levels of vendor. The most obvious scenario is when the original manufacturer of the item, be it hardware or software, no longer offers support. When an item reaches end-of-life from the original manufacturer’s standpoint, this signifies the finality of its life under almost all circumstances. After the manufacturer stops supporting an item, options to keep it up to date with patches and fixes seldom exist. At this point, an organization that continues to use the product assumes all of the risk associated with issues uncovered after the product has entered end-of-life status, and the options to address these risks are limited to compensating controls.

Another scenario in which lack of vendor support arises is when the system under question was implemented by a third-party vendor and that vendor either no longer supports the configuration or, in some cases, is no longer in business. The underlying technology may still be supported by the original manufacturers, but the lack of support for the middleware provided by the third-party implementer raises questions as to whether the underlying products can be updated or patched. This places the testing burden on the end user, and in many cases the end user does not have the knowledge or skills necessary to conduct thorough regression testing.

EXAM TIP    A system can have vulnerabilities related to the age of the system. Whether the system is composed of old parts, as in an embedded system, or has become an end-of-life legacy system, the lack of vendor support can result in the owner’s inability to address many newly discovered issues.

Improper Input Handling

Improper input handling is the true number one cause of software vulnerabilities. Improper input handling or input validation is the root cause behind most overflows, injection attacks, and canonical structure errors. Users have the ability to manipulate input, so it is up to the developer to handle the input appropriately to prevent malicious entries from having an effect. Buffer overflows (discussed later in the chapter) have long been recognized as a class of improper input handling. Newer input handling attacks include canonicalization attacks and arithmetic attacks. Probably the most effective defensive mechanism that you can employ is input validation. Considering all inputs to be hostile until properly validated can mitigate many attacks based on common vulnerabilities. This is a challenge, as the validation efforts need to occur after all parsers have completed manipulating input streams, a common function in web-based applications using Unicode and other international character sets.

Input validation is especially well suited for the following vulnerabilities: buffer overflow, reliance on untrusted inputs in a security decision, cross-site scripting (XSS), cross-site request forgery (XSRF), path traversal, and incorrect calculation of buffer size. Input validation may seem suitable for various injection attacks, but given the complexity of the input and the ramifications from legal but improper input streams, this method falls short for most injection attacks. What can work is a form of recognition and whitelisting approach, where the input is validated and then parsed into a standard structure that is then executed. This restricts the attack surface to not only legal inputs but also expected inputs.

The impact of improper input handling can be catastrophic, allowing an attacker to either gain a foothold on a system or increase his level of privilege. Because this type of error is dependent upon the process being attacked, the results can vary, but they almost always result in attackers advancing their kill chain.

EXAM TIP    Input validation is especially well suited for the following vulnerabilities: buffer overflow, reliance on untrusted inputs in a security decision, cross-site scripting (XSS), cross-site request forgery (XSRF), path traversal, and incorrect calculation of buffer size. When taking the Security+ exam, look for questions that address a large number of related problems with a common potential cause.

Improper Error Handling

Every application will encounter errors and exceptions, and these need to be handled in a secure manner. One attack methodology includes forcing errors to move an application from normal operation to exception handling. During an exception, it is common practice to record/report the condition, typically in a log file, including supporting information such as the data that resulted in the error. This information can be invaluable in diagnosing the cause of the error condition. The challenge is in where this information is captured. The best method is to capture it in a log file, where it can be secured by an access control list (ACL). The worst method is to echo the information to the user. Echoing error condition details to users can provide valuable information to attackers when they cause errors on purpose.

Improper error handling can lead to a wide range of disclosures. Errors associated with SQL statements can disclose data structures and data elements. Remote procedure call (RPC) errors can give up sensitive information such as filenames, paths, and server names. Programmatic errors can disclose line numbers that an exception occurred on, the method that was invoked, and information such as stack elements. Attackers can use the information they gather from errors to further their attack on a system, as the information typically gives them details about the composition and inner workings of the system that they can exploit.

Misconfiguration/Weak Configuration

Most systems have significant configuration options that administrators can adjust to enable or disable functionality based on usage. When a system suffers from misconfiguration or weak configuration, it may not achieve all of the desired performance or security objectives. Configuring a database server to build a complete replica of all actions as a backup system can result in a system that is bogged down and not capable of proper responses when usage is high. Similarly, old options, such as support for legacy protocols, can lead to vulnerabilities. Misconfiguration can result from omissions as well, such as when the administrator does not change default credentials, which is equivalent to having no credentials at all, leaving the system vulnerable. This form of vulnerability provides a means for an attacker to gain entry or advance their level of privilege, and because this can happen on components with a wide span of control, such as a router or a switch, in some cases an attacker can effectively gain total ownership of an enterprise.

Default Configuration

Default configuration is the configuration that a system enters upon start, upon recovering from an error, and at times when operating. This configuration acts as a system baseline, a position from which all other states can be measured. It is very important for the default configuration to be secure from the beginning, for if not, then a system will be vulnerable whenever entering this configuration, which in many conditions is common.

“Secure by Default” is an initiative by Microsoft to ensure that all of its systems are designed to be secure by default when installed and operated. One of the key elements of this initiative is to force the system installer to provide unique and secure credentials upon installation. This prevents the misconfiguration by omission issue (discussed in the previous section) that enables attackers to reuse default admin credentials to gain admin- or root-level control over a system. As with misconfigurations, this form of vulnerability provides a means for an attacker to gain entry or advance their level of privilege, and because this can happen on components with a wide span of control, such as a router or a switch, in some cases an attacker can effectively gain total ownership of an enterprise.

EXAM TIP    Configuration issues are common causes of problems and are easy targets for questions on the Security+ exam. Pay attention to the details of the question to determine what the specific issue is, be it default configuration, misconfiguration, or weak configuration, as you will likely see all of these as choices.

Resource Exhaustion

All systems are defined as a process that creates specific outputs as a result of a defined set of inputs. The internals of the system use a variety of resources to achieve the transition of input states to output states. Resource exhaustion is the state where a system does not have all of the resources it needs to continue to function. Two common resources are capacity and memory, which are interdependent in some scenarios but completely separate in others. Capacity is defined by a system having the necessary amount of communication bandwidth, processing bandwidth, and memory to manage intermediate states. When one of these resources becomes exhausted, failure can ensue. For instance, if a system has more TCP SYN requests than it can handle, it fails to complete handshakes and enable additional connections. If a program runs out of memory, it will fail to operate correctly. This is an example of a resource exhaustion attack, where the attack’s aim is to deplete resources.

EXAM TIP    Like race conditions, resource exhaustion vulnerabilities tend to result in a system crash. These attacks can result in less damage, but from the aspect of an attacker advancing a persistence, it’s necessary to change system functions as part of an overall attack strategy. However, in some cases, the outages can stop essential services, including customer-facing systems.

Untrained Users

Untrained users are users who do not know how to operate a system properly because they haven’t received training associated with the system’s capabilities. Unfortunately, untrained users are fairly common in most modern organizations. Whether they are end users who don’t know how to navigate standard GUIs or highly technical people like software developers who don’t understand how to properly use the interface of their IDE, the end result is the same: the system of protections and efficiencies built into a program goes unused. Untrained users typically are less efficient because they do not use the system to its designed performance level. Untrained users can also add risk to a system by not using designed-in mitigations, in essence bypassing controls designed to reduce risk.

Training of users begins with policies and procedures. These elements explain the what and how of workers daily tasks. The procedures should also hand exceptions and abnormal conditions, for they occur and should be handled according to procedure. Training also needs to include general user security training including things like password policies and defending against social engineering attacks.

EXAM TIP    Users are part of the overall system, and users have the ability to be configured during training. Training users how to properly use their tools, including general security items such as security policies and how to defend against social engineering is essential. Untrained users are easier targets for an attacker to compromise.

Improperly Configured Accounts

Accounts form the basis for access control, for they define the user, and this leads to the list of allowed actions via an access control list (ACL). Improperly configured accounts can lead to improper allowances via ACLs. Individual accounts quickly become too numerous to efficiently manage on an individual basis, and as a response to this problem, administrators create group accounts to reduce the number of controlling entries to a manageable number. But when a user account ends up in the wrong group, the user may receive permissions that are inappropriate for that user, and even worse, there is no distinct warning flag that this has occurred. This is one of the reasons that Linux system administrators do not log in as root even when they need to perform root actions. If they were logged in as root, then an inadvertent typo or a command in the wrong directory could result in catastrophic failure. Forcing them to use the su command to take a root action reminds them of the gravity of the action and to proceed cautiously.

A common misconfiguration on Windows computers is the use of a local administrator account. This may seem harmless as it is only a local account, but if an attacker is able to access a local administrator account, he then has numerous potential paths leading to domain administrator access; thus, organizations need to limit the use of local admin accounts, or take specific mitigating actions to ensure they can’t be used to gain domain admin access.

Vulnerable Business Processes

Virtually all work is a combination of technology, people, and processes. Just as technology and users often have vulnerabilities that can be comprised, as previously discussed, vulnerable business processes are subject to compromise. When a business process that contains an inherent vulnerability is automated, then all that automation can do is increase the speed of the failure. A simple example would be paying an invoice without matching it to an approved purchase order. A common form of fraud is to send an invoice to an organization for goods or services that were not provided, typically for something common like office supplies. If someone in the organization processes the invoice for payment without verifying that the organization ordered and received the supplies, then this is clearly a business process failure. If the payment process is automated and works similarly, the vulnerability is even greater.

Weak Cipher Suites and Implementations

Cryptographic errors come from several common causes. One typical mistake is choosing to develop your own cryptographic algorithm. Development of a secure cryptographic algorithm is far from an easy task, and even when attempted by experts, weaknesses can be discovered that make the algorithm unusable. Cryptographic algorithms become trusted only after years of scrutiny and repelling attacks, so any new algorithms would take years to join the trusted set. If you instead decide to rely on secret algorithms, be warned that secret or proprietary algorithms have never provided the desired level of protection. A similar mistake to attempting to develop your own cryptographic algorithm is to attempt to write your own implementation of a known cryptographic algorithm. Errors in coding implementations are common and lead to weak implementations of secure algorithms that are vulnerable to bypass. Do not fall prey to creating a weak implementation; instead, use a proven, vetted cryptographic library.

The second major cause of cryptographic weakness is the employment of deprecated or weak cryptographic algorithms. Weak cipher suites are those that at one time were considered secure but are no longer considered secure. As the ability to use ever faster hardware has enabled attackers to defeat some cryptographic methods, the older, weaker methods have been replaced by newer, stronger ones. Failure to use the newer, stronger methods can result in weakness. A common example of this is SSL; all versions of SSL are now considered deprecated, and should not be used. Everyone should switch their systems to TLS-based solutions.

The impact of cryptographic failures is fairly easy to understand: whatever protection that was provided is no longer there, even if it is essential for the security of the system.

Memory/Buffer Vulnerability

When computer programs take inputs for a variable, they are put into buffers in memory. These buffers are located where the variable is stored in memory, so when the program needs to reference the value of a variable, it uses the memory location to obtain the value. Some languages, referred to as type safe, verify the length of an input before assigning it to the memory location. Other languages, such as C/C++, rely upon the programmer to handle this verification task. When this task is not properly performed, there exists a chance to overwrite the allocated area in memory, potentially corrupting other values of other variables, and certainly not storing what was requested in the variable in question. This is a memory/buffer vulnerability and it can exist in software without issue until input that exceeds the allocated space is received. Then the memory/buffer vulnerability becomes an input overflow or buffer overflow error.

Other forms of memory vulnerabilities include DLL injections, where additional code can be put into a program’s memory space and used, and issues associated with pointers, including pointer errors, commonly associated with dereference errors.

The impact of memory and buffer vulnerabilities is the same as for input-handling issues. An attacker can use the access to program flow to either obtain access or advance privilege level.

Memory Leak

Memory leaks are programming errors caused when a computer program does not properly handle memory resources. Over time, while a program runs, if it does not clean memory resources as they are no longer needed, it can grow in size, with chunks of dead memory being scattered across the program’s footprint in memory. If a program executes for a long time, these chunks can grow and consume resources, causing a system to crash. Even if the program only runs for a short time, in some cases, leaks can cause issues when referencing values later in a run, returning improper values.

The impact of memory leaks is similar to that of race conditions and resource exhaustion: the system can crash. Thus, based on what function the affected system performs, the loss of that function or capacity is the result.

Integer Overflow

An integer overflow is a programming error condition that occurs when a program attempts to store a numeric value, an integer, in a variable that is too small to hold it. The results vary by language and numeric type. In some cases, the value saturates the variable, assuming the maximum value for the defined type and no more. In other cases, especially with signed integers, it can roll over into a negative value, as the most significant bit is usually reserved for the sign of the number. This can create significant logic errors in a program. As with most errors, integer overflow errors are targets for attackers to exploit, as they can be manipulated to create incorrect results in a system.

Integer overflows are easily tested for, and static code analyzers can point out where they are likely to occur. Given this, there are not any good excuses for having these errors end up in production code.

Buffer Overflow

Buffer overflow attacks are input validation attacks, designed to take advantage of input routines that do not validate the length of inputs. Surprisingly simple to resolve, all that is required is the validation of all input lengths prior to writing to memory. This can be done in a variety of manners, including the use of safe library functions for inputs. This is one of the vulnerabilities that has been shown to be solvable, and in fact the prevalence is declining substantially among major security-conscious software firms.

The concept behind the buffer overflow vulnerability is relatively simple. The input buffer that is used to hold program input is overwritten with data that is larger than the buffer can hold. The root cause of this vulnerability is a mixture of two things: poor programming practice and programming language weaknesses. For example, what would happen if a program that asks for a 7- to 10-character phone number instead receives a string of 150 characters? Many programs will provide some error checking to ensure that this will not cause a problem. Some programs, however, cannot handle this error, and the extra characters continue to fill memory, overwriting other portions of the program. This can result in a number of problems, including causing the program to abort or the system to crash. Under certain circumstances, the program can execute a command supplied by the attacker. Buffer overflows typically inherit the level of privilege enjoyed by the program being exploited. This is why programs that use root-level access are so dangerous when exploited with a buffer overflow, as the code that will execute does so at root-level access.

Pointer Dereference

Some computer languages use a construct referred to as a pointer, a variable that refers to the memory location that holds a variable as opposed to the value in the memory location. To get the value at the memory location denoted by a pointer variable, one must dereference the pointer. The act of pointer dereference now changes the meaning of the object to the contents of the memory location, not the memory location as identified by the pointer. Pointers can be very powerful and allow fast operations across a wide range of structures. But they can also be dangerous, as mistakes in their use can lead to unexpected consequences. When a programmer uses user inputs in concert with pointers, for example, lets the user pick a place in an array, and uses a pointer to reference the value, mistakes in the input validation can lead to errors in pointer dereference, which may or may not trigger an error, as the location will contain data and it will be returned.

DLL Injection

Dynamic link libraries (DLLs) are pieces of code that can add functionality to a program through the inclusion of library routines linked at run time. DLL injection is the process of adding to a program at run time a DLL that has a specific vulnerability of function that can be capitalized upon by an attacker. A good example of this is Microsoft Office, a suite of programs that use DLLs loaded at run time. Adding an “evil” DLL in the correct directory, or via a registry key, can result in “additional functionality” being incurred.

EXAM TIP    There are several different vulnerabilities with similar causes. Memory leaks and buffer overflows can be caused by a variety of input-related vulnerabilities. What distinguishes many of these causes is the actual target of the vulnerability. Integer overflows target math operations, SQL injection targets SQL engine operations, and so forth. The key to the correct answer lies in the details of the quest.

System Sprawl/Undocumented Assets

The foundation of a comprehensive security program is understanding all of your assets and how they are connected. This applies to hardware, software, and data. Understanding your network diagram, including all the systems and how they are connected, is essential to managing the flow of traffic. Understanding what software you have, where it is installed, and how it is configured is essential when updates and patches become necessary. These elements are all important, not to mention correct access control lists for the above. Data is its own asset category because it moves around and can’t be diagrammed. Data can be in transit, at rest, or in use, and typically it is the most important asset to protect. All of these topics are covered throughout this book and listed in the Security+ exam objectives.

System sprawl is when the systems expand over time, adding elements and functionality, and over time the growth and change exceeds the documentation. This addition of undocumented assets means that these specific assets are not necessarily included in plans for upgrades, security, etc. Enterprises inevitably end up with system sprawl and undocumented assets. What begins as correct, over time moves to complete failure to understand because we seldom manage the documentation of the architecture as built and deployed. As changes occur, we always seem to miss updating the diagrams, architectures, and rules associated with security. System sprawl occurs because we continually “improve” systems by adding functionality and frequently fail to update the architecture plans. The new elements that are not documented become undocumented assets and contribute to misunderstandings and issues when they are not considered for future changes. Undocumented assets also have a higher chance of becoming an unknown vulnerability primarily because of their undocumented status that precludes their inclusion in routine security checks.

EXAM TIP    As time passes, an enterprise may lose the ability to properly manage all of the systems, devices, software, and data assets that have accumulated. This results in overprovisioning provisioned resources and is commonly known as system sprawl. Don’t confuse the Security+ exam objective terms system sprawl and VM sprawl. Although they are similar in concept, VM sprawl applies to virtual machines and is covered in Chapter 15.

Architecture/Design Weaknesses

System architectures can have strengths and weaknesses. Most of these are the result of design. Architecture/design weaknesses are issues that result in vulnerabilities and increased risk in a systematic manner. These flaws are not easily corrected without addressing the specific architecture or design vulnerability that created them in the first place. An example of this is a flat network design without any segmentation. This increases the likelihood that an attacker can traverse the network and get access to sensitive data from an entry point that is significantly less trusted.

New Threats/Zero Day

Zero day is a term used to define vulnerabilities that are newly discovered and not yet addressed by a patch. Most vulnerabilities exist in an unknown state until discovered by a researcher or developer. If a researcher or developer discovers a vulnerability but does not share the information, then this vulnerability can be exploited without a vendor’s ability to fix it, because for all practical knowledge the issue is unknown, except to the person who found it. From the time of discovery until a fix or patch is made available, the vulnerability goes by the name zero day, indicating that it has not been addressed yet. The most frightening thing about a zero day threat is the unknown factor—their capability and effect on risk are unknown because they are unknown. Although there are no patches for zero day vulnerabilities, you can use compensating controls to mitigate the risk.

EXAM TIP    Zero day threats have become a common topic in the news and are a likely target for exam questions. Keep in mind that defenses exist, such as compensating controls, which are controls that mitigate the risk indirectly; for example, a mitigating control may block the path to the vulnerability rather than directly address the vulnerability.

Improper Certificate and Key Management

Certificates are the most common method of transferring and managing cryptographic keys between parties. Improper certificate management can lead to key problems and cryptographic failures. Failure to properly validate a key before use can result in an expired or compromised key being used. Improper key management can result in failure to secure data if, for example, a compromised key continues to be used. The PKI system has established processes and procedures to ensure proper key hygiene and limit the potential issues associated with public key cryptography. To receive these benefits from a PKI system, it is important to follow the established procedures and methods for both certificate usage and subsequent key usage.

Chapter Review

In this chapter, you became acquainted with the impact associated with various types of vulnerabilities. The chapter began with a discussion of the impacts associated with a series of specific types of vulnerabilities, including race conditions, system vulnerabilities, improper input handling, and improper error handling. The chapter continued with coverage of impacts associated with misconfiguration/weak configurations, default configurations, resource exhaustion, untrained users, improperly configured accounts, and vulnerable business practices. The next set of impacts examined included those associated weak cipher suites and implementations and memory/buffer vulnerabilities. The chapter concluded with an examination of the impacts of system sprawl/undocumented assets, architecture/design weaknesses, new threats/zero days, and improper certificate and key management.

Questions

To help you prepare further for the CompTIA Security+ exam, and to test your level of preparedness, answer the following questions and then check your answers against the correct answers at the end of the chapter.

1. You’re reviewing a custom web application and accidentally type a number in a text field. The application returns an error message containing variable names, filenames, and the full path of the application. This is an example of which of the following?

A. Resource exhaustion

B. Improper error handling

C. Generic error message

D. Common misconfiguration

2. A web server in your organization has been defaced. The server is patched and properly configured as far as anyone can tell. Your logs show unusual traffic from external IP addresses just before the defacement occurred. It’s possible your server was attacked by which of the following?

A. Misconfiguration attack

B. Insider threat

C. Zero day exploit

D. Design weakness attack

3. You’re working with a group testing a new application. You’ve noticed that when three or more of you click Submit on a specific form at the same time, the application crashes every time. This is most likely an example of which of the following?

A. A race condition

B. A nondeterministic error

C. Undocumented feature

D. DLL injection

4. Which of the following is a vulnerability related to a lack of vendor support?

A. The product has been declared “end-of-life” by the vendor.

B. The vendor is no longer in business.

C. The vendor does not support nonstandard configurations for its products.

D. All of the above.

5. An externally facing web server in your organization keeps crashing. Looking at the server after a reboot, you notice CPU usage is pegged and memory usage is rapidly climbing. The traffic logs show a massive amount of incoming HTTP and HTTPS requests to the server. Which type of attack is this web server experiencing?

A. Input validation

B. Distributed error handling

C. Resource exhaustion

D. Race condition

6. A colleague on your team takes three times longer than you do to complete common tasks in a particular application. When you go to help him, you notice immediately that he doesn’t use any of the shortcuts designed into the application. When you ask him why he is not using shortcuts, he tells you he didn’t know the shortcuts exist. This is an example of which of the following?

A. An untrained user

B. Improper application configuration

C. Memory leak

D. Lack of vendor support

7. Your organization is considering using a new ticket identifier with your current help desk system. The new identifier would be a 16-digit integer created by combining the date, time, and operator ID. Unfortunately, when you’ve tried using the new identifier in the “ticket number” field on your current system, the application crashes every time. The old method of using a 5-digit integer works just fine. This is most likely an example of which of the following?

A. Common misconfiguration

B. Zero day vulnerability

C. Memory leak

D. Integer overflow

8. While examining a laptop infected with malware, you notice the malware loads on startup and also loads a file called netutilities.dll each time Microsoft Word is opened. This is an example of which of the following?

A. Zero day exploit

B. DLL injection

C. System infection

D. Memory overflow

9. You’re providing incident response services for a small company after a breach. The first thing you notice is the entire network is completely flat once you get behind the firewall. Services, user workstations, and printers are all on the same subnet with no VLANs or network segmentation. This is an example of what type of weakness?

A. Architecture/design weakness

B. Network traversal weakness

C. TCP overflow weakness

D. Memory leak weakness

10. A web application you are reviewing has an input field for username and indicates the username should be between 6 and 12 characters. You’ve discovered that if you input a username 150 characters or more in length, the application crashes. What is this is an example of?

A. Memory leak

B. Buffer overflow

C. Directory traversal

D. Integer overflow

11. You’ve been asked to help address some findings from a recent PCI (Payment Card Industry) audit, one of which is support for SSL 2.0 on a web server. Your CFO wants to know why SSL 2.0 support is a problem. You tell her SSL 2.0 support is an example of which of the following vulnerabilities?

A. Separation of duties

B. Default configuration

C. Resource exhaustion

D. Weak cipher suites

12. Your organization is having issues with a custom web application. The application seems to run fine for a while but starts to lock up or crash after 7 to 10 days of continuous use. Examining the server, you notice that memory usage seems to climb every day until the server runs out of memory. The application is most likely suffering from which of the following?

A. Memory leak

B. Overflow leak

C. Zero day exploit

D. Pointer dereference

13. While examining internal network traffic, you notice a large amount of suspicious traffic coming from an IP address in the development environment. The IP address isn’t listed on any network diagram and shouldn’t be active on your network as far as you can tell. When you ask the developers about it, one of them tells you he set up that server over 12 months ago for a temporary project and forgot all about it. This is an example of which of the following?

A. Single server contingency

B. DLL injection

C. Undocumented asset

D. Insider threat

14. While auditing an organization, you discover that new users are added to the domain by sending an e-mail request to the IT department, but the e-mails don’t always come from Human Resources, and IT doesn’t always check with HR to ensure the new user request corresponds to an authorized user. This is an example of which of the following?

A. Process overflow

B. Vulnerable business process

C. Insider threat

D. Trojan e-mail attack

15. Which of the following is an example of an embedded system?

A. A user workstation

B. A web server

C. A network-enabled thermostat

D. A database server

Answers

1. B. When an application fails to properly trap an error and generates error messages containing potentially sensitive information, this is known as improper error handling.

2. C. If a completely patched, properly configured server is successfully attacked, the most likely culprit is a zero day exploit. With zero day exploits, the vulnerability being exploited is unknown to the general public or the developer, so even a “fully patched” system is potentially vulnerable to zero day exploits.

3. A. This is most likely an example of a race condition. A race condition is an error condition that occurs when the output of a function is dependent on the sequence or timing of the inputs. In this case, the application crashes when multiple inputs are submitted at the same time because the application is not receiving the inputs or handling the inputs in the expected order.

4. D. All of these are potential vulnerabilities associated with a lack of vendor support. When a vendor declares a product to be end-of-life, the vendor typically ends support for that product, which typically means it will provide no updates, patches, or maintenance even if critical vulnerabilities are later discovered. A vendor that no longer exists clearly can’t provide support or patches. Vendors that support only specific configurations may not provide maintenance, features, or patches that allow their product to work securely in your specific environment.

5. C. Resource exhaustion is the state where a system does not have all of the resources it needs to continue to function. In this case the server does not have the memory or CPU capacity to handle the massive volume of HTTP/HTTPS requests that are coming into the server.

6. A. Your colleague is an untrained user. Untrained users are users who do not know how to operate a system efficiently or securely because they haven’t received training associated with the system’s capabilities.

7. D. An integer overflow is a programming error condition that occurs when a program attempts to store a numeric value, an integer, in a variable that is too small to hold it. In this case the 16-digit integer is too large for the field that’s working just fine with the 5-digit integer.

8. B. This is an example of DLL injection. DLL injection is the process of adding to a program at run time a DLL that has a specific vulnerability of function that can be capitalized upon by an attacker.

9. A. A flat network designed with no network segmentation increases the likelihood an attacker can easily traverse the network and gain access to sensitive information. The problem lies with the how the network was designed/built. This is known as an architecture/design weakness.

10. B. This is a fairly classic example of a buffer overflow. The input routine does not validate the provided input to ensure a maximum of 12 characters are received and processed. In this case, the application tries to store all 150 or more characters of the username, resulting in areas of memory being overwritten and causing the application to crash.

11. D. SSL 2.0 is an example of a weak cipher suite. While technically the protocol used for SSL 2.0 is not a “vulnerability,” the cipher suites used in SSL 2.0 are cryptographically insecure—meaning an attacker can “break them” and access the content you are trying to protect.

12. A. Memory leaks are programming errors caused when a computer program does not properly handle memory resources. Over time, while a program runs, if it does not clean memory resources as they are no longer needed, it can grow in size, with chunks of dead memory being scattered across the program’s footprint in memory. If a program executes for a long time, these can grow and consume resources, causing a system to crash.

13. C. This is a good example of an undocumented asset. The server was added to the environment, but the appropriate network documentation was never updated.

14. B. This is an example of a vulnerable business process. If IT is creating new user accounts based on e-mails it receives without validating that the requests are valid, then an attacker could take advantage of this process.

15. C. The network-enabled thermostat is an example of an embedded system. This device is a stand-alone, single-purpose system that is a component of a larger system (the HVAC system in this case).