Hundreds of Hotels Affected by Data Breach at Hotel Booking Software Provider (bleepingcomputer.com) 30
Catalin Cimpanu, reporting for BleepingComputer: The personal details and payment card data of guests from hundreds of hotels, if not more, have been stolen this month by an unknown attacker, Bleeping Computer has learned. The data was taken from FastBooking, a Paris-based company that sells hotel booking software to more than 4,000 hotels in 100 countries -- as it claims on its website.
In emails the company sent out to affected hotels today, FastBooking revealed the breach took place on June 14, when an attacker used a vulnerability in an application hosted on its server to install a malicious tool (malware). This tool allowed the intruder remote access to the server, which he used to exfiltrate data. The incident came to light when FastBooking employees discovered this malicious tool on its server.
In emails the company sent out to affected hotels today, FastBooking revealed the breach took place on June 14, when an attacker used a vulnerability in an application hosted on its server to install a malicious tool (malware). This tool allowed the intruder remote access to the server, which he used to exfiltrate data. The incident came to light when FastBooking employees discovered this malicious tool on its server.
How in the hell... (Score:5, Insightful)
... is this even possible:
In some cases, but not all, the intruder also obtained payment card details were also stolen, such as the name printed on the payment card, the card's number, and its expiration date.
Seriously. How is it possible that this data is not stored on hosts on separate, fortified networks, with decryption keys available only on other locked down machines that exist only to generate bank settlements and/or transmit billing information to the hotel as needed?
This cavalier attitude by so many organizations towards data security, the culture of expediency over security, and the fact that so often security is a zero sum game that no one really wants to be involved with has got to change. If it doesn't, there will be such a lack of trust and saturation of everybody's personal data that I could see the entire system becoming destabilized. Wouldn't that be fun. /rant
Re: (Score:1)
Perhaps companies who write the code, or install the code in software/firmware should be held accountable for the security of their products and if there are breeches then the companies and developers whill have to shoulder the multi-million fines. Don't want to be held accountable, then don't get involved with writing security code etc. The same goes for the Chinese and all their lack security of IoT
Re:How in the hell... (Score:4, Interesting)
Sadly, often, devs, sysops, and devops, and the security architects, will propose good, solid solutions.
But - they are expensive and difficult to maintain. All too often, expediency gets in the way. And with security, all it takes is one hole, one door left wide open.
So, business decisions are made. Security guys go get drunk, and executives launch new and exciting products.
And when it does eventually hit the fan, no amount of documentation will prevent some poor technical sap from taking the fall.
Combine the fact that keeping the bad guys out is seen as a zero sum game - the ultimate cost center - and the above described all-too-common culture, who in their right minds wants to go into the field? And now you want to penalize the devs?
I agree that there has to be accountability. But it needs to rest with the decision makers, not the poor saps who have to follow orders or tell their spouse unemployment isn't the end of the world.
The problem is it's often easy to hide. Fire code (Score:3)
A problem with penalizing companies that fall victim to hackers is that most such incidents are easy to hide, which is precisely what you don't want. You don't want companies covering up a breach to avoid penalties. You want the systems to be safe in the first place, which requires communicating about risks and attacks.
People also have a terrible intuition about judging risks. They probably won't have a major breach this year, so it's not a top priority.
What you want is to have people make their stuff safe.
Re: (Score:2)
Let me guess. You're and MBA, not an engineer.
Re: (Score:2)
Re: (Score:2)
No, the question is why is the cardholder name, card number, and card expiration date stored on the booking system at all? Only keep the data as long as necessary to effect the transaction.
For convenience of course. That way when you go back for another reservation, you don't need to type out all of those annoying numbers again.
Re:How in the hell... (Score:4, Interesting)
... is this even possible:
In some cases, but not all, the intruder also obtained payment card details were also stolen, such as the name printed on the payment card, the card's number, and its expiration date.
Seriously. How is it possible that this data is not stored on hosts on separate, fortified networks, with decryption keys available only on other locked down machines that exist only to generate bank settlements and/or transmit billing information to the hotel as needed?
There's not enough information to verify whether what happened was truly a function of the software itself. Allow me to illustrate...
A client at work and I got into a pretty bad argument at one point. They use a hosted Citrix app to book the things they book (don't want to say the name). The client's issue was that she had trouble copy/pasting credit card numbers into the PoS software, which "she used to be able to do". I told her I was not going to fix it, because she shouldn't be storing the credit card numbers in the Citrix app. "But then the clients need to read me their credit card numbers every time!" "Yes. That's the point."
"These people pay thousands of dollars monthly; I don't want to inconvenience them and potentially use these regular clients!"
"I am pretty sure that every single one of them would prefer to do that than to have their credit card numbers live in a system that is not even remotely PCI compliant, and for which your merchant account would likely drop you if they knew you were putting all of these card numbers at risk that way, preventing you from taking their credit card at all."
"But it's fine because it's in the 'notes' section. It's not labeled 'credit card number', so if the system were hacked, nobody would know to look for them."
"If you can get your payment processor to tell me it's okay to store credit card numbers that way, not only will I fix the issue, I won't bill you for the time. Do you want me to get them on the phone, or would you rather do it?"
"No, it's fine. I'll just write them down in an Excel spreadsheet."
"You cannot retain your client's credit card numbers in any form and retain your PCI compliance. Period. If your computer gets hacked and the hackers take that file, I guarantee you that the best case scenario is that you have lost every one of those clients, permanently, with the worst case involving multiple lawsuits. Moreover, the only reason you won't lose them beforehand is because I sincerely doubt they're giving it to you knowing that you have every intention of storing it in a very insecure manner. I know it's a pain, but the extra 30 seconds it will take them each order is preferable to every one of them than disputing credit card fraud. For the sake of your clients and the sake of your business, you *must* stop storing credit card numbers on your system, at all, period, full stop. Feel free to have the owner come out and discuss it with me, I will make the same case to him."
"...okay, fine."
The user was entering credit card numbers where they weren't supposed to, and the software wasn't smart enough to detect a credit card number in a generic 'notes' field. While it's entirely possible the booking software was poorly written, it's equally possible that it was being used in a way where the end users were intentionally making end runs around safety mechanisms.
Individual end users can generally be trained. In aggregate, they will take convenience over security 10 out of 10 times. If they don't, they're not end users, they're infosec.
Re: (Score:2)
GDPR? (Score:1)
By their report in the article the berach has been discovered on June 19 and they are informing affected parties on June 26, one week later. Doesn't the GDPR (they are even based in France) require to inform in just 72 hours (3 days)? Also if they adhered to PCI-DSS standards credit card numbers shouldn't have been stored unencrypted.
Re: (Score:2)
By their report in the article the berach has been discovered on June 19 and they are informing affected parties on June 26, one week later. Doesn't the GDPR (they are even based in France) require to inform in just 72 hours (3 days)? Also if they adhered to PCI-DSS standards credit card numbers shouldn't have been stored unencrypted.
You are assuming that they were adhering tot he GDPR (or whatever French regulation came before, GDPR was mainly an amalgamation of the existing data protection/privacy acts in EU nations, giving it the clout of the full ECJ). If they were not adhering to PCI-DSS, why would they care about GDPR. I assume they assumed they simply wouldn't get caught. This is why I dont use dodgy 3rd party booking agents. Hotels, airlines, et al. will likely give you the same price if you call, you'll be treated better and t
Malicious tool installed on FastBooking server? (Score:2)
What was the name of the Application and the name of the Operating System this malicious tool ran on. How did this malicious tool get onto the server in the first place.