Thanks to visit codestin.com
Credit goes to github.com

Skip to content

CodeQL query to detect open Spring Boot actuator endpoints #2901

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 7 commits into from
Apr 29, 2020
Merged

CodeQL query to detect open Spring Boot actuator endpoints #2901

merged 7 commits into from
Apr 29, 2020

Conversation

ggolawski
Copy link
Contributor

This PR adds a query to detect open Spring Boot actuator endpoints. It flags custom Spring Security configurations that allow unauthenticated access to an actuator endpoint, like this one:

@Configuration(proxyBeanMethods = false)
public class ActuatorSecurity extends WebSecurityConfigurerAdapter {

  @Override
  protected void configure(HttpSecurity http) throws Exception {
    // BAD: Unauthenticated access to Spring Boot actuator endpoints is allowed
    http.requestMatcher(EndpointRequest.toAnyEndpoint()).authorizeRequests((requests) ->
        requests.anyRequest().permitAll());
  }
}

Unauthenticated Spring Boot actuators may leak sensitive information or even lead to remote code execution: https://www.veracode.com/blog/research/exploiting-spring-boot-actuators, https://spaceraccoon.dev/remote-code-execution-in-three-acts-chaining-exposed-actuators-and-h2-database.

Test cases are also added, but without the .expected file.

@ggolawski ggolawski requested review from felicitymay and a team as code owners February 23, 2020 19:23
@ggolawski ggolawski mentioned this pull request Feb 23, 2020
Closed
1 task
@aschackmull
Copy link
Contributor

Apologies for the delay in reviewing this PR. We think this is a useful contribution but it will likely require a number of changes before we can accept it into our standard query set.

In order to streamline our review process going forward, we are now accepting experimental contributions. If you'd like to move this query into the experimental directory as per those guidelines, then we'll be able to proceed more quickly with this PR.

Otherwise the query looks mostly good, although I'd like to see at least one result on some project to verify the applicability of the query. As for the documentation, it is claimed that this can "lead to information disclosure or even to remote code execution" - it would be nice to include some references or explanation to document how this happens.

@aschackmull
Copy link
Contributor

We tried running this across all of lgtm.com https://lgtm.com/query/483327956475899158/ and got zero results.

@ggolawski
Copy link
Contributor Author

I've moved the query to experimental and added the reference to an article that describes how to exploit this to get RCE (https://www.veracode.com/blog/research/exploiting-spring-boot-actuators).

When you search for EndpointRequest.toAnyEndpoint() in GitHub and exclude test classes, you'll get 2K results (https://github.com/search?l=Java&p=36&q=EndpointRequest.toAnyEndpoint%28%29+-filename%3A%2ATests.java&type=Code), but indeed mainly in demos and samples. I was pretty sure that this kind of misconfiguration is much more common. Anyway I think that I could find some 'real' projects (I'm not sure about this, so please verify):

These projects are not available on LGTM, but the actuators are exposed in the same as in my test code, so my query should detect these issues.

@aschackmull
Copy link
Contributor

Thank you very much for those references. This definitely helps our evaluation.

@ggolawski
Copy link
Contributor Author

Thanks for the suggestion. I've committed the change.
I've also added stubs, qlpack.yml and expected results, so the test for the query is runnable via codeql test run.

Please verify if everything is fine, especially qlpack.yml files - I had to add them in src/experimental and test/experimental.

@ggolawski
Copy link
Contributor Author

I've removed qlpack.yml files - I've realized that they're not needed.

aschackmull
aschackmull approved these changes Apr 29, 2020
View reviewed changes
Copy link
Contributor

@aschackmull aschackmull left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot for adding the working test. This looks ready to merge.

@aschackmull aschackmull merged commit 29a5ea1 into github:master Apr 29, 2020
@ggolawski ggolawski deleted the java-spring-boot-actuators branch April 30, 2020 18:25
pwntester
pwntester reviewed May 15, 2020
View reviewed changes
java/ql/src/experimental/Security/CWE/CWE-016/SpringBootActuators.qll
Comment on lines +88 to +97
predicate permitsSpringBootActuators() {
exists(AuthorizeRequestsCall authorizeRequestsCall |
// .requestMatcher(EndpointRequest).authorizeRequests([...]).[...]
authorizeRequestsCall.getQualifier() instanceof RequestMatcherCall
or
// .requestMatchers(matcher -> EndpointRequest).authorizeRequests([...]).[...]
authorizeRequestsCall.getQualifier() instanceof RequestMatchersCall
or
// http.authorizeRequests([...]).[...]
authorizeRequestsCall.getQualifier() instanceof VarAccess
Copy link
Contributor

@pwntester pwntester May 15, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ggolawski this clause seems to be causing many FPs where there are no evidences that Spring Actuators are being used.

See results here https://lgtm.com/query/4456298315122374638/

If EndpointRequest is not used, we need a different way to know that Actuators are indeed enabled.

Having said that, those results may be of interest for a different query in the line of https://vulncat.fortify.com/en/weakness?q=spring%20security%20misconfiguration

Also, for lines 91 and 93 there are some FPs in the form of:

http.authorizeRequests().requestMatchers(EndpointRequest.to("info", "health")).permitAll();

which could be solved by checking that TypeEndpointRequestMatcher matches only EndpointRequestMatcher returned by toAnyEndpoint() or by to() if arguments contains an edpoint other than health and info which are of no interest and public

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for spotting this. My intention was to raise the flag only if EndpointRequest.toAnyEndpoint() is being used. I'll check what's wrong and correct this query.

@ggolawski ggolawski mentioned this pull request May 18, 2020
Merged
@ggolawski
Copy link
Contributor Author

@pwntester I fixed these FPs in #3506. Please check it.

@pwntester
Copy link
Contributor

Awesome, thanks!

@iamvolvo
Copy link

iamvolvo commented Jan 9, 2025 •
edited
Loading

Hi there, have you considered promoting this out of experimental?

Recent news suggest this is something companies sometimes get wrong and should be concerned with. See:

@jcogs33 jcogs33 mentioned this pull request Feb 25, 2025
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@pwntester pwntester pwntester left review comments

@aschackmull aschackmull aschackmull approved these changes

@felicitymay felicitymay Awaiting requested review from felicitymay

Assignees
No one assigned
Labels
Java
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@ggolawski @aschackmull @pwntester @iamvolvo