Pipeleak

Pipeleak is a tool designed to scan CI/CD logs and artifacts for secrets.

It supports the following platforms:

• GitLab
• GitHub

Getting Started

To begin using Pipeleak, download the latest binary from the Releases page.

General Usage

Run the following command to scan your e.g. GitLab instance:

pipeleak gl scan --token glpat-xxxxxxxxxxx --gitlab https://gitlab.com

Scanning Artifacts

In addition to logs, Pipeleak can also scan artifacts generated by your pipelines.

Note: Scanning artifacts uses a lot of memory!

pipeleak gl scan --token glpat-xxxxxxxxxxx --gitlab https://gitlab.com -a 

Confidence

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, but verification can be disabled using --truffleHogVerification=false.

Customizing Scan Rules

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.

Keybindings

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.

Platform Specific Hints

GitLab

Dotenv

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 gl scan --token glpat-xxxxxxxxxxx --gitlab https://gitlab.com -v -a -c [value-of-valid-_gitlab_session]

Memory Usage

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.

Additional Features

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

enum command: Enumerate user permissions and accesss

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 gl scan --token glpat-xxxxxxxxxxx --gitlab https://gitlab.com

GitHub

No remarks yet 🌟

ELK Integration

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 gl 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.