Skip to content

DAST job logs leak session cookies, accessible by unauthenticated users

HackerOne report #1783521 by joaxcar on 2022-11-24, assigned to @greg:

Report | Attachments | How To Reproduce

Report

Summary

The DAST scanner can be configured to scan a server for vulnerabilities using ZAP scanner. To be able to access the target service a developer can configure a site profile containing an Authentication endpoint, username, and password. When the DAST scan is initialized it will visit the configured URL to sign in to the target service and retrieve a session state. A session can either be a session cookie or a local storage object. These session cookies are then used to authenticate in further requests.

There are no guarantee that these session tokens/cookies are invalidated after the scan, and except for active scans there are no warning against running the scanner against production builds. This means that leaking the session token/cookies to an attacker will give the attacker access to the service.

In the pipeline log the session information is initially masked. Right after successful login the logs show

2022-11-24T11:33:51.984 INF AUTH login attempt succeeded
2022-11-24T11:33:51.987 INF MAIN authentication success
2022-11-24T11:33:51.987 INF MAIN auth-session=********; Domain=.joaxcar.com; Expires=2022-11-24 12:33:30 +0000 UTC; HttpOnly; Path=/; Secure, PHPSESSID=********; Domain=joaxcar.com; Expires=2022-11-24 11:43:30 +0000 UTC; Path=/, token=********; Domain=.joaxcar.com; Expires=2022-11-24 12:33:39 +0000 UTC; HttpOnly; Path=/; Secure

But further down in the log file the same session information is used to initiate the ZAP scanner like this

[zap_server] 38467 [ZAP-ProxyThread-23] INFO org.zaproxy.zap.extension.httpsessions.HttpSessionsSite - Setting new active session for site 'joaxcar.com:443': HttpSession [name=auth-session, active=false, tokenValues='']

[zap_server] 38511 [ZAP-ProxyThread-27] INFO org.zaproxy.zap.extension.httpsessions.HttpSessionsSite - Setting new active session for site 'joaxcar.com:443': HttpSession [name=auth-session, active=true, tokenValues='auth-session=123-test-user;PHPSESSID=6b83124e751f25f1c687df291fb419ad;token=123-test-user']

Here you can see the values in plain text. Together with the first output an attacker can now easily recreate the cookies in his/her own browser and access the system.

When doing an active scan there is also an output like this

2022-11-24 10:23:13,030 Starting new HTTP connection (1): 127.0.0.1:53554
2022-11-24 10:23:13,034 http://127.0.0.1:53554 "GET http://zap/JSON/httpSessions/action/setSessionTokenValue/?site=https%3A%2F%2Fjoaxcar.com%2Fscan3.php%3Furl%3Dhttps%3A%2F%2Fwebhook.site%2Fda4bcb03-4cc2-4cbb-9aa0-99654c4faa60&session=auth-session&sessionToken=PHPSESSID&tokenValue=7215d642bc0438875ffeac66efbc8d7c&apikey= HTTP/1.1" 200 15
2022-11-24 10:23:13,035 Cookie found: PHPSESSID - Value: 7215d642bc0438875ffeac66efbc8d7c

Again leaking the session information.

Steps to reproduce

These steps here will use my site https://joaxcar.com/scan3.php which will allow a scan to be run against it and allow any username/password to authenticate. It will give the DAST scanner a cookie PHPSESSID as a session

  1. Log in as a victim user.
  2. Create a new public project (you need Ultimate subscription)
  3. Go to https://gitlab.com/GROUPNAME/PROJECTNAME/-/security/configuration/profile_library#site-profiles and start creating a new site profile name it site1
  4. When you create the site profile makes sure to switch to Website. Also make sure to add authorization in the site profile as it is needed for the job to run.
  5. Set the Target URL and the Authorization URL to https://joaxcar.com/scan3.php , and the username and password to anything. Field names as shown in this image

config.png

  1. Go to https://gitlab.com/GROUPNAME/PROJECTNAME/-/security/configuration/profile_library#scanner-profiles and create a new scanner profile. Check "passive scan" as the mode. name it scanner1
  2. Go to https://gitlab.com/GROUPNAME/PROJECTNAME/-/ci/editor?branch_name=main and make this your pipeline config
###  Add `dast` to your `stages:` configuration  
stages:  
  - dast

###  Include the DAST template  
include:  
  - template: DAST.gitlab-ci.yml

###  Your selected site and scanner profiles:  
dast:  
  stage: dast  
  dast_configuration:  
    site_profile: "site1"  
    scanner_profile: " scanner1 "
  1. Click Save
  2. Go to https://gitlab.com/GROUP/PROJECT/-/pipelines
  3. Click the new pipeline
  4. When the pipeline finishes search in the log for PHPSESSID
  5. You should be able to see the plain text session cookie
  6. Visit the same page as an unauthenticated user (log out). You can still see the output

Impact

Log output leaks session information that can give an unauthenticated attacker access to production deploys of victims systems

Examples

active scan output: https://gitlab.com/ultimatetest7/hen/dast/-/jobs/3373938232
passive scan output: https://gitlab.com/ultimatetest7/hen/dast/-/jobs/3374371233

What is the current bug behavior?

The log is only masking the session information in one place

What is the expected correct behavior?

All occurrences of the session info should be redacted in the logs

Output of checks

This bug happens on GitLab.com

Impact

Log output leaks session information that can give an unauthenticated attacker access to production deploys of victims systems

Attachments

Warning: Attachments received through HackerOne, please exercise caution!

How To Reproduce

Please add reproducibility information to this section: