CAO problems

OTK

Hearing that the CAO's site was suffering load problems, I had a quick peek.

Jesus, first link on the main page 'Apply' goes to a page with a PHP on windows error:
http://193.1.214.170/APP/apply.php
(note the reassuring URL)

Clicking a few more apply links I arrived here
https://websr3.cao.ie/apply.php?page=appform
which contains both secure and nonsecure items. If you click 'Yes' then your application is vulnerable to man in the midddle attacks and you have no idea if any of the page contains secure content.

So they have more than load problems.

CAO is recommending that students who are concerned send them another 10 quid along with a paper application. Jaysus!

OTK

Just noticed this helpful advice below the above link:
"In some cases, a user`s configuration will not allow connection to a secure site. If you are having problems connecting to our secure server, you may wish to continue using the basic payment option."
They then suggest you send them your credit card details unencrypted over http. Fantastic. Only applies to 'some cases' - for example where you are using a computer on the internet.

I doubt any bank's merchant services division allows clients to accept credit card transactions over http.

quinta

Doesn't matter, these attacks work over http and https and they work with 2FA in place aswell.

The key is authorising the transaction in Banking not necessarily the user.

Martyr

yep.. seems like incompetent technical staff at CAO.
although CAO maintain the problems occurred due to large volume of people using the system at once.
not saying its untrue, but can anyone independently verify that? hmm..probably not.
going by above comments, i'd say it was more to do with the code.

on different note.
because it was well announced in advance as the closing date for applications being 1st february, and assuming that most people usually leave it until the last minute, is it possible that criminal gangs could make a note of it themselves when to carry out man-in-the-middle attacks of the SSL connection?
accessing wireless routers, and using ARP poisoning to re-direct traffic??

collecting credit card numbers..etc??

possible?

Capt'n Midnight

Average Joe wrote:

although CAO maintain the problems occurred due to large volume of people using the system at once.

What are the chances of that happening, eh?*

*CAO could provide numbers of applications by date from previous years to show the volume they were expecting and then factor in that most people post stuff early because of delays.

They are a prime target for DDoS attack since the deadline is once per year, so shouldn't they have lots of spare capacity during the critical period. Anyway what's to stop a disgruntled applicant launching an attack in future so as to force them to extend the deadline ?

No such file or directory in C:\Inetpub\wwwroot\APP\apply.php on line 223

Martyr

No such file or directory in C:\Inetpub\wwwroot\APP\apply.php on line 223

OTK

quinta wrote:

Doesn't matter, these attacks work over http and https and they work with 2FA in place aswell.

Are you saying that man in the middle attacks work even with correctly configured Transport Layer Security? How is this?

The key is authorising the transaction in Banking not necessarily the user.

I don't understand what you're saying here. The key to what? Good authentication? Good encryption?

quinta

OTK wrote:

Are you saying that man in the middle attacks work even with correctly configured Transport Layer Security? How is this?

I don't understand what you're saying here. The key to what? Good authentication? Good encryption?

Yep, trick the user into following a link that opens the legitimate site, with its fancy SSL encrypted page and padlock there for all to see, launch a pop window on top of that page, collect the details, and log in to the site and run amok.

Failing that mimic the real site, and again trick the user into entering the details, then pass them on to the real site and conduct transactions. A lot of this is scripted so even 2FA devices can be defeated as the one time code usualy has a lifetime of one minute, plenty of time.

With regards to the other comment, I was mainly referring to online banking, with regards to authorisation. Most Banks will push towards placing strong authentication on the transaction rather than at the log in stage.

There have been little if any notable attacks on credit cards through the act of sniffing them off the wire as they are entered, bar key-loggers of course but they are generally local to the machine.

OTK

quinta wrote:

Yep, trick the user into following a link that opens the legitimate site, with its fancy SSL encrypted page and padlock there for all to see, launch a pop window on top of that page, collect the details, and log in to the site and run amok.

Yes, I've seen this with internet bank phishing emails. Some internet banking sites tell you to close any popups you see.

Failing that mimic the real site, and again trick the user into entering the details, then pass them on to the real site and conduct transactions. A lot of this is scripted so even 2FA devices can be defeated as the one time code usualy has a lifetime of one minute, plenty of time.

Spoofing attacks are meant to be prevented by users checking the URL and certificate but of course very few users understand these. I guess the idea of certificates was to provide the equivalent of a passport for web sites that the user could check for authenticity. Well my mother could make a stab at determining between a real passport and a fake one but what chance would she have determining whether a certificate was genuine? It goes deeper than that because the general public understand the purpose, issuing process, validity and even cancellation of passports but only a tiny number understand these items for certificates. Who knows what a certificate authority or a revocation list are. I think many developers don't even get it.

The advice to the public is often something like 'Check for https and not http' or 'Check that there is a lock icon'. This is like telling people you can trust someone when they have a little book with the word 'passport' on it. Very few people understand the warning messages the browser produces. The whole system is bull****.

(edit)

rather than just moan here are some suggestions:
* For use in browsers, "Class 3 Digital Certificates" should be renamed "Web Site Passports" or "Software Passports" where appropriate.
* These should be issued by the passport authorities of sovereign states only. I don't see how anyone can tell whether a private certificate authority such as Equifax Secure Global eBusiness CA-1 is trustworthy.

For example,
"The government of the United States certifies that this web site is owned by Google Inc." or
"The government of Angola certifies that this web site is owned by AIB Ltd."

* Warning messages should all be analagous to the passport paradigm. For example,
"The passport for this web site issued by the Government of France has expired."
"The passport for this web site has been cancelled by the Government of Germany"
"This passport has been issued by the Government of Chad but that country is currently unable to say whether the passport has been cancelled or not"

*A mix of secure and nonsecure items on a page should be treated as nonsecure.

quinta

Yep, technology cannot solve user education problems.

SSL certs are there to bind a public key to an identity, namely the website, so the site authenticates itself to the user. Of course this falls apart if nobody is checking.

All these guys need is a very small percentage of users to take the bait, to reap the rewards. Regardless of increasing public awareness, somebody is going to fall for it.