web application Archives

boot2root, hacking, web application security

@Vulnhub – Solving #Cofveve

July 7, 2023July 14, 2023 thefluffy007

Another day, another challenge.

In this post we’re going to solve the Cofveve virtual machine.

Let’s get started

After downloading the virtual machine and starting it we see the following:

Using the netdiscover command we can find the IP that the virtual machine is using

Going back to our attacking machine (I’m using the parrot virtual machine).

Doing an nmap scan with the command – nmap -sV <IP address from netdiscover command>, we see the following

There are three ports that are open – ssh, and two http ports.

When http ports are opened the next step is to try to do a recursive brute force attacks to find hidden directories.

We’re going to use two programs – dirb and gobuster.

Doing the dirb of port 80, we get:

Using gobuster we see:

We see that both of the programs did not return anything.

Let’s try to the following programs with the 31337 port, let’s start

We see five files – a robots.txt, and four hidden files (start with .)

The robots.txt gives information about sites that should not be crawled by the internet. This is useful as it will give us files or directories (folders) to review to get more information.

Going to the robots.txt we see:

Hmm, there are three directories that are disallowed. Let’s try to go to them.

Let’s start with taxes. When navigating there we see:

We found the first flag!

Going to the second directory .bashrc we see

Hmm, it’s a file, let’s save it.

Going to the last directory of .profile we see

Another file to save.

Going back to either dirb or gobuster results we have one more directory, .ssh.

This is strange. The .ssh which is hidden should not be exposed on the internet. This folder has information about how to login into the system. Such information is a private key (which only the user should know) public key (which everyone knows), as well as other things.

Going to this folder we see:

We see three items, which look like additional files.

Let’s see if we can navigate to these files.

Navigating to the first item, id_rsa we see:

Another file, so let’s save it.

Let’s try the second file – authorized_keys. Going there we see:

Another file, let’s save it.

Finally, let’s go to the third item – id_rsa.pub

Now that we saved everything let’s go back to our virtual machine and open the files.

First, let’s open the id_rsa.pub file. This file is the public key that is part of a pair. The other pair is the private key. As the name suggests only the user should know their private key and not expose it to anyone else. The public key can be exposed to everyone.

Opening the file we see:

We see a ssh-rsa. RSA is a cryptographic algorithm. Looking at the end of the file we see a valid user – simon@covfefe. We need to save this user as we will need it later.

Opening the id_rsa file we see:

This file is the private key to log into the SSH server as Simon! This is bad, as I said before this file should NOT be exposed as Simon private key should only be known by him only.

Opening the authorized_keys file it has the same content as the id_pub

How can we use this information?

We know a user (simon@covfefe) and a private key.

Well we can log into the ssh server.

Let’s start.

We can use the command ssh -i id_rsa simon@covfefe

Let’s break this down.

We’re logging into the SSH server, specifying a file id_rsa (Simon’s private key) and the user of Simon

We get the following output:

Uh oh – we received an error:

The private key is too open. We need to change the make it less accessible. To do this we’re going to change the permissions from 644 to 600. What this will do is give access to the owner in this case parrot (which is us).

To do this we will use the command chmod 600 id_rsa

Trying to log in again we have the following:

We need a passphrase… which we don’t have. How do we get this?

Doing a good ol’ Google search of cracking passphrase for id_rsa we see the following link

We see there’s a command ssh2john which can be used to crack the passphrase. Let’s do it!

First, we located where the ssh2john command lives in the file system. Next, we’re going to create a hash using ssh2john. We’re going to use this for the next step.

Next, we’re going to send our hash to john which will be used to crack it. We’re going to use the wordlist rockyou.txt which is a common wordlist used to crack passwords. Doing so, we found our passphrase – starwars.

Running our SSH command again, we enter the passphrase of starwars and we’re in the system!

Doing a long listing and showing all of the files (ls -la) we see the files we found before when brute forcing the directories. Let’s look at the .bash_history. This file is good to review as it will let you know commands that were executed on the machine.

Opening this file we see a read_message and then exit. What is read_message? Is this a program?

Executing the read_message we get a prompt. Let’s enter the name Simon. We received a message stating this is is a private messaging system and the source code is in the root directory.

Navigating to the root directory and doing a long listing with all the files (ls -la) we see there’s a read_message.c file, and flag.txt!

Opening the flag.txt file we see a permission denied :-(. Looking at the long listing again this file (flag.txt) can only be accessed the owner, which in this case is root (column 4). I am the user Simon, so I can’t view the file.

Opening the read_message.c file, we see source code, and… the second flag!

And it’s giving us a hint – we need to review the source code.

Looking at the source code we have a buffer (buf) that is holding 20 characters and is executing another file program which is pointing to /usr/local/sbin/message. Whenever we see buf we need to think of buffer overflows.

Buffer overflows are a vulnerability where you overflow the input to access other parts of the computer system. In this case, since we have a holding space of 20 characters – we’re going to overload the buffer with characters OVER 20 characters. Also we’re going to try to change the shell to /bin/sh <— bourne shell. We’re going to change the shell to escalate the user. Changing from Simon to root. We need to be root to open the flag.txt file.

Let’s try it.

Running the commands id and whoami we see we’re root!

Now let’s open the flag.txt and see what’s in the file.

We solved the challenge!

boot2root, hacking, web application security

@Vulnhub – Solving Hemisphere – Gemini #boot2root

June 30, 2023June 30, 2023 thefluffy007

Another day, another challenge.

In this post, we’re going to solve the Hemisphere boot2root from Vulnhub.

Let’s get started.

When we start the Hemisphere – Gemini machine we see the following screen:

OK, we’re prompted with a login screen.

For most boot2root’s we need to find user and root.txt on the box.

Next, on our attacker machine (I’m using parrot security), I am going to type the command netdiscover.

Netdiscover will ping your network with active IPs. From there you can figure out which IP is being used for the virtual machine.

After finding the IP address, let’s open a terminal and type nmap -sV <IP address from netdiscover>. In my case, it’s going to be nmap -sV 192.168.1.132. Doing this we have the following output:

We have 5 ports open.

FTP

SSH

HTTP

And ports 139 and 445.

What do the above two ports belong to?

Well these two ports are for Samba SMB. SMB allows computers to talk with each other. Most times when SMB is enabled, it’s SMB 1.0 which is extremely insecure. So how do we exploit it?

Well, there’s an application enum4linux which will enumerate all of the SMB shares. To do this we’ll use the command enum4linux -a <IP address from netdiscover>. In my case it will be enum4linux -a <192.168.1.132>

Doing this we have:

As you can see we have A LOT of output from enumerating the different shares from SMB.

Looking through the input we see there’s a username: William. We need to save this as we’ll use it later.

Now reviewing the nmap scan again – we see that port 80 or HTTP is open.

Next step, is to enumerate/brute force to see if we can find hidden directories.

Let’s use our two favorite applications – dirb and gobuster.

We have an assortment of files/directories to review.

robots.txt – a helpful file that tells web crawlers to exclude directories to be crawled/exposed on the internet.

Going to the robots.txt file we see:

There are three directories. Let’s see if we can find any goodies!

Going to the secret folder we see:

Hmm… there’s nothing there.

Let’s try admin.

Nothing there either.

Let’s try the last folder – lol

Nothing there.

So the robots.txt was a red herring. It’s a way to knock us off our game as there’s nothing there.

Going back to dirb/gobuster we see there are two folders to review.

Let’s try assets and see what we get.

Going to the assets folder we see:

Hmm – nothing really there. It’s styling for our website.

Let’s try the second folder – images.

Going to this folder we see:

Nothing of importance. This directory is a space for all of the pictures for our site.

Speaking of our site. Let’s go to the index.html file

Going to this page, we see:

Looking through the page we don’t see anything of value.

So now – we’ve enumerated all of the hidden folders and really haven’t found anything. We know we have a user of William, but how do we log in?

We need to enumerate/brute force the directories again.

How do we do this? Change our wordlist.

Going back to gobuster – we’re going to use the dirbuster directory-list-2.3-medium.txt which has more directories to check.

Entering the updated command we see there’s a new folder – portal. Let’s go to that page and see what we get.

Entering this into the URL we see:

Another page. It’s written in Spanish. We see there are three links at the top. Let’s click on the second (Sobre Nosotros) and see what we get.

Nothing to render/view.

But there is something interesting. In the address bar we have a view parameter. Which is pointing to the about-us.html page. Whenever we see a parameter field we should try to do a Local File Inclusion (LFI).

LFI is a vulnerability where you can access the files in the underlying filesystem. Let’s try to access the /etc/passwd file.

In Linux, the /etc/passwd file holds all the users. Let’s try it.

Let’s break this down.

We have five ../. What is this? Well we’re using this (../) to navigate one folder up. Meaning we want to access the parent directory of our current directory. Finally, when we’re at the topmost area of the file system. We’re telling the application to go to /etc/passwd.

Doing this the webpage displays the /etc/passwd file which reveals all of the users!

When you look in the file we see that there is a user named William. That let’s us know our enumeration from the enum4linux command worked correctly.

Now we have the user William, and we can do LFI on this application. What’s our next step.

Well we know that port 22 or SSH is open. We also know there’s a public and private key for all the users to log into the server.

We have a user of William. So we know he’s a valid user. How do we find William’s public and private key?

These keys will be in his home folder.

In Linux, every user has a home folder which allows the user to save files that can only be accessed by them.

With the public and private keys for SSH, we know it’s stored in a hidden directory titled – .ssh and saved in the id_rsa file.

id_rsa is the private key file

id_rsa.pub is the public key file

We don’t want to access the public key file as it’s accessible to EVERYONE. Hence the name.

We want the private key (id_rsa).

Let’s see if we can access this folder through LFI.

Success! We’re able to access the private key. We’re going to need this to log into the SSH server.

First we need to save this key.

To do this, right-click on the file and highlight the text, copy the text.

Open your favorite word browser, and save the contents as id_rsa (the name is important!). Also make sure you know where you saved this file!

After saving the file – let’s do a ls (listing) in the terminal

We see our id_rsa file.

Now let’s try to log in the ssh server.

Enter the command ssh -i id_rsa william@<IP address from netdiscover>. In my case the command will be ssh -i id_rsa william@192.168.1.132.

Uh-oh. We can’t log in as the permissions are too permissive or too open.

Press Control-C to get out of the prompt, we’re going to change the permissions of the id_rsa file.

To do this we’re going to enter the command chmod 600 id_rsa.

After entering this command, do a listing (ls) to view the permissions.

For the id_rsa file we see there is rw in the 2nd and 3rd position. These positions belong to the owner. In this case the owner would be parrot (column 4 in the above screenshot).

Now let’s try to log in again.

Success! We’re in the SSH server.

Now let’s do a listing to see what we see

We have the user.txt file. Let’s open it.

Enter the command cat user.txt

We have the user flag. Now to find the root.txt.

How are we going to do this?

Well there’s a few things we can do.

Since this is a Linux system, let’s enter the command sudo -l

This command will see if a user can elevate (or escalate) their privileges without being the root user.

Entering the command we see this program doesn’t exist.

OK, so we can’t use that.

Remember how we had to change the permissions to gain access to the server?

Well I wonder if we can check files that are overly permissive and use one of those files to elevate our privileges.

What command would we use?

The command we enter is find / -perm -u=s -type f 2>/dev/null

Let’s break this down

We’re using the find command

the / specifies we want to start at the top of the file system

-perm u=s specifies we want to find users that have the sticky bit on.

What is the sticky bit? Sticky bit in Linux specifies we can run an application as the owner of the file.

We want to access the root.txt, so we know that the superuser root is probably the only user who can access this file.

-type f = specifies we want files

2>/dev/null specifies that any errors go to the /dev/null file.

Entering this command we see:

Most of these files are always there but we have a file that shouldn’t be there /etc/passwd.

Why shouldn’t this file in this list? Well the /etc/passwd file holds all the users in the operating system.

This file is overly permissive. We see we have read, write, and execute.

So what do we do? Add another root user.

How do we do this?

First we need to create a password. We’re going to use the openssl command to create a suitable password for the /etc/passwd file. I’m going to select a password of password. See the screenshot below.

Next, we’re going to add our new user in the /etc/passwd file. How are we going to do this?

We’re going to use the echo command.

Let’s break this line down.

echo is a command in Linux. We’re going to echo what is in quotation marks.

We’re going to create a user of test

Next, we enter the password we created with openssl

Next, we have the numbers of 0 for userid and groupid. 0 represent root.

Next, we have the name of root

Next, we specify the home folder for root which is /root

Next, we have the shell for this user which is the bourne again shell (/bin/bash)

Finally, we’re appending this input to the /etc/passwd

Pressing Enter we are prompt back to the command line

Using the command su (switch user)

and enter our new user of test and password of password

We see that the login was successful.

Entering the whoami command we see that our user is now root. Which means our privilege escalation worked!

Now that we’re root let’s navigate to the /root folder and do a listing

Cool, we see the root.txt file.

Opening this file we see:

Success! We found the root flag!

*****If you’ve read to the end – I wanted to add that I am now on @buymeacoffee! If you like the above content and want more of it. Please support: https://www.buymeacoffee.com/thefluffy007

boot2root, hacking, web application security

@RealTryHackMe – RootMe

June 16, 2023April 9, 2023 thefluffy007

Another day, another challenge.

In today’s post we’re going to solve the RootMe room in TryHackMe.

Let’s get started.

Going to the room let’s deploy the machine. This will give us the IP target IP address.

Note: Make sure you’re logged into TryHackMe’s network through OVPN.

After the deployment is complete, we see the following.

Note: Your IP will be different.

Let’s answer the questions

First question:

We can press the completed button as we have successfully deployed our machine.

Second question:

We need to see how many ports are open. Let’s use the application – nmap. Nmap or Network mapper is used to find open/active services on a server.

We’re going to use the -sV (all) command to get find the version numbers of the active services.

Let’s open a terminal and enter the below command.

The complete command is nmap -sV <IP address from deployment> in my case the command will be nmap -sV 10.10.239.135

A screenshot below shows:

2 ports are open. 22 and 80. Corresponding to SSH and HTTP.

So the answer is two.

Entering this into the text box and pressing Enter, we see that is the right answer.

Moving on to question 3.

Going back to our screenshot above of our nmap results we see the version is Apache 2.4.29. Entering 2.4.29 into the text box and pressing Submit we see that’s the correct answer.

Now to question 4.

Going back to our nmap scan we see that for port 22 the service is SSH (case matters!)

Entering this into the text box and pressing Submit we see that is the correct answer.

Question 5

We need to find directories on the web server using the GoBuster Tool.

First we need to figure out – what is the web server?

Going back to our nmap results, the web server is port 80 or HTTP. HTTP stands for Hyper Text Transport Protocol. You’re using the HTTP protocol right now by viewing this blog post. When accessing the internet, and typing in http is invoking the above protocol.

Now that we know that the web server is port 80 or HTTP. How do we access the GoBuster tool?

Well if you’re using the Parrot Security or Kali virtual machine (or attack box on TryHackMe) all you need to do is open a terminal and type gobuster

To access the different directories we’re going to enter the following command gobuster dir -u http://<ip address from deployment> -w /usr/share/wordlists/dirb/common.txt. In my case the command will be gobuster dir -u http://10.10.239.135 -w /usr/share/wordlists/dirb/common.txt.

Let’s break this command down

We enter gobuster to invoke the program

dir to specify we want to brute force or view all directories

-u http://<ip address from deployment> – specifies we want to view all directories from this website

-w /usr/share/wordlists/dirb/common.txt – specifies we want to use this file as our wordlist to find the hidden directories.

Entering the above command into a terminal and pressing enter we have the following:

Let’s explain the numbers next to the results

The numbers are HTTP codes and can tell you a lot of information

Let’s break give a brief breakdown of the different codes

HTTP Code 200 – OK – meaning the website rendered correctly

HTTP Code 301/302 – Redirection – meaning the website will redirect to another page. Pages with this number you should delve deeper into by visiting the actual page

HTTP Code 401 – Unauthorized – meaning you’re not authenticated (or logged in) to view the page

HTTP Code 403 – Forbidden – meaning you’re not authorized to view the page

From the screenshot above we see a few 301’s (redirects) that we should check out.

Question 5 is a gimme/free question as it says no answer is needed, so press Submit to collect the points.

Now, on to question 6

We need to find the hidden directory.

Looking at our gobuster results and what we know about HTTP codes, the 302 are the results we should focus on. Looking at the results and the number of characters the question is looking for – we can surmise the answer is panel.

Entering /panel/ into the text box and pressing Enter we see the assumption was correct.

We can also double check this by opening a web browser and entering the following http://<IP address from deployment>/panel

Doing this on my machine – I see the following

Again – just because we see a redirect doesn’t mean the page will not render. Always check 301 and 302 HTTP codes!

Now on to question 7.

First we’re in a new section of the challenge titled – getting a shell. This is where things get interesting…

What is a shell? Well there are two types of shells

Bind shell – need to have a listener running on the target machine. How bind shells work is the attacker connect to the listener on the target machine to gain a remote shell. This is a two step process. Also, the listener has to be on the target machine. If it’s not this type of shell will not work.

An visual example of a bind shell:

Note: The -e /bin/sh specifies to send a Bourne shell to the attacker’s box

Reverse shell – listener is on the attacker machine, and the target connects to the listener on the attacker machine with a shell. This is the best option as it removes having a listener on the target machine. Also reverse shells allows to be done on popular ports such as HTTP

In our case we’re going to use a reverse shell.

How are we going to do this?

We know that we have a secret directory named – panel. When we went to this page we also noticed that we can upload files.

Let’s try to upload a php file that has a reverse shell attached to it.

Going to this site, we see a file of PHP code.

Copy the code and open a text editor and paste the results.

Scrolling down we see a few lines that need to be changed.

I’m going to explain this below.

The two lines we need to change are our IP address and port.

The IP address is going to point to our IP from our TryHackMe account. You can find the address at the top of the page in green. My address is 10.13.2.231. This will be considered the Attacker’s box.

The port we can make anything we want. In this case let’s make it 1234

Save the file and exit the editor.

Now doing a listing (ls) we see the following

We need to change the permission to have the file execute. To do this we enter the command chmod +x test.php

Now let’s go to the panel directory.

Opening a browser and entering http://<IP address from deployment>/panel, we see the following. Let’s try to update our test.php file.

After pressing upload we see there’s an error. PHP files are not permitted.

How can we fix this? Well, let’s try changing the extension from PHP to PHP5.

Going back to the terminal let’s enter the command: cp test.php test.php5. This will create a new file named test.php5.

Doing a listing (ls -la) we see that the file is created.

Going back to the panel directory let’s browse and select test.php5

After pressing Upload we see that the file was uploaded successfully.

We see the file was uploaded, but how do we get to the file? Going back to to our gobuster results, we see there’s another 301 named uploads. Let’s try to navigate to this directory.

Opening another tab and entering http://<IP address from deployment>/uploads we see the following:

Our test file is here!

Now how do we connect to the target box?

First, we need to open a new terminal and enter nc -nvlp 1234

Let’s explain what’s happening:

nc – is a program named netcat. You can think of netcat as a swiss-army program that can do a lot of information. In our case, we’re going to use netcat to set up our listener on our machine.

nvlp – this is a series of parameters that do the following not resolve names, verbose printing, listen, on a specific port

1234 – is the port we’re going to listen on. **Make sure this matches the port inside your test.php5 file, otherwise the next steps will not work**

Going back to the tab with the uploads folder, click on the test.php5. You will notice the application is running and seems to hang. This is what we want.

Going back to our terminal where we set up the netcat listener, we have input! Our reverse shell worked successfully! We’re officially on the target machine!

We can prove this by entering the command whoami which will give us our current user. The current user is www-data which signifies the web user.

OK, we’re on the machine, but how do we find and open the user.txt file (we need this to answer the question). We need to find it on the file system.

Entering the command find / -name=user.txt 2>/dev/null

Let’s explain this command:

find – is the program we’re using

/ – specifies we want to start at the root

-name user.txt – specifies the file we want to find on the file system

2 >/dev/null – specifies if there are any errors – such as we access denied, send that output to /dev/null. In other words do not output it to the screen.

Entering this in the terminal we see the following:

The user.txt is at /var/www/user.txt

Navigating to the /var/www directory using the cd (change directory) command, we need to view the user.txt file. We’re going to do that with the cat (concatenate) command.

Doing this we see:

We found the answer!

Entering THM{y0u_g0t_a_sh3ll} into the text field we see it’s the correct answer.

Now on to question 8.

OK, we need to search SUID permissions to find a weird file.

First, we need to describe what is a SUID. SUID or a user sticky bit is a permission inside of Linux that allows an application to run as it’s root owner. This is good for system administrators when they want to run commands without switching users. However, there are times where these files are overly permissive or too open for anyone to run. With these files we can do something called privilege escalation which means we can upgrade our user from a regular user to an admin/super user.

How do we find files that have the sticky bit turned on in Linux?

Well we enter the command find / -perm -u=s -type f 2>/dev/null.

Let’s break this down

find – the program we’re using

/ – start at the root of the file system

-perm – specifies we’re looking at permissions

-u=s – specifies we’re looking for the SUID. u is user, and s specifies the sticky bit with execution turned on. If we didn’t want execution turned on we would use S (this wouldn’t help us as we need to execute the program)

2>/dev/null – specifies if there are any errors (such as permission denied) send it to /dev/null

Looking at the output, some of these files are standard. There is one file that looks suspect. The file is /usr/bin/python.

Entering this in the text box we see this is the correct answer.

On to question 9

We need to escalate our privileges to change from www-data to root.

From question 8, we see that /usr/bin/python is the weird file in question that shouldn’t have the SUID bit on. We’re going to use this file to escalate our privileges from www-data to root.

Going to this site and scrolling down we see a section to escalate our privileges using python. Let’s go back to the terminal and enter the command

Let’s break this down

/usr/bin/python – specifies we want to execute the python program

-c = execute the following command

‘import os; os.execl(“/bin/sh”, “sh”, “-p”)’ – specifies we want to import the os library. Then we’re going to execute another command execute command line (execl) with the following parameters:

/bin/sh – specifies we want ot use the Bourne shell

sh – we’re specifying the file or the shell

-p – specifies the command we want to use

This question is a gimme so we can click the completed button.

Now, on to the last question – question 10.

We need to find the root.txt file

After the above command and doing a whoami command we see that we’re root!

Now we need to read the root.txt file

Navigating to the /root folder and doing a listing (ls -la) we see the root.txt file!

Opening the root.txt file with the cat command, we see:

Entering the above THM{pr1v1l3g3_3sc4l4t1on} into the text box we see that’s the correct answer and we have solved all the challenges.

Like this content and want more? Well support me by Buying Me A Coffee. Link –> https://www.buymeacoffee.com/thefluffy007

boot2root, hacking, web application security

@RealTryHackMe – Bounty Hacker

June 9, 2023April 9, 2023 thefluffy007

Another day, another challenge.

In today’s post we’re going to solve the Bounty Hacker room in TryHackMe.

Let’s get started.

Going to the room and clicking the deploy/start machine, we see the following:

Your IP address will be different.

Let’s start answering the question.

The first question is to find open ports.

We’re going to enter the command: nmap -sV <deployed IP address> which in my case will be nmap -sV 10.10.126.62

Doing this we see:

We have three ports open. FTP, SSH, and HTTP.

Next question.

We need to see who wrote the task list.

With FTP depending on the configuration, you can access this server with a username of anonymous and any password.

Let’s see if this works.

It worked!

Now let’s do a listing to see what is on the server.

We have a locks.txt and a task.txt file

How do we download the files?

We can use the get command – get <file>

Let’s try it.

The files were downloaded successfully.

We can close the ftp server by entering the exit command.

Doing an cat (concatenate) to open the task.txt file we see:

We found the user – lin.

Let’s answer the next question.

What service can we use to brute force the text file?

Looking at the services opened, we already anonymously logged into the FTP server, so that’s not it.

Let’s see if SSH is the answer. It is!

Next question.

What is the user’s password? The user in this case is lin.

Well to brute force SSH we can use the program – Hydra.

We didn’t open the tasks.txt file.

Let’s open it.

Using the cat command cat locks.txt we see:

Hmm… this file seems like this is a file with passwords.

Going back to Hydra, doing this we can use the command hydra -l lin -P locks.txt <IP address> -t 4 ssh in my case it will be hydra -l lin -P locks.txt 10.10.126.62 -t 4 ssh

Let’s explain the command

Hydra – The program we’re going to use

-l lin – select the user we want to use (lin)

-P tasks.txt – selecting the password file we want

<IP address> – specifying the IP address we want to brute-force

-t 4 – the number of threads we want. In this case we say we want 4 threads. The bigger the threads, the faster hydra will perform

ssh – let’s us know we want to brute-force the ssh server

Doing this we get the following:

We found the password – RedDr4gonSynd1cat3

Now let’s login

Going back to our terminal let’s enter the command ssh lin@10.10.126.62

Let’s break this down

ssh – invoking we want to access the SSH server

lin@10.10.126.62 – the user at the server

We get the following:

We get the question of are we sure we want to connect – enter yes.

Next we need to enter the password. Copy the password from the Hydra output.

Doing that we see the above screenshot.

We are now in the SSH server!

Let’s answer the next question.

We need to find and open the user.txt file.

Doing a long listing to view everything ls -la we see:

We see the user.txt file!

Using the cat command to open the file it will be – cat user.txt

Now to the final question.

We need to find and open the root.txt file.

Going back to the terminal – we’re going to enter the command: find / -perm -u=s -type f 2>/dev/null

Let’s break it down

find – invoke the find command

/ – specifying we’re starting at the root file system

-perm = look for a specific permission

-u = s – specifies we want to find users (owners) with the sticky bit set. The sticky bit allows a user to execute the program as the owner. In this case we want to find sticky bits that can be executed as root.

-type f = we’re looking for files

2>/dev/null – we’re redirecting error messages from the standard output (the screen) to /dev/null.

Doing this we get the following:

The above files allows us to execute the program as root.

Most of these are standard, but the sudo command should not be there.

Why? The sudo allows to execute root commands for the specific command.

With the sudo command there’s also a file sudoers file that tells the users, and files that can run as root.

To figure this out, let’s enter the command sudo -l

We’re going to be prompted for the password which is: RedDr4gonSynd1cat3

Doing this we see:

We see that one file – /bin/tar can run as root.

Going to Google and typing in privilege escalation tar file

We see:

Clicking on the first link we see:

Scrolling down we see:

We see a section on Sudo!

Copying this command into our terminal and entering the whoami command we get:

We have successfully escalated our privileges to root!

Going to the root home directory and doing a long listing we see:

We see the root.txt file

Let’s open it with the cat command.

Doing this we see:

We have successfully solved the challenge!

hacking, owasp, web application security

Slides from Hacking OWASP Top 10 – Infinity Stones + Walkthrough at Blacks in Cybersecurity

February 8, 2021March 3, 2021 thefluffy007

On Friday February 5, 2021, I provided a training on teaching Application Security concepts using the OWASP Top 10.

The Open Web Application Security Project or OWASP is a non-profit organization whose mission is to make application security better. Members of OWASP meet every few years to create a top 10 list of the prevalent vulnerabilities in the industry. The last list was from 2017.

The structure of my training is the first part is to present the theoretical part – concepts and definitions. The last part of the training is a practical or application of the first part of the training (theoretical).

For the practical piece I used the website – BodgeIt Store. The BodgeIt Store is an insecure app, that should NOT be deployed in commercial servers. Many will say that the BodgeIt Store is a SUPER old insecure app (it’s close to 10 years old).

The app is close to 10 years old, but I find this app is good to teach application security as there’s a scoreboard and 12 challenges to complete.

Anyway, without further ado below are my slides from my training

I also provided documents that provide a walkthrough of the BodgeIt store as well as installing and using an interception proxy such as Burp Suite.

Finally, I included instructions on how to import the OWASP Broken Authentication VM which have a series of insecure apps.

See below.

BodgeIt Walkthrough Download

Installing And Using Burp Download

Importing OWASP Broken Authentication VM Into Virtualization Download

Enjoy and keep hacking!

boot2root, hacking, web application security

@TryHackMe – Pickle Rick CTF

March 14, 2019March 3, 2021 thefluffy007

Another day, another challenge.

Today’s blog post I will be solving the Pickle Rick CTF on TryHackMe.com. Click HERE to be redirected to the challenge.

After hitting the deploy button we now have our IP address.

We see that this challenge is focused on finding vulnerabilities in a web server.

Let’s run nmap, nikto, and dirbuster to see what we find…

Executing nmap, we see that there are two port open – 22 (ssh), and 80 (http).

Moving on to nikto…

Running nikto we see that there is an login php file which is interested.

Finally, let’s look at dirbuster.

With dirbuster we have an access directory, as well as an index.html, and robots.txt file (both returning a 200 which is good). We also have a server-status which is returning a forbidden http code of 403.

We’ve done basic enumeration let’s move to the web app and see if we can find more clues.

Let’s answer the first question.

Navigating to the IP address in a browser we see the following.

Nothing really stands out, except for the burping :-). Let’s view the source code and see what we find.

Viewing the source code (Right click on page, select view source code) we see at the bottom there’s a username. Let’s see if we can find a password. Maybe our dirbuster results will come in handy…

Going back to our results in dirb we notice there’s a robots.txt file. Going to this file, we see the above. Hmm, this is a strange robots.txt file. Maybe this could be the password, let’s see if it works.

In our nikto results, we had a login page. Navigating to that page and entering our username from the index.html page, and a password from the robots.txt page we get the following.

Success! We’re in the application.

Let’s run the ls (listing) command with the options of all and long listing and see what we have.

Opening the Sup3rS3cretPickl3Ingred.txt file we have the first ingredient below.

Also notice that the directory shows the asset directory that we found in dirbuster. Navigating to that webpage we see the following

The directory have gifs and jpgs, nothing of importance to solve the challenge.

Let’s move on to question 2.

We know this application is vulnerable to command injection, let’s see if we can perform a directory traversal to view other parts of the application. Going back to the directory listing we notice there’s a clue.txt file. Opening the file we see the following

Our hunch was correct, we need to look around the file system to find the next ingredient.

In the above command we’re doing a directory traversal to move up to the root directory, list all of the files in long form (ls -al), and print the working directory to make sure we’re in the correct folder (pwd). Doing this we get the below screenshot.

We’re viewing the root level directory, so our command(s) were a success! We notice a lot of folders, but at this time two are useful for us. The first is home, which in every Linux system ever user has a home directory. The second is root (admin/super user) which can only be accessed through the admin. We’ll come back to root later. Let’s see if we can navigate to the home directory.

Executing the command above, we’re now in the /home directory! We notice there are two folders, rick and Ubuntu. The Ubuntu folder is from the operating system. Let’s explore the rick folder and see what we can find.

Changing to the rick directory we see the second ingredient!

Using the less command we open the second ingredient. Note: The filename is in quotations due to spacing. Without the quotations Linux would interpret the second in second ingredients.

We now have our second ingredient, let’s answer the final question.

Remember in the beginning of this walkthrough, I mentioned that another folder – root is of particular interest to us and only the admin or superuser is the only user to access this folder. Let’s see if we can elevate our privileges to the admin and view this folder.

Before we can access this folder, let’s run the sudo -l command to see what privileges we have on this box.

Executing this command we see that we can execute ANY command on this box WITHOUT a password (ALL NOPASSWD: ALL). This surely is NOT good security! Let’s use the sudo command with the listing (ls) with the root folder and see what we can find.

Executing the command, we see that there are two files in the /root folder. One of them is named 3rd.txt. Could this be our third ingredient? Let’s see.

Executing the sudo command in conjunction with the less command on the 3rd.txt file, we see that we do indeed have the third and final ingredient.

Challenge solved!

boot2root, hacking, OSCP, web application security

OSCP Series: Kioptrix Level 3

March 10, 2019March 3, 2021 thefluffy007

Another day, another challenge.

In today’s blog post we’re going to solve level 3 of the Kioptrix series.

For the level 2 walk through, click HERE.

Let’s begin.

Starting the VM, we’re presented with the following login screen.

Going back to the login screen the disclaimer states that we need to modify the /etc/hosts to include our IP address that our kioptrix3 vm is running.

Let’s see which services are running on the virtual machine

Hmm… we have two services open – ssh and http. Let’s go to the web application and do a manual crawl of the site.

Navigating to kioptrix3.com we see the following:

Clicking the Login button we’re presented with a login screen. At the bottom we notice the page is using LotusCMS. Let’s keep this in mind, just in case we it to exploit the application.

Let’s run nikto to see if we can find more vulnerabilities in the web application.

We see that the application found a phpmyadmin folder. Let’s go to the folder and see what we can find.

Going to the php page, we realize we don’t have login credentials, so at this point we can’t log into the phpmyadmin page. We know the application is using LotusCMS let’s see if there’s a LotusCMS module that we can use in Metasploit.

After opening and searching Metasploit for LotusCMS we see there’s a perfect remote code execution we can use.

After selecting the exploit let’s review the options to see what we need to add to the module to make the exploit work. We need a remote host (RHOST), remote port (RPORT) and the URI. Let’s add the information below.

After entering the information, and typing run, we notice that we’re presented with a meterpreter shell! Let’s go to the home directory and see how many users are on the box.

We have three users, dreg, loneferret, and www (web). Let’s see what’s in the dreg folder.

Searching the dreg folder we don’t see much. We see a bash_logout, bashrc, and profile scripts. Let’s move on to loneferret.

Hmm… Loneferret has a lot of information. We see there’s a file titled, “.sudo_as_admin_successful”, a company police readme, and a checksec script. Let’s review the company policy readme.

Well… it seem if we want to edit, create, or view files we need to use the command sudo ht. Let’s keep this in our toolbox because I am sure we will use it later. Remember we found a phpmyadmin page, let’s see if we can find a config file with login credentials.

Doing a search on the kioptrix3 folder, we see there are three config files. Let’s review the last file, gconfig.php.

Opening the gconfig.php file we notice there are login credentials for the phpmyadmin page! Let’s keep this in our toolbox because we might have to use it later.

At this point, we have php login credentials, but that’s not enough to gain root privileges. Let’s see if we can review the web application again for more clues.

We notice there’s a gallery section of the application. Maybe we can be lucky and the application is susceptible to sql injection.

Adding an apostrophe to the end of the number there’s no change in the application. We notice at the bottom of the page there’s a sorting option. Let’s see if changing the sorting option will invoke a SQL injection.

Changing the sorting option to Photo Id, and adding the apostrophe to the end of the number, we get the following…

Success! The application is susceptible to SQL injection. Let’s fire up sqlmap and see what goodies we can find.

Executing a preliminary SQLMap run we see that SQLMap verified our manual testing results that the application is susceptible to SQL injection. SQLMap also found the technologies the application is using. Let’s do a more extensive probe. Firing SQLMap again we use the dump all to see what data we can find.

We found the dev accounts database, and notice that we have two users dreg, and loneferret, along with their passwords. Remember these are the same users we found when we used Metasploit with the LotusCMS remote code execution.

Now that we have login credentials, and we know that loneferret has more promising information than dreg, let’s connect to loneferret’s account through ssh.

Connecting to loneferret’s account, we try to access the root folder, but receive a permission denied (we’re not root… yet). We also try to execute the sudo ht command that was listed in the company readme file, and we get the error, “error opening terminal: xterm-256color”.

Doing a quick google search we find that we need to use the following command “export TERM=xterm”. Doing this and running the sudo ht command again we’re presented with the following screenshot. Let’s see if we can view and modify the /etc/sudoers file and see if we can escalate our privileges from loneferret to root.

Opening the /etc/sudoers file we notice that the loneferret has a user privilege escalation where a password is not required. Right now it’s for the commands: su, and sh. Let’s add our ht command to the list. After adding the command, saving, and exiting we’re presented back to the command prompt.

Executing the command sudo /bin/sh, and running a whoami we see that we’ve been escalated to root! Running the ls command we see that we’re presented with the same information we had in our meterpreter shell. Changing our directory to /root we notice there’s a Congrats.txt file.

Opening the Congrats.txt file we have found the flag and completed the challenge!

hacking, owasp, web application security

OverTheWire: Natas Level 9 – #appsec #webapp #websecurity #wargames

June 5, 2018March 3, 2021

Another day, another hacking challenge…

Today’s challenge is to find the password for level 9.

To view level 8, please go HERE.

After entering the username/password we see the following screen:

On the right side there’s a link that says, “view sourcecode”.

Clicking this link we see the following:

First, you should notice that there is weird syntax (language) of “<? and ?>” What is this? Well, this is PHP (Personal Home Page). Which is a server-side programming language.

What exactly is passthru? Passthru is a function that executes a command. To learn more about the passthru function click HERE. In this case we’re using the word in the first screenshot to look through a file named dictionary.txt.

Let’s try to enter the word “test” to see what we get…

The code returns all of the words that have test in it. OK. Let’s see if we can get ALL of the words in the dictionary.txt file.

Let’s try the word of “” instead of test. Doing that we get the following:

We have all the words in the dictionary.txt file. Why did I pick “” ? Well if you look in the passthru function the command was enclosed in quotes. I figured that if I entered quotes we would break out of the command which would produce all of the words in the file.

So now we have all of the words, what do we do now?

The challenge seems to be vulnerable to command injection. To learn more about command injection, go to the link HERE.

Let’s try to add another command to list all of the directories in the folder. The command to enter is: ls%20-la; (%20 is the URL encoding of space). This command is listing all of the files in the directory include hidden ones (in Linux hidden files start with the “.”).

We have listed all of the directories, and have a potential gem. There’s a file named .htpasswd. Let’s add on to the command sequence to open this file. To do that we add the following: cat%20.htpasswd;.

We have received the password! Which is: $1$p1kwO0uc$UgW30vjmwt4x31BP1pWsV.

hacking, owasp, web application security

The BodgeIT Store Series #7, Change your Passwords via a GET Request – #bodgeit #infosec #pentest #appsec #webapp

January 19, 2018March 3, 2021 thefluffy007

Happy hacking!

Today’s blog post is #7 in the BodgeIt Store series.

To view the blog post #6 click HERE.

Today’s topic is we’re going to change our password via a GET request.

Let’s get started.

We were able to log into the application without supplying a password – click HERE to read it.

Logging into the application as user1@thebodgeitstore.com’ OR ‘1’=’1

We get the following:

Clicking on the user1@thebodgeitstore.com link we see:

Let’s view the page source of the webpage:

We see that the update password is looking for a POST, but we need to send it as a GET. How are we going to solve this?

Let’s do a right click on one of the text boxes and select “inspect element”.

From there we see:

Double clicking on the form method we’re going to change the method from POST to GET.

Going back to the password page, we can select the password to anything. I am going to use “hello”, and press “Submit”

We we’re able to change our password, through a GET request.

Let’s see if our solution was accepted.

Our solution was accepted (as the challenge is now green)!

hacking, owasp, web application security

OverTheWire: Natas Level 8 – #appsec #webapp #websecurity #wargames

August 11, 2017March 3, 2021 thefluffy007

Another day, another challenge…

In today’s challenge we’re going to solve level 8 from the Natas wargame.

Let’s begin.

Going to the following link, and entering the username “natas8” and password “DBfUBfqQG69KvJvJ1iAbMoIpwSNQ9bWe” we get the following:

OK, we see a page that is asking for an input secret. Clicking the view sourcecode link we see:

Looking at the screen, there’s PHP code with an encoded secret variable that seems to be in hexadecimal. There’s also a function titled “encodeSecret” that does the following steps:

Change the binary to hex (bin2hex)
Reversing the string (strrev)
Base64 encoding (base64_encode)

From there the code is checking to see if our input secret equals the encoded secret. If it does then we get the code for level 9, otherwise we need to try again.

So, how are we going to solve this?

Going to Google and looking for a PHP interpreter, we’re presented with the following link.

From there, We’re going to do the reverse the steps of above. Our new steps are:

Convert the hex to binary (hex2bin)
Reverse the string (strrev)
Base64 decode (imap_base64)

Below is the screenshot that depicts the above steps.

Doing the steps, we are presented with the decoded secret which is “oubWYf2kBq”

Going back to the level 8 page, and entering our decoded secret we get the following:

We found the flag!