InfoSec LAB

Soccer_soc-player.soccer.htb

Created: 4 min read

soc-player.soccer.htb

Upon gaining the initial foothold, several unidentified network sockets have been discovered.

www-data@soccer:~$ ll /etc/nginx/sites-enabled/
total 8.0K
4.0K drwxr-xr-x 2 root root 4.0K Dec  1  2022 .
   0 lrwxrwxrwx 1 root root   41 Nov 17  2022 soc-player.htb -> /etc/nginx/sites-available/soc-player.htb
   0 lrwxrwxrwx 1 root root   34 Nov 17  2022 default -> /etc/nginx/sites-available/default
4.0K drwxr-xr-x 8 root root 4.0K Nov 17  2022 ..
 
www-data@soccer:~$ cat /etc/nginx/sites-enabled/soc-player.htb
server {
	listen 80;
	listen [::]:80;
 
	server_name soc-player.soccer.htb;
 
	root /root/app/views;
 
	location / {
		proxy_pass http://localhost:3000;
		proxy_http_version 1.1;
		proxy_set_header Upgrade $http_upgrade;
		proxy_set_header Connection 'upgrade';
		proxy_set_header Host $host;
		proxy_cache_bypass $http_upgrade;
	}
 
}

one of them was 127.0.0.1:3000 and it has been speculated to be a virtual host, serving a web application located at /root/app/view via an nginx proxy; http://localhost:3000

The /etc/hosts file on Kali has been updated for local DNS resolution

Updated Soccer Club

Navigating to the soc-player.soccer.htb virtual host reveals a similar soccer club web application seen in the soccer.htb host

However, there are notable differences. There are buttons are mapped to other pages and the /tiny/ directory isn’t available at all

Additionally, this appears to be an Express application with PHP backend

/match

The /match page contains 2 match entries There is a suggestion for signup as it would provide free ticket

/signup

Creating a testing account at the /signup page; test@test:test

/login

Using the newly created testing account, I can authenticate to the /login page

I am being redirected to the /check page

Interestingly, it also pulled me to send a GET request to the web server on the target port 9091 with the following headers;

  • Sec-WebSocket-Key with some base64 data in it
  • connection: upgrade The web server on the target port 9091 initially could not be enumerated due to the insufficient response from the server

looking further into it, the web server responded with code 101 the code 101 indicates a protocol to which the server switches. The protocol is specified in the Upgrade request header. it wants to upgrade the connection to websocket

This would imply that it is a WebSocket API service, hosted on the target port 9091

/check

The /check page displays a ticket id; 69743 This must be the provided free ticket mentioned in the /match page earlier above

Additionally, it contains what appears to be an input field

Loading the /check page alone invokes uploading to the WebSocket protocol It’s like that the /check page has the WebSocket call hard-coded into the source code

WebSocket

websocket is a computer communications protocol, providing simultaneous two-way communication channels over a single Transmission Control Protocol (TCP) connection. The WebSocket protocol was standardized by the IETF as RFC 6455 in 2011. The current specification allowing web applications to use this protocol is known as WebSockets. It is a living standard maintained by the WHATWG and a successor to The WebSocket API from the W3C.

transition is made with the protocol handshake that looks much like what’s shown during the authentication process of the target web application. It’s also mentioned that the client sends a Sec-WebSocket-Key header containing base64-encoded random bytes, and the server replies with a hash of the key in the Sec-WebSocket-Accept header to prevent a caching proxy from re-sending a previous WebSocket conversation, and it does not provide any authentication, privacy, or integrity

testing out the input field results sending out a websocket message of JSON data to the web server on the target port 9091 The reply suggests that it’s meant to handle ticket id

Burp Suites support WebSocket handling for repeater The WebSocket API server appears to be using an SQL query to check whether or not if the given id exists in the database backend If the provided id does exist, the WebSocket API server responses with Ticket Exists, else TIcket Doesn’t Exist

Interesting thing that I have discovered is that the arithmetic operation is passed and processed through the SQL query as the result shows above This may suggest that the WebSocket API server is vulnerable to blind SQL injection

Interactive Graph View

Backlinks