Hey, DNS! (with HCL AppScan Domain Name Server)

Once upon a time, “Dynamic Analysis” was called “Black-Box Testing”. I miss the old names (Black-Box, White-Box, Glass-Box…). While the new names have nice acronyms (DAST, SAST, IAST, etc.) they are far less descriptive in the way they work. The challenges faced when performing one type of testing or another are far clearer when the name explains how the testing option actually works.  

Black-Box very clearly tells you that you are treating the test target as a “black box”. You cannot see inside. You can only rely on what the black box chooses to expose to you. When we perform test attacks, we call that a “reflection,” which is how the application responds to an attack. It is sometimes the lack of reflection that indicates whether a test succeeded. 

This reliance on reflections is one of the major challenges faced by DAST. It is a limiting factor on the type of issues that can be detected. Some tests create an immediate response (or a response in a following sequence of requests) and those are issues DAST can find. Some tests are designed to disrupt a WebApp’s execution flow (intentionally causing a reflection failure) and those also are issues that DAST can detect.  

What about everything else?  

Impact of Asynchronous Validation Mechanism Testing 

Maybe not everything else, but the asynchronous validation mechanism introduced several years ago does help. The idea behind these tests is not to rely on direct reflection (or lack thereof) but on other externally observable behavior of the application. 

Where is this useful? For example, when testing for Command-Execution. We try to execute commands that would perform one of the actions described below. These are done outside the context of the running application and would, in many cases, have no response (direct reflection in an HTML, for example) associated with them. Under normal circumstances a DAST scanner would not be able to detect these vulnerabilities.  

The first class of tests attempt to trigger an HTTP request to a web server embedded within the AppScan scanner itself. AppScan tries to get the tested server to initiate an HTTP request to a specific URL that helps us understand the source attack. It also improves detection of External File Inclusion vulnerabilities. 

This is the payload: https://<appscan_ip>:<port>/AppScanMsg.html?varId=<attack_id> 

Where appscan_ip and port are the IP of the machine where the scanner is running and the port of the embedded web server. The value of attack_id identifies the actual attack that was sent.  

These tests have a very high degree of accuracy, but they are prone to failures. Network segmentation, in many cases, prevents these requests from reaching AppScan in the first place. The HTTP request is in fact generated by the server, but then can be blocked by a firewall or segmentation rule in the network itself. This is very common in a lab or staging environment. Access into the network segment may be allowed, but machines within the segment will not be able to generate HTTP traffic outside of the segment. 

While HTTP traffic may not be able to escape, DNS requests often can, due to the very nature of DNS. For this reason, we have decided to include a second class of tests. Like the first, these tests try to trigger requests. However, the new tests try to trigger a DNS lookup to an embedded server.  

DNS is a chained process. When one DNS server cannot resolve a host name to an IP, it will try to look for that host name in other connected DNS servers. DNS requests are almost never blocked by firewalls, gateways and other network mechanisms. 

The results are very good with a high degree of accuracy, but there is a catch. Many machines, by virtue of organizational policies, cannot perform a lookup to a specific DNS resolver; only to resolvers already configured in the operating system. This means that the scanner-embedded DNS server must be configured on the machines. That is a problem. 

The solution is to create a DNS server that will be automatically recognized.  

Introducing AppScan Domain Name Server (ADNS)  

Introducing ADNS – AppScan Domain Name Server. A cloud-based server that sits on the open Internet and is accessible and available to any machine that can use Internet-based DNS servers. This constitutes the vast majority of computers in the world (except computers that are physically disconnected from the Internet). Even environments that are closed off to HTTP traffic or are closed off by a Firewall to limit the type of connections that can be made, would usually allow DNS traffic through.  

The resulting test mechanism is this: 

Step #1: Craft an attack with a payload to a crafted host. 

Step #2: The tested server looks up this host name. 

Step #3: The ADNS receives and keeps a record of this lookup. 

Step #4: AppScan queries the ADNS whether a lookup has been made. 

To maintain simplicity, and to ensure that Step #4 is successful, the query is also made using DNS lookup. So AppScan instances with no direct Internet access (HTTP access) can still use this mechanism, as there is a very high probability that the DNS lookup will be successful.  

As mentioned, the DNS lookup is done to a crafted hostname. The hostname is constructed like this: 

vX–ping-<variant_id>-<scan_GUID>.securityip.appscan.com 

1. securityip.appscan.com / securityip.appsechcl.com – these  refer to the ADNS itself. This article is written at a time of transition from “appsechcl” to “appscan”. You will see one name or the other. For purposes of this article, I will use “appscan.com”. 
2. variant_id – an ID identifying the specific attack 
3. scan_GUID – an ID that identifies the specific scan. Variant IDs are unique in a single scan, but for a globally identifiable ID we need a random scan ID as well. 
4. X – this is an internal identifier for the AppScan protocol (exchange between the scanner and ADNS). 

A payload will look like this: 

v3-ping-11345–b697b0fb-06f5-4aab-a8d5-1867c7daa8c5.securityip.appscan.com 

1. 3 – the current protocol version 
2. 11345 – the variant ID identifies the original test that was sent 
3. b697b0fb-06f5-4aab-a8d5-1867c7daa8c5 – a globally unique instance ID, making sure that we don’t confuse one test with another 

The ADNS is waiting for these lookups and keeps a record of them. The ADNS does not maintain anything other than the resolved hostname (source IP/Port, for example) and there is no way to identify the origin of the request. The ADNS will then wait for another lookup that will look like this: 

v3-query-11345-b697b0fb-06f5-4aab-a8d5-1867c7daa8c5.securityip.appscan.com 

This is the lookup that the AppScan scanner generates. Resolving this name returns the ADNS IP address or NXDOMAIN (Non-Existent Domain). This is the validation stage of the attack. If the server returns a valid IP address, the attack succeeded. If not, then AppScan registers that the tested application was not vulnerable.  

AppScan uses ADNS in a variety of tests. The obvious are direct lookups in a Command Execution scenario. However, other types of tests can also benefit. Remote File Inclusion, for example. The classic DAST validation tries to trick the application into embedding external content that can be detected in the response. Using ADNS, the external URL can include the ADNS domain. While content will not be embedded, the application will at least need to resolve the host name, and that is proof of vulnerability. 

ADNS represents a leap in accuracy for non-reflected tests and increases the overall number of types of vulnerabilities that AppScan can be used to detect. 

We’re always happy about that! 

To Learn More 

To learn more about ADNS, please reach out to us and schedule a demo now.