Tell HN: Alaska Airlines website exposes passenger data | Hacker News Reader

Tell HN: Alaska Airlines website exposes passenger data

65 pointsJaakkoP44 comments

TL;DR: Alaska exposes other customers names, record locators, flight information, phone numbers emails, and probably more. I could have canceled or changed these people's flights.

The first time it happened it appeared by seeing "Treat yourself, Samantha" in the website ad for upgrading yourself to Premium class. My name is not Samantha.

I clicked, and saw Samantha Lastname was traveling from Miami to Seattle. There was her phone number, record locator, ticket and mileage numbers, emails and other info. It also would have let me change or cancel her flights.

When I refreshed I got a new person. Trevor. He's going from JFK to SEA, and back to EWR.

I figured this wasn't one-off (yet still serious) bug, and called Alaska Support. They didn't believe me, but once I had rattled off the customer information I had in front of me and told them I'm none of these people, they transferred me to somewhere I thought was a higher up.

The higher-up person verified some information, asked no questions on how to replicate the bug, and asked me to log out and log back in. Once I did, the issue did not show up again. They said they'll send me 3,000 points for reporting. That sounded pretty low to me as it seemed like a serious data leak, but whatever.

I contemplated whether to post about this as I thought it would be interesting for the HN audience to see, but decided against it thinking I'll give Alaska time to fix it.

It's been 4 months now, and today this happened again. I saw an upgrade ad for Sally. Sally and Chris are traveling in the same reservation from Redmond, OR to Seattle in Main Preferred class. Knowing what I was looking at, I figured Alaska had done absolutely nothing to fix the issue.

I have a theory what's causing it as there's something specific that happened before both of these issues, but I'll refrain from posting it here so it's not as easy to exploit. Who knows what else the payload might include.

I took screenshots throughout the process, including some console logs, to document what I saw. I am sharing this here in the hope that the added visibility will finally push Alaska Airlines to address the issue.

They have an ecomm team and info sec team but they’re pretty unwilling to fix this. They do agile but no one wants to own this, especially in December since they have change freezes and this will affect the yearly and monthly issues.

I would advise submitting this is the state of Washington and DOT federal and state.

Technically this is a data breach. Atg.wa.gov I would submit a data breach notification this will force them to actively fix it this month otherwise they will sit on it and push it off per agile sprint and do it when it’s convenient for the airline. Post holiday rush.

How do you know they are unwilling to fix this? My guess is it has not been fixed because the people who can fix the bug do not know it exists.

Support won't know what to do. Have you tried their cybersec form? https://www.alaskaair.com/content/about-us/site-info/report-...

Thanks! Just did. I didn't think of it the first time given they escalated me to someone who then asked me to verify the information I had just told them over email. Maybe this will get their attention.

Cyber or the executive offices, corporate. More responsive and better perks for you.

Actually call if possible.

Right. But now you have agreed not to tell anyone about this bug. What you've told before cannot be counted I assume.

And you have agreed not to access any information not yours. So if in n months you will be greeted "Treat yourself MikkoX" you are not allowed to click anymore.

Not necessarily trying to say you did the wrong thing. But I do hate corporate lawyers.

I have connections with people at Alaska. I will send this their way and hopefully someone will reach out. Make sure there is contact info in your bio

Are you trying to get OP sent to prison?

Stop being dramatic. Most companies appreciate white hats. OP didn't divulge the exploit and is being responsible.

Clearly you haven't read the CFAA.

OP has already contacted them once. If they want, one thing all lawyers are competent at is digging out info.

You need to be very, very careful about posting this, depending on your jurisdiction - in most western countries this disclosure is illegal, and you can be criminally prosecuted for providing information about accessing personal information, and you are also admitting that you knowingly accessed the personal information of other customers - in fact, airline passengers, who there are additional privacy laws for.

What you’ve done here is a criminal act according to the CFAA, and your exploration of their site could also be construed as wire fraud. As you’ve done this across state lines this is also a federal felony. You’re also in violation of the GLBA, as you’re disclosing the availability of airline customer information. You could also fall foul of the FTC and the wiretap act.

I have seen people (Weev, Michael Brown, numerous others) go to prison for similar, and this lot could win you years in a federal penitentiary.

Please, consider the legal consequences this could bring upon you.

I would simply forget about it and promptly delete this - it’s their problem, not yours, and by posting about it here, they could decide to make it your problem.

I am not a lawyer but this line of thinking does not make sense to me. First, poster did not post any personal information. Second, the poster responsibly disclosed the bug to Alaska Airlines but Alaska did not fix it. The poster is now publicly disclosing that the bug exists. Note that the poster did not include repo steps for the bug.

The bottom line is we need a mechanism to ensure security bugs are fixed. Publicly disclosing security bugs when an organization does not fix the bug is a good way to do this.

Note this practice started in the 1980s or early 1990s because software venders refused to fix security bugs. The full disclosure movement was created because security researchers wanted the bugs fix and publicly disclosing them was the only way to get some organizations to fix their security bugs.

Yeah, that’s all nice and all but it’s irrelevant in the eyes of the law.

Not posting personal information is irrelevant - that he has accessed it and admits doing so, is.

Prior disclosure is irrelevant. There’s case law that makes this clear.

Not including repro steps is irrelevant as merely disclosing the presence of a vulnerability is enough to fall foul of the CFAA, as the reasonableness test is whether a competent person could with the knowledge given reproduce the vulnerability, to which the answer is almost always yes. They also admit using the vulnerability, which is definitely a violation of the CFAA.

I agree wholeheartedly with your sentiment that this is nuts, but this is the way the law has been written and applied, and he is taking a serious risk with this disclosure.

They clicked an ad. What did they do that's illegal?

They have a bug. Serious one, yes, but they listened and gave you points for reporting it. Seems to me at least the support staff are trying (even if they aren't quite able to get it fixed).

I don't think it's realistic to expect airline support staff to know how to properly classify and route web vulnerabilities. Giving someone points is just a way to get them to go away so the ticket can be closed.

I disagree. Even support staff should be able to say "oh wow, this is really bad, let me get my supervisor", who would then recursively escalate until they get to someone who can open the correct ticket.

“Should” is doing a lot of work there.

For that to actually happen support staff has to be empowered to think for themselves and also be compensated enough to care.

Agreed. Every customer support rep should be making at least $200k a year. Then they'll care about their career and quality will improve with their morale.

Seems like people down-voted you for this "outrageous" opinion, but I agree. The people that do all the important work in our society (nurses, garbage collectors, cleaners, customer support, etc.) should get the highest income.

Teachers should be paid like 10x more than they do now

Extreme DevOps is making on-call talk to customers.

That'd be nice, it just doesn't match my experience dealing with frontline support.

Most companies don't give them the training, autonomy, problem solving tools, or even buy-in to deal with something like this.

When I call in I expect them to be able to change my reservation and handle seat changes and such. I don't expect them to be able to triage a tech support call and tell the difference in severity between, say, a shared computer with somebody else's login, a browser caching issue, a database hack, a proxy or CDN issue, etc.

The OP can report the security problem by going to https://www.alaskaair.com/content/about-us/site-info/report-... . I think this is probably the best way to get Alaska Airlines to fix the problem.

You did not read before commenting. OP had already done this: https://news.ycombinator.com/item?id=42347618

Not blaming you, we all do this. Just stating a fact.

Perhaps some sort of UUID collision in terms of cookies/sessions?

Or perhaps a caching issue?

I'm going to go with caching issues + interactions with Sabre backend. Also, did you know that your confirmation code, aka record locator is not globally unique? They are 6-character sequences like KZVGX5, so as you might imagine with the number for passengers flying, it doesn't take long to exhaust the namespace.

Alaska uses 6 letters. 26^6 is a bit over 300 million codes. Each year there are about 5 billion air passenger boardings, so while the whole of aviation runs through that space every 3 weeks, any individual airline takes much longer.

Would it also include digits? If so, 36^6, which is 2.1B

Each record locator is unique not by airline but for gds, in this case Sabre. Each record locator reference a reservation which may include many flights and people that fligth together in a trip. And a reservation is done 1 year in advance. It’s not a easy math

The letter/digit-space is per GDS, not per-airline/industry, however different airlines can have particular additional restrictions on codes. Some airlines don't allow 0 and O (i.e. Qantas), others don't allow I and 1, and others always/usually have the same ending letter (unless code-sharing).

Another thing to note is (unless something's changed in the 15 years since I left the airline industry) that non-trivial booking changes (i.e. not just passenger information changes) generally result in a new PNR being generated to replace the old one, effectively using up the old code.

A PNR is not supposed to be unique. It literally is a record, that is tied to the airline ticket stock code (first three digits of a ticket number) and booking system (Sabre/amadeus) until recently a gds was not able to query one or the other (and yeah there are more, even ticketless/couponless ones)

Thats why you are required to have two to verify, ticket number or last name but in old old systems you always used the ticket number as that had all the passenger information, coupon status, route, etc the PNR is just a shortcut to facilitate this.

Originally the PNR when the reservation systems where built in the 1960’s and 70’s the six / seven / eight digit reference was the hash of the physical location in memory of the booking. It would take very few cpu cycles to recall the booking.

Nowadays of course the booking reference is virtual.

Should I read this as a reversible hash? I can't imagine it works this way, have you got any pointers to learn more about early sabre ?

You can read here https://www.jstor.org/stable/249202?read-now=1#page_scan_tab... I am sure there are other resources available.

Yeah, I bet anything this is a caching issue. I assume there's a part of the page which one layer of templates expects to be cacheable, and then someone added this dynamic promotional upgrade feature inside of it, so it keeps being stored into the cache with random people's details in it, whoever was there each time there was a cache miss.

If this is some content that isn't always shown, it could be semi-rare for the upgrade message to show up at all, which is how this kind of thing sneaks past basic QA. Also sometimes QA is operating with low traffic, such that you might still just see your own information simply because you're the only one using the site right now.

>I'll refrain from posting it here so it's not as easy to exploit.

I commend your ethics, but I'm going to be straight with you: Alaska isn't going to do anything until tangible harm and damage occurs. The cost to address the problem is higher than the cost to just ignore it. Alaska probably won't think this even is a problem yet, for that matter.

If you still want to be an unwarranted gentleman, I would report this again but put a firm deadline to disclosure and say "No" is not an answer. Also have a lawyer handy if you choose to make this a problem for them.

Do you have prior experience reporting to them, or why do you believe this to be the case?

(I'm not affiliated with them, just an occasional customer who's wondering if they have a bad reputation in this regard or something.)

>Do you have prior experience reporting to them,

No, though I'm a frequent flyer and have a fairly lukewarm view of them compared to other airlines.

>why do you believe this to be the case?

Generally speaking, people will take the path of least resistance and even moreso if they're professionals who probably aren't paid enough to care enough. Beancounters also won't care beyond the numbers in their spreadsheets.

I don't think this is fair. My guess is the person who found the bug did not report it to a person who knew how to handle a security bug report. My guess is the technical people at Alaska will fix the bug once they know it exists.

OP did they ever write back?

load balancer / caching issues

Reply on news.ycombinator.com