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.
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?
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...
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.
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...
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.
It's a $20k bounty for simply taking a cookie that a HackerOne employee accidentally pasted when responding to a different vuln report on HackerOne.
The tech in the travel industry is cursed, and the pay is bad. Do not recommend.
Because it doesn't say what you seem to think it does.
There are businesses where if you suffer a theft, you shut everything down and run a stocktake. For example, an arms dealer. And there are times credit card providers shut down - because there is a known vulnerability, and they have to immediately mitigate, or lose their insurance.
You could do but it's a pretty risky way to run a business. Obviously the real world often gets in the way, but a competent manager would look at that org structure and say "shouldn't we move some of those smart ppl on to the build team to catch issues before they're in prod? Seems awfully risky waiting until it's live to catch these bugs which could cause us massive financial harm"
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.
I have been able to save USD 500 with a VPN (booked Aeroflot ticket advertised on Russian google with a Russian IP). I am able to read a little bit Cyrillic so I was able to go through the booking. Citibank then blocked my CC and called me. Did everything again and got the ticket for USD 1000 instead of USD 1500.
Good experience with switching languages on sites. I was able to buy tickets 80% discounted by switching from English to the native language.
"blogs" ruined a lot of tricks and fun for some; but my understanding from observing the FT thread is that there are still people involved, just on a much smaller scale.
Bullet train tickets in Germany are expensive. You were able to buy them online in the Czech Republic for a fraction of the price. Like Prague->Brussels 20 Euro. You don't have to use the whole ticket, you boarded in Frankfurt and went to Brussels for 20 Euro.
Gone....
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 flights close out on the airline but are bookable to last minute on OTA as well.)
Flyertalk is a great resource, and also, surprisngly the reason why Whatsapp was created too! - But I wasn't being indicitive of that and knowing what a fare code/y/j/whatever class fare is - I meant that sabre/amadeus and the front end of the airline are really "broken", and you can do similar things to what the original article posted, even abusive things like "walk" for tickets to refund to an airline hosted "Wallet" (usually you can attach a PNR and reuse it and rebook a new PNR/Ticket) which can break the chain and require someone at revenue management to really pull the log for that coupon/PNR to see where the money went, or why someone else flew that segment.
You can also double refund - and of course the airline can clawback - if they find out in time. Though many airlines have special gateway relationships w/ banks (as noted by the point system tied to a credit card network) (But this comes down as general fraud.)
The fuel dumping community isn't the only one, the reason they are unfriendly to newcomers is because they think they got a neat trick and they do, and once it hits front page news, that fare/date is dead. But there are other communities similar too - there is the staff travel/non revenue community which flies for free*, buddy passes, companion passes or on Zed90 tickets which is standby travel on OAL, other airlines (though you need to be listed/included on someones benefits.) and travel industry IATA or something - and thats the thing, if you can get access to a GDS and encode fares you may be able to list yourself but these aren't normally commercial fares, but I've seen many times a GDS spit out wrong class, class mismatch, fare/class mismatch, etc that wouldn't be a mistake fare per se, but a misconfiguration or a unsantized input that did this :)
But also, some GDS's are also nto that locked up, you can find some on shodan if you know the right keywords and literally poll someones name to see if they have any active flights, etc. I'm not encouring anyone to go find them, but if you know what to look for, there are many insecure or generally not behind any login page that opens up to a general query and allows reservations and confirmed commercial fares - but that falls down to just poor IT security operations in general vs GDS flaw.
tl;dr All Airlines front end/ecomm site talks to it's own GDS which are cloud hosted but act like 90's shell programs, some/many ecomm front ends are really bad and you can do stuff you shouldn't. It all comes down to your identity and is all tracable which is why many of these flaws still exist, because it's enforcable the other way/tech debt to fix is too much.
And we haven't even got into SSR codes, OSI codes, etc
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.
Do not trust the data you send to a user, to remain secure.
> Deadbolting a bathroom is also pointless - there is nothing to protect.
Pedantically, many people keep medicines in their bathroom and if you happen to have any recreationally-usable drugs, they'd be one of the first things to go in a lot of robberies. Or, sadly, be taken by your teenager or seemed-to-be-normal friend.
Security through obscurity is allowing REST commands to the /totallysecretaddress/neverleaked/ URI.
Please stop.
> By default flask doesnt have a db.