From NA to P1, How i was able to get access to a Bank Admin Panel

Hello everyone, Today, I’m excited to share a story about how I gained access to a bank’s admin panel while working on a bug bounty program. Before we dive into the technical details, let me introduce myself. My name is Yousef, and I’m a Cybersecurity Engineer with a passion for uncovering vulnerabilities in my free time as a part-time bug bounty hunter.

In this write-up, I’ll walk you through one of my findings that allowed me to exploit a hardcoded Basic header to obtain admin-level privileges.

So let’s start, Consider the company name as “target.com”.

The first step was to collect all the subdomains related to the organization using different tools like ( Amass, subfinder, findomain, etc..)

Once I gathered a list of all possible subdomains, I filtered out the live ones using httpx to ensure I was only working with active domains:

cat all_subdomains | httpx -sc -td -server -cl -title -o httpx

Now, I have a lot of useful information but for me, i always like to start with the easy way so I will start using the grep command to get well-known products and CMS like ( Jira, Grafana, Jenkins, Drupal, and WordPress ).

But at that moment i didn’t find anything interesting. So, I opened my burp and started doing some manual dorking while keeping burp at the background.

I didn’t do anything fancy just normal Dorking site:target.com ext:php

The goal here was to identify potentially sensitive files or pages that might have been indexed but not meant for public access. After about half an hour of Dorking, I returned to my Burp Suite dashboard to review any intercepted traffic and requests.

To my surprise, I stumbled upon a js file that referenced an API call with a GET method. Digging deeper, I found that this request contained Basic authorization header calling a subdomain, backend.blog.target.com

At that moment I was very excited thinking that I would get my bounty easily

My Bad I didn’t try to show most of the impact at this time so I just used a normal WordPress endpoint that was meant for authorized users and showed that it gave me 401 when I called it without the header and when I used the header it gave me 200 OK with all the information

This simple test effectively showed that the hardcoded header provided unauthorized access.

At this moment I thought that this was enough and immediately went to report it.

I was very excited waiting for the triage. But TAL has a different opinion and closed my report as NA saying that they were unable to identify any security impact.

It was Friday night, and I knew that Bugcrowd wouldn’t respond until after the weekend, giving me a couple of days to try and escalate the finding and demonstrate a more solid impact.

I considered two possible paths for escalating the finding:

Accessing the wp-admin Directory: The first approach involved trying to reach the wp-admin directory and logging in using the credentials I had obtained from the hardcoded Basic header. If successful, this could give me access to the WordPress admin panel, potentially exposing more sensitive functionality.Understanding the WordPress API: The second option was to dive deeper into how the WordPress API worked. By understanding the structure and behavior of the API, I could identify endpoints that might be accessible with the header and demonstrate their impact. This would allow me to show that even without direct admin access, there were other ways to exploit the system.

Let's Dig deep

First, I tried to access thewp-admin directory but it was redirecting me to their okta panel, Unfortunately, the creds didn’t work there.

I went back to the subdomain and started fuzzing again to my surprise at this moment I found /dir/wp-login.php accessible, I quickly tried logging in using the credentials I had obtained from the hardcoded Basic header. My heart raced as I entered the credentials, hoping this would grant me access to the WordPress admin panel. But just as I thought I was in, a new obstacle emerged 2FA was enabled on the account.

Now i only have the second option to understand the wordpress API. First thing that came to my mind is to see if i’m able to upload any plugin using the wp-json api endpoint. But After alot of searches i kenw that it’s not possible due to security reasons . I had the ability to activate and de activate any plugin but i thought that might cause a problem.

After spending so much time I found an interesting way to prove the impact, the famous /wp-json/wp/v2/users/ but this time not to disclose the users of the website but to create a backdoor user with admin privilege

It was documented in the documentation that you can create a WordPress user by sending a POST to the endpoint /wp-json/wp/v2/users/

POST /wp-json/wp/v2/users/ HTTP/2
Host: target.com
Content-Length: 135
Content-Type: application/json;charset=UTF-8

{"username":"Bugcrowedpocc",
"email":"xxx@bugcrowdninja.com",
"password":"xxxxxx",
"roles":["administrator"]}

Immediately, I went to wp-login.php and entered the credentials I Just created then I was prompted to enable the 2FA, After enabling it got access to the admin panel.

And here we go mission accomplished

That’s the end of my write-up. I hope you enjoyed it and learned something new!