Easyjet hacked: 9 million people's data accessed plus 2,200 folks' credit card details grabbed Budget British airline Easyjet has been hacked, it has told the stock markets, admitting nine million people's details were accessed and more than 2,000 customers' credit card details stolen. Some information about the attack was released to the London Stock Exchange by the company, which claimed it had been targeted by "a …
Incompetent data controllers often claim to be victims of "highly sophisticated" attacks, despite taking security "extremely seriously".
An unkind person might suggest that many don't think much about whether a database is private / don't check incoming messages against buffer sizes / never heard of SQL injection. To them, I suppose, any attack is "highly sophisticated".
If I we're going to get 9 million peoples details in a "sophisticated hack", I'd probably do the following:
1. Start an airline called EasyJet.
2. Run a shit service for many years.
3. Appoint a board of shitty execs.
4. Walk away with the data.
This is pretty sophisticated, especially 1, running an airline that balances price with poor quality is pretty tricky because you have to be just good enough that people won't complain because the price is just right.
Which language is that?
in csh it would be:
foreach i (`seq 1 9999999`)
wget https://easyjet.com/customerPortal/creditCardDetails?customerId=$i
end
In bash it would be:
for i in {1..9999999}; do wget https://easyjet.com/customerPortal/creditCardDetails?customerId=$i; done
in powershell it would be
for ($I=0; $I -le 9999999; $I++) {wget https://easyjet.com/customerPortal/creditCardDetails?customerId=$i}
They went further and didn't claim the attack was sophisticated just that the attacker was sophisticated. That is quite some claim - do they know the attacker?
The fact that they "have now closed off the unauthorised source" makes is sound like it is totally not sophisticated at all. Either they've closed off a backdoor, a bug etc or they've removed access to a previous employee. None of which is that sophisticated.
Wasn't the TalkTalk attack originally 'highly-sophisticated' - before it was revealed it was some script kiddies playing with freely-available tools on an unsecured Tiscali database?
Still, it's not like the then-management of TalkTalk are doing anything vital these days are they?
https://www.gov.uk/government/news/new-chair-of-coronavirus-test-and-trace-programme-appointed
"on an unsecured Tiscali database"
It was worse than that wasn't it? Application and DB all on a single Internet-facing server.
The IT version of leaving going out and leaving all your house doors and windows open with a big sign saying 'Criminals Welcome' hanging outside.
Or an even simpler case of "Lets outsource the database management. It will be cheaper as the overseas support company can do it cheaper than our in-house team". To then come in one day and find the database deleted. WTF! It surely wasn't the cheaper overseas support company that did it? Oh yes, oh yes it was. The incompetent local IT manager who was the 1st line manager before somehow getting the 2nd line managers roll despite being an incompetent fuck as a 1st line manager. Who also frequently exposing HR confidential info to their mate because they'd got it from their HR buddy. But cause their mate had a big mouth we also heard it. hadn't been managing properly, so had left a support account wide open for them to come and go as they pleased with no records. So said overseas company had a rogue employee who connected in with the unattended account that should of been locked and used it to delete the database. They were caught and charged eventually but a simple rogue employee can cause all sorts of issues.
What fun.
Erm, yes.
Thumb up for the xkcd reference. Or, maybe it wasn't: in one of my former lives our password policy explained how a "good" password should be constructed and also gave an example. As part of an access security audit we checked passwords. Young and naive I was rather surprised when finding how many users used that exact example as their password.
I haven't used Easyjet until this year when we had a work trip to France. When I heard they'd been hacked I thought that's just typical of my luck. My immediate reaction was to call the bank and as I was fairly certain I'd paid on my debit card and ask them to check. Before I'd finished dialing I remembered the trip was paid for by work. Therefore the most they would have is my passport details. When I read more about it I realised unless they were really shoddy about it I'd be okay as we didn't fly until February.
The boarding at both ends was a shambles and we were delayed because of it. They took hand luggage off people who had bags they'd tagged for the hold. These people had been let into the holding area before boarding which was a scrum and then their bags were taken....... I vowed there never to use Easyjet again.
Fine, now I am angry again. TSA managed to break one of their keys in the lock of my suitcase, so they cut it open and returned it to me in a plastic bag. They made sure there is enough red tape in place to prevent people file a complaint (or, god forbid, claim damages).
Waste of oxygen, all of them.
"...it is never a good idea to store your card details on any website"
Doesn't make any difference. Either these details were slurped in real-time by a script on the transaction page or they were read from the database. Regardless of whether you "store your card details" on a website or not. They will be recorded as part of the transaction unless they are using a third party provider's system (which can also cause issues). Therefore they either need to two-way encrypt the card details and never store the CCV or never store the card details after the transaction has completed and then not have an easy way to securely do refunds. As a punter you won't know what they do with your card details after you have entered them and clicked submit.
"For refunds the common sense approach would be to only store the last 4 digits and get the customer to confirm the rest when processing the refund."
A "confirmation" is when they read you information they have and you "confirm" that it is or isn't correct. I don't play that game they call "confirming my information" as the way I see it, I am giving out sensitive information. They don't seem to understand that, but since I've already been on hold for an hour, I'll wait another to talk with the supervisor.
Doesn't make any difference.
I'm pretty sure you are correct for actual purchases. I'm unsure how the vendor could handle a chargeback or refund without having the CC number stashed with the transaction data. Likewise monthly subscriptions for services. The alternative to a stored CC for those would appear to be direct charges to your bank account. Somehow, that sounds even worse to me.
But I think the OP was referring to vendors like Amazon who allow one to use a stored credit card number so one doesn't have to type it in every time they order a box of chocolates.
I kind of wonder if it isn't about time for governments to start working on a set of explicit worldwide standards and conventions for digital commerce. Of course there might be a problem if it turns out that no set of standards and conventions that actually allows commerce and is also secure is possible.
If they're doing it properly, then the credit card numbers will be passed to a CC processor, who will return a transaction number. If they want to refund the transaction, that's what they need. The CC processor will hold that link, but there are a small number of them and they can afford to do security a lot better (and understand that they need to do it).
Likewise for repeating credit card payments, saved cards etc. done properly it will be passed to the CC processor who will return a token. That token can only be used by that merchant - so if the token does get exposed you can't use it all over the place.
Of course, no guarantees that things are done properly, and it's very easy to e.g. turn on debug logging of all inputs without remembering there are some you definitely shouldn't be logging!
If they're doing it properly, then the credit card numbers will be passed to a CC processor, who will return a transaction number.
So basically we replace a token known to me, the merchant, and my "bank" with a token known by the merchant, the "bank" and a trusted third party but unknown to me. I'm not sure that's a bad idea. But in addition to being kind of complicated, its potentially risky if the "trusted third party" turns out to be not so trustworthy. Or they ae compromised by -- say-- ransomeware. Or if they go out of business. Or if they decide to charge outrageous fees for their services.
Don't get me wrong. Sometimes the best answer for a problem is more complicated than the simplest answer. But ...
Speaking from the far off lands of the Netherlands, but also available in some other European countries, we have a wonderful system called iDeal, where a transaction is stated in the vendor's environment, transferred via a single use number negotiated between vendor and bank and then finishes the transaction in the bank's environment.
We also use IBAN, which can be used to transfer money to an account and identify the account, but cannot be used to charge the account without jumping through a bunch of hoops at which point a large part of the responsibility lies with the bank.
Obviously this is less attractive for Amazon and all, because they can't use their one click purchasing with these systems.
Yes it does make a difference as it means a certain attack vector is no longer possible. That reduces the risk of compromise of the card data.
It doesn't completely eliminate the risk as different threat actors may adopt a different attack vector.
But the idea that it's not worth implementing the measure because it doesn't entirely eliminate the risk is flawed.
Doesn't stop a vector as you don't know whether the card details are being recorded anyway as part of the transaction. Therefore there would be no vector that you're eliminating.
In fact you'll probably find that the sites that allow you to store card details are probably much more secure than the ones that don't. Ones that ask you to store card details are *likely* to have put a lot of thought into the security of such a feature. Those that don't may have rally rubbish security and still be recording the details.
Not necessarily so of course, and it doesn't mean that you should store your card details, I don't for most sites. However the idea that using sites for CC details means they aren't stored is plain wrong in many cases.
This is why it is never a good idea to store your card details on any website. Never have done, never will.
They're welcome to my vcard ones - the details change after every transaction :).
The only issue is is that it has become such a habit that I forget it's not very useful for subscriptions. Sorry, Akeeba :).
The main reason for temporarily storing card details is to deal with offline payments. If the payment provider is down, or any fraud checking services respond with inconclusive results, then they are retried without keeping the customer waiting. Once it is verified as being legitimate/fraudulent then offline details are erased.
So it could be the offline card details were accessed, and the cleanup process hadn’t run - potentially an overnight process?
You will find that it is not be that the Security Team being "lazy",
What you will find that the Management has chosen not to implement certain Security controls in for "Business Reasons" even though the Security Team has demanded it.
You will find that the Business will have a high turnover of Security Team as people join, try and do their best to secure the Business, then realise that the Management are not on board.
EU261: if the flight couldn’t depart because of something outside of the control of the airline, like strikes, volcanoes, then no you are not entitled to it. If the airline had a technical problem or staffing issue, then yes, you will get a refund.
Every airline in Europe works this way. Don’t think that easyJet are the only ones working like this.
1. It is interesting the ICO won't release details of when they were notified. There is a legal time limit of notifying the ICO upon detection of the breach. This makes me think that EasyJet did not comply with the time limit.
2. There is no legally mandated need or time limit to notify the customers, but if the ICO thinks you should have done, given the potential impact on the customer, and you haven't, the ICO can take that into consideration when determining the size of the fine
If the breach was detected in January and EasyJet didn't notify customers to the beginning of April then the ICO should throw the book at them. But somehow I don't think they will.
"There is no legally mandated need or time limit to notify the customers ..."
Not true - article 34 GDPR gives the requirements for notifying data subjects that their data has been breached: that is why the ICO can take failure to notify into consideration in fining.
Really Il Reg?
If it was funny, I wouldn't mind..... but its neither accurate or funny ..... so do please try again?
Its headquarters, are in the Netherlands, the three largest countries involved are France, Spain and Germany, followed by UK and many other European countries ..... so maybe try something like "Euro-Bloc Flying Fortress" etc ......?
There, that wasn't so hard now was it? ;-)
If *Airbus* gets its way, there won't be any more Welsh wings. Or any other parts manufactured in the UK.
The buggers have been trying to get all manufacturing out of the UK since I started working at BAe Systems (or British Aerospace as it was back then) in the 1980s. They don't mind us designing everything but they don't want us to be able to actually build anything.
"We took immediate steps to respond"
Yup, we sent out some emails and also contacted people than can do nothing.
"manage the incident "
In other words we did our best to avoid GDPR fines.
What we did NOT do was secure our data in the first place... and once the data is gone, it's gone, and soon to be for sale on the Dark Web....
Sheesh, here we go again, another big name scrimping on IT security and using Stevie Wonder for their PCI-DSS audits.
Sod the ICO/GDPR fines, the banks should just take away their ability to take card payments, its not like this stuff is actually difficult.
If it's SQL injection again they really need to rethink their application and DB tiering, but I'll hazard a guess that everything is running on a single Internet-facing tier.
I'd call them cowboys, but at least cowboys wear boots.
Have you ever thought that they’d done everything right, they organised pen tests regularly, patched their system and ran their payment environment just as PCI-DSS describes. It’s just they got hit with a zero-day or that one machine that was offline for 6 months suddenly became infected?
I wouldn’t be too presumptuous to assume that it’s a TalkTalk breach all over again. Many companies in the sector and size of TalkTalk really did pay attention to it.
Only the ICO report will tell us how sophisticated this attack was and what efforts easyJet went to to protect their customer data, applications and PCI environment.
(However - judging by the DSG Retail ICO report, the ICO will be expecting easyJet run their whole organisation in a similar way to how the PCI-DSS environment is managed. If they’re organisational processes don’t at least align with PCI-DSS, that’s the first nail in the coffin.)
Done properly storing credit card details isn't a problem since the actual details themselves are never stored just a reference token that can only be used by that one merchant. Of course as an end user you have no idea if the website is going to do it properly or just chuck them into a table next to your email address and password.
As mentioned in the article this most likely isn't Easyjet storing card details but some kind of script running on top of the website harvesting the card details as they are entered. It makes little sense that Easyjet would have card details stored in an accessible way for 2200 people only.
Right now I'm coding the card-taking bit of a site I'm developing and no bloody way, my non-technical business partner wanted us to handle it all in-house to reduce transaction costs but I refused to. No way I'm being responsible for that sort of stuff.
We're using a proper/expensive card processing company, storing nothing card-related for one-off payments and only storing a token to re-identify customers for repeat subscription charges, and I'm being super-paranoid about that, Azure Key Vault for the db connection string and authentication key for the card processor, proofs against sql injection of course, custom obfuscation of the tokens and key itself (because why not), super-locked down privileges about which users can initiate financial stuff (not the ones used by interactive sessions for a start, not even admin users!) and I'm still looking around to see what else I can do.
The idea of leaking people's names and emails is scary enough, even for our small user-base, but card data; jeez, that's terrifying.
Cheers, here in Bali I'd kill for a proper beer which looked like that...
Now, if somebody can tell me how to persuade my code to get at the bloody Azure key vault when it's actually running on Azure that'd all be great, got my dev code using it fine but can't get the system test install to work, so it can't even open the database never mind process a transaction, it's one of those 'switch to branch, fight with it for half an hour, give up, do something less annoying for a while' problems !!
>Have you looked into Stripe?
We're using exactly them in fact, I say 'expensive' in comparison to not using them, I think their charges are perfectly reasonable.
They're also the mandatory default in a way, the 2 other 'big boy' card processors we contacted seemingly weren't interested enough in our tiddler of a company to reply to my initial 'send their support folk a few questions and see if they respond' pings. Stripe came back to me almost instantly.
The Stripe.net library is open source, I reported a bug in the new 36.12.1 recently (2 properties of a message type were marked internal rather than public by mistake), got a response in 10 minutes, they fixed it within half an hour and 36.12.2 was available in NuGet within the hour, I'd barely cloned the code and started working with a temporary fix before they'd released the fix-proper, now that's impressive !
"The Information Commissioner’s Office said in a prepared statement that it has “a live investigation into the cyber attack involving easyJet” but did not answer questions about when Easyjet notified it of the hack. The agency has previously said it will not be enforcing data protection or freedom of information laws during the coronavirus pandemic, something noticed by Wired magazine today."
Wait, what?!?
The agency has previously said it will not be enforcing data protection or freedom of information laws during the coronavirus pandemic
WTF!
I am hoping that does not mean EasyJet and any other company is being let-off their legal responsibilities. I expect the ICO to enforce the law and issue fines at a later date for those GDPR violations which occur during COVID-19, but I fear ICO will go easy on them and they won't be held accountable.
You misreading it. They are not ENFORCING it at the moment. Doesn't mean they are ignoring it. Deferring is better wording. Companies will still get find, but courts are not running fully, their staff will be reduced and you could be building a case against a company that may not be around in 3 months time.
Besides, better to hit them when they have some cash
They are not ENFORCING it at the moment. Doesn't mean they are ignoring it. Deferring is better wording.
The Wired article quotes a letter received by a complainant from the ICO. "We have therefore decided not to take forward any complaints that require organisations to take action or respond to enquiries from us until the situation improves."
If you receive a letter saying "we have decided not to take forward your job application", it means that the company isn't going to hire you, not that they are going to hire you in a couple of weeks time.
It the ICO isn't processing these complaints until the end of the Covid crisis, but the complaints will be saved up an actioned after that, perhaps they should have actually said that instead of writing in ambiguous euphemistic bollocks management speak.
Smooth Newt said "If you receive a letter saying "we have decided not to take forward your job application", it means that the company isn't going to hire you, not that they are going to hire you in a couple of weeks time."
Conveniently overlooking the phrase "UNTIL THE SITUATION IMPROVES". Which puts a completely different spin on things when it's added to a statement...
Personally, I agree with those who think the ICO will simply brush anything and everything they can under the carpet, given how effective they have been so far. But we can always live in hope,
Smooth Newt said "If you receive a letter saying "we have decided not to take forward your job application", it means that the company isn't going to hire you, not that they are going to hire you in a couple of weeks time."Conveniently overlooking the phrase "UNTIL THE SITUATION IMPROVES". Which puts a completely different spin on things when it's added to a statement...
"We have therefore decided not to take forward any job applications until the situation improves" doesn't mean you have been hired. It just means no-one else has either.
The sentence they used was "We have therefore decided not to take forward any complaints that require organisations to take action or respond to enquiries from us until the situation improves." You hope the sentence means that processing of complaints is deferred but it just as easily means that complaints will be binned until the situation improves.
So it is earier getting data and creadit card details from EasyJet than getting a refund on a cancelled flight!
Was due to go to Krakow in March but as Poland shut the airport EasyJet cancelled the flights. Got a refund for the flight out - but the flight back has been deleted from my bookings making the task of applying for a refund a tad difficult. Trying the creditcard route but they are similarly in being un-cooperative.
The PCI DSS security standard for handling credit cards mandates this. If easyJet (subs note sp) were doing so (about as unlikely as storing their site password in clear text), they'll be in a world of trouble. The standard also requires all CC data to be strongly encrypted.
The PCI DSS security standard for handling credit cards mandates this. If easyJet (subs note sp) were doing so (about as unlikely as storing their site password in clear text), they'll be in a world of trouble. The standard also requires all CC data to be strongly encrypted.
Flaws in encryption are almost always around key management. Encrypting a block of data is just a library function call, but key management is a tricky design problem fraught with potential difficulties.
The news nowadays is full of "hacks" sophisticated and otherwise. The good news is the increasing mindfulness we all have about IT security, the bad news obviously is for the victims. There always seems to be a lot of happy finger pointing in these posts, "I'm better than you" , "never going to happen here". Maybe. When I read about these stories my predominant thought is about redoubling my own efforts and worrying what I don't know or might have missed. The unknown unknown. The moment we allow ourselves that small moment of schadenfreude, or even smugness we run the risk of being the next victim.
Chief exec Johan Lundgren apologised for the failings of his airline's "robust security measures," saying: "We would like to apologise to those customers who have been affected by this incident."
Aside from the glaringly obvious fact that something which was "robust" cannot have failed, this is yet another example of the way the higher echelons of business in the UK (and elsewhere, too) are permeated with morons all using the same prayer book to lament the evils of others whilst absolving themselves of any blame.
The idiot Lundgren must surely be on Dildo Harding's Christmas card list and vice versa. Amazing, the way this particular sub-species proliferates.
When the BBC reported on this,they said that it bore all the hallmarks of a Chinese hacking team.
I wonder did they get this information from EasyJet or was it something dreamt up by their inhouse disinformation team.
Of course, they might have thought the Russian angle has been a little overplayed of late, who would care if it was Iran and as for North Korea that will be saved for another time.
It will be interesting if what they mean by "sophisticated" ever emerges?
"Our investigation found that your name, email address, and travel details were accessed for the easyJet flights or easyJet holidays you booked between 17th October 2019 and 4th March 2020."
But I haven't booked a holiday with EasyJet for well over 3 years. Certainly not between 2019 and 2020.
Me thinks the greek complains too much.
Does anybody else have more free credit monitoring from numerous data breeches that it's seeming a bit redundant?
I'm way past the point where I want to start seeing C-level execs in pillory and companies fined into oblivion and anybody with any security job posting to be in serious trouble of being able to take on subsequent employment in that field after enquiries are complete. It needs to be a major liability to store customer's PII and financial details. If it could mean company ending fines, maybe they'd take it far more serious. I'm more than happy to be John Smith 12345 for any miles account and type in my CC number each time. They don't need my bloody life story on file "to serve me better".
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
