Data breaches in focus
Making your website more secure from hacking
Learning lessons from the University of Greenwich
The University of Greenwich was recently fined £120,000 by the Information Commissioner’s Office (ICO) because of a breach which resulted in the personal data of some 19,500 people being stolen and then leaked.
Here we dissect what it was all about and how other organisations can avoid similar pitfalls.
The kind of attack that Greenwich suffered isn’t new, and is still a vulnerability for many organisations, including other universities.
Why did the ICO give this level of fine?
The ICO thought the breach serious enough to levy a significant financial fine because of the number of data subjects, the nature of the personal data held and the potential consequences of the leak.
At a number of points in the findings, the ICO criticises the university for not knowing about the vulnerability and not resolving it until long after (three years) it was first exploited.
“For no good reason the university appears to have overlooked the need to ensure that it had robust measures in place despite having a central IT team,” said the ICO report.
What was at the bottom of the attack?
The ICO said the breach was through a decade-old, long forgotten microsite. This microsite was reportedly created for a conference in 2004 by a student on behalf of an academic.
Unfortunately for Greenwich, this microsite contained a crucial security flaw and it remained online and forgotten long after the conference had end.
What is SQL Injection?
This security flaw in the micro-site was exploited using something known as an SQL Injection attack.
At a very basic level, an SQL Injection attack is where an attacker uses ‘input fields’ on a website to trick the site to perform functions or return information it wasn’t originally designed to do.
Imagine that I’m collecting a delivery from the post office, and the postmaster behind the counter asks me to write my name onto a form so they can locate my package. I write: “Rob Savage, and all the other packages too please”. And instead of giving me just my parcel, he follows my instructions and gives me everything else in storeroom too.
Madness right? But this is exactly how an SQL injection attack works - it misuses input opportunities to give instructions to perform other functions.
How does an SQL Injection attack work?
I’m going to try and not get too technical but if you want more information, here it is. If you're not interested in the detail you can skip past this section.
Now imagine a basic website. You enter your username into a box and when you hit submit it displays for you the email address associated with your account.
Behind the scenes, when you hit submit, the site will fetch your information from the database.
It does this by using a ‘query language’ known as SQL (Structured Query Language) and the internal command will look something like:
By inputting my username “Rob”, the query the site sends to the database will be:
The database will then be searched for any records within it where the username is ‘Rob’. The email address associated with these identified records will be found and displayed on screen.
But what would happen if, instead of just inputting my username into the box on the site, I inputted some additional SQL code. For example, what would happen if I entered “Rob OR 1=1”? Well, the query sent to the database would be:
where username=Rob OR 1=1;
As the database processes this query it will evaluate it as a match for every record, regardless of what the username is, because 1 is always equal to 1.
Without this vulnerability being dealt with effectively, this request would return every entry in the database and will display on screen every single email address stored within the database (oops).
This is a very basic example and simplified to illustrate the point, however, the theory remains the same.
In the case of The University of Greenwich, the breach was a result of an attacker using an input field that allowed attendees of the 2004 conference to upload conference papers.
Unfortunately, this was permitted without validation or credentials.
This data input field was used to gain access to an account with sufficient privileges to upload malicious code to the site. And later download the personal data.
Could the university have avoided this?
The simple answer is yes.
The ICO report said: “SQL Injection is a common and well-understood security vulnerability, and known defences exist.”
So. What’s the fix?
A number of failings led to this breach. And a number of things could have been done that would have prevented this attack.
- Security by Design - Firstly, the micro-site should have been coded in a way that prevents SQL Injection. This is relatively simple to do. However, I think the student could be forgiven for his/her mistake here. The landscape was very different in 2004 and they were writing a site that was originally to be used by a limited audience for a finite period of time, not one that would still be open to the whole world 12 years later.
- Housekeeping – Quite simply, the site should have been taken down long ago, as soon as it was no longer required. The more doors and windows there are in your house, the more likely a fault or flaw – or a way in - will be found by an intruder.
- Least privilege – The principle of least privilege is that all accounts should only have access to information or be able to perform the activities needed to perform their role - and nothing else. That way, the effects of a breach, should one occur, can be contained and limited. Without knowing all the intricacies of this particular attack it’s difficult to say if this could have helped but it’s likely to be a factor. And simple, easy and relatively inexpensive technologies could have sorted this out.
- Web Application Firewall (WAF) – A WAF is a computer system that monitors traffic between users of a site and the site itself. The WAF applies a set of rules of what is and is not permitted.
- Advanced Web Application Security – The problem with a WAF is that it’s based on a set of rules which need to be maintained. There is, however, a next-generation set of tools that use Artificial Intelligence to ‘learn’ what ‘normal’ traffic looks like, so when something ‘unusual happens’ the system takes steps to stop it. Today this is used by security savvy organisations on their main website as well as anything temporary.
Any one of these five measures could potentially have prevented the data breach had they been implemented correctly, and avoided the fine and the ICO’s damning comments:
“… the Commissioner has considered whether the university failed to take reasonable steps to prevent the contravention. Again, she is satisfied that this condition is met.
“Reasonable steps in these circumstances would have included being aware of the microsite either in 2004 or in the intervening period; identifying the possible risks to its wider network and underlying systems; ensuring that the microsite was otherwise made secure; and ensuring that appropriate testing and monitoring was in place.
“The university did not take these steps. The Commissioner considers there to be no good reason for the failure.”
But not everyone should feel too smug. Greenwich aren't the only ones at threat of SQL Injection attacks. Many other organisations – especially those with legacy technology or log-in portals - still have similar vulnerabilities, and should take urgent advice about the challenge on their own hands.
Rob Savage is the Chief Technology Officer with the infosecurity specialists, Avatu. He can be contacted on firstname.lastname@example.org or 01296 621121.