Application SecurityCode FightersNews

Research: CVE-2021-43076 and the Risks Caused by Insecure Design

In the latest edition of OWASP TOP 10 Vulnerabilities 2021, some new categories were introduced in their classifications. In this article, we will address A4 – Insecure Design.

This category would be related to the risks of a poorly formulated or incorrectly planned architectural structure – covering good development practices.

A good option is the so-called shift-left, which comprises the use of security concepts already in the first moments of the design of an application, prioritizing mainly actions such as the execution of Threat Modeling and, thus, pointing out several requirements enumerate the possible resources within the application.

The category also exposes the numerous weaknesses that an application could present in the issues of its construction, aiming to cover the simple generation of error messages, storage of credentials, and other limits of trust of the software.

There are dozens of CWEs related to this topic, addressing inappropriate use of APIs, application functions, execution of incoming commands in URLs (IDOR), integrity in application communication, and many other weaknesses, as in the case of CVE-2021-43076 explained later.

Insecure Design can result in severe consequences, as attacks of this nature can interfere with the logical execution of the application and result in possible leaks of sensitive data.

Case study

A vulnerability has been identified in the Fortinet Product – FortiADC, classified as [CWE-269] improper privilege management. This weakness can be classified as A4 – Insecure Design.

Generally speaking, you can access a CLI and use fnsysctl to do many things, for example, upload files using FTP and place HTML files on the file system. The main problem is privilege escalation, which consequently can bring other problems. In this case, it is possible to use commands like mv and cp, where an attacker, authenticated with a restricted user profile, can modify the system files using shell access.

But what would be the design error in this case? Initially, it was identified that Fortinet provides a custom Unix command called fnsysctl. It is used in some instances, for example, to configure 3g and 4g modems in Fortigate.

This same command was identified in FortiADC, allowing some critical actions, as in the case of an upload via FTP. Therefore, to exploit the vulnerability, the following steps were taken:

  1. Access with a restricted user;
  2. Web access console of the equipment;
  3. Execution of the fnsysctl command;
  4. Execution of the command fnsysctl ls /, to list the system files.
  5. Execution of the command fnsysctl FTP client, to upload malicious files with the same name as the system files.
  6. Upload malicious files in the temp folder.
  7. Execution of fnsysctl mv Source > destination to move files inside FortiADC.

As a result, we identified the following impacts:

  • Moving files with the restricted user;
  • Modification of the web interface;
  • Changing some application behaviors.

And the solutions are:

  • Upgrade to FortiADC version 6.2.2 or higher.
  • Upgrade to FortiADC version 7.0.0 or higher

Mitigations

To avoid insecure design vulnerabilities, it is necessary to consider security aspects from the early stages of software development, ie: requirements analysis, software architecture, development, testing, and implementation.

It is also essential to implement secure processes from the beginning of the project. We are talking here about the practice known as Shift-Left, which consists of moving the beginning of the testing phase to the left, that is, instead of tests occurring only in the final phase of the treadmill, the tests start to hang throughout the development cycle.

OWASP recommends many measures that should be taken into account to prevent insecure design vulnerabilities from occurring, such as:

  • Implement an AppSec program to assess and design security and privacy controls.
  • Use automated tools for code analysis such as SAST, SCA, and DAST.
  • Perform threat modeling on critical processes to identify potential attack vectors.
  • Use only up-to-date and reliable libraries.
  • Implement security controls at different layers of the architecture.
  • Consider the concept of least privilege when defining user permissions.
  • Conduct unit tests to validate security requirements on critical application functions considering the threat model.

In addition to the points listed above, a great ally in the secure development process is the OWASP SAMM framework, which was designed to provide a set of security practices that meet the entire software lifecycle considering different levels of maturity.

It is worth emphasizing that no application is completely secure. However, during software design, we must make sure that the design of the project implements security best practices. Using a secure development cycle, paying attention to standards, and performing periodic testing, all contribute to creating a reliable and mature application.

Authors:
Fernando Vasques – Information Security Analyst
Danilo Costa – Appsec Consultant
Luiz Henrique Custódio – Application Security Analyst 

Nova call to action
About author

Articles

A team of professionals, highly connected on news, techniques and information about application security
Related posts
Application Security

Design according to SAMM: Threat Modeling in Application Security

In this article, we will approach threat modeling according to the Software Security Maturity Model…
Read more
Application Security

Design according to SAMM - Secure Architecture in Application Security

“The security architecture practice focuses on managing architectural risks for the software…
Read more
Application SecurityProduct

AppSec: Integrations with CI/CD tools through Conviso Platform

Within development teams, managing results in CI/CD tools, getting visibility, continuous feedback…
Read more

Deixe um comentário