There is a huge category of different vulnerabilities that arises due to ineffective or absent control and relates to insecure design practices. Those vulnerabilities are found in various systems, including software, applications, network protocols, and hardware devices, and are a major concern nowadays.
Having insecure design practices imposes significant consequences on businesses, including but not limited to data breaches, legal penalties, reputational damage, and customer trust. This is why, it is important to understand the causes and types of insecure design implementation to develop an application that can defend itself from known attack vectors.
In this article, we will discuss what makes a software design insecure and how to convert it into secure design patterns with required security controls and eliminate different weaknesses and associated security risks.
Such vulnerabilities occur when software does not create changes, verify or track the privileges of users and therefore allows them to modify their privileges without proper authentication.
Similarly, in the case of FortiADC an authenticated web console user with read-only access could use fnsysctl to execute system commands and upload arbitrary files onto the FortiADC appliance via its FTP client. This allows an attacker to modify the web interface and change application behaviour.
The FPD_Image_Utils::sanitize_filename() method from fpd-image-utils checked the filename for a malicious extension and then sanitised it, removing the special characters and spaces.
An attacker could upload a malicious .php file with a filename and extension such as “webshell.p h p” and bypass the extension check as the “.php” file extension was not considered a malicious extension.
Afterwards, when the filename was sanitised, all special characters and spaces were removed, and the uploaded file resulted in webshell.php being uploaded onto the server.
A secure development lifecycle can be integrated at various stages of the application development process, including during the initial design phase, during the development phase, or post-production. However, it is optimal to incorporate it from the beginning to reduce architectural flaws along with cost, time, and compliance complications.
Incorporating security into the SDLC enhances software security, assists in defending against specific attacks, evaluates threats and promotes a culture of awareness and compliance with security regulations and standards, which is critical for many industries.
Typically, SSDLC has the following stages.
The purpose of performing threat modelling secure design is to map out the weaknesses and gaps in the reference architectures, which can offer an attack path to the threat actors. Each asset, application, system feature, and functionality is analysed using threat models to identify possible attacks. For each identified weakness, a control or remediation is offered to prevent the threat via risk management and assessment.
For example, suppose the application design has a vulnerability that could allow an attacker to have remote access. Through performing a threat model, security teams can investigate what immediate privileged access the attack would get after compromising the application. What security controls can be put in place to block remote accesses? How the application can have an access control mechanism to verify unauthorised or unauthenticated access, etc.?
All such scenarios to evaluate threats are taken under consideration by security teams while performing threat modelling. It also involves performing risk assessment and resource management on the assets to provide a clear picture of all the ineffective control design, loopholes and implementation defects leading to insecure design patterns.
What are insecure design vulnerabilities?
Insecure design vulnerabilities refer to the risks arising from design and architectural flaws that have not been considered at the beginning of the software development lifecycle. Since application design is one of the initial stages of SDLC, if designed securely can lead to perfect implementation and, later on, better coding. Such weaknesses can be more difficult to detect and fix, as they inherently affect the secure design patterns and overall application or system.Examples of insecure design vulnerabilities
Numerous vulnerabilities arise due to insecure design flaws; some of the common weaknesses enumerations (CWE) that exist because of a lack of secure design practices are:CWE-73: External control of file name or path
Design flaws like this could allow attackers to control file names or paths externally. By identifying and exploiting this design vulnerability, an attacker might be able to obtain privileges to modify or overwrite files.CWE-501: Trust boundary violation
Often applications are designed without the controls to differentiate between trusted and untrusted data and thus merge them into the same data structure. Such security vulnerabilities eventually lead to trust boundary violations and various injection attack vectors.CWE-209: Generation of error message containing sensitive information
It has been observed that applications and systems often display error messages containing sensitive information about their environment in response to invalid inputs and queries. This is often dangerous because it breaks the confidentiality of user data and other sensitive information, increasing the attack surface.CWE-269: Improper privilege management
Improper implementation of access to track, modify, create, or verify privileges allows a malicious user to gain unauthorised access.CWE-312: Cleartext storage of sensitive information
Clear text or unprotected storage of sensitive information compromises the confidentiality of application data and allows attackers to read them.Read world insecure design attack
FortiADC – read-only user able to modify system files (CVE-2021-43076)
A vulnerability, traced to CVE-2021-43076, was found in the Fortinet FortADC due to insecure design practices of privileges management. The vulnerability could allow remote users with a restricted user profile to modify the systems files using shell access.
Such vulnerabilities occur when software does not create changes, verify or track the privileges of users and therefore allows them to modify their privileges without proper authentication.
Similarly, in the case of FortiADC an authenticated web console user with read-only access could use fnsysctl to execute system commands and upload arbitrary files onto the FortiADC appliance via its FTP client. This allows an attacker to modify the web interface and change application behaviour.
The fancy product designer WordPress plugin (CVE-2021-24370)
The Fancy Product Designer plugin of WordPress had an insecure design vulnerability that allowed an unauthenticated user to upload arbitrary files. The vulnerability tracked to CVE-2021-24370, lay in the sanitisation of filenames when they were being uploaded to the server.
The FPD_Image_Utils::sanitize_filename() method from fpd-image-utils checked the filename for a malicious extension and then sanitised it, removing the special characters and spaces.
An attacker could upload a malicious .php file with a filename and extension such as “webshell.p h p” and bypass the extension check as the “.php” file extension was not considered a malicious extension.
Afterwards, when the filename was sanitised, all special characters and spaces were removed, and the uploaded file resulted in webshell.php being uploaded onto the server.
How can you prevent and eliminate insecure design vulnerabilities?
Eliminating insecure design vulnerabilities is quite easy compared to other security flaws. It involves identifying and addressing design and application architecture weaknesses that may create opportunities for malicious attackers to tamper with applications, business logic, and critical flows to achieve their desired goals.Secure development lifecycle
The secure development lifecycle is a framework that integrates security countermeasures throughout the entire software development process. It describes how software should be built, developed, and released to minimise risks and maximise security. The SDLC helps software developers and businesses in embedding security controls in each development phase.
A secure development lifecycle can be integrated at various stages of the application development process, including during the initial design phase, during the development phase, or post-production. However, it is optimal to incorporate it from the beginning to reduce architectural flaws along with cost, time, and compliance complications.
Incorporating security into the SDLC enhances software security, assists in defending against specific attacks, evaluates threats and promotes a culture of awareness and compliance with security regulations and standards, which is critical for many industries.
Typically, SSDLC has the following stages.
- Requirements
- Design
- Coding
- Testing
- Maintenance
Threat modelling
Threat modelling is a security technique to determine potential security threats and possible attacks on software or systems. It is typically performed when the security and business requirements are collected and the software design phase is completed.
The purpose of performing threat modelling secure design is to map out the weaknesses and gaps in the reference architectures, which can offer an attack path to the threat actors. Each asset, application, system feature, and functionality is analysed using threat models to identify possible attacks. For each identified weakness, a control or remediation is offered to prevent the threat via risk management and assessment.
For example, suppose the application design has a vulnerability that could allow an attacker to have remote access. Through performing a threat model, security teams can investigate what immediate privileged access the attack would get after compromising the application. What security controls can be put in place to block remote accesses? How the application can have an access control mechanism to verify unauthorised or unauthenticated access, etc.?
All such scenarios to evaluate threats are taken under consideration by security teams while performing threat modelling. It also involves performing risk assessment and resource management on the assets to provide a clear picture of all the ineffective control design, loopholes and implementation defects leading to insecure design patterns.
Implement system and network layer tier segregation
For the perfect implementation of the secure design pattern, there must be an appropriate level of segregation across the systems and network tier layers. The segregation might depend on how efficiently the organisation can manage their business risk profiling, resource consumption, and other technical requirements. Nonetheless, doing so makes it easier to restrict access control to resources, and if one layer suffers any incident, it will not escalate or damage the other.Conclusion
Insecure design weaknesses arising from implementation defects can be mitigated in several ways, but it is important to ensure that security controls are considered throughout the design process. Incorporating risk mitigation strategies during the secure design phase is essential to implementing “Shift Left” security practices. Furthermore, it is important to carry out thorough security testing and review during the development process, including both automated and manual unit and integration tests, to ensure risks related to design security are robustly managed. Get in touch with us to discuss your security concerns and risks related to security implementation or the secure development lifecycle.
Shahrukh, is a passionate cyber security analyst and researcher who loves to write technical blogs on different cyber security topics. He holds a Masters degree in Information Security, an OSCP and has a strong technical skillset in offensive security.
