Section 7.7 Application Vulnerabilities

As you study this section, answer the following questions:

• How does an overflow attack work?
• What is a cross-site scripting attack?
• Why would you implement application controls?

In this section, you will learn to:

• Apply security solutions for software assurance

The key terms for this section include:

Key Terms and Definitions

Key Terms and Definitions

Term	Definition
Overflow attack	An attack that occurs when a program is designed only to handle a certain amount of data, but the attacker sends more data to cause the system to crash or behave in unexpected ways.
Cross-site scripting (XSS) attack	An attack that exploits input validation errors on a website to inject malicious code into a trusted website.

This section helps you prepare for the following certification exam objectives:

Exam	Objective
CompTIA CySA+ CS0-003	2.4 Given a scenario, recommend controls to mitigate attacks and software vulnerabilities Cross-site scripting Overflow vulnerabilities Buffer Integer Heap Stack Broken access control Cryptographic failures Insecure design Security misconfiguration End-of-life or outdated components Identification and authentication failures Remote code execution Privilege escalation
TestOut CyberDefense Pro	4.3 Analyze Indicators of Compromise Examine applications for any signs of compromise

7.7.1 Overflow Attacks

Click one of the buttons to take you to that part of the video.

Overflow Attacks 00:00-02:28 Web applications are vulnerable to different types of attacks. The most common attacks we usually see are overflow attacks and cross-site scripting attacks.

In this lesson we'll look at these attacks and how attackers implement them.

Most programs take some sort of input, whether its typed manually by the user or passed through by another program like the web browser.

The program should validate all input to ensure that its legitimate and expected.

Unfortunately, many applications suffer from inadequate error handling or input validation which attackers take advantage of by sending malicious code through the input fields.

A common form of these attacks are overflow attacks. These attacks occur when a program is designed to only handle a certain amount of data, but the attacker sends more data which can cause the system to crash or behave in unexpected ways.

There are three types of overflow attacks, the buffer stack overflow, heap overflow, and integer overflow.

Let's look at how each of these overflow attacks work.

Buffer stack overflow attacks target the stack of a program. To better understand this, lets look at how programs are put together.

When the program is run, its executables are stored in the memory of the system.

At the top of the memory is the kernel. This contains the OS commands and environment variables that the program will use.

At the bottom, is the text which is the actual code of the program. This area of memory cannot be touched or changed.

Above that is the data which contains the program variables.

Above that is the heap. This is where large objects like images and files are stored.

And finally, below the kernel is the stack. This holds the variables for each function. This area between the stack and heap is unallocated memory. Both the stack and heap memory can expand into this area.

Programs are built using functions. These functions work together by calling on each other, passing data to each other, and returning values.

What should happen is if a function is called, it gathers the requested information or variable and stores it in the stack area. The stack also holds the return address. This tells the function where to return to when its done.

This is where the buffer stack overflow exploits.

If the program is designed to hold a fixed amount of data, the attacker can send more data to the stack which can overwrite or change the return address.

Attackers can use the stack overflow attack to crash the system or run their own code to take control of the machine.

Heap Overflow 02:28-03:06 Attackers can also target the heap portion of memory to carry out an overflow attack.

When developing the program, the developer can insert code that tells the program to store items in the heap and then release them when done with it. This can include images or files.

Poor programming of heap memory management can lead to memory leaks.

This is when the program doesn't release the memory being used and keeps adding on. This causes the program to use more and more resources which will eventually lead to system slowdowns and crashes.

Attackers can take advantage of this and target the heap portion of memory to overload it and crash the system.

Integer Overflow 03:06-04:21 The final overflow attack is the integer overflow.

An integer is any whole-valued positive or negative number, or zero. In many programs, allocated memory size is defined using whole-valued numbers.

If the attacker can get the program to perform a calculation that exceeds that defined memory size, this can cause an integer overflow.

The results of these attacks can be unpredictable as they can lead to program corruption or crash the system.

Overflow attacks are one of the most dangerous types of attacks. The main cause for these attacks are errors in programming.

For example, many programs are written in C or C++. This language includes a command called strcpy which many programmers would utilize.

The problem with this command is it doesn't check to see if the data being copied would overwrite the boundaries of a buffer.

Attackers exploit this to carry out their overflow attacks.

The best way to defend against these attacks is to use proper programming practices and avoid these functions that are known to be vulnerable.

Thankfully, many modern languages such as Python and Java have built-in controls that will prevent overflow attacks.

As a security analysts, you must be aware of the vulnerabilities that may exist in older programs and do what you can to mitigate these attacks.

Cross-Site Scripting Attacks 04:21-04:47 Cross-site scripting, or XSS, attacks are another common and dangerous attack.

When a user visits a web page, the assumption is that the site is trusted and safe.

If an attacker discovers an input validation error in the site, they can exploit this to carry out a cross-site scripting attack.

There are three types of XSS attacks – reflected, persistent, and document object model, or DOM.

Let's take a look at these attacks.

Reflected XSS Attack 04:47-05:31 A reflected XSS attack involves a client clicking on a link to visit a trusted site.

The attacker first finds a site that has an input validation vulnerability.

The attacker then crafts a URL link that contains malicious script. The attacker can then post this link on a forum, social media, send it through email, or some other method with the goal of getting someone to click the link.

When the user clicks the link, the malicious script is run on the site and reflected back to the user's browser.

Reflected XSS attacks are non-persistent. This means that the link must be clicked every time the attack is carried out, so the attacker is playing a numbers game to get as many people as possible to click the link.

Persistent XSS Attack 05:31-05:49 A stored cross-site scripting attack is like the reflected, except its persistent.

These attacks are less common because it requires the attacker to inject their malicious code into the web server itself.

When any user visits the site, the malicious script is executed on the user's browser automatically.

DOM XSS Attack 05:49-06:44 Finally, we have the document object model, or DOM, XSS attack.

Document object model is basically a structure to handle HTML and XML documents. It works across different platforms and allows for different scripting languages to be used to run on web applications.

A DOM XSS attack is carried when a web application writes data to the DOM without proper sanitization. The attacker can manipulate this data to include their malicious script which will then run whenever a user accesses the web page. These attacks are very rare and the most difficult to pull off.

To protect against these attacks, you should ensure that all data input is sanitized before being allowed to run on the server. This is the main reason for these vulnerabilities.

Since reflected XSS attacks require the user to click on a link, educating users to be vigilant and not clicking on links is the best defense against these attacks.

Summary 06:44-07:18 That's it for this lesson.

In this lesson we looked at the two most dangerous attacks, overflow attacks and cross-site scripting attacks.

We first looked at the types of overflow attacks which include the stack buffer overflow, heap overflow, and integer overflow.

We then looked at cross-site scripting attacks which exploit input validation errors. The different types of XSS include reflected, persistent, and DOM cross-site scripting attacks. We also discussed best practices to help mitigate these types of attacks.

7.7.2 Overflow Attacks Facts

Most programs take some sort of input, whether typed manually by the user or passed through by another program like the web browser. The program should validate all input to ensure it is legitimate and expected. Unfortunately, many applications suffer from inadequate error handling or input validation, which attackers can take advantage of by sending malicious code through the input fields.

This lesson covers the following topics:

• Overflow attacks
• Cross-site scripting (XSS) attacks

Overflow Attacks

Overflow attacks are one of the most dangerous types of attacks. They occur when a program is designed to handle only a certain amount of data, but the attacker sends more data to cause the system to crash or behave in unexpected ways.

Programming errors are the main cause of these vulnerabilities. An example of this is found when programmers use the strcpy function, a command included in the C and C++ languages. This command allows a string to be copied in the code but does not check to see if the data being copied would overwrite the boundaries of a buffer. Attackers could exploit programs using this command to carry out overflow attacks.

To understand these attacks, an understanding of how programs operate is necessary. When a program is run, its executables are stored in the memory of the system. The typical memory structure is composed of six levels:

1. Kernel - this top level contains the OS commands and environment variables programs use.
2. Stack - this is where the variables, or data, that functions generate are stored. This can expand into the unallocated memory area.
3. Unallocated memory - this area of memory is available for the stack and heap to expand into as needed.
4. Heap - large objects such as images and files are stored here. This can expand into the unallocated memory area.
5. Data - program variables are stored here.
6. Text - this is the actual code of the program. This area is protected and cannot be written to at all.

Programs are built using functions. These functions work together by calling on each other, passing data to each other, and returning values. When a function is called, the following should take place:

1. The function performs its assigned task and gathers the requested information, also known as the variable.
2. The variable is stored in the stack. The stack also stores the return address, which tells the function where to return when done.
3. The function returns to the return address.

The following table describes the four types of overflow attacks:

Overflow Attack Type	Description
Buffer stack overflow	A buffer overflow is a software vulnerability where a program attempts to write more data to a buffer (a temporary storage area in memory) than it can hold, causing the excess data to overflow into adjacent memory space. This can cause the program to crash or behave unpredictably. In some cases, it can be exploited by an attacker to execute arbitrary code or take control of the affected system. Heartbleed is a security vulnerability discovered in the widely used OpenSSL cryptographic software library. The bug allows an attacker to read sensitive information from the memory of a vulnerable web server, such as private keys, usernames, passwords, and other confidential data. The vulnerability existed in the OpenSSL implementation of the Transport Layer Security (TLS) protocol's heartbeat extension. In vulnerable versions of OpenSSL, an attacker can send a malformed heartbeat request that causes the server to leak up to 64 kilobytes of memory data in response, potentially revealing sensitive information. The Heartbleed bug is significant because OpenSSL is widely used for secure communication over the internet, including for websites, email servers, and other critical applications. The vulnerability affected a large percentage of all web servers on the internet at the time of its discovery. To mitigate the impact of the Heartbleed bug, organizations needed to upgrade the OpenSSL software to a non-vulnerable version, revoke and reissue any compromised SSL/TLS certificates, and encourage users to change their passwords on affected systems. The Heartbleed bug highlighted the importance of regular software patching and vulnerability management in maintaining the security of internet-connected systems.
Heap overflow	The heap is an area of memory allocated by the application during execution to store a variable. The heap can be used to store larger amounts of data than the stack, and variables are globally accessible to the process. When developing the program, the developer can insert code that tells the program to store items in the heap and then release them when done with it. This can include images or files. Poor programming of heap memory management can lead to memory leaks. This is when the program does not release the memory being used and keeps adding on. This causes the program to use more and more resources which will eventually lead to system slowdowns and crashes. Attackers can take advantage of this and target the heap portion of memory to overload it and crash the system.
Integer overflow	An integer is any positive or negative whole number. In many programs, allocated memory size is defined using whole numbers. An integer overflow is a type of software vulnerability that occurs when a program tries to store an integer value larger than the maximum value that the data type can hold, causing the value to wrap around to a lower value or overflow into adjacent memory space. This can cause the program to behave unpredictably, resulting in a security vulnerability if the overflowed value is used in a sensitive calculation or security check. An integer overflow vulnerability occurred during NASA's Mars Climate Orbiter mission in 1999. During the mission, the orbiter was lost due to a navigation error caused by an integer overflow. The navigation software for the orbiter used a 16-bit signed integer to represent the force of the thrusters. Unfortunately, the actual force of the thrusters was much larger than the maximum value that the integer was designed to hold. When the orbiter's software tried to convert the observed force to a 16-bit integer value, an integer overflow occurred, causing the value to "wrap around" to a negative value resulting in a miscalculation of the orbiter's trajectory, causing it to burn up in the Martian atmosphere. This incident illustrates the importance of proper integer handling in software development, particularly in safety-critical systems like spacecraft. To prevent integer overflow vulnerabilities, secure coding practices and techniques like input validation, range checking, and type-safe libraries ensure that integer values are correctly handled and do not exceed the maximum value the data type can hold.
Stack overflow	A stack overflow vulnerability occurs when a program tries to store more data in the stack than it can handle. The stack is a region of memory that holds temporary data created by a program during runtime. When a function is called, it creates a stack frame that contains information such as local variables, return addresses, and other data. If a program tries to store more data than the stack frame can hold, it can cause a buffer overflow, overwriting adjacent memory and potentially causing the program to crash or execute malicious code. Attackers can exploit stack overflow vulnerabilities to gain control of a system or steal sensitive data. To prevent stack overflow vulnerabilities, developers must ensure that programs allocate enough memory for the stack, use safe programming practices, and use operating systems that utilize address space layout randomization (ASLR). Something as fundamental as choosing one programming language over another may mitigate overflow issues. For example, C and C++ contain built-in functions such as strcpy that do not provide a default mechanism for checking if data will overwrite the boundaries of a buffer. The developer must identify such insecure functions and ensure that every call made to them by the program is performed securely. Many development projects use higher-level languages, such as Java, Python, and PHP. These interpreted languages will halt execution if an overflow condition is detected. However, changing languages may be infeasible in an environment that relies heavily on legacy code, so it is imperative that you know where the weaknesses in your apps are. Running software with the least privilege can also help prevent this type of attack, as can using an operating system with address space layout randomization (ASLR). ASLR randomizes where components of a running process—the base executable, APIs, the heap, and so on—are placed in memory, which makes it more difficult to aim a buffer overflow at specific points in the address space.

image

---

---

The best way to defend against overflow attacks is to use proper programming practices and avoid using functions known to be vulnerable. Most modern-day languages, such as Python and Java, have built-in controls to prevent overflow attacks.

Cross-Site Scripting Attacks

Cross-site scripting (XSS) attacks are another common and dangerous attack. When a user visits a web page, the assumption is that the site is trusted and safe. If an attacker discovers an input validation error in the site, they can exploit this to carry out a cross-site scripting attack.

The following table describes the three types of XSS attacks:

Cross-Site Scripting Attacks	Description
Reflected	A reflected XSS attack involves a client clicking on a link to visit a trusted site. The steps to carry out this attack are as follows: The attacker finds a site that has an input validation vulnerability. The attacker crafts a URL link that contains malicious script. This link is shared on forums, social media, sent through emails, or some other method. The goal is to get people to click on the link. When the link is clicked, the malicious code is run on the vulnerable site and returned to the user's browser. These attacks are non-persistent. This means the link must be clicked every time the attack is carried out.
Persistent/stored	A persistent or stored XSS attack works very similarly to the reflected attack. Instead of relying on a user to click a link to run the attack, the attacker is able to upload the malicious script to the web server itself. Whenever a user visits the site, the malicious script will be run automatically.
Document object model (DOM)	Document Object Model (DOM) is a cross-platform structure to handle HTML and XML documents. DOM also allows for multiple scripting languages to be used in web applications. A DOM XSS attack is carried out when a web application writes data to the DOM without proper sanitation. The attacker can manipulate this data to include their malicious script, which then runs whenever a user accesses the web page. These attacks are very rare and the most difficult to pull off.

The best defense against XSS attacks is to ensure that all data input is properly sanitized before being allowed to run on the server. Educating users to be vigilant and not to click on links will help prevent reflected XSS attacks.

7.7.4 Application Attack Mitigation Checklists Facts

Implementing security controls is an essential component of mitigating application attacks. Application controls help prevent, detect, and respond to security threats in software applications, including input validation and sanitization, access control, and encryption. Implementing controls such as these (as well as others) helps to reduce the risk of successful application attacks.

This lesson covers application attack mitigation:

Application Attack Mitigation

The following table describes some important security controls for several important application security risks:

Application Security Risk	Security Controls
Security misconfiguration	Perform regular vulnerability assessments and penetration testing Use best practices Configure secure default settings Use configuration management tools Update and patch software and the OS regularly Restrict access to configuration interfaces Monitor and log configuration changes Conduct regular skills training
End-of-life or outdated components	Identify end-of-life or outdated components Implement compensating controls Implement replace or upgrade strategies Use containerization or virtualization Conduct regular vulnerability assessments
Privilege escalation	Implement the principle of least privilege Implement appropriate access controls Use strong authentication Regularly review and update permissions Monitor for unusual activity Use IDS/IPS appliances Conduct regular vulnerability assessments Conduct regular employee training
Identification and authentication failures	Use strong, unique passwords Implement multi-factor authentication and access controls Use secure communication protocols Regularly review and update user accounts Use IDS/IPS appliances Conduct regular vulnerability assessments Conduct regular employee training
Broken access control	Perform regular vulnerability assessments and penetration testing Use best practices Configure secure default settings Use configuration management tools Update and patch software and the OS regularly Restrict access to configuration interfaces Monitor and log configuration changes Conduct regular skills training
Cryptographic failures	Use strong cryptographic algorithms and appropriate key sizes Use random, unpredictable keys Protect all keys Use appropriate modes of operation and appropriate padding Use proper key management practices Test cryptographic systems regularly Keep up to date with the latest security best practices
Insecure design	Follow design principles Use secure coding practices Conduct threat modeling Implement secure architecture patterns Carefully use third-party libraries and frameworks Conduct code review and testing Follow secure development processes Train employees on secure practices
Remote code execution	Validate that software is up to date Use secure coding practices Implement access control and network segmentation Use IDS/IPS appliances Monitor all network traffic Implement application allowed listings Conduct regular vulnerability assessments Conduct regular employee training

The following video helps explain how to analyze vulnerabilities and recommend risk mitigation:

Video

Click one of the buttons to take you to that part of the video.

00:00-06:49 You know, it's kind of important when it comes to analyzing vulnerabilities to understand how to recommend good mitigation, right? To mitigate that risk. And so, to talk about what it means to analyze vulnerabilities and then recommend good things, is Ian Trump. -How are you doing, Ian? I'm doing great, James.

Ian's calling in from London. Tell us a bit more about yourself and let's start talking about analyzing vulnerabilities.

All right. Well, I'm the CISO for Cyjax, a threat intelligence company and I will tell you, one of the major things we do is analyze vulnerabilities, but more, I would say appropriately is analyzing the vulnerability from the attacker perspective, right? What is exposed? Is it vulnerable? Has a proof of concept for exploitation dropped? And, you know, is it going to be easily weaponized and, you know, tear across the internet, right?

-Yeah. -So... What are some of the bigger vulnerabilities that seem to be getting weaponized more? Are we still, I shouldn't say still, but, you know, we are talking about buffer overflows, we're talking about broken authentication or just misconfiguration or all of the above?

Yeah. I mean, it runs the gamut. I mean, the best way to really look at it is like the OWASP ten in terms of like what's pawning websites, but, you know, we're still seeing a lot of issues around like the latest print spooler issue dates back to 2005, right? It's a... One DLL apparently gives up your administrator credentials. So, that's not good.

So, we've got this kind of attack surface going on here whether it be from an insider attack or an outsider attack or in a zero-trust model, you know, what are some of the inherently kind of vulnerable systems and applications here? We can talk about this from a developer's perspective or a hacker's perspective, but like, you know, for example, from client side to server side, what are some of the issues that we're running into?

Well, you know, in a lot of cases in the client server world it dates back to, you know, 2000 and sometimes even beyond, where security wasn't really even a consideration. We've seen a lot of cases, to make it work security has to be disabled, the firewalls need to be turned into Swiss cheese. It's not a good situation from a security perspective. I think though, you know, when we look at operating system, browser, email client, those attack surfaces are the ones because they're going to be interacting -with the internet, right? -Sure. Where they, they're the conduit that the bad guys are going to use to try and get something inside your organization. Whether we're using the cloud or client server or whatever, it's the web browser where... Where they actually...

Yeah. I really think that is probably the major one. I mean, and then of course there's the external attack surface, which is the thing that's getting attacked, you know, remote desktop, web, web access... VPN, being some of the common ones. So, when you're thinking about vulnerable management, I'm going to say there's two spheres, there's the technical sphere and then there's the business impact

and you can't talk about technical vulnerability without taking into consideration, you know, the flows, the ebbs and flows of business within your organization. If you want get hated doing vulnerability management, do it all at the end of the month, when everyone in the organization is trying to desperately make their numbers, right?

-Right. -So, so, get in tune, have your vulnerable management program in tune with the business objectives, right? And that's how you make friends and not make enemies. All too often the disruption of a major patching effort comes at exactly the wrong time, the wrong moment.

That, that particular moment. You know, when it comes to some inherently vulnerable issues, people will sometimes or often mention JSON, for example or REST. What makes those things inherently an issue? It's not that they were made in an insecure way, it's got to be in the implementation or do I have it backwards?

No, I think it's a combination of two. Software development really doesn't have a huge background in security believe it or not. Application security is sort of a new arrival and so a lot of things were done out of necessity, you know. One of the first criticisms that people can lay on code is using filters to prevent bad stuff from happening as opposed to parametrized input that only accepts input under particular circumstances.

-Right. -And, unfortunately, one of the problems with legacy code is it's been around longer, it's, there's been more opportunity for adversaries to study it, to exploit it and it just will not hold up to modern standards of adversarial capability. So, one of the things, you know, I advise a lot of companies and, you know, tell me about the oldest thing that you have. I said, "Well, let's spend some money to, you know, improve it or replace it and that'll advance your security dials a tremendous amount," right?

Get rid of the 2003 small business server and all of a sudden, you've won, you've won the hearts and minds of every organization on the planet, right?

They're more efficient, they're more secure, right?

Absolutely. And I think that's one of the things and, and the management costs go down, considerably down when you no longer have legacy equipment that you have to look after.

Because then you're hopefully starting to cut down on various injection type attacks or sandbox escape attacks because with the newer technologies, hopefully, it can be monitored, visualized better and hopefully it was developed better, but those are the things you have to look into, right?

Absolutely. And in fact, you know, when you're thinking about how do I threat model against my major applications, download the free tools that the bad guys -are going to be using, right? -Yeah. Oh, yeah.

Run it against your stuff and then try to fix what is there. If you can't fix it, find a mitigative technology like, you know, a CDN or a web application firewall, put it in front of that application to further secure it. At the end of the day, you know, there's no such thing as a 100% security, someone will always find a way, right?

But you have to do a best effort, you do have a duty of care for your customers and even for your employees. So, you know, come up with the best way that you can, make it difficult for the bad guys -to get at your stuff. -Nicely put.

I mean, because you've got the whole idea, if you can't prevent it, then you mitigate it. So, thank you so much, Ian, for your time on this. It's great to hear from you.