Get easy $50,000 bugbounty hunting from hackerone program

In today’s blog post, we’ll delve into an intriguing bug bounty case where a hacker discovered a GitHub Personal Access Token (PAT) within an Electron desktop application. This access token provided the hacker with unauthorized access to a company’s sensitive repositories. After breaking down how this vulnerability was discovered, we’ll explore how you can find similar issues in web applications to enhance your bug bounty hunting skills.

## The Bug: GitHub Token Found in an Electron App

This story revolves around a hacker who was reviewing an **Electron app** developed by a Shopify employee. Electron is a framework for building cross-platform desktop apps using web technologies such as HTML, CSS, and JavaScript. The hacker’s method involved extracting files from the Electron app, uncovering an **environment file** (`.env`), which is often used to store sensitive configuration data such as API keys and tokens.

Here’s how the hacker went about it:

### 1. **Unpacking the Electron App**
The hacker extracted the app’s source files from the `.asar` archive, which is a format used by Electron apps to bundle resources. This was done using a simple command:
```
npx asar extract path/to/app.asar extracted/path
```
The `.asar` file contained all the files used by the Electron app, including a hidden `.env` file.

### 2. **Discovering the GitHub Token**
Inside the `.env` file, the hacker found a variable named `GH_TOKEN`, which contained a **GitHub Personal Access Token** (PAT). Initially, the hacker assumed the `.env` file contained only basic app configurations. However, upon closer inspection, it became clear that the app never actually used the `.env` file, suggesting it was a leftover from the development or build process.

### 3. **Testing the Token**
The hacker tested the validity of the token by authenticating against GitHub’s API using the following command:
```bash
curl -H “Authorization: token $GH_TOKEN” -H “Accept: application/vnd.github.v3+json” https://api.github.com/user
```
This revealed that the token was valid and active, allowing the hacker to authenticate as the user who created the token.

### 4. **Exploiting the Access**
To explore the token’s scope, the hacker accessed the `/user/orgs` GitHub API endpoint, which returned a list of organizations the user was a part of. Among these was **Shopify**. The hacker then made a request to `/orgs/Shopify/repos`, which returned a list of repositories, both public and private, along with the permissions associated with the token. It turned out that the token granted **push** and **pull** access to private Shopify repositories, allowing the hacker to make unauthorized changes, including inserting malicious code into the repositories.

### **Impact**
The exposure of the GitHub token in this case gave the hacker read and write access to all private Shopify repositories, potentially allowing for code injection, backdoors, and other severe attacks on Shopify’s infrastructure.

— -

## How to Find Similar Bugs in Web Applications

Finding vulnerabilities like the one above in web applications requires a different approach since you can’t simply unpack an Electron app. However, similar bugs involving the exposure of sensitive credentials, API keys, and tokens can often be found in poorly secured web applications. Here’s how you can uncover them:

### 1. **Look for Exposed `.env` Files on Web Servers**
`.env` files, used for environment variables, are often mistakenly uploaded to web servers in production environments. These files can contain sensitive information like API keys, database credentials, and tokens.

**How to Find It:**
— Test common paths like:
```
https://target-website.com/.env
https://target-website.com/config.js
```
— These files should never be accessible from a browser. If you can access one, inspect it for sensitive data like API keys, tokens, or database credentials.

**Tools**: Use automated tools like **Nuclei** to scan for `.env` file exposures:
```yaml
id: exposed-env-file
info:
name: Exposed .env File
severity: high
requests:
— method: GET
path:
— “{{BaseURL}}/.env”
matchers:
— type: word
words:
— “APP_KEY”
— “SECRET_KEY”
```

### 2. **Search JavaScript Files for Hardcoded Secrets**
Developers often hardcode API keys or tokens into JavaScript files without realizing that these files are publicly accessible.

### 3. **Check for Exposed API Endpoints**
Some APIs, especially those used for internal purposes, may be exposed to the public without proper authentication or authorization, making them accessible to attackers.

### 4. **Hunt for Source Code Leaks or Backup Files**
Sometimes developers accidentally leave behind backup files (`.bak`, `.old`, or `.zip`) or expose source code repositories that contain sensitive information.

**How to Find It:**
— Use Google dorking to search for source code leaks or backup files. For example:
```bash
inurl:backup filetype:zip OR filetype:bak OR filetype:old
site:target-website.com
```
— Check for Git repository leaks by attempting to access `.git/` directories directly:
```
https://target-website.com/.git/
https://target-website.com/.git/config
```

### 5. **Check for Cloud Bucket Misconfigurations**
Cloud storage services like AWS S3 and Google Cloud Storage are often used to host assets, but if these storage buckets are misconfigured, they can be publicly accessible, exposing sensitive files.

**How to Find It:**
— Use tools like **CloudBrute** or **S3Scanner** to search for misconfigured cloud storage buckets.
— For AWS S3, try accessing the bucket via the URL:
```
https://bucket-name.s3.amazonaws.com
```
— If accessible, inspect the contents for sensitive files like `.env`, configuration files, or backups.

### 6. **Subdomain Enumeration**
Development or staging environments are often less secure than production environments and may expose sensitive files or misconfigurations.

**How to Find It:**
— Use subdomain enumeration tools like **Subfinder**, **Amass**, or **Sublist3r** to find subdomains.
— Test the subdomains for exposed files or APIs, as these environments may contain `.env` files or misconfigured API endpoints.

— -

## Conclusion

While the hacker in the original case was able to exploit a vulnerability in an Electron desktop application by extracting a GitHub token from a `.env` file, similar bugs can often be found in web applications through misconfigurations or poor development practices. By actively searching for exposed files, hardcoded secrets, unsecured APIs, and cloud misconfigurations, you can uncover sensitive information that could lead to serious security breaches.

Happy hunting!