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

31–40 of 80 posts

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

#31

Post by ryandrake »

jfoutz wrote: post #18
kbenson wrote: post #10

Earlier quoted context omitted.

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 r…

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)

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

#32

Post by jfoutz »

ryandrake wrote: post #31
jfoutz wrote: post #18

Earlier quoted context omitted.

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 r…

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.

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

#33

Post by ryandrake »

jacquesm wrote: post #14
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.

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.

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

#35

Post by kbenson »

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.

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.

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

#36

Post by ryandrake »

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.

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

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

#38

Post by tptacek »

[deleted] wrote: post #20
jacquesm wrote: post #2

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.

[deleted]

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.

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

#39

Post by throwaway28474 »

jacquesm wrote: post #21
[deleted] wrote: post #20

Earlier quoted context omitted.

[deleted]

You may as well give them an 'fix this or else I go public' with a reasonable deadline then. That's in everybody's interest.

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?
Post reply on HN