PortfolioBugcrowdLinkedinYogoshaYoutube

From Key to Chaos: How a JS Key Breaks Notification Security

Push notifications are now a standard feature in our online lives. Whether it is your favourite online shopping app alerting you to a discount, a news app pushing breaking news, or a banking app reminding you about a transaction, push notifications are a standard feature.

But here's the thing: there's a security feature behind those messages. It's a mechanism that verifies the messages as being authentic and from the actual program you've installed. The VAPID private key plays a central role in this system.

Recently, I discovered, while conducting an evaluation, that the VAPID private key was directly hardcoded into the app's code. Although this appears to be a small error, it has the potential to cause severe security issues if the attackers happen to exploit it.

Let us break it down.

🔐What Are VAPID Keys?

VAPID (Voluntary Application Server Identification for Web Push) is a Web Push Notification standard.

VAPID assists the push service, such as Firebase or a browser's push service, in verifying that a notification server is genuine.

A VAPID configuration usually consists of two components:

  • Public Key → It is given to the push service and clients. It acts as your ID card that you present to others.

  • Private Key → It remains hidden on the server. It serves as your personal signature that verifies authenticity.

The rule is straightforward: you can give away the public key, but the private key has to remain secret.

💀The Problem: Hardcoded Private Key

During the assessment, I found that the VAPID private key was hardcoded in a JS file, like this:

# Example of insecure implementation
VAPID_PRIVATE_KEY = "ABcDEfghIjKL1M...."

Initially, this might not seem to be harmful. It's just a string. But in fact, it's an issue.

Here’s why:

  1. Code Repositories: If the repository is public, e.g., on GitHub, GitLab, or Bitbucket, anyone can locate it. Even in private repos, developers, contractors, or whoever has access could extract it.

  2. Backups and Logs: Code-stored keys can inadvertently fall into backups, log files, or CI/CD pipelines.

  3. Client Exposure: In certain instances, compiled code or frontend bundles may expose such values, allowing them to be accessed by attackers.

🎭What Attackers Can Do With This Key

If the attacker gets hold of the VAPID private key, they can:

  • Having access to the Push Server: They can sign requests and send push notifications that look entirely legitimate.

  • Spread Malicious Content: Users may be sent deceptive messages with phishing URLs, malware downloads, or scam promotions.

Real-World Scneario:

Imagine receiving a push notification from a banking app, asking you to click on a link to “verify your account.” If an attacker has the VAPID private key, they can make this look real.

⚒️How to Fix the Issue

  1. Remove Hardcoded Secrets

    • Never commit private keys, API tokens, or passwords into source code.

  2. Use Environment Variables or Secrets Managers

    • Store sensitive values outside the codebase.

    • Examples:

      • AWS Secrets Manager

      • Azure Key Vault

      • HashiCorp Vault

      • Docker Secrets

# Store the key securely
export VAPID_PRIVATE_KEY="ABcDEfghIjKL1M...."
# Load it safely in your code
import os
VAPID_PRIVATE_KEY = os.getenv("VAPID_PRIVATE_KEY")

  • Rotate the Exposed Key

    • Generate a new VAPID key pair using libraries like web-push.

    • Revoke and stop using the exposed key immediately.

  • Restrict Access

    • Ensure that only server-side code has access to the private key.

    • Never expose it in frontend/client-side applications.

📊 Visualising the Risk

👨‍💻Exploitation

I have used a JS code for exploitation, where the public key, private key and subscription details are required.

Feel free to reach out if you need the JS file!

🔒 Conclusion

Hardcoding secrets such as VAPID private keys may appear to be an easy and convenient means of accomplishing things, but it's a dangerous shortcut. When these keys become public, attackers can pretend to be your application and communicate with your users directly. That destroys trust and invites abuse.

The best part is that this can be prevented. By implementing secure key management, secret scanning, and educating developers to do credentials right, organisations can entirely remove this risk.

Small oversights in security, like one hardcoded string, can form massive vulnerabilities for attackers.

🤝You can connect with me:-

Bugcrowd:- https://bugcrowd.com/GhostR LinkedIn:- https://www.linkedin.com/in/rushikesh-kaware-383802160/ YouTube:- https://www.youtube.com/@GameFreakYo

I trust this information proves valuable to your bug bounty journey. Feel free to share this article with other budding bug bounty hunters.

Stay tuned for more articles delving into new concepts. Take care, everyone! 😊

Last updated

Was this helpful?