Pipeleak is a tool designed to scan GitLab job output logs and artifacts for potential secrets.
To begin using Pipeleak, download the latest binary from the Releases page.
Run the following command to scan your GitLab instance:
pipeleak scan --token glpat-xxxxxxxxxxx --gitlab https://gitlab.com
In addition to logs, Pipeleak can also scan artifacts generated by your pipelines.
Note: Scanning artifacts uses a lot of memory!
pipeleak scan --token glpat-xxxxxxxxxxx --gitlab https://gitlab.com -a
Pro tip:
Note: Dotenv artifacts are not accessible through the GitLab API. To scan these, you need to manually provide your session cookie after logging in via a web browser. The session cookie name is
_gitlab_session
. The cookie should be valid for two weeks.
pipeleak scan --token glpat-xxxxxxxxxxx --gitlab https://gitlab.com -v -a -c [value-of-valid-_gitlab_session]
The following confidence levels for scans are used by default:
low
medium
high
high-verified
these are validated by the corresponding TruffleHog validator.
However if you want to add custom ones, you can define any value in the rules.yml
file
To scan only for a specific level, you can specify it via CLI flag e.g --confidence=high,medium
. Define multiple by comma separating the values.
Note: high-verified
cannot be removed.
As the scanner processes a lot of resoures (especially when using --artifacts
) memory, CPU and disk usage can become hard to manage.
You can tweak --threads
, --max-artifact-size
and --job-limit
to obtain a customized performance and achieve stable processing.
shodan
command: use the Shodan command to identify gitlab instances that might allow for anyone to register. this command assumes a JSON file from a Shodan export. example query: product:"GitLab Self-Managed"
runners
command: Identify (shared) runners which are available globally or through a group where the user has at least developer access. Create projects with a default exploitation .gitlab-ci.yml
file.
register
command: Best effort automation to register a new user on an instance.
vuln
command: Check the installed version for CVEs in the NIST Vulnerability database
variables
command: Enumerate configured project/group/instance variables
secureFiles
command: Enumerate secure files
Setting an HTTP proxy is possible by setting the environment variable HTTP_PROXY
e.g. to route through Burp:
HTTP_PROXY=http://127.0.0.1:8080 pipeleak scan --token glpat-xxxxxxxxxxx --gitlab https://gitlab.com
In the scan
mode you can change interactively between log levels by pressing t
: Trace, d
: Debug, i
: Info, w
: Warn, e
: Error. Pressing s
will output the current queue status.
To easily analyze the results you can redirect the pipeleak output using nc
into Logstash.
Setup a local ELK stack using https://github.com/deviantony/docker-elk.
Then you can start a scan:
pipeleak scan --token glpat-xxxxxxxxxxx --gitlab https://gitlab.com --json | nc -q0 localhost 50000
Using Kibana you can filter for interesting messages, based on the JSON attributes of the output.
e.g. message.level=warn and message.confidence=verified
to find verified results.
When you run Pipeleak for the first time, it generates a rules.yml
file based on this repository. You can customize your scan rules by modifying this file as needed.