White Hat Hackers Cracked 50 UK Universities' Computer Systems In 2 Hours (bbc.co.uk)

"A test of UK university defences against cyber-attacks found that in every case hackers were able to obtain 'high-value' data within two hours," writes the BBC.

Bruce66423 shares their report: The tests were carried out by "ethical hackers" working for Jisc, the agency providing internet services to the UK's universities and research centres. They were able to access personal data, finance systems and research networks....

The simulated attacks, so-called "penetration testing", were carried out on more than 50 universities in the UK, with some being attacked multiple times. A report into their effectiveness, published by Jisc (formerly the Joint Information Systems Committee) and the Higher Education Policy Institute (Hepi), showed a 100% success rate in getting through the cyber-defences. Within two hours, and in some cases one hour, they were able to reach student and staff personal information, override financial systems and access research databases.

The tests were carried out by Jisc's in-house team of ethical hackers, with one of the most effective approaches being so-called "spear phishing"...where an email might appear to be from someone you know or a trusted source but is really a way of concealing an attack, such as downloading "malware".

Comments

again...

[guygo]

it comes down to the human with an irredeemable case of "click before think".

Re: again...

[dougdonovan]

you gotta be smarter than what you are working with.

This is absolutely no surprise

[gweihir]

Any competent security expert knows that security universally sucks and any experiences security consultant has seen the most demented decisions by "management" that are the root-cause for this. Unless we see personal, criminal liability for those that screwed it up and made the decision to go with bad (but cheap) options, nothing is going to change.

Phishing

[Fusen]

I work at a UK university and the report linked in this story doesn't surprise me one bit.

The key part that enabled the 100% success rate is phishing.

Most Universities will have multiple thousand staff. Most of those staff will not be technically literate. Most technically illiterate people fall for phishing.

We constantly have compromised staff accounts that originate from the most basic poorly crafted phishing emails.

Unless you completely lock down the email system or are able to teach every single staff member the detailed ways of checking email headers and body sources then this won't be fixed.

Re:Phishing

[rtb61]

Parallel networks. If it absolutely needs to be connected to the internet, connect it to the internet. If it does not absolutely need to be connected to the internet, then bloody don't connect it to the internet, run it on an internal hard wired network. Why would accounting need to directly face the internet.

Communications systems should be completely seperate, just communications only, seperate little notebook on the persons desk, next to their smart terminal, one only connects to the university system and the other connects anywhere. If the communications system is compromised so what, do a quick reinstall and you are under way. There is no need to run email etc. on that secured smart terminal, that can run fine on the cheapest Linux notebook you can find.

Parallel networks if you want security for secure systems, otherwise you are betting your security on the shitty non-warranties that come with the software you buy, seriously, how stupid is that. The manufacturers do not trust their software to be secure, hence they do not warrant it as being secure, yet the customer buys it and delusionally expects it to be secure.

Re:Phishing

[TheRaven64]

At Cambridge, most of the systems use a single sign on system and provide tokens for the services, so no one sees your password except the authentication system. They've now integrated that with Office365, so Microsoft doesn't see the password when you log in (when they first set it up, they accidentally sent the entire password database to Microsoft, in plain text. Ooops). It ought to be easy to tell people 'only ever enter your password into raven.cam.ac.uk'. Unfortunately, they also:

• Set the flag in the password field that prevents password managers from caching it (I think most browsers now ignore this), which prevented the obvious clue of 'Hmm, why is this not autofilled, maybe something bad is happening here'.
• Use the same password for email, so every single mail client also contains a copy of the master password for that user's account, rather than something like an OAuth token generated for that device and granting access only to email.
• Have a bunch of new systems written by muppets (such as the new payroll system) that ask for the password and don't integrate with the SSO system, so they require people to enter the password into that site (giving that password to Payroll gives Payroll access to everything, including the student information database - I'm astonished that this is allowed under the GDPR).

I filed numerous bugs against these systems while I was there. None of them were fixed.

Re: Phishing

[Fusen]

We only use SSO for the majority of our systems, we still get people falling for phishing login forms that look like they were created in Word 1997.

There is a plan to use MFA for staff with higher access but trying to get that working for every single staff member with an IT account will be mayhem when they forget their phone or lose their yubikey...

Classic example of the triangle of security, ease of use, speed. Only ever 2 of the three when people just want all 3. And that is why JISC saw 100%

Very few are willing to do security properly all the time as it takes a lot of effort

Re: Phishing

[Fusen]

We also use*

Hacked

[ArchieBunker]

The word is "hacked" not "cracked".

about spearfishing

[epine]

In nuclear silos, according to every movie I've ever seen, at least two people have to turn keys simultaneously to set a "high value" chain of events into motion.

At present, we don't treat private information with the same respect. But is that a good thing?

Status quo: private information is not a nuclear-tipped ICBM.

Cluestick quo: the cat doesn't go back into the bag

orthographic weeds

[epine]

The tests were carried out by Jisc's in-house team of ethical hackers, with one of the most effective approaches being so-called "spear phishing" ... where an email might appear to be from someone you know or a trusted source but is really a way of concealing an attack, such as downloading "malware".

I can almost see adding "wakey wakey" quotes to "spear fishing" for all the fish out of water.

But adding scarequotes to "malware" is at direct eye level with adding scarequotes around "weed" (and I'm not talking about Colorado, either).

Hippy to Yuppie: I'm sorry you think my lawn is covered in "weeds", but I don't happen to see it that way.

But those aren't scarequotes; they're Birkenstock sarcasm quotes, and 90% of the reason that good fences make for good neighbours.

Re: why.. why.. why..

[jabuzz]

Well as far as I can tell they didn't get into my HPC facility. Well its not mine personally but its the one I am responsible for maintaining. Being a multi institutional facility it is of course accessible via SSH on the wider internet. I am of course reasonably confident that they would need a zero day exploit or a compromised account to get in. In the latter case I am confident without a zero day privilege escalation they could only ravage the compromised account, and I have daily backups of that. Its TSM but up to a year, with 10 inactive copies for 31 days, dropping to one there after for 13 months. Then again my monthly nessus scan rarely shows anything. Last one was a couple of my websites where still allowing insecure cryptographic protocols, and that was months ago and more a better ditch these as they are possible to compromise with significant effort now.

Re: why.. why.. why..

[TheRaven64]

SSH security leaves a lot to be desired. Do your users all use ssh-agent? If not, they're probably using ssh keys with no passphrase, which can be stolen by anyone who gets read access to their local filesystem. At that point, the attacker can gain access to your system. If they do use ssh-agent, then the attacker needs to gain debug privilege on their local machine, but that's also not too hard. ssh-agent has no protection against a compromised host OS, for example, unless you set up PAM on your systems to require a second factor such as a U2F key (there's no SGX version of ssh-agent, for example).

If their private key is compromised, ssh doesn't have a global revocation mechanism, so you need to go and find all of the places where an authorized_keys file contains their public key. What is your revocation policy? Do you have a simple way for people to submit a compromised public key and automatically revoke it across your entire system?

By default (though, thankfully, now not the only option) the known_hosts file contains a good list of all systems that an attacker should look at next. Do you require that your users turn on the feature that stores hashes of the machines, or does any compromise of one of your users' systems lead immediately to the attacker knowing that they have compromised a key that gains access to your system.