This week, we have two new vulnerabilities: firstly, the big news in the Spring4Shell zero-day vulnerability in the Spring Framework coming hot on the heels of the recent Log4Shell vulnerability, and secondly, a vulnerability in the CRI-O container runtime that allowed host access to attackers. We also feature a guide to REST API security and an article on why API security is essential even if you are using an API gateway.
Vulnerability: Spring4Shell zero-day vulnerability in Spring Framework
Hot on the heels of theย log4shell vulnerability in December 2021 comes another shell vulnerability โ this time the affected component is Java-based Core module in the Spring Framework. The vulnerability has been dubbed Spring4Shell/Springshell, and it allowed unauthenticated attackers to trigger a remote code execution (RCE) on target systems. The vulnerability was first discovered by a researcher who posted some sample exploit code which has now been deleted.
The vulnerability has yet to be assigned a CVE but it has been acknowledged by Spring, who have announced the deployment of an emergency patch on Thursday last week in Spring Framework versions 5.3.18 and 5.2.20 through Maven Central. Although of concern as an RCE vulnerability, initial reports suggest this may not be as severe as the log4shell vulnerability due to the necessary preconditions for viable exploitation, namely Spring Framework versions 4.3.0 to 5.3.15, Apache Tomcat and JDK 9 or higher, and packaging as a traditional WAR instead of a JAR.
42Crunch covered this vulnerability this week in some depth to demonstrate the benefits of a positive security model toward the reduction of such high severity, zero-day vulnerabilities.
Vulnerability: CRI-O Container Runtime allows attackers host access
This week’s second vulnerability is in the CRI-O container runtime used commonly in Kubernetes installation. The vulnerability, discovered by CrowdStrike researchers, allowed malicious users to gain root access to the underlying host and was rated 8.8 on the CVSS scoring system. The vulnerability has already been patched and users are urged to upgrade their systems.
Using the concept of namespaces, it is possible to set kernel parameters of individual containers and not affect the host itself โ this is a standard safety mechanism to ensure only “safe” parameter changes are allowed. CRI-O version 1.19 introduced a feature that allowed users to override this setting and pass arbitrary parameters to the kernel using the parameter kernel.core_pattern. Unfortunately, this parameter was not validated, allowing an attacker to send arbitrary commands to the host.
This vulnerability is a timely reminder to ensure that hardening patterns and guidelines are applied to complex systems, such as Kubernetes.
Guide: REST API security reference
This week I am pleased to feature my reference card on REST API security, courtesy of the team at DZone. The reference card is intended to be a quick start guide for developers tasked with developing APIs and needing to get a high-level overview of API security. The guide covers the following key topics:
- Introduction to API security
- Foundations of API security
- Secure API life cycle
- Common API attack methods (and defenses)
- Common vulnerabilities
- Best practices for securing APIs
I’m thankful to the team at DZone for the opportunity to work on this guide, and hope that this is a useful contribution to our community.
Article: API gateways need to be supplemented by API security
Finally this week,we have views from Security Boulevard on the need for dedicated API security solutions in addition to any API gateways already deployed โ defense in depth is the best strategy for comprehensive API security.
API gateways are an essential piece of the API security puzzle, providing features such as:
- Inline proxy for control over APIs
- Verifying identities associated with requests through credential and token validation
- Routing of API calls to frontend endpoints and backend services
- Metering of traffic through APIs using rate limiting and throttling
- Additional logging and monitoring.
Whilst all Cloud providers offer API gateway products, they all without exception recommend the use of additional API security products, such as WAFs, WAAPs, or API-specific security products. The fundamental difference between API gateways and API-specific tooling is that the former are operating on endpoints only and are schema-agnostic, whilst API-specific tools are able to inspect API traffic at the payload level. By inspecting API transactions at the schema and operation level, it is possible to restrict and limit data that does not conform to the specification (limiting mass assignment and excessive data exposure vulnerabilities) and restrict invalid operations (use of unknown HTTP verbs). This approach is the fundamental principle of the positive security model: only known good is permitted, and everything unknown is assumed bad and blocked.
A good read on the benefits of the positive security model and the value of a defense in depth approach.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
