hacking, mobile

#MobileSecMondays Video 7 – Solving CrackMe Challenge 2

Another day, another challenge.

In today’s post, we’re going to solve CrackMe Challenge 2.

In this challenge, we’re presented with a login screen with a email, and a secret. Can we find the necessary information to log into the app?

Watch the below video to find out!

Like my content? Buy me a coffee – http://buymeacoffee.com/thefluffy007

hacking, mobile

#MobileSecMondays Video 6 – Solving CrackMe Challenge 1

Another day, another challenge.

In this post, we’re going to solve the first CrackMe challenge.

After reading the instructions, we need to find the secret string using techniques such as decompiling an Android app, and try to reverse engineer the source code.


Watch the below video for more details and to find the secret string!

Like my content? Buy Me a Coffee!

Link: https://buymeacoffee.com/thefluffy007

hacking, mobile

#MobileSecMondays Video 4 – Solving IGLearner Level 2

Hello everyone!

Another day, another challenge.

In this post we’re going to solve this challenge by finding a world-writeable (a file that is writeable by everyone) in the application.

For this challenge we’re going to reverse engineer this app, and review the code to solve the challenge.

Without further ado, check out the video below.

Like my content? Buy me a coffee! buymeacoffee.com/thefluffy007

hacking, mobile

#MobileSecMondays Video 2 – Solving OWASP Mobile Security Testing Guide (MSTG) Uncrackable Level 1

Hello everyone!

Another day, another post.

Here’s the second video from MobileSecMondays.

In this video I’m solving the OWASP Mobile Security Testing Guide (MSTG) Uncrackable Level 1 challenge.

In this challenge we’re going to reverse engineer an app. Using Frida, a dynamic analysis tool to change values during runtime to find a secret message!

Want to learn more and do the challenge yourself? Well watch the video below!

Like the content? Buy me a coffee – buymeacoffee.com/thefluffy007

hacking, mobile

#MobileSecMondays Video 1 – Installing Mobile Apps Using ADB

Hello everyone,


I’m doing something a bit different…

I’ve created a new series where I solve Mobile Security challenges (Android Only). I’ve titled it, “Mobile Sec Mondays”.

With the first video, we’re going to get our feet wet with Android Debug Bridge (ADB). ADB is used for Android mobile hacking. In this video we’re going to install an app from our virtual machine (IntroToAndroidSecurity) to an Androidx86 emulator.

Without further ado, check out the video below!

Enjoy!

Like the content? Buy Me a Coffee! buymeacoffee.com/thefluffy007

capture the flag, hacking, web application security

Solving @TryHackMe – Brooklyn Nine Nine

Another day, another challenge.

In this blog post, we’re going to solve the Brooklyn Nine Nine boot 2 root.

Let’s get started.

Going to the room, and pressing the start machine we get our IP address.

Here’s a screenshot of my IP address:

Next, let’s fire a terminal and see if we can enumerate the machine.

Going to the terminal let’s enter the command nmap -sV <IP address> in my case it will be nmap -sV 10.10.188.95

Doing this we get the following:

We see there’s an open port of FTP.

What can we do with FTP?

FTP can be configured where we can enter a username as anonymous with any password. Of course, this is NOT good security as there should be a valid username and password combination.

Let’s try it.

Going back to the terminal and enter ftp press Enter

Next enter open <ip address> in my case it will be open 10.10.164.245

Doing this we see:

We were able to login!

Next, let’s use the ls or list command to see what files/directories (folders) are on the FTP server.

We have one file – note_to_jake.txt

How can we download this file onto our terminal? We can use the GET command

enter get note_to_jake.txt to download the file onto our computer.

Afterwards, enter the command exit to exit the FTP server.

Now we’re back to our terminal on our machine. Enter the command ls -la which will do a long listing showing hidden files as well.

Doing this we see our file – note_to_jake.txt!

Now let’s open the file with cat note_to_jake.txt

We see:

OK – Amy is telling Jake his password is weak. This is good for us as we will need to use Jake’s login information to get into the system.

We’ll keep this in our toolbox.

Going back to the open ports, we now have SSH (22) and HTTP (80).

Let’s try the HTTP server and see what we find.

We’re going to use the brute force program – dirb

Let’s enter the command dir http://<IP address> in my case it will be dirb http://10.10.188.95

Doing this we have:

We didn’t find much.

Let’s move to the SSH server.

We can brute force the password using the hydra command. We’re going to enter the command hydra -l jake -P /usr/share/wordlists/rockyou.txt ssh://<IP address> -t 4

In my case it will be hydra -l jake -P /usr/share/wordlists/rockyou.txt ssh:/10.10.188.95 -t 4

Let’s break it down

hydra – command

-l jake – the user we want to brute force

-P /usr/share/wordlists/rockyou.txt – The wordlists (rockyou.txt) we want to brute force the SSH server with

-t 4 – we’re specifying to hydra that we want use 4 threads (more threads make hydra complete faster)

We found the password for jake’s login credentials for SSH. As you can see the password is not secure.

Now we’re going to log into the SSH server with the following ssh jake@<IP address> in my case it will be ssh jake@10.10.188.95

Doing this we’re prompted to enter our password which is 987654321.

After pressing Enter we’re in!

Now we need to find the user.txt.

How are we going to find this file?

Using the find command

In the terminal let’s enter: find / -name user.txt 2>/dev/null

Let’s break this down

find – the find command

/ – start at the root file system

-name – want to find a file by name

user.txt – the name of the file

2> – redirect errors from standard output (screen)

/dev/null – move the errors (from the 2>) to the /dev/null

Doing this we see:

We found the user.txt

Let’s open the file.

We found the user.txt code.

Now we have one more question – we need to find the root.txt

How are we going to do this?

Let’s see if we can do an escalation of privilege.

One of the first thing we can do is see if the user (jake) can execute any files or directories as root.

How do we check this?

Execute the command sudo -l

Let’s break this command down.

If the user (jake) is in the /etc/sudoers file then the above command will let us know what commands we can execute to get to root.

Entering the command we see:

There’s a command we can enter as to execute our privileges – less.

Let’s see how we can do this.

Doing a google search of less privilege escalation we see the following link.

Click the above link and scrolling down we see how we can do an escalation privilege under the sudo section.

Going back to our terminal let’s enter: sudo less /etc/profile (press) Enter) then enter !/bin/sh

Doing this we see:

Once we press Enter we’re back to the terminal

but if you notice the prompt has changed to a #

doing a whoami we see that we’re root!

Now let’s navigate to the root home directory (/root) to see if the root.txt is located there.

Enter the command cd /root to navigate to the root home directory

Doing a long list to show everything (ls -la) we see there’s a root.txt file!

Now let’s open the root.txt file

Enter the command cat root.txt we see:

boot2root, hacking, web application security

Solving @TryHackMe – Bounty Hunter

Another day, another challenge.

In today’s post we’re going to solve the Bounty Hunter 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!

boot2root, hacking, web application security

@TryHackMe – Solving RootMe

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:

Netcat 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

netcat-reverse-shell

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