Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

United Airlines Bug Bounty: An experience in reporting a serious vulnerability

randywestergren.com

Post reply on HN
Print view View original

51–60 of 80 posts

Re: United Airlines Bug Bounty: An experience in reporting a serious vulnerability

#51

Post by jacquesm »

rodgerd wrote: post #49
throwaway28474 wrote: post #39

Earlier quoted context omitted.

Does the company not have any legal recourse against people going public (or threatening to go public) with a bug like this before it's fixed? If not, how is it that United can just mark unfixed bugs "as duplicates" and refuse to pay out for them? Shouldn't all those devs immediately go public with them?

There can be a fine line between full disclosure and blackmail. I would be concerned "give me airpoints or else" would go over it.

That's a good point. If you get something out of it then it's not exactly as if you only have the public interest at heart. Which makes me wonder what would be the way to act if you found a major vulnerability in some vendors product and they point blank refuse to fix it even given plenty of time. The public good would (could?) clearly outweigh the company's interest if the hole is bad enough but it could get extremely expensive if you went public with the flaw against their wishes (assuming they know who you are and you're in a location where they can make your life hard).

This is probably very different from jurisdiction to jurisdiction, here in NL we have a government watchdog for such cases which starting 1/1/2016 will have a lot more teeth but in other countries the situation will surely be very different.

Anonymity would seem to be an asset in such cases.

Re: United Airlines Bug Bounty: An experience in reporting a serious vulnerability

#52

Post by eyeareque »

If you've participated in their program, you'll probably find that they have their fair share of issues. This is probably where their delay is coming from (but not a valid excuse). I found two serious problems in less than a hour. I reported the issues to them and was subsequently told that both submissions were out of scope and a firm warning to follow the rules. You're welcome for the free findings.

Re: United Airlines Bug Bounty: An experience in reporting a serious vulnerability

#54

Post by peterkelly »

blantonl wrote: post #53

How was this vulnerability able to be exposed in the first place if the API is communicating over SSL?

You can intercept your own SSL communications if you create your own certificate authority and add it to the list of trusted CAs on your device. You can then use this to generate SSL certificates for arbitrary domains, and by proxying traffic through your own machine you can grab the plaintext by impersonating the real site. Of course this will only work for devices you have added your CA to; you won't be able to intercept just anyone's traffic.

There's an app for OS X called Charles, which automates this process for you, acting as a proxy and generating the fake certificates on-demand. See https://www.charlesproxy.com/documentation/using-charles/ssl...

Re: United Airlines Bug Bounty: An experience in reporting a serious vulnerability

#55

Post by joshmn »

peterkelly wrote: post #54
blantonl wrote: post #53

How was this vulnerability able to be exposed in the first place if the API is communicating over SSL?

You can intercept your own SSL communications if you create your own certificate authority and add it to the list of trusted CAs on your device. You can then use this to generate SSL certificates for arbitrary domains, and by proxying traffic through your own machine you can grab the plaintext by impersonating the real site. Of course this will only work for devices you have added your CA to; you won't be able to int…

> There's an app for OS X called Charles, which automates this process for you, acting as a proxy and generating the fake certificates on-demand.

It's a bit more difficult than just loading up an MITM and generating the certs; if they've pinned (which they have), you have to go a _bit_ deeper than _just_ using an MITM proxy.

Re: United Airlines Bug Bounty: An experience in reporting a serious vulnerability

#56

Post by danjayh »

ryandrake wrote: post #5

Is six months really unreasonable for a big bloated bureaucracy like United Airlines? I've worked on projects for smaller tech companies with release cycles longer than that. Not defending--obviously they should be set up to be able to put out small emergency fixes quickly especially if they're running a bug bounty. But, hey, it's an airline: releasing software is not exactly their bread and butter.

Where I work, we turn around releases of software that runs on airplanes faster than that, and trust me, every company that writes safety-critical software for airplanes a gigantic and also a bureaucracy. Six months for a ticketing system is a joke.

Re: United Airlines Bug Bounty: An experience in reporting a serious vulnerability

#57

Post by MichaelGG »

jsjohnst wrote: post #6

If you know the PNR of an itinerary and the person's last name you can quite easily do most of what was described in this article via United's website or over the phone. Always makes me laugh when I see folks posting full images of their plane tickets online, they so easily could have their travel plans screwed. :(

Yeah at one point their app endpoints returned full pnr and last names, then truncated for display. I always thought it'd have been fun to exploit it to bump yourself up on the upgrade list by changing the flights of those in front of you.

Re: United Airlines Bug Bounty: An experience in reporting a serious vulnerability

#58

Post by BostonEnginerd »

kyllo wrote: post #41
stefs wrote: post #15

Earlier quoted context omitted.

>But, hey, it's an airline: releasing software is not exactly their bread and butter. it's not pilots and flight attendants coding that application. they've got an IT department whose bread and butter IS releasing software.

The point is they don't get sufficient resources to do their job properly because they are seen as a cost center.

This is a problem -- flying airplanes is almost secondary. Airlines are primarily logistics companies running entirely on software.

Re: United Airlines Bug Bounty: An experience in reporting a serious vulnerability

#59

Post by kyllo »

BostonEnginerd wrote: post #58
kyllo wrote: post #41

Earlier quoted context omitted.

The point is they don't get sufficient resources to do their job properly because they are seen as a cost center.

This is a problem -- flying airplanes is almost secondary. Airlines are primarily logistics companies running entirely on software.

Sort of, at least in that the airplanes would be grounded if the software didn't work. But this isn't unique to airlines. These big industry companies are lagging behind in technology and they always will, because they associate revenue to sales, marketing and account management, and they see business operations and IT as operating cost, and not a part of the product. And they have little incentive to change, because the low margins and high capex are barriers to entry that keep venture capital out.

Re: United Airlines Bug Bounty: An experience in reporting a serious vulnerability

#60

Post by bnj »

jfoutz wrote: post #32
ryandrake wrote: post #31

Earlier quoted context omitted.

I've worked where software was not the primary product and was treated as merely another line item on the BOM. They grudgingly had to "do some software" order to make money with their real product. If United is this type of place, here are a few things I'd be willing to bet are true: 1. They don't have a formal QA process or an independent QA team. 2. They don't have source control (or it's very rudimentary, like sto…

yes, absolutely. 2 freaked me out the most. I managed to get enterprise github installed, taught people how to use it, set up the client on their computers, pointed them at tutorials, and pestered them regularly. For all that effort, over the 6 months the adoption rate was pretty much just 1 developer in one department - me. It's just so damn hard to get people to change.

I'm in the position of trying to push towards changes just like these- introducing better issue management, team communication. Anyone aware of useful resources on rolling out institutional changes like that?
Post reply on HN