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.
Seriously! I actually can’t think of any openly documented security incident with such impressive remediation timelines.
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.
> - oncall-level alerting for your security.txt inbox
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.
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.
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.
> You can have a team of donkeys building a product and the sharpest hackers guarding it.
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"
From experience, a lot of talent security people really just don’t want to be developers, even if they’re good at it. It’s not always as simple as shuffling people around between teams.
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
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.
I guess I should go check if I can unlock my (regular lock) bathroom door from outside!
> 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.
No, but the bathroom does have a lock that can be used from the inside. Not a door that has a window in it and a lock that can be controlled from both sides of the door.
Makes me wonder if they (points.com) have some key-word alerts on incoming emails. I know for sure that at some companies, this would have taken hours (to days!) to detect, if the tip had come through a regular info@ or contact@ inbox.
The article mentions a security.txt[1] which doesn't seem to contain an email address but it does contain a link[2] to a disclosure program, I'm guessing that's how they submitted all their findings?
It seems they reacted before the team even sent over a report in one case:
> 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!
You almost have to pull the site to stroke bounty hunter egos when you could just push a change to prod instead.
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”
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 of their generic rewards platform/partner.
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.
> 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.
The whole point of these rewards programs is to share your data (bookings, itineraries, employment, email, travel class, etc.) with as many partners as possible. So at the end of the day, a data leak is only marginally worse than the expected behavior.
(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.)
Fun read! So close to unlimited point generation and process tickets for those fancy flights~
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.
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'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.
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.
Fuel dumping is probably a much smaller deal then it was a few years back!
"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.
Enjoy while it last. Some Idiot always has to make a blog post to collect some ad revenue or some attention. People don't understand that you can only use a loophole, if few people know about it.
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.
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
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.
It's interesting United Airlines is mentioned here. I am a security researcher and found vulnerabilities through the United Airlines bug bounty program last year. They pay you in miles instead of money.
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.
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 hierarchy).
It is a very real option. If it's not being exploited by hundreds of people right now and you make more money keeping the site up vs. what you lose in "fraud" it makes sense to keep it running.
Just like you don't shut down your store if someone stole some merchandise or how credit cards just factor fraud into the fees.
It's often a violation of both government laws and insurance contracts, if you knowingly expose that much financial information to a proven vulnerability.
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.
Ok, but shutting down the website because of legal/moral responsibility to protect customer info is very different than doing so because of the “real money involved”, which is what commenter dewey was responding to. You can choose to just take the fraud cost hit in the latter case.
That's why people aim for the legal costs to be commensurate with the possible gain they will miss out on. Many corporate penalties are small enough that mathematically, it's absolutely worth simply breaking the law all the time.
I don't think this is a good analogy. It's more like you find that the lock on your stores front door has been broken for a long time and you just hadn't noticed. Nobody has broken in yet, but could at any moment. Also, it's not just your goods and business that are at risk, instead you're responsible for the protection of things that belong to other people.
> 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.
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 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.
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 are redefining "tragedy of the commons" there... TOTC is about overusing shared resources (e.g. too many people helping themselves to a shared plate of food), not about confusing who should do what.
When I was in my greyhat days I gained admin access[0] to a very big IIS web hosting provider. After spending a day trawling through their file system I found the actual admin password for their servers in a file. I tested it via their open RDP port. It worked.
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.
Also why would anyone store and read data like { 'groups': [...] } on the client-side?
Session cookies are supposed to be identifiers only, with the data stored server-side.
By default sessions in Flask are stored in plaintext:
> 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.
That's precisely why the cookie should just be an identifier, that you look up group info from the database. Because you can guarantee the cookie contents will be modified by someone at some point. Make it useful to you, useless to them.
Or if you can bruteforce the secret, or if there's a vulnerability in the secret, or if... You're relying on the fact that the cryptography will be impregnable, rather than adopting an actual security posture.
Do not trust the data you send to a user, to remain secure.
No. It's relying on both cryptography, and the inaccessiblity of information. Which is a tried, practiced, and often federally mandated, method of security. Controlling who has access to information is sorta security 101. Don't dump your database to the Internet.
Security through obscurity is allowing REST commands to the /totallysecretaddress/neverleaked/ URI.
It's so funny to me, this is normally read aloud as "security vulnerabilities disclosed after patching" but in reality this is a natural part of how software is made. You make compromises. Terrible ones. Security ones. In the beginning. Not always, but some places, some applications, some websites, some languages, sometimes you make some concessions for sake of simplicity or prototyping or proof-of-concept'ing that ends up making it all the way to prod. And then these "vulnerabilities" are really things that mean your company grew way faster than you anticipated, and lucky for you some ethical hackers "exploited" these concessions, first.
Does anyone know what sort of market share points.com has in this space? It's always interesting to spot correlations between market fragility and a lack of competition (as in the case of the recent Crowdstrike and CDK Global outages).
There was nothing abrupt about the Air Miles bankruptcy, they'd been in long-term decline and had lost nearly all of their major partners by that point. I called the BMO purchase months before it happened.
Insane vulnerabilities. The massive mismatches between authentication and authorization scopes are crazy. Encrypting data with "secret" as the key is also a facepalm.
Someone didn't bother reading my carefully prepared memo on commonly-used passwords. Now, then, as I so meticulously pointed out, the four most-used passwords are: love, sex, secret, and...
Ages ago I was tasked with migrating a site for a famous workout instructor. I noticed they stored passwords in plain text. His along with a shocking number of user accounts all used just his first name as the password.
So would your holiness care to change her password?
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.
This is only tangentially related but it always blows my mind how insecure airline booking portals are. For many (most?) airlines all you need is the booking reference (PNR number) and surname to log in and see flight itinerary, contact details and, in some cases, change or cancel the booking. No password or MFA needed.
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.
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.
You can only imagine the pain of having a "-" in your last name, when some documents accept spaces but not hyphens, and some accept hyphens but not spaces, and some accept neither, and some require other identifying documents to match each other...
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.
It's worse with some. A recent trip had me create an account with an airline - I can log in and see my trips, points, name, etc... but to see the itinerary, I have to have the PNR number, which isn't anywhere in the authenticated portal area. It's only delivered by email, once AFIACT. I thought I'd lost it at first - couldn't find it for a while (went to spam apparently).
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.
I know this is HN and here it's not a popular opinion, but maximum security is _not_ always a good idea. Even setting aside the problem of many different actors having to access these details mentioned below, there's value in a simple login process. Specifically for airplane tickets, the most common ones I had to struggle with multiple times are retrieving reservations bought from a different computer, or by a travel agency. In all these situations, it was exactly the simple approach that saved me. If 2FA was mandatory, the best case scenario was that the travel agency would have to send you a separate e-mail with details about how to access their portal where this 2FA would somehow work. The number of systems multiplies, the number of credentials to remember does, as well. If you are not from your usual workplace (and chances are, if you are travelling, you are not) or from a shaky connection (same), you are in a real problem. In a time-critical scenario, which makes it really worse.
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?)
> (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.
Maybe it was after boarding the flight? I still find it convenient . It's not that hard to keep the PNR number and surname. The reason it's so open is that there's an Identity check at the next stage where you can't use them if you're faking.
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.
Seriously! I actually can’t think of any openly documented security incident with such impressive remediation timelines.
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.
> - oncall-level alerting for your security.txt inbox
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.
We call that guy grafana alerts at ours
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.
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.
> You can have a team of donkeys building a product and the sharpest hackers guarding it.
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"
From experience, a lot of talent security people really just don’t want to be developers, even if they’re good at it. It’s not always as simple as shuffling people around between teams.
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.
I guess I should go check if I can unlock my (regular lock) bathroom door from outside!
> 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.
I guess medicine storage is an interesting cultural thing - I've always known them to be stored in the kitchen!
No, but the bathroom does have a lock that can be used from the inside. Not a door that has a window in it and a lock that can be controlled from both sides of the door.
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.
Makes me wonder if they (points.com) have some key-word alerts on incoming emails. I know for sure that at some companies, this would have taken hours (to days!) to detect, if the tip had come through a regular info@ or contact@ inbox.
The article mentions a security.txt[1] which doesn't seem to contain an email address but it does contain a link[2] to a disclosure program, I'm guessing that's how they submitted all their findings?
[1] https://www.points.com/.well-known/security.txt
[2] https://bugcrowd.com/plusgrade-vdp-pro
It seems they reacted before the team even sent over a report in one case:
> 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!
You almost have to pull the site to stroke bounty hunter egos when you could just push a change to prod instead.
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.
> when you could just push a change to prod instead.
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.
How about this one: https://hackerone.com/reports/745324
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.
100%, hacking is as much technical prowess as it is social engineering.
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 of their generic rewards platform/partner.
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.
> 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.
This makes sense because a hack job that generates money is more likely to stay online than a hack job that makes no money.
The whole point of these rewards programs is to share your data (bookings, itineraries, employment, email, travel class, etc.) with as many partners as possible. So at the end of the day, a data leak is only marginally worse than the expected behavior.
(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.)
Fun read! So close to unlimited point generation and process tickets for those fancy flights~
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.
> 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.
The researcher also told this story on DarkNet Diaries Ep 84, “Jet-Setters.” It’s worth a listen.
"Right click > Inspect Element, all you need to subvert the Commonwealth of Australia"
Can you provide a link or two so one could read up on what you've mentioned in your post?
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'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.
I thought fuel dumping is a thing from the past?
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.
Fuel dumping is probably a much smaller deal then it was a few years back!
"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.
Enjoy while it last. Some Idiot always has to make a blog post to collect some ad revenue or some attention. People don't understand that you can only use a loophole, if few people know about it.
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....
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 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
...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.
Any recommended resources for learning GDS?
It's interesting United Airlines is mentioned here. I am a security researcher and found vulnerabilities through the United Airlines bug bounty program last year. They pay you in miles instead of money.
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.
Relevant post: https://blog.docbert.org/united-airlines-bug-bounty/
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 hierarchy).
Given the real money involved, keeping it online with this flaw in place isn’t an option.
It is a very real option. If it's not being exploited by hundreds of people right now and you make more money keeping the site up vs. what you lose in "fraud" it makes sense to keep it running.
Just like you don't shut down your store if someone stole some merchandise or how credit cards just factor fraud into the fees.
It's often a violation of both government laws and insurance contracts, if you knowingly expose that much financial information to a proven vulnerability.
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.
Ok, but shutting down the website because of legal/moral responsibility to protect customer info is very different than doing so because of the “real money involved”, which is what commenter dewey was responding to. You can choose to just take the fraud cost hit in the latter case.
That's why people aim for the legal costs to be commensurate with the possible gain they will miss out on. Many corporate penalties are small enough that mathematically, it's absolutely worth simply breaking the law all the time.
I don't think this is a good analogy. It's more like you find that the lock on your stores front door has been broken for a long time and you just hadn't noticed. Nobody has broken in yet, but could at any moment. Also, it's not just your goods and business that are at risk, instead you're responsible for the protection of things that belong to other people.
The optimal amount of fraud is non-zero. https://www.bitsaboutmoney.com/archive/optimal-amount-of-fra...
I expect the report triggered something in a contract somewhere and they were obligated to take it offline knowing there was an issue.
> 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?
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 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.
Then imagine how often this happens without the "sensible employee" and "pop a ticket in JIRA" parts.
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 are redefining "tragedy of the commons" there... TOTC is about overusing shared resources (e.g. too many people helping themselves to a shared plate of food), not about confusing who should do what.
Responsibility is the "resource" that becomes diminished. What would you rather call it then? The bystander effect at organizational scale?
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.
When I was in my greyhat days I gained admin access[0] to a very big IIS web hosting provider. After spending a day trawling through their file system I found the actual admin password for their servers in a file. I tested it via their open RDP port. It worked.
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.
Also why would anyone store and read data like { 'groups': [...] } on the client-side? Session cookies are supposed to be identifiers only, with the data stored server-side.
By default sessions in Flask are stored in plaintext:
> 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.
That's precisely why the cookie should just be an identifier, that you look up group info from the database. Because you can guarantee the cookie contents will be modified by someone at some point. Make it useful to you, useless to them.
By default flask doesnt have a db. There is flask-sessions extensiom that does this for you.
Or you can just link to a DB directly. A Flask app is just a WSGI app. You can mount and extend it with any kind of Python, no extension necessary.
That's what the extension does for you.
Can't session data be stored on disk? that's the default PHP behavior.
Because you might have multiple webservers.
There are solutions for that: Shared NAS, sticky sessions etc.
Good luck with maintaining that NAS. Your sticky sessions will logout all users on a server that goes down. It's better to have a db.
Please stop.
Of course it's better to have a db doh... I'm replying to your
> By default flask doesnt have a db.
People don't have NAS laying around. And don't use a filesystem as a db, especially a remote filesystem.
The cookie contents can be changed only if you know the secret config.
Or if you can bruteforce the secret, or if there's a vulnerability in the secret, or if... You're relying on the fact that the cryptography will be impregnable, rather than adopting an actual security posture.
Do not trust the data you send to a user, to remain secure.
And you're relying on security through obscurity.
No. It's relying on both cryptography, and the inaccessiblity of information. Which is a tried, practiced, and often federally mandated, method of security. Controlling who has access to information is sorta security 101. Don't dump your database to the Internet.
Security through obscurity is allowing REST commands to the /totallysecretaddress/neverleaked/ URI.
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...
And stores session data in the DB by default
It's so funny to me, this is normally read aloud as "security vulnerabilities disclosed after patching" but in reality this is a natural part of how software is made. You make compromises. Terrible ones. Security ones. In the beginning. Not always, but some places, some applications, some websites, some languages, sometimes you make some concessions for sake of simplicity or prototyping or proof-of-concept'ing that ends up making it all the way to prod. And then these "vulnerabilities" are really things that mean your company grew way faster than you anticipated, and lucky for you some ethical hackers "exploited" these concessions, first.
Impressively fast responses from Points.com!
The secret was "secret".
Does anyone know what sort of market share points.com has in this space? It's always interesting to spot correlations between market fragility and a lack of competition (as in the case of the recent Crowdstrike and CDK Global outages).
Is this why / when airmiles when bankrupt and get bought out at the 11th hour by BMO?
https://newsroom.bmo.com/2023-03-10-BMO-Confirms-Agreement-t...
There was nothing abrupt about the Air Miles bankruptcy, they'd been in long-term decline and had lost nearly all of their major partners by that point. I called the BMO purchase months before it happened.
It’s amazing to me that these well known attack vectors are still possible today.
Reading about directory traversal in 2023-2024 is like a blast from the past.
Anyone know of other blogs similar to Sam Curry's web API exploitation stuff?
Insane vulnerabilities. The massive mismatches between authentication and authorization scopes are crazy. Encrypting data with "secret" as the key is also a facepalm.
Someone didn't bother reading my carefully prepared memo on commonly-used passwords. Now, then, as I so meticulously pointed out, the four most-used passwords are: love, sex, secret, and...
Ages ago I was tasked with migrating a site for a famous workout instructor. I noticed they stored passwords in plain text. His along with a shocking number of user accounts all used just his first name as the password.
hunter2
You are being downvoted because your comment only shows up as ****, which is not a significant contribution to the conversation.
So would your holiness care to change her password?
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
Password.
The username is Cyril Figgis.
god.
password????
The image is a probably an img2imgd pepe dealer :)
This is only tangentially related but it always blows my mind how insecure airline booking portals are. For many (most?) airlines all you need is the booking reference (PNR number) and surname to log in and see flight itinerary, contact details and, in some cases, change or cancel the booking. No password or MFA needed.
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...
The issue here is interoperability.
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.
You can only imagine the pain of having a "-" in your last name, when some documents accept spaces but not hyphens, and some accept hyphens but not spaces, and some accept neither, and some require other identifying documents to match each other...
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.
My name almost always gets trimmed. Here you can see a bit of the interoperational hell: https://xx1.pass-consulting.com/documentation/xx1-travel-sdk...
The tech in the travel industry is cursed, and the pay is bad. Do not recommend.
It's worse with some. A recent trip had me create an account with an airline - I can log in and see my trips, points, name, etc... but to see the itinerary, I have to have the PNR number, which isn't anywhere in the authenticated portal area. It's only delivered by email, once AFIACT. I thought I'd lost it at first - couldn't find it for a while (went to spam apparently).
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.
Because then they'd have to `SELECT *` on an unindexed field...
I know this is HN and here it's not a popular opinion, but maximum security is _not_ always a good idea. Even setting aside the problem of many different actors having to access these details mentioned below, there's value in a simple login process. Specifically for airplane tickets, the most common ones I had to struggle with multiple times are retrieving reservations bought from a different computer, or by a travel agency. In all these situations, it was exactly the simple approach that saved me. If 2FA was mandatory, the best case scenario was that the travel agency would have to send you a separate e-mail with details about how to access their portal where this 2FA would somehow work. The number of systems multiplies, the number of credentials to remember does, as well. If you are not from your usual workplace (and chances are, if you are travelling, you are not) or from a shaky connection (same), you are in a real problem. In a time-critical scenario, which makes it really worse.
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?)
> (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.
Maybe it was after boarding the flight? I still find it convenient . It's not that hard to keep the PNR number and surname. The reason it's so open is that there's an Identity check at the next stage where you can't use them if you're faking.
The concern is more about DOSing - using a pnr and last name, you can view (and in some cases, cancel) online via the airlines web site.
It's overlooked security issue in the airline industry. Yet I still haven't encountered such data theft stories (I mean personally)
[dead]
[flagged]
[flagged]