THIS FLAW HAS BEEN FIXED BY THE OWNER AT THE TIME THIS POST IS PUBLISHED. THE CONTENT IS FOR KNOWLEDGE SHARING PURPOSE TO PREVENT THIS FLAW HAPPEN AGAIN
Retail bank industry is booming in Vietnam recent years. Many banks invest for retail business through improve customer service. Mobile banking is one of the hot topics, every bank already had or soon to have mobile banking and mobile apps for their customers use. Winter season is nebulous in Vietnam and the repetitive company work make me so bored. I need a fresh air. Luckily, a commercial bank contacted us for help them idetify the security risks on their mobile application (iOS, Android) and I took care of it.
First thing first, I had a quick checks this application, the UI is too bad but the functionalities work well. It is implemented SSL, constructed manually the packets for sending to server,… The exciting things is not showing up on the face. I have to perform deep analyses using my reverse engineering skills (OMG! RE is my hobby) to understand correctly how the app work. I choose Android version.
After reading the JAVA code blocks in .APK file, I found the way that the app constructed the message to send to the server. Below is the screenshot of the constructed XML structure:
XML structure is vary depend on the function. Next, another encryption function encrypt the XML structure using AES algorithm and put it in the payload (screenshot below):
Return result of this function:
Next, the app is sending to the server 3 parameters: ID, Encoded string (Base64), and function name:
What will this system return if I change the content? I have to re-write to answer this question (fundamental question that we should keep in mind when testing):
Here is the result returned from the server:
Returned result contains:
- Bank’s customer information.
- SerialID: Everytime using app, KickOff function is generating new SerialID and the system send mobile message for activation bank’s mobile banking service.
- SessionKey: is customer session and each login, the system returns a random Session Key.
- ConcatenationID: is to matching information between 2 consequence transactions. Every transaction, the system returns a different ConcatenationID and next transaction must have that one in request data.
Based on my experience, I tried many checks without succeed. Accidentally, I found a flaw, really serious flaw, in the function to get transaction detail:
Below is what their server return, it is normal. Hmm!
If I change to another customer banking number and send to server, can you see it, can you see it? Bingoooooo! I found the Easter Egg.
Customer detail is returned. It is normal, except that this information belong to another customer. This is IDOR (Insecure Direct Object References) flaw. The identical bank number between the logged and the requested one is not matched.
Take advantage, I check another function like below image:
And the result:
If I changed to different bank number, the information is not belong to me returned:
How can I help them to fix this serious security flaw? It will be on next topic…