Threat actors can enter the network or move about it by using attacks to execute arbitrary code on trusted hosts. An attacker can easily progress to breaching data assets or triggering a denial of service against critical servers with adequate privileges and access.
Most application attacks aim to achieve arbitrary code execution, which involves exploiting vulnerabilities to allow an attacker (or threat actor) to execute their own code. When the code is transmitted from one machine to another, it is known as remote code execution, enabling the attacker to send and execute code from a remote host on a target host that is vulnerable to such exploits.
In today's post, we will look at potential application attack indicators to help in recognize the presence of a current or future attack on software applications. Examining odd network traffic, anomalous system activity, unusual user actions, security alerts, and known attack patterns are all part of this. Individuals can more effectively notice and respond to application threats if these indications are successfully examined.
#1: Privilege escalation
Privilege escalation is the process by which an attacker elevates their privileges from a lower level (such as a regular user) to a higher level (such as an administrator or root) in order to gain increased/higher access and control within a system, network, or application.
Privilege escalation can occur in an operating system or other application
Types of privilege escalation:
Vertical Privilege Escalation: An attacker attempts to elevate their privileges inside the same user hierarchy. A user with limited privileges, for example, attempts to get administrative access to the same system.
Horizontal Privilege Escalation: In this case, the attacker attempts to achieve the same level of privileges as another system user. This often occurs when a flaw permits impersonation or session hijacking, allowing the attacker to obtain access to another user's account or session.
Lateral Privilege Escalation: Obtaining privileges in another system or environment within a network. Once an attacker has gained access to one system, they will exploit weaknesses to gain access to other interconnected systems.
Mitigation
Cross-site scripting
Cross-site scripting (XSS) is one of the most common web attack
methodologies. The cause of the vulnerability is weak user input validation.
If input is not validated properly, an attacker can include a script in their
input and have it rendered as part of the web process.
cross-site because of browser security flaws
– Information from one site could be shared with another
Takes advantage of the trust a user has for a site
TYPES OF XSS
Non-persistent XSS attack The injected script is not persisted or
stored but rather is immediately executed and passed back via the web
server.
CONTROL
Controls to defend against XSS attacks include the use of anti-XSS
libraries to strip scripts from the input sequences. Various other ways to
mitigate XSS attacks include limiting the types of uploads, screening the size
of uploads, and whitelisting inputs. However, attempting to remove scripts
from inputs can be a tricky task. Well-designed anti-XSS input library
functions have proven to be the best defense. Cross-site scripting
vulnerabilities are easily tested for and should be a part of the test plan for
every application. Testing a variety of encoded and unencoded inputs for
scripting vulnerability is an essential test element
Input validation is helpful at preventing XSS attacks.
Input validation, also commonly known as data validation, is the
structured and proper testing of any input that is supplied by an application or
user. Input validation prevents improperly formed (malformed) data from
entering a system.
Protecting against XSS
Injections
User input without input validation results in an opportunity for an attacker to
craft input to create specific events that occur when the input is parsed and
used by an application
Types of injection attacks
Structured query language (SQL)
Structured Query Language (SQL) injection attacks
involve the manipulation of input, resulting in a SQL statement that is
different from the statement the designer intended
A SQL injection attack is a form of code injection aimed at any SQL-based
database, regardless of vendor. An example of this type of attack is where the
function takes the user-provided inputs for username and password and
substitutes them in a where clause of a SQL statement with the express
purpose of changing the where clause into one that gives a false answer to
the query
The addition of the or clause, with an always true statement and the
beginning of a comment line to block the trailing single quote, alters the SQL
statement to one in which the where clause is rendered inoperable. If the
where clause is altered to return all records, this can result in a data breach.
control
Stored procedures are precompiled methods implemented within a
database engine. Stored procedures act as a secure coding mechanism
because they isolate user input from the actual SQL statements being
executed. This is the primary defense mechanism against SQL injection
attacks—in other words, separation of user input from the SQL statements.
User-supplied input data is essential in interactive applications that use
databases; these types of applications allow the user to define the specificity
of search, match, and so on
Dynamic-link library (DLL)
DLL injection is a vulnerability that allows the malware to take advantage of the operating system's ability to attach one process to another. Attackers inject a malicious DLL into a legitimate process, potentially causing program instability and sensitive data spillage. This method makes use of dynamic-link library (DLL) technology, which provides functionality to a program via library routines that are linked at runtime. DLLs, for example, are loaded at runtime in Microsoft Office, and putting a malicious DLL in the relevant directory or via a registry entry can bring new destructive functionality.
A Dynamic-Link Library is a Windows library that contains both code and data. Inject a DLL into an application and have it run a program that runs as part of the target process.
Lightweight Directory Access Protocol (LDAP)
LDAP-based systems are also subject to injection attacks. When an
application constructs an LDAP request based on user input, a failure to
validate the input can lead to a bad LDAP request. Just as SQL injection can
be used to execute arbitrary commands in a database, LDAP injection can do
the same in a directory system. Something as simple as a wildcard character
(*) in a search box can return results that would normally be beyond the
scope of a query. Proper input validation is important before a request is
passed to an LDAP engine.
Extensible Markup Language (XML)
XML can be tampered with via injection as well. XML injections can be
used to manipulate an XML-based system. Because XML is nearly
ubiquitous in the web application world, this form of attack has a wide range
of targets. XML that is maliciously altered can affect changes in
configurations, changes in data streams, changes in outputs—all from the
injection
#: Pointer/object dereference
Pointer dereference is a software vulnerability that occurs when code tries to access memory through a pointer but the pointer itself is null. Pointers in C/C++ programming store memory addresses. Dereferencing a pointer entails reading or writing data to the memory address to which it points. If the pointer is null or invalid (which can happen as a result of malicious intervention), a null pointer dereference exception occurs, resulting in a process crash.
Mitigation
Directory traversal
A directory traversal attack is when an attacker uses special inputs to
circumvent the directory tree structure of the filesystem. Adding encoded
symbols for “../..” in an unvalidated input box can result in the parser
resolving the encoding to the traversal code, bypassing many detection
elements, and passing the input to the filesystem. The program then executes
the commands in a different location than designed. When combined with a
command injection, the input can result in the execution of code in an
unauthorized manner. Classified as input validation errors, these can be
difficult to detect without doing code walkthroughs and specifically looking
for them.
Directory traversals can be masked by using the encoding of input
streams. If the security check is done before the string is decoded by the
system parser, then recognition of the attack form may be impaired.
# Buffer overflows
A buffer is a section of memory reserved by the application to store expected data. Buffer overflows occur when data exceeds a target buffer's capacity, damaging adjacent memory. This can cause system crashes or allow attackers to run unauthorized code. Consider a program that expects a username of maximum of 15 characters but receives a string of 100 characters.. If not handled properly, this can result in a buffer overflow.
In a buffer overflow attack, the attacker deliberately sends data that exceeds the buffer's intended capacity.
Mitigation
#: Race conditions
A race condition is a software vulnerability that happens when certain events do not take place in the sequence and at the right times as intended by the developer and the expected result of execution processes depends on them. The idea of several inputs trying to impact the output first is referred to as a "race condition." This flaw can appear in distributed or multithreaded programs where appropriate program operation depends on the order or timing of processes or threads.
Time of check/time of use
When there is a delay between when an application examines a resource and when it actually uses it. This inconsistency creates the possibility for modifications to happen between the check and use stages, which could compromise the application's integrity or security.
For instance, an attacker might modify or delete a temporary file generated by an application to store a value for later use if they have access to the system between the time the file is created and the time it is utilized.
Mitigation
#: Error handling
Application security depends on secure handling of errors and exceptions, as they are inevitable in every application. Attackers can exploit error management procedures to gain access to sensitive data by intentionally triggering errors.
Mitigation
# Improper input handling
To avoid application attacks, proper input handling is crucial in software development. Attackers frequently take advantage of inadequate input validation by sending erroneous or malicious data to vulnerable processes. This can lead to SQL injections, buffer overflows, denial of service, etc
Mitigation
Replay attack
Replay attacks work against applications by attempting to re-create the
conditions that existed the first time the sequence of events occurred. If an
attacker can record a series of packets and then replay them, what was valid
before may well be valid again. An example of this would be repeating the
previous set of transactions, like getting paid twice or successfully passing a
security check at a login event.
Session replays
When a user connects to a system via the web, the connection forms a
“session” in the respect that the various elements that are transmitted back
and forth form a conversation between the client and the server. A session
replay event is the re-creation of this interaction after it has occurred.
#: Integer overflow
Integers (whole integers) are data types defined with fixed lower and upper bounds. An integer overflow attack occurs when a computed result is too large to fit in the allocated storage space, resulting in a crash or data corruption, as well as a buffer overflow. This can cause a positive number to become negative (for example, transforming a bank debit to a credit).
Mitigation
Request forgeries
Request forgery is a class of attack where a user performs a state-changing
action on behalf of another user, typically without their knowledge. It is like
having someone else add information to your web responses. These attacks
utilize the behavioral characteristics of web-based protocols and browsers,
and they occur because of client-side issues but they can be seen on both the
server side and the client side.
Server-side:
Server-side request forgery is when an attacker sends requests to the serverside application to make HTTP requests to an arbitrary domain of the
attacker’s choosing. These attacks exploit the trust relationship between the
server and the target, forcing the vulnerable application to perform
unauthorized actions. The typical trust relationships exploited are those that
exist in relation to the server itself, or in relation to other back-end systems
within the same organization. Common attacks include having the server
attack itself or attack another server in the organization.
Cross-site:
Cross-site request forgery (XSRF) attacks utilize unintended behaviors that
are proper in defined use but are performed under circumstances outside the
authorized use. This is an example of a “confused deputy” problem, a class
of problems where one entity mistakenly performs an action on behalf of
another. An XSRF attack relies upon several conditions to be effective. It is
performed against sites that have an authenticated user and exploits the site’s
trust in a previous authentication event. Then, by tricking a user’s browser
into sending an HTTP request to the target site, the trust is exploited. Assume
your bank allows you to log in and perform financial transactions but does
not validate the authentication for each subsequent transaction. If a user is
logged in and has not closed their browser, then an action in another browser
tab could send a hidden request to the bank, resulting in a transaction that
appears to be authorized but in fact was not done by the user.
Many different mitigation techniques can be employed, from limiting
authentication times, to cookie expiration, to managing specific elements of a
web page (for example, header checking). The strongest method is the use of
random XSRF tokens in form submissions. Subsequent requests cannot work
because a token was not set in advance. Testing for XSRF takes a bit more
planning than for other injection-type attacks, but this, too, can be
accomplished as part of the design process
#: Application programming interface (API) attacks
APIs are used to feed data to an application. It is used in web apps and cloud services to enable consumers to automate services. if the API is not secure, threat actors can simply exploit it to compromise the web application's services and data. It is critical to utilize an API exclusively via an encrypted channel (HTTPS).
Mitigation
#: Resource exhaustion
Resource exhaustion occurs when a system lacks the necessary resources to function properly, including capacity and memory. Attacks exploiting this vulnerability aim to deplete these resources, similar to race conditions, leading to system crashes and disruption of services. Examples include overwhelming a system with TCP SYN requests or exhausting program memory. These attacks can impact customer-facing systems and disrupt essential services. Resource exhaustion attacks target CPU time, memory, disk capacity, and network utilization, causing systems to become unresponsive or fill up state tables.
Mitigation
#: Memory leak
Memory management is the process of controlling and coordinating computer memory, allocating it to variables, and reclaiming it when it is no longer required. Memory leaks, a software vulnerability in which allocated memory is not released once it is no longer in use. This can lead to increased resource use over time, potentially causing system instability. A memory leak happens when a process fails to relinquish memory, resulting in ongoing memory depletion and possible system crashes.
Mitigation
Secure Sockets Layer (SSL) stripping
Secure sockets layer (SSL) stripping is a man in the middle attack against all
SSL and early versions of TLS connections. The attack is performed
anywhere a man in the middle attack can happen, which makes wireless
hotspots a prime location. The attack works by intercepting the initial
connection request for HTTPS, redirecting it to an HTTP site, and then
mediating in the middle. The reason the attack works is because the
beginning of an SSL or TLS (v1.0 or v1.1) handshake is vulnerable to attack.
The main defense is technical: only use TLS 1.2 or 1.3, as these versions
have protections against the specific attack method.
Driver manipulation
Drivers are pieces of software that sit between the operating system and a
peripheral device. In one respect, drivers are a part of the OS, as an
extension. In another respect, drivers are code that is not part of the OS and
are developed by firms other than the OS developer. Driver manipulation is
an attack on a system by changing drivers, thus changing the behavior of the
system. Drivers may not be as protected as other parts of the core system, yet
they join it when invoked. This has led to drivers being signed and
significantly tightening up the environment of drivers and ancillary programs.
Shimming
A shim is an additional code that is placed between an application driver and the operating system to enable functionality that would otherwise be unavailable. It allows modifications between different OS versions without altering the original driver code, giving it flexibility and portability. Shimming can be exploited by malicious code to change the functionality of a driver without altering the driver itself.
Refactoring
Refactoring is the practice of restructuring application code in order to improve its design and performance while retaining its original functionality. It can be used to improve code or to deal with certain scenarios. However, attackers can use refactoring to introduce illegal functionality to a driver while still allowing it to work normally. it is a Metamorphic malware that can appear different each time
#: Pass the hash
The pass-the-hash attack is an attack in which the attacker takes hashed user credentials and uses them to authenticate on the same network or other systems without knowing the original password. This technique makes use of hashed passwords rather than plaintext passwords for authentication.
Mitigation