Ghost St Badmus, a cracked Snr. Application Security Engineer developed a vulnerable Web Application, API and Mobile Application for Pentesters, Bug Bounty Hunters and Security Researchers. To test their skills without messing up real world infrastructures.

It comes with about 40 noticeable vulnerability, and going beyond the OWASP API Top 10, I will attempt to exploit the vulnerabilities individually regardless of their vulnerability name.

This gives you a more hands-on feel for finding vulnerability. My name is CyberPreacher ❤️. Remember that! (Warning: It’s very extensive!!!)

Link to these projects can be found:

🏦 Vulnerable Bank

📱 Vulnerable Bank Mobile Application

The installation process of these labs are included in the documentation on github

Testing Guide 🎯

Authentication Testing

1. SQL Injection in login
2. Weak password reset (bruteforce 3-digit PIN)
3. JWT token manipulation
4. Username enumeration
5. Token storage vulnerabilities

Authorization Testing

1. Access other users’ transaction history via account number
2. Upload malicious files
3. Access admin panel
4. Manipulate JWT claims
5. Exploit BOPLA (Excessive Data Exposure and Mass Assignment)
6. Privilege escalation through registration

Transaction Testing

1. Attempt negative amount transfers
2. Race conditions in transfers
3. Transaction history access
4. Balance manipulation

File Upload Testing

1. Upload unauthorized file types
2. Attempt path traversal
3. Upload oversized files
4. Test file overwrite scenarios
5. File type bypass

API Security Testing

1. Token manipulation
2. BOLA/BOPLA in API endpoints
3. Information disclosure
4. Error message analysis

Virtual Card Testing

1. Exploit mass assignment in card limit updates
2. Analyze card number generation patterns
3. Access unauthorized card details
4. Test card freezing bypasses
5. Transaction history manipulation
6. Card limit validation bypass

Bill Payment Testing

1. Test biller enumeration
2. Payment amount validation bypass
3. Access unauthorized payment history
4. SQL injection in biller selection
5. Reference number prediction
6. Race condition exploitation in payments

1. SQL Injection on Login

SQL injection was fairly easy to spot, the Login page was vulnerable to SQL injection, but the vulnerable point was the username field. And with the help of SQLMap, our exploitation is automated.

username: "preacher'OR+'1'='1'--"
password: "SQL_Attack"
With this, admin dashboard was inevitable. But for note, if the password was vulnerable then do this(with the above username param): password: "'none" .

Now that we are able to gain access to the admin dashboard, that is nice, but that’s not all.. can’t we get access to the database itself?

(On burpsuite, right-click the login request, then click “save item”. Save it with your desired name, it’s time to perform injection using SQLMAP.

┌──(cyber㉿preacher)-[~/Desktop]
└─$ sqlmap -r x-vulnsql -p username --batch --dbs --ignore-code 500,401 --risk 3
-r | request file
-p | payload to attack
--batch | auto answer default option
--dbs | get Database

sqlmap -r x-vulnsql -p username --batch -D public --tables --ignore-code 500,401 --risk 3

sqlmap -r x-vulnsql -p username --batch -D public -T users --dump --ignore-code 500,401 --risk 3

2. Weak Password Reset (brute-force 3-digit PIN)

When it comes to finding vulnerability, my mentor always tells me
always be on the lookout for rate-limiting vulnerability.
And a good spot to find rate-limiting is in brute-forcing OTPs and performing username enumeration.

On your browser, go to the reset password and place in the username of the user you want to reset. An OTP get sent to the user (3-digits). Turn on burpsuite proxy, then place in a random 3-digit pin, so that burpsuite can capture the request. Now it’s time to brute-force.

We have successfully exploited the weak password reset by brute-forcing. On to the next

3. JWT Token Manipulation

Upon logging in to my account, I took note of the JWT token.

Now some flaws that comes with Weak JWT is Authorization Bypass (BFLA)

• Bypassing Authorization check by changing user-level (user -> admin)
• User Impersonation by changing user ID

A powerful tool for JWT exploitation is jwt_tool. And I would be using it to exploit these vulnerabilities. Read the github link on installation guide.

Step 1: Copy your JWT Token
Step 2: Bruteforce the secret to the jwt token.

secret123 is the correct key!, the key is needed to always re-sign every manipulated JWTs. (for authenticity)

Step 3: Manipulate some Json Web Tokens (JWTs).
python3 jwt_tool.py <your-token> -T -S hs256 -p ‘secret123’

Now we’re printed with new JWT token for our communication, it’s also a good step to verify your spoofed JWT — jwt.io

4. USERNAME ENUMERATION

note: username enumeration can be found in different endpoints
1. Login endpoint: you try to log in and an error message shows user not found
2. Password reset endpoint: a debug error of user not found

For this lab, there is a password reset functionality that checks for username. And we will be exploiting that.

since we are using burpsuite, we can go ahead and perform dictionary attack on the username, by sending the request to intruder to find potential username to reset their pass.

Bingo, we found the admin user, and an OTP has been sent for password reset. Using the above password reset vulnerability, we can take over the admin account.

5. TOKEN STORAGE VULNERABILITIES

I read up about token storage vulnerabilities, and what makes it vulnerable is the fact that cookie token is stored in user browser, and that could lead to a potential XSS attack to extract the token. How to exploit? that’s XSS.

But you can observe your browser token and see if it could be manipulated.

A simple XSS to extract document.cookies can capture this token and lead to a user account compromise.

6. ACCESS OTHER USERS’ TRANSACTION HISTORY VIA ACCOUNT NUMBER

Checking the API endpoint on postman, we can see an endpoint that checks for transfer transactions for users. But first, let’s proxy our postman connection to burpsuite. See below on detailed steps

There is an endpoint /transactions/:account-number used for checking for a user transaction history, and the default should deny checking for other account number transactions, but we still have to test it.

So, I logged in as a new user ' admin' the system didn’t validate the naming convention, we found another vulnerability. but that’s not the goal for this task, so from the SQL injection above, I got some other user account number, let’s try to view

We have a 200 OK we found our vulnerability. moving on.

7. UPLOAD MALICIOUS FILES

Upload vulnerability is not among Authorization attack, but we are to go according to the list.
Looking around the web application, there is only one endpoint that accepts file upload. Profile Picture Upload.

And from the third screenshot, we can see a successful upload, whereby the application doesn’t filter file-type upload. This is a medium — high vulnerability depending on the case.

8. ACCESS ADMIN PANEL

For this attack, the admin panel is hidden in a super secret endpoint, and using the way of bruteforcing on the server would not get us to the admin panel, so what did I do?

I exploited a weak token management vulnerability.
By exploiting it, I got access as an admin user and I found the /sup3r_s3cr3t_admin directory.

I took the endpoint and try it as a normal user, and as expected, access is to be denied. So how can we bypass that?
JWT Token Manipulation (See below)

All I did was to get newly modified token and replace it with original token, and unfortunately, the application didn’t resist. Welcome to Admin Panel.

9. MANIPULATE JWT CLAIMS

Manipulating JWT claims still stems from weak JWT implementation.
The other time, we were able to bypass authorization check, by making admin statement true i.e is_admin=true

But this JWT claim is a little different. It allows for user impersonation.
user impersonation allows to manipulate JWT token to be logged in as another user.

We can achieve that by changing the user_id parameter to that of the vicim, then we should claim someone else identity.

So, with JWT Claim manipulation, we could access someone else payment history.

10. EXPLOITING BOPLA (EXCESSIVE DATA EXPOSURE AND MASS ASSIGNMENT)

BOPLA category combines API3:2019 Excessive Data Exposure and API6:2019 — Mass Assignment, focusing on the root cause: the lack of or improper authorization validation at the object property level. This leads to information exposure or manipulation by unauthorized parties.

So our focus will be to see if any endpoint exposes too much data such as user_id and more, or mass assignment allowing us to manually add a property to our body leading to unvalidated authorization bypass (check number 11 for more detail)

Now looking for excessive data exposure.

I searched up and down, and found none. Then I stumbled upon this when I was finding vulnerabilities around the credit card.

At first, it seemed normal not until I saw some endpoint that pointed to using card_id as reference, then I knew I had hit on a jackpot. Then I found some mass assignment vulnerability on the Virtual card page, which would be exploited below.

11. PRIVILEGE ESCALATION THROUGH REGISTRATION

I feel this could have been the top of the list. The first thing that a user does, is to register an account. And while registering, we can see the body field that the appplication sends through the API.

Now another notable vulnerability that we can spot is the weak password and username validation fail. that makes it extra 2 vulnerabilities discovered in the process.

We can see the response of a successful registration, and we are not an admin. So, BOPLA vulnerability has to deal with custom adding the admin property to the application, and letting the application receive the newly registration as an admin. See below…

And with that we’ve successfully escalated our privilege through registration.

12. ATTEMPT NEGATIVE AMOUNT TRANSFERS

Negative amount transfer stems from lack of input sanitization and Broken Function Level Authorization (BFLA) in a form field. First thing is to observe how the API returns data sent through the platform.

Now, let’s try to add the negative sign, to see if we get any error.

13. RACE CONDITIONS IN TRANSFER

What is Race condition?
API4: Unrestricted Resource Consumption
This vulnerability occurs when an API allows clients to consume excessive server resources (CPU, memory, bandwidth, or database queries) without any limits or throttling, leading to performance issues, service degradation, or even denial of service (DoS).

Examples of API4 are bruteforcing, no rate limiting, password spraying and race condition.

Race condition might be fairly hard to spot, but we have a clue to check the transfer endpoint. So here is my balance

Now, I am going to race the system and transfer as much money as I can..

How it works: Capture a single request (or pause time, like I call it)..
→ Don’t forward yet, and send more request so burpsuite accumulate the requests.
→ Then you forward all requests in 1 click using “BurpSuite Forward All” …
→ Exploit the vulnerability… See below

Result? See below…

Race condition exploited successfully.

14. TRANSACTION HISTORY ACCESS

Transaction History Access could be classified as Excessive Data Exposure and Broken Object Level Authorization (BOLA). As it both exposes sensitive data, and no proper authorization check is done to restrict access.

Exploiting this is fairly simple. The mechanics behind it is that it requests for user account number and returns the user transaction history.

Note: even being unauthenticated, the vulnerability still persists… so it is a HIGH vulnerability!!!

Even ADMIN transaction history is vulnerable as well.

15. BALANCE MANIPULATION

Balance manipulation is quite tricky, as there is no clue on this exactly. Now in a way the negative balance exploit had helped us to achieve balance manipulation, but is that all there is to it?
There is more…

After toiling around the API endpoints, and testing for vulnerability flaw, there was only one exploit that stood out as a Balance Manipulation, which is a particular BOPLA vulnerability on register page.

Remember how we added is_admin enpoint on register to allow us become admin? (Yes it’s same thing you’re thinking right now)..
Adding the balance json body to the API and we can see that it manipulated the users balance, and we have more than enough.

The /register endpoint doesn’t sufficiently validate input, and in turn manipulation called BOPLA is made possible.

16. UPLOAD UNAUTHORIZED FILE TYPES

Earlier, we exploited malicious file upload, and this upload also deal with unauthorized file type.
When trying to exploit this vulnerability, we can make use of .php, .xml, .html, .php5, .txt to test it. And remember, never assume that a web application has filtered all because if filtered one. Always probe to confirm.

We have successfully exploited the unauthorized file type upload.

17. ATTEMPT PATH TRAVERSAL

What is Path Traversal?
API8: 2023 — Security Misconfiguration:
APIs and the systems supporting them typically contain complex configurations, meant to make the APIs more customizable. Software and DevOps engineers can miss these configurations, or don’t follow security best practices when it comes to configuration, opening the door for different types of attacks.

Path traversal, also known as directory traversal, is a web security vulnerability that allows an attacker to access files outside the intended directory structure. This is achieved by manipulating user input, such as file names or paths, to navigate to other directories, potentially exposing sensitive information or code.

The only endpoint found that referenced a file in server, yet I tried different Path Traversal technique. Couldn’t pull this one off, or maybe it doesn’t exist.

18. UPLOAD OVERSIZED FILES

Still on the Unrestricted Resource Consumption vulnerability, if there is no maximum file size placed on the application, an attacker can upload 200GB data as picture, which in turn consumes resource, (and if they are cloud-based, it consumes costs)… Exploiting it is simple, upload a large file. See below…

19. TEST FILE OVERWRITE SCENARIOS

Still on the Unrestricted Resource Consumption vulnerability, by allowing repeated upload of a single file, which in turn consumes resources.
So how do we exploit file overwrite scenarios?

Same request sent, yet different filename shown. All other uploads still reside in the server and can be accessed on the URL e.g http://127.0.0.1:5000/static/uploads/610046_etc_passwd

20. FILE TYPE BYPASS

File type bypass allow bypass the filetype the application is requesting for, which still falls under upload vulnerability.
Bypassing file types mostly come from null_byte upload

e.g if a web application requests for a picture (jpg, jpeg, png), a null byte upload allows us attach a .php filetype for example and pad it.

e.g. shell.php%00jpg becomes our upload since websites generally interprets %00 as space

21. TOKEN MANIPULATION

Token manipulation is similar to the JWT tampering that we did above, it’s about testing each of the JWT payload that can be manipulated. For example;

header_type
header_algorithm
payload fields e.g., user_id, username, is_admin, timestamp
also testing adding more fields to the payload.

See below for example:

Another vulnerability found on the lab, is that the token lacks expiry time, and that’s a vulnerability in itself.

22. BOLA/BOPLA in API endpoints

Exploiting Broken Object Level Authorization (BOLA) and Broken Object Property Level Authorization (BOPLA) in the web application can be quite tricky to spot. But here are the few ones spotted.

Adding is_admin:true on registration screen leads to a BOPLA attack.

Adding balance:10000 on registration screen leads to a BOPLA attack.

Updating my card limit allows for a BOPLA current_balance attack. As well as unauthorized update of other users’ card through the card_id parameter.

Unauthorized access of a users’ card transaction history leading to a BOLA attack.

23. INFORMATION DISCLOSURE

Information disclosure comes from excessive data exposure. When application fails to properly sanitize output and exposes a lot of sensitive data. Some data exposure found includes:

Though might not be fully considered as excessive data exposure, the ID parameter though is exposed, and getting from the exposed id, we are able to tell the card database key value, leading to BOLA attacks on different level.

24. ERROR MESSAGE ANALYSIS

On the login page, I tried performing a SQL injection attack by sending some SQL queries, and from the output I was able to tell that the username parameter was vulnerable to SQL injection. (Check above for SQL injection on Login page).

25. EXPLOIT MASS ASSIGNMENT IN CARD LIMIT UPDATES

API3:2023 — Broken Object Property Level Authorization: This category combines API3:2019 Excessive Data Exposure and API6:2019 — Mass Assignment, focusing on the root cause: the lack of or improper authorization validation at the object property level. This leads to information exposure or manipulation by unauthorized parties.

Got confused on the difference between Mass Assignment and BOPLA… but yes, that’s that.

Now let’s exploit the vulnerability on the card, through the API on postman, here is my current balance.

Exploiting mass assignment is similar to that of BOPLA, where user adds new property to the JSON field.

26. ANALYZE CARD NUMBER GENERATION PATTERNS

The card pattern was very random, and after generating over 5 cards and not seeing any pattern whatsoever.

I’ve analyzed it and there’s nothing I can do here.

27. ACCESS UNAUTHORIZED CARD DETAILS

Accessing unauthorized card details can be considered as a BOLA attack, and thus strict authorization is needed. Now we were able to identify excessive data from the virtual card and discovered that the card runs on id making it easier for us to guess the next card id.

Whilst there was no direct means of getting a user card details, making use of the /update-limit endpoint revealed the card details.

leading to unauthorized access to user card details.

28. TEST CARD FREEZING BYPASSES

Testing the card freezing, firstly I froze one of my virtual cards, then I got to pay the bills using the frozen card. On the main dashboard, the frozen card doesn’t appear on the list but by manipulating the request and placing the frozen card_id . But then, as expected it denies the request.

Looking around again, there is a card_freeze endpoint which requests for card id. What if we use another users’ card id. Will it accept it?

Bingo, we successfully froze a users’ card. I can’t really call it a freezing bypass; it is more of an authorization bypass on card freeze.

29. TRANSACTION HISTORY MANUPULATION

Transaction History Manipulation allows us to bypass authorization check for getting another users’ transaction history leading to a BOLA attack.

Moving to the card_id/transactions endpoint, we are able to get users’ transaction history by card_id. Now, most of the payment shows pending for buying a bill, so none have shown completed. Hence, why I believe the transaction history is empty.

But if we take a look at other card history, we get a success message. Which tells us that the request was successful.

30. CARD LIMIT VALIDATION BYPASS

Card Limit validation bypass. This vulnerability allows us to store more money than the limit capacity.

Default limit and balance below.

On the upload limit vulnerability, we are able to exploit BOPLA vulnerability by adding a current_balance to exploit extra money.

The request got accepted and the card limit is set, and the balance got accepted.

The card is not meant to accept a value greater than the limit but it is exploited through BOPLA attack.

31. TEST BILLER ENUMERATION

There are billers that allows us to pay for bills and subscription, so let’s see if we can get more details on the billers.

Let’s go to the /api/billers/by-categories/:category_id and guess the category ID by integer number 9 i.e 1,2,3,4,5,6 etc

By enumerating the category, we are able to get more information about the individual billers in the category.

32. PAYMENT AMOUNT VALIDATION BYPASS

This vulnerability might be ranked low-medium, because it doesn’t properly validate the minimum payment amount, and also does not have a maximum payment amount. And that could pose a problem on the long run for banks, as scammers for example can get a money funded into their account and then pass all the money into a payment bill. Making money laundering a success.

So I exploit this by paying below the minimum amount requested, and here is the output.

No error given, we have been able to exploit this. Paying $1,000,000 into the bill is also accepted, leading to a High Vulnerability.

33. ACCESS UNAUTHORIZED PAYMENT HISTORY

Now since we are in the BILL category, there is an endpoint to get bill history. Now HOW CAN WE ACCESS UNAUTHORIZED PAYMENT HISTORY?Since there’s no ID to place in?

Simple, let’s try to manipulate the token and get the payment history.
if you’re not familiar with JWT token manipulation, scroll up to №3

So here is my original payment history.

Now after JWT token manipulation, and refresh the payment history, we get another users’ history.

34. SQL INJECTION IN BILLER SELECTION

No SQL injection found in the Biller Selection.

35. REFERENCE NUMBER PREDICTION

Reference number prediction allows us to predict the next reference number for other user transaction.

After making some bill transaction, let’s observe the reference number.

We can notice the pattern of the reference number.

36. RACE CONDITION EXPLOITATION IN PAYMENTS

Finally, race condition in payment transfer.

API4: Unrestricted Resource Consumption
This vulnerability occurs when an API allows clients to consume excessive server resources (CPU, memory, bandwidth, or database queries) without any limits or throttling, leading to performance issues, service degradation, or even denial of service (DoS).

Examples of API4 are bruteforcing, no rate limiting, password spraying and race condition.

First thing, is to enable my intercept and send as many requests as possible then, we have this; leading to screenshot number 2

37. APK Hardcoded Flag

For the Apk SAST, I will be making use of Jad-x (https://github.com/skylot/jadx/releases), after installation. Download vuln-bank apk (https://github.com/Commando-X/vuln-bank-mobile/releases/tag/v1.2.0) and let’s get into the analysis.

Open the Jadx-gui, and open the APK inside of the JADx, we are brought with its source code.

Going to to its MainActivity endpoint, we can see the sources code of the Android application, and taking a closer look into it, we can find some interesting USERNAME and PASSWORD hints… and Arghhh we found our FLAG…

38. SECRET ENDPOINT DETECTION

Notice that over the hardcoded flag, we have a class being pointed to Secrets, exploring into the Secrets class by double clicking it, we get to find out hidden debug endpoint, coupled with an hardcoded admin JWT.