3 Types of Scanning - Port Scanning, Web Application Scanning, and Infrastructure Scanning

Summary

This is a brief overview on the differences between infrastructure scanning, web application scanning and port scanning and highlights why each is important and what each delivers. All three are supported by AppCheck:

Infrastructure Scanning

Infrastructure scanning is enabled by adding an IP (or Fully Qualified Domain Name/FQDN that resolves to an IP - eg "ftp.example.com")  as the target of a scan.

Infrastructure scanning works by our scan hubs making a series of connections and requests to ports and services on a target host. These will be performed at various "tiers" or layers of the network stack and will probe various ports and services found at a relatively cursory layer, making basic connection-type attempts, although without attempting in most cases to perform any serious service usage or access. In order to support this testing, the scan hub has to be able to understand and "speak" the protocol in question - eg if it find port 445 open then it needs to "speak" SMB (server message block) protocol in order to find any vulnerabilities with the SMB service (as you'd expect from an infrastructure scan).

However, HTTP is another application protocol, just like any other, so if an infrastructure scan finds port 80 open for example it will attempt to "speak" HTTP protocol at it and establish a connection. It will not (as in a web application scan) attempt to "use" the web application but it will make a basic request to the port and receive an HTTP response, including headers. From this, some vulnerabilities relating to the HTTP protocol usage (such as lack of headers, as in this vulnerability) can be found and reported. ie an infra scan is not HTTP-focused, but nor does it exclude HTTP ports and protocols from the same basic sweep it performs of all other ports and services found.

Infrastructure vulnerabilities broadly fall into the category of "known" vulnerabilities: what we mean by this is that it's a vulnerability that has been disclosed publicly (typically as a "CVE") and is known to exist in one or more "off the shelf" software products.

Detection is usually as simple as getting the version number of the product and checking it doesn't fall within a list of known vulnerable versions, through to sending a payload to a vulnerable service to in order to make it behave in a way to exhibit the vulnerable behaviour for detection. Solutions are usually to patch or upgrade the product to the latest version from the vendor which contains the fix.

Identifying and patching critical services both internet facing and internal is important as with the increase of ransom ware, the attacks are becoming more frequent and they are targeting new vulnerabilities faster.

Its also worth pointing out that infrastructure scanning can - optionally - also be configured to be "credentialed" (use provided authentication credentials in order to connect to a host in an authorised/privileged fashion) in order to find more vulnerabilities, based on performing interrogations directly such as installed binaries/applications. More information on this is available on our knowledgebase at https://appcheck.zendesk.com/hc/en-us/articles/360011113914-Credentialed-Infrastructure-Scanning

Web Application Scanning

Web application scanning is enabled by adding a web origin/URL (eg "https://www.example.com/" )as the target of a scan.

The key difference with a web application scan is that it is an extensive and focused scan of one or more web applications found to be operating on a given port at a given URL. Web application scans "only" talk HTTP to the server, but they do so much more richly, processing the responses at the application layer just like a browser running on your own computer would. They crawl sometimes thousands of pages, they understand and process returned JavaSCript and HTML and render pages returned, and they can intelligently submit "attack payloads" in requests in order to tease out vulnerabilities in a web application.

With application scanning you are generally looking for "previously-unknown" (unpublished/unrecorded) vulnerabilities in custom (in-house) code.

With custom code there is no "signature" (response pattern or data) to detect a vulnerability so it requires different approach to detect vulnerabilities. What AppCheck does is look for a range of potential exploits within a application operating under "first principles". When we talk about first principles we are talking about working through a methodology of going through a work flow in the same way a manual tester would looking for vulnerable components within an application - that is exhaustively testing hundreds or thousands of query variants to tease out potential vulnerabilities that were not previously known about.

To do this, initially we look to build up an attack surface: this is a collection of logical controllers within an application which we will start testing for vulnerabilities. For instance if we were to scan amazon.com it can be seen to have for all intents and purposes infinite products but we don't need to attack every product page to know if the product controller is vulnerable.

Depending on the size of the attack surface we could have a potentially very large number of payloads to work through and observe the behaviour of and while we want to make sure we catch some complex edge cases we also want to avoid generating too much noise with false positives. A key part of this is how we build up a rationale for why something is vulnerable, when AppCheck discovers something it will attempt to exploit it, starting with a basic case and building up to an easily confirmable payload.

Doing these things takes a good deal more steps than infrastructure scanning and hence takes longer, but it's important to remember how critical these vulnerabilities can be if overlooked. In the case of an SQL injection it can mean not only a compromised database but also a compromised server, with a compromised server it's not much of a leap to a compromised network all the while the firewall is useless as traffic is allowed to pass out through the vulnerable application.

All the big breaches of the last few years have been through custom applications and often these have been exploited by simple injections that are easily fixed. 

Port Scanning

Port scanning  is enabled by adding an IP (or FQDN that resolves to an IP - eg "ftp.example.com")  as the target.

Port scanning will check for open ports and report on services found, and perform OS detection if configured in the more advanced options under this section.