Uncovering Elusive API Targets via VHOST Discovery

What if I told you that the API server you are targeting might be hosting other API versions that haven’t been tested yet? How valuable would it be to find those resources?

This concept of hosting multiple versions of an API on the same server is called virtual hosting, or VHOST for short. It’s a common way for DevOps to reuse data center hardware or cloud computing resources without spinning up new systems.

In this article, I will show you how to find these elusive API targets using VHOST detection.

What is VHOST?

VHOST, or virtual hosting, is a technique web servers use to host multiple websites on the same server. It allows different versions of a website to be served from the same physical or virtual machine, differentiated by their domain names.

This concept can also be applied to APIs – allowing multiple versions of an API to be hosted on the same server. This can save time, resources, and costs for companies that need to have multiple versions of their APIs available.

How does a VHOST work?

Imagine this scenario…

A small development team is working on a new API for their crapi.site. When they are in the midst of writing the API, they need a place to run it and try new things. Chances are, this code is frail and brittle, constantly changing as they go about their agile development process.

So they decide to host this development version at https://dev.crapi.site so the team can work with it.

When they are ready to have QA look at it to complete their functional testing and have the redteam conduct their security testing, they push it to a separate instance at https://staging.crapi.site.

Finally, after sign-off from testing, the API is deployed to production, a separate instance at https://www.crapi.site.

With VHOST, this is all hosted on the same machine. DNS records point each domain to the same IP address, and it’s up to the webserver to route the request to the proper instance by parsing the HOST header in the HTTP request.

Why does finding VHOSTs matter?

When a server hosts several versions of an API, new and changing endpoints may expose potentially vulnerable code. If those vulnerabilities can be exploited, it may give you a foothold on the server that allows you access to the production configurations, API artifacts, and data stores.

Therefore, finding VHOSTs increases the blast radius of anything you can exploit. As it’s not difficult or time-consuming, this should be part of your regular recon process.

Let me show you how to do VHOST enumeration and discovery using a few tools you probably already have in your arsenal.

VHOST Discovery & Enumeration

There are several tools dedicated to VHOST discovery that you can download, like HostHunter and vhost-enum. However, I am going to show you the tools I regularly use to do this, which I already have installed as part of my regular API recon process.

Scan target with Nmap

So you should be pretty familiar with Nmap at this point. I even mentioned it in the Beginners Guide to API Hacking. Nmap is the de facto standard tool to use for port and service discovery on a target. It’s literally the “network mapper,” helping you map the attack surface of the hosts you are attacking.

Built into Nmap is a variety of scripts known as Nmap Scripting Engine (NSE) modules. These modules dramatically extend the functionality of Nmap and are used to perform a wide range of tasks such as vulnerability detection, advanced version checking, and even certain types of exploitation.

The NSE modules are what really set Nmap apart from other network scanning tools, providing a level of flexibility and power that is unparalleled. They are an essential part of the toolkit for any serious penetration tester or security researcher.

The NSE script we want to leverage for VHOST discovery is http-vhosts. Let me show you it in action and then explain the command line I typically use:

nmap --script http-vhosts -p 80,443 --script-args http-vhosts.domain=crapi.site,http-vhosts.filelist=/opt/SecLists/Discovery/DNS/subdomains-top1million-5000.txt www.crapi.site

Here is the breakdown of the parameters I use:

• –script http-vhosts : Tells Nmap to load the NSE module for VHOST discovery
• -p 80,443 : Focuses on probing only the HTTP and HTTPS ports
• –script-args : Tells Nmap to override the default script variables with the ones that are about to follow
• http-vhosts.domain=crapi.site : Sets the root domain we will be enumerating to crapi.site. (yes, it’s a real domain)
• vhosts.filelist=/opt/SecLists/Discovery/DNS/subdomains-top1million-5000.txt : Sets the wordlist to use during enumeration. In this example, I used the default wordlist of the top 5000 subdomains defined in Daniel Miessler’s SecLists repo.

As you can see, when Nmap completed its discovery, it detected all dev, staging, and www instances.

Fuzzing with GoBuster

Another way to complete VHOST discovery is by fuzzing the virtual hosts with a tool like GoBuster.

I prefer Feroxbuster over GoBuster when bruteforcing webservers and conducting content discovery. However, FeroxBuster doesn’t do VHOST subdomain enumeration, which is why I fall back to GoBuster for this.

This is the typical command I use for VHOST discovery:

gobuster vhost -k --append-domain -u crapi.site -w /opt/SecLists/Discovery/DNS/subdomains-top1million-20000.txt

Here is the breakdown of the parameters I use:

• -k : Skips TLS certificate verification. Useful when the dev/testing instances may have self-signed certs.
• –append-domain : Appends the main domain defined in the URL to the subdomains listed in the wordlist. If you don’t use this param, each item in your wordlist must be a fully qualified domain name that includes each subdomain.
• –u crapi.site : Defined the main domain URL to probe
• –w /opt/SecLists/Discovery/DNS/subdomains-top1million-20000.txt : Defines the wordlist to use. In this example, I used the default wordlist of the top 20,000 subdomains defined in Daniel Miessler’s SecLists repo. I can afford to scan for more subdomains than with nmap here, as GoBuster is far faster in its enumeration.

If you are a fan of keeping scan results in Burp Suite, you can proxy GoBuster’s requests through it by using --proxy http://127.0.0.1:8080. Then you can sort by Status Code to find the requests that actually received an HTTP response.

VHOST detection via Subject Alternative Name (SAN) certificates

Finally, the last recon technique I use for VHOST discovery is to parse out the server’s SSL certificate from the production URL, looking for subdomains that might be listed in the Subject Alternative Name (SAN) metadata properties.

Here is the command I usually use:

openssl s_client -connect www.crapi.site:443 2>&1 < /dev/null | openssl x509 -noout -text | grep -i dns

As you can see, we were able to grep out all the subdomains bound to this certificate. It doesn’t mean the subdomain is in use, but it’s a leading indicator of potential additional targets we should look at.

Conclusion

I hope I’ve shown you how easy VHOST detection is and how it’s a crucial technique in uncovering elusive API targets. By utilizing tools like Nmap and GoBuster to enumerate subdomains, as well as parsing SSL certificates for Subject Alternative Names, we can expand our attack surface and find potential vulnerabilities within the target’s infrastructure.

With the right approach and persistence, VHOST detection can lead us to uncover hidden API targets and gain valuable access to sensitive data. So next time you conduct recon on a target, remember to include VHOST detection techniques in your methodology.

You’ll be surprised what you might find.

Good luck!

One last thing…

Have you joined The API Hacker Inner Circle yet? It’s my FREE weekly newsletter where I share articles like this, along with pro tips, industry insights, and community news that I don’t tend to share publicly. If you haven’t, subscribe at https://apihacker.blog.

The post Uncovering Elusive API Targets via VHOST Discovery appeared first on Dana Epp's Blog.

*** This is a Security Bloggers Network syndicated blog from Dana Epp's Blog authored by Dana Epp. Read the original post at: https://danaepp.com/uncovering-elusive-api-targets-via-vhost-discovery