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.
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?
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.
It sounds like they are disqualified from receiving any rewards any time in the future.
But other than that, there is nothing preventing you from revealing the vulnerability, or worse, selling it on the grey market. The US government is a heavy buyer of vulnerabilities (although usually in applications, not in airline websites).
Why are you looking for off-site vulnerabilities? Would this be something you did even if they weren't running a bounty?
You should be careful testing sites out of scope. The bounty gives you implied permission to test for vulnerabilities on sites in-scope, but "I was just security testing" is demonstrably not sufficient to insulate you from civil litigation or even criminal charges --- you would probably win in court, but it would be ruinously expensive.
What are your thoughts on the bug bounties that have extremely limited scopes, considering the in-scope domains typically rely on the out-of-scope parts?
They are not explicit in what domains or ip addresses are in scope. This makes it difficult. You'd expect them to have a list of approved sites for testing.. But they don't (or didn't when I tested.)
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).
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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)
79 comments
[ 3.7 ms ] story [ 137 ms ] threadThis 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.
Blackmail is one of those rare crimes that consist entirely of legal conduct.
But other than that, there is nothing preventing you from revealing the vulnerability, or worse, selling it on the grey market. The US government is a heavy buyer of vulnerabilities (although usually in applications, not in airline websites).
You should be careful testing sites out of scope. The bounty gives you implied permission to test for vulnerabilities on sites in-scope, but "I was just security testing" is demonstrably not sufficient to insulate you from civil litigation or even criminal charges --- you would probably win in court, but it would be ruinously expensive.
I agree that United's attitude on this is silly.
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.
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.
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)
It's just so damn hard to get people to change.
Which is why there needs to be pressure on management.
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.
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.
Then again, how hard is it for a company of their size to hire some 1099's for a brief time...
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.
it's not pilots and flight attendants coding that application. they've got an IT department whose bread and butter IS releasing software.
I don't think you've dealt with UA much...
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)
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.
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.
Not sure what to do by now.
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.
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...
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.
I have similar problem with one of the Salesforce's subdomains. Report accepted and assigned status low. 7 months later XSS is still there.
Not sure what to do by now.
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.
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.
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".)
Don't most airline websites allow that when you get the last name and date of departure right?
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)