<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="3.10.0">Jekyll</generator><link href="https://qu4ker.com/feed.xml" rel="self" type="application/atom+xml" /><link href="https://qu4ker.com/" rel="alternate" type="text/html" /><updated>2026-07-10T23:14:58+00:00</updated><id>https://qu4ker.com/feed.xml</id><title type="html">qu4ker</title><subtitle>Just some bug bounty writeups. Breaking down real-world findings, exploitation techniques, and practical methodologies in cybersecurity.</subtitle><entry><title type="html">Exposing Internal Endpoints via Path Traversal</title><link href="https://qu4ker.com/posts/path-traversal/" rel="alternate" type="text/html" title="Exposing Internal Endpoints via Path Traversal" /><published>2026-07-10T00:00:00+00:00</published><updated>2026-07-10T00:00:00+00:00</updated><id>https://qu4ker.com/posts/path-traversal</id><content type="html" xml:base="https://qu4ker.com/posts/path-traversal/"><![CDATA[<p>While hunting on the main web application of a private bug bounty program (which we will refer to as target.com), I discovered a Path Traversal vulnerability with a High severity rating (CVSS 7.5). The target is a mature platform built with Next.js on the frontend, Strapi as a CMS for image and content management, and a legacy Vista Connect API handling critical business operations like ticket purchasing and seat reservations.</p>

<h2 id="the-discovery">The Discovery</h2>
<p>I began my assessment by using the application as a normal user, proxying all traffic through Burp Suite. Direct interactions with Strapi and the Connect API did not reveal any obvious misconfigurations or quick wins. However, since the application is built on Next.js, it is highly common to find massive amounts of compiled business logic, internal routes, and microservice references embedded within the JavaScript bundles.</p>

<p>After meticulously reading through the <code class="language-plaintext highlighter-rouge">.js</code> files, a specific string caught my attention:</p>

<figure class="highlight"><pre><code class="language-plaintext" data-lang="plaintext">https://target-portal-prod.azurewebsites.net</code></pre></figure>

<p>This Azure subdomain was acting as a remote testing API that had been left referenced in the production code. One of the API calls being made by the JavaScript to this endpoint was:</p>

<figure class="highlight"><pre><code class="language-plaintext" data-lang="plaintext">/api/v1/REDACTED/GetREDACTEDBySession</code></pre></figure>

<h2 id="fuzzing-hidden-parameters">Fuzzing Hidden Parameters</h2>
<p>When interacting directly with this Azure endpoint, it became clear that it required specific parameters not explicitly declared in the base URL structure. To uncover these, I utilized <code class="language-plaintext highlighter-rouge">x8</code>, a highly efficient parameter fuzzing tool designed to discover hidden keys.</p>

<p>Within seconds, <code class="language-plaintext highlighter-rouge">x8</code> successfully identified a valid parameter: <code class="language-plaintext highlighter-rouge">session</code>. I then proceeded to send a test request using a random numeric identifier as the value, and the backend responded in a controlled manner:
<img src="/assets/images/2026-07-10-path-traversal/1.png" width="700" /></p>

<h2 id="path-traversal">Path Traversal</h2>
<p>After seeing a normal, predictable response, I decided to test how the server handled unsanitized input within the <code class="language-plaintext highlighter-rouge">session</code> parameter. By injecting a basic directory traversal sequence (<code class="language-plaintext highlighter-rouge">../</code>), the backend failed and exposed the following error:
<img src="/assets/images/2026-07-10-path-traversal/2.png" width="700" />
This error message gave me some details. It revealed that the Azure API was acting as a proxy or gateway, blindly concatenating the <code class="language-plaintext highlighter-rouge">session</code> value into an internal route pointing to a Connect WSVistaWebClient API service (<code class="language-plaintext highlighter-rouge">/WSVistaWebClient/RESTData.svc</code>).</p>

<p>Attempting to traverse further back by jumping four directories up (<code class="language-plaintext highlighter-rouge">../../../../</code>), the server tried to locate a file outside the <code class="language-plaintext highlighter-rouge">seat-plan</code> directory:
<img src="/assets/images/2026-07-10-path-traversal/3.png" width="700" />
Despite getting a 404, this confirmed the server was actively processing the directory escape sequences and navigating backwards through the IIS virtual directory structure. However, attempts to guess typical files (health, metrics, ping, etc.) failed to return a 200 OK, likely because the backend was still appending a suffix or a route extension to my input, breaking the internal URI.</p>

<h2 id="thank-you-">Thank You, #</h2>
<p>To bypass the forced route concatenation occurring on the backend, I changed my approach. I decided to inject a URL-encoded hash fragment (<code class="language-plaintext highlighter-rouge">%23</code> -&gt; <code class="language-plaintext highlighter-rouge">#</code>) at the end of the payload. The goal was to force the backend’s routing parser to interpret any dynamically appended strings as a URI fragment, effectively truncating them.</p>

<p>By sending <code class="language-plaintext highlighter-rouge">test%23</code>, the reflected error changed:</p>

<figure class="highlight"><pre><code class="language-plaintext" data-lang="plaintext">Description: HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable. Please review the following URL and make sure that it is spelled correctly.
Requested URL: /WSVistaWebClient/RESTData.svc/cinemas/1016/sessions/test</code></pre></figure>

<p>Bingo! The server discarded the subsequent route components and processed my input exactly as provided. By combining the Path Traversal with this truncation technique, I could force the gateway to target resources on the web server that shouldn’t be externally accessible.</p>

<h2 id="getting-odatasvc">Getting OData.svc</h2>
<p>Executing a four-directory traversal and injecting the OData service definition file (<code class="language-plaintext highlighter-rouge">OData.svc%23</code>) finally returned a successful status code:
<img src="/assets/images/2026-07-10-path-traversal/4.png" width="700" /></p>

<h2 id="limitations">Limitations</h2>
<p>During further exploitation attempts, I realized that the Path Traversal was strictly confined within the context of the IIS worker process and its assigned virtual directories. Due to Azure Web Apps’ container isolation restrictions, it was impossible to interact with the OS (e.g., fetching <code class="language-plaintext highlighter-rouge">/etc/passwd</code> equivalents).</p>

<h2 id="impact--conclusion">Impact &amp; Conclusion</h2>
<p>Even though the traversal was sandboxed to the web server’s root directory, the vulnerability was still classified as High (7.5) and awarded a generous bounty. The impact factors included:</p>
<ul>
  <li>Information Disclosure: Unauthorized exposure of internal business service endpoints (<code class="language-plaintext highlighter-rouge">OData.svc</code>).</li>
  <li>Access Control Bypass: The ability to query internal backend logic without requiring valid session tokens or administrative privileges.</li>
</ul>

<p>The vulnerability was promptly reported and remediated. The remediation consisted of decommissioning the affected API entirely. So… yeah. See you next time!</p>]]></content><author><name></name></author><summary type="html"><![CDATA[How a # exposed internal endpoints via a Path Traversal]]></summary></entry></feed>