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

Hacking the largest airline and hotel rewards platform (2023)

samcurry.net

Post reply on HN
Print view View original

91–100 of 122 posts

Re: Hacking the largest airline and hotel rewards platform (2023)

#91

Post by astura »

bankcust08385 wrote: post #22
xnorswap wrote: post #19

Earlier quoted context omitted.

This is way more common than you'd like, here's a scenario where it can happen even without outright incompetence: Someone (or some AI) copies an example auth implementation from stackoverflow. Being sensible they realise they shouldn't put key material in source code either, so they leave "secret" in place, and pop a ticket in JIRA to update with the key material from the vault before it goes live. Employee falls il…

Tragedy of the Commons often happens where there are too many developers and unclear functional or concerns ownership. Each concern needs a home, a checklist, a runbook, documentation, a support escalation path, and responsible tech or business owners.

You should actually read Garrett Hardin's influential essay you are referencing before referencing it again. It's freely available from his estate at https://www.garretthardinsociety.org/articles/art_tragedy_of...

Because it doesn't say what you seem to think it does.

Re: Hacking the largest airline and hotel rewards platform (2023)

#92

Post by fragmede »

udev4096 wrote: post #81
toyg wrote: post #46

Earlier quoted context omitted.

Why? One depends on development practices, the other on security-team practices. You can have a team of donkeys building a product and the sharpest hackers guarding it. Ideally best practices would trickle down, but that's not a given.

Why would anyone even use such a predictable word for dev environment? I am baffled by this practice of not following the bare minimum security mindset even when you are just running it in a dev environment

Because it's dev. Does your bathroom door have a deadbolt and a key and you lock it firmly every single time when you're home alone?

Re: Hacking the largest airline and hotel rewards platform (2023)

#93

Post by fragmede »

simondotau wrote: post #61
bogtog wrote: post #59

Is taking the website offline really necessary? If the vulnerability has been there for 1 year or so already, what harm does it being there for 1 year and an hour do? Also, maybe it's not clear to me exactly what is getting taken down, but I'm amazed that the chain from "person reading email" to "person that is permitted to take down the website" moves so quickly (or that the latter right is given so low in the hiera…

Given the real money involved, keeping it online with this flaw in place isn’t an option.

The optimal amount of fraud is non-zero. https://www.bitsaboutmoney.com/archive/optimal-amount-of-fra...

Re: Hacking the largest airline and hotel rewards platform (2023)

#94

Post by ramses0 »

rootsudo wrote: post #50
klausa wrote: post #11

Earlier quoted context omitted.

A lot of the knowledge is very arcane, and like, split over hundreds and thousands of flyertalk.com pages, and like... institutional knowledge of more clever travel agents. I think a lot of the "fun" that can potentially be had also requires a direct access to a GDS, which, AFAICT is on the order of ~$10k a year? And if your "tricks" are discovered, airlines have a direct way to demand payment for any shenanigans you…

Correct, it's very arcane knowledge. Revenue manager of any, every airline will catch up to you but some of them are nice. Many are not. :) Direct access to an GDS can also come way of an OTA, which, may not sanitize input properly, or if you learn how bulk purchasing of tickets happen (e.g. if airline is sold out, but it still shows/bookable by an OTA they have access to bulk ticket fares and can sell - sometimes fl…

...to demystify some of what's being said:

Imagine buyFlights.php?bash="cp+foo+bar;mv+bar+baz;etc..."

Then imagine: buyFlights.php?sabre="1DFWSFO12JAN23FEB+etc..."

If you've ever seen your passenger name come back as ALL UPPERCASE, it's likely been washed through the methuselah of systems, and those systems have lots of internal quirks and commands that may let you do things like switch seats, add a car, drop a passenger, change your meal preference, etc.

"some/many ecomm front ends are really bad and you can do stuff you shouldn't"

...if you pay attention to what's going on "in the system", if there's an unprotected endpoint where you can say "LUNCH=vegetarian&&btw-duplicate-this-flight-then-cancel-and-issue-a-refund-in-cash", that's (sometimes) the level of badness in the different systems.

Historically: SABRE was a spinoff of AA and one of the first real database / computer / IT companies. EaasySabre (ca: 1986!?!!) was one of the first "credit card over modem" applications (eg: on Prodigy!) - https://www.travelweekly.com/Travel-News/Travel-Technology/S...

...lots of opportunity for "legacy" bugs hiding there.

Re: Hacking the largest airline and hotel rewards platform (2023)

#95

Post by kredd »

grecy wrote: post #52
sangeeth96 wrote: post #39

I've always felt most such rewards program portals and apps were more hack-jobs than serious applications and thus, would be riddled with issues like these. I'm from India and I see many of these sites come and go all the time but not a single one has inspired confidence in me about keeping my data safe. For example, even the topmost cards here (HDFC Diners/Infinia) have a shoddy website, mostly a reskinned version o…

> I've always felt most such rewards program portals and apps were more hack-jobs than serious applications It’s easy to figure out which way any system goes. Does it generate revenue or cost money? The former will be a serious application, the latter a hack job

Just did a mental test of this theory through past projects I’ve consulted for, and it seemed the opposite. I’ve seen hack jobs generating about $1M/day, as a second product of the company. And seen very mature serious applications barely breaking even.

Re: Hacking the largest airline and hotel rewards platform (2023)

#98

Post by Normal_gaussian »

fragmede wrote: post #92
udev4096 wrote: post #81

Earlier quoted context omitted.

Why would anyone even use such a predictable word for dev environment? I am baffled by this practice of not following the bare minimum security mindset even when you are just running it in a dev environment

Because it's dev. Does your bathroom door have a deadbolt and a key and you lock it firmly every single time when you're home alone?

Whilst you are being facetious, deadbolting a bathroom door is really really dangerous.

Bathrooms have a high risk of life threatening accidents and any locks should be bypassable indicators - this is why most have a coin unlock on the outside.

Many countries have regulations requiring bathrooms to be unlockable from the outside without a key, and the external doors to be unlockable from the inside without a key.

Deadbolting a bathroom is also pointless - there is nothing ti protect.

Using an effective password for dev environments is sensible; it holds no risk of meaningful loss and can prevent compromise due to a common mistake.

Re: Hacking the largest airline and hotel rewards platform (2023)

#99

Post by 8organicbits »

switch007 wrote: post #67
junto wrote: post #6

> On May 2nd, 2023, we identified that the Flask session secret for the points.com global administration website used to manage all airline tenant and customer accounts was the word "secret". After discovering this vulnerability, we were able to resign our session cookies with full super administrator permissions. Seriously?

Makes you wonder if there a colleague who wanted to use Django with the biggest "I told you so" grin right now

For anyone unfamiliar with Django:

> django-admin startproject automatically adds a randomly-generated SECRET_KEY to each new project

https://docs.djangoproject.com/en/dev/ref/settings/#secret-k...

Re: Hacking the largest airline and hotel rewards platform (2023)

#100

Post by mywacaday »

remus wrote: post #38
alwa wrote: post #3

I’m really impressed at the number of times they say their counterparts responded to their report in under an hour, immediately took the affected site offline, then resolved the issue quickly. That seems like an enviable operation.

It's a strange disconnect between the quality of the incident response and the extremely basic nature of many of the bugs reported. I mean SECRET_KEY='secret'?! Seriously straightforward stuff.

I don't know if points.com was a startup at some stage with a build fast fix later attitude, I wonder if a lot of startups are in the same boat.
Post reply on HN