Hacking

Hack I-Bank Pro

In this article we are going to see some major vulnerabilities typical of a remote banking application. We found an interesting vulnerable machine created by PHDays team. We hosted the vulnerable machine in Virtual box and logged in with these credentials: Username:root Password:phd2012. We identified the IP for that machine and opened it from the browser.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

[download]

Here we can see the login page for the bank which requires a name and password. We don't have any credentials, so we have to hack. The first thing we do is search for internal files which could reveal some information about the application. So we crawled the application's URL by using Burp Suite Spider.

As we can see in the above figure, we found only two links: the login page and the recovery page. The recovery page leads to the forgot password functionality.

Now the for recovering password, we need the login name. We guessed here for default credentials such as admin, ibank, bob, etc. But nothing worked.

But we noticed the error message "Identifier not found"; this is a good indicator that we are dealing with numbers rather than a username that could be lower and upper-case alphanumeric, reducing our scope of required characters, making it easier to brute-force. Again we move on to the login page to find something juicy.

We can see the three parameters in this authentication page: Login, Password and CAPTCHA.

Hmm.. CAPTCHA. Let's find where it's coming from. Just right click on the CAPTCHA image and select the Inspect element.

Now we can see a link there: image.php has a code parameter holding a value which looks like a Base64 encrypted. We took that value and decoded it from base64 decoder by using Burp Suite Decoder.

After decoding, we get a value =ljN5YTO. We were confused a little bit, but noticed that it's again a Base64 and it's reversed so we have to reverse this output like this OTY5Njl= and then decode it again.

Now we get the exact CAPTCHA value, which is 96962. 'Til now we identified how CAPTCHA is generating, but this will not help us to gain access to the bank account. We move on to do some user credentials enumeration. First give a login and password whatever you want and in CAPTCHA don't give the right value. Let us see if the CAPTCHA is working or not.

After logging with wrong credentials and invalid CAPTCHA the application is giving an error message, "Wrong code".

Again, try to login with any credential, but this time put the valid CAPTCHA value and see this time how it is responding.

After trying to log in with valid CAPTCHA values, the application is giving again an error, but this time it is different , "Identifier not found".

Now we started to check whether the CAPTCHA is properly implemented or not. Generally CAPTCHA is used to stop the automation process in order to prevent a brute force attack. Most of the time the CAPTCHA is not implemented properly. If the CAPTCHA value is not changing per request, then the login is vulnerable to a brute force attack. So let us verify. Login with any credentials and put the right CAPTCHA value and intercept the request with Burp Suite.

Here in the above figure, we can see the intercepted request has a login value, password value, code and another code which is the base64 encrypted CAPTCHA code. Now we will repeat this request multiple times to verify that the CAPTCHA is validating or not. We are going to use Burp's Intruder to repeat this request. Select Action and then select Send to Intruder as shown in the figure below.

Select the Intruder tab and we can see our target is added.

Then select Positions and click on the Clear button for clearing all default positions selected by Burp's Intruder.

After clearing the positions, select the Login parameter and password parameter values and click on Add.

We can see in the below figure that our position is set on both parameters.

After that, select the attack type and set it to Cluster bomb.

Now select the Payload tab for setting payloads on both positions. Payload set is 1, which means the first position is the Login parameter value. Leave the Payload type value set to Simple list and in the next section, select Add from list to Usernames, which has a list of default usernames.

Next, change the Payload set to 2. Leave the Payload type as it is. Select Add from list and choose Passwords, which contains a large default password list.

Everything is set. Now run the Intruder. Select Intruder from the Burp's menu and select Start attack.

Our attack is started; check the attack response. We noticed that the CAPTCHA value is the same as it was given at the login time. In the below figure, we selected request no.304 and its CAPTCHA value is the same as the first request. It means the CAPTCHA is not working properly and we can do brute force here.

'Til now what information we have:

1. We can do brute force

2. The application is using Identifier as login

Predictable user identifiers are far more dangerous than it can seem. This application is also using Identifier as we have already seen, just like most identifiers in actual remote banking applications e.g 100000, 1000001 etc.

So we have to create a list of identifiers for brute forcing. We use a small Python script for creating an identifier list.

Line 3: Creates a text file called "numericWordlist.txt" the attribute 'a' allows content to be appended to the text file.

Line 5: Is a loop that starts from 1000000 to 1000101

Line 6: Appends the generated number to the text file.

Line 8: Simple closes the text file.

Just save the code with py extension and run. It will generate a Wordlist.txt with identifiers list.

Now that we have the login identifier list, it's time to brute force. Intercept the login request as we did previously and send the request to the Intruder and add positions. Then in the Payload option here we are going to use our worldlist.txt, so select Runtime file from Payload type and select file to browse the worldlist.txt file from its location.

Then run the intruder attack, and during the attack we notice that there is something different with Length. We saw two types of length: 4749 and 4755.

The identifier from 1000001 to 1000005 has content length 4749 and the rest of the identifiers have 4755. So let us see where is the difference? We selected the 4749 length request, looked on the HTML response, and rendered the page and we saw an error message "Wrong password".

Then we selected the 4755 Length request and looked the HTML response. It's showing a different error message, "Identifier not found"

So now we have confirmed valid identifiers.

Valid Identifiers: 1000001, 1000002, 1000003, 1000004, 1000005

We have the login names, now we need the passwords for these accounts. Again we will brute force with these identifiers, Login with the identifier and intercept the request and send it to the intruder. This time, don't change the attack type. Keep it at Sniper, because we are adding only one position in the password parameter.

We created a password list, which can easily be found on the Internet.

Next select the Payload options and change the Payload type to Runtime file and select the password list.

Then run the Intruder. After running it, we found that there is one request with a status of 302 and content Length is also different than others.

The password for that request is 1234567 as can be seen above. We tried to login with that password and it worked.

By using this process, we have three out of five login details:

1000001:1234567

1000004:qwerty

1000005:1234567

Conclusion: After pentesting this application we saw some typical known vulnerabilities which lead to compromise a user's account. Some major vulnerabilities such as weak passwords, CAPTCHA not implemented properly which leads to possible brute force, and improper error message handling leads to user enumeration.

References:

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

http://www.slideshare.net/phdays/typical-vulnerabilities-of-ebanking-systems