If I was the author, I'd be kept up at night by the idea of being kidnapped in the middle of the night and whisked off to some black site, however likely or unlikely that is.
the fact that he mentions the bounty but not the reward means he probably got a reward. If he did not get one, he would have mentioned it.
it was not a ridiculous amount because 1. he would have refused it and talked about it. 2. the money was good enough for him to comply and not cite the companies
was it a large amount ? it could be the reason why he's not telling it. Companies don't want to be spammed by script kiddies attracted by the "largest reward in town".
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.
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__
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?
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!
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.
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.
> 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.
Given that the MAC address is the only thing the access point has to tie your packets to a (paid) session in an unencrypted network, I'd expect this to still work today, or am I missing anything?
OWE [1] might help in this scenario (if it‘s possible to reliably bind that to a login session somehow), but that's pretty new, and given how long upgrade cycles on airplane hardware are, I wouldn't count on seeing that within the next couple of years.
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!
Or even better invest in standing tech and cram like a subway, and fire all the stewardess, make it remote piloted and outsource to the south asian countries to fly it.
Security + revenue + cost cuts. All in one shot.
You need 3 remote (contract) pilots, the plane only responds to a quorum of synchronized inputs. Then you can drive the price down as you let them fly multiple planes at the same time. Perhaps even a gig economy play here.
There's several of these "I changed X and got Y" without ever showing what X is, just alluding to it. That grinds my gears in any blog post, perhaps only second to not stating which version/system some code is running against.
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.
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
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.
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.
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.
To your point - Although the post discusses possible PCI implications, I don't think exposing last 4 and PII alone are enough to run afoul of the requirements (at least 3.2 as far as I remember). We would need the full PAN or CVV or evidence that this was being stored improperly, etc. If I recall, a company can store first 6 and last 4 in plaintext. With that said, these problems may indicate bigger issues that would violate the DSS, he may have found more that wasn't written about, or I could just be mistaken.
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.
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?".
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.
One valuable thing that did come out of that is that it proved your monitoring works and you caught the attack quickly. I also had a similar experience in where we were getting bombarded with alerts from our wifi controller all of sudden. It turned out that a pen tester showed up in the middle of the day and started to run “scans” probably with Nessus or something.
I could have done all of this myself and saved the company tens of thousands of dollars but I think management insisted it came from an outside company. It would be nice though to find an actual pen tester from the back alley of DEFCON who you have to pay in crypto or precious metals and have them do some actual hacking. :)
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?
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.
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.
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.
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!"
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.
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.
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"?
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
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.
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.
OK, I'm honestly curious, because the idea in my head is this:
Using a VPN to protect you from the dangers of public Wi-Fi is worthless, because HTTPS already does everything VPN companies claim their VPNs do to protect you, such as protecting people from snooping your banking information or redirecting you to some "Wells Fargo But It's A Phishing Frontend" website, because HTTPS provides both encryption and, through certificate verification by way of the browser's own trust store, validation that you're connecting to the domain you think you're connecting to and an MITM attack isn't going on.
If I'm somehow wrong about any part of that, I'd like to know.
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.
It's also ok for you to sit down. You know that, right?
I did read the article and "use a VPN" is solid advice; moreover it's something you have complete control over, whereas the system on board the airplane is beyond your control.
Except you can just not use it, which is probably the best advice of all.
You clearly don't understand it enough to know that "use VPN" has nothing to do with it. It may be good best practice, but it has literally nothing to do with this article or the vulnerability in question.
It's the equivalent of me coming into the thread and saying "the sky is blue". It's a factual statement, it's kind of in the realm of being related, considering airplanes fly in the sky, and yet it is completely and utterly tangential to the article and vulnerability. It's as off topic as a comment can be.
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.
> 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.
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.
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.
The article is about authenticating to a Wi-Fi captive portal. So not only is a VPN irrelevant, as everyone has already pointed out and you continue to ignore, it wouldn't even work.
I don't understand how a black hat, even with access to your account, could spy on your traffic? They're entirely different concepts. Just having access to the account doesn't mean you can see all data going through the network for people using that account.
And even if they could, any sensitive page should be using HTTPS, so the data will be encrypted. A VPN still wouldn't make a difference.
> 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.