“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz enables you to assess whether you should read this entire chapter thoroughly or jump to the “Chapter Review Activities” section. If you are in doubt about your answers to these questions or your own assessment of your knowledge of the topics, read the entire chapter. Table 3-1 lists the major headings in this chapter and their corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes and Review Questions.”

1. What type of privilege escalation attack occurs when a user accesses functions or content reserved for other normal users—for example, if one user reads another’s email?

1. Horizontal

2. Vertical

3. Sudo abuse

4. None of these answers are correct.

2. Which vulnerability can lead to stealing of cookies or redirecting users to malicious sites and where the malicious code or script is permanently stored on a vulnerable system?

1. DOM-based XSS

2. Stored XSS

3. Reflected XSS

4. All of these answers are correct.

3. Which type of injection attack occurs when code is run within the address space of another process, forcing it to load another library?

1. DLL injection

2. LDAP injection

3. SQL injection

4. None of these answers are correct.

4. Which condition occurs when a program dereferences a pointer that it expects to be valid but is null, which can cause the application to exit or the system to crash?

1. Address space layout randomization

2. Tunnel-trap

3. Format string

4. Null pointer dereferences

5. Which type of attack occurs when an attacker tries to escape the web root folder and access arbitrary files by using ../../ in an URL?

1. Directory traversal

2. Path traversal

3. Dot-dot-slash

4. All of these answers are correct.

6. What occurs when arithmetic operations attempt to create a numeric value that is too big for the available memory space?

1. Stack overruns

2. Integer overflows

3. Format strings

4. Heap underruns

7. Race conditions are also known as ________ attacks.

1. Heap overflows

2. Time-of-check (TOC) or time-of-use (TOU)

3. Stack overflows

4. Buffer overflows

8. _______________code should be checked thoroughly so that a malicious user can’t find out any additional information about the system.

1. Regression

2. Patched

3. Error exception handling

4. Remote code execution

9. Input validation vulnerabilities can be found by using which of the following techniques?

1. A python debugger

2. Fuzzing

3. Heap flags

4. All of these answers are correct.

10. Which type of attack occurs when an attacker might use a packet sniffer to intercept data and retransmit it later?

1. Overflow

2. DLL injection

3. XSS

4. Replay

11. A web session ID is typically represented in a cookie. Which type of attack occurs when an attacker could steal a valid user’s session ID and reuse it to perform malicious transactions?

1. Session replay

2. Session fuzzing

3. SQL injection

4. All of these answers are correct.

12. __________ attacks leverage the trust that the application has in the targeted user. For example, the attacker could inherit the privileges of the user to perform an undesired action, such as stealing sensitive information, creating users, or downloading malware.

1. XSS

2. SQLi

3. XML injection

4. XSRF

13. Which of the following are general best practices to protect APIs?

1. Secure API services to provide only HTTPS endpoints with a strong version of TLS.

2. Validate parameters in the application and sanitize incoming data from API clients.

3. Explicitly scan for common attack signatures; injection attacks often betray themselves by following common patterns.

4. All of these answers are correct.

14. Which of the following is a type of denial-of-service (DoS) attack?

1. C2

2. Botnet

3. Resource exhaustion

4. None of these answers are correct.

15. Which of the following attacks can reduce the performance of a computer, especially in systems with shared memory or limited memory?

1. Heap underrun

2. Format string

3. XSS

4. Memory leak

16. Which of the following is a common way to launch an SSL strip attack?

1. Creating a rogue wireless access point (hotspot)

2. Launching Metasploit

3. Fuzzing an application

4. Leveraging a memory leak

17. Which of the following is a driver manipulation attack where an attacker adds a small library that intercepts API calls?

1. Kernel module attack

2. Request forgery

3. Refactoring

4. Shimming

18. Pass the hash are attacks usually performed in which of the following operating systems?

1. Apple iOS

2. macOS

3. Linux

4. Windows

Foundation Topics

Privilege Escalation

Privilege escalation is the act of exploiting a bug or design flaw in a software or firmware application to gain access to resources that normally would have been protected from an application or user. This results in a user gaining additional privileges, more than were originally intended by the developer of the application—for example, if a regular user gains administrative control, or if a particular user can read another user’s email without authorization.

The original developer does not intend for the attacker to gain higher levels of access but probably doesn’t enforce a need-to-know policy properly and/or hasn’t validated the code of the application appropriately. This technique is used by attackers to gain access to protected areas of operating systems or to applications—for example, if a particular user can read another user’s email without authorization. Buffer overflows are used on Windows computers to elevate privileges as well. To bypass digital rights management (DRM) on games and music, attackers use a method known as jailbreaking, another type of privilege escalation, most commonly found on mobile devices. Malware also attempts to exploit privilege escalation vulnerabilities, if any exist on the system. Privilege escalation can also be attempted on network devices. Generally, the fix for this is simply to update the device and to check on a regular basis if any updates are available. For example, a typical SOHO router has a user account and an administrator account. If a device like this isn’t properly updated, an attacker can take advantage of a bug in the firmware to elevate the privileges of the user account. Couple this with the fact that a person forgot to put a password on the user account (or disable it) and your network could be in for some “fun.” It is also possible on some devices to encrypt the firmware component. The following are a couple different types of privilege escalation:

• Vertical privilege escalation: When a lower-privileged user accesses functions reserved for higher-privileged users—for example, if a standard user can access functions of an administrator. This is also known as privilege elevation and is the most common description. To protect against this situation, you should update the network device firmware. In the case of an operating system, it should again be updated, and use of some type of access control system is also advisable—for example, User Account Control (UAC).

• Horizontal privilege escalation: When a normal user accesses functions or content reserved for other normal users—for example, if one user reads another’s email. This can be done through hacking or by a person walking over to other people’s computers and simply reading their email! Always have your users lock their computer (or log off) when they are not physically at their desk!

There is also privilege de-escalation, when high-privileged but segregated users can downgrade their access level to access normal users’ functions. Sneaky administrators can attempt this to glean confidential information from an organization. It’s a two-way street when it comes to security; you should think three-dimensionally when securing your network!

Cross-Site Scripting (XSS) Attacks

Cross-site scripting (commonly known as XSS) vulnerabilities, which have become some of the most common web application vulnerabilities, are achieved using the following attack types:

• Reflected XSS: Reflected XSS attacks (nonpersistent XSS) occur when malicious code or scripts are injected by a vulnerable web application using any method that yields a response as part of a valid HTTP request. An example of a reflected XSS attack is a user being persuaded to follow a malicious link to a vulnerable server that injects (reflects) the malicious code back to the user’s browser. This causes the browser to execute the code or script. In this case, the vulnerable server is usually a known or trusted site.

• Stored (persistent) XSS: Stored, or persistent, XSS attacks occur when the malicious code or script is permanently stored on a vulnerable or malicious server, using a database. These attacks are typically carried out on websites hosting blog posts (comment forms), web forums, and other permanent storage methods. An example of a stored XSS attack is a user requesting the stored information from the vulnerable or malicious server, which causes the injection of the requested malicious script into the victim’s browser. In this type of attack, the vulnerable server is usually a known or trusted site.

• DOM-based XSS: The Document Object Model (DOM) is a cross-platform and language-independent application programming interface that treats an HTML, XHTML, or XML document as a tree structure. DOM-based attacks are typically reflected XSS attacks that are triggered by sending a link with inputs that are reflected to the web browser. In DOM-based XSS attacks, the payload is never sent to the server. Instead, the payload is only processed by the web client (browser). In a DOM-based XSS attack, the attacker sends a malicious URL to the victim; after the victim clicks on the link, it may load a malicious website or a site that has a vulnerable DOM route handler. After the vulnerable site is rendered by the browser, the payload executes the attack in the user’s context on that site. One of the effects of any type of XSS attack is that the victim typically does not realize that an attack has taken place. DOM-based applications use global variables to manage client-side information. Often developers create unsecured applications that put sensitive information in the DOM (for example, tokens, public profile URLs, private URLs for information access, cross-domain OAuth values, and even user credentials as variables). It is a best practice to avoid storing any sensitive information in the DOM when building web applications.

Successful exploitation of an XSS vulnerability could result in installation or execution of malicious code, account compromise, session cookie hijacking, revelation or modification of local files, or site redirection.

You typically find XSS vulnerabilities in the following:

• Search fields that echo a search string back to the user

• HTTP headers

• Input fields that echo user data

• Error messages that return user-supplied text

• Hidden fields that may include user input data

• Applications (or websites) that display user-supplied data

The following XSS test can be performed from a browser’s address bar:

Click here to view code image

javascript:alert("Omar_s_XSS test");
javascript:alert(document.cookie);

The following XSS test can be performed in a user input field in a web form:

Click here to view code image

<script>alert("XSS Test")</script>

Attackers can use obfuscation techniques in XSS attacks by encoding tags or malicious portions of the script using Unicode so that the link or HTML content is disguised to the end user browsing the site.

Injection Attacks

Attackers can use several types of injection attacks to manipulate and compromise an application. The following are the most prevalent injection attacks:

• Structured Query Language (SQL) injection attacks

• Dynamic link library (DLL) injection attacks

• Lightweight Directory Access Protocol (LDAP) injection attacks

• Extensible Markup Language (XML) injection attacks

Structured Query Language (SQL) Injection Attacks

SQL injection (SQLi) vulnerabilities can be catastrophic because they can allow an attacker to view, insert, delete, or modify records in a database. In an SQL injection attack, the attacker inserts, or injects, partial or complete SQL queries via the web application. The attacker injects SQL commands into input fields in an application or a URL in order to execute predefined SQL commands.

Let’s take a brief look at SQL. As you might know, the following are some of the most common SQL statements (commands):

• SELECT: Used to obtain data from a database

• UPDATE: Used to update data in a database

• DELETE: Used to delete data from a database

• INSERT INTO: Used to insert new data into a database

• CREATE DATABASE: Used to create a new database

• ALTER DATABASE: Used to modify a database

• CREATE TABLE: Used to create a new table

• ALTER TABLE: Used to modify a table

• DROP TABLE: Used to delete a table

• CREATE INDEX: Used to create an index or a search key element

• DROP INDEX: Used to delete an index

Typically, SQL statements are divided into the following categories:

• Data definition language (DDL) statements

• Data manipulation language (DML) statements

• Transaction control statements

• Session control statements

• System control statements

• Embedded SQL statements

Tip

At the W3Schools website, you can find a tool called the Try-SQL Editor that enables you to practice SQL statements in an “online database” (see https://www.w3schools.com/sql/trysql.asp?filename=trysql_select_all). You can use this tool to become familiar with SQL statements and how they may be passed to an application. Another good online resource that explains SQL queries in detail is https://www.geeksforgeeks.org/sql-ddl-dml-tcl-dcl.

Web applications construct SQL statements involving SQL syntax invoked by the application mixed with user-supplied data. The first portion of the SQL statement shown in Figure 3-1 is not shown to the user; typically, the application sends this portion to the database behind the scenes. The second portion of the SQL statement is typically user input in a web form.

If an application does not sanitize user input, an attacker can supply crafted input while trying to make the original SQL statement execute further actions in the database. SQL injections can be done using user-supplied strings or numeric input.

Tip

I have created a learning environment called WebSploit that you can use to practice some of these attacks in a safe environment. It includes several intentionally vulnerable applications running in Docker containers. Instructions on how to set up WebSploit can be found at https://websploit.org.

Figure 3-2 shows a basic SQL injection attack.

In the figure, WebGoat is used to demonstrate the effects of an SQL injection attack. When the string Smith' or '1'='1 is entered in the web form, it causes the application to display all records in the database table to the attacker.

One of the first steps when finding SQL injection vulnerabilities is to understand when the application interacts with a database. This is typically done with web authentication forms, search engines, and interactive sites such as e-commerce sites.

You can make a list of all input fields whose values could be used in crafting a valid SQL query. This includes trying to identify and manipulate hidden fields of POST requests and then testing them separately, plus trying to interfere with the query and to generate an error. As part of penetration testing, you should pay attention to HTTP headers and cookies.

As a penetration tester, you can start by adding a single quote (') or a semicolon (;) to the field or parameter in a web form. The single quote is used in SQL as a string terminator. If the application does not filter it correctly, you might be able to retrieve records or additional information that can help enhance your query or statement.

You can also use comment delimiters (such as -- or /* */), as well as other SQL keywords, including AND and OR operands. Another simple test is to insert a string where a number is expected.

SQL Injection Categories

SQL injection attacks can be divided into the following categories:

• In-band SQL injection: With this type of injection, the attacker obtains the data by using the same channel that is used to inject the SQL code. This is the most basic form of an SQL injection attack, where the data is dumped directly in a web application (or web page).

• Out-of-band SQL injection: With this type of injection, the attacker retrieves data using a different channel. For example, an email, a text, or an instant message could be sent to the attacker with the results of the query; or the attacker might be able to send the compromised data to another system.

• Blind (or inferential) SQL injection: With this type of injection, the attacker does not make the application display or transfer any data; rather, the attacker is able to reconstruct the information by sending specific statements and discerning the behavior of the application and database.

Tip

To perform an SQL injection attack, an attacker must craft a syntactically correct SQL statement (query). The attacker may also take advantage of error messages coming back from the application and might be able to reconstruct the logic of the original query to understand how to execute the attack correctly. If the application hides the error details, the attacker might need to reverse-engineer the logic of the original query.

Essentially, five techniques can be used to exploit SQL injection vulnerabilities:

• Union operator: This technique is typically used when a SQL injection vulnerability allows a SELECT statement to combine two queries into a single result or a set of results.

• Boolean: This technique is used to verify whether certain conditions are true or false.

• Error-based technique: This technique is used to force the database to generate an error in order to enhance and refine an attack (injection).

• Out-of-band technique: This technique is typically used to obtain records from the database by using a different channel. For example, it is possible to make an HTTP connection to send the results to a different web server or a local machine running a web service.

• Time delay: It is possible to use database commands to delay answers. An attacker may use this technique when he or she doesn’t get any output or error messages from the application.

It is possible to combine any of the techniques described here to exploit an SQL injection vulnerability. For example, an attacker may use the union operator and out-of-band techniques.

Dynamic Link Library (DLL) Injection Attacks

In DLL injection, code is run within the address space of another process by forcing it to load a dynamic link library (DLL). Ultimately, this type of attack can influence the behavior of a program that was not originally intended. It can be uncovered through penetration testing.

Binary planting is another term used when the attacker implants a malicious binary to a local or remote file system in order for the application to load and execute such malicious binary. You can access detailed information about this technique at OWASP’s website at https://owasp.org/www-community/attacks/Binary_planting.

Lightweight Directory Access Protocol (LDAP) Injection Attacks

LDAP injection is similar to SQL injection, again using a web form input box to gain access, or by exploiting weak LDAP lookup configurations. The Lightweight Directory Access Protocol is used to maintain a directory of information such as user accounts or other types of objects. The best way to protect against this type of attack (and all code-injection techniques for that matter) is to incorporate strong input validation.

Extensible Markup Language (XML) Injection Attacks

XML injection attacks can compromise the logic of Extensible Markup Language (XML) applications—for example, XML structures that contain the code for users. It can be used to create new users and possibly obtain administrative access. You can test for this type of attack by attempting to insert XML metacharacters such as single and double quotes. It can be prevented by filtering in allowed characters (for example, A–Z only). This is an example of “default deny” where only what you explicitly filter in is permitted; everything else is forbidden.

One thing to remember is that when attackers utilize code-injecting techniques, they are adding their own code to existing code or are inserting their own code into a form. A variant of this is command injection, which doesn’t utilize new code; instead, an attacker executes system-level commands on a vulnerable application or OS. The attacker might enter the command (and other syntax) into an HTML form field or other web-based form to gain access to a web server’s password files.

XML External Entity (XXE) is another type of input validation vulnerability and attack against an application that parses XML input. It occurs when input containing a reference to an XML external entity is handled by a poorly configured XML parser. Successful exploitation could lead to the disclosure of confidential data, server-side request forgery, and denial of service. To obtain additional information about this attack and vulnerability, see https://owasp.org/www-community/attacks/.

Pointer/Object Dereference

Another potential memory-related issue deals with pointer dereferencing—for example, the null pointer dereference. Pointer dereferencing is common in programming; when you want to access data (say, an integer) in memory, dereferencing the pointer would retrieve different data from a different section of memory (perhaps a different integer). Programs that contain a null pointer dereference generate memory fault errors (memory leaks). A null pointer dereference occurs when the program dereferences a pointer that it expects to be valid but is null, which can cause the application to exit or the system to crash. From a programmatical standpoint, the main way to prevent this situation is to use meticulous coding. Programmers can use special memory error analysis tools to enable error detection for a null pointer deference. Once the problem is identified, the programmer can correct the code that may be causing the error(s). But this concept can be used to attack systems over the network by initiating IP address to hostname resolutions—ones that the attacker hopes will fail—causing a return null. What this all means is that the network needs to be protected from attackers attempting this (and many other) programmatic and memory-based attacks via a network connection.

A programmer can make use of address space layout randomization (ASLR) to help prevent the exploitation of buffer overflows, remote code execution, and memory corruption vulnerabilities. It randomly arranges the different address spaces used by a program (or process). This can aid in protecting mobile devices (and other systems) from exploits caused by memory-management problems. While there are exploits to ASLR (such as side-channel attacks) that can bypass it and derandomize how the address space is arranged, many systems employ some version of ASLR.

Directory Traversal

Directory traversal, path traversal, or the ../ (“dot-dot-slash”) attack, is a method of accessing unauthorized parent (or worse, root) directories. It is often used on web servers that have PHP files and are Linux or UNIX-based, but it can also be perpetrated on Microsoft operating systems (in which case it would be .. or the “dot-dot-backslash” attack). It is designed to get access to files such as ones that contain passwords. This access can be prevented by updating the operating system or by checking the code of files for vulnerabilities, otherwise known as fuzzing. For example, a PHP file on a Linux-based web server might have a vulnerable if or include statement, which when attacked properly could give the attacker access to higher directories and the passwd file.

Figure 3-3 shows an example of a directory traversal (path traversal) attack. The attacker is able to retrieve the contents of the /etc/passwd file of a vulnerable web application. You can also practice this attack using the WebSploit environment.

Buffer Overflows

Memory and buffer vulnerabilities are common. Of the several types, perhaps most important is the buffer overflow. A buffer overflow occurs when a process stores data outside the memory that the developer intended. This could cause erratic behavior in the application, especially if the memory already had other data in it. Stacks and heaps are data structures that can be affected by buffer overflows. The stack is a key data structure necessary for the exchange of data between procedures. The heap contains data items whose size can be altered during execution. Value types are stored in a stack, whereas reference types are stored in a heap. An ethical coder will try to keep these running efficiently. An unethical coder wanting to create a program vulnerability could, for example, omit input validation, which could allow a buffer overflow to affect heaps and stacks, which in turn could adversely affect the application or the operating system in question.

Let’s say a programmer allows for 16 bytes in a string variable. This wouldn’t be a problem normally; however, if the programmer failed to verify that no more than 16 bytes could be copied over to the variable, that would create a vulnerability that an attacker could exploit with a buffer overflow attack. The buffer overflow can also be initiated by certain inputs. For example, corrupting the stack with no-operation (no-op, NOP, or NOOP) machine instructions, which when used in large numbers can start a NOP slide, can ultimately lead to the execution of unwanted arbitrary code, or can lead to a denial of service on the affected computer.

All this can be prevented by patching the system or application in question, making sure that the OS uses data execution prevention, and utilizing bounds checking, which is a programmatic method of detecting whether a particular variable is within design bounds before it is allowed to be used. It can also be prevented by using correct code, checking code carefully, and using the right programming language for the job in question (the right tool for the right job, yes?). Without getting too much into the programming side of things, special values called “canaries” are used to protect against buffer overflows.

On a semi-related note, integer overflows occur when arithmetic operations attempt to create a numeric value that is too big for the available memory space. This creates a wrap and can cause resets and undefined behavior in programming languages such as C and C++. The security ramification is that the integer overflow can violate the program’s default behavior and possibly lead to a buffer overflow. This situation can be prevented or avoided by making overflows trigger an exception condition or by using a model for automatically eliminating integer overflow, such as the CERT As-if Infinitely Ranged (AIR) integer model. You can learn more about this model at https://www.sei.cmu.edu/about/divisions/cert/index.cfm.

Then there are memory leaks. A memory leak is a type of resource leak caused when a program does not release memory properly. The lack of freed-up memory can reduce the performance of a computer, especially in systems with shared memory or limited memory. A kernel-level leak can lead to serious system stability issues. The memory leak might happen on its own due to poor programming, or it could be that code resides in the application that is vulnerable and is later exploited by an attacker who sends specific packets to the system over the network. This type of error is more common in languages such as C or C++ that have no automatic garbage collection, but it could happen in any programming language. Several memory debuggers can be used to check for leaks. However, it is recommended that garbage collection libraries be added to C, C++, or other programming language, to check for potential memory leaks.

Race Conditions

Another exploit is the race condition. This exploit is difficult to perform because it takes advantage of the small window of time between when a service is used and its corresponding security control is executed in an application or OS, or when temporary files are created. It can be defined as anomalous behavior due to a dependence on timing of events. Race conditions are also known as time of check (TOC) or time of use (TOU) attacks. Imagine that you are tasked with changing the permissions to a folder or changing the rights in an ACL. If you remove all of the permissions and apply new permissions, then there will be a short period of time when the resource (and system) might be vulnerable. This vulnerability depends on the system used, how it defaults, and how well you have planned your security architecture. That was a basic example, but the race condition is more common within the programming of an application. This exploit can be prevented by proper secure coding of applications and planning of the system and network architecture.

Error Handling

At times, applications will fail. How they fail determines their security. Failure exceptions might show the programming language that was used to build the application, or worse, lead to access holes. Error handling or error exception handling code should be checked thoroughly so that a malicious user can’t find out any additional information about the system. These error handling methods are sometimes referred to technically as pseudocodes. For example, to handle a program exception, properly written pseudocode will basically state (in spoken English): “If a program module crashes, then restart the program module.”

Once found, security vulnerabilities should be thoroughly tested, documented, and understood. Patches should be developed to fix the problem but not cause other issues or application regression.

There are some other concepts to consider. First is obfuscation, which is the complicating of source code to make it more difficult for people to understand. This is done to conceal its purpose in order to prevent tampering and/or reverse engineering. It is an example of security through obscurity. Other examples of security through obscurity include code camouflaging and steganography, both of which might be used to hide the true code being used. Another important concept is code checking, which involves limiting the reuse of code to that which has been approved for use and removing dead code. It’s also vital to incorporate good memory management techniques. Finally, you should be very careful when using third-party libraries and software development kits (SDKs) and test them thoroughly before using them within a live application.

For the Security+ exam, the most important of the SDLC phases are maintenance and testing. In the maintenance phase, which doesn’t end until the software is removed from all computers, an application needs to be updated accordingly, corrected when it fails, and constantly monitored. It’s imperative that you know some of the vulnerabilities and attacks to a system or application, and how to fix them and protect against them. The best way to prevent these attacks is to test and review code.

Improper Input Handling

Programmers have various ways to test their code, including system testing, input validation, and fuzzing. When a combination of these testing techniques is used during development and testing, there is a much higher probability of a secure application as the end result.

System testing is generally broken down into two categories: black-box and white-box. Black-box testing utilizes people who do not know the system. These people (or programs, if automated) test the functionality of the system. Specific knowledge of the system code—and programming knowledge in general—is not required. The tester does not know about the system’s internal structure and is often given limited information about what the application or system is supposed to do. In black-box testing, one of the most common goals is to crash the program (often done using fuzzing tools or “fuzzers”). If a user is able to crash the program by entering improper input, the programmer has probably neglected to thoroughly check the error handling code and/or input validation. White-box testing (also known as transparent testing) is a way of testing the internal workings of the application or system. Testers must have programming knowledge and are given detailed information about the design of the system. They are given login details, production documentation, and source code. System testers might use a combination of fuzzing (covered shortly), data flow testing, and other techniques such as stress testing, penetration testing, and sandboxes.

Stress testing is usually done on real-time operating systems, mission-critical systems, and software, and checks if they have the robustness and availability required by the organization. In a penetration test, the tester mimics what an attacker could do in a vulnerable system.

Compile-Time Errors vs. Runtime Errors

Programmers and developers need to test for potential compile-time errors and runtime errors. Compile time refers to the duration of time during which the statements written in any programming language are checked for errors. Compile-time errors might include syntax errors in the code and type-checking errors. A programmer can check these without actually “running” the program but instead check it in the compile stage when it is converted into machine code.

A runtime error is a program error that occurs while the program is running. The term is often used in contrast to other types of program errors, such as syntax errors and compile-time errors. Runtime errors might include running out of memory, invalid memory address access, invalid parameter value, or buffer overflows/dereferencing a null pointer (to name a few), all of which can be discovered only by running the program as a user. Another potential runtime error can occur if there is an attempt to divide by zero. These types of errors result in a software exception. Software and hardware exceptions need to be handled properly. Consequently, structured exception handling (SEH) is a mechanism used to handle both types of exceptions. It enables the programmer to have complete control over how exceptions are handled and provides support for debugging.

Code issues and errors that occur in either compile time or run time could lead to vulnerabilities in the software. However, it’s the runtime environment that you are more interested in from a security perspective, because that more often is where the attacker will attempt to exploit software and websites.

Input validation is very important for website design and application development. Input validation, or data validation, is a process that ensures the correct usage of data: it checks the data that is inputted by users into web forms and other similar web elements. Data not being validated correctly can lead to various security vulnerabilities, including sensitive data exposure and the possibility of data corruption. You can validate data in many ways, from coded data checks and consistency checks to spelling and grammar checks, and so on. Whatever data is being dealt with, it should be checked to make sure it is being entered correctly and won’t create or take advantage of a security flaw. If validated properly, bad data and malformed data will be rejected. Input validation should be done both on the client side and, more importantly, on the server side. Let’s look at an example next.

If an organization has a web page with a PHP-based contact form, the data entered by the visitor should be checked for errors or maliciously typed input. The following PHP code is contained within a common contact form:

Click here to view code image

else if (!preg_match('/^[A-Za-z0-9.-]+$/', $domain))
 {
 // character not valid in domain part
 $isValid = false;
 }

This example is a part of a larger piece of code that checks the entire email address a user enters into a form field. This particular snippet of code checks to make sure the user is not trying to enter a backslash in the domain name portion of the email address. This character is not allowed in email addresses and could be detrimental if used maliciously. In the first line within the brackets, note that it says A-Za-z0-9.-, which tells the system what characters are allowed. Uppercase and lowercase letters, numbers, periods, and dashes are allowed, but other characters such as backslashes, dollar signs, and so on are not allowed. The form’s supporting PHP files would interpret those other characters as illegitimate data and would not pass them on through the system. The user would receive an error, which is a part of client-side validation. But the more a PHP form is programmed to check for errors, the more it is possible to have additional security holes. Therefore, server-side validation is even more important. Any data that is passed on by the PHP form should be checked at the server as well. In fact, an attacker might not even be using the form in question but instead might be attacking the URL of the web page in some other manner. This type of validation can be checked at the server within the database software or through other means. By the way, the concept of combining client-side and server-side validation also goes for pages that utilize JavaScript.

This is just one basic example, but as mentioned previously, input validation is the key to preventing attacks such as SQL injection and XSS. All form fields should be tested for good input validation code, both on the client side and the server side. By combining the two and checking every access attempt, you develop complete mediation of requests.

Note

Using input validation is one way to prevent sensitive data exposure, which occurs when an application does not adequately protect personally identifiable information (PII). You can also prevent this type of exposure by doing the following: making sure that inputted data is never stored or transmitted in clear text; using strong encryption and securing key generation and storage; using HTTPS for authentication; and using a salt, which is random data used to strengthen hashed passwords.

Replay Attacks

A replay attack is a network attack in which a valid data transmission is maliciously or fraudulently repeated or delayed. It differs from session hijacking in that the original session is simply intercepted and analyzed for later use. In a replay attack, an attacker might use a packet sniffer to intercept data and retransmit it later. In this way, the attacker can impersonate the entity that originally sent the data. For example, if customers were to log in to a banking website with their credentials while an attacker was watching, the attacker could possibly sniff out the packets that include the usernames and passwords and then possibly connect with those credentials later on. Of course, if the bank uses Secure Socket Layer (SSL) or Transport Layer Security (TLS) to secure login sessions, then the attacker would have to decrypt the data as well, which could prove more difficult. An organization can defend against this attack in several ways. The first is to use session tokens that are transmitted to people the first time they attempt to connect and identify them subsequently. They are handed out randomly so that attackers cannot guess at token numbers. The second way is to implement timestamping and synchronization, as in a Kerberos environment. A third way would be to use a timestamped nonce, a random number issued by an authentication protocol that can be used only one time. You can also implement CHAP-based authentication protocols to provide protection against replay attacks.

Session replay attacks occur when an attacker steals a user’s valid session ID and reuses that ID to perform malicious transactions and activities with a web application.

Session hijacking is the exploitation of a computer session in an attempt to gain unauthorized access to data, services, or other resources on a computer. A few types of session hijacks can occur:

• Session theft: This hijack can be accomplished by making use of packet header manipulation or by stealing a cookie from the client computer, which authenticates the client computer to a server. This is done at the application layer, and the cookies involved are often based off their corresponding web applications (such as WWW sessions). This type of attack can be combated by using encryption and long random numbers for the session key and then regeneration of the session after a successful login. The Challenge Handshake Authentication Protocol (CHAP) can also be employed to require clients to periodically reauthenticate. However, session hijacking can also occur at the network layer—for example, TCP/IP hijacking.

• TCP/IP hijacking: This is a common type of session hijacking, due to its popularity among attackers. It occurs when an attacker takes over a TCP session between two computers without the need of a cookie or any other type of host access. Because most communications’ authentication occurs only at the beginning of a standard TCP session, an attacker can attempt to gain access to a client computer anytime after the session begins. One way would be to spoof the client computer’s IP address, then find out the last packet sequence number sent to the server, and then inject data into the session before the client sends another packet of information to the server. Remember the three-way handshake that occurs at the beginning of a session; this is the only authentication that occurs during the session. A synchronization (SYN) packet is sent by the client to the server, then a SYN/ACK packet is sent by the server to the client, and finally, an acknowledgment (ACK) packet is sent by the client to the server. An attacker can jump in anytime after this process and attempt to steal the session by injecting data into the data stream. This is the more difficult part: the attacker might need to perform a DoS attack on the client to stop it from sending any more packets so that the packet sequence number doesn’t increase. In contrast, UDP sessions are easier to hijack because no packet sequence numbers exist. Targets for this type of attack include online games and also DNS queries. To mitigate the risk of TCP/IP hijacking, you should employ encrypted transport protocols such as SSL, IPsec, and SSH.

• Blind hijacking: This type of hijacking occurs when an attacker blindly injects data into a data stream without being able to see whether the injection was successful. The attacker could be attempting to create a new administrator account or gain access to one.

• Clickjacking: This type of hijacking occurs when a user browsing the web is tricked into clicking something different from what the user thought he or she was clicking. It is usually implemented as a concealed link—embedded code or a script on a website that executes when the user clicks that element. For example, a Flash script, when clicked, could cause the user’s webcam to turn on without the user’s consent. The user is often redirected to the website from a malicious source. This type of attack can be prevented by updating the user’s web browser and using third-party add-ons that watch for clickjacking code or scripts. On the server side, web page frames (such as iframes) must be managed carefully. JavaScript-based snippets can be added and content security policies also can be configured to help manage frames.

• On-path attack (previously known as man-in-the-middle [MITM] and man-in-the-browser [MITB] attacks): These attacks intercept all data between a client and a server. It is a type of active interception. If successful, all communications now go through the MITM attacking computer. The attacking computer can at this point modify the data, insert code, and send it to the receiving computer. This type of eavesdropping is successful only when the attacker can properly impersonate each endpoint. Cryptographic protocols such as Secure Socket Layer (SSL) and Transport Layer Security (TLS) address MITM attacks by using a mutually trusted third-party certification authority (CA). These public key infrastructures (PKIs) should use strong mutual authentication such as secret keys and strong passwords.

  On-path attacks also can make use of a Trojan (from a proxy location) that infects a vulnerable web browser and modifies web pages and online transactions, in an attempt to ultimately steal money or data. For example, a user might make an online banking transaction, and the user would see confirmation of the exact transaction, but on the banking side, a different amount might have been actually transferred, with some of it going to a different location altogether. This type of attack can be prevented by updating the web browser, using transaction verification (often third-party), and updating the antimalware on the computer in question.

• Watering hole attack: As discussed in Chapter 1, a watering hole attack is a targeted attack that occurs when an attacker profiles the websites that the intended victim accesses. The attacker then scans those websites for possible vulnerabilities. If the attacker locates a website that can be compromised, the website is then injected with a JavaScript or other similar code injection that is designed to redirect the user when the user returns to that site (also known as a pivot attack). The user is then redirected to a site with some sort of exploit code…and the rest is, well, history. The purpose is to infect computers in the organization’s network, thereby allowing the attacker to gain a foothold in the network for espionage or other reasons. Watering hole attacks are often designed to profile users of specific organizations, and as such, an organization should develop policies to prevent these attacks. This can be done by updating antimalware applications regularly and by using secure virtual browsers that have little connectivity to the rest of the system and the rest of the network. To avoid having a website compromised as part of this attack, you, as administrator, should use proper programming methods and scan the website for malware regularly.

Request Forgeries

Cross-site request forgery (XSRF) is a type of vulnerability in which an attacker lures the targeted user to execute unwanted actions on a web application. Threat-performing XSRF attacks leverage the trust that the application has in the targeted user. For example, the attacker could inherit the privileges of the user to perform an undesired action, such as stealing sensitive information, creating users, or downloading malware.

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. As SSRF attack exploits trust relationships.

Application Programming Interface (API) Attacks

Application programming interfaces (APIs) are used everywhere today. A large number of modern applications use some type of API to allow other systems to interact with the application. Unfortunately, many APIs lack adequate controls and are difficult to monitor. The breadth and complexity of APIs also make it difficult to automate effective security testing. Attackers can launch attacks against APIs to steal, delete, or modify data or to perform a denial-of-service condition.

The following are a few methods or technologies behind modern APIs:

• Simple Object Access Protocol (SOAP): This standards-based web services access protocol was originally developed by Microsoft and has been used by numerous legacy applications for many years. SOAP exclusively uses XML to provide API services. XML-based specifications are governed by XML Schema Definition (XSD) documents. SOAP was originally created to replace older solutions such as the Distributed Component Object Model (DCOM) and Common Object Request Broker Architecture (CORBA). You can find the latest SOAP specifications at https://www.w3.org/TR/soap.

• Representational State Transfer (REST): This API standard is easier to use than SOAP. It uses JSON instead of XML, and it uses standards such as Swagger and the OpenAPI Specification (https://www.openapis.org) for ease of documentation and to encourage adoption.

• GraphQL: GraphQL is a query language for APIs that provides many developer tools. GraphQL is now used for many mobile applications and online dashboards, and many different languages support GraphQL. You can learn more about it at https://graphql.org/code.

SOAP and REST use the HTTP protocol; however, SOAP limits itself to a stricter set of API messaging patterns than REST.

An API often provides a roadmap that describes the underlying implementation of an application. API documentation can provide a great level of detail that can be very valuable to a security professional, as well to attackers. API documentation can include the following:

• Swagger (OpenAPI): Swagger is a modern framework of API documentation and development that is the basis of the OpenAPI Specification (OAS). You can obtain additional information about Swagger at https://swagger.io. The OAS specification is available at https://github.com/OAI/OpenAPI-Specification.

• Web Services Description Language (WSDL) documents: WSDL is an XML-based language that is used to document the functionality of a web service. The WSDL specification can be accessed at https://www.w3.org/TR/wsdl20-primer.

• Web Application Description Language (WADL) documents: WADL is an XML-based language for describing web applications. The WADL specification can be obtained from https://www.w3.org/Submission/wadl.

The following are general best practices and recommendations for securing APIs:

• Secure API services to only provide HTTPS endpoints with a strong version of TLS.

• Validate parameters in the application and sanitize incoming data from API clients.

• Explicitly scan for common attack signatures; injection attacks often betray themselves by following common patterns.

• Use strong authentication and authorization standards.

• Use reputable and standard libraries to create the APIs.

• Segment API implementation and API security into distinct tiers; doing so frees up the API developer to focus completely on the application domain.

• Identify what data should be publicly available and what is sensitive information.

• If possible, have a security expert do the API code verification.

• Make internal API documentation mandatory.

• Avoid discussing company API development (or any other application development) on public forums.

Resource Exhaustion

Resource exhaustion is an attack against availability that is designed to bring the network, or access to a particular TCP/IP host/server, to its knees by flooding it with useless traffic. Resource exhaustion attacks are a form of denial-of-service attacks. They can also leverage software vulnerabilities such as memory leaks and file descriptor leaks.

Today, most DoS attacks are launched via botnets (a collection of compromised systems), whereas in the past tools such as the Ping of Death or Teardrop may have been used.

Memory Leaks

A memory leak is a type of resource leak caused when a program does not release memory properly. The lack of freed-up memory can reduce the performance of a computer, especially in systems with shared memory or limited memory. A kernel-level leak can lead to serious system stability issues. The memory leak might happen on its own due to poor programming, or it could be that code resides in the application that is vulnerable and is later exploited by an attacker who sends specific packets to the system over the network. This type of error is more common in languages such as C or C++ that have no automatic garbage collection, but it could happen in any programming language. Several memory debuggers can be used to check for leaks. However, it is recommended that garbage collection libraries be added to C, C++, or other programming language to check for potential memory leaks.

Secure Socket Layer (SSL) Stripping

Transport Layer Security is the protocol that replaced SSL. However, many people still refer to TLS implementations as “SSL.” TLS versions older than 1.2 and all SSL versions are susceptible to SSL stripping attacks. The latest version of TLS (at the time of writing) is version 1.3.

An SSL stripping attack occurs when an attacker performs a man-in-the-middle attack and can redirect a client to an insecure HTTP connection. The attacker still establishes a secure HTTPS connection between herself or himself and the server, as illustrated in Figure 3-4.

The attacker in Figure 3-4 downgrades the client connection from HTTPS to HTTP and sends it back to the victim’s (User1) browser. The browser is then redirected to the attacker, and all the victim’s data will be transferred in plaintext format. Meanwhile, the web server successfully established a secure connection, but with the attacker’s machine, not the victim’s system.

An attacker can launch an SSL strip attack in many different ways. One of the most common ways is to create a wireless hotspot and lure the victims to connect to it.

Driver Manipulation

It’s important to verify that any drivers installed will be compatible with a system. As a security administrator, you should be aware of the potential to modify drivers through the use of driver shimming (the adding of a small library that intercepts API calls) and driver refactoring (the restructuring of driver code). By default, shims are not supposed to be used to resolve compatibility issues with device drivers, but it’s impossible to foresee the types of malicious code that may present itself in the future. So, you should be careful when updating drivers by making sure that the drivers are signed properly and first testing them on a closed system.

Pass the Hash

All versions of Windows store passwords as hashes in a file called the Security Accounts Manager (SAM) file. The operating system does not know what the actual password is because it stores only a hash of the password. Instead of using a well-known hashing algorithm, Microsoft created its own implementation that has developed over the years.

Microsoft also has a suite of security protocols for authentication, called NT LAN Manager (NTLM). NTLM had two versions: NTLMv1 and NTLMv2. Since Windows 2000, Microsoft has used Kerberos in Windows domains. However, NTLM may still be used when the client is authenticating to a server via IP address or if a client is authenticating to a server in a different Active Directory (AD) forest configured for NTLM trust instead of a transitive interforest trust. In addition, NTLM might also still be used if the client is authenticating to a server that doesn’t belong to a domain or if the Kerberos communication is blocked by a firewall.

So, what is a pass the hash attack? Because password hashes cannot be reversed, instead of trying to figure out what the user’s password is, an attacker can just use a password hash collected from a compromised system and then use the same hash to log in to another client or server system.

Figure 3-5 shows an example of a pass the hash attack.

The Windows operating system and Windows applications ask users to enter their passwords when they log in. The system then converts the passwords into hashes (in most cases using an API called LsaLogonUser). A pass the hash attack goes around this process and just sends the hash to the system to authenticate.

Mimikatz is a tool used by many penetration testers, attackers, and even malware that can be useful for retrieving password hashes from memory; it is a very useful postexploitation tool. You can download the Mimikatz tool from https://github.com/gentilkiwi/mimikatz. Metasploit penetration testing software also includes Mimikatz as a Meterpreter script to facilitate exploitation without the need to upload any files to the disk of the compromised host. You can obtain more information about Mimikatz/Metasploit integration from https://www.offensive-security.com/metasploit-unleashed/mimikatz/.

Chapter Review Activities

Use the features in this section to study and review the topics in this chapter.

Review Key Topics

Review the most important topics in the chapter, noted with the Key Topic icon in the outer margin of the page. Table 3-2 lists a reference of these key topics and the page number on which each is found.

Define Key Terms

Define the following key terms from this chapter, and check your answers in the glossary:

privilege escalation

cross-site scripting

injection attacks

SQL injection (SQLi)

DLL injection

LDAP injection

XML injection

null pointer dereference

address space layout randomization (ASLR)

directory traversal

buffer overflow

integer overflows

memory leak

remote code execution (RCE)

race condition

time of check (TOC) or time of use (TOU)

error handling

input validation

black-box testing

white-box testing

compile-time errors

runtime error

structured exception handling (SEH)

input validation

replay attack

nonce

session replay

session hijacking

on-path attack

watering hole attack

cross-site request forgery (XSRF)

server-side request forgery (SSRF)

application programming interfaces (APIs)

resource exhaustion

memory leak

SSL stripping attack

shimming

refactoring

pass the hash attack

Mimikatz

Review Questions

Answer the following review questions. Check your answers with the answer key in Appendix A.

1. What tool is used by many penetration testers, attackers, and even malware that can be useful for retrieving password hashes from memory?

2. What is the act of restructuring driver code called?

3. What type of attack occurs when the attacker performs an MITM attack and can redirect a client to an insecure HTTP connect?

4. What is a modern framework of API documentation and development that is the basis of the OpenAPI Specification (OAS)?

5. What type of attack occurs when a user browsing the web is tricked into clicking something different than what the user thought he or she was clicking?

6. What type of attack is difficult to exploit because it takes advantage of the small window of time between when a service is used and its corresponding security control is executed in an application, operating system, or when temporary files are created?

7. What feature is supported in most modern operating systems that can help prevent the exploitation of buffer overflows, remote code execution, and memory corruption vulnerabilities?

8. What is a type of input validation vulnerability and attack against an application that parses XML input?