DAST API logs leaking username/password and custom request headers to unauthorized users
HackerOne report #1765521 by joaxcar
on 2022-11-07, assigned to @greg:
Report | Attachments | How To Reproduce
Report
Summary
When configuring an On demand DAST scan
(see docs) the user configuring the scan can enter both username and password and a list of custom request headers.
Both the password and the custom request headers are masked in the UI, and are not possible to view after being saved (not even by the user who configured the scan). Note that to even be able to view On demand DAST scan
configs a user needs to have at least Developer
access to the project.
But when a scan runs it creates some log files, it seems to differ what type depending on if it is a website scan
or an API scan
. During my testing the API scan
leaks usernames, password and custom headers, while website scans
leak custom headers.
When a user configures a Site profile
(see docs) the user can add headers and password that the docs describe in this way
When configured, request headers and password fields are encrypted using aes-256-gcm before being stored in the database. This data can only be read and decrypted with a valid secrets file.
But they will be present in clear text in job logs accessible by unauthenticated users (on a public project)
As an example, configuring a site profile using a HAR file for API information will when executed leave a log file (/jobs/ID/artifacts/gl-api-security-worker-entry.log) containing the lines
2022-11-07 22:46:05 [DEB] API Security: Setting 'http_password_base64' with value of 'aGVqaGVqaGVq' on app
...
2022-11-07 22:46:05 [DEB] API Security: Setting 'request_headers_base64' with value of 'YXNkOiBhc2Q=' on app
where the base64 values contain password and header values. This file is on a public project accessible by unauthorized users. The same file contains the password and headers in plain text when the site profile is of OpenAPI type
2022-11-07 21:53:22 [DEB] API Security: Payload: {'project': 'ultimatetest7/hen/dast', 'profile': 'Quick-Active', 'runnerOptions': {'httpUsername': '<h1>asd</h1>', 'httpPassword': 'sadfasdf', 'openapi': 'https://webhook.site/8d852063-91a4-4bbb-8a68-27a51f9026c5', 'headers': ['asd: asd'],
You can visit my logs here (this is how the logs are presented, they are accessed through GitLab pages, I have not moved them):
On a website
target the headers are printed in clear text here
https://gitlab.com/ultimatetest7/hen/dast/-/jobs/3287276071
in the job log. But the password is masked, and no artifacts are created.
Steps to reproduce
- Log in as a victim user.
- Create a new public project (you need Ultimate subscription)
- Go to https://gitlab.com/GROUP/PROJECT/-/on_demand_scans/new
- Configure all fields
- When you create the
site profile
makes sure to switch to API. You can fill out with random URLs. It is not important that it works out. It will leak anyway
- Click
save and run scan
- Go to https://gitlab.com/GROUP/PROJECT/-/pipelines
- Click the new pipeline and then click on the DAST job
- When available click browse artifacts
- Open the file named gl-api-security-worker-entry.log
- Your data should now be visible in the log
- Visit the log as an unauthorized attacker in another browser to see that it is leaking
Impact
DAST scan logs leak credentials to deploy environments
Examples
What is the current bug behavior?
Credentials are printed in plain text (or base64) in log files open to all users
What is the expected correct behavior?
Credentials should not end up in the logs
Output of checks
This bug happens on GitLab.com
Impact
DAST scan logs leak credentials to deploy environments
Attachments
Warning: Attachments received through HackerOne, please exercise caution!
How To Reproduce
Please add reproducibility information to this section: