[HN Gopher] Hacking on a plane: Leaking data of millions and tak...
___________________________________________________________________
Hacking on a plane: Leaking data of millions and taking over any
account
Author : crecker
Score : 177 points
Date : 2022-12-08 19:01 UTC (3 hours ago)
(HTM) web link (rez0.blog)
(TXT) w3m dump (rez0.blog)
| cwkoss wrote:
| Nice catch, and kudos to you and them for the quick resolution!
| throwaway019254 wrote:
| > Monday (November 21st) the airline was made aware of the issue
|
| > Wednesday (November 23rd) resolution has already been tested
| and deployed
|
| That's a pretty nice response time - compared to some big
| companies that are asking security researchers to not disclose
| vulnerability for six months.
| sbuccini wrote:
| Especially since the vuln was in a third-party system so the
| airline couldn't push a fix themselves.
| birdman3131 wrote:
| Depends on if it was a security issue or a config issue. From
| the end user's perspective they can look the same.
| rez0123 wrote:
| This was a bug in the WiFi portal's api. No need for the
| airline to fix anything. It simply affected their
| customers.
| crecker wrote:
| Good job!
| jaywalk wrote:
| I can understand when there's a bug that causes something like
| this. It doesn't excuse it, but we all introduce bugs in code,
| and sometimes they're disastrous.
|
| But this? This is just straight up careless, thoughtless design
| with zero regard for security whatsoever. It's inexcusable.
| version_five wrote:
| Airplane wifi is very much still in the "enterprise software"
| phase, by which I mean a lowest bidder sells it to someone who
| will never use it and buys it with only some corporate
| objective in mind. I've been using it a lot recently, across
| several airlines, and the experience is universally bad. It
| doesn't surprise me they also skimped on security
| jaywalk wrote:
| At least as far as the connectivity itself goes, Viasat's Ka-
| band airplane WiFi is actually really good.
|
| As luck would have it, I've got a flight coming up in a few
| days on a plane using the provider implicated in this
| article. I'll be doing some poking around myself for sure.
| dfcab wrote:
| Coincidentally on a flight right right now and service is
| decent on United. Not fast but useable. One caveat is that
| it performs much better with a VPN enabled. Seems they
| block certain things such as Zoom and the VPN allows the
| use of the chat feature. Apple Music was struggling until
| the VPN was enabled and solid since.
| Cupertino95014 wrote:
| When on any sort of public WiFi network, use a VPN.
|
| If anyone has a story about how "that's not enough" I'm eager to
| hear it. Can't be too careful, can we?
| jaywalk wrote:
| This has absolutely nothing to do with the fact that it was
| public WiFi, so your advice of using a VPN is irrelevant.
| Cupertino95014 wrote:
| This has to do with being on a public network (an airplane),
| does it not? Maybe your outrage is over-the-top.
| petschge wrote:
| Absolutely not. This has to do with how accounts for that
| network are managed. Even if you use a VPN you will still
| have an account there and your data were at risk to this
| vulnerability.
| Cupertino95014 wrote:
| > The impact of these two bugs was signifcant. It was
| access to first name, last name, address, and email of
| the user as well as last 4 digits, expiration date,
| billing name, and address of the credit cards.
|
| Assuming you're a black hat exploiting this bug, what can
| you do, if the target is using a VPN?
|
| I don't know what "address of the credit cards" means,
| but let's assume it's the target's home address.
|
| You don't get their credit card number or security code.
| You don't get access information on any of their web
| accounts. Correct?
|
| If you spy on their internet activity during the flight,
| it's all encrypted. You won't learn anything.
|
| However, you do have the ability to change their
| password, so they can't get into their own account
| anymore.
|
| You could also bill all your own activity to their
| account. I don't know if you can bill other things to the
| account.
|
| You could get access to whatever data was stored in that
| account. I don't know what that would be, other than when
| & how much you used it in the past.
|
| Is this a complete summary of the potential damage?
|
| Since there's no Reply button for the two answers to
| this:
|
| Neither of them answer my last question ("is this a
| complete summary..."). Should I assume it is?
|
| And I never said "oh but the data leak isn't really that
| bad of a vulnerability" -- you did.
| Mogzol wrote:
| > Assuming you're a black hat exploiting this bug, what
| can you do, if the target is using a VPN?
|
| Going by the same logic, what can a black hat exploiting
| this bug do if the target ISN'T using a VPN?
|
| Using or not using a VPN in the context of this bug is
| totally irrelevant.
| Cupertino95014 wrote:
| Wouldn't that depend on whether this airplane system lets
| two machines use the same account at the same time?
| petschge wrote:
| You still have an account, even when you are not
| currently in the air.
| Cupertino95014 wrote:
| You seem confused about what we're arguing about.
|
| OP said "what would _not_ being on VPN let someone do to
| you? "
|
| not
|
| "what harm could occur if you're not in the air?" or
|
| "does using a VPN protect you from _all_ harm? "
|
| and the question/assertion is, "if you were in the air,
| and not on VPN, then could a black hat who's compromised
| your account spy on your traffic?"
| jaywalk wrote:
| You completely missed what this vulnerability is. It has
| nothing to do with intercepting another user's traffic.
| The checkout page in question actually uses SSL anyway,
| so it's not even possible absent some sort of MITM
| attack.
|
| This has to do with API endpoints that exposed customer
| information and allowed password changes without checking
| that the request was coming from the customer. The
| customer didn't have to be logged in to the account, or
| even on the flight in the first place. If they had an
| account, it was exposed.
| Cupertino95014 wrote:
| Quite right. But as I said, "intercepting another user's
| traffic" would be an _additional_ vulnerability, but not
| if you 're on VPN.
|
| Maybe you could just admit that and end the argument.
| This doesn't require you to minimize the seriousness of
| the bug.
| petschge wrote:
| None of the impact of having your data leaked from your
| account is in any way modified by using a VPN for your
| data traffic while you are on the airplane. Hence the
| initial reply of that your suggestions of a VPN is
| irrelevant. Don't try to change this into a "oh but the
| data leak isn't really that bad of a vulnerability" after
| having lost that argument.
| Cupertino95014 wrote:
| Where do I say "oh but the data leak isn't really that
| bad of a vulnerability"?
|
| I tried to summarize what the vulnerability is. Why are
| you so upset about that?
| mynameisvlad wrote:
| It's ok to admit you're wrong; you know that, right? You don't
| have to dig further down or move the goalposts when it's
| clearly shown you didn't actually read the article or
| understand the vulnerability in question.
| [deleted]
| plastiquebeech wrote:
| Not surprising, airplane wifi has always been ridiculously
| insecure.
|
| Back in the day, when it was first rolling out, you could
| (theoretically ofc) join the plane's network and scan for MAC
| addresses, then clone someone else's for free access.
|
| I think the authentication is a bit more sophisticated these
| days, but it's clear that these providers treat security as an
| afterthought. At least the one in the article had a bug bounty
| program and responded quickly, I guess.
|
| Unrelated, I think it's funny that the AI artist put a little
| picture of a house on the airplane's interior wall in the
| article's header image. Maybe plane trips would be more bearable
| if the cabins didn't look like a utopian abbatoir's waiting room.
| jshchnz wrote:
| crazy how this makes it all the way to production, I wonder how
| long this vulnerability was exposed...
| dopamean wrote:
| I's kind of incredible how common this specific kind of
| vulnerability is. I have to assume the developers of these
| systems just hope that no one will notice?
| crecker wrote:
| I'm not the author of the article. But I think developers
| thought "ahaha who's going to checkout? Someone that has
| developer tools in airplane? Good joke bob!"
| brazzy wrote:
| No, the developers simply don't realize that there is a
| vulnerability, _even though they have the required knowledge_
| because they look at the code with the "how do I implement
| this feature" mindset (which is their _job_ ), not a "how could
| this be abused" mindset.
| marapuru wrote:
| In addition to the comment above, this mindset is
| strengthened by time squeezes in development. Which lead to
| sales, project managers and product owners who prevent
| developers from actually looking into this.
| HideousKojima wrote:
| Just because a vulnerability is common and easy to avoid won't
| stop lazy and/or incompetent devs from making it. I mean SQL
| injection is still incredibly common despite being easily
| mitigated by really basic knowledge and despite being handled
| properly by the most common data access libraries in every
| single programming language.
| amackera wrote:
| These types of fails are generally due to incompetence, in my
| experience.
| jaywalk wrote:
| This one is 100% due to incompetence. There was no attempt at
| anything resembling security.
| hackbinary wrote:
| I'm not sure what your experience is, but mine is over
| multiple decades over multiple companies over multiple
| continents, and in general, corporate management, project
| management, and business analysts are not concerned about
| security.
|
| Instead, they are interested in delivering buttons, fields,
| and streamlined workflows. Technical debt and library
| upgrades? Os upgrades? Forget about it. They need to
| deliver value back to the business in terms of faster
| business processes.
|
| Only when the business is hacked or they fail compliance
| does the business leadership start to care.
|
| Blaming the people with the hands on the tools is not fair
| when the business will not give the resources to do their
| work properly.
| rwmj wrote:
| I've seen development environments that try to abstract away
| the underlying web mechanisms[1], which can make it very hard
| to tell what's really going on at the request level. Combine
| that with incurious developers, deadlines and a need to ship
| anything that works and this is what you get.
|
| [1] I'm thinking in particular of Ars Digita's second system
| effect Java replacement for their original Tcl environment. It
| tried to turn everything into late 1990s Java buzzwords and was
| completely opaque, as well as being comically inefficient.
| 8jy89hui wrote:
| The author did not mention if they were rewarded by the bug
| bounty program. A vulnerability of this severity surely requires
| a reward of some sort.
|
| Does anyone have any more information about whether or not this
| person was compensated for their work?
| boringg wrote:
| And how much they were compensated is also interesting...
| noduerme wrote:
| Once a user is logged in, is including their username or userID
| routine API responses considered bad practice? I don't see why it
| should be, if everything you can _do_ with that username requires
| an active login token.
|
| The fact that you could put in an email address in lieu of a
| username/userID seems irrelevant; lots of systems allow email
| addresses as a username. What stands out about this to me is: We
| see in both requests the same `uxd_id` field. This looks to be a
| temporary login key or validation key generated by the server,
| that the client would probably use to validate further requests
| or validate a password change request from that username. It's
| different in the email than in the live server response so they
| are generated in different sessions. So...
|
| 1) The email reset has two calls. What does the author mean that
| the first call validates the user's auth? If this is a "forgot
| password" link for a user who's not logged in, there should be no
| existing auth (unless that old uxdID functions as a permanent
| password, but even then, it should be specific to the user). That
| link should go to a page that issues a new email with a temporary
| validation token that's tied to the specific user and then
| emailed back to that user's email address. Unless you could
| intercept the named user's email there should be no way to know
| the new token and reset the password.
|
| 2) If, on the other hand, it was a reset pass call with the user
| _already logged in_ , why is the server not checking that uxd_id
| matches the active login session _which also matches the user
| whose password is to be changed?_ What 's the point of the uxd_id
| field in the PUT call if not to check that calling user ==
| authorized user == user whose password should be changed? Who
| would write something like that? For that reason, this looks more
| like a backdoor for testing password resets that was
| unintentionally left open.
|
| Am I misunderstanding something about the way this thing is
| taking tokens to change passwords...? Or is what's described
| really as simple as "system doesn't check if uxd_id matches
| user's email on an active session"?
| glyphosate wrote:
| Yes, it's as simple as the back end not validating that the
| user id and email address in the requests are tied to the
| active session. It's a very common mistake, often happens when
| devs try to roll their own session management/access control
| functionality
| SoftTalker wrote:
| You can't trust the client. You need to validate everything on
| the server in the context of the authenticated session. At that
| point, it doesn't really make sense for the client to be
| submitting data that will have to be looked up and verifed
| anyway.
| noduerme wrote:
| If the client has a session, the client is passing the
| session hash on each and every call. You have to accept it
| and check it. Whether it's in a session cookie or manually as
| a GET param. The server doesn't "know" what session it's
| receiving a call from; it uses the session cookie sent by the
| client to check it.
|
| Meaning, those $_SESSION variables in PHP are stored on the
| server, but the server only knows which session to access
| based on a key passed with every call from the client. A
| hacker copying someone's php session id would "trick" PHP
| into using the target's server side variables.
|
| If you're coming from a reset password email and the user has
| no active session, a token has to be sent via GET and
| checked, which means you have to look it up and verify it.
| LiamPa wrote:
| How is something like this not picked up in a pen test? Can only
| assume there never has been..
| jesuspiece wrote:
| so many "pentests" are:
|
| * run scanner
|
| * print out report
|
| not a lot of deep diving
| nicholasjarnold wrote:
| Yep. It's a shame. I once (long ago :)) alerted our CTO to an
| ongoing attack in production after seeing some obviously
| attack-oriented requests coming in and hitting our gateway.
| It became a pretty high-visibility incident for about 20
| minutes until a manager spoke up that his "pen test" was
| being performed. Looking into the "testing" that was
| occurring they were attempting to scan for decade-old PHP
| bugs in a set of services which were written in Java and
| NodeJS. Very high value stuff... Can only imagine what the
| invoice was for this valuable service.
| nicholasjarnold wrote:
| So, to try and add some value to this conversation vs just
| reporting a personal anecdote... Do people here have
| suggestions for actually-good white-hat companies?
|
| Can you recommend companies that you've personally worked
| with who employ knowledgeable security engineers (hackers)
| to perform real penetration tests and conduct valuable
| security scans resulting in value-add reports your
| engineering team can work with?
|
| Not looking for naming and shaming...but rather "Who
| doesn't suck at doing this?".
| deepoftdrink wrote:
| we had a good experience with
| https://www.praetorian.com/services/penetration-testing/
| earlier this year
| photon12 wrote:
| NCC Group is probably the biggest name because they go
| around Hoovering up companies that are usually above
| average in the competencies you asked about. And they can
| attract and retain talent.
|
| Trail of Bits is another big name because they hire and
| retain talent across a large number of enterprise,
| emerging tech, and research verticals.
|
| Other established firms include Atredis Partners,
| IOActive, Security Innovation. There are more one could
| list.
|
| Sometimes these companies work with partners who ask to
| publicly disclose some artifact resulting from the test.
| Here is a collection of those reports aggregated by firm:
| https://github.com/juliocesarfort/public-pentesting-
| reports (Edit: note this is not a great way to evaluate
| any particular company, but it does provide an objective
| listing of companies that exist in the pentesting space).
|
| Each firm will also have variability in their personnel
| for your project which can yield different results for
| two independent tests on the same target from the same
| firm.
| amackera wrote:
| Probably because a lot of pen testing is security theatre.
| photon12 wrote:
| Since this is specifically related to accepting payment, one
| would hope this infrastructure has received adequate security
| testing as required by PCI standards.
|
| In practice, PCI standards compliance is a mess of people
| selling "point and click compliance solutions," companies
| being too big to be properly audited, code churn between
| audits, companies misleading auditors or hiding key data.
| Security theater is especially pervasive in PCI compliance.
| jacquesm wrote:
| More likely: the pentest report that was made because it was
| mandatory ended up in someone's drawer.
| technion wrote:
| Don't assume it wasn't.
|
| I've done tests several years on a row where I pop a service
| using the first years report.
| Scoundreller wrote:
| Kinda like when a government program says they consulted the
| bar society or the privacy commissioner before going ahead
| with it.
|
| But if you read their reports, it's all "no, no, no, no
| way!!!!!!"
|
| A lot of "consultations" are really "inform/get informed, and
| ignore it all and do what you were going to do all along
| anyway".
|
| But you can check the box to say you did your consultations.
| YeBanKo wrote:
| Not related to the content of the article, but to the
| presentation: that art work in the header is spot on, except
| maybe for what appears to be tree branches in the window. I think
| we are witnessing how generative are killing photo stock
| business.
| LiamPa wrote:
| I think they are supposed to be the 'wing'
| kermi wrote:
| I think it might be dragon wings
| YeBanKo wrote:
| Maybe. But aside from that little artifact, it is really nice
| and it fits a description well. And probably it only took the
| author few moments to get it generated.
| goblinux wrote:
| Ew yeah the more you look at it the weirder it gets. Like
| what's between his fingers, or what is that keyboard layout? Is
| that supposed to be cash sitting on the armrest, or like a
| plane ticket?
| ok_dad wrote:
| Is he wearing a hoodie or a down jacket, and why is his neck
| wrap thingie seems to be integrated into the hoodie. Also, he
| seems to be wearing some sort of leather harness or backpack.
| Weird stuff!
| goblinux wrote:
| Also what is that seat back, is it his backpack or has he
| pulled the emergency flotation device out from under his
| seat already?
| yakshaving_jgt wrote:
| How is his left ring finger attached to the rest of his
| hand!?
| alistairSH wrote:
| The more I look at it, the worse it gets.
| rez0123 wrote:
| Thank you! I generate a ton of cool hacker art with midjourney.
| My Twitter has a bunch more if you click the media tab and
| scroll down https://Twitter.com/rez0__
| rez0123 wrote:
| Here's a post with a good # of them:
| https://twitter.com/rez0__/status/1585981770209820672
| sys_64738 wrote:
| I think the way that airlines handle this is to squash as many
| seats together as possible so it's not possible to open your
| laptop to do hacking. Problem solved!
| t3estabc wrote:
___________________________________________________________________
(page generated 2022-12-08 23:00 UTC)