Lesson 14 Flashcards
application attacks
- Attacks that target vulnerabilities in application code or architecture/design
- Privilege escalation
- Get privileges from target vulnerable process to run arbitrary code
- Remote execution when code is transferred from another machine
- Vertical and horizontal privilege escalation
- Detect by process logging and auditing plus automated detection scanning
- Error handling
- Identify attack from error messages
- Leaking information through errors
- Improper input handling
•Privilege escalation (application attacks)
The purpose of most application attacks is to allow the threat actor to run his or herown code on the system. This is referred to as arbitrary code execution. Where the code is transmitted from one machine to another, it can be referred to as remote code execution. The code would typically be designed to install some sort of backdoor or to disable the system in some way (denial of service).
arbitrary code execution
The purpose of most application attacks is to allow the threat actor to run his or her
own code on the system. This is referred to as arbitrary code execution.
remote code execution.
Where the code is transmitted from one machine to another, it can be referred to as remote code
execution. The code would typically be designed to install some sort of backdoor or to
disable the system in some way (denial of service).
Two types of privilidge escalation
If a software exploit
works, the attacker may be able to execute arbitrary code with the same privilege level as
the exploited process. There are two main types of privilege escalation:
- Vertical privilege escalation
- Horizontal privilege escalation
- Vertical privilege escalation
Vertical privilege escalation (or elevation) is where a user or application can
access functionality or data that should not be available to them. For instance, a
process might run with local administrator privileges, but a vulnerability allows the
arbitrary code to run with higher system privileges.
- Horizontal privilege escalation
Horizontal privilege escalation is where a user accesses functionality or data
that is intended for another user. For instance, via a process running with local
administrator privileges on a client workstation, the arbitrary code is able to execute
as a domain account on an application server.
How to detect priviledge escalation
- Detect by process logging and auditing plus automated detection scanning
Without performing detailed analysis of code or process execution in real time, it is
privilege escalation that provides the simplest indicator of an application attack. If process
logging has been configured (varonis.com/blog/sysmon-threat-detection-guide), the audit
log can provide evidence of privilege escalation attempts. These attempts may also be
detected by incident response and endpoint protection agents, which will display an alert.
Error Handling
- Identify attack from error messages
- Leaking information through errors
An application attack may cause an error message. In Windows, this may be of the following types: “Instruction could not be read or written,” “Undefined exception,”or “Process has encountered a problem.” One issue for error handling is that the
application should not reveal configuration or platform details that could help an
attacker. For example, an unhandled exception on a web application might show an
error page that reveals the type and configuration of a database server.
Improper input handling
Most software accepts user input of some kind, whether the input is typed manually or
passed to the program by another program, such as a browser passing a URL to a web
server or a Windows process using another process via its application programming
interface.
Good programming practice dictates that input should be tested to ensure
that it is valid; that is, the sort of data expected by the receiving process.
Mostapplication attacks work by passing invalid or maliciously constructed data to the
vulnerable process. There are many ways of exploiting improper input handling, but
many attacks can be described as either overflow-type attacks or injection-type attacks.
overflow attack
the threat actor submits input that is too large to be stored in a variable assigned by the application
Ideally, the
code used to attempt these attacks will be identified by network IDS or by an endpoint
protection agent. Unsuccessful attempts may be revealed through unexplained crashes
or error messages following a file download, execution of a new app or a script, or
connection of new hardware.
Buffer Overflow
[There is a diagram in the guide that is a little helpful]
- Buffer is memory allocated to application
- Overflows can allow arbitrary code to execute
To exploit a buffer overflow vulnerability, the attacker passes data that deliberately overfills
the buffer. One of the most common vulnerabilities is a stack overflow. The stack is an
area of memory used by a program subroutine. It includes a return address, which is the
location of the program that called the subroutine. An attacker could use a buffer overflow
to change the return address, allowing the attacker to run arbitrary code on the system.
Integer Overflow
- Cause application to calculate values that are out-of-bounds
- Could use to cause crash or use in buffer overflow attack
An integer is a positive or negative number with no fractional component (a whole number). Integers are widely used as a data type, where they are commonly defined
with fixed lower and upper bounds. An integer overflow attack causes the target
software to calculate a value that exceeds these bounds. This may cause a positive
number to become negative (changing a bank debit to a credit, for instance). It could
also be used where the software is calculating a buffer size; if the attacker is able to
make the buffer smaller than it should be, he or she may then be able to launch a
buffer overflow attack.
Null Pointer Dereferencing and Race Conditions
[I did not understand this one]
- Pointers are used in C/C++ to refer to memory locations
- Dereferencing occurs when the program tries to read or write the location via the pointer
- If the location is null or invalid, the process will crash
- Race condition
- Execution depends on timing and sequence of events
- Time of check/time of use (TOCTTOU)
- Environment is manipulated to change a resource after checking but before use
Memory Leaks
Memory leaks
•Process allocates memory locations, but never releases them
•Can cause host to run out of memory
•Could be faulty code or could be malicious
Resource exhaustion
- CPU time, system memory allocation, fixed disk capacity, and network utilization
- Spawning activity to use up these resources
A malicious process could spawn multiple looping threads to use up CPU time, or write
thousands of files to disk. Distributed attacks against network applications perform a
type of resource exhaustion attack by starting but not completing sessions, causing
the application to fill up its state table, leaving no opportunities for genuine clients
to connect.
Dynamic Link Library (DLL)
•Dynamic Link Library (DLL) implements some function that multiple processes can use
A dynamic link library (DLL) is a binary package that implements some sort of standard
functionality, such as establishing a network connection or performing cryptography.
The main process of a software application is likely to load several DLLs during the
normal course of operations.
DLL Injection
•DLL injection forces a process to load malicious DLL
DLL injection is a vulnerability in the way the operating system allows one process to
attach to another. This functionality can be abused by malware to force a legitimate
process to load a malicious link library. The link library will contain whatever functions
the malware author wants to be able to run. Malware uses this technique to move from
one host process to another to avoid detection.
Refactoring
Refactoring might allow code obfuscation to elude anti-virus (DLL Injection)
Shim
•Exploit application compatibility framework to allow malware to persist on host
Another opportunity for malware authors to exploit
these calls is the Windows Application Compatibility framework. This allows legacy
applications written for an OS, such as Windows XP, to run on later versions. The code
library that intercepts and redirects calls to enable legacy mode functionality is called a
shim. The shim must be added to the registry and its files (packed in a shim database/
.SDB file) added to the system folder. The shim database represents a way that
malware with local administrator privileges can run on reboot (persistence).
application compatibility framework
Windows Application Compatibility framework. This allows legacy
applications written for an OS, such as Windows XP, to run on later versions.
pass the hash
- Exploiting cached credentials to perform lateral movement
- Windows hosts cache credentials in memory as NTLM hashes
- Local malicious process with administrator privileges can dump these hashes
- Malware executes another process on a remote host
- Attacker can just pass hash without having to crack it
- Remote host will accept hash as credential
- Detection through security log events
URL Analysis
- Uniform Resource Locator (URL) format
- HTTP methods
- TCP connections
- GET, POST, PUT, HEAD
- POST or PUT
- URL (query parameters)
- Fragment/anchor ID
- HTTP response codes
- Percent encoding
•Uniform Resource Locator (URL) format
There is a diagram inthe guide
HTTP methods
- TCP connections
- GET, POST, PUT, HEAD
- POST or PUT
- URL (query parameters)
- Fragment/anchor ID
- HTTP response codes
How an http session works
An HTTPsession starts with a client (a user-agent, such as a web browser) making a request to
an HTTP server.
The connection establishes a TCP connection. This TCP connection canbe used for multiple requests, or a client can start new TCP connections for different
requests.
A request typically comprises a method, a resource (such as a URL path),
version number, headers, and body. The principal method is GET, used to retrieve a
resource. Other methods include:
- POST—send data to the server for processing by the requested resource.
- PUT—create or replace the resource. DELETE can be used to remove the resource.
- HEAD—retrieve the headers for a resource only (not the body).
•GET, POST, PUT, HEAD
- GET - used to retrieve a resource
- POST—send data to the server for processing by the requested resource.
- PUT—create or replace the resource. DELETE can be used to remove the resource.
- HEAD—retrieve the headers for a resource only (not the body).
POST of PUT
Data can be submitted to a server either by using a POST or PUT method
Percent encoding
A URL can contain only unreserved and reserved characters from the ASCII set.
Reserved ASCII characters are used as delimiters within the URL syntax and should only
be used unencoded for those purposes. The reserved characters are:
: / ? # [ ] @ ! $ & ‘ ( ) * + , ; =
There are also unsafe characters, which cannot be used in a URL. Control characters,
such as null string termination, carriage return, line feed, end of file, and tab, are
unsafe. Percent encoding allows a user-agent to submit any safe or unsafe character
(or binary data) to the server within the URL. Its legitimate uses are to encode reserved
characters within the URL when they are not part of the URL syntax and to submit
Unicode characters. Percent encoding can be misused to obfuscate the nature of a URL
(encoding unreserved characters) and submit malicious input. Percent encoding can
exploit weaknesses in the way the server application performs decoding. Consequently,
URLs that make unexpected or extensive use of percent encoding should be treated
carefully. You can use a resource such as W3 Schools (w3schools.com/tags/ref_
urlencode.asp) for a complete list of character codes, but it is helpful to know some of
the characters most widely used in exploits.
Application Programming Interface Attacks
- API calls and parameters
- Must only be with HTTPS encryption
- Common weaknesses and vulnerabilities
- Ineffective secrets management
- Lack of input validation
- Error messages leaking information
- Denial of service
HTTPS). API calls over plain HTTP are not secure and could easily be
impersonated or modified by a third party. Some other common attacks against APIs
target the following weaknesses and vulnerabilities:
• Ineffective secrets management, allowing threat actors to discover an API key and
perform any action authorized to that key.
• Lack of input validation, allowing the threat actor to insert arbitrary parameters into
API methods and queries. This is often referred to as allowing unsanitized input.
• Error messages revealing clues to a potential adversary. For example, an
authentication error should not reveal whether a valid username has been rejected
because of an invalid password. The error should simply indicate an authentication
failure.
• Denial of service (DoS) by bombarding the API with spurious calls. Protection against
this attack can be provided through throttling/rate-limiting mechanisms.
Replay Attacks
- Resubmitting or guessing authorization tokens
- Session management cookies
- Replay cookie to obtain authenticated session
- Secure cookies
Session management enables web applications to uniquely identify a user across
a number of different actions and requests. Session management is particularly
important when it comes to user authentication, as it is required to ensure the integrity
of the account and the confidentiality of data associated with it. Session management
is often vulnerable to different kinds of replay attack. To establish a session, the
server normally gives the client some type of token.
A replay attack works by
sniffing or guessing the token value and then submitting it to re-establish the session
illegitimately.
HTTP and cooks and replay actack
HTTP is statless. Cookiesu used to preserve stateful data. Cookies need to encypted. If using TLS, information in a cookie
would be secure in transit but reside on the client computer in plaintext, unless it had
been separately encrypted.
~~~~
HTTP is nominally a stateless protocol, meaning that the server preserves no
information about the client, but mechanisms such as cookies have been developed
to preserve stateful data. A cookie is created when the server sends an HTTP response
header with the cookie data. A cookie has a name and value, plus optional security and
expiry attributes. Subsequent request headers sent by the client will usually include
the cookie. Cookies are either nonpersistent (session) cookies, in which case they are
stored in memory and deleted when the browser instance is closed, or persistent, in
which case they are stored in the browser cache until deleted by the user or pass a
defined expiration date.
If cookies are used to store confidential information, the web application should
encrypt them before sending them to the client. If using TLS, information in a cookie
would be secure in transit but reside on the client computer in plaintext, unless it had
been separately encrypted. The value can be any URL-safe encoded string in whatever
format and structure the application uses for parsing.
Session Hijacking
Cookie hijacking and session prediction
In the context of a web application, session hijacking most often means replaying a
cookie in some way. Attackers can sniff network traffic to obtain session cookies sent
over an unsecured network, like a public Wi-Fi hotspot. To counter cookie hijacking,
you can encrypt cookies during transmission, delete cookies from the client’s browser
cache when the client terminates the session, and design your web app to deliver a
new cookie with each new session between the app and the client’s browser.
Session Prediction
Session prediction attacks focus on identifying possible weaknesses in the generation
of session tokens that will enable an attacker to predict future valid session values. If
an attacker can predict the session token, then the attacker can take over a session
that has yet to be established. A session token must be generated using a nonpredictable
algorithm, and it must not reveal any information about the session client.
In addition, proper session management dictates that apps limit the lifespan of a
session and require reauthentication after a certain period.
Client-side/cross-site (CSRF/XSRF) request forgery
There s a diagram that shows how it works
- Passes a URL to another site where the user has an authenticated session
- Confused deputy
This kind of attack is also known as confused deputy (the point being that the user and the user’s browser are not necessarily the same thing).
A client-side or cross-site request forgery (CSRF or XSRF) can exploit applications
that use cookies to authenticate users and track sessions. To work, the attacker must
convince the victim to start a session with the target site. The attacker must then pass
an HTTP request to the victim’s browser that spoofs an action on the target site, such
as changing a password or an email address. This request could be disguised in a few
ways and so could be accomplished without the victim necessarily having to click a
link. If the target site assumes that the browser is authenticated because there is a
valid session cookie and doesn’t complete any additional authorization process on the
attacker’s input (or if the attacker is able to spoof the authorization), it will accept the
input as genuine. This is also referred to as a confused deputy attack (the point being
that the user and the user’s browser are not necessarily the same thing).
Clickjacking
Add invisible layer to intercept/redirect click events
Clickjacking is an attack where what the user sees and trusts as a web application
with some sort of login page or form contains a malicious layer or invisible iFrame
that allows an attacker to intercept or redirect user input. Clickjacking can be launched
using any type of compromise that allows the adversary to run arbitrary code as a
script. Clickjacking can be mitigated by using HTTP response headers that instruct the
browser not to open frames from different origins (domains) and by ensuring that any
buttons or input boxes on a page are positioned on the top-most layer.
•SSL strip
A Secure Sockets Layer (SSL) strip attack is launched against clients on a local network
as they try to make connections to websites. The threat actor must first perform a
Man-in-the-Middle attack via ARP poisoning to masquerade as the default gateway.
When a client requests an HTTP site that redirects to an HTTPS site in an unsafe way,
the sslstrip utility (tools.kali.org/information-gathering/sslstrip) proxies the request and
response, serving the client the HTTP site, hopefully with an unencrypted login form. If
the user enters credentials, they will be captured by the threat actor. Sites can use the
HTTP Strict Transport Security (HSTS) lists maintained by browsers to prevent clients
requesting HTTP in the first place.
HTTP Strict Transport Security (HSTS)
A way to prevent SSL Strip attacks
Sites can use the HTTP Strict Transport Security (HSTS) lists maintained by browsers to prevent clients
requesting HTTP in the first place.
Cross-Site Scripting (XSS) attack
•Attacker injects code in trusted site that will be executed in client browser
Web applications depend on scripting, and most websites these days are web
applications rather than static web pages. If the user attempts to disable scripting,
very few sites will be left available. A cross-site scripting (XSS) attack exploits the fact
that the browser is likely to trust scripts that appear to come from a site the user has
chosen to visit. XSS inserts a malicious script that appears to be part of the trusted site.
Types of XSS attacks
- Non-persistent/reflected
- Coded in a link that the user must click
- Persistent/stored XSS
- Injected into a database the site uses to serve content
- Client-side scripts
- Document Object Model (DOM)
Non-persistent/reflected XSS attack
Coded in a link that the user must click
•Persistent/stored XSS
•Injected into a database the site uses to serve content
•Client-side scripts
•Document Object Model (DOM)
Client-side versus server-side attacks
Attacks such as session replay, CSRF, and DOM-based XSS are client-side attacks.
This means that they execute arbitrary code on the browser. A server-side attack
causes the server to do some processing or run a script or query in a way that is not authorized by the application design. Most server-side attacks depend on some kind of injection attack.
Injection attack
Most server-side attacks depend on some kind of
injection attack.
Where an overflow attack works against the way a process performs memory
management, an injection attack exploits some unsecure way in which the application
processes requests and queries.
For example, an application might allow a user to view
his or her profile with a database query that should return the single record for that
one user’s profile. An application vulnerable to an injection attack might allow a threat
actor to return the records for all users, or to change fields in the record when they are
only supposed to be able to read them.
SQL
A web application is likely to use Structured Query Language (SQL) to read and write
information from a database. The main database operations are performed by SQL
statements for selecting data (SELECT), inserting data (INSERT), deleting data (DELETE),
and updating data (UPDATE).
SQL Injection
- Pass SQL statements to the web application via user input or URL
- Show or insert database records
In a SQL injection attack, the threat actor modifies
one or more of these four basic functions by adding code to some input accepted by
the app, causing it to execute the attacker’s own set of SQL queries or parameters.
If successful, this could allow the attacker to extract or insert information into the
database or execute arbitrary code on the remote system using the same privileges as
the database application
SQL statements
•SELECT, INSERT, DELETE, UPDATE, WHERE
SQLstatements for selecting data (SELECT), inserting data (INSERT), deleting data (DELETE),
and updating data (UPDATE).
SELECT * FROM tbl_user WHERE username = ‘Bob’
XML and LDAP Injection Attacks
Extensible Markup Language (XML) injection
•XML tagged documents
•XML External Entity (XXE) to exfiltrate data and files
Lightweight Directory Access Protocol (LDAP) injection
•Query language to read and update network directories
XML Injection Attacks
External Entity
(XXE) attack
Extensible Markup Language (XML) injection
•XML tagged documents
•XML External Entity (XXE) to exfiltrate data and files
Extensible Markup Language (XML) is used by apps for authentication and
authorizations, and for other types of data exchange and uploading. Data submitted
via XML with no encryption or input validation is vulnerable to spoofing, request
forgery, and injection of arbitrary data or code. For example, an XML External Entity
(XXE) attack embeds a request for a local resource
]>
&bar;
This defines an entity named bar that refers to a local file path. A successful attack will
return the contents of /etc/config as part of the response.
Lightweight Directory Access Protocol (LDAP) injection
Lightweight Directory Access Protocol (LDAP) injection
•Query language to read and update network directories
The Lightweight Directory Access Protocol (LDAP) is another example of a query
language. LDAP is specifically used to read and write network directory databases. A
threat actor could exploit either unauthenticated access or a vulnerability in a client
app to submit arbitrary LDAP queries. This could allow accounts to be created or
deleted, or for the attacker to change authorizations and privileges (owasp.org/wwwcommunity/
attacks/LDAP_Injection).
