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.

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.

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

Actually call if possible.

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.

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.

“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.

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.

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.

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.

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.

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

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

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 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.

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.

OP did they ever write back?