Orbitz Suffers Data Breach Impacting 880K Customers
Expedia-owned travel fare aggregator Orbitz.com discovered that one of its platforms was compromised last year and hackers might have accessed the payment cards details and personal information of about 880,000 customers.
The company discovered this month that hackers had access to its legacy travel booking platform between Oct. 1 and Dec. 22. This system contained data for purchases made between Jan. 1, 2016, and June 22, 2016, directly by Orbitz customers and for purchases made between Jan. 1, 2016, and Dec. 22, 2017, through partners who used the company’s platform.
The data included full names, payment card information, dates of birth, phone numbers, email addresses, physical billing addresses and gender, but not Social Security numbers or passport and travel itinerary information.
The current Orbitz website was not impacted by the incident, so customers who used it recently are likely not affected. However, since data from purchases made through partners up to the end of last year were also potentially compromised, some customers might not even know that they’ve used Orbitz.
Orbitz is used by millions of users and was acquired by former competitor Expedia in 2015 for $1.2 billion. The company will notify affected customers, as well as its partners, of the breach and is offering victims one year of complimentary credit monitoring and identity protection.
“Orbitz took immediate steps to investigate the incident and enhance security and monitoring of the affected platform,” the company said on its breach notification website. “As part of the Company’s investigation and remediation work, Orbitz brought in a leading third party forensic investigation firm and other cybersecurity experts, began working with law enforcement, and took measures to effectively prevent any unauthorized access and enhance security.”
Orbitz customers are advised to monitor their payment card statements for suspicious transactions and to be aware of potential rogue phone calls or phishing emails that might attempt to use this incident to extract additional personal information from users.
“Always be certain before you hand over any private info at all these days, regardless of the fact that the inquiring company may seem legit,” Mark James, a security specialist at ESET, said via email. “If you have not personally initiated the request, then don’t be worried about verifying who they say they are—no legitimate company should penalize you for making sure. Data breaches are becoming a very common occurrence these days—with so much of our data available on the internet, we need to be extra careful about giving over more than we have to.”
Apple Kills HSTS-Based Tracking Attempts in Safari
Apple has implemented new defenses in Safari to prevent the abuse of HTTP Strict Transport Security (HSTS) records for tracking, a technique that’s recently been observed in the wild.
HSTS is an important security feature that allows websites to tell browsers that they should always be accessed over HTTPS on future visits. Its goal is to prevent so-called SSL stripping attacks, wherein if the initial request sent by the browser is over HTTP, a man-in-the-middle attacker can redirect the victim to a fake version of the website.
Researchers warned in the past that HSTS records, which are sent in an HTTP traffic header and stored in the browser, can be used as a super cookie to track unique users across different visits even if they use privacy mode or regularly wipe browser cookies.
Because HSTS can have only a 1-bit value—it’s either on or not—but tracking requires a unique ID for each user, websites could force browsers to make requests to multiple subdomains with different HSTS settings—for example, by loading small 1-pixel transparent images from all of them. The resulting combinations of HSTS records stored in users’ browsers could serve as unique IDs to track them.
“Recently we became aware that this theoretical attack was beginning to be deployed against Safari users,” developers of Apple’s WebKit browser engine, which is used in Safari, said in a blog post. “We therefore developed a balanced solution that protects secure web traffic while mitigating tracking.”
WebKit will now only set an HSTS record for the host that is being visited and for its top-most parent domain. For example, if you’re visiting a.b.example.com, HSTS records would only be accepted for a.b.example.com and example.com, not for b.example.com, or b.b.example.com or any other combination.
To set HSTS records for other subdomains, attackers would have to redirect the browser to those subdomains in a chain. While this is possible, it would add significant latency to page loads and would be perceptible to the user. Web tracking is primarily used by advertisers, but to be viable, it has to be done without impacting the user experience on the websites that might be interested in displaying those ads.
A second mitigation added in Safari ignores HSTS records for sub-resources loaded from websites for which the browser’s tracking protection already blocks cookies.
“Telemetry gathered during internal regression testing, our public seeds, and the final public software release indicates that the two mitigations described above successfully prevented the creation and reading of HSTS super cookies while not regressing the security goals of first party content,” the WebKit engineers said.
