Pentest Writeup — Birdeye Official writeup

simple network map scan:

Notes:

As usual Since the port 80 is open, we started with a simple look on the browser:

The application seems like a simple Store, we can follow the recon with some to discover if there is any hidden routes, for that we will use :

The Fuzzing reveals some interesting routes :

→ : potential hidden admin assets

→ : potential admin dashboard However these routes are protected for external requests:

which means we should find a way to access these routes internally.

Going back to the web app :

We can see this Products page with a search functionality, after inspecting the page :

The request looked like this :

Based on the naming of the route and the param we can tell that the web server uses a fetch functioning that retrieve the products from the internal route /api/products/

which is CRITICAL, since it opens the door for SSRF vulnerability

SSRF is a vulnerability where an attacker forces a server to make unauthorized requests to its own internal network or to external third-party services. Essentially, the server becomes an unwitting proxy for the attacker.

This means that we can craft a request with the functionality to hit the protected routes we found before :

The request exploit the route to call the /admin/config

From the server means a full 403 bypass with ssrf vulnerability on the protected route with the server giving us :

Admin credentials :

Login panel route:

As expected the is also protected, which means we should use our SSRF finding to access it :

The same as before: we get a with the login page source :

From the browser we see :

Now we successfully got access to the Admin login page : interesting right ! Now we can login.. Well … Not so fast.

Since the page we are seeing is being rendered from the route, Even when using the correct credentials on the broswer… the app wont give us access. The reason is : the is making a request to the , However we need a request to actually preform the login action.

In that case we should force the to make a request on our behalf we should first check what are the request method options we have on the route with:

Fortunately for us, we can see the : , ,

Which means the route accepts requests

Now we can preform the login with :

It is extremely necessary to use the or else our proxy endpoint () will continue using the default request method :

And the server response was:

A header pops up containing the session token along side with confirms that we successfully got access to the admin dashboard… we can simply now use the cookie on the browser using cookie-editor and enjoy the view:

The dashboard allows the admin to run a command on the server.. Since we are obviously the admin now , we can try a simple id command for the sake of test:

Followed by setting up a simple python reverse shell

Finally, we can set up our listener :

And on fire up the run button :

NB : The PE phase was made simple since the lab was focusing on the SSRF vulnerability. starting by identifying the current users:

Now our target is user.

then we check is there is any sudo privileges for the :

digging further into the:

simply for us we can just run the as sev and get the bash shell ;)

now after getting the user we can follow up with the previous procedure to see the sudo privileges we have as user

means that we can run the built in tool on linux to get a root shell.

to do that i recommend using gtfobins :

firing up the command as :

And we successfully achieved root access on the server.

User flag : FLAG{wwwd4t4_t0_s3v_3sc4l4t10n}

Root flag : FLAG{5ev1l_r00t_4cc3ss_4ch13v3d}