351–360 of 459 posts
Earlier quoted context omitted.
A random person pretending to be an airline pilot in a room full of airline pilots? I don’t see it happening, they’ll get kicked out in a second.
You don't have to pretend to be a pilot. Any cabin crew is allowed in the cockpit, AFAIK
Earlier quoted context omitted.
> Is there any sort of assurance that this wouldn't turn into a prosecution, though? It's not obvious to me on that site. Perhaps the CISA doesn't want to deter researchers, but do they get to make the final call? I don't think any sort of absolute assurance is possible, and if it was given I wouldn't trust it to be permanently binding :-) This is my intuition from having interacted with CISA, and my impression from…
I guess... at the end of the day without some reform to the CFAA I just wouldn't ever feel comfortable using exploits to gain access to a random website–particularly one related to air travel security–that I had no engagement with, even if there are enlightened folks in government who want to protect good-faith research. The downsides are just way too serious in the case someone, somewhere decides there's something w…
Earlier quoted context omitted.
This is a bit of ridiculous comment. Who in the right mind would say a sql injection is a backdoor for a 3LA? Added, why would they use FlyCass when they could just access the data directly?
I have to say I admire the linguistic beauty of your turning Three-Letter Agency into a three-letter acronym.
Earlier quoted context omitted.
You're not wrong, but I would have a hard time as a jury member convicting them of a CFAA violation or whatever for creating a user named "Test TestOnly" with a bright pink image instead of a photo. If they had added themselves as known crewmembers and used that to actually bypass airport screening, then yeah, they'd be in jail.
That's what jury instructions are for. The judge can instruct the jury to ignore pretty much any facts and consider any subset of what really happened that they want. So they'd just instruct "did they access the system? Were they authorized? If the answer to the first question is yes, and to the second is no, the verdict is guilty, ignore all the rest". The jury won't be from the HN crowd, it would be random people w…
Since they actually went past the SQL injection and then created a fake record for an employee, I'm shocked that Homeland did not come after and arrest those involved. Homeland would have been top of the list to misinterpret a disclosure and prefer to refer to the disclosure as malicious hacking instead of responsible disclosure. I'm more impressed by this than the incompetence of the actual issue.
https://bugcrowd.com/engagements/dhs-vdp
They've had that relationship for a few years now, so I'm guessing they're somewhat versed. TSA specifically might be less so, but I can't imagine the DHS referring anything to the DOJ for prosecution given that they both have a VDP for the entire department and advise other departments on how to run VDPs (via CISA).
But I might just be overly optimistic.
Earlier quoted context omitted.
Oh, everyone knows that one single person can make things a lot worse . That's all that's happening here. That doesn't say anything about how much one single person can make things better . In the former case, your powers are amplified by the incompetence of everyone else involved; in the latter case, they are diminished.
Better / worse for whom? Given the nature of these systems, this 1 person likely made the day to day lives of a lot of people better, providing an (arguably) snappier web interface to existing systems. Granted, they've probably made someone's day a lot worse with this discovery, but..
I take issue with the way that disclosure was implemented here. The responsible thing to do would be to contact the site first, no matter if 1 or 1000 employees.
Then you move forward with FAA, DHS, Etc. Assume that the site will act in good faith and recommend that they take down access until the problem is remedied, then back that up with disclosures and calls for auditing and verification to partner agencies.
Contacting the site first is the only honorable thing to do. It doesn’t mean you wait to contact other agencies, but contacting the site means the quickest halt to the vulnerability and least interruption to service. Disclosing to partner agencies is still required, of course, but hopefully they will be looking at a patched site and talking about how they can implement improvements in auditing the systems connected to the KCM service.
By disclosing in the right order you improve the possibility that organisations will focus on their appropriate role. The site fixes their egregious error and realises that their business depends on being secure, the TSA KCM manager realises that they need to vet access, and the FAA realises that the TSA needs to be supervised in the way that they interact with aircrew access.
Otherwise, everyone might just focus on the technical problem, which will be solved in a few hours or days and then go back to business as usual.
The vulnerability here actually is much, much larger thanSQL injection. It is an inherent vulnerability in the organisational structure and oversight, and this will only be addressed in a bureaucracy if the actual problem is made clear at each organisational level and no red herring excuses that allow finger pointing are provided.
Not to mention it’s a dick move to leave the technical people out of the loop completely in the process of disclosure, even if the disclosure is primarily of a systemic organisational failure.
I’m sure the individual responsible was much more alarmed to get a call from DHS than they would have been to get a call from security researchers, so the given rationale is clearly fictional.
Assume people will act in good faith, but don’t give them room not to. Trust but verify. When dealing with companies and orgs this is the way. When dealing with randos on the internet, not so much.
Earlier quoted context omitted.
Someting I’ve been thinking about, esp since that crowdstrike debacle. Why do major distributors of infrastructure (msft in case of crowdstrike, DHS/TSA here) not require that vendors with privileged software access have passed some sort of software distribution/security audit? If FlyCASS had been required to undergo basic security testing, this (specific) issue would not exist
I do believe that is the point of having things like FedRAMP and StateRAMP. Your company must meet said requirements to become a vendor for certain agencies or even be able to submit an RFP for governmental agencies.
Earlier quoted context omitted.
I believe the biggest increase in security since 9/11, is that passengers are no longer expected to sit down and behave. Pre-9/11, the expectation was you don't draw attention to yourself, wait it out, you're going to have a long day and a story to tell. Post-9/11, the expectation is you fight for your life. Better cockpit doors and access hygiene probably come second.
> I believe the biggest increase in security since 9/11, is that passengers are no longer expected to sit down and behave. While that may be a factor, there's never any news about this happening, except maybe shortly after 9/11 with shoe or underwear bombs.