Imagine you're a transaction processor that powers ticketing for several consumer travel websites, and you are contacted by a programmer outside of your company who says there's a flaw in how your platform interacts with the websites of your vendors.
Thieves could exploit the flaw to skim the credit card details of consumers, says this programmer.
What would you do?
It isn't entirely an abstract question.
This winter, a North American programmer, or hacker, contacted a major ticketing platform based in the US, alleging that the websites powered by its white-label solution was vulnerable to this type of attack.
The company reacted with alarm. Its affected clients included the consumer websites of minor, but nationally known, brands used mostly by domestic travelers.
If true, a customer's credit card details would be vulnerable to theft as they were typed into any of the branded websites.
What follows is something of a "he said, she said," story between the hacker and that ticket processing provider. But of course this is also a cautionary tale for other companies that may be exposed to the same alleged vulnerability -- without knowing it.
Timeline
Last November, a self-styled white-hat hacker contacted a ticketing solutions provider alleging the company and its vendors had a security hole.
The programmer says he had discovered a flaw in the booking software which exposes customers to credit-card skimming.
In his words [with identifying information redacted]:
"An attacker could easily set up a router near a hotel, call it "Hilton WiFi", and skim card info for anyone who connected to it and later booked [a major attraction nearby]. Any off-the-shelf router will work; it's simply a matter of changing DNS settings."
On the webpage where a user enters in his or her credit card details, the Verisign logo would be displayed and all would seem as if the transaction was secure. But the transaction would actually be vulnerable.
The hacker says he discovered the flaw in a roundabout way.
I'd done some work with credit-card integration in the past and I was aware of the security requirements and best practices.
In October I booked tickets to an event at a theme park attraction. I noticed that one of the basic security requirements -- that the page be loaded over a secure connection -- was missing.
The part that I (re)-discovered actually came after the initial contact with [the company]. Initially only bookings made while connected to a "bad guy's" router would be affected.
The "discovery" was that as long as the customer had connected to the bad guy's router at some time in the past, the card was vulnerable.
Here's the paper from the guys who actually discovered it in 2010
On November 27, a little more than a month after noticing that the page was not loading securely, the hacker developed a proof-of-concept attack and contacted the company. On December 6, he sent a YouTube video he had made demonstrating the attack.
On December 14, he published a post that didn't mention the company but that described the nature of the attack to get the word out about it. The post offered a more technical explanation of injecting JavaScript on an unsafe network which is run later on a safe network.
As noted above, the hacker learned he was not the first to discover the potential for this type of attack. But he was the first to find the flaw in the company's product in particular.
The hacker says he persisted for weeks in attempting to get executives to fix the issue. In his account, which is supported by emails and a trail of voice messages, executives as high up in the company as the CEO did acknowledge the alleged security vulnerability.
The hacker told Tnooz about the situation. On April 4, Tnooz contacted the company.
The company's communications team faced a series of scheduling delays, so ten days passed before Tnooz received a comment from it. By that time, in mid-April, the alleged security vulnerability appeared to have been patched by the company's largest clients.
The company told Tnooz by phone:
"[We have] a rich history of being very focused on security. We're proud of our security protocols. We comply with federal security mandates, and we're level 1 PCI compliant, which is the highest level security certification for payment processing.
But even so, we're never going to be complacent about the role we play in helping venues fulfill e-commerce transactions.
It is [our] policy to aggressively research, authentiticate and address any and all security risks. We work closely with venues to provide the clients with strongest fraud prevention and data protection technology available.
It would be irresponsible and counterproductive of us to publicly address our approach to security or to speak about individual cases.
Responsible disclosure
In the spirit of "responsible disclosure," Tnooz is only telling this story today at a point when, to the best of this reporter's knowledge, the company and its vendors have had a reasonable period of time of five months to patch the alleged security glitch -- if the glitch indeed existed and was a real threat.
Yes, that statement is worded confusingly. The reason? The company has declined to confirm on the record that the threat ever existed, so we can't 100% say that it did exist and has been repaired. The company has also declined to say if any clients or customers experienced any data loss.
However, according to the hacker who alleged its existence, the glitch on the particular website shown in the video is no longer an issue.
Tnooz does not mean to single out the company for criticism -- hence, our use of anonymity in this story.
But it does want to give adequate details so that other travel companies (and would be "white-hat" hackers) can draw their own lessons from the timeline, pooling their knowledge to decide on best practices.
A fight over the video demo of the alleged vulnerability
There's a twist to this story: Before the hole had been patched on all of the websites of its vendors, the hacker posted a video on YouTube that explained how the company's platform was vulnerable to attack.
The video received only a few dozen views over four months. The hacker says:
The video would never have shown up in YouTube searches or even on my profile. It was a private video that only people with the URL could see.
Around April 23, the video disappeared from YouTube, where it was replaced by a statement saying that it had been removed due to "a copyright claim" made by the company.
On April 25, the hacker sent a Digital Millennium Copyright Act (DMCA) counter-notice to YouTube, which in turn says it passed the counter-notice on to the company lawyer on the same day. Under the DMCA, the transaction processor had a limited number of days to serve the YouTube user with a lawsuit, or else YouTube could restore the video within 4 days after that.
The hacker has sought advice from the Electronic Frontier Foundation (EFF), a San Francisco group which describes itself as "a donor-supported membership organization working to protect fundamental rights regardless of technology."
This back-and-forth over the copyright claim may be resolved shortly.
But in the meantime, the story illustrates the lengths to which a travel company might go to keep a video critiquing its security procedures out of the public domain.
This is also a story of a security vulnerability that appears to affect several consumer-facing travel websites.
Details on the alleged vulnerability
Here's hacker's explanation, in an e-mail to Tnooz, of how the attack would work:
A big red flag is when when companies "enable transactions directly through the vendor's site". There are secure ways of doing this, but it's easy to get wrong.
Essentially [the company's] value proposition is that it can be dropped into the attraction's site and facilitate ticket purchases without leaving the page. Everything from [the company's] servers is loaded securely (ie. over HTTPS) and all the sensitive data is sent encrypted over the network.
The problem is that the [consumer travel] site itself is loaded over HTTP; a big piece of the value proposition is that their customers don't have to muck around with SSL certificates.
This means that if the user is connected through an untrusted router, that router could intercept the [consumer travel] site before the "secure" parts are loaded and add a few lines of JavaScript to send every keystroke back to a server controlled by the "bad guy".
That's bad by itself, but there's actually no requirement that the user is accessing the site through an untrusted router while booking. As long as the user has accessed a website through the "bad" router in the past, the user is vulnerable.
(This works by forcing the browser to cache a version of jQuery with the key logger code. As long as the bad code is cached, the user is vulnerable.)
An attacker could easily set up a router near a Seattle hotel, call it "Hilton WiFi", and skim card info for anyone who connected to it and later booked the [attraction/destination/activity]. Any off-the-shelf router will work; it's simply a matter of changing DNS settings.
Sites which take major credit cards are explicitly required by the card issuers to have HTTPS in the Address Bar to prevent this sort of thing (as per PCI DSS v2 4.1.e)
SEC and other implications
For public companies, keeping quiet about alleged and real security vulnerabilities may even be risky.
In 2011, the US Securities and Exchange Commission (SEC) said that corporations must "report any material losses" resulting from a hacker attack. This winter, at least 27 companies reported attacks in their financial statements, according to Bloomberg News.
Yet all businesses have lost some of their ability to work in secret -- and at a pace of their own choosing -- to make sure that thieves can't steal their customers' information.
We now live in an era of so-called ethical hackers, programmers who use their spare time to find or fix security holes in the websites and apps of organizations they don't work for.
Ethical hackers say they want to help companies, and they appear to have varied motivations.
Many say they want to be Good Samaritans, helping to protect innocent companies and people from being harmed. A handful want to shine a spotlight on their programming smarts in the opportunistic hope of being hired by a company who hears of what they've done.
Ethical hackers differ from those "black hat" hackers, who instead grab headlines by exploiting software glitches to embarrass or harm companies, such as the recent cases of black hat hackers who exposed password information inadequately protected by companies such as LinkedIn.
Information technology (IT) departments of major companies, including in the travel sector, are still trying to figure out how to handle the unsolicited help of ethical hackers.
Sometimes outsiders, including amateur security researchers, are able to spot flaws that employees have overlooked.
This can happen even if a company has a solid focus on creating robust procedures around securing products before release and in using industry "best practices" to protect their e-commerce transactions from interference.
Even if there's no real danger, companies may worry that allegations of a security vulnerability or breach could unnerve customers. Companies may also fret that rumors would bait "black hat" hackers, who might target a company for actual attacks, like sharks smelling blood in the water.
The debate over "responsible disclosure"
If your travel company is approached by someone who claims to have spotted an alleged security flaw in your product, how should your team respond?
This territory is so new that industry guidelines are still in flux and few companies have procedures in place for how to handle such a situation.
One industry model being touted is for companies to pro-actively publish online their "responsible disclosure policy." This means posting some brief language on the company's website that tells hackers how to share any security flaws and breaches they may found in a discreet manner.
The key is to allow the company reasonable time to repair the problem before publicising the news.
For example, EngineYard, a platform-as-a-service provider, has posted online its responsible disclosure policy.
EngineYard follows the custom of many companies to publish the hacker's name (with a link back to the person's website or Twitter handle) as a courtesy or a thank you.
A simpler option is to instruct one's IT team that -- if they are approached by someone who claims to have spotted an alleged hack -- they "agree to allow a period of time for the vulnerability to be patched before publishing the details," in the words of the Wikipedia entry on "responsible disclosure."
Ideally, the company would agree to a timeline, and the hacker or reporter would keep the lid on the issue until it's fixed, assuming that progress was being made according to the original timeline (with extensions granted when there's evidence of progress).
For example, on January 11, the hacker discovered a similar JavaScript issue with Twitter and contacted that company. On February 22, the the company fixed the issue.
The tricky part of "responsible disclosure" is striking a balance between giving a company time to fix an issue without giving them an indefinite amount of time, in which they may simply be ignoring the problem -- potentially exposing their clients and customers to trouble.
The hacker justifies his actions this way:
I didn't contact a media outlet [Tnooz] until four months after I first contacted [the company], which based on my experience was more than long enough to fix the issue.
It was my opinion at that point that the responsible thing to do was to put public pressure on [the company] to fix the issue, which seems to have worked.
Other websites may be affected
This security vulnerability appears to affect other companies not powered by this particular white-label solution.
The hacker says he has discovered a similar security hole in a few other travel websites. He contacted these sites to say he thinks they are vulnerable to this type of attack.
Those companies have politely acknowledged the problem and say they are working on solving the alleged problem, according to the hacker.
We spoke to one of the travel startups in question, who confirmed our source's version of events.
But the hacker hasn't done an exhaustive search of all travel websites, obviously. So there may be companies out there affected by this alleged security vulnerability who don't even realize it.
NB: Comments are closed on this article.
[Image credit: Guy Fawkes mask courtesy Rob Kints / Shutterstock. The security illustration is courtesy of Shutterstock, too.]