[Hacking Bank] Broken Access Control Vulnerability in Banking application [PART II]
As I mentioned in Part 1 the story of finding a Critical vulnerability in Banking mobile app , in the Part II,I will explain how I debugged the obfuscated JavaScript using Chrome Dev Tools to extract the request parameters before encryption, as well as how I found the vulnerability and created the exploitation with Python.
Search for the encrypt and decrypt functions in javascript
In the Sources tab of Dev Tools, you will be able to navigate through your source code.by searching for keywords like (encrypt, decrypt, AES, RSA, key, crypto …) in all files I found the encrypt and the decrypt functions. In addition,,I set a breakpoints on all interested functions by clicking on the line number. [encryptRequestWithSWK , encryptRequest].
After sending the login request from the app, The program will pause at your selected break point (encryptRequest).
PS: By setting breakpoints in encryptRequest and decryptResponse, we can now see both of the request and the response as clear text.
The Request and Response Encryption Mechanism:
First, the app will generate SWK at random and put it with request parameters.
Before sending the request, the encryptRequest function encrypts the parameters with RSA using a stored public key.
After sending the request, the server will encrypt the response using DES3 algorithm with SWK as key which will decrypt by the decryptResponse function.
How I found the vulnerability:
After logging in, I checked the get user details API call, which should return account information (name, email, balance, ..etc).
There are no JWT, API Keys, cookies, or token values in the request [body or headers] to determine whether the user is authorized or not.
The clear text request body contains:
The headers :
The first thing that comes to mind is to change MSISDN. I used LinkedIn to obtain the phone number of a bank employee to ensure that he has an account.
After setting the breaking point in both EncryptRequest and DecryptResponse, I refresh the home page to re-call the get user details API. The browser will pause at your selected breakpoint (encryptRequest). I used the console to overwrite the phone number before encrypting the request and then resumed execution to send the request.
The resume button will jump to the next breakpoint the return value of DecryptResponse, I noticed that I get the victim information (full name, email, balance)
I test also get transaction API , by changing only the phone number I get valid response (victim transaction list).
I used the console to overwrite the phone before the request get encrypted and i resume the execution to send the request.
jumping to the return value of DecryptResponse , i found that i get the victim information ( full name ,email,balance )
I test also get transaction api , by changing only the phone number i get valid response (victim transaction list)
The full API vulnerable with broken access control .
Impact :
With only the victim’s phone number, attackers can obtain full information (Balance, transaction list).
Sending Money API is protected by a PIN (4 digits) that can be easily brute-forced in register a new device API ( Rate limit Vuln)
the exploitation:
For the exploitation, I created a Python script that does the following:
1- Generate random value SWK .
2- Encrypt requests function with RSA public key and create the signature,
3-send the request (get user details api )
4- Decrypt responses function with DES3 using SWK as key
The output:
Conclusion:
the applications need to verify access control checks on the server when each function is accessed . If requests are not verified, attackers will be able to forge requests in order to access into critical data without proper authorization.
