Assalamu’alaikum (Peace be upon you)

Okay, this is my second post, reading the title is very interesting right?

I started with the mechanism of this application. My mobile number was registered in this mobile banking application and I was set up my PIN for login.

My user profile config was encrypted in the internal storage of the mobile device. Because I don’t have enough knowledge about mobile pentesting. I’m doing this test with my web app methodology that I know. :D

This is how the mobile application work:

1. Every time the application load for the first time, it requests the back end API (api/v1/credential/status) to check the mobile banking number (mobile phone) registered in the device for the status. If the number status was OK then the server will respond like this:

(“Sukses” mean success). The request and response were encoded with base64, so can easily be decoded.

2. Then the application will pop up the input form for a PIN to log in.

3. For changing the PIN, the User will be prompted for OTP verification sent to the mobile phone number registered in that mobile banking app.

That was a normal flow for this mobile banking application. Now here is how I found (accidentally) bypassing the OTP verification mechanism for changing the PIN.

Enumerating the status response

Me and my team registering 4 mobile phone number to the banking system. and because I was trying to check the anti automation mechanism, my phone number was blocked. so, when I open my mobile banking app, it shows the response like this:

My account was blocked and required me to go to the nearest ATM Machine to activate it again. :’D but there is an interesting in here, I got a different response from my mobile number. So, what happens if I change the phone number (in request) it is possible to enumerate the status of the phone number?

Luckily, there is no limit to use api/v1/credential/status function, so I made some payloads including all 4 numbers for testing this app to know the status. I fire up the burp intruder and I found 4 status from my payload.

1. Success status
2. Already registered and need to set the PIN

3. Blocked (My mobile phone number :D), and

4. Unregistered mobile phone number

Some of you can already guess what the next step will be, right? point number 2 is very interesting. let say it’s number 08123456789. what happens if I change my phone number to 08123456789? so I turn on the intercept and load my mobile app banking, and it comes with the request to api/v1/credential/status, I change the phone number parameter to 08123456789. And uupsss, the application shows up the setup PIN form. (I can’t show the screenshot for this, because the identical of UI).

At this point, I think I successfully set up a new PIN for the 08123456789 mobile number. But It is not. What happened was I successfully change my own PIN but the status was still blocked.

So where are the takeover possibilities?

Although the probability is very small, it still could happen. If someone lost their phone and or attacker has the ability to access the device and the owner haven’t had time to block the account yet. The attacker will try to full control the device, (rooting or jailbreaking), and if the device is successfully rooted, an attacker can perform the above test.

Again the chances are very small but prevention is better than cure right?

My notes:

• if is any chance of doing some enumerating condition, don't miss that test.
• Having a test user with multiple conditions will make the test more comprehensive.

Okay, that's all for this time. once again, I apologize for the limited English. I hope it can be understood.

Please comment if you have a good resource about mobile penetration testing, books or websites, etc. I will be very grateful. And also I'm interested in Brida, anyone already uses it for mobile pentesting especially for android app? please share with me.