OOPS Bank of Ireland

conolan

Decided to look at bank of ireland website for some info. Accidently typed https://www.boi.ie. (note the https)
Got this

boi.ie is a valid website but someone slipped up on the security certificate.

BaconZombie

The SSL Cert is signed to the " www.BankofIreland.Com " so it looks like " BOI.ie " is just a VHost on the same Server so that way you are getting the error.

conolan wrote: »

Decided to look at bank of ireland website for some info. Accidently typed https://www.boi.ie. (note the https)
Got this

boi.ie is a valid website but someone slipped up on the security certificate.

probe

And they are only using a 1,024 bit public key in 2010!!!

You'd have thought that the bank would get a certificate for each domain - it is not going to break the .....

You must start a connection in secure mode from the outset to prevent the risk of a man in the middle attack on the connection. So any organisation offering secure services on the www needs to facilitate SSL/TLS on any website that a customer might use. It is not enough to provide a link "online banking" with https:// - the user has to enter https://www.companyxyz.com to get a man in the middle risk free connection.

The same applies to airlines and anyone who accepts card numbers or other financially sensitive data over the web.

BaconZombie

I find fault with that statement.....

probe wrote: »

And they are only using a 1,024 bit public key in 2010!!!

You'd have thought that the bank would get a certificate for each domain - it is not going to break the .....

You must start a connection in secure mode from the outset to prevent the risk of a man in the middle attack on the connection. So any organisation offering secure services on the www needs to facilitate SSL/TLS on any website that a customer might use. It is not enough to provide a link "online banking" with https:// - the user has to enter https://www.companyxyz.com to get a man in the middle risk free connection.

The same applies to airlines and anyone who accepts card numbers or other financially sensitive data over the web.

probe

BaconZombie wrote: »

I find fault with that statement.....

One is all ears as to why you find fault with the statement.

De-Zombify SVP....

probe

A bank that doesn't support https://bankname.xxx in fully encrypted mode, with at least a 2,048 bit key is displaying gross incompetence and contempt for its customers' welfare and that of the nation's economy, in my view.

We've seen how several governments have been active in the internet space hacking into sites containing private information in the recent past to steal assets/information and use IT to create mayhem to suit their agenda.

BoI appear to have downgraded the security even further since the root posting of this thread.

Whoever is responsible for these issues at the bank should be fired. An incompetent, arrogant idiot.....

Unless one can visit a website starting with an https connection at the outset, a man in the middle attack is possible under the current half-baked https:// infrastructure.

If a bank can't afford a 2,048 bit set-up it is truly bankrupt!

Even https://www.godaddy.com can manage to do it.... with an EV certificate..... Not that an EV certificate matters with a bank you know..... but why should you trust them if they use less than best practice in their business?

Fire the bastard, now... And replace him with someone who isn't living in the dark ages of the 1990s where https:// and 2,048 bit keys used to imply massive computing overhead that took serious computing power to deal with and lots of delay.

No e-commerce website should be permitted to operate with less than this minimum standard - not to mind a bank - by www.dataprivacy.ie. And banks, given the role they occupy in the financial infrastructure of a country, should all support and promote multi-factor authentication to any customer who wishes to use it.

molloyjazz

probe wrote: »

A bank that doesn't support https://bankname.xxx in fully encrypted mode, with at least a 2,048 bit key is displaying gross incompetence and contempt for its customers' welfare and that of the nation's economy, in my view.

We've seen how several governments have been active in the internet space hacking into sites containing private information in the recent past to steal assets/information and use IT to create mayhem to suit their agenda.

BoI appear to have downgraded the security even further since the root posting of this thread.

Whoever is responsible for these issues at the bank should be fired. An incompetent, arrogant idiot.....

Unless one can visit a website starting with an https connection at the outset, a man in the middle attack is possible under the current half-baked https:// infrastructure.

If a bank can't afford a 2,048 bit set-up it is truly bankrupt!

Even https://www.godaddy.com can manage to do it.... with an EV certificate..... Not that an EV certificate matters with a bank you know..... but why should you trust them if they use less than best practice in their business?

Fire the bastard, now... And replace him with someone who isn't living in the dark ages of the 1990s where https:// and 2,048 bit keys used to imply massive computing overhead that took serious computing power to deal with and lots of delay.

No e-commerce website should be permitted to operate with less than this minimum standard - not to mind a bank - by www.dataprivacy.ie. And banks, given the role they occupy in the financial infrastructure of a country, should all support and promote multi-factor authentication to any customer who wishes to use it.

Good post +1

LoLth

probe wrote: »

One is all ears as to why you find fault with the statement.

De-Zombify SVP....

https from the outset does not completely negate the risk of a MITM attack, it just reduces the risk.

MITM on https requires two SSL connections victim -(fake cert)-> mitm -(real cert)-> destination and a fake certificate.

the victim will get a pop up about the certificate but most users will ignore that and continue on anyway.

so, you're both right, sort of. MITM risk is lessened by full HTTPS but it is not negated.

from OWASP:

The MITM attack could also be done over an https connection by using the same technique; the only difference consists in the establishment of two independent SSL sessions, one over each TCP connection. The browser sets a SSL connection with the attacker, and the attacker establishes another SSL connection with the web server. In general the browser warns the user that the digital certificate used is not valid, but the user may ignore the warning because he doesn’t understand the threat. In some specific contexts it’s possible that the warning doesn’t appear, as for example, when the Server certificate is compromised by the attacker or when the attacker certificate is signed by a trusted CA and the CN is the same of the original web site

link: http://www.owasp.org/index.php/Man-in-the-middle_attack

probe

LoLth wrote: »

https from the outset does not completely negate the risk of a MITM attack, it just reduces the risk.

MITM on https requires two SSL connections victim -(fake cert)-> mitm -(real cert)-> destination and a fake certificate.

the victim will get a pop up about the certificate but most users will ignore that and continue on anyway.

so, you're both right, sort of. MITM risk is lessened by full HTTPS but it is not negated.

from OWASP:


link: http://www.owasp.org/index.php/Man-in-the-middle_attack

While there is no such thing as "absolute security" if a bank prevents a customer from initiating an https:// connection at the outset, they are contributorily negligent in the event of hacking fraud. The customer is doing best efforts to create a secure connection. The bank is defeating them.

The customer knows best. If the customer is in a coffee joint or hotel using wifi, if they have anything between the ears, they WILL WANT TO use https:// during their entire interaction with the bank.

If a bank's allows a compromised certificate to get on their servers they are totally, grossly negligent. Another reason to fire the IT guy!

The same observations apply to Aer Lingus, Ryanair, hotel reservation sites, online shopping sites and other Irish "e-commerce" websites - they are not providing their customers with best practice security standards - unlike many airlines, banks and others in the same businesses on the Continent.

LoLth

to clarify, I was referring to the phrase "mitm risk free connection".

the dodgy cert is not hosted on the bank's server, it is generated from the attacking machine, the cert between the attacker and the bank server is valid. its the victim that receives the fake cert. (redirect https://www.boi.ie though ARP poisoning to the attacker machine while simultaenously creating a https connection with the banking site is no more difficult than with http: , the only added security is the questionable cert the attacker has to issue to the victim but if they click the "yeah yeah" button the session will contunue with the victim being none the wiser).

You are right though, a full https session is more secure than being redirected to a https site after the initial visit. similarly, all banking sites should remove all cookies and session IDs from the client machine once the session has been terminated (especially when accessed from a shared terminal).

Gavin

The attacker need not even go to the effort of generating a fake SSL certificate. The Moxie Marlinspike attack described at BlackHat 09 demonstrated this fairly effectively on a Tor exit node. The average user doesn't even check for a https in the url bar.

http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf

And to be fair the bank does have https enabled on their actual online banking site - https://www.365online.com/

stefanovich

LoLth wrote: »

to clarify, I was referring to the phrase "mitm risk free connection".

the dodgy cert is not hosted on the bank's server, it is generated from the attacking machine, the cert between the attacker and the bank server is valid. its the victim that receives the fake cert. (redirect https://www.boi.ie though ARP poisoning to the attacker machine while simultaenously creating a https connection with the banking site is no more difficult than with http: , the only added security is the questionable cert the attacker has to issue to the victim but if they click the "yeah yeah" button the session will contunue with the victim being none the wiser).

You are right though, a full https session is more secure than being redirected to a https site after the initial visit. similarly, all banking sites should remove all cookies and session IDs from the client machine once the session has been terminated (especially when accessed from a shared terminal).

With tools like ettercap available these MITM attacks aren't just the domain of genius hackers either. And yes, most people ignore certificate warnings. I think firefox are doing it right where you actually have to add an exception rather than just click a button.