Tryhackme VulnNet: Internal

VulnNet Entertainment is a company that learns from its mistakes. They quickly realized that they can’t make a properly secured web application so they gave up on that idea. Instead, they decided to set up internal services for business purposes. As usual, you’re tasked to perform a penetration test of their network and report your findings.

• Difficulty: Easy/Medium
• Operating System: Linux

This machine was designed to be quite the opposite of the previous machines in this series and it focuses on internal services. It’s supposed to show you how you can retrieve interesting information and use it to gain system access. Report your findings by submitting the correct flags.

Note: It might take 3–5 minutes for all the services to boot.

• Author: SkyWaves
• Discord: SkyWaves#1397

First thing we will do, is run an nmap scan against all open ports: nmap -vv -A -O -sC -sV 10.10.253.59 -p-

Since 445 (SMB) is open, lets try and see if anonymous login is enabled. First we will enumerate the shares

Now we can log into the shares location (password would be anonymous)

Lets go ahead and see what files exist

If we run more services.txt, we will be able to retrieve the flag

changing into the other directory (data) reveals 2 other files

running more data.txt

running more business-req.txt

Lets go ahead and try logging into the redis-cli and see if we can run any commands, this error means that a password is required

if we run showmount, we will get the following output

Now we will make a test directory inside of our temp folder

Now lets go ahead and mount the /opt/conf remote directory

Lets go ahead and verify our mount was successful by running df -k

Now lets go ahead and navigate to the /tmp/test directory

Now lets go in the redis folder and see what files exist

If we run more redis.conf and keep proceeding further through the file, eventually we will come across a password

Lets go ahead and login with that password

Running ping and receiving a response of pong lets us know that we are successfully logged in

Lets go ahead and show all of the keys

Lets retrieve the internal flag by running GET

Helpful Redis commands

Here are the commands to retrieve key value:

if value is of type string -> GET <key>
if value is of type hash -> HGETALL <key>
if value is of type lists -> lrange <key> <start> <end>
if value is of type sets -> smembers <key>
if value is of type sorted sets -> ZRANGEBYSCORE <key> <min> <max>
if value is of type stream -> xread count <count> streams <key> <ID>. https://redis.io/commands/xread
Use the TYPE command to check the type of value a key is mapping to:

type <key>

Since authlist has a type of list, we need to run lrange, in order to retrieve everything in the list we can start with the number 0 followed by the end value of -1

Information regarding the different fields under the info command

INFO

if we use cyberchef (or base64 decode locally), to decode the authlist, we will obtain a new password for rsync

Now lets go ahead and connect to the files folder

Lets connect to the sys-internal directory

Some common options used with rsync commands
-v : verbose
-r : copies data recursively (but don’t preserve timestamps and permission while transferring data.
-a : archive mode, which allows copying files recursively and it also preserves symbolic links, file permissions, user & group ownerships, and timestamps.
-z : compress file data.
-h : human-readable, output numbers in a human-readable format.

Lets go ahead and copy the files down to our local machine user a new folder called user_files

Now we can cat out the user.txt file locally to obtain the user flag

Lets go ahead and create an ssh public key, and then copy it over to the server. Just in case, set a password

First, in the folder we copied down using rsync, uder the .ssh hidden folder, we notice that there is not an authorized_keys folder

First lets go ahead and create our ssh key using ssh-keygen -f id_rsa

Now lets create a file called authorized_keys and change the permissions using chmod 700

Our final step,before rsync is to copy the public key into the authorized file

Now lets rsync the authorized_keys file back to the server

Now we can ssh in using our private key, specifying the password we set

Now that we are in, we need to back up the directory and will find a directory called TeamCity

Within that directory under logs, we will find a file called catalina.out

Inside of catalina.out, if we scroll up, we will find this section

Now we need to open up a new terminal window and port forward our ssh session

Now that we are authenticated, our next step is to open a browser and browse to the ip and port

Now, to login, we need to login with a blank username using the auth token as the password. I was having some issues with the login, so I went back to the file and catted it out again, the auth token changed

Once the new token was supplied, login was successful

Lets go ahead and create a project manually (it doesn’t matter what we name it

Once created, click on Build Configurations

When we click Create, it will bring us to a new screen, but we don’t need to run through all of these steps. At the top, click Projects

Click on the Project Name

Right hand side: Edit Configuration Settings

Click on Build Steps

Add a Build Step

Fill out the following and Save

Once saved, click Run

Now that we’ve created this successfully, back on the terminal we can verify /bin/bash exists via searching for SUID

Now that we’ve confirmed it, we can elevate /bin/bash to root

Lessons Learned/Remediations

1. Do not expose SMB to the internet, if you have to, make sure to lock it down and do not allow anonymous logon
2. Make sure to lock down nfs permissions via /etc/exports (https://linux.die.net/man/5/exports)

5.4. Securing NFS Red Hat Enterprise Linux 4 | Red Hat Customer Portal

Make sure to verify the nfs mounts are set up correctly via the: showmount -e <hostname> command

3. Do not store redis.conf files within exposed nfs mounts, also make sure there isn’t a plaintext password within the config file as well

4. Make sure to lock redis authorized down to authorized devices (https://redis.io/docs/manual/security/)

5. Make sure to lock rsync down to authorized devices via building either an allow or deny list (https://www.upguard.com/blog/secure-rsync)

Further rsync reading

How Rsync on the Public Internet Puts Your Data at Risk | Rapid7 Blog

6. Here is a list of TeamCity Hardening Advice

Hardening Your TeamCity Server | The TeamCity Blog

The TeamCity Super User is enabled by default, but can be disabled via the following command: teamcity.superUser.disable=true

Super User Access | TeamCity On-Premises