process
At 10 o ‘clock in the morning of March 4th, I suddenly received problem feedback and pre-sent the environment gateway back to interface 500.
Log in to the gateway service of the pre-delivery environment and find the following error:
java.lang.IllegalArgumentException:a header value must not end with '\r' or '\n':uid=0(root) gid=0(root) groups=0(root)
Copy the code
ResponseHeader () {return ResponseHeader () {return ResponseHeader (); At that time, some functions need to be accepted and tested in the pre-delivery environment. In order not to delay the progress, the gateway service is directly restarted. After the restart, the gateway service is restored. Because the key to the problem was not found and the Gateway started normally, there was no error log. I decided to watch for a while longer.
The Header value is the result of a Linux command. After searching for and testing the Header value, it turns out to be the result of a Linux command.
At this point, I haven’t thought of it as a security issue. Just keeping an eye on it. When it came to 3pm that day, the same problem appeared again in the pre-delivery environment. This time, AFTER LOGGING in the application log, I found a new error:
I looked up the I.P. address as you.s. Suddenly realized there might be a cyber attack.
To view the stack and found abnormal from org. Springframework. Expression. The spel package. SPEL is an expression language provided by Spring, which can run expressions in code or even call Java libraries. In this case, the runtime.exec () method is called to execute system commands. This explains the morning’s exception stack.
So how does an attacker use SPEL to implement remote code execution?
A web search for spEL + Spring Cloud Gateway + execution vulnerability yielded a report. We found that the Gateway version we used, 3.0.3, was right in the range.
As recommended in the report, the SpringCloudGateway Actuator module in the preconfigured environment is disabled. After the service is restarted, no exception occurs.
The principle of
The article was found in the follow-up problem tracing process
The records are as follows:
First: StandardEvaluationContext classes can be arbitrary execution spel within the # {} expression. Once the execution point of the code execution vulnerability is found, what behavior causes the method to be executed?
Looking at the method call stack, you can see that this is due to route refresh.
When CachingRouteLocator receives RefreshRoutesEvent,
- Is called
RouteDefinitionRouteLocator.getRoutes()
Methods to obtainRouteDefinition
List of route definitions. - And I’m going to go through each of them
RouteDefinition
, the callconvertToRoute(RouteDefinition)
That will beRouteDefinition
Object converted toRoute
Object and hand overCachineRouteLocator
. During the transformation process, the filters from the route definition process need to be taken out to build real filters. - in
RouteDefinitionRouteLocator.loadGatewayFilters()
In the methodthis.configurationService.with(factory)
Will buildConfigurableBuilder
Here a chain call is used, the name() method is used to record the filter definition name, and the properties() method is used to record the filter definition name as a custom parameter passed in. The bind() method is the way to resolve the “args” in the filter defined by the route.
In the call ConfigurableBuilder. NormalizeProperties () method, is called shortcutType (). The normalize () method to possible Spel expression of generalization, eventually led to the Spel expression is invoked.
conclusion
To sum up, after the refresh mode of the interface of the Actuator is called, the CashingRouteLocator class of the Gateway reloads all cached route definitions after receiving the refresh event, regenerates route objects, and recache them to refresh routes.
In the process of parsing from the RouteDefinition object to the Route object, the system will generalize the possible SPEL expression in the Route definition, which provides the possibility for the remote execution of the code.
Look at the spring cloud gateway v3.1.0 is how to solve this bug: StandardEvaluationContext will originally. Replaced with GatewayEvaluationContext.
lesson
1. Spring Cloud Actuator module is a module used to monitor and manage Springboot applications. After loading the Actuator module, The sub-module can monitor and manage using its own endpoints (use the Actuator’s endpoints annotations to load its own management and monitoring nodes under/Actuator paths). In particular, spring Cloud Gateway uses the Actuator’s own endpoints to add and refresh routes. Therefore, even without the copper leakage, directly exposing a path with such permissions to the public network is very dangerous. Specifically, exposing any service that does not require authentication to the public network is dangerous.
2. Spring Boot provides spring-Security components to provide security services, so once our services need to use the Actuator to achieve management and monitoring, we must also load the Spring-Security module to ensure application security. Unless the service is publicly unreachable.