flAWS Level 2 #aws #flAWS #flaws

Another day, another challenge.

Today’s blog post we will solve the second level of the flAWS CTF challenge.

To read the post for the first level click HERE.

Let’s get started.

Going to the URL: http://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud/, we see:

flAWS_level_2_1flAWS_level_2_2

This challenge is similar to the level 1 except we need the free tier AWS account.

To complete that part of the challenge, click HERE.

Let’s list the bucket from level 2 and see if we can find anything.

We’re going to run the command we did in level 1:

aws s3 ls <s3 domain>

We will enter the command: aws s3 ls s3://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud/

Doing this we have:

flaws_level2_listing_directory

We have a secret file titled, secret-e4443fc.

Let’s see if we can access this file.

Appending this file to the URL, we get:

flAWS_level2_solved

Yay!! We have solved the challenge.

 

Advertisements

flAWS Level 1 #aws #flAWS #flaws

Another day, another challenge.

In today’s post, we will solve the first challenge of the flAWS CTF.

flAWS CTF explores misconfigurations, and gotchas in AWS.

Let’s get started.

NOTE: I will be using the AWS command line. Which you can download HERE.

Going to the URL, http://flaws.cloud/, we’re presented with:

flAWS_landing_page

Scrolling down we see:

flAWS_level1

From the little bit of information we have this level contains buckets, and we possibly need to view the contents.

In AWS, there is a service called S3 or Simple Storage Service which is used for storing items for the Internet. To store an item you will need to create a bucket (see how everything is starting to come together…). Once the bucket is created, you can add your items to it.

Opening a command prompt we can type the following command

aws s3 ls <s3 domain>

Let’s break down this command.

  1. We’re using the AWS command line (by typing aws)
  2. We’re specifying we want to access the s3 service
  3. We want to list the contents of said bucket (ls = listing)
  4. We’re specify the s3 domain we want to access

In this case we will type aws s3 ls s3://flaws.cloud

Below is the output:

flaws_level1_listing_directory

Hmm… there’s a secret-dd02c7c.html file. Let’s see if we can access it.

Opening a web browser (I’m using Chrome) and entering the following URL: http://flaws.cloud/secret-dd02c7c.html, you should see:

flAWS_level1_solved

Yay! We have solved the challenge, along with getting the URL for level 2.

Look out for another blog post where we solve that challenge.

Takeaway from the challenge –

For this level the bucket was public which means it’s accessible for EVERYONE. If there’s sensitive information that the world should not see, AWS allows for buckets to be private.

 

@TryHackMe – Pickle Rick CTF

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.

pickle_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…

pickle_nmap

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

Moving on to nikto…

pickle_nikto

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

Finally, let’s look at dirbuster.

pickle_dirb

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.

pickle_first_ingredient_question

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

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

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…pickle_robots

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.pickle_login

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.pickle_portal

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.

pickle_listing

pickle_listing_directory

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

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

pickle_assets_directory

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

Let’s move on to question 2.pickle_second_ingredient_question

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

pickle_clue_txt

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

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.

pickle_root_directory

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.

pickle_change_home_directory

pickle_listing_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.

pickle_change_rick_directory

Changing to the rick directory we see the second ingredient!

pickle_list_second_ingredient_rick_directory

pickle_less_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.

pickle_second_ingredient_answer

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

pickle_third_ingredient_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.

pickle_sudo_listing

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.

pickle_sudo_listing_as_root

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.

pickle_access_root_listing

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.

pickle_less_root_third_ingredient

pickle_third_ingredient

Challenge solved!

@TryHackMe – Basic Pentesting Room

Another day, another challenge.

Today’s blog post – I will give a walk-through on a boot-to-root room called, “Basic Pentesting Room”. This boot to root is perfect to get practice in preparation for the OSCP.

Let’s get started.

Logging into TryHackMe with your credentials and heading into the room we see the following:

TryHackMe1

OK, we have tasks to complete and we will learn the following skills – brute forcing, hash cracking, service enumeration, and Linux enumeration.

The first question is:

TryHackMe2

Clicking the deploy button at the top we get the following:

tryhackme

Second question is:

TryHackMe3

OK, we need to find the services exposed. What can we do?

One solution is to use nmap -sV (TCP scan) <IP address>

In this case it would be nmap -sV 10.0.0.204. Doing this we see the following screenshot:

tryhackme_nmap

Success! We now have the services.

TryHackMe4

Let’s use dirb to find the hidden directories. See the following screenshot:

tryhackme_dirb

Our hidden directory is development.

TryHackMe5

Reviewing our enumeration we see that ports 139 and 445 are open. These ports are used for SMB (Server Message Blocks) which are HIGHLY vulnerable. Let’s run the command enum4linux and see what we find.

tryhackme_smbtryhackme_smb2

We found two users: kay and jan

Question #5!

TryHackMe6

First, entering kay, I received an error. Let’s try entering jan. Success!

TryHackMe7

Let’s fire up Hydra which is password cracking tool with the password list of rockyou (this password list is used a lot in Kali and even in the OSCP… hint, hint!)

tryhackme_hydra

TryHackMe8

The service we use to access the server is SSH.

TryHackMe9

tryhackme_jantryhackme_jan2

TryHackMe10

kay

TryHackMe11

Since we have a new user (kay) and we have a ssh folder that lists the public key we can try to get the password.

TryHackMe12

From question #10 we have the user (kay) and a public key how can we go about cracking the key?

Doing a quick Google search, I was presented with the following link.

Scrolling down we see the following:

ssh_command

Let’s see if we can recreate this to find the passphrase. Using the ssh2john we created the hash.

tryhackme_ssh2johntryhackme_zip

Next we’ll use John The Ripper with the famous rockyou wordlist to see if we can crack the passphrase.tryhackme_kay1We were successful! The passphrase is beeswax. Let’s try to ssh with kay’s private key and see if we can get in.

tryhackme_kay2

Entering the passphrase we see that we were able to successfully log into the kay account! Just to be sure I issued the command of whoami (don’t mind the fat fingering!)

tryhackme_kay_listing

tryhackme_kay_passwordNext, we run the list command to see what we’re working with. We see a pass.bak file, let’s see if this lists the password. Opening the file we see the password. Score!

Let’s run sudo -l, which will show us what commands kay can run as root. We’re prompted with the password and we entered the password that we just acquired. We’re presented with all of the commands that kay can run, and we see that kay can execute all commands as root. Great, this will be helpful for us.

There’s another file that is important in the directory – bash_history. Bash_history is useful because it shows all the commands the user executed before logging off. Let’s open the file.

tryhackme_bash_historytryhackme_listing_2

After opening the file we see a lot of commands. There is one that is very useful – sudo su. If working correctly, running this command we will change from the kay user to root. In other words we would do privilege escalation – where we start as a non-admin user and through improper configuration change to a root user. Let’s try the command and see if it works.

tryhackme_sudo_su

Running the sudo su command, and typing whoami, we see that we’re now root! We do another directory  listing which shows the files from before, so no change. Let’s see if we can get into the root directory.tryhackme_kay6

Changing to the root directory we see that there is a flag.txt file. Opening this file we presented with the verbiage above. We solved the challenge!

OSCP Series: Kioptrix Level 3

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.

Kioptrix_Level3_Login

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.

Kioptrix_Level3_cat_etc_hosts

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

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:

Kioptrix_Level3_webpage1

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.Kioptrix_Level3_webpage2_login

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

Kioptrix_Level3_nikto

Kioptrix_Level3_nikto2

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

Kioptrix_Level3_webpage2_phpMyAdmin

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.

Kioptrix_Level3_msfconsole

Kioptrix_Level3_msfconsole2

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

Kioptrix_Level3_msfconsole_lotus_exploit

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.

Kioptrix_Level3_msfconsole_lotus_meterpreter

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.

Kioptrix_Level3_msfconsole_lotus_meterpreter_2

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

Kioptrix_Level3_msfconsole_lotus_meterpreter_dreg

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

Kioptrix_Level3_msfconsole_lotus_meterpreter_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.

Kioptrix_Level3_msfconsole_lotus_meterpreter_loneferret_company_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.

kioptrix_config_file

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

Kioptrix_Level3_msfconsole_lotus_meterpreter_loneferret_gconfig

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.

Kioptrix_Level3_gallery

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.Kioptrix_Level3_gallery_photo_id_before_sql_injection_2

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

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

Kioptrix_Level3_sqlmap

Kioptrix_Level3_sqlmap2

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.

Kioptrix_Level3_sqlmap3

Kioptrix_Level3_sqlmap4

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.

Kioptrix_Level3_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”.

Kioptrix_Level3_cat_etc_hosts_xterm

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.

Kioptrix_Level3_ht1

Kioptrix_Level3_ht_adding_sh

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.

Kioptrix_Level3_root

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.Kioptrix_Level3_root2Kioptrix_Level3_root3

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

OSCP Series: Kioptrix Level 2

Another day, another challenge.

In today’s post we’re going to solve Kioptrix Level 2.

Let’s get started.

After booting the machine, we see the following:

Kioptrix_Level2

This screen is very similar to level 1 click HERE if you missed that.

Let’s begin.

First, let’s enumerate using nmap, with the command nmap -sV <IP_ADDRESS>. In my case it will be nmap -sV 192.168.0.14

Below is the screenshot I have:

Kioptrix_nmap_Level2

We have a number of ports open. Let’s look at port 80 (http) and see what we can find.

Going to http://<IP_ADDRESS> (substitute IP_ADDRESS with your IP address)

We see the following screen:

Kioptrix_webpage_Level2

A login screen… let’s see if we can do an authentication bypass by doing a SQL injection.

Kioptrix_webpage_login_Level2

Entering the username of admin and password of ‘ OR ‘1’=’1′–

Success! We were able to complete an authentication bypass. Now we’re presented with a web console to ping a machine. So let’s ping.Kioptrix_webpage_console_Level2

Entering our IP address and pressing the submit button we see that the web page pings our machine.

Kioptrix_webpage_ping_Level2

Kioptrix_webpage_ping_results_Level2

Let’s see if we can complete one or more commands in succession. This vulnerability is called command injection, as the attacker can enter arbitrary commands to read and write to the server.

Kioptrix_webpage_command_injection_Level2

Kioptrix_webpage_command_injection_results_Level2

We see this application is vulnerable to command injection as we were able to ping our machine and list the contents on the server.

Let’s see if we can use the command injection vulnerability to get a remote shell.

Going to Google and typing in “remote shell commands” the following screenshot is from the first result.

Kioptrix_remote_shell_command_Level2

As you can see this web page lists different ways to gain a remote shell a server. Let’s use the first command, and see this will be successful for us.

First we need to get our IP address.

Entering the command in a terminal ifconfig we will get our IP address, which is what we need for our remote shell.

The below screenshot is mine:

Kioptrix_webpage_ipconfig_Level2

The next two steps need to be completed at the same time.

Going back to the web console, we’re going to enter the above remote shell command, changing our IP address, to the IP address from our ifconfig command. As well as change our port to the port listed in our netcat command (note the port can be anything, I just picked 4444 as it’s easier for me. It could be 1234, 2222, etc.)

Kioptrix_remote_shell_command_webpage_Level2

Now we need to start a listener, the below screenshot is used with netcat

Kioptrix_remote_shell_Level2

After pressing the submit button from the web console, we have the following screenshot – our remote shell worked! we see that we’re connected (192.168.0.14 is the Kioptrix machine and 192.168.0.12 is my machine). You’ll notice that when we list the directory it matches the above screenshot from the command injection inside the web console.

Continuing on let’s see the server version we’re running. See screenshot below.Kioptrix_webpage_uname_Level2

Opening a new terminal, let’s go to searchsploit and see how many exploits we can find for this version.Kioptrix_webpage_searchsploit_1_Level2Kioptrix_webpage_searchsploit_2_Level2Kioptrix_webpage_searchsploit_3_Level2Kioptrix_webpage_searchsploit_4_Level2Kioptrix_webpage_searchsploit_5_Level2Kioptrix_webpage_searchsploit_6_Level2

There are A LOT of exploits, as I was pretty lax on the search results. Let’s use exploit 9545.c as it lists the version number and it also use CentOS (which we saw during the enumeration phase) exploit.

Let’s copy the exploit to the current directory – see screenshot below.

Kioptrix_copy_exploit_Level2

Since we’re working with a web server, we need to move our exploit to the Apache folder and start Apache. See screenshots below.

Kioptrix_apache_exploit_in_folder_Level2Kioptrix_apache_start_Level2

Now let’s try to download our exploit. The first time doesn’t work as one we didn’t specify the file, and we get a permission denied – screenshot below.

Kioptrix_download_file_failure_Level2

Let’s try to change the directory to the /tmp folder and see if we can download our exploit.Kioptrix_download_file_success_Level2

We were successful! Our exploit was downloaded.

Let’s compile our exploit, and give it the name of exploit. See screenshot below.Kioptrix_compiling_exploit_Level2

Running the exploit and entering the whoami command we’re now root. W00t! Kioptrix_whoami_root_Level2

Let’s see if we’re truly root – let’s read the /etc/shadow by entering the following command cat /etc/shadowKioptrix_etc_shadow_Level2Kioptrix_etc_shadow_2_Level2

We’re able to view the /etc/shadow file, which means we’re truly root.

OSCP Series: Kioptrix Level 1

Another day, another challenge.

I am studying for the OSCP exam. I read the following boot-to-root is a good VM to root in preparation for the exam.

Anyway without further ado…

Note: I set Kioptrix and Kali to both Bridged, so both VMs are on the same network. Please make sure to do this or the walkthrough will not work.

Booting the Kioptrix machine we see the following…

Kioptrix_boot

Hmm… so we need to acquire root of this machine. And we’re presented with a login prompt.

Going to our Kali machine, we first need to find open the terminal and find the IP address of the Kioptrix machine.

To do this, type netdiscover followed by Enter.

For me, the IP address is 192.168.0.10, this will be different for you.

Now, let’s see which services are running on the Kioptrix VM.

Type nmap -sV (TCP scan) <IP_ADDRESS> in my case my IP address is 192.168.0.10.

Below is a screenshot:

kioptrix_services

We have the following services open – ssh, http, rpcbind, netbios-ssn, ssl/http, status

Let’s look at the http page and see if we can find something useful

Kioptrix_html

Nothing useful was listed here. Let’s go back to the services above and see if we can use another vector to find gems in the VM.

We see there’s a Samba server running on 139.

Maybe we can enumerate this server and get more information.

What can we use to enumerate?

There’s a useful tool called enum4linux which enumerate SMB servers for goodies.

Running the command enum4linux -a <IP_ADDRESS> we get:

Kioptrix_enum1Kioptrix_enum2Kioptrix_enum3Kioptrix_enum4Kioptrix_enum5Kioptrix_enum6Kioptrix_enum7Kioptrix_enum8

As you can see the tool returns a lot of data. The important pieces are:

  1. The server version of Samba server
  2. The different groups and users for the server

Looking at the output we see the Samba server is 2.2.1a

Let’s see if we can find an exploit for this server version.

Using searchsploit we have the following:

Kioptrix_SambaKioptrix_Samba2

OK, this looks promising.

Let’s try the first exploit. We need to copy the exploit to our current directory.

kioptrix_first_exploit

This is a perl program, so let’s see what we need to supply to get the exploit working:kioptrix_first_exploit2

We need to supply a target type, our ip, and a target ip. After supplying the correct information we have the following:

kioptrix_first_exploit3

The exploit didn’t work. Let’s try another.

Going back to the searchsploit results, the second exploit – Samba 2.2.8 – Remote Root Exploit, we see that it’s a c program.

First, let’s copy this file to our current location.

kioptrix_copy

Now we need to compile this file.

Using the gcc compiler, we can have a working exploit.

kioptrix_gcc

Let’s see what options we can use for this exploit…

kioptrix_sambaSploit

OK. We need to specify the platform (-b), it’s good to have the verbose (-v), and specify the host. Let’s see a screenshot of this.

kioptrix_remote

Score! We were able to gain a shell!!

OK, let’s see if we can find some goodies…

kioptrix_remote2

Looking at the bash history we see mail has been accessed.  Let’s try accessing the mail.kioptrix_remote4

Going to the inbox and reading the first message, we see the above message.

Score! We have successfully completed this boot to root!!