Internet Web Site Security (including Banking)

Web Site Security (including Internet Banking)

Following on from my thread relating to Internet Banking, I will now cover some areas of concern regarding Man-in-the-Middle (MitM) attacks. A MitM could be a network technician in your office, your firewall administrator, Telkom, ISP, etc. It could also in some situations be the person sitting next to you. This information is focussed towards Internet Banking, but applies to other web sites too.

It is important to understand the difference between non-secure (http) and secure (https) connections. http connections are unencrypted, and the can be intercepted/modified by a MitM without your knowledge. You have no proof that the content you are seeing is indeed from the site that you think you are accessing.

With a https connection, you can click on the padlock in the corner and see who you are receiving the content from. If you receive a warning message saying that there is an error with the certificate DO NOT continue. You could be providing your details to someone other than the bank (even if the warning message has the Bank's name on it!). You should never enter a Credit Card Number, Pin Number, etc, on a nonsecure web site.

Standard Bank, for example, opens up a non-secure page when you go to www.standardbank.co.za, and then opens up a secure page when you click on Internet Banking. That non-secure page might not really be the page you think it is, and may do other things, such as run JavaScript onclick, or onload. With FNB, if you go to www.fnb.co.za, it automatically redirects you to https://www.fnb.co.za. But a MitM could change the redirect page (which is nonsecure) to open a http pop-under page, for example. In addition, any other non-secure web pages that you might have open, could have been intecepted, modified, and have Javascript running.

Once you have logged in, different banks use different methods to remember who you are. Some banks store a session-ID in the URL's, or a hidden Form. Other banks use Cookies. Cookies are stored by the browser and sent to the server with every request sent to that server for the specific directory. Some Banks use more than one Cookie.

So lets say that you received a Cookie SESSIONID=12345 from https:www.asdfgh.com for the /asd directory, that cookie would also be sent to the server for http://www.asdfgh.com/asd/test.gif, unless it is set to be a secure cookie. And that http request (including the cookie) could be intercepted by a MitM. So if the MitM could convince your browser to send a http request to a similar URL, your cookie could be sent to a server other than the intended server, from where the Cookie could be retrieved. This would work even if the real server doesnt accept http connections.

So now we know that when you access sites such as Internet Banking Sites, you could have non-secure pages open which have JavaScript running on them. That Javascript could request an image to be downloaded from http://www.asdfgh.com/asd/test.gif at regular intervals (but not necessarly displayed - it could even be a cgi script that doesnt return an image). And if there was a cookie for that page, that was set by the https version of that site, the MitM now has those cookies, which could include Session-ID's. And until that session expires on the server (or you log off), if someone has that Session ID, they may be able to access the secure site, such as your Internet Banking.

In a case like that, the server would think that you and the MitM are the same person, because you are using the same Session-ID, so the MitM would not need to log in, and no SMS/email would be sent. In addition, the MitM could most probably make the requests come from the same IP address. And he would be able to see the IP address of the server that you connected to, so if the Bank had multiple servers, he could work out which one you are using.

So quite simply, in cases where security has been implemented like this, the MitM could access your account without you knowing. In the case of Internet Banking, SMS and email alerts would still be received if any transactions were processed and this was enabled, but the MitM would not log on, so one-time-passwords, SMS alerts, etc, wouldnt help you, because the MitM is simply using your Session.

So put all of this together, and decide whether the web sites that you are accessing are secure!

I should point out that some banks, including ABSA, 20Twenty, Old Mutual Bank, cannot be exploited in this way.

I look forward to your comments.

this is a very good point... but nothing to be concerned about if you ask me.

most sites use either http or https, not a combination of both. i have seen some sites that do though.

As I pointed out near the start, Standard Bank uses both, and javaScript could be loaded on the non-secure pages or access the Cookie set on the secure pages.

Also, if you access http://www.fnb.co.za to access fnb, this "redirect page" could be used to open a nonsecure page, which would contain the necessary JS.

It isnt necessary for the nonsecure page to be loaded during the normal course of events - the fact is that a MitM could modify pages (even totally unrelated pages) to load an image from a non-secure page while you are using doing your banking, for example.

Lets say, hypothetically, that you went to Standard Bank, and the (http) home page was modified to include this code...

<a href="https://www.encrypt.standardbank.co.za/" onclick=setTimeout("getcookie();",60000) target="_blank" </a><br>

<SCRIPT LANGUAGE="JavaScript">
<!--
function getcookie() {
var testimg = new Image();
testimg.src = 'http://www.standardbank.co.za/test.gif';
}
//-->
</SCRIPT>

I hope that this explains my point a bit better.

paulcam123 said:

I should point out that some banks, including ABSA, 20Twenty, Old Mutual Bank, cannot be exploited in this way.
.

Click to expand...

Why is that? What did they do differently?

asmith said:

Why is that? What did they do differently?

Click to expand...

From what I can remember, OMB and 20Twenty do not use cookies to remember who you are - they use other methods, such as hidden forms. Most browsers on the default browser settings, do not allow non-secure web pages to access variables stored on secure pages, even if the hostname is the same.

ABSA is very similar to Standard Bank, but the cookie that they use is a secure cookie, meaning that it is only sent with secure requests. If you use FireFox, you can select Edit->Preferences->Privacy->View-cookies (might be under tools->options on older versions) and it will show you:

Send For: Any Type of connection
or
Send For: Encrypted Connections only

Obviously, if it is set to the latter option, the cookie will not be sent with any page that is not secure. This simple change makes a big difference.

Nice work paulcam. Now we need a response from the banks...

Standard Bank has fixed their site

Standard Bank Internet Banking appears to have been changed to use secure Cookies.

It is amazing how quickily they can react if the motivation is right!

Perhaps FNB would like to do the same?