This article originally appeared on Alan Solomon’s personal blog.
TalkTalk has announced that they’ve been hacked. The details of four million customers are in play.
The big question that they’re being asked is, “Was the data encrypted?” The answer, currently, is “I don’t know”.
This is, of course, a silly question. And a silly answer.
Data encryption is, in this case irrelevant.
Standard practice, is to store sensitive data on an encrypted file system. That way, if the computer is physically stolen, the data is safe. This is great for the “laptop left in a train” scenario, but a database with the details of 4,000,000 customers won’t be a laptop. It’s also great in a “burglars ram-raid the datacenter” scenario, because although they’ve stolen the hardware, they can’t access the data.
But in a scenario of “authorised user accessing the data”, the encrypted data will be decrypted and supplied, because the authorised user gave the correct decryption key.
So, let’s imagine a big company, with the sensitive details of 4,000,000 customers stored on a server. That data is there because it gets used. For billing, for marketing, for tech support. But it’s encrypted, so only authorised users can access it.
Now let’s imagine a wily hacker, who uses an SQL injection vulnerability, or a PHP vulnerability, or a WordPress vulnerability, or any one of a zillion other vulnerabilities, to get root priviledge, and is now logged on as the root user.
He can now log on as any user on that computer, and because he’s an authorised user, he has all the access to the sensitive database that the kosher user has.
That’s why “Is it encrypted” is a silly question. Because it actually doesn’t matter in the hacking scenario we’re looking at here.
And that’s why “I don’t know” is a silly answer, because the correct answer is “Of course it is, do you think we’re idiots? But the fact that it’s encrypted, doesn’t stop the hacker from accessing (and copying) it, because, see above.”
Aren’t there any people who understand about computer security in the media? Or in Talktalk?
Found this article interesting? Follow Graham Cluley on Twitter or Mastodon to read more of the exclusive content we post.
27 comments on “TalkTalk was hacked. But it’s silly to ask if the data was encrypted”
This seems like an oversimplification. Sure, it's likely that the system design was imperfect and the data was at risk. However, that's not guaranteed and so it's not a silly question.
Good security segments access control and uses data brokering to mitigate risk. Consider a system design where computer a has the encrypted data, computer b has the means to get the encrypted data from computer a, and computer c knows how to ask computer b for the data and how to decrypt it.
With this design, a compromise of computers a or b doesn't put data at risk as long as the encryption holds up. A compromise of computer c does put data at risk. However, in this case, the data broker on computer b should be able to detect a suspicious pattern of requests from compromised computer c. The question then becomes, how much data was accessed before computer b figured out computer c was hacked and shut down access?
There is also the consideration that all stored passwords should be hashed and encrypted and never unencrypted. When a client logs in their entered password is hashed and encrypted and compared to the stored value. Any system that stores passwords in a recoverable format is asking for trouble.
As for credit card info, merchant services allow profiles to be configured and re-used so that credit card numbers do not need to be stored anywhere. Pretty sure most merchant service companies would drop clients doing this due to liability if it was discovered.
Bottom line, the tools are out there to secure or at least minimize the damage of a security breach. A company this size should know better.
Hmm … "Of course it is, do you think we're idiots"…. Seems Alan has a gap in understanding of current enterprise practices…..
In an interview with the Sunday Times, Harding said that her company was under no "legal obligation" to encrypt sensitive customer data, such as bank account details.
"It wasn't encrypted, nor are you legally required to encrypt it," she told the newspaper. "We have complied with all of our legal obligations in terms of storing of financial information."
You can steal the contents of database tables (such as through SQL injection attacks) – but if that data is encrypted you don't necessarily have the ability to decrypt it. In those situations you don't necessarily get the same access of a root user – you often are supplied with raw data that you shouldn't have access to.
There are too many details to go into as to how encryption can be implemented and how that data may be able to be decrypted (e.g. with a key that is part of an application that the hackers don't have), or in the case of passwords you may still need the original password to match to the encrypted data (one-way encryption).
It's a perfectly sensible question to ask whether data stolen through a SQL injection attack was encrypted. If it was then that's still a bad situation – but if it was suitably encrypted then it makes using that data much more difficult.
This post seems to mix up encryption with authorisation. Encryption is often there so that data can never be directly seen, regardless of the authorisation of the user trying to access it.
'You can steal the contents of database tables (such as through SQL injection attacks)…'
Maybe they stole more than the database tables? He did indeed suggest more than this. This means you must question what type of data is taken, as well as how determined and resourceful the attacker is (presume they are incredibly determined and resourceful).
'This post seems to mix up encryption with authorisation.'
Not really. What part of salted+hashed passwords for authentication doesn't involve encryption? Yes, it is an example but for authentication it usually IS a password.
'Encryption is often there so that data can never be directly seen, regardless of the authorisation of the user trying to access it.'
Define 'seen' or 'access': Have you ever done any programming with salted+hashed passwords being used for authorisation? If you have, you would understand that the original password can be determined – even if indirectly (you don't even need to have done this type of programming, though). Then there are brute force attacks. You might say what if we're not talking about passwords. Okay, you would have a point to an extent.
Bottom line: the data in question is what matters and assuming they only have the most limited data set is asking for trouble (do they? they might – but they might not). Assuming also that the attacker doesn't have the resources or determination, is asking for more trouble (the fact they went so far already is a good reason to think they do have these things). The impossible can – and do – become possible.
The thing I think the Doctor is trying to get across is that encryption only goes so far, and depending on the determination of the attacker, it may very well not be enough. It's been known to happen this way and it is why it is always a many-layered thing. Put another way, does the attacker truly care more than gaining access to the data? The answer is obviously 'no'. With this you can probably determine exactly how determined and resourceful they are (they already got the data, you see).
The question shouldn't be CAN they but WHEN will they ? Whether it happens or not isn't the point.
I call bullcrap on most of this premise. If the nsa can't decrypt aes256 neither can anyone else in this scenario. Pure and simple. If you leave a key laying around then what do you expect. Talk talk is wrong and its customers should vote with their wallets.
If I encrypt my database you can steal it and do whatever you like but you won't be reading any of it into plain text fields. Encryption always works. So does leaving the key around.
This is, unfortunately a bit of an oversimplification.
Alan seems to be inferring at full disk encryption, or potentially database encryption itself. Both of these approaches would be moot if the hacker were connecting to carry out an injection attack.
However, if it was encrypted at a data level, all they would have got is garbage; however, this sort of protection is really uncommon for this level of data – as the server is supposed to be secured (and why can a single request return so much bulk data? Surely that is a good WTF for a secure storage).
While PCI does not mandate encryption on the “de-sensitised” information – such as PAN’s with numbers replaced with X’s, I would have thought the fact there is a bulk of Personally Identifiable Information (PII) meant that Talk Talk were under requirement to provide good due practice protection of this data (both by design and implementation), and this does not sound like it has been followed.
Utilizing a security platform that not only selectively encrypts sensitive data fields, but also features user behavioral analysis to determine regular users from nefarious ones based on their login location, device fingerprint, measuring their activity within the system against their typical behavior and that of their peers, etc – and then deploys defensive countermeasures when something is awry may stop such an attack in its tracks, or at the very least minimize losses and provide an audit trail of how the hackers got in and what was accessed.
Disk and file system encryption methods are only useful in securing against media theft and irrelevant to cyber security, so the premise of this article is based on rather confused thinking, unfortunately.
Sorry but this is rubbish…. the attackers used SQL injection which is one of the easiest tricks in the book so they didn't have root access like you've said. They would still need to decrypt much of the data if it even WAS encrypted in the first place, so no it's not a stupid question EVER. Companies should NEVER store details like this in plain text end of. If you do you should be fined heavily.
But it wasn't even encrypted, as Anonymous states above (Anonymous October 25, 2015 at 4:14 pm). If the trick was as simple as re-stating the URL with a " or 7>(3+2)" at the end, then Talk Talk ought to be publicly flogged! ;-)
Encryption is enough if done correctly.
For example: the user's password can be used to encrypt the data (with salting) to allow them to see the information in realtime only.
The same data can be encrypted using a "private key" on the web server and the encrypted data securely shipped (physical media once a day) to another non-internet server (with direct connectinos to banks only) that holds the public key.
The problem is security is usually a tick box exercise: ICO recommends encryption, so let's just add encryption. Security has to be designed, not just installed.
This unfortunately is result of pricing a service without an overhead, TalkTalk simply cannot afford to create proper data storage safety nets. and neither can the competing clowns, so its only a matter of time before it comes to pass that somebody else announces, that somebody has been poking around in their systems and they don't know for how long or what they've been doing.
Data security costs big money on large enterprise.
I'm with TalkTalk and am wondering that if I move from them to another internet provider would I end up with that internet provider being hacked.
Also wonder that if a hacker hacks into a system and don't let themselves be found, just watches and waits, could that happen?
Can hackers copy data and not be noticed?
Security is only as good as its weakest link, which of course needs to be intelligently and robustly challenged at every point, because a failure can wreak so much havoc on such large groups of people and threaten the future of the company.
I do wonder though if we might not feel some empathy for Dido Harding who particularly made a point of very visibly owning up to the attacks and accepting responsibility on behalf of the company, when the security industry knows most businesses hide away and leave their customers even more at risk?
It's probably a good question still…
What is encrypted where?
1) Yes the media may be encrypted. The O/S decrypts and sends the clear data to the server side software application for use. If you just steal the media from the storage device you can't get to the data without a lot of effort to decrypt it. If you steal all the 'tin' you can then take as much time as you like to hack the software and locate the keys to decrypt the media.
2) The data may be encrypted on top of the media encryption. Additional DB or application level encryption may be applied to the data before sending it for storage where it will be encrypted again by the O/S. Why don't companies like to do this for all the data? It makes DB searching very hard since you can only really (complicated…) search against the non-encrypted data. So you might encrypt the finance details since you probably only want to search and retrieve the data by Surname or Talk-Talk-Account-ID, etc.
Who care's about (1)? No one since the 'tin' wasn't stolen. But what about (2)? I think Talk Talk are saying that they didn't do any of (2) – not even for the financial data.
SQL Injection and similar hacks. Well, a simple injection should be able to recover some of the data even if (2) was done since the website application needs the data in clear and back end will simply run the SQL assuming the data has been legitimately requested. There are simple ways to protect against this sort of hack including analysing and filtering the SQL calls in a layer in front of the DB to remove requests that look malicious. You can also use the concept of Stored Procedures to make it very hard for the injection to take any real volume of data (i.e. a single row of customer data but not the entire customer table). This is just good coding practise. Was any of this done at Talk Talk?
Talk Talk fixed the 'hole' very quickly so I would suspect this might be less down to coding standards and more likely down to human error. For example someone might have left root access to the DB open for a server account that was easy to hack into, etc. An easy thing to fix quickly.
I hope this helps!
Few things everyone should be aware of.
1. Encryption alone (disk or database e.g. TDE) will not solve the issue.
2. Old school boy error on why SQL injection vulnerabilities are not fixed by doing scheduled pen testing
3. Separation of duties (root level/ admin to DBA) and using simple tools eTrust (formally SeOS which all unix and linux admin are familiar with)
Perhaps they should have 2 methods of authentication, 1 password and 1 physical so you have to be on site to gain access to the encrypted data.
Seems no matter what products you're using, mitigation strategies and defence systems are in-place, if you're target of interest, be it politically, financially, or simply a p1ssing contest amongst hackers, black hatters are likely to find the weakest link to break through.
One article referred to TT's "security partner". We all know that security is not simple and many large companies outsource the management of their security. This security partner should be named and shamed since it is likely they will have other customers and if they have not done what they are paid to do by TT then what confidence can the other customers have? Security is now so complex that even large companies have difficulty in building and maintaining a competent security team. Security is the CIO's worst nightmare.
I would say "protected" rather than "encrypted" – most solutions that are effective against arbitrary code execution on the webserver (tokenization, hashing, application firewalling) require that the DB be on another physical system, and aren't (other than very vaguely) encryption.
There are some things some people are missing. This includes responding to this bit:
'Now let's imagine a wily hacker, who uses an SQL injection vulnerability, or a PHP vulnerability, or a WordPress vulnerability, or any one of a zillion other vulnerabilities, to get root priviledge, and is now logged on as the root user.'
The assumption is the only attack was against the database. Some have said they won't have root access. But they could have done more (or maybe they gained access to the database after rooting the server). Did they? Whether the administrators did one thing or another isn't the (most important) question to be asked; you should ask what the attacker accessed (also whether they still have access) and what should the administrators be looking for (and what they can do to make things better for next time). Just because something is claimed (or isn't) doesn't make those things true or false. That's why science requires evidence, testing and so on. Assuming that they only compromised a database is a dangerous thing (even if the attacker claims that's all they did). It goes the other way, too.
On the other hand, if they didn't encrypt it, it does raise other concerns. But even if they did encrypt it, the attacker already has the upper hand, and with the right computer power and the right resources (which you should presume they have), they could go further than that. Whether they do or don't is besides the point (whether the attacker has root in this case or other cases, is also besides the point; that they could is what matters). And even if it was 100% impossible (but see next part) this time, it doesn't mean it always will be. Maybe Alan isn't meaning this but the thing to keep in mind is that you should never assume something is completely safe from attackers. The impossible has become possible and this will continue to happen (this also goes for things unrelated to computers/networking).
"Do you think we're idiots?"
The hacker gained access via SQL Injection – so yes, yes I do.
This is not true. Even if you are a root 'Admin' you still have to decrypt the data and this requires a password or a pass phrase. Password files are also encrypted. I use PGP and even as root would still need to provide the passphrase to unencrypt my encrypted confidential files.
This is how a modern, well organised e-commerce environment works:
Front end: dedicated firewalls and load balancers
Middle: Web servers with redirectors and serving static content
Middle: App servers (e.g. J2EE).
Back end: Firewall protected, clustered database servers (e.g. Oracle)
Login information entered by a HTTP client hitting the web server must ultimately be compared with information held in the database. So the app servers are authenticated AUTOMATICALLY by the database server using hash keys stored in protected files. It doesn't matter what's encrypted anywhere in terms of SQLi. SQLi are malformed statements allowed through to the database servers by LAZY programmers. SQL statements should be checked BEFORE being relayed to the database to check for metacharacters (line an asterick). LAZY programmers are employed by LAZY managers. What happened at TalkTalk was poor management incapable of understanding e-commerce security. Look at the board: only one executive director with tech knowledge, a CTO with NO security experience.
This is the same old British disease we've always had – LAZY managers with both eyes on the bottom line. Baroness Harding should go. She earnt seven million pounds last year and at that price she has to take responsibility. For that kind of money TalkTalk could have hired a few security experts to sort out their problems. The 3rd hack in a year as well!
It has been most interesting reading the different takes on protecting data. That so many presumably knowledgeable people differ so in their opinions shows what a difficult subject data protection is. Small wonder that those who try to regulate commerce are effectively incompetent to carry out their responsibilities and rely on bluff and bluster to conceal their shortcomings and their uselessness.
One final point to note. The Data Protection Act requires that a company merely takes "reasonable steps" to ensure the security of a user's data. "Reasonable steps" – what the heck does that really mean? If the resultant public enquiry achieves anything, it must change that wording. Make companies that get hacked because of poor internet security liable for any subsequent fraud or identity theft that takes place and additionally the authorities must pile on excessive fines. Make companies like TalkTalk take internet security as seriously as they do making a profit. Accountants run companies, not security experts. It's the only way.