Slashdot Mirror

← Back to Stories (view on slashdot.org)

Hundreds of Hotels Affected by Data Breach at Hotel Booking Software Provider (bleepingcomputer.com)

Posted by msmash on from the privacy-woes dept.

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.

4 of 30 comments (clear)

  1. How in the hell... by forkfail · · Score: 4, 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

    --
    Check your premises.
    1. Re:How in the hell... by forkfail · · Score: 3, 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.

      --
      Check your premises.
    2. Re:How in the hell... by Voyager529 · · Score: 3, 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.

  2. The problem is it's often easy to hide. Fire code by raymorris · · Score: 2

    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. The fire code gives us a pattern for this that has worked. Companies comply with the fire code, and avoid fires, because otherwise their insurance company or the fire marshall will bust them for not following safety code - before they ever have a fire. You don't penalize people for having a fire, the insurance company checks that you're following fire code BEFORE a fire occurs.