CompTIA Security SY0-601 Exam: Basics of Application Attacks

Given a scenario, analyze potential indicators associated with application attacks.

Topic covered:
- privilege escalation
- cross-site scripting (XSS)
- injection
- directory traversal
- buffer overflow
- race condition
- time-of-check to time-of-use (TOCTOU)
- error handling
- improper input handling
- replay attack
- integer overflow
- cross-site request forgery (CSRF)
- server-side request forgery (SSRF)
- application programming interface (API) attack
- resource exhaustion
- memory leak
- Secure Sockets Layer (SSL) stripping
- shimming
- refactoring
- pass-the-hash attack

Many attacks don’t always lead to the ultimate objective. Often attackers combine these types of attacks with subsequent application and service attacks. For example, an attacker may tailgate into a sensitive area to gain access and then conduct further attacks.
The evolution of web- or cloud-based application resources available via the HTTP and HTTPS protocols presents an “anytime/anywhere” approach to enterprise network resource availability. As more applications are migrated into a browser, attackers have an increasingly large attack surface area for interception and interaction with user input and for directed attacks against web-based resources.

Race Conditions
A race condition involves software and, specifically, the way a program executes sequences of code. A race condition typically occurs when code sequences are competing over the same resource or acting concurrently. Time-of-check to time-of-use (TOCTOU) is an example of a race condition; it is an asynchronous attack that exploits timing. TOCTOU takes advantage of the time delay between the checking of something and the usage of something. Here’s a simple analogy to consider: Say that you want to withdraw $100 from your bank’s ATM. First, you check your balance and see that you have $100. Next, you initiate the withdrawal, but you are told that you don’t have sufficient funds. Between the “check” and the “use,” your spouse used a different ATM to make a withdrawal.
Race conditions can result in unexpected and undesirable results or can even result in malfunction. Race conditions also can cause denial of service. In fact, a race condition can cause null pointer errors. With a null pointer error, an application dereferences a pointer that it expects to be valid but that is really null, resulting in a system crash. Race conditions are also associated with allowing attackers to exploit system processes to gain elevated access to areas that otherwise should be restricted. This is known as privilege escalation.
A race condition exploits a small window of time in which one action impacts another. These out-of-sequence actions can result in system crashes, loss of data, unauthorized access, and privilege escalation.

Improper Software Handling
Software should be designed to ensure proper handling of input into the system, as well as proper error handling. Both of the following software errors can have operational impacts on an organization and its users, as well as security impacts:
- Improper input handling: Solutions that don’t properly validate input into the system can affect data flow and expectations; this is called improper error handling. An attacker might be able to gain control of a system or inject code for remote execution.
- Improper error handling: When software is not designed to properly handle errors, the result might be release of message and diagnostic information that is sensitive to the inner workings of the systems. This data can disclose details to an end user and allow an attacker to gain sufficient information to advance an attack.
Software that is not properly designed to validate input or manage errors is vulnerable to program manipulation and could reveal information that should not be disclosed.

Resource Exhaustion
Computing systems often have finite hardware resources available. Cloud computing systems might offer elasticity in terms of ability to scale, but monetary costs are associated with such scalabilty. If software does not properly manage resources such as memory, CPU, and storage, a system might completely consume or exhaust its resources. The most obvious impact of such a situation is denial of service. Without the required resources, users will not be able to access the system, and processing can be impacted. Resource exhaustion can also result from other unexpected events and attacks. For example, with a memory leak, all available memory is exhausted from the system, resulting in slow operations or unresponsiveness. At their best, memory leaks reduce the performance of a system. If left unchecked, they can cause an entire application or computer to become unresponsive, thus impacting a system’s availability.

Overflows
Buffer overflows cause disruption of service and lost data. An overflow occurs when the data presented to an application or service exceeds the storage space that has been reserved in memory for that application or service. Poor application design might allow the input of 100 characters into a field linked to a variable that is capable of holding only 50 characters. The application would not know how to handle the extra data and would become unstable. The overflow portion of the input data must be discarded or somehow handled by the application; otherwise, it can create undesirable results. Because no check is in place to screen out bad requests, the extra data overwrites some portions of memory that other applications use and then causes failures and crashes. A buffer overflow can result in the following:
- Data or memory storage may be overwritten.
- An attack may overload the input buffer’s capability to cope with the additional data, resulting in denial of service.
- The originator might execute arbitrary code, often at a privileged level.

An integer overflow is another type of overflow that is specific to whole numbers, known as integers. For example, 12 is an integer, but 12.1 is not. When programs do not carefully account for integer overflows, undesirable behaviors and consequences can result. Imagine a typical vehicle odometer. For example, most vehicle odometers support only six digits, which go to 999,999 miles or kilometers. Many vehicles are lucky to see 200,000 miles, but what happens if a car drives 1 million miles? The odometer suffers from an integer overflow and then shows that 0 miles have been driven. Put another way, a program designed to hold an integer of 8 bits could support a number up to 255, which is 11111111 in binary. The number 256 requires an extra bit and equates to binary 100000000. If this program accepted the decimal number 256, it could interpret 256 as 0 (accepting only the last 8 bits) or as 128 (accepting only the first 8 bits).
Overflows present an opportunity for compromise using privilege escalation. Services require special privileges for their operation. A programming error could allow an attacker to obtain special privileges. In such a situation, two possible types of privilege escalation exist: a programming error enabling a user to gain additional privileges after successful authentication and a user gaining privileges with no authentication.
Good quality assurance and secure programming practices can thwart buffer overflows. Currently, the most effective ways to prevent an attacker from exploiting software are to keep the software patched and updated and to monitor the web for newly discovered vulnerabilities.

Code Injections
A buffer overflow could enable an attacker to execute code outside of a specific application. Code injection, such as dynamic link library (DLL) injection, specifically allows an attacker to run code within the context of another process, which makes it difficult for the organization to trace the attack.
Arbitrary code execution can occur when an attacker is able to execute programs and commands on an attacked machine. Exploits are designed to attack bugs in software that provide the methods for running these commands. From a vulnerability standpoint, these types of bugs are significant because they allow the attacker to overtake a process. This capability increases the likelihood that the attacker can then completely take control of the client system. A system vulnerable to such code execution is highly susceptible to malware, which does not require the owner’s consent. This problem is compounded with remote code execution. Specifically, such code can run across networks and even the Internet.
Preventing these attacks begins with using secure coding practices. Unfortunately, end users are sometimes at the mercy of their software vendors. Therefore, it is important for end users to keep their systems patched and for organizations to pay attention to the types of software vulnerabilities. Arbitrary remote code execution vulnerabilities need to be prioritized in the remediation process.

Application developers and security professionals need to be aware of the different types of threats from malicious code. Using malicious code injection, attackers can perform a variety of attacks on systems. Proper input validation is a primary means of preventing such attacks. Injection attacks can result in modification or theft of data. Examples of common code injection techniques include the following:
- Cross-site scripting (XSS): By placing a malicious client-side script on a website, an attacker can cause an unknowing browser user to conduct unauthorized access activities, expose confidential data, and log successful attacks back to the attacker without users being aware of their participation. Cross-site scripting (XSS) vulnerabilities can be exploited to hijack a user’s session or to cause the user accessing malware-tainted Site A to unknowingly attack Site B on behalf of the attacker who planted code on Site A.
- SQL injection: In this type of attack, malicious code is inserted into strings that are later passed to a database server. The SQL server then parses and executes this code.
- LDAP injection: With this type of attack, which is similar to SQL injection, malicious input is applied to a directory server, which may result in unauthorized queries, granting of permissions, and even password changes.
- XML injection: An attacker can manipulate the logic of an application in order to perform unauthorized activity or gain unauthorized access by inserting Extensible Markup Language (XML) into a message.
- DLL injection: DLL injection involves inserting malicious code into a running process. This code injection technique takes advantage of dynamic link libraries (DLLs), which applications load at runtime. A successful attack occurs when the legitimate process hooks into the malicious DLLs and then runs them.
These attacks take advantage of coding flaws, which are preventable. In fact, many application and web development frameworks provide built-in resources and tools to prevent such errors. The Windows operating system now protects against DLL injection by using a protected process system to prevent attacks by ensuring that only trusted code gets loaded.
Proper input validation cannot prevent DLL injection attacks. Rootkits use DLL injection to hook themselves into older versions of the Windows operating system.
If given specific scenarios on the exam, remember that the different injection techniques are based on their targets: SQL injections target databases, LDAP injections target directory servers, and XML and DLL injections target applications.

Driver Manipulation
Kernel-mode device drivers, which most operating systems support, run at a much lower level than the operating system and with the same privileges as the operating system. Driver manipulation is a process that can legitimately be done to help improve performance, ensure compatibility, and improve security. However, the manipulation of device drivers also has the potential to do the opposite and even completely subvert a system. A driver manipulation attack is often a result of malicious code written specifically for system device drivers in order to modify their behavior.

Two concepts related to driver manipulation are important:
- Shimming: In the case of incompatible device drivers, a developer can either write a shim (a piece of code between two components that is then capable of intercepting calls) to provide compatibility or rework the existing driver through refactoring. Shimming can also be used as a sophisticated hack that involves installing a shim. Once calls are intercepted, the shim can handle the operation, make changes, and even redirect the call.
- Refactoring: Refactoring helps improve the manageability of code, which also helps reduce complexity and improve code extensibility without changing its outward behavior. Malware can potentially exploit poorly written code that is not refactored and look for vulnerabilities. In addition, a skilled attacker could refactor code and trick the underlying system into using the manipulated driver with malicious intent. It is therefore important to verify trusted code using cryptographic techniques to ensure the integrity of the code components allowed on the systems.

Request Forgeries
You need to be familiar with a couple types of attacks that take advantage of how a web server handles URLs:
- Cross-site request forgery (CSRF or XSRF)
- Server-side request forgery (SSRF)
Both of these attacks are made possible by a web server being improperly configured in the way it handles URLs. Otherwise, the two attacks are very different.
A cross-site request forgery (CSRF) causes end users to execute unwanted actions on a site they are already logged in to. The attacker prepares a specially crafted URL that is initiated on the client side, from the web browser. This could result in the user changing her own password to something the attacker knows or taking some other desired action. Imagine that you are logged in to a social media website. You then browse to another site in a different browser tab. Meanwhile, without your knowledge, that second site sends a request that includes code to post a status update on your social media account. If you remain logged in and the social media site is not designed to protect against such forged requests, this type of attack is entirely possible.
Keep in mind that with a CSRF attack, the user is tricked into going to a specially crafted URL, either by directly clicking on it or by going to a website under the attacker’s control with the embedded URL. This attack relies on the user’s identity and a website’s trust in that identity. If the user is logged in to a social media account, a subsequent malicious web request can succeed because the social media page trusts the individual who is already logged in. Figure 3.1 shows an example of this type of attack. In the final step, the attacker posts a message to the social media page. If the website involved were a financial institution site, the final request might transfer funds to the attacker.

An attacker uses CSRF to trick a victim into unknowingly posting a social media status update

A server-side request forgery (SSRF), unlike a CSRF, is initiated from a web server through a vulnerable web application. With a CSRF attack, the user is tricked into doing something that benefits the attacker. In contrast, an SSRF attack is done for the purpose of compromising information from the web server or enabling other attacks, such as bypassing input validation controls or enabling the attacker to execute further commands. An SSRF attack exploits trust relationships. For example, the vulnerable web application trusts requests coming from the local server on which it’s hosted. An SSRF then forces the web server to make a web request, either back to itself or to another server. The following is a simple example of a typical web request in which the attacker makes a request to retrieve data from another internal web server, which otherwise may not be reachable by users directly (see Figure below):

Attacker exploits a vulnerable web server to make a request, unknowingly, on the victim’s behalf, as the victim web app server trusts the vulnerable web app server
 

GET http://internal-server-B.example.com/meta-data/ HTTP/1.1

Host: example.com

In the following example, the server is making a request using a special file parameter to retrieve a file from itself (in this case, the password file):
GET file:///etc/passwd HTTP/1.1

Proper input validation is vital to preventing SSRF vulnerabilities in web applications. In addition, a list of allowed domains and protocols should be required. This list, known as a whitelist, allows only the domains and protocols specified to be fetched locally or from remote resources. Directory Traversal Web and application servers vulnerable to directory traversal can potentially expose system directories and files. In the previous section, you saw that an SSRF attack can enable an attacker to access a file on the web server’s local filesystem. When possible, applications should avoid passing input from the user to the filesystem interfaces and should at least validate all input. The simplest example of directory traversal is a server application being configured in a manner that provides no protection against such attacks. Directory traversal could allow an attacker to simply view the source code for a website’s public directories and files. Or an attacker might be able to look at the path for an image on the site and see, for example, the path https://example.com/images/image.png. An attacker who tries to go to http://example.com/images/ should be denied access. However, a server that allows directory traversal may provide a list of all the images in that directory. Building on this example, images from a web application are usually loaded from HTML in the following format:

<img src="/loadImage?filename=image.png">

Image files on the server are located in the var/www/images directory. The source in this case simply returns from this base directory the image it’s instructed to load by using a filesystem API that has read access. The attacker now uses the following address in his web browser: https://example.com/loadImage?filename=../../../etc/passwd. If you are familiar with command line operations, you likely know that ../ allows you to go up a level in the directory tree. So this address is asking the server to go up three levels from var/www/images and to the /etc directory and return the passwd file, which contains all the passwords. Therefore, if you were at the command line interface on the server in the /var/www/images folder, the following commands would lead you to the same location:

cd /etc/passwd

cd ../../../etc/passwd

By now you might have surmised that web servers have their own root directory that is separate from the operating system that they use to serve content (for example, var/www). Everything in this root directory is accessible to users, and the web server restricts this information, as needed, based on controls such as access control lists. In the second example above, the attacker is able to break outside the web root directory and into other directories in the operating system. As a result, directory traversal may be an undesired vulnerability only within the web root, or the operating system might be vulnerable, potentially allowing an attacker to attain files and even execute commands from the operating system.

Replay Attack
In a replay attack, packets are captured by using sniffers. After the pertinent information is extracted, the packets are placed back on the network. This type of attack can be used to replay bank transactions or other similar types of data transfer, in the hopes of replicating or changing activities such as deposits or transfers. Consider, for example, a password replay attack. In such an attack, the attacker intercepts a password and can later send the password to authenticate as if he were the original user.
Protecting yourself against replay attacks involves some type of time stamp associated with the packets or time-valued, nonrepeating serial numbers. Secure protocols such as IPsec prevent replays of data traffic in addition to providing authentication and data encryption.
A common attack on web applications is a session replay attack. A web application assigns a user a session ID (often stored in a cookie) that is good for the session (that is, the visit or use of the application). In this attack, the attacker retrieves the session ID from the user and uses it to appear as that authorized user within the application. Alternatively, an application may not use a cookie to maintain a session but instead might use a unique parameter value that is passed as part of the request. In this situation, an attacker could create a session ID and send it as part of a URL to another valid user (for example, https://example.com/app/login.php?SESSIONID=ATTACKER123). When the user clicks the link and logs in to the application using her own credentials, the attacker can access the account and impersonate the user by using the same URL.

Secure Sockets Layer (SSL) Stripping
Essentially, secure web transactions between a client and a server occur over the Hypertext Transfer Protocol over SSL/TLS (HTTPS) protocol, which incorporates encryption through either SSL or TLS. Most websites today use HTTPS. For example, any transaction on the web between you and your bank would be encrypted and have integrity ensured through HTTPS. With Secure Sockets Layer (SSL) stripping, an attacker strips—or removes—the encryption between the client and the website. By acting as a proxy or middleman, the attacker can establish a secure connection between himself and the server.
The figure below shows an example of this type of attack and how it’s possible to trick both the client and the server. Imagine that you are at a coffee shop and connect to the wireless network. To make this attack very simple, say that you unknowingly connect to a wireless hotspot you think is the coffee shop’s hotpot, but it actually belongs to an attacker. At this point, the attack is possible because the attacker is able to intercept an unencrypted (HTTP) request you make to your bank. The reason HTTP is used instead of HTTPS is that you haven’t established a secure connection to the bank. Most users, either by typing in directly or via a link on another unencrypted website often go to http://www.example.com rather than https://example.com. Normally this is fine, as an HTTP redirect occurs that sends your browser to the HTTPS site. The attacker uses software to intercept the HTTP traffic, and as the traffic is being redirected, the attacker strips away the use of HTTPS. Rather than connecting to your bank, you end up communicating directly with the attacker’s computer. At this point, the attacker makes a secure connection to the bank and provides the unencrypted content back to you. At this point, the attacker can capture and read all your information.

Summary of an SSL stripping attack

A number of countermeasures are available to help mitigate this type of attack. First, most websites have incorporated HTTPS by default. In addition, the introduction of HTTP Strict Transport Security (HSTS) mitigates the risk. Finally, modern browsers have introduced features that make it clear to users when HTTPS has been removed.

Application Programming Interface (API) Attacks
While application programming interfaces (APIs) have been around for decades and web APIs have existed since 1995, concern about API attacks in recent years has increased—for good reason. Modern applications across today’s mobile web and distributed environments that increasingly rely on smartphone apps aren’t monolithically designed the way applications were in the past. Instead, they are modular, composed of individual services, and are expected to provide and get their value from other services. APIs play a critical role in this by exposing application logic and making data available where it’s needed. As a result, attackers have naturally looked to APIs for their own use and also found ways to exploit them. Almost since its founding, the Open Web Application Security Project (OWASP) has annually published the OWASP Top 10 for web application security risks. APIs are so pervasive across web applications that OWASP now annually publishes a similar list for API security. The following is the OWASP’s most recent list of the top 10 risks:
- Broken Object Level Authorization: APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue. Object level authorization checks should be considered in every function that accesses a data source using an input from the user.
- Broken User Authentication: Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other users’ identities temporarily or permanently. Compromising a system’s ability to identify the client/user compromises API security overall.
- Excessive Data Exposure: Looking forward to generic implementations, developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user.
- Lack of Resources and Rate Limiting: Quite often, APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user. Not only can this impact the API server performance, leading to Denial of Service (DoS), but also leaves the door open to authentication flaws such as brute force.
- Broken Function Level Authorization: Complex access control policies with different hierarchies, groups, and roles and an unclear separation between administrative and regular functions tend to lead to authorization flaws. By exploiting these issues, attackers gain access to other users’ resources and/or administrative functions.
- Mass Assignment: Binding client-provided data (e.g., JSON) to data models, without proper properties filtering based on a whitelist, usually leads to Mass Assignment. Either guessing object properties, exploring other API endpoints, reading the documentation, or providing additional object properties in request payloads allows attackers to modify object properties they are not supposed to.
- Security Misconfiguration: Security misconfiguration is commonly a result of unsecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information.
- Injection: Injection flaws, such as SQL, NoSQL, Command Injection, and so on, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s malicious data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
- Improper Assets Management: APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. Proper hosts and deployed API versions inventory also play an important role to mitigate issues such as deprecated API versions and exposed debug endpoints.
- Insufficient Logging and Monitoring: Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems to tamper with, extract, or destroy data. Most breach studies demonstrate the time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.

Not much on this list is brand new in regard to how attackers would look to attack an application or a system. However, some of these risks may be magnified due to the nature of APIs, which are designed to expose application logic and data—often across a large population group. However, as with any other application or security system, you need to be concerned with things like authentication and authorization, understanding data sensitivity, proper configuration, ensuring availability, adequate documentation, and proper logging and monitoring.

Pass-the-Hash Attack
Most systems do not send passwords in plaintext. Instead, a system is likely to create a digital fingerprint, or cryptographic hash, of a password. Knowing a hash does not allow a system to reconstruct a password; it allows it to verify that an input maps to a particular hash value. In fact, most passwords are stored as cryptographic hashed values.
The current discussion provides a simplified example of hashing. Imagine that each letter of the alphabet corresponds to a number (A = 1, B = 2, C = 3, and so on). If your password is ABC, then by using your hashing algorithm (that is, adding up the numbers), you arrive at a value of 6. When a password is subsequently entered, it is run through the same algorithm and then compared to the stored value. If you try to enter ABD as the password, the resulting value, 7, does not match the value stored. Of course, actual hashing algorithms are much more complicated than this, but this should help you understand the concepts further.
In a pass-the-hash attack, the attacker does not need access to a user’s password. Instead, the attacker needs only the hashed value of the password. This type of attack is performed against systems that accept specific implementations of authentication schemes known as NT Lan Manager (NTLM) or LM. In such an attack, the attacker does not need the password as long as she has gained access to the cryptographic hash. The attacker then can pass this hash value to a system for authentication.

Quiz

1. An attacker exploited an interactive process in a recently developed and deployed application and was able to gain access to areas of the application from which users are otherwise restricted. Which of the following best describes what occurred? A. Driver manipulation B. Directory traversal C. Buffer overflow D. Privilege escalation

2. Which of the following attacks can be related to the length of a variable in an input not being properly checked and contained by an application? A. Input validation B. Shimming

3. A security analyst discovered on the dark web a text file containing a list of usernames along with many other attributes belonging to the organization. A review of the web server access logs reveals the following requests:

https://example.com/loadImage?filename=../../scripts https://example.com/loadImage?filename=.//.//.//etc/shadow https://example.com/loadImage?filename=../../../etc/passwd

What type of attack occurred? A. Cross-site scripting B. Refactoring C. Race condition D. Directory traversal

4. Which of the following can a race condition result in? (Select three.) A. Extensively Marked-Up Language B. System crash C. Unauthorized access

5. An attacker removes the encryption between a client and a website server and then establishes a secure connection between himself and the server. What is this technique called? A. Replay B. Integer overflow C. SSL stripping D. Cross-site request forgery

Answer 1: D. Privilege escalation occurs when an attacker is able to gain elevated access to areas that otherwise should be restricted. Although a buffer overflow may lead to privilege escalation, it’s not clear from the question that this is the best description, and so answer C is incorrect. Answer A is incorrect. Driver manipulation is done to improve performance, compatibility, or security of device drivers, and it is sometimes used by attackers with malicious intent. Answer B is incorrect. Directory traversal provides a user or an attacker the ability to list and navigate a web server or an operating system’s filesystem.
Answer 2: C. A buffer overflow may result from the length of a variable in an input not properly being checked and contained by an application. Answer B is incorrect. Shimming is a device driver manipulation technique. Answer D is incorrect as privilege escalation occurs when an attacker is able to gain elevated access to areas that otherwise should be restricted. Answer A is incorrect. Input validation is a solution to prevent a buffer overflow by ensuring that input variables are properly formatted.
Answer 3: D. Directory traversal can expose system directories and files. The logs reveal someone making requests to try to access system files from the web server’s base directory. Answer A is incorrect because cross-site scripting is a code injection technique that uses client-side scripts. Answer B is incorrect because refactoring is a driver manipulation technique. Answer C is incorrect. A race condition relates to the way a program executes sequences of code.
Answer 4: B, C, and D. A race condition exploits a small window of time in which one action impacts another. These out-of-sequence actions can result in a system crash, loss of data, unauthorized access, and privilege escalation. Answer A is incorrect and invalid because the proper term is Extensible Markup Language (XML), which is a text-based markup language that is both machine and human readable.
Answer 5: C. With Secure Sockets Layer (SSL) stripping, an attacker strips or removes the encryption between the client and the website. Acting as a proxy or middleman, the attacker establishes a secure connection between himself and the server. Answer A is incorrect because in a replay attack, packets are captured by using sniffers. After the pertinent information is extracted, the packets are placed back on the network. Answer B is incorrect. An integer overflow is specific to whole numbers, known as integers. For example, 12 is an integer, but 12.1 is not. When programs do not carefully account for integer overflows, undesirable behaviors and consequences can occur. Answer D is incorrect. A cross-site request forgery (CSRF) causes end users to execute an unwanted action on sites they are already logged in to. The attacker prepares a specially crafted URL that is client-side-initiated from the web browser.


Code Snippets
Many titles include programming code or configuration examples.