The attacker only needs to be right once, but defenders must be right all the time.

—Unknown

The threat of a cyberattack is a fact of life in our connected world. As new vulnerabilities are discovered, attackers will often look to take advantage of them using custom and/or commodity tools. Given the scale of these threats, operating in a strictly response capacity, or not at all, is not a prudent option. Protecting your organization’s operations and brand by establishing strong security habits combined with forward-looking practices will yield the best results. It’s useful for you to understand both the mechanics of common attacks as well as the trends associated with their usage in preparing your proactive and reactive defense plans. Additionally, having a full understanding of how common vulnerabilities may be exploited will prepare you for defending against future attacks not yet observed in the wild.

Attack Types

There are seemingly countless ways for a bad actor to gain access to privileged systems, and often a single flaw can be exploited to cause a nightmare. Many times, the exploited vulnerabilities are already well known across the Web. Hackers know that despite companies’ various disclosure mechanisms and security best practices, these targets may still be completely unaware of their malicious activities. In this section, we’ll cover common classes of attacks and how they are used to create the conditions that enable attackers to get in easily.

Injection Attacks

In injection attacks, attackers execute malicious operations by submitting untrusted input into an interpreter that is then evaluated. Security flaws may enable system calls into the operating system, where they invoke scripts and outside functionality or requests to back-end databases via database languages. Any time a web application uses an interpreter to assess untrusted data, it is potentially vulnerable to injection attacks. Injection attacks can take many forms, depending on what the attacker is trying to do and what target system is available. Injection vulnerabilities, though sometimes obscure, can be very easy to discover and exploit. The results of a successful injection attack range from a nuisance denial of service to, under certain circumstances, complete system compromise.

Remote Code Execution

Remote code execution (RCE) describes an attacker’s ability to execute malicious code on a target platform, often following an injection attack. RCEs are widely considered one of the most dangerous types of computer vulnerabilities, because they may allow for arbitrary command execution and do not require physical connectivity.

Here’s an example: An attacker may achieve RCE using a PHP built-in function called system(). If the attacker, through some reconnaissance, can determine that a web server is vulnerable to an injection attack, she might be able to invoke a shell on the server by wrapping the shell command in what is otherwise a legitimate PHP command:

http://victimwebsite.com/?code=system('whoami');

RCE attacks can be incredibly costly to the victim. Over the last decade, the popular web development framework Apache Struts has been the subject of many vulnerability disclosures. One such disclosure, covered by CVE-2017-5638, described a flaw in a parsing function for certain versions of Struts 2 that would allow for execution of arbitrary commands. This Struts 2 vulnerability gained a lot of attention from attackers and was quickly weaponized throughout the world in a matter of days. Two months after initial disclosure by Apache, it was discovered that hackers had accessed and exposed personal data of 143 million customers in what’s now known as the Equifax Breach. As of this writing, the estimated cost of remediation, clean up, penalties, and claims settlements is around $1.4 billion.

Extensible Markup Language Attack

Extensible Markup Language (XML) injection is a class of attacks that relies on manipulation or compromise of an application by abusing the logic of an XML parser to cause some unwanted action. XML injections that target vulnerable parsers generally take two forms: XML bombs and XML External Entity (XXE) attacks.

An XML bomb is an attack designed to cause the XML parser or the application it supports to crash by overloading it with data. A common XML bomb attack, the Billion Laughs attack, uses nested entities, each referring to another entity that itself may contain several others. When triggered, the parser will attempt to evaluate the input, expand the entities, and eventually run out of resources. The resulting crash can cause denial of service and application downtime. Figure 7-1 shows an example of code behind a Billion Laughs attack.

Figure 7-1 Example XML code designed to trigger a Billion Laughs attack

XXE can be used to initiate denial of service, conduct port scanning, and perform server-side request forgery (SSRF) attacks. The attack works though abuse of the XML parser to execute functions on behalf of the attacker, using a reference to an external entity. One feature of the XML standard is that it can be used to reference outside resources. By providing an input referencing an external entity, an attacker may be able to get a vulnerable XML parser to read and process normally protected data. In doing so, the parser could inadvertently leak sensitive information.

Structured Query Language Injection

SQL injection (SQLi) is a popular form of injection in which an attacker injects arbitrary SQL commands to extract data, read files, or even escalate to an RCE. To exploit this vulnerability, the attacker must find a legitimate input parameter that the web app passes through to the SQL database. The attacker then embeds malicious SQL commands into the parameter and hopes that it’s passed on for execution in the back end. These attacks are not particularly sophisticated, but the consequences of their successful usage in an attack are particularly damaging, because an attacker can obtain, corrupt, or destroy database contents.

Cross-Site Scripting

Cross-site scripting (XSS) is a type of injection attack that leverages a user’s browser to execute malicious code that can access sensitive information in the user’s browser, such as passwords and session information. Because the malicious code resides on the site that the user accesses, it’s often difficult for the user’s browser to know that the code should not be trusted. XSS thus takes advantage of this inherent trust between browser and site to run the malicious code at the security level of the website.

XSS comes in two forms: persistent and nonpersistent. With persistent attacks, malicious code is stored on a site, usually via message board or comment postings. When other users attempt to use the site, they unwittingly execute the code hidden in the previously posted content. Nonpersistent attacks, also referred to as reflected XSS, take advantage of a flaw in the server software. If an attacker notices a XSS vulnerability on a site, he can craft a special link, which when passed to and clicked on by other users, would cause the browser to visit the site and reflect the attack back onto the victim. This could cause an inadvertent leak of session details or user information to whatever server the attacker specifies. These links are often passed along through e-mail and text messages and appear to be innocuous and legitimate.

Another type of attack, called a DOM-based XSS attack, occurs when an attacker injects a malicious script into the client-side HTML being parsed by a browser. The DOM, or Document Object Model, is the standard by which a client, or more specifically, the browser, interacts with HTML. If website code either does not properly validate input or encode data correctly, it creates the opportunity for an attacker to modify code en route to initiate a XSS attack. Importantly, no server resources are affected using the method. The page, its HTML contents, and the associated HTTP response do not change, but the modifications that result from the malicious script cause the client to execute abnormally. Detecting DOM-based attacks using server-side tools is impossible because the traffic will look identical to legitimate traffic. Defense against DOM-based XSS involves sanitizing client-side code through inspection of DOM objects and using intrusion prevention systems that are able to inspect inbound traffic to determine if unusual parameters are being passed.

Directory Traversal

A directory traversal attack enables an attacker to view, modify, or execute files in a system that he wouldn’t normally be able to access. For web applications, these files normally reside outside of the web root directory and should not be viewable. However, if the server has poorly configured permissions, a user may be able to view other assets on the server. If an attacker determines a web application is vulnerable to directory traversal attack, he may use one or more explicit Unix-compliant directory traversal character sequences (../) or an encoded variation of it to bypass security filters and access files outside of the web root directory. Figure 7-2 shows the execution of a simple directory traversal attack against a vulnerable server. In this example, an attacker uses the wget utility to crawl up and down the file system to recover the unprotected /etc/passwd file.

Figure 7-2 Output from a successful directory traversal

Buffer Overflow Attacks

Attackers often will write malware that takes advantage of some quality or operation of main memory. Memory is an extremely complex environment, and malicious activities are prone to disrupt the delicate arrangement of elements in that space. The temporary space that a program has allocated to perform operating system or application functions is referred to as the buffer. Buffers usually reside in main memory, but they may also exist in hard drive and cache space. You may be familiar with the type of buffer used by video-streaming services. Streaming services often uses buffers to ensure smooth video playback and to mitigate the effects of an unexpected drop in connectivity. As the video is playing, upcoming portions are saved to memory in a sliding window. If the connection is dropped, the video can be played directly from the buffer until the connection resumes; the more buffer space the system has, the longer it is able to maintain the temporary streaming. Buffers in software enable operating systems to access data efficiently since RAM is among the fastest types of storage.

When the volume of data exceeds the capacity of the buffer, the result is buffer overflow. If this occurs, a system may attempt to write data past the limits of the buffer and into other memory spaces. Attackers will sometimes find ways to craft input into a program in a way that will cause the program to attempt to write too much data to a buffer. If the boundaries of data are well understood, an attacker may be able to overwrite legitimate executable data and replace it with malicious code.

Buffer overflows affect nearly every type of software and can result in unexpected results if not managed correctly. The Heartbleed Bug discussed in Chapter 5 resulted from a buffer overflow vulnerability that was not correctly addressed and resulted in exposure of information. Even though these types of attack are well understood, they are still fairly common. If an attacker is off by even a byte when writing to memory, this could cause memory errors that terminate processes and display some sort of message indicating this condition to the user. This type of symptom is particularly likely if the exploit is based on buffer overflow vulnerabilities. Fortunately, these messages sometimes indicate that the attack failed. Your best bet is to play it safe and take a memory dump so you can analyze the root cause of the problem.

To understand how specific types of buffer attacks work, it’s useful to understand the different types of memory allocation techniques. Generally, system memory is divided into two parts, the stack and the heap. The stack is a type of data structure that operates on the principle of last-in, first-out—the data that was last added to the stack is the first removed during a read operation. The stack is a structured, sequential memory space that is statically allocated for specific operations. The heap, in contrast, is an unstructured body of memory that the computer may use to satisfy memory requests. Heap memory allocation is done on a dynamic basis as space becomes available to use. A useful resource is security legend Elias Levy’s 1996 article, “Smashing the Stack for Fun and Profit,” a seminal piece into understanding and exploiting various buffer overflow vulnerabilities.

Stack-Based Attacks

Stack-based buffer overflows work by overwriting key areas of the stack with too much data to enable custom code, located elsewhere in memory, to be executed in place of legitimate code. Stack-based overflows are the most common and well known of all buffer overflow attacks, and the terms are often used interchangeably. Stack-based attacks have a special place in security history. The first widely distributed Internet worm was made possible through a successful stack-based buffer attack. The Morris Worm, written by graduate student Robert Tappan Morris from Cornell University in the late 1980s, took advantage of a buffer overflow vulnerability in a widely used version of fingerd, a daemon for a simple network protocol used to exchange user information. In short, the worm’s main purpose was to enumerate Internet-connected computers by connecting to a machine, replicating itself, and sending that copy on to neighboring computers. Morris’s activity also resulted in the first conviction under the 1986 Computer Fraud and Abuse Act.

Heap-Based Attacks

Attacks targeting the memory heap are usually more difficult for attackers to implement because the heap is dynamically allocated. In many cases, heap attacks involve exhausting the memory space allocated for a program. To make things more complicated for attackers, the success of a heap-based overflow does not always mean a successful exploit, since data in the heap must be corrupted rather than just overwritten.

Integer Attacks

An integer overflow takes advantage of the fixed architecture-defined memory regions associated with integer variables. In the C programming language, the integer memory regions are capable of holding values of up to 4 bytes, or 32 bits. This means the integer value range is –2,147,483,648 to 2,147,483,647. If a value is submitted that is larger in size than the 4-byte limit, then the integer buffer may be exceeded. The challenge with an integer overflow lies in its difficulty of detection, since there may not be an inherent way for a process to determine whether a result it calculated is correct. Most integer overflows are not exploitable because memory is not being overwritten, but they can lead to other types of overflow conditions. Real-life examples of exploits are rare but not unheard of.

In 2001, the CERT Coordination Center released Vulnerability Note VU#945216, which described a flaw in the SSH1 protocol that could allow for remote code execution. Curiously, the fault existed in a function designed to detect cyclic redundancy check (CRC) attacks. The function makes use of a hash table to store connection information used in determining abuse patterns. With a specially crafted packet of a length greater than the function’s integer buffer, an attacker could create a null-sized table, or one with no value, and allow for the attacker to modify arbitrary addresses within the daemon. What’s worse is that this attack could be executed before any authentication occurred, meaning the system may essentially have no defenses against it.

Privilege Escalation

Privilege escalation is simply any action that enables a user to perform tasks she is not normally allowed to do. This often involves exploiting a bug, implementation flaw, or misconfiguration. Escalation can happen in a vertical manner, meaning that a user gains the privileges of a higher privilege user. Alternatively, horizontal privilege escalation can be performed to get the access of others in the same privilege level. Attackers will use these privileges to modify files, download sensitive information, or install malicious code.

Authentication Attacks

In securing authentication systems, the main challenge lies in identifying and communicating just the right amount of information to the authentication system to make an accurate decision. These are machines, after all, and they will never truly know who we are or what our intentions may be. They can form a decision based only on the information we give them and the clues about our behavior as we provide that data. If an attacker is clever enough to fabricate a user’s information sufficiently, he is effectively the same person in the eyes of the authentication system.

Password Spraying

Password spraying is a type of brute-force technique in which an attacker tries a single password against a system, and then iterates though multiple systems on a network using the same password. In doing so, an attacker may avoid account lockouts from a single system. Detecting spraying attempts is much easier if there is a unified interface, such as that provided by a security information and event management (SIEM) solution, on which an analyst can visualize events from a range of security information sources. Common ways to detect password spraying include the following:

•   High number of authentication attempts within a defined period of time across multiple systems

•   High number of bad usernames, or usernames that don’t match company standard

•   High number of account lockouts over a defined period of time

•   Multiple successful logins from a single IP in a short timeframe

•   Multiple failed logins from a single IP in a short timeframe

Mitigation of spray techniques includes several technical and policy measures designed to add cost to the attackers, or to add visibility and response capabilities for analysts. The following is a short list of mitigations for attacks against password-spraying attacks:

•   Implement and enforce multifactor authentication (MFA) on all systems.

•   Enforce a password policy that requires complexity, password resets, and password rotation.

•   Disallow use of the same password on multiple systems whenever possible.

•   Increase alerting and monitoring through integration into a SIEM solution.

•   Enforce IP blacklisting for abusive traffic.

Credential Stuffing

Credential stuffing is a type of brute-force attack in which credentials obtained from a data breach of one service are used to authenticate to another system in an attempt to gain access. Given the scale and rate of data breaches, credential stuffing continues to be a major problem for the security and safety of organizations and data. Recent data breaches have each exposed hundreds of thousands to millions of credentials. When aggregated as “collections,” these numbers can easily top billions. If even a small fraction of a credentials list can be used to gain access to accounts, it’s worth it from the attacker’s vantage point, especially with the use of automation. For organizations, mandating MFA is effective in slowing the effectiveness of attacks, especially those that are automated.

Impersonation

Sometimes attackers will impersonate a service to harvest credentials or intercept communications. Fooling a client can be done one of several ways. First, if the server key is stolen, the attacker appears to be the server without the client possibly knowing about it. Additionally, if an attacker can somehow gain trust as the certificate authority (CA) from the client, or if the client does not check to see if the attacker is actually a trusted CA, then the impersonation will be successful.

Man-in-the-Middle

Essentially, man-in-the-middle (MITM) attacks are impersonation attacks that face both ways: the attacker impersonates both the client to the real server and the server to the real client. Acting as a proxy or relay, the attacker will use her position in the middle of the conversation between parties to collect credentials, capture traffic, or introduce false communications. Even with an encrypted connection, it’s possible to conduct an MITM attack that works similarly to an unencrypted attack. In the case of HTTPS, the client browser establishes a Secure Sockets Layer (SSL) connection with the attacker, and the attacker establishes a second SSL connection with the web server. The client may or may not see a warning about the validity of the client, as shown in Figure 7-3.

Figure 7-3 Firefox warning displaying information regarding a website’s certificate validity

If a warning appears, it’s very likely that the victim may ignore or click though the warning. The tendency for users to ignore warning highlights the importance of user training. The Firefox browser attempts to give as much information to the user about what’s happening in as plainly as possible. Firefox offers detailed information about the certificate for more technical users to use in troubleshooting any potential issues. Note that the certificate details shown in Figure 7-4 are valid only for certain domains, which prompted the initial warning from the browser. It’s possible for the warning not to appear at all, which would indicate that the attacker has managed to get a certificate signed by a trusted CA.

Figure 7-4 Firefox certificate details screen

Session Hijacking

Session hijacking is a class of attacks by which an attacker takes advantage of valid session information, often by stealing and replaying it. HTTP traffic is stateless and often uses multiple TCP connections, so it uses sessions to keep track of client authentication. Session information is just a string of characters that appears in a cookie file, the URL itself, or other parts of the HTTP traffic. An attacker can get existing session information through traffic capture, an MITM attack, or by predicting the session token information. By capturing and repeating session information, an attacker may be able to take over, or hijack, the existing web session to impersonate a victim.

Rootkits

Rootkits are among the most challenging types of malware because they are specially designed to maintain persistence and root-level access on a system without being detected. As with other types of malware, rootkits can be introduced by attacker leveraging vulnerabilities to achieve privilege escalation and clandestine installation. Alternatively, they may be presented to a system as an update to BIOS or firmware. Rootkits are difficult to detect because they sometimes reside in the lower levels of an operating system, such as in device drivers and in the kernel, or even in computer hardware itself, so the system cannot necessarily be trusted to report any modifications it has undergone.

Vulnerabilities

Attackers often use software vulnerabilities to get around an organization’s security policies intended to protect its data. Sometimes the flaws exist in how the rules are written, how the mechanism is implemented, or what functions are called in the operation of the software. All computer systems have vulnerabilities, but depending on the number and type of compensating controls in place, they may or may not result in damage if exploited. As we describe these errors, it’s important for you to remember that all of the vulnerabilities have some relevance to the secure operation of your company’s software and network. They aren’t just mistakes that inhibit usability or the look of the software, but rather enable attackers to do something they wouldn’t otherwise be able to do. They will sometimes result in unexpected and often undesirable behavior, but in many cases, they can be addressed using secure coding practices and thoughtful review processes before code ever goes to production.

Improper Error Handling

Error handling is an important and normal function in software development. Although developers work to identify problems quickly, consistently, and early, errors related to memory, network, systems, and databases routinely pop up in a production environment. Improper error handling can be a security concern when too much information is disclosed about an exception to outside users. When internal error messages such as stack traces, database dumps, and error codes are displayed to the user, they may reveal details about internal network configuration or other implementation details that should never be revealed. For attackers, this kind of information can provide the situational awareness they need to craft very specific exploits.

Sometimes error messages don’t reveal a lot of detail, but they can still provide clues to help attackers. Notices about file unavailability, timeout conditions, and access denial could reveal the presence or nonpresence of a resource or indications about a file system’s directory structure. As part of a secure coding practice, policies on error handling should be documented, including what kind of information will be visible to users and how this information is logged. Messages should be simple, conveying only what’s needed in a consistent way to avoid disclosing too much about the platform.

Dereferencing

A dereferencing vulnerability, or null point dereference, is a common flaw that occurs when software attempts to access a value stored in memory that does not exist. A null pointer is a practice in programming used to direct a program to a location in memory that does not contain a valid object. This vulnerability has legitimate uses when used as a special marker, but security issues arise when it is dereferenced or accessed. Often, dereferencing results in an immediate crash and subsequent instability of an application. Attackers will try to trigger a null pointer dereference in the hopes that the resulting errors enable them to bypass security measures or learn more about how the program works by reading the exception information.

Insecure Object Reference

Insecure object reference vulnerabilities occur when the object identifiers in requests are used in a way that reveals a format or pattern in underlying or back-end technologies, such as files, directories, database records, or URLs. If database records are stored in a sequential manner and referenced directly by a function, for example, an attacker may be able to use this predictable pattern to identify resources to target directly, thereby saving him time and effort.

Rather than referencing sources directly, developers can avoid exposing resources by using an indirect reference map. With this method, a random value is used in place of a direct internal reference, preventing inadvertent disclosure of internal asset locations. Enforcing access controls at the object level also addresses the primary issue with this vulnerability: insufficient or missing access check. While client-side validations for access may be useful, server-side will be more effective at verifying that the current user owns or is allowed to access the requested data.

Race Condition

A race condition vulnerability is a defect in code that creates an unstable quality in the operation of a program arising from timing variances produced by programming logic. These deviations from timing could mean that a program that relies on sequential execution of a series of actions may experience two actions attempting to complete at the same time, or actions that attempt to complete out of order. A subclass of race condition vulnerabilities, time-of-check to time-of-use (TOCTOU), is often leveraged by attackers to cause issues with data integrity. TOCTOU is used by software to check the state of a resource before its use. If the state of the resource is changed between the checking and usage window, it may result in unexpected behavior from the software.

All kinds of software are vulnerable to race condition attacks. One way that an attacker may target this vulnerability is to bypass any restrictions imposed by an access control list (ACL). CVE-2016-7098 refers to such a possibility in its description of a flaw in wget, a popular command-line tool that allows file retrieval from servers. This vulnerability affects the way that wget applies its ACLs during the download process. In this case, if a download is initiated with recursive options, the utility will wait until the completion of the download to apply the rules. An attacker may take advantage of this by inserting malicious code or altering a file mid-download, before the application has a chance to finish the transfer. Because the file gets deleted only after the connection closes, the attacker could keep the connection open and make use of the malicious file before its deletion.

Sensitive Data Exposure

Sensitive data exposure vulnerabilities occur when an application or system does not adequately protect data from access to unauthorized parties. Data can include authentication information, such as logins, passwords, and tokens, as well as personally identifiable information (PII), protected health information (PHI), or financial information. Recent advances in legislation and privacy laws, such as the European Union’s General Data Protection Regulation (GDPR), attempt to enhance protections around this kind of sensitive data. To help identify vulnerabilities in the space, you may find it useful to go through a few questions related to the data your organization handles:

•   Is any data transmitted in cleartext across your networks?

•   Are any old, weak, or custom cryptographic algorithms and libraries used in your organization’s code?

•   Are default cryptographic keys in use?

•   Are cryptographic keys rotated on a regular basis?

•   Is encryption enforced across services?

•   Do clients properly verify server certificates?

At the minimum, all organizations can follow a set of practices to ensure baseline protections against exploits of data exposure vulnerabilities. The process begins with identifying which data is sensitive according to privacy laws, regulatory requirements, or your organization’s own definitions. As the data is introduced into various systems and applications for processing and transmission, there needs to be a way to identify these various levels of sensitivity by some technical means. From this point, it’s straightforward for the data to be processed, stored, and transmitted in accordance with these standards. Furthermore, auditing can be made easier if the technical foundation is in place.

In terms of data storage, it’s important to collect and store only the minimum amount of data needed to fulfill a business requirement. It’s important that sensitive information be stored only as long as necessary and not beyond its usefulness. Stored data should be encrypted using strong standard algorithms and protocols. Private keys should be stored in a way that protects their disclosure and integrity. Strong encryption is also critical for all data in transit. When possible, your organization should promote usage of standards such as Transport Layer Security (TLS) with perfect forward secrecy (PFS) ciphers and HTTP Strict Transport Security (HSTS).

Insecure Components

Though modern software development practices make use of open source and external components to speed up the software development process, overreliance on these components, especially when they’re not fully examined from a security aspect, can lead to dangerous exposure of your organization’s data. Developers need to know what these components are doing, how they’re interacting with internal assets and data, and what compensating controls can be put into place to address security issues related to their use. Some vulnerabilities related to insecure components may lead to minor impacts in performance, but others can lead to major security events. What’s more, promises about the security of an external component may even lead to a false sense of security, making the impact potentially worse because there was some expectation of protection.

Insufficient Logging and Monitoring

Earlier in the chapter, we touched on the concept of errors as a way for developers to get feedback about their software and find ways to improve performance and stability. Like errors, logging gives critical feedback about the state of a system, enabling analysts to trace events back to their beginning as they work to determine root cause. The main vulnerability with logging is the nonexistence of logging mechanisms at key points within the network that would give insight into malicious and abusive behaviors. Nearly all network devices, operating systems, and other types of hosts provide one or more options for logging, often at various levels of detail (or verbosity). However, developers might disable or misconfigure logging during development and never turn it back on. Good logging practice is also much more than just having the feature enabled—it’s about setting the conditions under which logs can be ingested, understood, and operationalized easily. This may include developing intermediate steps such as setting up specialized servers and normalizing the data. Security without logging is so much harder because, as with asset visibility, you cannot defend what you cannot see.

As best practice, the Open Web Application Security Project (OWASP) recommends that logging be configured for the following activities:

•   Input validation failures such as invalid parameter names and values, and protocol violation

•   Output validation failures such as invalid data encoding

•   Authentication successes and failures

•   Access control failures

•   Session management failures

•   Application and component syntax and runtime errors

•   Connectivity problems

•   Malware detection

•   Configuration modifications

•   Application and related system startups and shut-downs

•   Logging functionality and state changes

•   Actions by administrative accounts

It’s also important to define what to exclude for logging. Data that is not legally sanctioned, or that may have serious privacy implications for users, should not be part of the logging effort. This usually includes some types of privileged communications, data collected without consent, payment card holder data, encryption keys, sensitive PII, access tokens, passwords, and intellectual property data. Keep in mind that local laws may explicitly forbid the collection of certain classes of data.

Weak or Default Configurations

Earlier we covered the concept of a vulnerability window, the time between the disclosure of a flaw from a vendor and the moment an organization is able to patch the flaw. Attackers will often attempt to exploit unpatched flaws during this time, or they may perform actions to cause a system to revert to a weakened state. Though Microsoft aimed to stop the cat-and-mouse game between attackers and defenders by modifying their predictable “Patch Tuesday” release model, attackers nevertheless pay close attention to disclosure announcements on a continual basis to maximize the vulnerability window.

Often attackers will attempt to take advantage of default accounts and settings in the hopes that administrators have not changed them. Security misconfigurations like this can exist at any level, from a factory password left on a wireless access point to static credentials left on enterprise devices. In some cases, despite a security team’s best effort, these credentials may not be able to be changed. An example of this last condition is described in an advisory issued by Cisco in 2019 and covered in CVE-2019-1723. There was a flaw in a previous version of the Cisco Common Service Platform Collector (CSPC), a tool used for gathering information from Cisco devices on a network, that allowed anyone to access and control the tool using a static default password.

Use of Insecure Functions

Even with a major focus on secure coding practices across the development industry, the use of insecure and dangerous functions is still a common occurrence. This vulnerability occurs when a function is invoked by a program that introduces a weakness into a system based on its implementation or inherent qualities. These functions may be used to perform the job they were designed for, but at greater risk to the organization employing them. Sometimes, the function can never be guaranteed to be used safely. This is the case with gets(), an inherently unsafe C function that operates by blindly copying all input from STDIN to the buffer without checking size. This is problematic because it may enable the user, intentionally or unwittingly, to provide input that is larger than the buffer size, resulting in an overflow condition.

strcpy

The strcpy() function simply copies memory contents into the buffer, ignoring the size of the area allocated to the buffer. This attribute can easily be misused in a manner that could enable an attacker to cause a buffer overflow. A short example of how this may occur is shown here:

Although there are some alternatives to some of these functions advertised as safe, those functions may themselves be vulnerable to other types of attacks. The strncpy() function, for example, is said to be a safer version of strcpy(), because it enables a maximum size to be specified. However, the strncpy() function doesn’t null terminate the destination if the buffer is completely filled, which may lead to stability problems in code. As a security analyst, it’s important that you not take alternative recommendations for granted. Doing so can give you a false sense of security and may introduce additional vulnerabilities.

Chapter Review

There are effective ways to reduce your organization’s exposure to the common types of attacks that we discussed in this chapter. Additionally, there are a number of controls that your organization can put into place at low cost to reduce the likelihood of the existence or exploitation of system flaws. With strong access controls, your security team will be able to defend both at the perimeter of the network and within its boundaries. Modern security appliances and software enable access control methods to be applied at a granular level, and it’s worth taking advantage of these features. Web proxies and filters can be used to detect and block executable downloads, or to block access completely to known malicious domains. For commonly used malware, it’s important for you to maintain a method to detect and respond to known malicious code using an endpoint and network-based tooling. Furthermore, preventing unknown software from being able to run at all using whitelisting rules is extremely effective in preventing exploits. To address software and implementation flaws, it’s critical that you develop a vulnerability remediation plan to enable the team to detect and patch common vulnerabilities.

Questions

1.   What kind of attack takes advantage of compatibility functionality provided by a program or protocol to force a user into operating in a less secure mode?

A.   Downgrade attack

B.   Side-channel attack

C.   Passthrough attack

D.   Hijacking

2.   Attacks that rely on an interpreter to evaluate untrusted input and execute tasks on an attacker’s behalf are known by what name?

A.   Injection attacks

B.   Authentication attacks

C.   Exhaustion attacks

D.   Overflow attacks

3.   What is the primary difference between a memory heap and memory stack?

A.   The stack allows for memory reservations beyond the limits of the buffer, while the heap does not.

B.   The stack is a structured, statically allocated memory space, while the heap space is not reserved in advance.

C.   The heap allows for memory reservations beyond the limits of the buffer, while the stack does not.

D.   The heap is a structured, statically allocated memory space, while the stack space is not reserved in advance.

4.   Software that checks the status of a resource before using it, but allows a change between initial check and final usage, suffers from what kind of vulnerability?

A.   Buffer overflow

B.   Race condition

C.   Injection

D.   Derefencing

Use the following scenario to answer Questions 5–8:

Your security team is made aware of a massive data breach of a popular social media platform. According to analysts of the breach, the records include details such as credit card information, e-mail addresses, language preference, and passwords. Although there is no connection between the social media platform and your organization, you are concerned about the security implications to your company given the popularity of the platform.

5.   You are aware that password reuse is a common occurrence and urge the team to issue a mandatory password reset for all users in hopes of preventing which kind of attack?

A.   Session hijacking

B.   Downgrade attack

C.   Password spraying

D.   Credential stuffing

6.   Your security dashboard sends an alert indicating that in the last hour, the same user had several unsuccessful login attempts across eight internal systems. What type of attack has most likely occurred?

A.   Session hijacking

B.   Man-in-the-middle attack

C.   Password spraying

D.   Firehose attack

7.   Security analysts investigating the breach have now indicated that attackers were able to target their attack to a specific system based on information recovered from an exception that was raised during their reconnaissance. Based on this information, what type of vulnerability did the attacks likely take advantage of?

A.   Improper error handling

B.   Insecure object reference

C.   Use of insecure functions

D.   Use of default configurations

8.   The information recovered from the previously identified reconnaissance effort indicated the use of a publicly facing security device known to have a static password in previous versions of its firmware. Analysts discovered that the firmware was never upgraded and static credentials were used to get into the device. What flaw is likely to have been exploited?

A.   Improper error handling

B.   Insecure object reference

C.   Use of insecure functions

D.   Use of default configurations

Answers

1.   A. Downgrade attacks are characterized by techniques that cause services to operate in a mode that offers lower levels of security, such as HTTP instead of HTTPS.

2.   A. In injection attacks, attackers execute undesirable operations by submitting untrusted input into an interpreter that is then evaluated.

3.   B. The stack is a type of reserved, sequential memory space that operates on the principle of last-in, first-out, while the heap is an unstructured body of memory that the computer may use as needed.

4.   B. A race condition vulnerability is a flaw in the operation of a program that may allow two actions to attempt completion at the same time or to perform actions out of order, resulting in integrity or stability issues.

5.   D. Credential stuffing is a type of brute-force attack where credentials obtained from a data breach of one service are used to authenticate to another system.

6.   C. Password spraying is a type of brute-force technique in which an attacker tries a single password against a system, and then iterates though multiple systems on a network using the same password.

7.   A. Improper error handling is a vulnerability that allows for too much information to be disclosed about an exception to outside users.

8.   D. Default configuration exist at many levels, from standard factory passwords to static credentials on enterprise devices. Attackers will take advantage of these settings to get around other security mechanisms.