Objective 1.7 Given a scenario, implement controls to mitigate attacks and software vulnerabilities
Both software and hardware have many inherent vulnerabilities that open them up to a multitude of attack vectors. In this module, we’re going to discuss different software vulnerabilities and the corresponding attacks that exploit those vulnerabilities. We’re also going to talk about the different controls that can be implemented to mitigate these attacks.
The vulnerabilities we discuss include improper error handling, dereferencing, insecure objects, race conditions, authentication issues, exposure of sensitive data, and several other vulnerabilities inherent to software. We also discuss the various attacks that could take advantage of these vulnerabilities, including XML attacks, SQL injection, various overflow attacks, remote code execution, privilege escalation, man-in-the-middle attacks, session hijacking, cross-site scripting, and many others.
By the end of this module, you should be able to identify popular and commonly seen vulnerabilities as well as the different attack vectors that can take advantage of these vulnerabilities. Vulnerabilities In Objective 1.3, we stated that a vulnerability could be a weakness in a system, but it also could be the absence or ineffectiveness of a security control.
An example of a system weakness could be software that was not developed under secure programming conditions and contains flaws that might allow an attacker to gain access to data they should not be able to access.
A control weakness example might be the absence of encryption over a network or using a weak encryption algorithm that can be easily broken by an attacker. Either of these conditions constitutes a vulnerability. Remember also that vulnerabilities are taken advantage of, or exploited, by threat events, which are in turn caused by threat actors. Vulnerabilities exist on assets or even in an organization through its management programs. No matter where the vulnerabilities reside, cybersecurity analysts must actively work every day to find and eliminate them. The vulnerabilities we discuss in this module are more specific to software or code and serve to give you a primer on modules we will discuss in Domain 2, which is focused on software security.
Keep in mind that we won’t cover every single known vulnerability in software, but we will go over the ones you are likely to see on the exam as well as the ones you are likely to see in the real world.
This CySA+ exam objective closely mirrors the vulnerabilities found in the OWASP Top 10 Application Security Risks. We discuss these vulnerabilities and then the attack scenarios that could take advantage of them, resulting in system compromise. We also discuss the different potential mitigations for each of these attacks. Improper Error Handling No software is built perfectly. Even software that has been stable over a few versions can be prone to errors. Errors involving functionality or performance aside, what is important is how the software handles errors. If coded incorrectly, the software could deal with an error unpredictably, causing the program or even the underlying system to hang or crash. Even worse, if the afflicted program does not properly handle errors, this could give a potential attacker a way to exploit the system, because a serious error condition might leave the system unstable and vulnerable to attack. An attacker could take advantage of improper error handling through input validation issues, buffer overflows, or escaping outside the software’s processing bounds. An additional issue with error handling is that the system will often throw error messages that are at best cryptic, but at worse may give an attacker too much information about the system that they can use to exploit any discovered vulnerabilities in the software. Error messages should give enough information for a user or a technician to solve problems but at the same time should not give away information about the underlying architecture. Critical error information that a programmer or technician should have should be sent to a log file that has restricted access. An attacker trying to exploit a piece of software over the Internet should not be able to gain any information from improper error handling. Dereferencing Dereferencing occurs when a program attempts to access a stored value that doesn’t exist. A null pointer dereference is the most common instance of this vulnerability. The application dereference is the pointer that the application expects to be valid but, in fact, is empty, or null. Most often, the application crashes when it experiences this condition. Several different software flaws can cause a null pointer dereference. These include flaws that we have already discussed, such as complex race conditions, but could also include simple programming errors. Attackers use dereferencing to cause system instability, which may allow them to bypass security mechanisms and gain privileged access to the system, or to access underlying data that they might not otherwise be able to. Most null pointer dereferencing cases occur in common languages, such as C, C++, and Java. Paying particular attention to error and exception handling can allow unexpected null pointer dereference occurrences to be resolved without allowing attackers to take advantage of them. Insecure Object Reference Sometimes applications need to access underlying data and must use different methods of referencing that data. If a malicious person can infer a pattern or mechanism for accessing that underlying data, they can use that to further access data they should not be able to see. For example, suppose a URL accesses a database record using an identifier such as a Social Security number (SSN). An attacker can modify the HTTP request and substitute a different SSN to access a different record out of the database. Another example might be if there is a file or directory reference in that URL that can easily be derived or predicted. While these are rather simplistic examples, they show that programmers should use random values or values that have no meaning to reference internal pieces of data. The solution to this is that programmers should avoid directly exposing internal references by creating what is called an indirect reference map. This map, or table, can translate the arbitrary values used in the request to a reference that has meaning in the underlying internal database or application and then access the correct data. Substituting another value in the request would not do anything for the attacker, as that value would not have any translation in the application’s reference map, so attempting to access a different record or file location using this method would be ineffective. Exam tip: Insecure object references are most often seen in the referencing URL in a web application. Race Condition The sheer volume of threads and processes that occur in a single second of processing in a modern computer system is staggering. The effort that goes into managing all those threads and processes is equally as staggering; however, because of this complexity, sometimes conditions known as race conditions can occur. A race condition is one of many issues that fall under the category of timing or sequencing issues in the system. A race condition is a software flaw that happens when different threads or processes need to access an object or resource that affects other threads or processes. If one thread, for example, relies on a value produced by calculation from another thread, and that value is in the process of being computed, then the first thread cannot use or access that value until the second thread has computed it. If the second thread or process does not produce that value or produces it out of sequence, then it creates a condition where the first thread cannot complete its task. Essentially you have a condition where the sequence of calculations or events is disrupted and out of order. Race conditions can be difficult to predict and fix and are dependent on race windows—a period when concurrent threads or processes compete to alter the same object at the same time. The goal in avoiding race conditions is to identify the race windows where they exist and to design systems so they are not attempting to concurrently access an object. This is known as mutual exclusion. Yet another timing issue is created between the time a program checks for a value and the time it uses that value; during this time, the value could change if manipulated by a malicious process between those two events. This is also known as a time of check/time of use (TOC/TOU) attack. Using this attack, a malicious person could substitute values, such as tokens or session IDs, and essentially hijack processes or threads. Secure coding standards, as well as careful attention to thread and process timing, can help avoid these vulnerable conditions. Exam tip: Remember that race conditions are a vulnerability in the timing or sequence of application threads and processes, which may result in a timing attack against an application. Broken Authentication Broken authentication refers to a myriad of attacks on weak authentication systems. Most authentication attacks are targeted against username/password authentication methods, as well as ineffective session management. During most of these attacks, attackers try one or more of several methods to gain access to credentials and take advantage of weak authentication mechanisms. This could include a lack of limiting failed login attempts, account lockouts not implemented, and easy-to-guess passwords. Other attacks can be slightly more complex and involve taking advantage of improperly validated session IDs. This is when a user session or authentication token is not properly validated during a logout from the session or a period of inactivity during the session. In many cases, an attacker can take advantage of these vulnerabilities and interrupt or hijack an existing session. Exam tip: Broken authentication vulnerabilities result in attacks on an application’s authentication mechanism, including weak password requirements, no limit on failed login attempts, failure to implement account lockouts, and vulnerabilities associated with the way that authentication credentials are passed to the application and validated. Sensitive Data Exposure Software applications and their underlying architectures, including their APIs, do not always protect critical data such as passwords, session IDs, and so on. This allows attackers to access sensitive data processed by the applications. This may include healthcare data, personal data, and proprietary or financial data. Exposure could result from any number of conditions, including lack of input validation, overly permissive access to underlying data, unpatched vulnerabilities, lack of encryption, weak authentication, and so on. Examples of how attackers could take advantage of these conditions include stealing credential information, initiating man-in-the-middle-attacks, and performing injection attacks. Insecure Components Software is built on so many different components in a complex architecture. These components include cryptographic modules, libraries, APIs, runtime modules, and objects. Any one of these can have vulnerabilities that can be taken advantage of through a variety of attacks. In addition to having inherent vulnerabilities, such as lack of input validation, memory mismanagement, and logic issues, these components can also have issues with authentication and authorization, such as faulty permissions or lack of authentication mechanisms. Components can also suffer from inefficient resource allocation and access, which may cause issues with memory, hard disk space, and CPU processing time. Any of these vulnerabilities can allow an attacker to interrupt system processing and potentially hijack a piece of software functionality, exposing its underlying data. Insufficient Logging and Monitoring Most software applications have some logging facility, either producing their own log files or sending events to the operating system’s log facility, such as Windows Event Viewer or syslog. Some of the better applications allow you to pick and choose which events and to what level of detail the application can log. However, this doesn’t always mean that individual cybersecurity analysts take advantage of those logging facilities, have them set properly, or even pay attention to the logs when they are produced. Given this deficiency, a serious and often subtle attack on a software application could go unnoticed by a security administrator. Therefore, it is incumbent upon all cybersecurity administrators to ensure that they are not only monitoring the application for functional and performance issues but also auditing for security issues as well. When combined with operating system and other security logs, adding application logs to the mix can construct a clear picture of a series of events for security administrators when they’re trying to determine the origin, cause, scope, and eventual resolution of an attack. It’s also, of course, helpful to send application logs to a security information and event management (SIEM) system for aggregation and more detailed analysis. Weak or Default Configurations Right of the box, most applications, and indeed some operating systems, are not secure. Their default configuration is typically set to allow a user of the least technical ability to install and configure the software application. There may be default settings that are not secure, such as vendor default passwords or no encryption. While there are security hardening guides available for many of these applications, security administrators don’t always take the time to go through the steps to secure the application itself, and many times these default settings are left in place, just waiting for an attacker to take advantage of them. Cybersecurity analysts should use industry best practices when securely configuring an application after it has been installed. This includes tightening down security settings, implementing encryption wherever possible, changing default vendor passwords, placing users in restricted groups, and assigning those groups limited permissions to only perform the actions they need to do their jobs. Use of Insecure Functions Insecure functions are those that can have unexpected results when used in programs and be taken advantage of by attackers. Most of these insecure functions result in buffer overflow conditions, where memory is corrupted and overwritten. This can cause a system to become unstable and crash, or even allow an attacker to arbitrarily execute code of their choosing and gain privileged access to the core of the application or even the underlying operating systems. Many examples of insecure functions are found in the C/C++ programming language, but most programming languages have examples of insecure functions that should be avoided if at all possible, or at minimum use function parsers to determine when an attempt is made to exploit them. One popular function, strcpy(), can be used to copy a large number of characters into a smaller memory area, which can result in unstable conditions and allow an attacker to overwrite buffers. The strcpy() function can copy a source string (src) of characters to a destination (dest) string. If the memory buffer size of the destination string is sufficient, then a terminating null character is the result. Note that this function does not specify the required size of the destination buffer. Therefore, if the destination buffer area is less than the source string length, it will overwrite the destination buffer and potentially corrupt other memory areas, with no terminating null character to discern the input from existing memory contents. Similar to this is the strncpy() function. Note: Sometimes it is difficult to distinguish the various vulnerabilities that may result in different attacks; often the attacker will take advantage of several vulnerabilities concurrently to stage a comprehensive attack against an application. Attack Types As mentioned earlier, vulnerabilities are exploited by threats. A threat event can manifest itself as an attack upon the system. The method that is used for the attack is called the attack vector. This is sometimes used interchangeably with the term threat vector, but they are not the same thing, as a threat vector indicates just one potential avenue for an attack that a threat event may use, versus the actual attack. The threat event can make use of any one or combination of different threat vectors, but only the ones used are called attack vectors. The attack types or vectors that we will discuss in this module specifically target software vulnerabilities, which we discussed earlier as well. In this section, we talk about the type of attack, the vulnerability it can target, and potential mitigations that may lessen the impact of an attack or stop it altogether. While we won’t cover every potential attack from which a software vulnerability could suffer, we will discuss the more commonly seen attacks as well as those you must know as part of the learning objectives for the CySA+ exam. Injection Attacks The injection attack is one of the most common forms of attack seen in the modern Internet era. Injection attacks occur because programmers don’t adequately validate user input, typically from web forms or web-based applications. An injection attack is when a malicious user inputs something that the web application cannot properly parse or validate. Typically, the user will enter code as their input into a common field such as a name field. The web application doesn’t know how to interpret this input, so it may respond in one of several ways. It may return an error, it may return data that the user does not have access to, or it may result in the user getting privileged access to the underlying application or even the operating system. Injection attacks can be used with Structured Query Language (SQL), operating system (OS) commands, Extensible Markup Language (XML), the Lightweight Directory Access Protocol (LDAP), and other common methods.
Examples of attacks also include directory transversal, cross-site scripting (XSS), and cross-site request forgery (CSRF). In the next few sections, we discuss these particular injection attacks and how they work. Exam tip: Remember that injection attacks take advantage of a lack of input validation, making it possible to enter or inject code and other malicious input into an application. Extensible Markup Language (XML) Attack Extensible Markup Language (XML) is a programming language, referred to as a metalanguage, that allows users to create their own markup languages. XML is used to format and display information from documents to databases on the Web and can be used to exchange data between different platforms. It can be used to assist in querying and presenting data from database-driven website applications. An XML injection attack is one in which the attacker manipulates XML application or service logic. This involves injecting XML content or structures into a web application to bypass the program logic of the application. Structured Query Language (SQL) Injection Structured Query Language (SQL) is a language, usually seen in the form of SQL statements, that is used to access, query, and update databases. Typically, SQL is used for relational databases. Many web applications today are multitiered applications; that is to say, their programming logic may reside on one server, the user interface or web page on another server, and possibly even a back-end database on yet another server. In this type of setup, a user may require information from the back-end database, but for security reasons is not allowed to access the database directly. The web interface typically provides forms and fields that allow a user to interact with a limited set of data from the database. Programmers don’t always do a good job of validating input for these forms and fields, and as a result, ordinary users, and sometimes even malicious entities, can input anything from pure garbage to specially crafted data into these forms. In the case of the latter, an attacker could formulate SQL statements that can, if they are not validated, access the underlying database and return data that the user should not be able to see—or worse yet, update the underlying database with data of the attacker’s choosing. This entire attack, based on invalid input, is known as SQL injection.
To execute an SQL injection attack, an attacker must do the following: - Input a few test values to see if the database is accessible and can be manipulated through injection attacks. - Use different SQL inputs that may generate error messages to enumerate and map out the database. - Input a specially crafted SQL statement to get the desired results.
As an example of an SQL injection attack, let’s say a user accesses a web application that has an input form. This input form has a login field to access the web application. The user must input their username and password. The web application passes this information on to access a database. In this scenario, the attacker intends to set up an injection attack using the following SQL statement: For this statement, assume that UsersTable is the table in the database that stores usernames and passwords used to access the database, <user_name_input_field> is the form field where a user would input their authorized username, and <password_input_field> is a form field where a user would input their password. These last two values would normally be found in the UsersTable of the database for an authorized user. However, a normal user would not input this SQL statement; they would simply enter their information in the appropriate fields. An attacker could enter this entire SQL statement in one of the fields, using the following information: Note the use of the’ character before the password. This actually tells the field that the remainder of the statement is a comment and can safely be ignored. Essentially, this makes the entire statement look like this to the database: This has the effect of confusing the web application if input validation has not been properly programmed and will cause the application to potentially allow access to the database as an administrator. Note that this is a simplistic example, and depending on how the web application has been programmed and the type of underlying database that supports the application, variations in this statement may be necessary. The key point here is that if user input validation is not conducted by the web application, a carefully crafted SQL statement could result in getting administrative access to the database. Also, other statements could be constructed that would return a list of usernames and valid passwords, or even complete records on individuals. As with all other types of injection attacks, simply validating user input could help prevent these attacks. Exam tip: Attacks on the back-end database of applications are usually conducted via an SQL injection attack. Cross-Site Scripting (XSS) Attacks Cross-site scripting (XSS) attacks cause a user’s browser to execute malicious code stored on a website the browser trusts. The attack primarily targets sensitive information, such as user passwords or session information that can be used to impersonate the user. In a persistent XSS attack, a user visits the site and unknowingly executes malicious code hidden there, typically through content that is posted to the site (for example, through user comments, scripts, or files) by a malicious person. There are also a couple of other different variations of an XSS attack; in addition to persistent attacks, there are reflected and Document Object Model (DOM) attacks. In a reflected (non-persistent) attack, the malicious attacker takes advantage of a server software flaw. Typically, the attacker will craft a special link with the hope that the link will be clicked by unsuspecting users. If they click the link, the browser goes to the site and reflects the attack back to the hapless user. Again, since this type of attack targets sensitive user information and session details, this information can be used to intercept user passwords, session information that could be used for impersonation attacks, and so on. In the reflected attack, a malicious entity could send links to this compromised site through e-mail, text messages, or even documents. Document Object Model (DOM) is a standard dictating how client browsers interact with HTML presented from the server. In the DOM version of the XSS attack, an attacker injects malicious script into the client-side HTML, which the browser parses. If for some reason the web app does not practice input validation, an attacker could modify code between the browser and the application to set up an XSS attack. Remote Code Execution Remote code execution typically isn’t a mode of attack but rather what the attacker is after in terms of a goal. Injection attacks, as well as overflow attacks, can give the attacker the ability to execute arbitrary code of their choosing (meaning scripts or whatever code they choose to input into a web form) remotely from their connection. This arbitrary code could be malicious in nature and used to carry out a denial-of-service attack on the web server, or it could be more sinister and be used to laterally move across a network or elevate privilege levels on different hosts. The key point here is that the code is whatever the attacker chooses if they can achieve this goal. Remote code execution comes from vulnerabilities that are a result of sloppy programming, including lack of input validation and bounds checking, and causes the application to not be able to distinguish between code that should be executed and data that is input. Directory Traversal Directory traversal—also known as directory climbing, “dot-dot-slash” attacks, and path traversal—is the ability of an attacker to access folders and directories outside of the web application’s web root folder. The web root folder is typically used by the application to service web requests. Users should not be able to read the contents of this directory through a directory listing; however, they must be able to execute certain code in it to get the services from the web application. A directory traversal attack allows an attacker to navigate outside of that directory system into other directories, including potentially sensitive directories such as the operating system file directories and other directories that contain sensitive data. Exam tip: Directory traversal attacks simply involve the ability to view folders and files outside of an application’s root directory and may include the ability to view operating system directories as well as other directories that contain sensitive data. Authentication Attacks Authentication attacks are a class of attack that attempts to authenticate an attacker as a valid user. The attacker’s goal is to enter into a communications session or access resources as the targeted user. Authentication attacks use a variety of methods, including credential stealing, password cracking, password spraying, credential stuffing, impersonation, and man-the-middle and session hijacking attacks. These attack methods are discussed in the following sections. Password Spraying Password spraying is a simplistic attack; traditional brute force attacks attempt to break into a single account by repeatedly trying many variations of the password in a short period. In a password spraying attack, however, the attacker uses one or only a few passwords across many different accounts in an organization. The theory is that some commonly used passwords may be valid for an account somewhere in the system, even if it’s not the user account the attacker is interested in brute forcing. Most often, the attacker will use easily guessed passwords that most organizations warn their users against using. They will also use social engineering tactics to profile the organization and its users to derive a shortlist of potential passwords. Password spraying can also be attempted against a single user, but across many different accounts, such as e-mail, banking, and other services. Password spraying can be prevented if the organization or individual uses multifactor authentication instead of simple username/password combinations. If passwords must be used as authentication, then the organization should enforce the use of strong passwords, with large keyspace, complexity, and length requirements. Passwords should also expire regularly, and a minimum length of time restriction for password changes should be required. Credential Stuffing Credential stuffing is an attack technique that allows the attacker to make use of previous data breaches. Instead of going through all of the trouble to obtain usernames and passwords through brute force or stealing password hashes, an attacker will use usernames and passwords obtained through a previous data breach. For example, an attacker may purchase a list of usernames and passwords from the breach of a major e-mail provider. The attacker would then target a user or organization and use those same usernames and passwords to attempt to compromise additional accounts. The defense against credential stuffing is to ensure that, when a breach is discovered, users immediately change their passwords with the breached organization or service, as well as ensure that the same passwords are not used for other personal or organizational accounts. To see if your users’ passwords show up in popular hacking databases as having been compromised, you can check online databases such as “Have I Been Pwned” (https://haveibeenpwned.com). An even more effective defense against credential stuffing is to use multifactor authentication, as well as additional authentication methods such as tokens or one-time passwords. Exam tip: Understand the difference between password spraying and credential stuffing. Remember that password spraying simply involves using a few passwords to attempt to compromise many user accounts across an organization. Credential stuffing is the use of usernames and passwords already obtained from a previous data breach in another organization to see if the same usernames and passwords are valid in the target organization. Impersonation In an impersonation attack, the attacker will attempt to steal credentials or forge them to impersonate a person or other entity, including a trusted server. Impersonation can be accomplished in a variety of means, including man-in-the-middle attacks and session hijacking (both discussed in the next two sections). Impersonation can even be used to a fool a client into thinking the attacker is a trusted Certificate Authority (CA). Man-in-the-Middle Attack A man-in-the-middle (MITM) attack is characterized by an attacker attempting to impersonate multiple entities in the communications session. The attacker may try to impersonate two individuals by intercepting and interrupting the communications session, or even impersonate a client and server. In this manner, the attacker acts as a proxy and inserts their own host in the middle of the conversation between the two parties. Both parties will believe that the attacker is the other party, enabling the attacker to send and receive all information to and from both parties at their discretion, modifying it as they see fit. Within an unencrypted connection, a man-in-the-middle attack is quite simple, but even with encrypted sessions, the attacker could potentially interrupt a secure session if they have compromised the client or server certificate or otherwise broken the SSL/TLS connection and inserted themselves in the middle. This often happens in the case of HTTPS connections, where the client browser establishes a secure connection with the attacker instead of the server. The attacker then establishes a secure connection with the target server. Sometimes either the client or server may get an error message about the validity of the other party’s certificate, but most people ignore those error messages and click right through them, allowing the communications session to happen. It should be noted that many organizations have instituted HTTPS or SSL proxying on their outbound connections to prevent users from using encryption to exfiltrate data or otherwise engage in activities that are against company policy. While the legality or ethics of this practice are questionable, this is an example of a sanctioned man-in-the-middle attack. Session Hijacking Session hijacking is a type of attack used to take over a communications session or conduct a man-in-the-middle attack. In a session hijacking attack, the attacker can intercept and use valid communications session information. This includes authentication information, such as username and passwords, cookies, TCP sequence numbers and timestamps, and so on. A replay attack is one method of session hijacking; this may take advantage of stateless HTTP traffic, for example, and communications sessions that use multiple TCP connections to maintain state information. Session hijacking can be prevented through a variety of means—strong authentication, including multifactor authentication versus the use of usernames and passwords, strong session encryption, TCP sequence unpredictability, and other measures. Note: Session hijacking and man-the-middle attacks are similar but can use different means and have different goals. A man-in-the-middle attack is designed to break into a communications session and authenticate as both parties of the session to each other. A session hijacking attack is also designed to break into a user session but typically involves only masquerading as one of the parties involved. Instead of breaking into the middle of the conversation and assuming both roles of the endpoints of the communication, it assumes only one of the endpoints of the communications session. Overflow Attacks Overflow attacks all have one simple goal in common: writing more data to a memory buffer than is allocated for that input. These types of attacks can take several forms, including buffer, integer, and heap overflows. Most overflow attacks, if successful, can result in the ability of the attacker to cause system instability or gain privileged access. Overflow attacks occur because programmers don’t include bounds checking in their program logic. This allows invalid input to escape the bounds set by the program allocated for the input. Famous examples of buffer overflow attacks include the very first worm, the Morris worm, which was released in 1988, and more recent malware such as Code Red and Slammer. We discuss the major types of overflow attacks in the following sections. Buffer A buffer overflow attack is probably the most common type of attack that most cybersecurity analysts are familiar with. This type of attack can be carried out using a wide range of methods, but the central goal is to overflow the buffer size of the memory space allocated to the input. The goal is to overflow that memory space and overwrite other memory locations. Again, this can cause system instability or allow the attacker to get into restricted areas of the application or operating system. Buffer overflows are caused by programmers being inattentive to bounds checking as well as by inherent weaknesses in some programming languages such as C. Many different functions in C permit overflows because they were originally designed with performance and memory space in mind instead of security. Examples of some of these unsafe functions include the strcpy() function, mentioned earlier in the module, and the gets() function. Integer Integer attacks are based on how numbers are stored in variables and memory locations. Normally, software applications store numbers based on a defined size. Integers are stored in 8-, 16-, 32-, and 64-bit locations and either as signed or unsigned numbers (absolute values or negative/positive, respectively). For example, a 32-bit integer unsigned number is a number whose value is in the range of 0 to 4,294,967,295. A 32-bit signed integer can be in the range of –2,147,483,648 to +2,147,483,647. Integer overflow attacks take advantage of a numerical value that is larger than the space assigned for it. An attacker can create a mathematical operation and inject it through invalid input into a field that expects a number of a specific range. When the number exceeds that range, it can overflow the memory location specified for the range and then result in different responses, including system instability, error messages, privileged access, or the ability to run arbitrary code at the attacker’s discretion. Like other overflow attacks, integer overflows can be mitigated using secure coding methods, sometimes specific to the particular programming language used. Exception handling is one good method; this means that programmers build in exception handling code anticipating an integer overflow, which can deal with the out-of-range numerical values. The application can then display a customized error message while keeping the system stable and secure. Another sound method is input validation, where mathematical operations resulting in these large numbers are not allowed as input. Heap Heap-based attacks are closely related to buffer overflow attacks. System memory is broken into two parts: the stack, which is a data structure that allows data in on a last-in, first-out basis, and the heap, which is unstructured and used on a space-available basis. In a stack-based buffer overflow attack, the attacker attempts to overwrite key areas of the stack so that the attacker’s arbitrary code can be executed instead of legitimate application code. Conversely, in a heap-based attack, the attacker attempts to exhaust the memory dynamically available for the application in the heap. Normally, a heap-based attack is more difficult to execute since data in the heap can’t only be overwritten, it must also be corrupted. Exam tip: All overflow attacks target memory usage in an application, to overwrite contents of adjacent memory locations in the hopes of creating an unstable condition that may result in the ability to execute arbitrary code or gain elevated privileges in an application or operating system. Privilege Escalation Privilege escalation is not an attack, per se—it’s more the goal of an attack. Many of the attacks described in this module can result in privilege escalation. The goal of a privilege escalation attack is to gain the additional privileges that a higher-level user, such as an administrator, may have. This is called vertical privilege escalation. An attacker may, if they cannot successfully gain higher-level privileges, seek to get privileges of other users at the same level. This is called horizontal privilege escalation. An attacker may use horizontal privilege escalation if they don’t necessarily desire the privileges of an administrator but need access to areas that an equivalent user may already have access to, such as sensitive files and databases. Rootkits A rootkit is a highly specialized form of malware that can be extremely difficult to both detect and eradicate. Rootkits don’t typically take advantage of applications; they directly target operating system core files. This could include restricted binaries, device drivers, dynamic link libraries, kernel modules, and so on. These core files typically operate and run on a highly privileged level, either as an administrator or as the operating system itself. Rootkits can be installed through infected boot media or other more sophisticated means. Unfortunately, because rootkits often replace sensitive core operating system files, they may easily fool antimalware software, making them difficult to detect. Evidence of rootkits can span a variety of indicators, including system instability, strange or unusual operations, performance issues, unauthorized access to files or data by processes that don’t normally have that access, unusual network traffic, and so on. Rootkits are often only detected by booting to known-good clean media with specialized antimalware software that is designed to test system file integrity and notify the user of system files that don’t conform to verification checks. Rootkits are also extremely difficult to eradicate. More often than not, the entire operating system has to be wiped and reinstalled, running the risk of losing user data on the system. Caution: Rootkits are extremely dangerous to an operating system; they are difficult to detect and eradicate. Because the only sure way to eliminate a rootkit is a complete rebuild of the system, you must have known-good backups so you can restore data after a rebuild. REVIEW Objective 1.7: Given a scenario, implement controls to mitigate attacks and software vulnerabilities In this module, we discussed various software vulnerabilities and the attacks that can take advantage of those vulnerabilities. Vulnerabilities include those that can be corrected through secure programming techniques and involve flaws in the application. These include improper error handling, dereferencing, insecure object reference, and various timing attacks, including race conditions. We also discussed other vulnerabilities such as broken authentication, exposing sensitive data, and using insecure software components such as APIs. You also learned that insufficient logging and security monitoring are issues, as are using default software configurations. Using insecure functions that allow attackers to take advantage of software flaws, such as the strcpy() function, is also something programmers should pay attention to. There are several different types of attacks that take advantage of these vulnerabilities. Three of the major types of attacks are injection attacks, authentication attacks, and overflow attacks. Injection attacks are made possible through a lack of input validation on the part of the program when the application code is written. Injection attacks can use many different methods, including XML attacks, SQL injection, and cross-site scripting. Injection attacks can result in the ability to access restricted areas of the application or even the operating system, as well as the ability to arbitrarily run remote code at the attacker’s discretion and the ability to break outside of the directory structure of the application into more sensitive areas. Authentication attacks include those that target authentication systems and breaking into communications sessions. These types of attacks can be non-technical, such as password spraying and credential stuffing. They can also be manifested as more sophisticated attacks, such as man-the-middle and session hijacking attacks. Usually with these last two types of attacks, impersonating an authorized user is the goal. Overflow attacks take advantage of software flaws associated with the use of memory in an application. Also, overflow attack generally will attempt to break out of reserved memory for a function and overwrite the contents of other memory locations. These types of attacks include buffer, integer, stack, and heap attacks. Finally, we discussed the use of rootkits by an attacker to substitute critical system files for the application or operating system. These types of attacks are extremely difficult to detect and eradicate and may necessitate a complete rebuild of the system to eliminate the rootkit. We also discussed various goals of the attacker, such as the ability to run arbitrary code remotely as part of an attack, as well as the goal of privilege escalation to gain administrative-level rights in the application or host.
Join 4M+ learners. Unlock unlimited quizzes, wrong-answer tracking, flashcards + reminders, study guides, and 1-on-1 challenges.