Short explanation of Talk Talk hack

Talk Talk were idiots.

38 thoughts on “Short explanation of Talk Talk hack”

  1. This is the first I’d heard of the Talk Talk hack (or Talk Talk itself), but I know a thing or two about SQL, and…
    … well, I’m refusing to look up any more, because I want to believe that Talk Talk is a company started by a hobbyist in his spare time that ended up popular beyond his wildest dreams. That’s the only way they could justify being vulnerable to a SQL Injection attack.

  2. Sad But Mad Lad,

    I read this

    “Experts said it was conducted by a denial of service (DDoS) attack.

    Tim Smith, partner and head of technology, media and telecoms at the insurance law firm BLM, said: “These types of attacks are becoming increasingly common in the UK and it is not at all unusual to find that hackers use an initial DDoS to distract a business’s IT team and then follow up with a second attack trying to steal information. “

    and unless he can explain that, it’s some weird bullshit to me. And Tim Smith is a lawyer, not a software consultant. If there’s a SQL Injection hole, you don’t need to distract the IT team. It’s just there. And SQL Injection is the most common way to do it because every other way to try and reach the data is really, really hard. Most company’s database servers aren’t on any public network. At best, you’d need to know the IP address of the VPN, then have a VPN login, then have know the address of the SQL server, and then know the login to it.

    Nearly all big hacks are about sloppy practice – not blocking SQL Injection, not blocking XSS, allowing users to change account numbers in query strings, not patching servers. I’ve yet to hear of a data leak where say, someone found a hole in IIS or Apache and exploited it.

  3. Bloke no Longer in Austria

    I simply refuse to believe that TalkTalk were hacked in this way.
    To allow direct SQL request from a website to a DB containing sensitive data is negligence of a criminal nature. It really is the sort of thing that someone knocking up a quick look-up page for a blog might do, but not a commercial site… surely ?

    My late missus used to write transaction processing software which was designed to channel DB requests so that the normal user never managed a glimpse of the database itself. She started on that over 30 years ago and although it has become ever more sophisticated, the principles have remained the same. It really isn’t difficult or even necessarily expensive.
    In my next post, I’ll tell you how thingsl ike this happen…

  4. CayleyGraph,

    “well, I’m refusing to look up any more, because I want to believe that Talk Talk is a company started by a hobbyist in his spare time that ended up popular beyond his wildest dreams. That’s the only way they could justify being vulnerable to a SQL Injection attack.”

    That doesn’t justify it, because this is no longer the internet of the late 90s where people weren’t aware of this problem and were running tiny websites that weren’t worth hacking.

    I was protecting against SQL Injection around 2004-5. If you’re running something as big as Talk Talk, someone in your IT function should be looking at code and flagging up that there’s SQL being strung together. You should have an external penetration testing team that is hitting all your requests with SQL injection attacks.

  5. BnLiA has it probably right. Not idiots but outstandingly negligent. Criminally so? Possibly. Not having the sort of data that was extracted both unencrypted and directly accessible from the net is a nono on page 1 of Data Security 101.

  6. Bloke no Longer in Austria

    I am a customer of Austria Telekom.
    I use their mail and web service bundled in with my business broadband in Vienna.
    A few years ago, I put up a simple HTML website, which one pal described as “looking like a set of shelves, built by a bloke only because his wife kept on nagging him about it.”

    Despite there being very few hits, I always checked the log files to see what sort of spread of viewers I had. 95% were robots, many from China and India.

    A couple of months ago, I noticed an ASP file had been accessed from the site. Impossible: all the files were HTML or JPEGs, I logged onto the FTP site and sure enough, there were 3 alien ASP files on my file system. I deleted them and changed the password.

    These files reappeared a few hours later. Cheek. So I wrote a little FTP script which logged on every quarter hour or so and deleted any ASP files it found.

    I complained to Austria Telekom about this security breach. Their response was “Ah well, you can migrate to a Linux platform or as we see that you use ASP [!] you can use our new Windows platforms.”
    I said to them,
    “My website is actually unimportant, I’d much rather that you fixed the problem. There is someone wandering around your IIS servers and it looks like Chinese hackers, uploading dodgy executables. This is simply unforgiveably bad security practice.”

    So I gave them the IP address of the invader and sent them a copy of the files that I had downloaded in between deletions.

    After a few more complaints answered with “You can always migrate…” I finally received an exasperated e-mail from one of the customer service agents.

    Basically these IIS servers were obsolete and so Austria Telekom didn’t maintain them any more.

    I told them to delete the DNS entry so that no one could get to my site.

  7. BnLiA,

    OK, here’s a possible way this can happen:

    1. You have a system built in the early 2000s when such practices weren’t really known.
    2. You have leadership of the company that doesn’t really get computers or how critical they are to their business and thinks they can outsource IT like they outsource business cards (you can outsource IT, but you do need a load of QA).
    3. They hand the whole thing to one of the big consultancies who use the cheapest staff they can get away with and who either don’t know or don’t care when they spot a strung SQL statement in the existing code.

  8. Most customer service reps for online retail sites cannot see full credit card or bank account numbers. Something went badly wrong.

  9. Most customer service reps for online retail sites cannot see full credit card or bank account numbers.

    But the account numbers are still in the databases – so if you make a more expansive SQL query through the SQL injection hole than the legit customer service application does (or don’t do the application layer data masking that the legitimate app does), then you get the full number.

  10. Bloke in North Dorset

    “I want to believe that Talk Talk is a company started by a hobbyist”

    SQL injection was one of the first things that this self taught hobbyists learned about. You can hardly as a question or read a book/web page on SQL without the issue being raised.

    I see that TT is also recommending changing passwords, does this mean that they were storing them in plain language? Now that would be criminal.

  11. SE,

    Not necessarily. It might be that the bank account stuff is on another database in another server behind a web service. You get a lot of that in big companies, as much as anything because it’s then the interface between different suppliers (so you hire some website people for the website bit and some payment/card specialists for other bits).

    I am a bit surprised that 24 hours after the attack, Dido Harding didn’t know what was at risk. You tell your head of IT, he calls in all the managers and software architects and you figure it out in a few hours.

  12. Bloke no Longer in Austria

    “I am a bit surprised that 24 hours after the attack, Dido Harding didn’t know what was at risk”

    She probably has been told, she just doesn’t understand it.

  13. Tim A, I worked for a big consultancy, very unpopular among SJWs as they would insist on passing dead people as fit for work, and I can confirm that they take security very seriously – they always use accredited security spods on their teams, so I would be extremely shocked if it turns out they were involved.

    Do we know which IT company was responsible? Or was it all in-house?

  14. @Bloke in North Dorset: “I see that TT is also recommending changing passwords, does this mean that they were storing them in plain language? Now that would be criminal.”

    Could be, but most likely not for that would be even closer to criminal negligence than missing some SQL injection loophole in an unused, but still-accessible corner of your website.

    More like, they stored the passwords as hashes, but neglected to salt them adequately. That means that anybody who got the password hashes and has a couple quid to spend on Amazon computer servers, may be able to recover a lot of the passwords.

    Never, ever use the same password for two different services (unless it is one of those deals where you don’t give a damn if somebody breaks into your accounts).

  15. First and foremost Talk Talk’s customer service reputation is zilch, its discombobulated business model is second to erm….. lower than dirt and even Voda.
    That Talk Talk have been compromised twice in recent times and the fact that they have a mutual history with that other bastion of protecting customer billing details namely ‘Carphone Warehouse’ – tells you all that you need to know about Talk Talk.

    There is another possibility, that, a pissed off former employee illegally purloined some account details and or passed on info/access details to whosoever was paying top dollar.

    It is sad to reflect that, so many businesses such as Talk Talk seem to rely heavily on dubious practice and where probity and trustworthiness is concerned: they hardly have a glowing name. Lying to all and anyone becomes thus a second nature and is possibly encouraged by senior management – a fucking boys club in other words, much like the investment arms of our ‘ace’ honest as the day is long banking sector. When making money is the be all and end all, IT security is the last thing on the lads minds.
    Moreover, and of course here, I am merely speculating but I put it that, would it not be far better to make angry customers and the wider public believe that, this latest dereliction and egregious IT blunder causing the release and too many breaches of personal information – was from some exterior assault, malcontent. Better surely, than to admit that it was an inside job, if you know what I mean.

  16. (you can outsource IT, but you do need a load of QA).

    Ah yes, but you can outsource the QA as well.

    No, seriously, they do, I’ve seen it, and it is priceless.

  17. Bloke in Costa Rica

    If you just run everything you get back from a web form though a string escape function then you put the kibosh on SQL injections. It really is as simple as that. Of course in practise you perform a lot more verification and validation than that, but if you’re too idle to do even the bare minimum then you only have yourself to blame.

  18. BnLiA has got the basic point. Systems are only as good as the weakest link – designer/maintenance engineer/server/inputter of data. 50 years ago I was a trainee programmer, forty years ago I was responsible for theinterface between Investment department and the firm’s IT department (I was never allowed into the ITdepartment because I would have torn it to pieces – eight months as a pre-university trainee taught me so much more than the idiots in charge knew that I should have embarrassed the people who appointed them as well as said idiots) and I could have done a Nick Leeson if I had been crooked because I had to sort out all the computer errors due to incompetent typists in IT department – on one occasion I got so fed up that I rang up to complain about a really bad mess and she referred me to her boss who ‘phoned trying to bully me (demonstrating his ignorance) and said “do you expect them to look at what they are typing?” and got the automatic, unthinking reply “Yes!”. He then made a formal complaint to my boss for that one-word answer: I shed no tears when he got sacked a couple of years later for unrelated incompetence.
    Hence I never put any sensitive stuff on the cloud, I refuse to have internet banking etc.
    The CEO of TalkTalk DID NOT KNOW whether customers’ sensitive financial data was encrypted – maybe she did not know that she is, under English law, personally responsible for the losses that said customers may suffer as a direct consequence of the failure of those under her control? I really hope that she is bankrupted because that might encourage other CEOs to talk their responsibilities seriously.

  19. @John77 “The CEO of TalkTalk DID NOT KNOW whether customers’ sensitive financial data was encrypted – maybe she did not know that she is, under English law, personally responsible for the losses that said customers may suffer as a direct consequence of the failure of those under her control?”

    Could you expand on this? What law? Has it ever been enforced?

  20. I have a question for our resident nerds.

    If TT’s 4M customers all go to their banks and request new credit and debit cards, that’s going to cost the banks a lot of money. Can they sue TT?

  21. Bloke in Costa Rica,

    I just use Entity Framework, the .net ORM which means you not only can work with domain-specific objects (which makes code nicer) but also sanitizes everything going to the database automatically. If I do that, there’s no way I can forget to include sanitisation 😉

  22. Bloke in Costa Rica

    Right now I’m using Node, and the DB module makes me write prepared statements, so I can’t forget either. But I was wrapping all my DB stuff in sanitisers back when I was using PHP 3 and MySQL 3.23 at the turn of the century. Talk Talk’s developers should be shot.

  23. That doesn’t mean they aren’t stored. If you’re regularly requesting payments you have to have the full card number somewhere to do so.

    But you don’t do it on a customer-facing webserver. On the systems I work with, the customer’s credit card number is shipped to another server, and stored on the front end only as long as it has to be for the system to work.

    They’re also implemented as a special CreditCard type in the code, to ensure no-one can do something stupid, like write them out to a debug log file. Try it, and it just comes out as a string of zeros.

  24. “But you don’t do it on a customer-facing webserver. On the systems I work with, the customer’s credit card number is shipped to another server, and stored on the front end only as long as it has to be for the system to work.”

    Don’t the PCI regulations mandate this kind of approach?

  25. Not just TalkTalk.
    Friday, I got an invoice e-mail* from a Scottish waterco. ( I’m with Southern, & S.East, but UK waterco’s are a mystery to me. I have to have two!?!?) Anti-virus program no-no’d the attachment.
    But the “from” date on the invoice was exactly the same as the “from” date on the invoice I’m expecting.

    ???

    The Scottish waterco are carrying a warning on their phone helpline. But neither of the English one’s were the slightest bit interested.

    *And I use a paid-for e-mail provider on a domain name. To mail me, you have to know the address. Not random attack free-mail addresses. What else has been lifted?

  26. Tim Almond makes a couple of good points re the red herring of DDoS and the likely separation of front and back-end DBs. The second of these is an organisational issue as much as architectural, i.e. the likelihood that the front-end data-capture has been outsourced to a contractor whose strength is Web not data or security.

    Another organisational dimension is that Talk Talk have grown as a business through acquisitions, over 6 in a decade. As anyone who has experienced this will know, it takes a couple of years to fully work through all system integration issues for a single merger, and that assumes you have full C-suite backing for the necessary expenditure and procedural reorg. Talk Talk bear the hallmarks of a business struggling to absorb change.

    One of the most obvious signs of this tends to be clinging to legacy systems – i.e. focus on gaps that need to be plugged and shore up what already works. Combine this with a front-end that may have been bought as a “black box”, and you have a recipe for risk.

  27. Tim,

    > If you’re regularly requesting payments you have to have the full card number somewhere to do so.

    Which, in this day and age, is ridiculous. You don’t need to store a password in order to allow someone to log in with it. The same principle should be applied to credit card numbers. Banks should accept hashes of the numbers.

    SSAE,

    > Never, ever use the same password for two different services

    It’s so bloody easy, as well. Come up with one unique password and then one or two simple rules along the lines of “4th and 6th letters of the company’s name” or “number of letters in the URL minus 5”. Different password for every site and piece of piss to remember. Why don’t people do this?

Leave a Reply

Your email address will not be published. Required fields are marked *