Based on the language on their site about requiring an existing CASS subscription, my guess is there was no approval at all. It appears this person has knowledge of the CASS/KCM systems and APIs, and built a web interface for them that uses the airline's credentials to access the central system. My speculation is that ARINC doesn't restrict access by network/IP, so they wouldn't directly know this tool even exists.
Some quick googling shows the FlyCASS author used to work for a small airline, so this may piggyback off of his prior experience working with these systems for that job. He just turned it into a separate product and started selling it.
The biggest failure here is with ARINC for not properly securing such a critical system for flight safety.
This right here people need to pay attention to gut the following reason:
One person can make a lot of impact
The most common thing I hear people say with respect to their jobs is: “I’m just one person, I can’t actually do anything to make things better/worse…”
But it’s just wrong and there’s thousands of examples of exactly that over and over and over
In this case, if this is true, it’s both amazing that:
One person, or a small number of people, could build something into the critical path as a sidecar and have it work for a long time and
And second, the consequences of “hero” systems that are not architecturally sound, prove that observability has to cover all possible couplings
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.
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..
They made the day of a lot of people, making the KCM program available to crewmembers of thousands of smaller airlines.
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.
When things go well nobody notices. I’ve certainly headed off and found/fixed a lot of bad decisions in my career, some of my own included. There was a lot of impact there, and it’s good when it’s invisible!
Good observation! This person is obviously meeting a need, and probably doing pretty well for themselves, SQL injection and all.
> The most common thing I hear people say with respect to their jobs is: “I’m just one person, I can’t actually do anything to make things better/worse…”
Yup. This is something on the order of a large-scale blackpill meme lately. Comment sections are usually rife with low-agency thinking. Which is quite something in tech, given that devs are the means of production for tech. True, tech as of late seems to be veering into more capital-heavy ventures (AI), probably to head off existential risk from the fact that a few skilled individuals can still really make a dent.
Real life is all of us and all of us have an enormous impact in some way. Especially if we try and apply ourselves. Not all the time, not for everything, but if we try enough things enough times and learn and grow, then people usually come out with impressive results of some sorts after a while.
People overestimate what can be done in the short term, and underestimate what can be done in the long term.
In a lottery the ratio is against you. In real life the ratio is almost guaranteed in your favor in some respect in the long term for anyone who tries.
Beware of black and white thinking here. There's no "winning," just small wins building momentum towards whatever change you want to effect. Luck is always a factor (and don't believe anyone who says otherwise), but don't discount your ability to work smarter and harder.
Why is it critical for flight safety? It is critical for security theatre we have to endure at airports because some people have heightened neuroticism.
Be that as it may, of course the error needs correction. If it really is a one man show for tool like this, it isn't even surprising that there are shortcuts.
Because your luggage is not checked at all. I'm sure that a state level actor could circumvent TSA but an amateur could not, and they pose a huge threat too, see the recent bombing attempt at the Tailor Swift concert or the Trump assassination attempt
Allowing literally anyone to get into any airport and into any locked cockpit without any screening is critical to flight safety. If you can’t immediately see why I’m not sure what to tell you.
Convenient way to quickly add extra debugging capability without rerunning. It isn't much different from the many `curl example.com/install.sh |bash` you see around. It's up to the user to check things out before running.
Yeah, the piping to bash is a tried and true method for various installers. People make a fuss about it, but we don’t see people getting owned that way often. I think with bash installers though it’s pretty trivial to just visit the link and read through the 100 lines of bash. So anything installed this way should be as simple as visiting the link and reading a short amount of code imo
Sure, but it's a few extra steps. It's been proven(tm) that many people prefer a single, simple thing they can just copy, paste and run, so they can get back to their main concern.
And some may not want it actually installed for whatever reason. Such as when there's no proper separation between dev and prod deps. (I'm mostly just guessing at this point though...)
Not everywhere that python is run has access to pip. Sshing into some locked down remote machine and needing to debug some script is a use case that comes to mind.
You don't have to keep your hands on the yoke during hard turns with the FSD beta. Even with a wheel, it would be hard to signal the right amount of pressure without disengaging when their is a lot of movement going on.
Yeah but with the wheel you can grip it loosely and let it slide through your fingers whenever you want. With the yoke you'll be forced to constantly let go and grab it again to silence the nagging.
Some quick googling shows the FlyCASS author used to work for a small airline, so this may piggyback off of his prior experience working with these systems for that job. He just turned it into a separate product and started selling it.
The biggest failure here is with ARINC for not properly securing such a critical system for flight safety.