The Lost Rabbit Labs team has spent the past month working hard to discover new attack vectors, techniques, and building complimentary tools to assist both offensive and defensive security teams. The focal point of the team’s development efforts has been building out our WisQuas Engine, a custom ‘Digital Footprint Discovery and Asset Analysis Crawler’. The WisQuas Engine attempts to reveal that which may be hidden, through slight fuzzing, enumeration, and fingerprinting around your entire domain and its web services. Using a handful of nominal web requests, WisQuas Engine attempts to identify areas of weakness around serious Information Disclosures, Security and Service Misconfigurations, Default Installations, and Missing Input Sanitization. Hidden web containers, granting access to Shadow VHosts and localhost data, are detected along with WAF bypassing payloads, Host Header Manipulations, successful VERB Tampering, and User Agent redirection. In addition, full ‘Digital Footprint Discovery and Inventory’ across a given domain is performed for completeness. Our WisQuas Engine has proved to be extremely beneficial for performing OSINT, Penetration Testing, and supporting the VCISO (Virtual CISO) role and function, by providing situational awareness around all managed domains within an organization.
In this write-up, we will provide an introduction to our WisQuas Engine, share some of LRL‘s recent discoveries, and take a quick look at causing an internal Information Disclosure (through overflowing the Apache web service), and using this disclosure to access an unprovisioned Shadow VHost (Virtual Host).
“When attacking, use softness…when defending, use everything!”
WisQuas Engine – Digital Footprint Discovery and Asset Analysis Crawler
In order to properly provide situational awareness around all digital assets belonging to a domain, we have created a custom web crawler, focused on detecting common security misconfigurations, the presence of suspicious or leaked data, and missing controls and protections. In the example below, we will use WisQuas to scan the domains ‘dji.com’ and ‘djicdn.com’, for the purpose of Bug Bounty Hunting. Once the crawl data has been ingested, we can use our query system to search for specific criteria. In our example, we will search for any URL that contains ‘dji’ with a payload of ‘config.php’, has a status code of 200, and has between 1 and 15 successful replies across 80 total requests for other commonly observed files and directories on that same host.
Our search yields 30 results for ‘config.php’, observed across the two (2) DJI domains. Let’s take a deeper look at a couple of the hosts to see if these are legitimate findings or false positives. Clicking the hostname on the left will provide an additional, detailed view into the host.
It appears that ‘config.php’ is available on both hosts, along with an observed ‘uploads’ directory on one host. Clicking on the link for the ‘config.php’ payload results in the loading of the actual website. The ‘config.php’ file is real and contains credentials for a database connection on the localhost. Lost Rabbit Labs did submit this observation through the proper Bug Bounty channels and was assured this is only a sample file, and poses no danger to any system on their network.
Other interesting findings in our database include…files and directories with improper permissions, debug and trace leakages, hidden admin portals, unique VERB and header manipulations, interesting OSINT and associations, and heaps of Missing Input Sanitization. We are seeing several cases of CDN/WAF/Container hooking and bypassing using “//”, “%2f”, and “%7b” appended to the URL (some samples below).
414 Overflow to Hidden Container Access (Shadow VHost Exploration)
Maximizing LOW criticality findings is necessary in order to see how deep the rabbit hole really goes, and ensure a threat is indeed, LOW risk. Often times, however, attackers can chain multiple LOW findings together in order to elevate severity and overall risk, and lessen your security posture. Let’s show an example around the way Apache web server currently works with configured containers, and disclosing Virtual Host, IP, and localhost information.
414 HTTP Response Code = URI Too Long (RFC 7231)
The URI provided was too long for the server to process. Often the result of too much data being encoded as a query-string of a GET request, in which case it should be converted to a POST request.
Our ‘414overflow.py’ script simply appends the provided value’s worth of “%” characters to the end of the provided URL. In our example, appending 255 characters to the end of the URL returns nothing. However, when providing 256 characters, we get an information disclosure around that web container’s server signature and actual configured virtual host name. When we use 2726 characters or bytes, we get the default web container’s information, and in our example, the locally configured IPv6 address.
Here’s an example where overloading the request is done through a standard web browser. Simply provide the required number of characters for the desired information disclosure after the URL (in our case we want the default container and will use 2726 characters appended to the trailing slash of the URL).
Now that we have the default Virtual Host name, let’s use curl to modify our ‘Host’ header value to the newly discovered host, and make another request.
Achievement Unlocked! Software version info observed, internal path disclosure detected, MySQL credentials in plain text, along with associated cloud container. Not bad for a couple of LOW findings (Hostname Info Disclosure/Host Header Manipulation), chained together to increase value and severity.
Additional container names for an IP address can be discovered through DNS, OSINT, and investigating Passive DNS records. Proper controls around web containers and the ‘host’ header object are needed to defend against unauthorized access. In addition, to FIX the Apache information disclosure, simply ensure you have “ServerSignature Off” in your Apache conf file.
Other findings of interest around these Shadow Vhost containers include; API access, admin portals and dashboards, indexable directories and files, the ability to perform SSRFs (Server-side Request Forgery), and access to localhost content.
How many web servers, WAFs, LBs, rewrites, and containers are really involved in one (1) URL request. Whose server are you really connected too?! And this is where we end this adventure…but you begin yours. Thank you to all the great connections made so far during our Responsible Disclosure reach outs and Bug Bounty interactions. We really do love Offensive Security, but have great passion for Defending and Protecting, and look forward to many more detections and remediations to come. Till next time!
– the Lost Rabbit Labs Team