Menu
Automated vulnerability scanning or automated penetration testing can be an invaluable approach for organisations looking to gain assurance in their organisation’s security posture. However, there can often be confusion as to exactly what automated vulnerability scanning entails, how it is conducted, and how it differs from alternative methodologies such as penetration testing or static code analysis.
In this blog post we provide a high-level summary or overview of what automated vulnerability scanning entails, and how it can help provide assurance in the security posture of an organisation, reducing the likelihood of any security exploits occurring.
Vulnerabilities are flaws in a computer system or one if its operated services that weaken the overall security of the system. Vulnerabilities can be weaknesses that occur at many levels, including the underlying hardware, the operating system that runs on that hardware, or application software that runs in order to provide a specific service (such as serving a web application).
Vulnerabilities exist as potential in that the existence of a vulnerability does not necessarily mean that an organisation has suffered direct harm yet: they are weaknesses that collectively represent what is known as the attack surface of a system or organisation – points at which an attack could occur. A security incident occurs when a vulnerability with one or more known instances of working exploits that are able to leverage them are available, and there is a suitably positioned attacker that is ready and willing to take advantage of them.
Vulnerabilities can occur due to weaknesses present in computer infrastructure, in the code running on that infrastructure, within the configuration that the code references (such as environmental configuration variables) or in data itself.
The root causes of vulnerabilities are manifold, but can include factors such as: the complexity of estate causing an attack surface to be inadvertently created; there being excessive connectivity lacking in appropriate access control or restriction; mistakes made in configuration; unchecked, unexpected or unvalidated user input; underlying design flaws at the architectural or code levels; and mistaken assumptions as to safe usage, or unexpected boundary conditions being encountered during code execution.
Vulnerabilities exist in a potential or limbo state, as exploitable weaknesses in a system. They are therefore somewhat of a ticking time bomb – but with the opportunity for them to be disarmed before they can cause harm. An attacker who exploits a vulnerability to violate the security of a system has performed a successful attack and the organisation in question has suffered a security incident. However, organisations have the opportunity to detect weaknesses in their own systems before attackers do. Often this can involve usage of the same tools as attackers make use of. However, organisations have the “upper hand” since they can potentially detect weaknesses before they are introduced to production systems, as we shall see shortly.
The primary purpose of vulnerability assessment is to find any vulnerabilities in a target system or systems. Once discovered, vulnerabilities can be summarized in an assessment report and action taken to triage, prioritise and remediate (or mitigate) them on a priority basis. A vulnerability assessment can also be used to conveys to stakeholders such as senior management or shareholders that an organisation’s system are appropriately secured from vulnerabilities: this can provide security assurance as part of a programme of responsible corporate governance, due diligence, or compliance fulfilment. Vulnerability assessment provides assurance both that systems do not contain weaknesses, as well as confirmation that technical controls (equipment and services such as firewalls that are intended to provide cyber defense) are operating as expected in preventing system exploit.
Vulnerability assessments are typically performed as part of a broader vulnerability management programme: a cyclical practice that contains common processes including assets/system inventorying and prioritisiation, the ongoing assessment for vulnerabilities, the production of a report on vulnerabilities found, followed by the remediation of those vulnerabilities before verification and beginning the cycle afresh.
Vulnerability assessment covers various methods for identifying and classifying the weaknesses in an organisation’s information technology systems. It can be performed using a number of methods at different stages of the Software Development Lifecycle (SDLC) – and in fact a robust vulnerability management programme would include many different assessment and detection methods throughout the software development process in larger organisations. Assessment techniques include methods such as pair programming, code review, static code analysis and network-based vulnerability scanning and assessment known as Dynamic Analysis Security Testing or DAST.
In a network-based vulnerability assessment, vulnerabilities are detected by a process known as vulnerability scanning. This scan either locates (or is provided with a list of) systems on a network, which are designated as the scan targets. The scanner then determines what network services are in use on these targets and analyzes those services for potential vulnerabilities using various techniques that we shall describe below. The CIS (Centre for Internet Security) Critical Security Controls for Effective Cyber Defense designates continuous vulnerability scanning as a critical control for effective cyber defence.
Vulnerability scanning is a very flexible process that can actually be performed at several stages in the software development lifecycle. Traditionally, vulnerability scans were performed “late” in the SDLC – that is, scanning production systems once they are running a live service and after code is developed and deployed. This is still the most common timepoint at which scanning is performed, often on a repeated and ongoing basis in order to provide continuous assessment and ongoing assurance that there has been no regression or introduction of a new vulnerability via newly deployed code or changes to systems.
However, newer technologies and methodologies that are increasingly being adopted by many organisations mean that vulnerability scanning is also increasingly being extended into earlier stages of development. This can involve the scanning of local (development) instances before code is pushed or merged, as well as during the deployment process itself (via Continuous Deployment or Continuous Integration platforms such as Jenkins or Travis) as well as the traditional scanning of systems in production after code has been deployed.
Vulnerability scan assessments can be run on a set periodic basis, as well as in an ad hoc or on-demand fashion in order to verify that vulnerabilities that are believed to have been fixed were actually resolved or not. This cycle of assess, patch, and re-assess has become the standard method for many organizations to manage their security issues.
Vulnerability scans work on a client-server model. That is, there is a vulnerability scanner which acts as a “client”, making requests across a network to target systems (servers). These requests can consist of a number of different protocols at different layers of the TCP/IP stack or internet protocol suite.
Modern vulnerability scanners allow for both authenticated and unauthenticated scans. In an unauthenticated scan, a vulnerability scanner simply makes requests as an attacker would, with no privileged access to target systems. In an authenticated scan, a vulnerability scanner is provided by an organisation with credentials that allow it to authenticate to a target system or service, meaning that it can actively query that system from a trusted perspective, allowing it to detect more issues.
A vulnerability scan works by (safely) simulating attacks against a system. However, when a vulnerability scan begins, it has insufficient information to do so effectively: the only information that it has is the “target” that it should scan. The first thing that it does therefore is try and find out as much as it can about the target, in the same way that the military would when planning a mission, or that a criminal might if targeting a building for attack. There’s no use in turning up to attack something if you don’t bring the correct tools or ordnance for the target in question.
In the first stage of a network vulnerability assessment, a scanner will therefore perform a process known as Open-Source Intelligence Gathering (OSINT) to harvest and collect further information on a target. During this discovery phase of the scan, multiple open-source intelligence databases are consulted to learn as much about the target system as possible. For example, host names registered to the target IP address, web components indexed by search engines, and historical network data. Data that is in scope for the scan is then seeded into the scan configuration.
In the second stage of assessment, infrastructure scanning is used to identify vulnerabilities on each accessible network device. The scan begins by port scanning each IP address within the target scope, to identify accessible services. Each identified service is then probed for vulnerabilities using tens of thousands of checks. Identified systems are checked for known vulnerabilities using a regularly updated vulnerability database that combines well known sources such as the National Vulnerability Database (NVD) with our own internally-maintained vulnerability feed.
In the final stage of assessment, any targets running a web service are subjected to methodical security testing via a web application scan. HTTP is just one of many protocols and service types that are operated, but because of its ubiquity, it warrants an entire stage of assessment to itself, and a lot of effort is put into detecting vulnerabilities in these web services. 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
This stage of the assessment process works from first principles. What we mean by this is that vulnerabilities in bespoke systems such as in-house developed web applications cannot be detected in the same way as infrastructure vulnerabilities. This is because vulnerabilities in in-house applications are not yet known and not published to a national database. With custom code there is no “signature” (response pattern or data) to detect a vulnerability, so it requires different approach.
A web application scanner will therefore look for a range of potential exploits within a targeted web application by operating under “first principles.” When we talk about first principles, what we mean is that a methodology is adopted of going through a workflow by exhaustively testing hundreds or thousands of query variants to tease out potential vulnerabilities that were not previously known about. This careful probing is known as fuzzing (varying inputs to a web system and observing differences in responses). This is a complex challenge and Dynamic Application Security Testing (DAST) is needed. This approach takes each user supplied data component in a webpage, such as a form field of query string parameter, then modifies it to include a specific test case before submitting it to the server. A web application scan can assess thousands of pages, and the scanner can understand, and process, JavaScript and HTML returned from the server in order to render webpages natively and locally. Web application scans can intelligently submit “attack payloads” in requests in order to tease out vulnerabilities in a web application. Based on the application’s response, further test cases are then submitted through the same method to confirm the vulnerability.
This third and final stage of web application scanning is sufficiently complex that it is worth breaking down a little further to see how it is performed by an automated scanner.
Before a scanner can test a target web application for vulnerabilities, it must first build up a map of the site so that it knows what pages exist and therefore need testing for vulnerabilities, before going on to then simulate attacks against the target (in a safe manner). The scanner builds up this map through a combination of crawling (following links from the root/main page of the site defined in the scan) and by brute-forcing (guessing paths that there are no explicit links to, but which may contain hidden content and be navigated to directly by requesting a specific URL, at common locations such as “/admin”.
In the first step, a browser-based “crawler” navigates the target site or application in a “human-like fashion.” Crawling involves exploring and building a “map” of a target site, by following hyperlinks on pages from the “starting page” that is set for the scan – if no specific path is set, then the scanner will start navigating at the root “/”. The aim here is to produce a map of the website and find out its extent. It is also worth bearing in mind that during this early phase, the scanner is not checking for vulnerabilities, it is simply preparing the way for later scan steps.
In the next step, a web application scanner will then use a “page scraping” crawler to perform less sophisticated crawling (not making use of a full browser instance and rendering the presented user interface as in the former step) whereby the raw HTML (code) of each page is automatically “scraped” to find hidden HTML components, in order to discover components. This crawler is less sophisticated but helps discover components that are within the page but aren’t rendered to the user so are invisible to the more sophisticated browser-based crawler.
In step three “forced browsing” and search engine-based discovery is performed. In the forced browsing discovery, the scanner will attempt to find areas of the targeted site that are not linked to from other pages but can only be accessed by direct navigation (i.e., requested directly). It will do this by attempting to guess the location of common components such as admin interfaces, and components that may have security flaws but aren’t linked within the application – for example it may be reasonable to check for “hidden” unlinked pages at paths such as “/admin” or “/login” etc. The process iterates through lists of potential directory and file names and tries them against the server.
Components identified in the previous stages are then passed into the “attack” phase. This phase is where the main testing process begins and delivers the bulk of vulnerability detection. Each query string parameter, form, JSON body and in some cases HTTP header is subject to testing. For each test, the value within the parameter is changed from that which the server is expecting to include a “test case” value and then resubmitted to the application in a process known as “fuzzing”. The response to each specific request variant is then analysed by the scanner to determine if the test case warrants further investigation based on the response: if so, then further tests are conducted to determine if there is a security flaw.
The type of scanning we have outlined above is often referred to as “Dynamic Application Security Testing (DAST)” – the dynamic part indicates that it is often used to test a live, running instance of an application, in contrast to offline static analysis of source code (an alternative form of testing). The dynamic testing of a live web application or service does make automated vulnerability scans similar in some ways to a manual penetration test. However, although much of the methodology is common to both, automated vulnerability scans and penetration tests are not directly equivalent.
The fundamental distinction is that a penetration test is performed manually, and by a human. An automated vulnerability scan requires minimal initial configuration by a human, but afterwards can be executed – and executed repeatedly – by an automated scanner. Automated vulnerability scanning delivers ongoing and repeatable assessment and offers far greater scalability and speed of testing than a human tester. Penetration testing and vulnerability scanning are typically seen as complimentary offerings – i.e., both should be performed – rather than directly comparable substitutes or competitors with one another. The table below summarises some of the main differentiators:
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
