That seems like an enviable operation.
There’s a lot that has to go into fixing things on such a tight timeline too:
- oncall-level alerting for your security.txt inbox - your oncall needs to either be someone who can actually take corrective action on the system in question (not easy in a large company!) or able to route the issue to the right team - the service owners need to be empowered to treat security with the appropriate severity (taking the site down so quickly speaks highly to this)
Hats off to the points.com team. With any luck, this post doesn’t get too much traction and y’all won’t get flooded with bounty beggar spam.
Maybe the terminology is different in your company, but my employer has an 'operations' team which has several shifts of workers, who look after things that need 24/7 monitoring. They then triage and escalate as appropriate.
That's who you'd have monitoring the security inbox, if you want round-the-clock monitoring, so nobody's getting woken several times a night by spam.
> Before we could even finish sending our report or see if other endpoints were accessible (e.g. adding points to a customer rewards account), the points.com team had detected our testing and had completely shut down United's production points.com website. Bummer!
If not, they are quick to bash you publicly.
There’s too much hubris in the “professional” web app bug hunter community.
Generally, their attitude is very “look at these stupid developers,” “developers suck at security,” or “a conspiracy is happening because company X didn’t take their app down within 10 minutes of getting my email.” It’s much more nuanced than that.
I’d like to see:
1) more bounties and better paid bounties
2) less ego and much more professionalism and patience from “researchers”
Both would be better for consumers.
I wonder if there's an attack vector hiding where you induce a malicious bug via an illegitimate bounty and the developers' bias against inaction.
And I'm not just hand-waving here cause there are many forums that discuss taking advantage of their bad implementations to maximize returns. Even when one eventually gets patched, another springs up.
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
(Obviously this doesn’t lessen the impact of vulnerabilities that allow malicious actors to charge you, steal your points, amend your bookings, or access your travel data in real time. But for read-only queries, an attacker won’t get much more access than a paying partner of the program could get.)
I would say if you wanted to generate "free" flights, which is entirely possible, learn how GDS works and the workflow for a ticket purchase and how a coupon is attached ;) but that would probably be going to far then just normal poking and secure disclosure but there is enough techdebt that if you know how one airline processes a ticket, it will work on quite a few other too!
You can also do very tricky things too that would process as normal for a majority of airlines too - event though most airlines may fall onto amadeus/sabre, you'd be surprised (or not really) at the front end that will allow almost anything - and "farecodes" that could rewrite a ticket which have been exposed to customer facing endpoints that are best verified, with only an active PNR.
Then again, I do recall a famous post on here about australian politician and someone jusing using view source to verify a quantas ticket.
https://mango.pdf.zone/finding-former-australian-prime-minis...
No "view source" level hackery, but presumably what you're referring to.
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've pulled (ADM, https://www.ana.co.jp/businesspartners/en/admacm-policy/). But perhaps OP had something different in mind, I'm curious myself now :P
If you wanna really go off the deep end, try looking into "fuel dumping" community — there's a small group of people who basically have figured out a series of bugs in how fares are coded (that lets them buy flights much cheaper then intended).
They use (very dumb) coded language to talk about their "findings", and are very very very unfriendly to newcomers; but it's a fascinating world to observe.
The problem is that they gift them to you instead of what you might get from a credit card rewards program. You end up having to pay a 2% tax on the total amount in points (at least in the US).
When I made the calculations, I am actually paying more in taxes on the points than if I just paid for the flights myself. They end up being almost completely worthless.
Just like you don't shut down your store if someone stole some merchandise or how credit cards just factor fraud into the fees.
Seriously?
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 ill, everything gets re-assigned. Leaves before it gets actioned and that ticket slips through the cracks, with the person taking over their duties not realising how serious "J10243: Populate secret from key vault" actually is, perhaps assuming it's currently coming from a different configuration location.
There's little chance that the regular testing are discovering the flaw as the key gen based on "secret" goes live.
Their password? "internet"
I sent them an email showing them their vulns. I never followed up to see if they did anything about it.
[0] they had a forum that allowed profile pic uploads but it didn't check they were images, so I crafted an ASP page which emulated a file explorer and uploaded that, then browsed to it.
> This is implemented on top of cookies for you and signs the cookies cryptographically. What this means is that the user could look at the contents of your cookie but not modify it, unless they know the secret key used for signing.
> django-admin startproject automatically adds a randomly-generated SECRET_KEY to each new project
https://docs.djangoproject.com/en/dev/ref/settings/#secret-k...
https://newsroom.bmo.com/2023-03-10-BMO-Confirms-Agreement-t...
Reading about directory traversal in 2023-2024 is like a blast from the past.
Once upon a time, I ran ypcat passwd and piped it into John the Ripper on the CompSci Linux cluster at one of the University of California campuses. Within 90s, I had amassed passwords of over 40 users including several lecturers and a tenured professor. The CS IT shop's mistake was running NIS+ rather than something like LDAP + Kerberos.
Edit: ... god
The username is Cyril Figgis.
The kicker is that your PNR number and surname are encoded in the barcode on your boarding pass, easily scannable with a phone app. If you ever post a boarding pass online you're unintentionally doxxing yourself and potentially letting people screw with your flights.
I've seen celebrities do this, and during the Cloudstrike outage one tech CEO posted his handwritten boarding pass on Twitter with the PNR in full view.
https://krebsonsecurity.com/2017/08/why-its-still-a-bad-idea...
PNR identifier and last name is the only reasonable key to use when a single PNR is meant to be shared among the GDS, the IT provider, the traveler and companions, hotels, car rentals companies, travel agencies and countless other players in the market (sometimes several of each at the same time).
But it's also true it relies on the traveler keeping the PNR reference secret.
Adding MFA would involve adding new segments to all sorts of EDI messages, more complex booking/ticketing/cancelling flows, and getting all those companies on the same page so shit works without impact.
It'd be possible and an impressive engineering effort, but also a royal PITA given all the moving parts in the travel industry.
The few times I had to cancel/rebook or similar I was next to the counter with my ID, but I can think that having people call you and/or send an email for you to click to confirm is easier and has less friction than revamping the whole GDS industry and their (ducks) legacy B2B interoperation.
I imagine this is the sort of thing that makes these stay so open. If my flight is cancelled and rebooked with a partner, but my id says "Last-Name" and my boarding pass says "LastName" and for some reason I'm in the system as just "Name," then it's really nice the I can still make it on my next flight departing in 10 minutes.
But... if I'm logged in via user/pass... why would this notion of 'view your itinerary' NOT be available? What security benefit is there? None as far as I could see.
Implementing a "secure" connection here would be a sure road for pain ahead, at least it would need the airplane company to increase customer support a lot, and likely a lot of bad publicity every time something fails. Delays cost money, especially in this industry. And what would you get for that? The safety that, if you publish a picture of your reservation / boarding pass online, nobody can log in with your credentials and cancel your flight? That's a rather niche and very targeted risk, which is better handled by a single customer support agent who, simply, issues you a new ticket.
(by the way, by the time you have checked in and your boarding pass has been issued, a lot of companies just don't allow you to cancel anymore, so it's really a non-issue?)
Which companies have a cancellation policy that is contingent upon getting a boarding pass? I've cancelled checked-in tickets before. If the flight is operated by a different airline than the ticket issuer, you just have to call the operating airline first to undo the check-in (a few airline can even do this online). After that it should be possible to cancel the ticket by the ticket issuer without any problems.
