Talk Talk hacked

[Phanerothyme 12]

So all that's needed is a tightening up of the software. It must be more secure than needing to input a few letters from a word to confirm online identification.

 

You'd think with over 10 years in hand, it would have been "fixed", but it seems to be more of a hardware issue - namely enabling the hardware to distinguish between living fingers and gelatine ones is not cost effective. Yet.

[yorky15 10]

it would appear that a 15year old from Ireland has been arrested re this!

[999tigger 10]

it would appear that a 15year old from Ireland has been arrested re this!

 

15 years old how embarrassing for TT.

[andyofborg 11]

Having read more about the attack, encryption would not have helped one bit.

 

errr yes because then they would have got encrypted data which would have been useless unless they were willing to go to the trouble and expense of trying to decrypt it

 

---------- Post added 26-10-2015 at 19:32 ----------

 

enabling the hardware to distinguish between living fingers and gelatine ones is not cost effective. Yet.

 

when you think about it there isn't a great deal of difference between them

[tzijlstra 11]

15 years old how embarrassing for TT.

 

Not really, a lot of subversive hackers are under-age, working from dark dinghy attic rooms without their parents ever knowing what they are up to. Once they hit an age where they have to work to earn money they tend to slowly drop it over time (although of course a lot of them end up working as... security experts in IT.)

[999tigger 10]

Not really, a lot of subversive hackers are under-age, working from dark dinghy attic rooms without their parents ever knowing what they are up to. Once they hit an age where they have to work to earn money they tend to slowly drop it over time (although of course a lot of them end up working as... security experts in IT.)

 

We will see when we find out the details of how he did it (if he did it). The fact your system isnt secure enough to keep out a single 15 year old imo is embarrassing. It wont surprise me if they have been negligent and complacent in the way they have secured their data, which will do further damage to an already battered reputation.

[sgtkate 10]

errr yes because then they would have got encrypted data which would have been useless unless they were willing to go to the trouble and expense of trying to decrypt it

 

---------- Post added 26-10-2015 at 19:32 ----------

 

 

when you think about it there isn't a great deal of difference between them

 

Another one...The application must have access to the unencrypted data, yes? Otherwise how would it work? So if you get access to the application and the application security is poor then you can get full access to the unencrypted data. As the hack has been said to be SQL injection, whereby someone uses an input text box normally on a website to run commands directly against the DB, they can perfectly easily run a 'select all your customer data' which would be returned in clear, non-encrypted text to the application as the application is allowed to request this!

 

Honestly, this is my job. I do this stuff nearly every day, and have already been advising parts of my own company how they can utilise tools and better application coding to stop this kind of attack. For the final time, encryption here WOULD NOT HAVE HELPED, however it does protect from other types of attack and I recommend it greatly where appropriate.

 

---------- Post added 27-10-2015 at 12:01 ----------

 

We will see when we find out the details of how he did it (if he did it). The fact your system isnt secure enough to keep out a single 15 year old imo is embarrassing. It wont surprise me if they have been negligent and complacent in the way they have secured their data, which will do further damage to an already battered reputation.

 

SQL injection. They already know how he did it. You go to a website with an input box. You type something like "sgtkate or 1=1". If the application hasn't been coded to watch for this and to refuse it, that command "can" get sent directly to the database, because the underlining website code will be something like 'select username, password from customerdetails where username='text you entered'; 1=1 is always true so it would return EVERY SINGLE row from that table, unecrypted. This is the most basic SQL injection attack and if TalkTalk got hit with something this simple then I suspect their dev team will be looking for new jobs.

 

Seriously this is all getting highly geeky. If anyone is actually interested let me know and I'll continue my lesson

Edited October 27, 2015 by sgtkate

[AlexAtkin 10]

The sad part is that TalkTalk have done incredible damage to themselves by not announcing the type of attack it was sooner.

 

All this speculation that they had been hacked and gotten bank details and credit cards. When in fact it seems they had at least followed the basic practice of having bank detail obscured when read back from the customer facing side, making this is a lot less serious than first implied.

[sgtkate 10]

The sad part is that TalkTalk have done incredible damage to themselves by not announcing the type of attack it was sooner.

 

All this speculation that they had been hacked and gotten bank details and credit cards. When in fact it seems they had at least followed the basic practice of having bank detail obscured when read back from the customer facing side, making this is a lot less serious than first implied.

 

Yes, that's potentially correct, but again it will depend on what the application asks for and is offered. It's not hard at all to stop this kind of attack with just some basic common coding rules.

[Phanerothyme 12]

One line of code will prevent an SQL injection attack on a LAMP stack web application -

 

If the TT website didn't sanitize its inputs, it's a case of incompetence and negligence, not misfortune.

[sgtkate 10]

One line of code will prevent an SQL injection attack on a LAMP stack web application -

 

If the TT website didn't sanitize its inputs, it's a case of incompetence and negligence, not misfortune.

 

This^

 

Stop blaming the databases everyone!

[Obelix 11]

Yes, that's potentially correct, but again it will depend on what the application asks for and is offered. It's not hard at all to stop this kind of attack with just some basic common coding rules.

 

SQL injection attacks are so old hat that it should be ingrained into everyones skull who works in the field, it's not something people should have to apply coding rules to. They should just assume its going to be attacked this way - it's like when you leave the house you lock the door it should be automatic...

 

If TT fell for this one, I'd be going utterly mental at them - especially since they have said that people are not going to be allowed to leave. I'd have though promising to keep data secure and then not doing so is a clear breach of contract myself.