WebVerse

Evergreen

Evergreen Property Management's tenant portal — wired up by a contractor in 2018 — has stayed on its first auth implementation for six years. The legacy verifier still has the vendor-debug branch the contractor left in.

Minatour

— 4 min read

Room Description

Evergreen — figure 1

https://dashboard.webverselabs-pro.com/events/evergreen

Briefing

Evergreen Property Management has been "care that scales" since 2008. The marketing site is fine. The tenant portal — the one piece a contractor wired up in 2018 — has stayed on its first auth implementation for six years, even after Maris keeps adding reminders to the ops backlog. The legacy verifier still has the vendor-debug branch the contractor left in.

Initial Analysis

Considering this is a daily challenge, I will try to keep this one short and sweet, as yes, the web application has a couple of functionalities, such as property listing, applying for listings and a member portal page, but the briefing specifically mentions an auth implementation, so we should focus on the portal page.

Evergreen — figure 2

The available endpoints through the UI:

    <div class="ev-nav-links">
      <a href="/units" class="is-active">Available Units</a>
      <a href="/about" class="">About</a>
      <a href="/apply" class="">Apply</a>
      <a href="/contact" class="">Contact</a>
    </div>
    <div class="ev-nav-cta">
      
        
        <a class="ev-pill" href="/portal">Portal</a>
        <form method="post" action="/portal/logout" class="ev-inline-form"><button type="submit" class="ev-link-quiet">Sign out</button></form>
      
    </div>

We have our /portal endpoint that we should take a look at.

Finding the bug

Heading over to the /portal endpoint, we can see that it's a typical login page, but here we have credentials left over for us to preview the portal from within.

Evergreen — figure 3

We could try an SQL injection here, but we don't know the admin's e-mail, and it is asking for an e-mail, not a username, I tried with [email protected] and a basic SQLi login bypass, but that is obviously not the intended route.

Evergreen — figure 4

There's not much to do here as it only lists information, there isn't an option to create a New ticket in reality, just sends us to /portal# .

So now we have two options, either to fuzz for endpoints or look at how we got authenticated.

Evergreen — figure 5

We see there's a Set-Cookie header that gives us our session JWT. Let's take a look at it with jwt.io.

Evergreen — figure 6

We have a role parameter and we see that the algorithm being used is HS256. Now JWTs can be vulnerable for many reasons, but the only way to figure that out is to try, first and foremost, I decided to try and bruteforce the signing secret since I thought it might be a weak signing key.

https://hacktricks.wiki/en/pentesting-web/hacking-jwt-json-web-tokens.html

https://portswigger.net/web-security/jwt

Exploitation

We can bruteforce JWTs using jwt_tool.

./jwt_tool.py eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOjE4NCwicm9sZSI6InRlbmFudCIsImVtYWlsIjoiai5jYXJkZW5hc0BldmVyZ3JlZW5wcm9wLmxhYiIsIm5hbWUiOiJKb25hcyBDYXJkZW5hcyIsImV4cCI6MTc3ODQzNjI0M30.EcwnPpmyVosgdX0r-8AgfkuqYYNSbVIhGV1Ud4ee0nU -C -d /usr/share/wordlists/rockyou.txt
Evergreen — figure 7

Alrighty, bruteforce isn't the way apparently, now we can try to just change the role parameter to see if any signing is even required.

Evergreen — figure 8

Using our new JWT that we replace with our old one through DevTools, we see that we get logged out.

Evergreen — figure 9

This means that there is some sort of signature being used, so a different attack type is necessary. Considering that the description hints at a legacy auth mechanism, we can try to do a none algorithm attack.

Evergreen — figure 10
eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOjE4NCwicm9sZSI6ImFkbWluIiwiZW1haWwiOiJqLmNhcmRlbmFzQGV2ZXJncmVlbnByb3AubGFiIiwibmFtZSI6IkpvbmFzIENhcmRlbmFzIiwiZXhwIjoxNzc4NDM2MjQzfQ.

We can go ahead and replace our old JWT in the Cookies section through DevTools and refresh, or send a new request through Burp Suite, or use browser extensions like Cookie Editor or ModHeader, any of that does the job. I just changed it through DevTools, hit refresh and landed the portal page but with an Admin panel in the top right available to us that leads us to the manager dashboard where the flag is located.

Evergreen — figure 11
Evergreen — figure 12

We have the flag! Now, we could also use jwt_tool to run through all attack types, but it is beneficial to try and do it manually too, since for example, the portal page returns 200 response codes no matter whether you're signed in or not

Read more