Google Dorks Bug Bounty – Hackersatty – Learn Ethical Hacking, Bug Bounty, and Cybersecurity Tips

Apache server-info Exposure: 7-Step Deep Analysis of 403 Bypass & Internal Data Leak

hackersatty — Wed, 06 Aug 2025 10:41:22 +0000

About Me

I’m Satyam Pawale, better known in the bug bounty world as @hackersatty. As a dedicated security researcher, I specialize in uncovering complex misconfigurations and information disclosures—especially in web servers and directory services. My toolkit includes Shodan, Burp Suite, custom scripts, and creative reconnaissance techniques. In this article, I’ll guide you through the discovery and exploitation of an Apache server-info Exposure vulnerability, so you can sharpen your own bug bounty skills and help secure critical infrastructure.

2. Introduction

Apache server-info Exposure via a 403 bypass is a critical misconfiguration that can unveil deep internal infrastructure—ranging from module lists and environment variables .

3. What Are Apache server-info Exposure and server-status?

Apache server-info Exposure HTTP Server provides two administrative modules by default:

mod_info (/server-info): Reveals server configuration, loaded modules, compiled-in directives, and runtime parameters.
mod_status (/server-status): Displays live metrics—active requests, worker threads, bytes served, and uptime.

These endpoints are invaluable for administrators but must be strictly restricted (e.g., Require local or IP whitelisting). Left exposed, they become a treasure trove for attackers mapping infrastructure and identifying potential weaknesses.

4. Path Normalization & Bypass Fundamentals

Web servers normalize incoming paths to apply security rules uniformly. However, path normalization vulnerabilities arise when different components handle slashes inconsistently. A common bypass technique:

Expected Denial:

GET /server-info → 403 Forbidden
Bypass with Double Slash:

GET //server-info → 200 OK

Some security controls see //server-info as a different resource, failing to apply the 403 rule. By chaining encoding tricks or additional slashes, attackers slip past defenses.

5. Discovery of the Vulnerability

During routine reconnaissance with automated path enumeration tools, the following sequence occurred:

Initial Scan:
- Tool: Custom Python script iterating common admin paths.
- Found /server-status and /server-info returned 403 on standard requests.
Bypass Attempt:

curl -I http://target.example.com//server-status # HTTP/1.1 200 OK
Verification:
- Visiting //server-status in a browser displayed live server metrics.
- Similarly, //server-info rendered a full HTML page listing configuration details.

6. Technical Deep Dive: Double-Slash Bypass

6.1 Apache server-info Exposure Configuration Fragment

6.2 Path Normalization Steps

Raw Request: //server-info
Server Core: Treats leading double slash as a single slash.
Authorization Module: Matches against the original request URI (//server-info), skipping the rule that blocks external requests.

7. Proof of Concept (PoC) Walkthrough

Standard Access (Denied):

curl -i http://target.example.com/server-info # HTTP/1.1 403 Forbidden
Bypass Request (Allowed):

curl -i http://target.example.com//server-info # HTTP/1.1 200 OK
Retrieve Configuration:
- Visit http://target.example.com//server-info?config to list full conf.
- Use ?module=mod_authnz_ldap.c to see LDAP auth directives.
Confirm Sensitive Credentials:

AuthLDAPBindDN "uid=apacheauth,cn=Service Accounts,dc=example,dc=com" AuthLDAPBindPassword "P@ssw0rd!123"
Extract Private IP Ranges:
- - Over 100 lines of Require ip and Allow from with CIDR blocks like 10.0.0.0/8, 172.16.0.0/12.
Path normalization flow demonstrating double-slash bypass to elude 403 protections

8. Exposed Data & Internal Config Details

Through /server-info, the attacker gains:

LDAP Authentication Credentials:

AuthLDAPBindDN "uid=apacheauth,cn=Service Accounts,dc=example,dc=com" AuthLDAPBindPassword "P@ssw0rd!123"
Complete Module List:
- mod_ssl, mod_dav, mod_proxy, mod_authnz_ldap, mod_log_config, and more.
Environment Variables:
- SERVER_ROOT, HTTPD_ROOT, MPM_WORKER, and custom site-specific vars.
Private & Public IP Ranges:

10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 203.0.113.5 198.51.100.22 …100+ entries
Runtime Hooks & VirtualHosts:
- Active mod_rewrite rules, virtual host configs, SSL cipher suites.

9. Impact Analysis

Confidentiality: Attackers see internal topologies, service accounts, and credentials.
Integrity: Knowledge of modules (e.g., mod_proxy) enables targeted CVE chaining.
Availability: Although read-only, leaked DoS‐vulnerable modules (e.g., mod_dav) could be exploited.
Compliance: Violates GDPR/PCI-DSS by exposing sensitive configuration and creds.
Attack Chains:
1. Use AuthLDAPBindDN to bind and enumerate directory.
2. Identify vulnerable modules (e.g., mod_authnz_ldap CVE-2018-1312).
3. Mount DoS or RCE attacks based on leaked module versions.

10. Mitigation & Hardening Strategies

Disable Unused Modules: Remove mod_info and mod_status from production.
Strict Access Controls:

Require ip 127.0.0.1 ::1
Path Normalization Fixes:
- Upgrade to Apache server-info Exposure ≥2.4.50 where double-slash handling is hardened.
- Add WAF rules to block // sequences.
Credential Security: Move LDAP bind credentials to a secure vault—never in plaintext.
Regular Audits & Pen Tests: Include bypass scenarios in automated scans.

11. Broader Security Lessons

Assume All Endpoints Are Public: Test with modified URIs (//, ..;, URL-encoding).
Defense in Depth: Even if modules are enabled, restrict them at the network perimeter.
Secret Management: Hardening is only as strong as your secret storage.
Monitor for Anomalies: Alert on requests containing suspicious patterns (//server-).

11. External Resources & Further Reading

13. Conclusion

The Apache server-info Exposure vulnerability demonstrates how a seemingly minor path-normalization issue can compromise an entire web server’s security posture. Attackers can bypass 403 restrictions, harvest sensitive credentials, map private networks, and identify vulnerable modules—paving the way for lateral movement and targeted exploits. By understanding the mechanics of double-slash bypass, continuously auditing server configurations, and enforcing strict access controls, organizations can defend against such high-impact misconfigurations.

14. Final Thoughts: Other Bug Bounty Blogs

Google Dorking remains a powerful reconnaissance technique in modern bug bounty methodology. With the right mindset and crafted queries, it’s possible to uncover sensitive files, misconfigurations, credentials, and more—without sending a single request to the server. This makes it especially useful for stealthy or scope-sensitive bug bounty programs.

Remember: always stay within scope, validate what you find, and follow responsible disclosure guidelines.

Keep exploring. Keep hunting.

25+ Google Dorks for Bug Bounty: Find Exposed Signatures, NDAs & Confidential Docs

hackersatty — Fri, 18 Jul 2025 10:46:28 +0000

By Satyam Pawale (@hackersatty)

About Me

Google Dorks Bug bounty is one of the most underrated skills in bug bounty hunting, yet it can lead to discovering high-severity and real-world vulnerabilities. I’m Satyam Pawale, widely known in the cybersecurity community as @hackersatty. As a passionate bug bounty hunter, I specialize in uncovering impactful bugs through creative reconnaissance techniques, especially using publicly available search engines like Google.

In this article, I’ll show you how to perform actionable bug bounty reconnaissance using Google Dorks Bug bounty to discover sensitive information like signature pages, NDAs, internal contracts, credentials, and other confidential files that are often unintentionally exposed on the web. Whether you’re a beginner or a seasoned hunter, you’ll learn how to add this powerful skill to your recon arsenal.

Let’s dive deep into the art of dorking for vulnerabilities.

Introduction

Google Dorking, also known as Google hacking, is an advanced search technique used to find exposed sensitive information through the use of tailored Google queries. For bug bounty hunters, Google Dorks Bug Bounty can serve as a gateway to discovering misconfigurations, exposed credentials, hidden portals, and even full documents that were never meant to be public.

I’m Satyam Pawale, widely known in the cybersecurity community as @hackersatty. As a passionate bug bounty hunter, I specialize in unearthing hidden vulnerabilities and valuable assets using methods that are both manual and automation-driven. Google Dorking is one of the oldest yet still highly effective methods for performing reconnaissance during bug bounty assessments.

In this article, we’ll walk through real-world examples, advanced Google Dork techniques, signature hunting, and tips to optimize your bug bounty recon. Whether you’re just starting out or already deep into bug bounty hunting, this guide will give you a fresh edge using Google search itself.

What is Google Dorking?

Google Dorking involves using special search operators to extract hidden information from public-facing websites. The idea is that Google indexes everything—sometimes more than it should—and by crafting specific queries, you can find pages that developers never intended to be indexed.

Focus Keyword: Google Dorks Bug Bounty

Why Use Google Dorks Bug Bounty?

Bug bounty is about scope, precision, and creativity. Often, the most critical bugs are buried in obscure or forgotten assets. Google Dorks Bug Bounty let you:

Find sensitive documents (PDF, XLSX, DOCX, TXT)
Uncover exposed login panels and admin consoles
Locate API keys or credentials in indexed pages
Discover configuration files or server info
Reveal staging environments and forgotten subdomains

Google Dorks extend your recon capabilities without the need for intrusive scanning.

Real-World Examples of Google Dorks Bug Bounty

1. Finding Exposed PDF Contracts

site:example.com filetype:pdf confidential

Use this to find PDF files with potentially sensitive contracts or agreements. Add intitle:"nda" to refine for NDAs.

site:example.com filetype:pdf intitle:nda

2. Discovering Passwords in GitHub Repos

site:github.com "api_key" "example.com"

Search GitHub for exposed API keys linked to your target.

3. Login Panel Discovery

site:example.com inurl:admin

site:example.com intitle:"login"

Great for finding potential login endpoints and bypassing public-facing dashboards.

4. Configuration Files Exposure

site:example.com ext:env | ext:yaml | ext:json

Many .env, .yaml, or .json files contain DB credentials and API tokens.

5. Index Pages and Directory Listings

site:example.com intitle:"index of /"

Use this to locate open directories or file servers.

Dork Crafting Approach

A smart bug bounty hunter understands how to craft dorks per asset type. Here’s how to approach it:

Step 1: Understand the Asset Type

Web apps: Look for login pages, dashboards
APIs: Look for documentation, keys, usage logs
Documents: PDFs, Excel sheets, TXT notes
Cloud Storage: Google Drive, AWS S3, Firebase

Step 2: Combine Keywords & Operators

Use logical operators:

site: to limit to a domain
filetype: to find specific formats
intitle: for keyword in title
inurl: for keyword in URL
cache: to view old or deleted versions

Step 3: Add Contextual Terms

Terms like “confidential”, “internal use only”, “do not share”, “restricted” often lead to gold mines.

site:example.com filetype:pdf "internal use only"

Advanced Signature Hunting Using Google Dorks

A powerful tactic is finding signature pages that contain document footers, author names, company templates, or timestamp structures. You can do this by:

Searching for Signature Markers

site:example.com filetype:pdf "Signature"

site:example.com filetype:pdf "Authorized Signatory"

These can reveal:

Contractual documents
Signed NDAs
Employment documents
Partnership forms

Sometimes these documents contain personal info, email IDs, full addresses, or contract clauses—providing strong reconnaissance material or even PII disclosures.

Example:

site:gov.in filetype:pdf "Signature"

Results may include tender documents with authorizing signatories and sensitive contact information.

Hunting Exposed IP Addresses

You can look for IP addresses by searching for headers or configuration exposures:

site:example.com intext:"X-Forwarded-For:"

site:example.com intext:"Server IP"

These dorks help you track misconfigured headers or identify internal infrastructure.

Explore the ultimate Google Dorks collection by Satyam Pawale (@hackersatty) on GitHub – crafted for bug bounty hunters and OSINT researchers to uncover hidden vulnerabilities and exposed data.

Practical Use in Bug Bounty Programs

Here’s how to leverage these discoveries:

Recon Stage

Use Google Dorks to discover undocumented subdomains and portals.
Validate sensitive file exposure.

Exploitation Stage

Analyze PDF/Excel documents for hardcoded credentials or PII.
Use configuration files to attempt login or privilege escalation.

Reporting Stage

Provide the full Dork used.
Include metadata (e.g., PDF timestamp, author info).
Explain potential impact (e.g., credential reuse, data leakage).

Tips to Avoid False Positives

Validate URLs using tools like curl, wget, or Burp Suite.
Use Google Cache to grab deleted or moved files.
Be cautious of decoy pages or honeypots.

Tools to Combine With Google Dorks

GitHub Dorking Tools: Use github-dork to automate GitHub leak discovery.
GoogleHackingDatabase: Explore pre-built dorks from Exploit-DB.
DorkScanner: Automates mass scanning with custom dorks.
Burp Suite: Validate endpoints or files.

Final Thoughts : Other Bug Bounty Blogs

Remember: always stay within scope, validate what you find, and follow responsible disclosure guidelines.

Keep exploring. Keep hunting.