Menu
Vulnerability scanning can be a complex topic and organisations looking to evaluate vulnerability scanning solutions can often find themselves frustrated by a confusing landscape. The infrastructure scanning solution space can sometimes suffer from a lack of clarity and differing terminology between vendors, a swarm of acronyms and initialisms that can be at times proprietary or conflicting, and a technical vocabulary that is often poorly explained.
In this blog post we take a step back and provide a high-level introduction to infrastructure vulnerability scanning: what it covers, what it aims to achieve, and how it contrasts to other vulnerability scanning methodologies and techniques.
Information technology infrastructure (IT infrastructure) encompasses all the hardware and software components that the business operations run on. Although sometimes used to refer to people and processes too, it more typically refers to physical components such as computer and networking hardware.
Much IT infrastructure is “hidden” in that it is not directly operated as an end-user service, and so is often invisible to many end-users and customers. It operates as a set of components and hardware on which operated services rely.
IT infrastructure can be thought of within vulnerability scanning as consisting of everything “beneath” the application layer. So, for a web application written in PHP, for example, which may consist of all the various “layers” of software and hardware that support the application, including:
Infrastructure vulnerability scanning is the process of performing an automated series of checks against an infrastructure target or range of targets, in order to detect whether there are any security vulnerabilities that are potentially exploitable. The targets are specified as one or more IP addresses or IP address ranges to be scanned, or as Fully Qualified Domain Names (FQDNs) that resolves to an IP – such as ftp.example.com.
Infrastructure vulnerability scanning is performed across a network, such as the internet. The scans run on, and originate from, dedicated scan hubs, which run a scan engine that make connections to the targets that are to be scanned, in order to evaluate them for vulnerabilities.
In the case of AppCheck, the infrastructure scan beings by port scanning each host to identify accessible services. Each service is then probed for vulnerabilities such as missing security patches, configuration weaknesses, and information disclosure vulnerabilities.
If the target system is hosted within Amazon Web Services, Google Cloud or Azure, specific configuration assessment modules are launched to identify common configuration weaknesses.
Most infrastructure vulnerability scans are performed against external targets: that is, against targets that are exposed on, and therefore reachable across, the public internet. The targets can collectively be seen as representing the attack surface of an organisation: the collection of exposed components, services and systems that are hosted on an IP within the public address space.
Internal network scans are also possible, if a scan hub is deployed within the boundaries of an organisation’s network. This allows the scanning of screened and private infrastructure portions that are not exposed on the public internet.
Infrastructure scanning works by scan hubs making a series of connections and requests to ports and services on target hosts. When you or I access a webpage, our computers are making a connection at what is known as the application layer of the internet protocol suite. However, this is a virtual layer that exists for ease of intercommunication but is implemented by lower layers of inter-computer connectivity and ultimately physical wiring. Infrastructure scanning is performed at various “tiers” or layers of the network stack, often below the application layer, and will probe various ports and services found.
In order to support this testing, scan hubs/scan engines have to be able to understand and “speak” the protocol that is used by the underlying service in question – for example, if it finds port 445 open on a given target IP, then it most likely needs to “speak” SMB (server message block) protocol in order to communicate with the service on that port in order to find any vulnerabilities with the SMB service.
Once the scan hub has established a connection to a given port, it will attempt initially to determine the service that is running on that port, via a range of techniques: sometimes the service will “announce” its operating software and version in the metadata that it returns; other times the service can be guessed via a process of fingerprinting: recognizing distinctive patterns in how that service responds to requests that are due to quirks in the implementation of the software in question.
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, being published in the National Vulnerability Database (NVD) to which the scan hubs have access.
Detection techniques can sometimes be as simple as determining the version number of the product (via fingerprinting and other techniques, as above) and checking that the given version doesn’t fall within a list of known vulnerable versions.
However, more subtle techniques involve sending a payload to a vulnerable service to in order to make it behave in a way to exhibit vulnerable behaviour that can be detected via its returned responses. The trick here is to send a series of data and requests to the service, and to check the responses of each for discrepancies. The difficulty lies in the fact that the requests sent cannot be simply random bytes, they must be lexically correct within the protocol that the server is running on that port because the server needs to “understand” what you send. A process of fuzzing can therefore be used in certain types of infrastructure scanning, whereby a large number of very slightly different requests are sent, one after the other, and the differences in responses observed.
The sweet spot for this type of scanning lies in a narrow band of request forms that are sufficiently valid to be recognised and responded to by the server, but sufficiently unexpected to elicit a response not planned by the service author.
In the correct environment and given enough information, infrastructure scanning can detect the majority of vulnerabilities with an infrastructure device or service that has a published vulnerability in the CVE database. This can include very serious vulnerabilities, such as remove code execution (RCE) vulnerabilities that allow complete compromise of the affected device by an attacker.
Common vulnerabilities detected during the infrastructure scanning phase include; missing operating system patches, weak administrative passwords and access control vulnerabilities.
Infrastructure scanning can be somewhat prone to false positives in some situations, since the scanning is performed in a “black box” fashion in which the scan hub does not have privileged access, and so is attempting to tease out very subtle differences in responses, which can be prone to error. It can also be unsafe to attempt to exploit a vulnerability to positively determine its presence without negatively impacting a scanned device, so to be safe the scan hub may report a vulnerability as potential only, and not seek to positively determine its presence if this cannot be done without guarantee of safety to the target involved.
However, infrastructure scanning can – optionally – also be configured to be performed in a more privileged “credentialed” mode. In this mode, the organisation provides the scan hub service with authentication credentials for the targets being scanned. The scan hub is then able to connect to a host in an authorised/privileged fashion and to perform active queries of the host from an authenticated (trusted) perspective not available to an attacker. This permits the scan hub both to find more vulnerabilities, as well as with a greater assurance/certainty in the presence of discovered vulnerabilities being false positives. It is able to do this based on performing interrogations directly on the target device, in order to discover information such as installed binaries/applications, even where these are not exposed on the network and hence not discoverable to a scan hub with unprivileged network-based access to the target only.
AppCheck help you with providing assurance in your entire organisation’s security footprint. AppCheck performs comprehensive checks for a massive range of infrastructure as well as web application vulnerabilities from first principle to detect vulnerabilities in in-house application code. Our custom vulnerability detection engine delivers class-leading detection of vulnerabilities and includes logic for multiple detection methods.
The AppCheck Vulnerability Analysis Engine provides detailed rationale behind each finding including a custom narrative to explain the detection methodology, verbose technical detail, and proof of concept evidence through safe exploitation.
AppCheck is a software security vendor based in the UK, offering a leading security scanning platform that automates the discovery of security flaws within organisations websites, applications, network, and cloud infrastructure. AppCheck are authorized by the Common Vulnerabilities and Exposures (CVE) Program as a CVE Numbering Authority (CNA).
As always, if you require any more information on this topic or want to see what unexpected vulnerabilities AppCheck can pick up in your website and applications then please get in contact with us: info@appcheck-ng.com
No software to download or install.
Contact us or call us 0113 887 8380
