Teletext Holidays a) exists and b) left 200k customer call recordings exposed in S3 bucket Teletext Holidays managed to leave more than 200,000 customer phone call recordings exposed on an unsecured AWS server, according to reports. A total of 532,000 files were exposed on AWS servers belonging to Truly Travel, the company that trades as Teletext Holidays, of which 212,000 were recordings of live news. Verdict, the …
You still make it sound like S3 buckets are inherently insecure, and companies need to do something to secure them.
This is NOT the case, by default an S3 bucket is set up with no access, and users have to actively turn off security to make them publicly accessible.
I'm quite sure that most of the time, what happens is a DevOps developer sticks some data in a bucket, finds he/she can't access it externally, and so turns off security because it's getting in the way, instead of talking to someone with a clue and arranging access in a secure manner.
I'm quite sure that most of the time, what happens is a DevOps developer sticks some data in a bucket, finds he/she can't access it externally, and so turns off security because it's getting in the way, instead of talking to someone with a clue and arranging access in a secure manner.
You can delete the DevOps reference, clueless idiots were doing this sort of thing from the start. I can remember a web developer in the mid 90s deciding to spray 777 permissions all over a world facing Unix server(*) because he was too stupid to work out what he actually needed to do. When I gave him a bollocking for it(**) he promptly complained to management that I was harassing him.
(*) The bits he had access to. He wasn't in wheel group like he wanted because at least I managed to persuade management that was a step too far.
(**) I was a syadmin. All the responsibility, none of the power.
I'm quite sure that most of the time, what happens is a DevOps developer sticks some data in a bucket
You need better devops.... all the ones I know would never let this kind of stuff slide.... (Lazy developers however; or clueless managers with time pressures are another thing...)
"Since this keeps happening, it makes me wonder whether perhaps something about the process could be improved, so that users are less likely to turn off rather too much of the security?"
Or, many of the practices that organisations use fall far short of best practice. The existing business process was "turn off anything security related until it works, or just assume it doesn't work until security services are disabled", and the same policy is being applied to the cloud.
i.e host firewalls are generally disabled rather than enabled with relatively simple, open policies for internal networks. Or not installing endpoint protection on servers because it might affect something. Or being years behind in security patching in case something breaks. These are just the examples that quickly spring to mind, there are a lot more to add - while there may be valid reasons for some exceptions to security policies, but the exceptions are generally for more broad than they should be.
A lot of organisations seem to think the cloud is magically secure - it isn't, its just setup to provide many of the services that you wish you could provide with on-prem facilities at either a fraction of the price (logging/storage/DDoS) or with greater resilience/redundancy/flexibility/scalability to allow you to avoid some of the traps with on-premise environments.
If you deploy services to the cloud and follow the same steps (no host hardening, disabling security features, ignoring logging/alerting requirements, bypassing RBAC by giving accounts all roles, deploying services with differing security needs on shared hosts etc) you are likely to see similar results.The only thing that the cloud has really provided is more bandwidth/resources for attackers to do things (i.e. dump your S3 buckets) faster with minimal impact on your services.
TL;DR: this requires an organisational culture change regarding security rather than process changes at cloud providers. While automated best practice wizards and checks may help some, the majority of the organisations will ignore them.
Mines the half empty pint. Not just that, the heat is making it evaporate too...
The thing is, if you have a file server on your local network, you can open it up to everyone if you want everyone to be able to write to it, and rely on your router to stop people from outside getting access to it. That will usually work. Often, all the staff do need to have write access to it.
Move your file server to the cloud however, than that approach most definitely will not work.
They find it a hassle to create an AWS VPN, especially when they are an agency dev and used to working directly on LAN servers, will continue to develop the app once the intial builds have been dropped and the new VPN would need to be transferred (or second one created) for the customer. WHich will then require some configuration of their firewall ... etc..
So you just assign it a public IP, open it to the public and connect to that from the application. Works from Dev, From Test, From customer and from partners (oh and from anyone else who wishes to connect to it without you knowing).
It's just lazy (non)security. Then again it is still possible to find SQL injections floating around, even from major enterprise communication companies. So it's no surprise.
Given how old this data is, I rather suspect that what's happened here is that "secured by default" is a more recent thing from Amazon and that, when this system was spun up, "knickers around ankles" was the default setting.
Amazon wouldn't have applied the new default settings to existing setups for very obvious reasons.
The first time I used AWS S3 buckets was around 2009 and they defaulted to private access at that time. As far as I'm aware, they have never defaulted to public access (i.e. based on AWS documentation) but I don't have any personal experience between launch in 2006 and testing in 2009.
I suspect the reason for the majority of the data being historical is that big breaches have meant people have stopped ignoring the warning e-mails/checked if they have open buckets.
I know the wayback machine shows companies who have closed off their S3 buckets in recent years, so i would challenge your assertion that the "knickers around the ankles" was ever a default setting unless you have some evidence.
I have a messaround/free tier AWS account to play with and see what I can do/break, mainly to test new features which seem to appear every day on AWS.
I have an unsecured S3 bucket which has a few boring text files in it, amongst other properly configured (ie not messed with) S3 buckets. I knew immediately wen I left my S3 bucket open because it warned me and changed colour. I even got an email today from AWS telling me I had an open bucket.
My point being is that it's not that hard to keep locked up, its much harder to have it open. Now all you 1337 haxx0rz out there that want to find my open S3 then go hard, you'll find a file called wank.txt and imacunt.txt. If you wish to grab them then fill your boots.
But the alerts are probably going to a generic 'aws@domain.com' account that no-one monitors. One day someone will have a look in there ("whys that mailbox got 400000 unread emails") and find all the different services that have been warning them of their insecure configuration for the last 5 years.
Insecure AWS buckets are meant to be things of the past.
Maybe this is part of the nostalgic feel of Teletext Holidays? (Though I'm Bamboozled to think AWS and Teletext could ever have overlapped.)
(Edit: some googling suggests they really did for a few years, AWS is older than I remember, and Teletext lasted much longer than I thought.)
Look up Amazon Connect… it’s a managed service that sits on top of AWS services, recordings are stored in S3, although that bucket is under the customers control, it is still fed by (and therefore open to) the Connect service…
Obviously this may not be using Amazon Connect, but it’s an example of how AWS and a random organisation could come together.
My two pennies, this won’t be the last time a telephony platform is in the news for this, Amazon Connect doesn’t wow me with some of its security approaches! Amazon Connect does permit encrypted customer input, via DTMF, not speech recognition, at least not at the moment.
Teletext is actually alive and well in most countries it had any kind of presence. For example in Germany virtually every station has some sort of Teletext offer. It's actually trivial to have Teletext via DVB and most receivers will happily support it.
New developments include "Teletwitter" where a social media person at the teletext office monitors Twitter and broadcasts the best tweets via a special subtitle page.
My telly does do something like the old teletext, but it a more modern screen resolution form.
Press text on the remote and a menu comes up where you can select pages, just like the old one except you don't have to wait for the number to cycle round. Obviously no BBC Model B program downloads now though.
I really liked teletext in its day. it was sort of like a prototype web.
You mean the so-called "digital teletext" (#) that the UK replaced the original?
Yeah, everyone seemed to hate that, and criticised its usability compared to the old system. It seems to have been almost completely forgotten about.
Ironically, the TV I bought just six weeks before PAL and Teletext transmissions were shut down made using Teletext a breeze, because it was obviously automatically caching the pages as soon as they came in, giving virtually instant access. (Even the 1 KB required per single page was a *lot* in the mid-70s, and would have remained non-trivial well into the 80s. By 2010 though, the few megabytes required to cache every page transmitted on that channel would have been trivial.)
(#) Despite the fact that the original 1970s teletext was not merely digital in the first place- regardless of whether it was piggybacked onto the analogue TV system- but probably the first widely successful digital media/service aimed directly at the consumer market.
Well those "digital teletext" services never really got off the ground. In the areas where they are used, they are mostly used for displaying additional advertisements.
However DVB allows for not only Teletext, but arbitrary VBI data. This arbitrary data is encoded as 720 monochrome samples per line. I don't know if any device supports this, but in theory it could work.
The digital teletext appeared at a time when it is competing with www. Smart tellies have browsers too.
Just having a look at it now, no adverts, but the old teletext was swamped with advertising, mostly for travel companies and package holidays, flights etc.
The cached teletext was called fasttext.
They are storing on an insecure public server and you think they might have gone through a proper PCI compliance process.
Interestingly, the fact that they are clearly not PCI compliance should see major fines from their card processing company and possible suspension of their use of Visa/Mastercard for the foreseeable future.
Not just key tones. When I called Acme Car insurance about my renewal they had to take details of my new payment card. I was asked to finish all questions about the policy before payment was taken as once we started discussing card details they paused the recording. Very sensible idea.
From the article:
"While basic security measures were implemented, in that customers were told to input card numbers using the handset"
Getting people to type the card number is absolutely not a security measure. It's easier to automatically decode those tones than going through voice recognition to pick out a 16 digit number (along with "oh sorry, that was a 7") - and that applies to both the service and the criminals.
DTMF has been around since 1962 - way before AWS.
Do they use an Oracle database?
* This joke is only comprehensible to British viewers of a certain age who remember the ITV teletext service. The wikipedia article carries the following spooky paragraph :
ORACLE began to disappear at 23:31:09 on 31 December 1992, with the outer border of pixels turning black. This process continued until 23:55:55 when only a white square was left, with the text ORACLE gone 1978-1992. It was then replaced by the service from Teletext Ltd. ORACLE did not carry television listings beyond its midnight closing time on New Year's Eve 1992. It merely stated "00:00 the end of Oracle, now the nightmare begins.".
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
