You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Java] CWE-016: Query to detect insecure configuration of Spring Boot Actuator #310
List the CVE ID(s) associated with this vulnerability. GitHub will automatically link CVE IDs to the GitHub Advisory Database.
Report
Describe the vulnerability. Provide any information you think will help GitHub assess the impact your query has on the open source community.
Spring Boot is a popular framework that facilitates the development of stand-alone applications and micro services. Spring Boot Actuator helps to expose production-ready support features against Spring Boot applications.
Endpoints of Spring Boot Actuator allow to monitor and interact with a Spring Boot application. Exposing unprotected actuator endpoints through configuration files can lead to information disclosure or even remote code execution vulnerability.
Rather than programmatically permitting endpoint requests or enforcing access control, frequently developers simply leave management endpoints publicly accessible in the application configuration file application.properties without enforcing any access control through Spring Security.
This is a very common issue and is also one of the highest rewarded vulnerabilities on the HackerOne platform. The query detects this issue in Spring Boot projects with Maven and application.properties, which is the most widely adopted deployment scenario.
Are you planning to discuss this vulnerability submission publicly? (Blog Post, social networks, etc). We would love to have you spread the word about the good work you are doing
Result(s)
Provide at least one useful result found by your query, on some revision of a real project.
@luchua-bc We've ran your query on lgtm. However, the query does not flag any result. Would you be able to provide at least one result for this query on lgtm (or a local snapshot that you built if there's build problem etc. on lgtm) so that we can assess it? Thanks.
@m-y-mo This is a very common issue and there shall hundreds if not thousands of projects with this issue.
The reason no result is flagged is that the query checks application.properties, which is a Java properties file that is not included in the CodeQL database by default.
To enable this, I added export LGTM_INDEX_PROPERTIES_FILES=true to my local bash .bash_profile. Is there a way to enable properties file inclusion on the LGTM platform then retest?
Thanks for the submission! We have reviewed your report and validated your findings. After internally assessing the findings and the query we have determined this query is not eligible for a reward under the Bug Bounty program for the following reason (from our official rules):
To be eligible for a bounty, queries must be non-trivial, and meet a minimum complexity requirement. More concretely, queries that simply look for one or two AST elements, or that could be easily implemented with a linter or simple grep, may not be considered interesting enough for a bounty. Queries must also be sufficiently general to cover a class of vulnerabilities and may not be tailored to a specific CVE.
A good way to ensure that your queries meet this requirement is to ensure it uses some more advanced analysis, like data-flow or control-flow.
Even though this issue was assessed as being ineligible, we think it could find real security problems, and we appreciate the effort you put writing it, so we'll continue working on your PR, and we would still like to offer you $500.
Activity
ghsecuritylab commentedon Mar 12, 2021
Your submission is now in status SecLab review.
For information, the evaluation workflow is the following:
CodeQL initial assessment > SecLab review > CodeQL review > SecLab finalize > Pay > Closed
m-y-mo commentedon Mar 15, 2021
@luchua-bc We've ran your query on lgtm. However, the query does not flag any result. Would you be able to provide at least one result for this query on lgtm (or a local snapshot that you built if there's build problem etc. on lgtm) so that we can assess it? Thanks.
luchua-bc commentedon Mar 15, 2021
@m-y-mo This is a very common issue and there shall hundreds if not thousands of projects with this issue.
The reason no result is flagged is that the query checks
application.properties, which is a Java properties file that is not included in the CodeQL database by default.To enable this, I added
export LGTM_INDEX_PROPERTIES_FILES=trueto my local bash.bash_profile. Is there a way to enable properties file inclusion on the LGTM platform then retest?@luchua-bc
ghsecuritylab commentedon Mar 23, 2021
Your submission is now in status SecLab finalize.
For information, the evaluation workflow is the following:
CodeQL initial assessment > SecLab review > CodeQL review > SecLab finalize > Pay > Closed
xcorail commentedon Mar 27, 2021
Hey @luchua-bc
Thanks for the submission! We have reviewed your report and validated your findings. After internally assessing the findings and the query we have determined this query is not eligible for a reward under the Bug Bounty program for the following reason (from our official rules):
Even though this issue was assessed as being ineligible, we think it could find real security problems, and we appreciate the effort you put writing it, so we'll continue working on your PR, and we would still like to offer you $500.
Best regards and happy hacking!
ghsecuritylab commentedon Mar 27, 2021
Your submission is now in status Closed.
For information, the evaluation workflow is the following:
CodeQL initial assessment > SecLab review > CodeQL review > SecLab finalize > Pay > Closed
luchua-bc commentedon Mar 27, 2021
Thanks @xcorail for resolving the report.