Lesson 14 Flashcards
1
Q
application attacks
A
- 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
2
Q
•Privilege escalation (application attacks)
A
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).
3
Q
arbitrary code execution
A
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.
4
Q
remote code execution.
A
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).
5
Q
Two types of privilidge escalation
A
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
6
Q
- Vertical privilege escalation
A
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.
7
Q
- Horizontal privilege escalation
A
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.
8
Q
How to detect priviledge escalation
A
- 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.
9
Q
Error Handling
A
- 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.
10
Q
Improper input handling
A
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.
11
Q
overflow attack
A
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.
12
Q
Buffer Overflow
A
[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.
13
Q
Integer Overflow
A
- 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.
14
Q
Null Pointer Dereferencing and Race Conditions
A
[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
15
Q
Memory Leaks
A
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
16
Q
Resource exhaustion
A
- 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.
17
Q
Dynamic Link Library (DLL)
A
•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.
18
Q
DLL Injection
A
•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.
19
Q
Refactoring
A
Refactoring might allow code obfuscation to elude anti-virus (DLL Injection)
20
Q
Shim
A
•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).
21
Q
application compatibility framework
A
Windows Application Compatibility framework. This allows legacy
applications written for an OS, such as Windows XP, to run on later versions.
22
Q
pass the hash
A
- 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
23
Q
URL Analysis
A
- 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
24
Q
•Uniform Resource Locator (URL) format
A
There is a diagram inthe guide
25
HTTP methods
* TCP connections
* GET, POST, PUT, HEAD
* POST or PUT
* URL (query parameters)
* Fragment/anchor ID
* HTTP response codes
26
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).
27
•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).
28
POST of PUT
Data can be submitted to a server either by using a POST or PUT method
29
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.
30
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.
31
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.
32
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.
33
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.
34
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.
35
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).
36
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.
37
•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.
38
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.
39
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.
40
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)
41
Non-persistent/reflected XSS attack
Coded in a link that the user must click
42
•Persistent/stored XSS
•Injected into a database the site uses to serve content
43
•Client-side scripts
•Document Object Model (DOM)
44
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.***
45
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.
46
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).
47
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
48
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'
49
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
50
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.
51
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).
52
LDAP
The Lightweight Directory Access Protocol (LDAP) is another example of a query
language. LDAP is specifically used to read and write network directory databases.
53
Directory traversal
Limited understanding of this one
* Obtain access to files outside web site root directory
* Canonicalization attack and percent encoding
Directory traversal is another type of injection attack performed against a web server.
The threat actor submits a request for a file outside the web server's root directory by
submitting a path to navigate to the parent directory (../). This attack can succeed if the
input is not filtered properly and access permissions on the file are the same as those
on the web server directory.
The threat actor might use a canonicalization attack to disguise the nature of the
malicious input. Canonicalization refers to the way the server converts between the
different methods by which a resource (such as a file path or URL) may be represented
and submitted to the simplest (or canonical) method used by the server to process the
input. Examples of encoding schemes include HTML entities and character set percent
encoding (ASCII and Unicode). An attacker might be able to exploit vulnerabilities in
the canonicalization process to perform code injection or facilitate directory traversal.
54
Command injection
A command injection attack attempts to cause the server to run OS shell commands
and return the output to the browser. As with directory traversal, the web server
should normally be able to prevent commands from operating outside of the server's
directory root and to prevent commands from running with any other privilege level
than the web "guest" user (who is normally granted only very restricted privileges).
A successful command injection attack would find some way of circumventing this
security (or find a web server that is not properly configured).
55
Exploit Techniques used in Server-side Request Forgery
• Reconnaissance—a response may contain metadata describing the type and
configuration of internal servers. SSRF can also be used to port scan within the
internal network.
• Credential stealing—a response may contain an API key that the internal servers use
between themselves.
• Unauthorized requests—the server-initiated request might change data or access a
service in an unauthorized way.
• Protocol smuggling—despite initially being carried over HTTP, the SSRF might target
an internal SMTP or FTP server. That server may be configured in a "best effort"
way, strip the HTTP header, and do its best to return the response to the SMTP or
FTP request.
56
Secure coding Frameworks
```
OWASPSoftware Assurance Maturity Model (owasp.org/www-project-samm) and Security
Knowledge Framework (owasp.org/www-project-security-knowledge-framework).
```
OWASP also collates descriptions of specific vulnerabilities, exploits, and mitigation
techniques, such as the OWASP Top 10 (owasp.org/www-project-top-ten).
57
Important coding practices
input validation, output encoding,
| and error handling
58
Input validation
Input validation
•User-generated data typed/entered via form controls
•Passed by another program (URL or HTTP header)
•Document and test all types of user/API input
A primary vector for attacking applications is to exploit faulty input validation. Input
could include user data entered into a form or URL passed by another application as
a URL or HTTP header. Malicious input could be crafted to perform an overflow attack
or some type of script or SQL injection attack.
To mitigate this risk, all input methods
should be documented with a view to reducing the potential attack surface exposed by
the application. There must be routines to check user input, and anything that does not
conform to what is required must be rejected.
59
Normalization and Output Encoding
Normalization and output encoding
•Strip illegal characters and substrings and use a predictable format and character set for the context in which the output is used
•Check all data being passed as output
•Differences between character sets and encoding methods
60
Normalization
Where an application accepts string input, the input should be subjected to
normalization procedures before being accepted.
Normalization means that a string
is stripped of illegal characters or substrings and converted to the accepted character
set. This ensures that the string is in a format that can be processed correctly by the
input validation routines.
61
Output Encoding
When user-generated strings are passed through different contexts in a web
application—between HTTP, JavaScript, PHP, and SQL for instance—each with potentially different canonicalization schemes, it is extremely difficult to ensure that
characters that would facilitate script injection by XSS have been rendered safe.
**Output encoding means that the string is re-encoded safely for the context in whichit is being used. For example, a web form might perform input validation at the client,but when it reaches the server, a PHP function performs output encoding before
composing an SQL statement. Similarly, when a string is delivered from a database
using SQL, a JavaScript function would perform output encoding to render the string
using safe HTML entities
62
Server-side versus Client-side Validation
*Relying on client-side validation only is poor
programming practice.
These bullet points describe it wll
Client-side execution
•Code is run by the browser
•Document Object Model (DOM) scripting
•Might send a request to the server, but the request is constructed by the client
Server-side execution
•Code is run by the server
Client-side input validation
•Code is not running in a fully trusted environment
Server-side input validation
•Might require complex transactions, slowing down process
Both used together
63
Secure cookies - Some of the key
| parameters for the SetCookie header
* Avoid using persistent cookies for session authentication
* Set the Secure attribute
* Set the HttpOnlyattribute
* Use the SameSiteattribute
• Avoid using persistent cookies for session authentication. Always use a new cookie
when the user reauthenticates.
• Set the Secure attribute to prevent a cookie being sent over unencrypted HTTP.
• Set the HttpOnly attribute to make the cookie inaccessible to document object
model/client-side scripting.
• Use the SameSite attribute to control from where a cookie may be sent, mitigating
request forgery attacks.
64
Response Headers
A number of security options can be set in the response header returned by the server to the client
* HTTP Strict Transport Security (HSTS)
* Content Security Policy (CSP)
* Cache-Control
• HTTP Strict Transport Security (HSTS)—forces browser to connect using HTTPS only,
mitigating downgrade attacks, such as SSL stripping.
• Content Security Policy (CSP)—mitigates clickjacking, script injection, and other
client-side attacks. Note that X-Frame-Options and X-XSS-Protection providemitigation for older browser versions, but are now deprecated in favor of CSP.
• Cache-Control—sets whether the browser can cache responses. Preventing caching
of data protects confidential and personal information where the client device might
be shared by multiple users.
65
Data exposure
Data exposure
•Allowing privileged data to be read without authorization
•Weak authentication/session management
•Lack of encryption
Data exposure is a fault that allows privileged information (such as a token, password,
or personal data) to be read without being subject to the appropriate access controls.
Applications must only transmit such data between authenticated hosts, using
cryptography to protect the session. When incorporating encryption in your code, it's
important to use encryption algorithms and techniques that are known to be strong,
rather than creating your own.
66
Error handling
* Structured exception handler (SEH)
* Prevent use of error conditions for arbitrary code/injection
* Prevent display of default messages (don't show too much inforaion in the error)
(For the second bullet) Some handlers will deal with anticipated errors and exceptions; there should also be
a catchall handler that will deal with the unexpected. The main goal must be for the
application not to fail in a way that allows the attacker to execute code or perform
some sort of injection attack. One infamous example of a poorly written exception
handler is the Apple GoTo bug (nakedsecurity.sophos.com/2014/02/24/anatomy-of-agoto-
fail-apples-ssl-bug-explained-plus-an-unofficial-patch).
67
structured exception handler (SEH)
An error or exception could be caused by invalid user input, a loss of network connectivity, another server or process failing, and so on. Ideally, the
programmer will have written a structured exception handler (SEH) to dictate what
the application should then do. Each procedure can have multiple exception handlers.
68
Memory management
* Use of unsecure functions
* Input validation and overflow protection
Many arbitrary code attacks depend on the target application having faulty memory
management procedures. This allows the attacker to execute his or her own code in
the space marked out by the target application. There are known unsecure practices
for memory management that should be avoided and checks for processing untrusted
input, such as strings, to ensure that it cannot overwrite areas of memory.
69
Secure code storage
Developing code to perform some function is hard work, so developers will often
look to see if someone else has done that work already. A program may make use of
existing code in the following ways:
• Code reuse—using a block of code from elsewhere in the same application or from
another application to perform a different function (or perform the same function
in a different context). The risk here is that the copy and paste approach causes
the developer to overlook potential vulnerabilities (perhaps the function's input
parameters are no longer validated in the new context).
• Third-party library—using a binary package (such as a dynamic link library) that
implements some sort of standard functionality, such as establishing a network
connection or performing cryptography. Each library must be monitored for
vulnerabilities and patched promptly.
• Software development kit (SDK)—using sample code or libraries of pre-built
functions from the programming environment used to create the software or
interact with a third party API. As with other third party libraries or code, it is
imperative to monitor for vulnerabilities.
• Stored procedures—using a pre-built function to perform a database query.
A stored procedure is a part of a database that executes a custom query. The
procedure is supplied an input by the calling program and returns a pre-defined
output for matched records. This can provide a more secure means of querying the
database. Any stored procedures that are part of the database but not required by
the application should be disabled.
70
Code reuse
• Code reuse—using a block of code from elsewhere in the same application or from
another application to perform a different function (or perform the same function
in a different context). The risk here is that the copy and paste approach causes
71
Software development kit
• Software development kit (SDK)—using sample code or libraries of pre-built
functions from the programming environment used to create the software or
interact with a third party API. As with other third party libraries or code, it is
imperative to monitor for vulnerabilities.
72
Third party library
• Third-party library—using a binary package (such as a dynamic link library (DLL)) that
implements some sort of standard functionality, such as establishing a network
connection or performing cryptography. Each library must be monitored for
vulnerabilities and patched promptly.
73
Stored procedure
• Stored procedures—using a pre-built function to perform a database query.
A stored procedure is a part of a database that executes a custom query. The
procedure is supplied an input by the calling program and returns a pre-defined
output for matched records. This can provide a more secure means of querying the
database. Any stored procedures that are part of the database but not required by
the application should be disabled.
74
Unreachable and dead code
Unreachable and dead code
•Code that cannot be executed or does not affect program flow
- should be removed. possiblity it can be used in malicious ways
Unreachable code is a part of application source code that can never be executed. For
example, there may be a routine within a logic statement (If ... Then) that can never
be called because the conditions that would call it can never be met. Dead code is
executed but has no effect on the program flow. For example, there may be code to
perform a calculation, but the result is never stored as a variable or used to evaluate
a condition.
This type of code may be introduced through carelessly reused code, or when a block
of code is rewritten or changed. Unreachable and dead code should be removed
from the application to forestall the possibility that it could be misused in some way.
The presence of unreachable/dead code can indicate that the application is not being
well maintained.
75
Obfuscation/Camouflage of code
Obfuscation/camouflage
•Disguise nature of code
•Inhibit reverse engineering
It is important that code be well-documented, to assist the efforts of multiple
programmers working on the same project. Well-documented code is also easier to
analyze, however, which may assist the development of attacks. Code can be made
difficult to analyze by using an obfuscator, which is software that randomizes the
names of variables, constants, functions, and procedures, removes comments and white space, and performs other operations to make the compiled code physicallyand mentally difficult to read and follow. This sort of technique might be used to
make reverse engineering an application more difficult and as a way of disguising
malware code.
76
Static Code Analysis
Static/source code analysis
•Submit code for analysis by automated software
Static code analysis (or source code analysis) is performed against the application
code before it is packaged as an executable process. The analysis software must support the programming language used by the source code. The software will scan the source code for signatures of known issues, such as OWASP Top 10 Most Critical
Web Application Security Risks or injection vulnerabilities generally. NIST maintains a
list of source code analyzers and their key features
77
Manual code review
Manual code review
| •Human analysis of source code
78
Dynamic Code Analysis
* Run application in a staging environment for testing
* Fuzzing and stress testing
* Application UI
* Protocol
* File format
79
Fuzzing
Fuzzing is a means of testing that an application's input validation routines work
well. Fuzzing means that the test or vulnerability scanner generates large amounts
of deliberately invalid and/or random input and records the responses made by
the application. This is a form of "stress testing" that can reveal how robust the
application is. There are generally three types of fuzzers, representing different ways of
injecting manipulated input into the application:
• Application UI—identify input streams accepted by the application, such as input
boxes, command line switches, or import/export functions.
• Protocol—transmit manipulated packets to the application, perhaps using
unexpected values in the headers or payload.
• File format—attempt to open files whose format has been manipulated, perhaps
manipulating specific features of the file.
80
Types of fuzzers
• Application UI—identify input streams accepted by the application, such as input
boxes, command line switches, or import/export functions.
• Protocol—transmit manipulated packets to the application, perhaps using
unexpected values in the headers or payload.
• File format—attempt to open files whose format has been manipulated, perhaps
manipulating specific features of the file.
81
scripting
Automation of activity through programs and scripts
82
Basic elements of a script
* Parameters
* Branching and looping statements
* Validation and error handlers
* Unit tests
• Parameters that the script takes as input data (passed to the script as arguments).
• Branching and looping statements that can alter the flow of execution based on
logic conditions.
• Validation and error handlers to check inputs and ensure robust execution.
• Unit tests to ensure that the script returns the expected outputs, given the
expected inputs.
83
Popular scripting languages
PowerShell (docs.microsoft.
com/en-us/powershell/scripting/overview?view=powershell-7), Python (python.org),
JavaScript (w3schools.com/js), Ruby (ruby-lang.org/en), and Go (golang.org).
Scripting
will also make use of domain-specific languages, such as SQL, XML parsing, regex, and
orchestration tools.
84
python script environment
I didn't spend time on this. Didn't ujnderstand
85
PowerShell Script Environment
I also didn't spend time on this
86
Execution Control
Execution control is the process of determining what additional software or scripts
may be installed or run on a host beyond its baseline.
87
Execution control (block lists)
Execution control can be implemented as either an allow list or a block list.
* Allow lists and block lists
* Allow list control means that nothing can run if it is not on the approved list
* Block list control means that anything not on the prohibited list can run
88
Code signing (execution control)
Code signing is the principal means of proving the authenticity and integrity of code
(an executable or a script). The developer creates a cryptographic hash of the file then
signs the hash using his or her private key. The program is shipped with a copy of the
developer's code signing certificate, which contains a public key that the destination
computer uses to read and verify the signature. The OS then prompts the user to
choose whether to accept the signature and run the program.
89
OS-based Execution Control
Execution control is often enforced using a third-party security product, but there are
some built-in Windows features that can perform the task:
•Software Restriction Policies (SRP)
•AppLocker
•Windows Defender Application Control (WDAC)
•SELinux
•AppArmor
• Software Restriction Policies (SRP)—available for most versions and editions of
Windows, SRP can be configured as group policy objects (GPOs) to passlist file
system locations from which executables and scripts can launch. Rules can also be
configured by publisher signature or by file hash. There is also support for creating
blocklist-based rules.
• AppLocker—improves configuration options and default usage of SRP. Notably
AppLocker policies can be applied to user and group accounts rather than just
computer accounts. However, AppLocker GPOs can only be configured for
Enterprise and Ultimate editions of Windows 7 and later.
• Windows Defender Application Control (WDAC)—formerly Device Guard, this can
be used to create Code Integrity (CI) policies, which can be used on their own or
in conjunction with AppLocker. CI policies apply to the computer and affect all
users. CI policies can be based on version-aware and publisher digital signatures,
as well as image hashes and/or file paths. WDAC is a useful option for preventing
administrator accounts from disabling execution control options (docs.microsoft.
com/en-us/windows/security/threat-protection/windows-defender-applicationcontrol/
windows-defender-application-control). WDAC is principally configured
using XML policy statements and PowerShell.
90
Malicious Code Indicators
As with buffer overflow, indicators of malicious code execution are either caught by
endpoint protection software or discovered after the fact in logs of how the malware
interacted with the network, file system, and registry. If you are performing threat
hunting or observing malware in a sandbox, it is helpful to consider the main types of
malicious activity:
* Shellcode
* Creates a process or injects a DLL
* Credential dumping
* Dumps credentials from lsass.exe
* Lateral movement/insider attack
* Remote execution
* Persistence
* Registry autorun keys
* Services/scheduled tasks
* Windows Management Instrumentation (WMI) event subscriptions
91
Shell code (malicious code inidicator)
* Shellcode
* Creates a process or injects a DLL
```
Shellcode—this is a minimal program designed to exploit a buffer overflow or
similar vulnerability to gain privileges, or to drop a backdoor on the host if run as
a Trojan (attack.mitre.org/tactics/TA0002). Having gained a foothold, this type of
attack will be followed by some type of network connection to download additional
tools.
```
92
Malicious Code Indicators
As with buffer overflow, indicators of malicious code execution are either caught by
endpoint protection software or discovered after the fact in logs of how the malware
interacted with the network, file system, and registry. If you are performing threat
hunting or observing malware in a sandbox, it is helpful to consider the main types of
malicious activity:
* Shellcode
* Creates a process or injects a DLL
* Credential dumping
* Dumps credentials from lsass.exe
* Lateral movement/insider attack
* Remote execution
* Persistence
* Registry autorun keys
* Services/scheduled tasks
* Windows Management Instrumentation (WMI) event subscriptions
93
•Credential dumping
* Credential dumping
* Dumps credentials from lsass.exe
```
Credential dumping—the malware might try to access the credentials file (SAM on
a local Windows workstation) or sniff credentials held in memory by the lsass.exe
system process (attack.mitre.org/tactics/TA0006).
```
94
•Lateral movement/insider attack
* Lateral movement/insider attack
* Remote execution
Lateral movement/insider attack—the general procedure is to use the foothold
to execute a process remotely, using a tool such as psexec (docs.microsoft.com/
en-us/sysinternals/downloads/psexec) or PowerShell (attack.mitre.org/tactics/
TA0008). The attacker might be seeking data assets or may try to widen access
by changing the system security configuration, such as opening a firewall port or
creating an account. If the attacker has compromised an account, these commands
can blend in with ordinary network operations, though they could be anomalous
behavior for that account.
95
Persistence
* Persistence
* Registry autorun keys
* Services/scheduled tasks
* Windows Management Instrumentation (WMI) event subscriptions
```
Persistence—this is a mechanism that the threat actor's backdoor is restarted if the
host reboots or the user logs off (attack.mitre.org/tactics/TA0003). Typical methods
are to use AutoRun keys in the registry, adding a scheduled task, or using Windows
Management Instrumentation (WMI) event subscriptions.
```
96
PowerShell Malicious Indicators
powershell is another scripting langauge . i skipped this as well.
97
Bash and Python Malicious Indicators
i skipped this as well
98
Macros and Visual Basic for Applications (VBA)
* Macros record steps taken in office productivity application
* Macros are coded in a scripting language
* Virtual Basic for Applications (VBA)
* Office document macros
* JavaScript
* PDF document macros
99
Macros and Visual Basic for Applications (VBA)
* Macros record steps taken in office productivity application
* Macros are coded in a scripting language
* Virtual Basic for Applications (VBA)
* Office document macros
* JavaScript
* PDF document macros
100
Macros
document macro is a sequence of actions performed in the context of a word
processor, spreadsheet, or presentation file. While the user may be able to record macro steps using the GUI, ultimately macros are coded in a scripting language.
101
Visual Basic for Applications (VBA) vs javascript
Microsoft Office uses the Visual Basic for Applications (VBA) language, while PDF
documents use JavaScript. Microsoft Office document macros can be inspected
using ALT+F11.
102
Man-in-the-Browser Attack (MitB)
A man-in-the-browser (MitB) attack is a specific type of on-path attack where the web
browser is compromised. Depending on the level of privilege obtained, the attacker
may be able to inspect session cookies, certificates, and data, change browser settings,
perform redirection, and inject code.
103
How are MitB attacks done
Malicious plug-in/script/DLL
A MitB attack may be accomplished by installing malicious plug-ins or scripts or
intercepting calls between the browser process and DLLs
104
The Browser Exploitation Framework (BeEF)
The Browser Exploitation Framework (BeEF) is one wellknown MitB tool.
It is a browser penetration tool
105
Application Development, Deployment, and Automation
* DevSecOps and requirements for greater automation
* Automation - Completion of tasks without human intervention
* Automation facilitates better scalability and elasticity
* Scalability means that the costs involved in supplying the service to more users are linear
* Elasticity refers to the system's ability to handle changes on demand in real time
106
Devsecops and automation
A DevSecOps culture gives project teams a broad base of development, security,
and operations expertise and experience. This promotes an environment in which
security tasks make increased use of automation. Automation is the completion of
an administrative task without human intervention. Task automation steps may be
configurable through a GUI control panel, via a command line, or via an API called
by scripts. Tasks can be automated to provision resources, add accounts, assign
permissions, perform incident detection and response, and any number of other
network security tasks.
107
manual configuration
Manual configuration introduces a lot of scope for making errors. A
108
Scalability vs elasticiyh
* Scalability means that the costs involved in supplying the service to more users are linear
* Elasticity refers to the system's ability to handle changes on demand in real time
• Scalability means that the costs involved in supplying the service to more users are
linear. For example, if the number of users doubles in a scalable system, the costs to
maintain the same level of service would also double (or less than double). If costs
more than double, the system is less scalable.
• Elasticity refers to the system's ability to handle changes on demand in real time.
A system with high elasticity will not experience loss of service or performance if
demand suddenly doubles (or triples, or quadruples). Conversely, it may be important
for the system to be able to reduce costs when demand is low. Elasticity is a common
selling point for cloud services. Instead of running a cloud resource for 24 hours a day,
7 days a week, that resource can diminish in power or shut down completely when
demand for that resource is low. When demand picks up again, the resource will grow
in power to the level required. This results in cost-effective operations.
109
QA vs QC
Quality processes are how an organization tests a system to identify whether it complies
with a set of requirements and expectations. These requirements and expectations can
be driven by risk-based assessments, or they can be driven by internal and external
compliance factors, such as industry regulations and company-defined quality standards.
```
Quality control (QC) is the process of determining whether a system is free from defects or
deficiencies. QC procedures are themselves defined by a quality assurance (QA) process,
which analyzes what constitutes "quality" and how it can be measured and checked.
```
110
Environments
(Refer to the diagram on slide 46)
To meet the demands of the life cycle model and quality assurance, code is normally
passed through several different environments:
• Development
• Test/integration
• Staging
• Production
111
Development environment
the code will be hosted on a secure server. Each developer will check
out a portion of code for editing on his or her local machine. The local machine will
normally be configured with a sandbox for local testing. This ensures that whatever
other processes are being run locally do not interfere with or compromise the
application being developed.
112
Test integration environment
Test/integration—in this environment, code from multiple developers is merged
to a single master copy and subjected to basic unit and functional tests (either
automated or by human testers). These tests aim to ensure that the code builds
correctly and fulfills the functions required by the design.
113
Staging environment
Staging—this is a mirror of the production environment but may use test or sample
data and will have additional access controls so that it is only accessible to test
users. Testing at this stage will focus more on usability and performance.
114
Production environmen t
• Production—the application is released to end users.
115
Preserving environment integrity
Preserving environment integrity
•Sandboxing
•Secure baseline
•Integrity measurement
It is important to be able to validate the integrity of each coding environment.
Compromise in any environment could lead to the release of compromised code.
• Sandboxing—each development environment should be segmented from the
others. No processes should be able to connect to anything outside the sandbox.
Only the minimum tools and services necessary to perform code development and
testing should be allowed in each sandbox.
• Secure configuration baseline—each development environment should be built to
the same specification, possibly using automated provisioning.
• Integrity measurement—this process determines whether the development
environment varies from the configuration baseline. Perhaps a developer added an
unauthorized tool to solve some programming issue. Integrity measurement may
be performed by scanning for unsigned files or files that do not otherwise match the
baseline. The Linux dif f command can be used to compare file structures
(linux.die.net/man/1/diff).
116
Provisioning, Deprovisioning, and Version Control
Provisioning is the process of deploying an application to the target environment
•Installer/setup package
•Instance (VM with OS and application)
Deprovisioning is the process of removing an application from packages or instances
```
Version Control
•Customer version ID
•Developer build ID
•Source code version control
•Code commits and backups
```
117
Provisioning
Provisioning is the process of deploying an application to the target environment
•Installer/setup package
•Instance (VM with OS and application)
Provisioning is the process of deploying an application to the target environment,
such as enterprise desktops, mobile devices, or cloud infrastructure. ...**** The provisioning process must account for changes to any of
these applications so that packages or instances are updated with the latest version.
118
Deprovisioning
Deprovisioning is the process of removing an application from packages or instances
As well as removing the application itself, it is also important tomake appropriate environment changes to remove any configurations (such as open
firewall ports) that were made just to support that application.
119
Version control
```
Version Control
•Customer version ID
•Developer build ID
•Source code version control
•Code commits and backups
```
Version control is an ID system for each iteration of a software product. Most version
control numbers represent both the version, as made known to the customer or end
user, and internal build numbers for use in the development process. Version control
supports the change management process for software development projects. Most
software development environments use a build server to maintain a repository of
previous versions of the source code. When a developer commits new or changed
code to the repository, the new source code is tagged with an updated version number
and the old version archived. This allows changes to be rolled back if a problem is
discovered.
120
Automation/Scripting Release Paradigms
* Waterfall versus Agile SDLCs
* Continuous integration
* Commit updates often
* Reduce commit conflicts
* Continuous delivery
* Push updates to staging infrastructure
* Continuous deployment
* Push updated code to production
* Continuous monitoring and automated courses of action
* Continuous validation
121
Continuous integration
* Continuous integration
* Commit updates often
* Reduce commit conflicts
Continuous integration (CI) is the principle that developers should commit and test
updates often—every day or sometimes even more frequently. This is designed to
reduce the chances of two developers spending time on code changes that are later
found to conflict with one another. CI aims to detect and resolve these conflicts early,
as it is easier to diagnose one or two conflicts or build errors than it is to diagnose the
causes of tens of them. For effective CI, it is important to use an automated test suite
to validate each build quickly.
122
Continuous Delivery
* Continuous delivery
* Push updates to staging infrastructure
Where CI is about managing code in development, continuous delivery is about
testing all of the infrastructure that supports the app, including networking, database
functionality, client software, and so on.
123
Continuous Deployment
Where continuous delivery tests that an app version and its supporting infrastructure
are ready for production, continuous deployment is the separate process of actually
making changes to the production environment to support the new app version.
124
Continuous Monitoring and Automated Courses of Action
An automation solution will have a system of continuous monitoring to detect service
failures and security incidents. Continuous monitoring might use a locally installed
agent or heartbeat protocol or may involve checking availability remotely. As well as
monitoring the primary site, it is important to observe the failover components to
ensure that they are recovery ready.
You can also **automate the courses of action that
a monitoring system takes, like configuring an IPS to automatically block traffic that
it deems suspicious. This sort of capability is provided by security orchestration and
response (SOAR) management software.
125
Continuous Validation
```
An application model is a statement of the requirements driving the software
development project. The requirements model is tested using processes of verification
and validation (V&V):
```
• Verification is a compliance testing process to ensure that the product or system
meets its design goals.
• Validation is the process of determining whether the application is fit-for-purpose
(so for instance, its design goals meet the user requirements).
With the continuous paradigm, feedback from delivery and deployment must be
monitored and evaluated to ensure that the design goals continue to meet user and
security requirements. The monitoring and validation processes must also ensure that
there is no drift from the secure configuration baseline.
126
Software Diversity
* Runtime environment
* Compiled code
* Interpreted code
* Software diversity as obfuscation
* Security by diversity
* Avoid monocultures to make attacks harder to develop
127
compiled code vs interpreted code
An application's runtime environment will use one of two approaches for execution on
a host system:
• Compiled code is converted to binary machine language that can run independently
on the target OS.
• Interpreted code is packaged pretty much as is but is compiled line-by-line by an
interpreter, such as PowerShell or JavaScript. This offers a solution that is platform
independent because the interpreter resolves the differences between OS types
and versions.
128
•Software diversity as obfuscation
Software diversity can refer to obfuscation techniques to make code difficult to detect
as malicious. This is widely used by threat actors in the form of shellcode compilers
to avoid signature detection, such as the venerable Shikata Ga Nai (fireeye.com/blog/
threat-research/2019/10/shikata-ga-nai-encoder-still-going-strong.html). This can
be used as a defensive technique. Obfuscating API methods and automation code
makes it harder for a threat actor to reverse engineer and analyze the code to discover
weaknesses.
129
Security by diversity
Avoid monocultures to make attacks harder to develop
This works on the
principle that attacks are harder to develop against non-standard environments. A
monoculture environment, such as a Windows domain network, presents a fairly
predictable attack surface with plenty of commodity malware tools available to exploit
misconfigurations. Using a wide range of development tools and OS/application
vendors and versions can make attack strategies harder to research. As with security
by obscurity, this will not defeat a targeted attack, but it can partially mitigate risks
from less motivated threat actors, who will simply move to the next, easier target.
On the other hand, this sort of complexity will tend to lead to greater incidence of
configuration errors as technicians and developers struggle to master unfamiliar
technologies.
