United Airlines Bug Bounty: An experience in reporting a serious vulnerability | Hacker News Reader

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

randywestergren.com

164 pointsrwestergren72 comments

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.

It's pretty ridiculous that actual problems are "out of scope".

Maybe it is, but given that the original commentor did not describe what the problems were, we have no idea as to their severity.

If only TSA considered security out of scope, and settled on a firm warning to follow the rules.

Sure, planes may not fall out of the sky through webservice vulnerabilities, but but you'd think airlines would be slightly more aware of how security works.

Interesting terms, if you can't talk about it afterwards how do people know that any of these bounties were paid out? After all there is a pretty simple loophole here: mark any and all reports as duplicates, no need to pay out.

You can't talk about the details of the bug but you can talk about the reward: https://twitter.com/Stephen/status/627190837735239680 The program is legit, they are just very slow (I didn't actually receive the miles until October).

The author is being nice calling it a bug. A buffer overflow is a bug. This is a moronic design, like a sql vulnerability. I am shocked that in these days and age, so many web developers have not adopted the mentality "everything coming back from the client may and will ultimately be tainted". Relying on an ID provided by the client without checking the appropriate access is unexcusable. How many years ago was the Dell shopping cart bug (where a client could alter the price of an order)?

It's frequently scarier than that. I've seen applications do the right thing by IDs and queries, but then attempt to audit access and not correctly escape or sanitise HTTP headers.

Literally, every single piece of information that an application receives is not to be trusted. Even if it's something you think you have set and have full control of (a cookie value), you're wrong... you have no control, and attackers can and will manipulate every field or property to gain a foothold.

Actually, case in point... X-Forwarded-For. This is not in a spec, people are using it as an unofficial standard. But so long as your edge removes it and then sets it... you're good.

Except Google are doing their page speed optimisation thing in the style of the Opera Mini proxy, but for Chrome users on Android. Google have chosen to populate X-Forwarded-For, so any website that wants to audit the IP address of an end user now has to read this untrusted header.

So devs will realise this, look at the header, stop stripping it at the edge, and start trusting what is essentially a string that anyone can set.

I like the way IRC networks handle this, they use a pre-connection protocol verb called WEBIRC (de-facto standard documented here: http://git.io/vBLYp) that also enforces a whitelist of ip address + password combination. This stops most abuse of this feature. Maybe HTTP servers should have something similar.

> How many years ago was the Dell shopping cart bug (where a client could alter the price of an order)?

Sounds like every third-party shopping cart I've ever looked at except FoxyCart, and even then this behavior is the default.

(I've heard people refer to this as "that bug shopping carts have." It seems people overwhelmingly prefer catching this with "fraud detection".)

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.

Yes, it's really unreasonable.

Bloated beauracracies need agile ways to respond to important situations. Giving them a pass because they are bloated won't make that happen any sooner, and it does need to happen.

Organizations like that have no code hygiene. They have smart talented people that are entrenched in their way of doing things. They don't have the money to throw the code away and start over. They don't have the control to enforce code standards. There are a couple of terrible effects that slow them down.

I'll bet you a nickel that the json is generated by a stored procedure. In that kind of environment, you can't really run a local version of the system. if you're lucky there's a prod, qa, and development version. the development version is shared by everybody.

What winds up happening is the dev system has lots of in-progress stuff, and i can't release my stuff till the other in-progress stuff is ready to go, or is rolled back.

Also high priority stuff tends to go to "that one wizard guy". Unfortunately that one wizard guy is backed up with 6 months of other projects, cause he's the wizard.

Is it "right"? no, of course not. These systems evolve from people making good decisions in the moment, that don't really take into account the global state of the system.

Finally, every few years a new CIO comes into power and wants to clean things up. a few new folks buy in, but the older entrenched interests just pay lip service, because they know the only way to actually get software out the door is to do it their way. (They tried and were burned by at least one of the prior CIO approaches)

I think those organizations are pretty screwed. they are incapable of change at the layer they need. Banks, schools, airlines, machine shops, anyplace there's a large sized in house dev team (30+), that team is going to very likely kind of suck. There are exceptions, but generally, it's a rough state.

So, yes, i agree, but actually solving that problem in a way that won't kill the business is incredibly hard.

When these problems affect the bottom line in obvious ways, they get fixed quick. We shouldn't give them a pass just because they are large because that one wizard guy is required, and security problems need to go to the top of his pile, not somewhere in the middle or at the end.

I'm not saying these companies need to magically become less bloated, but they do need fix security problems with the urgency they require. If that means that we all need to make a stink so it starts actually seeming important to them, then so be it. Another way to look at this is that they've reaped the benefit of having a web presence for years, but haven't had to pay some of the associated costs (since they apparently don't have the internal structure in place to review and/or fix these problems). In that respect, they've been playing the odds for a long time and come out ahead (wittingly or not), but that doesn't mean they don't need to pay up when it bites them in the ass.

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 storing ZIP backups of source code on a network server).

3. Their issue tracking system is an excel sheet on a shared drive.

4. 75%+ of the code was written by someone not currently working for the company. 10%+ of the code is considered "untouchable" because it works and nobody remaining knows how it works.

5. Compiling the final executable takes more than 1 manual step, resulting in screens full of compiler warnings.

6. Management is resistant to any effort to fix any of the above because software is a COST and not an investment.

(EDITed because I can't seem to count to 6)

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.

Yes. Any change from the norm can be pointed to add a reason for failure/delay/cost overrun. There needs to be management buy-in and possibly even requirements for projects to reverse this inertia.

Which is why there needs to be pressure on management.

The mentality is: typing in code = assembling the widget, while setting up source control and an issue tracker = decorating the assembly line.

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?

Yes. See "The Phoenix Project" (book)

Basically it is all the result of aa long series of shortsighted "business decisions" based on simply doing whatever costs the least or brings the least short-term risk at the given time.

Well, having worked on applications like this, I think it's not totally unreasonable. Of course, could it have been done earlier? Yes. But the backend systems of such applications are usually so complicated and with ripple effects through layers that it takes quite a lot of planning to get it right.

I am not saying delaying a critical vulnerability patch for 6 months is right, but I think airline systems will typically need that much time to plan it well.

Let's rephrase your question: "Is six months really unreasonable for an airline to fix a vulnerability that allows customer data to be stolen?"

Yes, I would say so.. especially since this is a 'duplicate' meaning that multiple people were already aware of this, and on top of that it seems the only reason it was eventually fixed was because they couldn't delay fixing the problem any more.

I don't think anyone would consider this reasonable.

Which makes you wonder if person #3 or higher submitting this bug couldn't sell it since they are not getting a bounty. Six months is a long time to leak customer information.

If 3 different whitehats found the same bug independently, it's fairly sure bet that a number of blackhats are already exploiting it.

My point is that BigBureaucracy likely considers it reasonable. In fact, my bet is that an engineering manager in whatever software team deployed this fix is getting at least an 'attaboy' for what his management sees as a lightning fast fix.

If they were genuinely behind on patching vulnerabilities, I can sort-of understand.

Then again, how hard is it for a company of their size to hire some 1099's for a brief time...

About 10 years ago everyone got super sensitive with regards to airline security. So you problem couldn't just let a bunch of craigslist temps come in and apply some patches working on the live system.

I think the guys over at US could work a bit faster, but I will grant them they aren't exactly in an unregulated industry where they can "challenge the status quo". When kalanick bears down on the red tape, people aren't reminded that taxis were the attack vector of America's biggest security event.

But yeah, out-source it to one of the hundred or so DoD contractors or security professionals allowed to work on something like this, it likely wasn't that big of a job to patch that vuln.

He should have worded 'tech savvy terrorists' in his request and the result would have been much different.

Do you think only the good guys got into this?

Of course not, but United knows this too. It is possible that United is better at dealing with fraud than at dealing with software issues. It probably costs less to fix the infrequent fallout from exploits than to fix the actual software. The threat of public disclosure changes that calculation (infrequent -> frequent), and then the software fix becomes cheaper.

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

> an IT department whose bread and butter IS releasing software.

I don't think you've dealt with UA much...

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.

Which reminds me of when I reported 768-bit DHE on a Nest server to Google security. Original bug was https://bugzilla.mozilla.org/show_bug.cgi?id=1170833 . They fixed it in only a few days, but in the meantime they tweeted this: https://twitter.com/nestsupport/status/606246459822997505 (at that time the Firefox version that was broken was not even in the release channel!)

The only reason for "reasonable disclosure" deadlines like these is a tradeoff between 1) damage done by disclosing before patch available and 2) damage done by evil actors finding the same bug before disclosure & patch, the assumption being that disclosure will speed up patching.

On the bug difficulty totem pole, this one hangs rather low. Hell, they even claimed it was a duplicate report.

I'm surprised the newspaper didn't run the story anyways, because on a data leak bug like this the work isn't done when you patched the original problem, only when you have combed through all the application logs, identified malicious requests and notified customers and authorities of possible leaks can you claim to have dealt with the issue at hand.

(Yes, if your app server isn't logging all requests, you should probably start today, otherwise you end up like the NSA when Snowden took off and you first learn of lost data when it appears in a newspaper)

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.

I think bug disclosure should be based on how dangerous it is, not how fast/slow the company is in fixing it. The attackers won't work on the company's own schedule after all.

> Is six months really unreasonable for a big bloated bureaucracy like United Airlines?

It's unreasonable for anyone, no matter how big and bureaucratic they are. The fact that they're bloated and incompetent doesn't excuse their incompetence.

I reported 2 admittedly minor web security bugs to them several months back that surprisingly I was apparently the first to report, but still haven't heard back about either.

Mine was a duplicate as well. Anyone here who was paid out?

Yes

Yes.

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.

Just checked this using mitmproxy. My United MileagePlus Account is definitely there.

Also, you need a valid MP#, and the # is not sequential (nor all numbers).

At least they're using https.

Edit: Also annoying the app keeps making calls to Gogo wifi and some other Wifi page.

Edit2: I just realized United _did_ fix it. Thought it said they refused to fix it.

It's so funny to see how surprised people are about the "corp" IT compared to the "free" IT world. Once I was also surprised about how long it takes and that very important things can be out of scope.

I think the reason is that in fact in teams >10 people nobody really knows what's going on. That anything happens is more the result of many attempts and some luck. That nothing succeeds is the default.

Think of it more as "Twitch Programs Flight Ticketmanager App" than actual software development as you read it in a book. (I once worked with >5 other guys on getting a string in one computer pointing to another computer, took the whole week)

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

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

Have you participated in a bug bounty program on Hacker One? We are running one there now.

> Using just these two values, an attacker could completely manage any aspect of a flight reservation using United’s website.

Don't most airline websites allow that when you get the last name and date of departure right?

Yes. But the point is that he was able to gain these two bits of information.

Classic case of confused deputies caused by ambient authority. Wonder if we'll ever outlive these kinds of bugs.

Reply on news.ycombinator.com