[HN Gopher] Hacking the largest airline and hotel rewards platfo...
___________________________________________________________________
Hacking the largest airline and hotel rewards platform (2023)
Author : DavidChouinard
Score : 294 points
Date : 2024-08-13 05:10 UTC (1 days ago)
(HTM) web link (samcurry.net)
(TXT) w3m dump (samcurry.net)
| alwa wrote:
| 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.
| jollofricepeas wrote:
| 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.
| hansvm wrote:
| > 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.
| azeirah wrote:
| 100%, hacking is as much technical prowess as it is social
| engineering.
| Thorrez wrote:
| 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.
| joatmon-snoo wrote:
| 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.
| michaelt wrote:
| _> - 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.
| seanthemon wrote:
| We call that guy grafana alerts at ours
| TrackerFF wrote:
| 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.
| bakje wrote:
| 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
| remus wrote:
| 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.
| toyg wrote:
| 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.
| remus wrote:
| > 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"
| jmb99 wrote:
| 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.
| udev4096 wrote:
| 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
| fragmede wrote:
| 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?
| Normal_gaussian wrote:
| 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.
| lazyasciiart wrote:
| 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.
| Normal_gaussian wrote:
| I guess medicine storage is an interesting cultural thing
| - I've always known them to be stored in the kitchen!
| mylastattempt wrote:
| 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.
| mywacaday wrote:
| 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.
| diggan wrote:
| 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!
| sqs wrote:
| Impressively fast responses from Points.com!
| rootsudo wrote:
| 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.
| sushid wrote:
| Can you provide a link or two so one could read up on what
| you've mentioned in your post?
| klausa wrote:
| 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.
| Beijinger wrote:
| 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.
| klausa wrote:
| 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.
| Beijinger wrote:
| 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....
| rootsudo wrote:
| 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
| ramses0 wrote:
| ...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.
| nucleardog wrote:
| > 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.
| moritonal wrote:
| "Right click > Inspect Element, all you need to subvert the
| Commonwealth of Australia"
| chatmasta wrote:
| The researcher also told this story on DarkNet Diaries Ep 84,
| "Jet-Setters." It's worth a listen.
| throwawaysleep wrote:
| Any recommended resources for learning GDS?
| junto wrote:
| > 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?
| xnorswap wrote:
| 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.
| bankcust08385 wrote:
| 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.
| toyg wrote:
| 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.
| astura wrote:
| 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.garretthard
| insociety.org/articles/art_tragedy_of...
|
| Because it doesn't say what you seem to think it does.
| teractiveodular wrote:
| Then imagine how often this happens without the "sensible
| employee" and "pop a ticket in JIRA" parts.
| samsonradu wrote:
| 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.
| ddorian43 wrote:
| 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.
| shakna wrote:
| 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.
| ddorian43 wrote:
| By default flask doesnt have a db. There is flask-
| sessions extensiom that does this for you.
| shakna wrote:
| 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.
| ddorian43 wrote:
| That's what the extension does for you.
| samsonradu wrote:
| Can't session data be stored on disk? that's the default
| PHP behavior.
| ddorian43 wrote:
| Because you might have multiple webservers.
| samsonradu wrote:
| There are solutions for that: Shared NAS, sticky sessions
| etc.
| ddorian43 wrote:
| 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.
| samsonradu wrote:
| Of course it's better to have a db doh... I'm replying to
| your
|
| > By default flask doesnt have a db.
| ddorian43 wrote:
| People don't have NAS laying around. And don't use a
| filesystem as a db, especially a remote filesystem.
| ddorian43 wrote:
| The cookie contents can be changed only if you know the
| secret config.
| shakna wrote:
| 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.
| ddorian43 wrote:
| And you're relying on security through obscurity.
| shakna wrote:
| 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.
| switch007 wrote:
| Makes you wonder if there a colleague who wanted to use Django
| with the biggest "I told you so" grin right now
| 8organicbits wrote:
| 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.
| ..
| switch007 wrote:
| And stores session data in the DB by default
| qingcharles wrote:
| 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.
| ZephyrBlu wrote:
| Insane vulnerabilities. The massive mismatches between
| authentication and authorization scopes are crazy. Encrypting
| data with "secret" as the key is also a facepalm.
| jsemrau wrote:
| 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...
| S04dKHzrKT wrote:
| hunter2
| Phemist wrote:
| You are being downvoted because your comment only shows up
| as ****, which is not a significant contribution to the
| conversation.
| kalev wrote:
| password????
| wrboyce wrote:
| god.
| bankcust08385 wrote:
| _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_
| dawnerd wrote:
| 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.
| yard2010 wrote:
| Password.
|
| The username is Cyril Figgis.
| openplatypus wrote:
| The secret was "secret".
| sangeeth96 wrote:
| 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.
| grecy wrote:
| > _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
| kredd wrote:
| 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.
| chatmasta wrote:
| This makes sense because a hack job that generates money is
| more likely to stay online than a hack job that makes no
| money.
| chatmasta wrote:
| 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.)
| matteason wrote:
| 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...
| dustypotato wrote:
| 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.
| callmeal wrote:
| 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.
| fer wrote:
| 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.
| IggleSniggle wrote:
| 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.
| fer wrote:
| 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.
| spi wrote:
| 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?)
| thomas-st wrote:
| > (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.
| lowercased wrote:
| 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.
| ramses0 wrote:
| Because then they'd have to `SELECT *` on an unindexed
| field...
| interludead wrote:
| It's overlooked security issue in the airline industry. Yet I
| still haven't encountered such data theft stories (I mean
| personally)
| n4r9 wrote:
| 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).
| bogtog wrote:
| 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).
| simondotau wrote:
| Given the real money involved, keeping it online with this flaw
| in place isn't an option.
| dewey wrote:
| 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.
| shakna wrote:
| 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.
| jessriedel wrote:
| 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.
| lazyasciiart wrote:
| 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.
| tehryanx wrote:
| 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.
| fragmede wrote:
| The optimal amount of fraud is non-zero.
| https://www.bitsaboutmoney.com/archive/optimal-amount-of-
| fra...
| idk1 wrote:
| I expect the report triggered something in a contract somewhere
| and they were obligated to take it offline knowing there was an
| issue.
| 486sx33 wrote:
| 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...
| Marsymars wrote:
| 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.
| sova wrote:
| 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.
| xyst wrote:
| 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.
| Banditoz wrote:
| Anyone know of other blogs similar to Sam Curry's web API
| exploitation stuff?
| soygem wrote:
| The image is a probably an img2imgd pepe dealer :)
| billy99k wrote:
| 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.
| junar wrote:
| Relevant post: https://blog.docbert.org/united-airlines-bug-
| bounty/
___________________________________________________________________
(page generated 2024-08-14 23:02 UTC)