Explore

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

Last edited 864 days ago by Makiel [Muh-Keel].

Exploiting Web Application Vulnerabilities

Web applications are complex ecosystems consisting of application code, web platforms, operating systems, databases, and interconnected application programming interfaces (APIs).

The complexity of these environments makes many different types of attack possible and provides fertile ground for penetration testers.

Cross-Site Scripting (XSS)

Cross-site scripting (XSS) attacks occur when web applications allow an attacker to perform HTML injection, inserting their own HTML code into a web page.

In other words, it works by manipulating a vulnerable web site so that it returns malicious JavaScript to users. When the malicious code executes inside a victim's browser, the attacker can fully compromise their interaction with the application.

Reflected XSS If an attacker can control a script that is executed in the victim's browser, then they can typically fully compromise that user. Amongst other things, the attacker can:

Perform any action within the application that the user can perform.

View any information that the user is able to view.

Modify any information that the user is able to modify.

Initiate interactions with other application users, including malicious attacks, that will appear to originate from the initial victim user.

Stored/Persistent XSS Another common technique is to store cross-site scripting code on a remote web server in an approach known as stored XSS.

These attacks are described as persistent, because they remain on the server even when the attacker isn’t actively waging an attack.

This XSS attack could also be used to redirect users to a phishing site, request sensitive information, or perform another attack.

DOM XSS (Document Object Model Cross-Site Scripting) is a type of Cross-Site Scripting (XSS) attack where the malicious payload is executed as a result of modifying the DOM environment in a victim's browser.

Unlike traditional XSS attacks where the malicious payload is injected into the response from the server, DOM XSS operates exclusively on the client side.

While DOM XSS attacks don't inherently hide code, attackers often use obfuscation techniques to disguise their malicious payloads, making them harder to detect and understand.

Request Forgeries

Cross-site request forgery Attacks (XSRF) or (CSRF) exploit the trust that remote sites have in a user’s system to execute malicious commands on the user’s behalf.

This attack is based on a lot of assumptions, but when it sticks it sticks.

An online banking site. An attacker who wants to steal funds from user accounts might go to an online forum and post a message containing a link.

That link actually goes directly into the money transfer site that issues a command to transfer funds to the attacker’s account.

The attacker then leaves the link posted on the forum and waits for an unsuspecting user to come along and click the link. If the user happens to be logged into the banking site, the transfer succeeds.

⁠

Server-Side Request Forgery (SSRF) attacks exploit a similar vulnerability but instead of tricking a user’s browser into visiting a URL, they trick a server into visiting a URL based on user input.

If the server has access to private URLs, an SSRF attack can disclose that information to an attacker.

⁠

Injection Vulnerabilities

Injection Vulnerabilities allow an attacker to supply some type of input code to the web application and trick the web server into either executing that code or supplying it to another server to execute.

Code Injection Attacks SQL injection attacks are a specific example of a general class of attacks known as code injection attacks. These attacks seek to insert attacker-written code into the legitimate code created by a web application developer.

These are among the primary mechanisms that attackers use to break through a web application and gain access to the systems supporting that application.

SQL Injection Attacks

⁠

Blind SQL Injection Attacks

A Blind SQL injection attack type attackers use to

Find out if the website has a blind SQL Injection Vulnerability to begin with.

If the website does have said vulnerability, they can exploit it to extract various forms of information.

A subtype of blind SQL injection where the attacker observes the behavior of the database server and the application after combining legitimate queries with SQL commands that cause time delays.

If after the attacker queries the table and time delays occur, they can get more data about the table structure of the SQL table and finally extract data from the table.

An attacker can cycle through all the possible password combinations to narrow down the password character by character.

This may seem tedious, but security tools like SQLmap and Metasploit automate blind timing–based attacks.

Dynamic Link Libraries (DLL) Injection

A missing DLL or a DLL which is implemented in an unsecure method can be utilized in order to trick the running system to execute a malicious payload.

Injected commands may even attempt to load dynamically linked libraries (DLLs) containing malicious code in a DLL injection attack.

LDAP (Lightweight Directory Access Protocol) Injection Attack

LDAP Injection is an attack used to exploit web based applications that construct LDAP statements based on user input.

When an application fails to properly sanitize user input, it’s possible to modify LDAP statements using a local proxy.

This could result in the execution of arbitrary commands such as granting permissions to unauthorized queries, and content modification inside the LDAP tree.

Extensible Markup Language (XML) Injection Attack

XML Injection Attacks is a category of vulnerabilities where an application doesn’t correctly validate/sanitize user input before using it in an XML document or query.

Bad guys can then have full control to modify whatever is in your XML documents.

XML injections enable unvalidated user data (attacker input) to construct queries that allow an attacker to read or modify XML documents or execute commands in your XML-enabled database.

This enables an attacker to get around your application’s front end to gain access to the juicy stored data they seek by taking advantage of vulnerabilities that exist in input fields (e.g., the user’s name, password, and search input fields).

⁠

Pointer/Object Deference

Pointers are a commonly used concept in application development. They are simply an area of memory that stores an address of another location in memory.

Ex. We might have a pointer called ‘photo’ that contains the address of a location in memory where a photo is stored. When an application needs to access the actual photo, it performs an operation called pointer de-referencing. (The application follows the pointer and accesses the memory referenced by the pointer address).

In the case a Pointer is mapped to a blank or null value, the application will crash, providing an attacker with access to debugging information that may be used for reconnaissance of the application's security.

In the worst case, a null pointer exception may allow an attacker to bypass security controls.

Buffer Overflows

Buffer Overflow Attacks occur when an attacker manipulates a program into placing more data into an area of memory than is allocated for that program’s use.

The goal is to overwrite other information in memory with instructions that may be executed by a different process running on the system.

A static analysis can easily detect a buffer overflow.

⁠

Race Conditions

Race Conditions take advantage of the need that computing systems must execute some tasks in a specific sequence. In any such sequence, there is a small period of time when the system has carried out the first task but not started on the second.

If this period is long enough, a race condition vulnerability exists where an attacker can trick the system into carrying out unauthorized actions in addition to its normal processes.

Time of Check to Time of Use (TOCTOU):

TOCTOU is a type of race condition that occurs when a system's state changes between the time a property is checked (time of check) and the time that property is used (time of use).

If an attacker can exploit this window of opportunity between the check and the use, they can manipulate the outcome.

Analogy:

Imagine you're a security guard at an exclusive event. Your job is to check the guest list (time of check) and then let the person enter (time of use).

At 8:00 PM, you check the guest list and see that "John Doe" is on it.

Just as you're about to let John Doe in, an imposter (attacker) quickly takes his place and enters the event pretending to be John Doe.

In this scenario, the time between checking the guest list and letting the guest in is the vulnerable window. The imposter exploited the race condition (the brief moment between checking and using) to gain unauthorized access.

In Computing:

A classic example of TOCTOU in computing is with file operations:

A program checks if a file exists and if the user has permissions to access it (time of check).

Before the program actually accesses the file (time of use), an attacker replaces the file or changes its permissions.

The program, thinking it's accessing the original file, ends up accessing or executing the attacker's file.

This race condition can lead to unauthorized access, data corruption, or even system compromise if the replaced file contains malicious code.

In summary, TOCTOU is a race condition where the state of a system can change between the moment it's checked and the moment it's used, leading to potential security vulnerabilities.

Error Handling

Developers must write their code so that it is resilient to unexpected situations that an attacker might create in order to test the boundaries of code.

Developers must anticipate unexpected situations and write Error Handling Code that steps in and handles these situations in a secure fashion. Improper error handling may expose code to unacceptable levels of risk.

Ex. If a web form requests an age as input, it’s insufficient to simply verify that the age is an integer (number). Attackers might enter a 50,000-digit integer in that field in an attempt to perform an Integer Overflow Attack.

Proper error handling and planning must be implemented to prepare and mitigate this type of attack.

If error handling routines explain too much about the inner workings of code, they may allow an attacker to find a way to exploit the code.

Improper Input Handling

Input Validation and Improper Input Handling Applications that allow user input should perform validation of that input to reduce the likelihood that it contains an attack.

Input validation techniques are the go-to standard for protecting against injection attack

Improper input handling practices can expose applications to injection attacks, cross-site scripting attacks, and other exploits.

Input Whitelisting When the developer describes the exact type of input that is expected from the user and then verifies that the input matches that specification before passing the input to other processes or servers.

Ex. If an input form prompts a user to enter their age, input whitelisting could verify that the user supplied an integer value within the range 0–120. The application would then reject any values outside that range.

It is very important to ensure that validation occurs Server-Side rather than within the client’s browser.

Browser-side validation can easily be bypassed and compromised by attackers and penetration testers.

Input Blacklisting can be used when it may be difficult to describe the exact inputs needed for validation.

Instead you describe in detail what inputs are not allowed; Allows Application security to describe potentially malicious input that must be blocked.

Parameter Pollution is one technique that attackers have successfully used to defeat input validation controls.

Parameter pollution works by sending a web application more than one value for the same input variable.

Attacker inject two or more parameters into the code in hopes that one of them slip through the filtering technology.

This approach relies on the premise that the web platform won’t handle a URL with two different simultaneous parameters in the URL properly.

It might perform input validation on only the first argument but then execute the second argument, allowing the injection attack to slip through the filtering technology.

Parameter pollution attacks depend on defects in web platforms that don’t handle multiple copies of the same parameter properly.

Only really happens to unpatched or unprotected custom written code.

⁠

Replay Attacks

A Replay Attack occurs when a cybercriminal eavesdrops on a secure network communication, intercepts it, and then fraudulently delays or resends it to misdirect the receiver into doing what the hacker wants.

Not an On-Path (Man-in-the-Middle) attack.

Different because a replay attack doesn’t require the original workstation. Once the login credentials are captured, the attacker can use any workstation to access the resources on the server.

Preventative Measures

Encryption is Key, literally! Both sender and receiver should establish a completely random session key, which is a type of code that is only valid for one transaction and can't be used again.

Avoid this type of replay attack by adding a salt – Use a session ID with the password hash to create a unique authentication hash each time

Use Timestamps on all Messages. This prevents hackers from resending messages sent longer ago than a certain length of time, thus reducing the window of opportunity for an attacker to eavesdrop, siphon off the message, and resend it.

⁠

Privilege Escalation

Privilege Escalation attacks seek to increase the level of access that an attacker has to a target system.

They exploit vulnerabilities that allow the transformation of a normal user account into a more privileged account, such as the root superuser account.

More capabilities at the hands of the attacker equates to more problems.

Mo’ Privileges, Mo’ Problems.

⁠

Application Program Interface (API) Attacks

Application Programming Interfaces (APIs) are interfaces between clients and servers or applications and operating systems that define how the client should ask for information from the server and how the server will respond.

This definition means that programs written in any language can implement the API and make requests.

⁠

API security relies on authentication, authorization, proper data scoping to ensure that too much data isn’t released, rate limiting, input filtering, and appropriate monitoring and logging to remain secure.

Couple these with securing the underlying systems, configuring the API endpoint server or service, and providing normal network layer security, and you’ve got API Security defense-in-depth.

Code Review Models

Catching problems early can result in significant savings in time and cost. That’s why Code Review is essential in the development cycle.

Pair Programming

Pair programming is an Agile software development technique that places two developers at one workstation. One developer writes code, while the other developer reviews their code as they write it.

This is intended to provide real-time code review, and it ensures that multiple developers are familiar with the code that is written

Pass-Around Code Reviews

A form of manual peer review done by sending completed code to reviewers who check the code for issues. Pass-around reviews may involve more than one reviewer, allowing reviewers with different expertise and experience to contribu

Tool-Assisted Reviews

Relies on formal or informal software-based tools to conduct code reviews. Tools like Atlassian’s Crucible collaborative code review tool, Codacy’s static code review tool, and Phabricator’s Differential code review tool are all designed to improve the code review process. T

Fagan Inspection

Fagan inspection is a form of structured, formal code review intended to find a variety of problems during the development process.

Fagan inspection specifies entry and exit criteria for processes, ensuring that a process is not started before appropriate diligence has been performed, and also making sure that there are known criteria for moving to the next phase

⁠

Software Security Testing

Static code analysis (sometimes called source code analysis) is conducted by reviewing the code for an application. Since static analysis uses the source code for an application, it can be seen as a type of white-box testing with full visibility to the testers.

Static analysis does not run the program; instead, it focuses on understanding how the program is written and what the code is intended to do.

Dynamic code analysis relies on execution of the code while providing it with input to test the software. Much like static code analysis, dynamic code analysis may be done via automated tools or manually, but there is a strong preference for automated testing due to the volume of tests that need to be conducted.

Fuzz testing involves sending invalid or random data to an application to test its ability to handle unexpected data.

The application is monitored to determine if it crashes, fails, or responds in an incorrect manner.

Resource Exhaustion

Intentional or Accidental, systems may consume all of the memory, storage, processing time, or other resources available to them, rendering the system disabled or crippled for other uses.

Memory Leaks If an application requests memory from the operating system, it will eventually no longer need that memory and should then return the memory to the operating system for other uses.

In the case of an application with a memory leak, the application fails to return some memory that it no longer needs, perhaps by simply losing track of an object that it has written to a reserved area of memory.

SSL Stripping

SSL Stripping An attack that in modern implementations removes TLS encryption to read the contents of traffic that is intended to be sent to a trusted endpoint.

⁠

A typical SSL stripping attack occurs in three phases:

A user sends an HTTP request for a web page.

The server responds with a redirect to the HTTPS version of the page.

The user sends an HTTPS request for the page they were redirected to, and the website loads.

⁠

Driver Manipulation

Device drivers play an important role in computing. They serve as the software interface between hardware devices and the operating system.

If an attacker can convince a user to install a malicious driver on their computer, that malware can gain complete control of the system.

Refactoring If they have access to the driver’s source code, they can modify it to also include malware elements.

⁠

Shimming It takes a legitimate driver and wraps a malicious driver around the outside of it.

The malicious driver, known as the shim, receives requests from the operating system and simply passes them on to the legitimate driver so that the device functions normally. However, the driver can also carry out its malware payload in the background.

⁠

Directory Traversal

Directory Traversal occurs when some web servers suffer from a security misconfiguration that allows users to navigate the directory structure and access files that should remain secure.

⁠