Forem: Peter Davis

Final Tale: Part 3 - The Gateways We Left Open

Peter Davis — Fri, 30 May 2025 11:48:34 +0000

Part 3 of 3 in Git Tales Series

"Some files vanish from sight, but not from memory. Git remembers. So do attackers."

We’ve journeyed deep into the underbelly of modern software development where secrets hide in plain sight, tucked between commits and CI scripts, waiting to be exhumed. In Part 1, we met the careless developer. In Part 2, we followed the breadcrumbs into service accounts, dangling credentials, and quiet privilege escalation in the cloud.

Now, this is the final part of the Git Tales trilogy — and unlike the previous tales, this one breaks apart into three standalone compromises, each unearthed through separate hunts, reported via three different bug bounty programs, and rewarded with high to critical payouts.

Each started differently. Each felt like an accident — a digital whisper. But each time, that whisper led to something massive.

The Script That Wouldn’t Die

It began like any other passive recon session — checking out a newly public GitHub repository tied to a mid-sized tech company. Nothing looked special on the surface: some README files, a few basic Go services, and tests.

But something odd caught my attention in the commit history, a file named test.sh had been committed and then deleted. I’d seen this pattern before 😅. And 9 out of 10 times, it's harmless. But that one time? It changes everything.

I pulled the repo and dug deeper. A single commit. Then gone.
But Git’s memory is long.

git checkout <commit-hash>^ -- test.sh

And there it was.

A simple bash script, or so it seemed — containing an HTTP call with a GitHub token hardcoded in plain sight:

#!/bin/bash
curl -H "Authorization: token ghp_abcd1234EXAMPLETOKEN" https://api.github.com/orgs/example-org/repos

I stared at the token. I validated it with trembling fingers 🥲. It wasn’t expired.

curl -H "Authorization: token ghp_abcd1234EXAMPLETOKEN" https://api.github.com/user

200 OK!!! 😅. I was in.

Impact

Access to 20+ private repos
Read/write permissions across the org
Internal CI/CD workflows, API keys, infra configs
GitHub Actions secrets exposed

I submitted a report through their program, and within hours, triage confirmed its validity. A few days later, the bounty landed 🐞.

Ghost in the Registry

I wasn’t even looking for containers. Just passively scanning Git objects in a public repo of a private bug bounty program when I found a file named nginx-test-secret.yaml

It was gone from the live branch. Deleted months ago. But as always, Git’s memory outlived the author’s intention.

The file contained base64-encoded ACR credentials. My pulse picked up. Was this real?

I decoded it. Logged in.

docker login myregistry.azurecr.io -u acr-user -p s3cr3tP@ss

Success. The registry door opened.

What It Unlocked

80+ private container images
Secrets in ENV layers (.env, secrets.py)
Pre-production builds, old tokens, debug configs
Internal microservices

One image even had Slack bot credentials embedded in its CMD layer. The registry was unscoped. There was no IP filtering. No token rotation. This was a supply chain bomb waiting to go off.

The Git Leak That Bit Back

Sometimes, the real treasures aren’t in public repos or code. They’re in the infrastructure someone forgot existed. They call it "Shadow IT???" 🤔.

While targeting a company’s legacy subdomains, I started a fuzzing job out of curiosity — just to rule out low-hanging fruit. After hours of generic 403s and 404s, I hit on a strange path:

https://old-ci.example.com/test/internal/.git

I download the .git folder to my VPS for analysis and testing.

wget -r -np -nH --cut-dirs=1 -R "index.html*" https://old-ci.example.com/test/internal/.git

I checked the .git/config file cause I know based on previous experience some devs set creds here 🤫. A full config file, raw and alive with BitBucket credentials present.

[remote "origin"]
  url = https://devuser:bb_app_password@bitbucket.org/orgname/infra.git

I paused. Was it real? One command later git clone https://devuser:bb_app_password@bitbucket.org/orgname/infra.git

Boom🤯🤯🤯. Repo cloned. Zero MFA. No IP lock. No alerts.

And this was just the start. The Bitbucket account had access to multiple workspaces (3). In the following hours, performed some critical tests to check the scope of the credentials.

Tests Performed

List All Repositories via Bitbucket API

List Workspaces the user belongs to

Impact

Access to 60+ internal repos.
CI/CD secrets, API keys, Terraform configs.
Slack webhooks, pipeline tokens
Exposure across 3 different Bitbucket workspaces

This was a critical security hole via infrastructure drift — the kind of bug you only catch by digging where no one else looks anymore.

Lessons from the Fallout

This breach wasn’t theoretical. Every piece of it mirrors real-world incidents that have happened — sometimes quietly, sometimes splashed across news headlines.

What should have been done?

Use least-privilege tokens. Never commit a token with org-wide access. Or just never commit any secrets...
Secrets detection in CI using tools like Gitleaks, or GitHub's native secret scanning.
Use managed identities - Especially for container registries and pipelines. No passwords in YAML.
App passwords ≠ secure APIs. Especially in Bitbucket, where app passwords are commonly over-scoped and under-rotated.
Monitor audit logs. Both GitHub and Bitbucket offer event logs — but too few organizations actively monitor them.

The Tale Ends, But the Threat Lingers

The Git Tale wasn’t about zero days or advanced persistent threats. It was about something more dangerous, misplaced trust and developer convenience turned blind spot.

As we close this series, remember:

"Every secret you commit lives forever — unless you treat it like the threat it is."

Your containers aren’t safe just because they’re in a private registry. Your GitHub isn’t secure just because it’s behind SSO. Your Bitbucket isn't safe because it’s split into "separate" workspaces.

Attackers don’t care about your silos. They care about your secrets — and Git will gladly index them for the world to see.

What’s Next?

That’s the end of the Git Tales Series — but just the beginning of a broader journey.

Stay tuned for my next series: “*A bug represents something bigger *” — where we dive into the mind of a hacker or bug bounty hunter.

Until then, guard your Git, rotate your keys, and never trust a silent repo.

Git Tales: Part 2 - Demons in the Cloud

Peter Davis — Fri, 09 May 2025 10:05:39 +0000

Part 2 of 3 in Git Tales Series

Introduction

In the previous part of this series, we explored the haunting reality of sensitive secrets buried within Git repositories lurking quietly, waiting to be discovered. This time, we dig deeper into the darkness. This is the tale of cloud credentials: specifically, AWS access keys and GCP service account keys — the demons that, when found, can open portals into your cloud infrastructure.

This is not fiction. These were real credentials found in public GitHub repositories. The implications? Full access to critical cloud resources, with barely any barriers.

The Credentials Purpose

AWS Access Keys - CLI/SDKs

What are they?

AWS Access Keys are used to programmatically interact with AWS resources via the AWS CLI or SDKs.

Typical Use Cases

Deploying infrastructure via Terraform or CloudFormation
Automating tasks e.g., S3 uploads, Lambda management
Integrating CI/CD workflows

Risk When Exposed

If these keys are tied to an IAM user or role with broad permissions, an attacker can

List and exfiltrate S3 buckets
Spin up EC2 instances - for crypto mining or persistence
Access RDS snapshots or EBS volumes
Destroy resources or disable security services e.g., GuardDuty

GCP Service Account Keys

What are they?

A GCP service account key is a JSON file that authenticates as a service account. It allows full API access according to the permissions granted to that account.

Typical Use Cases

Interacting with GCP services e.g., Cloud Storage, Pub/Sub, BigQuery
Running automated workloads in CI/CD pipelines
Backend services or microservices accessing GCP APIs

Risk When Exposed

With a leaked key, an attacker can:

Authenticate with gcloud to your cloud project.
Access or modify GCS buckets.
Interact with APIs e.g., Cloud SQL, IAM, Compute Engine.
Move laterally across projects and regions, depending on scope.

Real World Discovery: Resurrecting Cloud Credentials

While hunting for vulnerabilities in a bug bounty program, I focused on a company's public GitHub repositories. One of the most overlooked areas in such assessments is Git history — especially commits related to CI/CD automation.

In this case, I discovered that the organization had once committed credentials within test configuration files, likely used for automation purposes during development. These files were later deleted — a move that gives a false sense of security to many developers 😂. But as any experienced hunter knows, deleting a file doesn't erase its past from Git.

Using basic git log and git show commands, I located the commit hashes and recovered the deleted files.

git log --diff-filter=D --summary | grep delete
git show <commit_hash>:path/to/test-service-account.json

And there it was — the buried treasure.

Finding 1: AWS Key in a Test File

Inside a deleted test config file, I discovered exposed AWS Access key as shown in the example below

[test-s3-eu-central-1]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

I immediately knew this was credentials for Frankfurt region based on the profile setting of test-s3-eu-central-1 and I rushed to CLI to configure this and test the credentials

aws configure --profile orgName-test-s3-eu-central-1
aws sts get-caller-identity --profile orgName-test-s3-eu-central-1
aws s3 ls

The second command above gave the below output in my CLI after configuring the profile confirming the credentials are active.

It worked 😎. The credentials were still active, and the IAM user had access to several buckets and EC2 metadata 🤯. Some even contained staging environment snapshots — a serious data exposure.

Finding 2: GCP Service Account Key Recovered

Another deleted commit in a different organization's public GitHub repo revealed a __json_key used for automated GCP deployments.

I decoded the credentials from base64 encoding and then saved them to a file org-sa-creds.json for authentication via gcloud.

gcloud auth activate-service-account --key-file=org-sa-creds.json
gcloud projects list
gcloud projects get-iam-policy PROJECT-ID \ --filter="bindings.members:serviceAccount:SERVICE-ACCOUNT-EMAIL@SOMETHING.iam.gserviceaccount.com" \ --format="json

The final command above can be used to view GCP IAM policy of the service account. Please NOTE this can only be successful based on permissions given to the service account.

Below is the service account authentication via gcloud

The key was valid, and I was able to enumerate projects, enumerate permissions, list GCS buckets, view/download bucket objects, and access compute resources — all tied to the target organization.

Consequences of Exposure

Business Risk

Data exfiltration and theft.
Infrastructure hijack for crypto mining or botnets.
Compliance violations e.g GDPR, HIPAA,etc..
Reputation damage if incidents go public.

Attack Vector Expansion

Persistence using created IAM users or service accounts.
Privilege escalation via over-permissive roles.
Lateral movement across multi-cloud or hybrid setups.

Lessons from the Shadows

Scan before you commit - use tools like git-secrets and Gitleaks.
Automate secrets detection - CI/CD pipelines should fail if secrets are detected.
Use short-lived credentials - prefer IAM roles and workload identity over static keys.
Audit and rotate - regularly audit credential usage and rotate keys periodically. But you know this rarely happens😁
Restrict and monitor - apply least privilege and set up anomaly detection using resources like AWS GuardDuty, GCP Security Command Center.

Final Thoughts

Cloud credentials are among the most powerful and dangerous secrets to leave in your Git history. In the wrong hands, they can become the demons that burn your cloud kingdom to the ground.

This is the second tale of our git tales 😁. In the final tale of the Git Tales series, we’ll dive into:

📝 Part 3: How committed Github tokens and Azure ACR creds can expose your private repos and container Images.

"Stay vigilant. Stay paranoid. Your cloud deserves it! 🫠🫠🫠" - @davisbug

Git Tales: Secrets in the Shadows

Peter Davis — Tue, 29 Apr 2025 12:10:28 +0000

Part 1 of 3 in Git Tales Series

Overview

In my recent bug hunting, I stumbled across something that perfectly shows why "deleted" doesn't always mean "gone." I discovered a particularly critical vulnerability that highlights a common oversight among developers, the misunderstanding of Git history. The target codebase had undergone multiple revisions, and one configuration file "appsettings.json" had been deleted in a recent commit.

Curious, I ran a quick scan of the Git history using tools like git log and git diff. To my surprise, the deleted file had once contained Shopify Admin API keys — plaintext credentials capable of granting administrative access to a Shopify store.

This wasn’t a file accidentally left in the final commit. It was a deleted file that had been committed earlier, still lingering in the repository’s history. This sort of vulnerability is often overlooked because many developers assume that once a file is deleted and pushed, it's gone. Git, however, retains every commit unless explicitly scrubbed.

Impact of the Vulnerability

The leaked Admin API token for Shopify was still valid when discovered and belonged to a store that had gone live in January 2025. The potential impact was significant and included:

Full Administrative Access 🔓

Read, update, and delete orders, products, customers, inventory, and themes.
Manage discount codes and price rules.
Add malicious ScriptTags to inject JavaScript into the storefront.

Data Breach Risk 📊

Exposed customer PII (names, emails, order history).
Violated data protection regulations like the GDPR.

Disruption of Store Operations 🛠

Unauthorized configuration changes
Loss or corruption of data
Deletion of products or categories

In short, a valid Admin API key, even for a development store, has access to production-level functionality. This creates an enormous attack surface.

Proof of Concept (PoC) and Bounty

To responsibly demonstrate the impact, I conducted a limited set of read-only API calls using curl

Get store information

curl -X GET \
  -H "X-Shopify-Access-Token: <admin_api_key>" \
  https://<storename>.myshopify.com/admin/api/2024-01/shop.json

List all products

curl -X GET \
  -H "X-Shopify-Access-Token: <admin_api_key>" \
  https://<storename>.myshopify.com/admin/api/2024-01/products.json

View access scopes

curl -X GET \
  -H "X-Shopify-Access-Token: <admin_api_key>" \
  https://<storename>.myshopify.com/admin/oauth/access_scopes.json

The last API call (access_scopes.json) confirmed that the token had read permissions across major endpoints as shown in the diagram below.

Responsible Disclosure ✅

The vulnerability was reported via the appropriate bug bounty platform. The organization responded quickly, revoked the token, and awarded a bounty for the finding.

Properly Remove Secrets from Git History

Many developers know how to delete a file from a repo, but far fewer understand that Git never forgets. A simple git rm followed by a commit only removes the file from the working directory — not from history.

Step-by-Step: Clean Your Git History 🧼

Option 1: Using BFG Repo-Cleaner

# Delete a file from all history
bfg --delete-files config.json

# Remove secrets from history using a list
bfg --replace-text passwords.txt

Option 2: Using git filter-branch
Kindly note this method is slower but more flexible.

git filter-branch --force --index-filter \
  "git rm --cached --ignore-unmatch config.json" \
  --prune-empty --tag-name-filter cat -- --all

Important

Force-push after cleaning. Commands below:

git push origin --force --all
git push origin --force --tags

Rotate any secrets found in history. Very Important!!!!!!!!!
Re-clone the repository to avoid residuals.
Notify all collaborators so they can do the same.

Conclusion

This finding is a prime example of how code history can betray your security efforts. Developers often overlook deleted files, unaware that a sensitive credential committed even once can remain accessible unless explicitly purged.

Key Takeaways

Deleting a file doesn't delete it from Git history.
Admin API keys in Shopify offer massive control and should be treated like passwords.
Always audit code and Git history before pushing public repositories or publishing code.
Use automated scanners during CI/CD to catch secrets before they go live.

This is just the beginning. In the next parts of the Git Tales series, we’ll dive into:

🧩 Part 2: How Service account keys can be your demons in the cloud.
📝 Part 3: How committed Github tokens can expose your private repos.

Until then, treat your Git repo like an open diary — someone might be reading.

Bug Bounty Hidden Treasures

Peter Davis — Wed, 26 Mar 2025 06:40:39 +0000

What's Bug Bounty

Bug bounty is a monetary reward given to ethical hackers for successfully discovering and reporting a vulnerability or bug in an application, API, or computer system. Bug bounty programs allow companies to leverage the hacker community to improve their systems’ security posture over time continuously.

Hidden Treasures

Bug bounty hunters thrive on uncovering vulnerabilities that others overlook, and some of the most rewarding finds come from hidden routes within an application. These routes, often undocumented or left exposed due to misconfigurations, can lead to critical areas such as admin panels, debug endpoints, or forgotten API endpoints. Attackers who discover these paths can manipulate backend systems, access sensitive data, or even take control of critical functionalities. By carefully mapping an application’s structure and testing unconventional input, hunters can reveal these concealed attack surfaces.

Another lucrative area for discovery lies in deployed but unknown features—those pushed into production without proper security vetting. Developers sometimes leave experimental or beta functionalities accessible via specific parameters or headers, unaware that they can be exploited. These features may bypass authentication, introduce unintended behaviors, or expose sensitive internal tools. A skilled hunter knows how to probe for such hidden mechanisms by analyzing application requests, reviewing JavaScript files, and testing feature flags to unlock functionalities that shouldn’t be publicly accessible.

Decommissioned features lingering in production are another goldmine. Organizations may retire certain functionalities but fail to fully remove their backend components, leaving old endpoints or outdated authentication mechanisms still operational. These forgotten elements often lack modern security protections, making them prime targets for exploitation. By identifying and testing legacy endpoints or accessing outdated documentation, hunters can uncover these remnants and turn them into high-value reports before malicious actors do.

How I Found One of Those Treasures

I've been doing bug bounties since 2018, and over the years have learned a thing or two on how to approach a target that may seem difficult or unhackable. I had a target.com that I found online that offers great bounties for their cloud assets. After the enumeration of all subdomains, I picked one that looked interesting to hack on.

I utilized ffuf to enumerate directories since it's faster and also has great flags that can help you get the results you want. I discovered quite a number of directories that looked like normal stuff and un interesting. I then discovered one called "/system/ which seemed more interesting and fun to probe further. I fuzzed it, and then I discovered an endpoint "/system/auth" that allowed users to authenticate to the application via a login form, as shown below.

This was not the normal endpoint for authentication to that application, but a way system administrators used to get to the application. The fun bit of it was that they used default credentials to access the console as shown above. This may seem like a trivial hack, but its impact was massive to the organization since the console was a central place where multiple client workloads were, as shown below

The above finding paid a 4-figure bounty. Sounds easy but gets paid a lot based on impact

Key Takeaways

Based on the example given above, hidden elements present high-value opportunities for bug bounty hunters who know where to look. Some of the things to look for are:

Hidden Routes in Applications

Undocumented admin panels, debug endpoints, and API paths can expose critical functionality.
Mapping an application’s structure helps reveal concealed attack surfaces.
Exploiting misconfigurations in routing can lead to data leaks or privilege escalation.

Deployed but Unknown Features

Experimental or beta features may be accessible via hidden parameters or headers.
Poorly tested functionalities can bypass authentication or introduce unintended behaviors.
Reviewing JavaScript files and application requests can expose hidden features.

Decommissioned Features in Production

Retired functionalities may still have active backend components, creating security gaps.
Legacy endpoints often lack modern security protections, making them easy targets.
Accessing outdated documentation or API references can uncover forgotten vulnerabilities.

Conclusion

Finding hidden treasures in bug bounty hunting requires patience, curiosity, and a keen eye for overlooked vulnerabilities. Whether it's discovering undocumented routes, probing deployed but forgotten features, or exploiting remnants of decommissioned functionalities, these hidden gems often lead to significant security findings. Skilled hunters who think outside the box, analyze applications thoroughly, and test unconventional attack surfaces can uncover critical weaknesses before malicious actors do. In the ever-evolving world of cybersecurity, the real rewards lie in what others fail to see. Keep digging—you never know what hidden bounty awaits! 🚀

The Cloud Resume Challenge - GCP :)

Peter Davis — Sun, 11 Sep 2022 08:11:41 +0000

Intro

In July 2022 I came across the cloud resume challenge by Forrest Brazeal shortly after completing my Cloud Engineer Certification by Google Cloud. The challenge was forwarded to me by mentor Martin and immediately after having an overview of the tasks I knew the challenge was good enough to piece together all I had learned about GCP.

The Resume challenge itself is simple but enables one to stitch together different functionalities of the cloud and come up with a complete workflow of building a static website which is fully hosted on cloud resources. Below is how I did the challenge:

1. Certification

The challenge required one to have at least completed Google Cloud Digital Leader by Google. Fortunately I had completed Associate Cloud Engineer by Google early July 2022 and I was comfortable building and hosting applications on GCP.

2. Static Website

The challenge prompted one to write a static site for their resume in HTML & CSS. This was a quick task for me having done a bit of systems development early on in my career, picked up a template online for the look and feel of the site and created custom CSS to make it look better.

3. Site Hosting

The static site (Resume) is supposed to be hosted on Google Cloud Storage and use a cloud load balancer for traffic flow. I used GCP storage bucket to host the site while Cloud Load Balancing via HTTP(S) Load Balancer on GCP.

bucket creation config

resources:
#site bucket
- name: resume.hexorsec.com
  type: gcp-types/storage-v1:buckets
  properties:
    zone: us-central1-f
    website:
      mainPageSuffix: index.html
      notFoundPage: index.html
    iamConfiguration:
      uniformBucketLevelAccess:
        enabled: true
    labels:
      app: davisresume

HTTPS certificate

# Put the bucket as a backend service
- name: davis-resume-backend-bucket
  type: gcp-types/compute-v1:backendBuckets
  properties:
    bucketName: $(ref.hexorsec.resume.com.name)
    description: Backend bucket for the CDN
    enableCdn: true

# Create an HTTPS certificate
- name: davis-resume-https-cert
  type: gcp-types/compute-v1:sslCertificates
  properties:
    type: MANAGED
    managed:
      domains:
        - $(ref.resume.hexorsec.com.dnsName)

4. DNS

The site is supposed to be pointed to a custom DNS domain name. My domain is already registered on Godaddy and I had just to add an entry for the site. Using the IP address of the Load balancer I created an entry for my resume.

5. Visitor Count

The challenge prompted one to have a section on the site for number of visitors who visit the site. For this I wrote a simple JavaScript code to fetch JSON content from endpoints and update visitor count on my site.

Firestore
I used Firestore to store and update visitor count object on the site. The database is automatically created by a script when the first visitor reaches the website.

API
The communication between JavaScript code and database is managed by a cloud function on GCP which I created. The function depends on HTTP triggers to invoke an event. The function:

reads the visitor count from firestore database
increments it by one
saves it to the database
returns the value to the client.

6. Python & Tests

The challenge prompts us to use python to write the serverless function and then perform some tests on our written code.
For this I used Python3.6 to write the serverless function and the communication between code and the backend db uses the google-cloud-firestore Python library.

7. Tests & Security

I used Pylint to perform basic test on the code and for the security bit I used snyk SCM to check for vulnerabilities within my code and it's dependencies.

8. IAC, CI/CD & Source Control

The challenge goes a head and prompt us to do a bit of IAC for automation purposes between the function, firestore and API gateway. The IAC allows one to replicate and do updates easily on the infra being provisioned. I opted to go with Deployment Manager as is an easy way to do quick deployments.

Static Site Syncing

steps:
# Copy the Site content to a GS bucket
- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk:latest'
  id: Sync the website content
  args: ['gsutil', '-m', 'rsync', '-r', 'site/', 'gs://resume.hexorsec.com']

Pylint Scanning

steps:
# Pylint SAST
- name: python:3.6
  id: Check the python package
  entrypoint: 'bash'
  args:
    - '-c'
    - |-
      pip install pylint
      pip install -r scripts/visitor_count/requirements.txt
      pylint scripts/

Infra as Code

# Deploy
- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk:latest'
  id: Deploy the infrastructure
  entrypoint: 'bash'
  args:
    - '-c'
    - |-
      apt install -y zip
      pushd scripts/visitor_count
      zip -r ../visitor_count.zip .
      cd ..
      file_name="count_$(md5sum visitor_count.zip | awk '{print $1}').zip"
      mv visitor_count.zip ${file_name}
      gsutil cp ${file_name} gs://hexorsec-XXXX-YYYYYYY
      popd
      gcloud deployment-manager deployments update resume-xxx-depl

Cloud Build
For the build I created two triggers for Infra and static site. With the two build triggers once changes are made to github and action is triggered for syncing and pushing changes.

9. Blog Post

Finally the challenge prompted one to create a blog post describing the entire process of the challenge. Here is the post for that :)

Outro

Going through the challenge is one of the best things have done after acquiring the associate cloud engineer cert from google. The entire process showed me how things work in the cloud and how use-cases can be created in such scenarios. I'm so grateful to Forrest Brazeal 👏 for setting up such a great challenge and my Mentor Martin 🫡 for pointing me to such amazing resource for learning.