Bypassing airport security via SQL injection • Hacker News Board

Re: Bypassing airport security via SQL injection

#291

Post by kijin » Fri, Aug 30, 2024, 2:20 AM UTC

shuntress wrote: post #283

jjav wrote: post #147

Earlier quoted context omitted.

> single-use tool websites use Google's login Topic drift, but no tools should use google login. Doing that means handing over to google the authority to decide who can and can't use your tool. And we all know google support is nonexistent and unreachable, so once it fails it's forever. If you market a tool, you'd really want to own the decision on who you can sell it to. For a government organization though, I'd agr…

Trusting Google's OAuth not to vanish overnight is less stressful than managing your own username/password database. And that's pretty much my point. 2FA? Password Resets? Account Activation? Updating Email Address? No thanks. I would rather not have to deal with any of that. I literally just need a unique identifier to associate with your data and preferences.

Many well-established web frameworks have plugins or components to handle user management out of the box, with sane defaults. Nobody should have to roll them by themselves with each hobby project. You're probably using a similar plugin to integrate with Google anyway.

Re: Bypassing airport security via SQL injection

#292

Post by edm0nd » Fri, Aug 30, 2024, 2:30 AM UTC

preciousoo wrote: post #50

VyseofArcadia wrote: post #30

Earlier quoted context omitted.

> Hilarious that the entire TSA system is vulnerable to the most basic web programming error that you generally learn to avoid 10 minutes The article mentions that FlyCASS seems to be run by one person. This isn't a matter of technical chops, this is a matter of someone who is good at navigating bureaucracy convincing the powers that be that they should have a special hook into the system. What should really be inves…

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.

Re: Bypassing airport security via SQL injection

#293

Post by jjav » Fri, Aug 30, 2024, 2:31 AM UTC

shuntress wrote: post #283

jjav wrote: post #147

Earlier quoted context omitted.

> single-use tool websites use Google's login Topic drift, but no tools should use google login. Doing that means handing over to google the authority to decide who can and can't use your tool. And we all know google support is nonexistent and unreachable, so once it fails it's forever. If you market a tool, you'd really want to own the decision on who you can sell it to. For a government organization though, I'd agr…

Trusting Google's OAuth not to vanish overnight is less stressful than managing your own username/password database. And that's pretty much my point. 2FA? Password Resets? Account Activation? Updating Email Address? No thanks. I would rather not have to deal with any of that. I literally just need a unique identifier to associate with your data and preferences.

> Trusting Google's OAuth not to vanish overnight

Sorry if I wasn't clear. It is not that google will remove the service overnight (although they are infamous for canceling things, but not that bad). The problem is google will lock out users randomly for no reason and no recourse.

If that user was using google login to access your service/tool, you lost that user and there is nothing you can do. You really don't want to gate the access to your product via an unreachable unresponsive third party like google.

Re: Bypassing airport security via SQL injection

#294

Post by tiagod » Fri, Aug 30, 2024, 2:37 AM UTC

partiallypro wrote: post #239

soneil wrote: post #126

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.

Pilots are also now told to not open the cockpit door, no matter what's happening in the cabin and to land the plane. There is a near 0 change you could take control of the plane. I would be more concerned about someone bringing a bomb on board.

What if you hack a system that allows you into the cockpit with no additional checks? That would be crazy...

Re: Bypassing airport security via SQL injection

#295

Post by nucleardog » Fri, Aug 30, 2024, 2:38 AM UTC

akoboldfrying wrote: post #220

permo-w wrote: post #180

Earlier quoted context omitted.

really feels like SQL should have never been written in such a fundamentally insecure manner, or immediately fixed once it was discovered that it was

How would you "fix" it, while still allowing people to write ad hoc queries?

Don't allow non-parameterized queries at all? Like right at the protocol and parser level? Strip "literal value" as a token right out of the query parser.

Then a simple interactive client could do something like:

``` > select * from users where username = :username username? admin

+----+----------+----------+ | id | username | password | +----+----------+----------+ | 7 | admin | 12345 | +----+----------+----------+ ```

While a fancier client could, in fact, transparently translate queries exactly as you write them today--pull out the values, replace them placeholders, then send the query and values over the wire.

``` > select * from users where username = 'admin'

sent as: query: select * from users where username = :placeholder1 placeholder1: admin ```

There's, of course, nothing stopping any given library or application from doing the same thing, but the vast majority of the time I'd wager this is happening because someone tried the obvious and simple thing (string concatenation) and it worked and they stopped there. Anyone who knows enough to write their own SQL parser or even think to go find a library to do this is probably going to know why they absolutely should not be doing this.

Re: Bypassing airport security via SQL injection

#296

Post by newscracker » Fri, Aug 30, 2024, 2:40 AM UTC

aftbit wrote: post #14

dylan604 wrote: post #9

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.

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.

> 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.

I think it could go any which way. The prosecution could argue that the defendant may have tampered with existing records or deleted some. In this particular case, it’s probable that the system does not have any or adequate audit trails to prove what exactly transpired. Or the claim could be that the defendant exfiltrated sensitive data (or that the defendant is trying to hide it) to share with hostile entities.

Re: Bypassing airport security via SQL injection

#297

Post by newscracker » Fri, Aug 30, 2024, 2:42 AM UTC

cabaalis wrote: post #15

dylan604 wrote: post #9

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.

If anyone from there reads the parent, they should know they have created an atmosphere where the worry of possible prosecution over responsible disclosure has the potential to scare away the best minds in our country from picking at these systems. That just means the best minds from other, potentially less friendly countries, will do the picking. I doubt they will responsibly disclose.

I’m not sure any country’s bureaucracy really appreciates responsible disclosures that make the government’s systems look very poorly designed. There is always the risk of being classified as an enemy agent/criminal depending on who’s reading the report and their own biases.

Re: Bypassing airport security via SQL injection

#298

Post by mvkel » Fri, Aug 30, 2024, 2:43 AM UTC

While this report is embarrassing for all involved, in a practical sense, I'd argue the security of this app was "fine."

What I mean: security through obscurity is imo the best situation to be in. You can't attack something if you don't know it exists in the first place. That alone gives this system a leg up over more exposed (but hardened) platforms.

Second, convenience always beats secure. Requiring password rotations is worse than requiring none at all, because people tend to find the path of least resistance (writing a password on a notepad instead of memorizing).

If it was faster/easier to ship a useful (but vulnerable) app, that's net better than the app not shipping at all because of security hurdles. I have to imagine sanitizing inputs doesn't take much more time to include, but I don't know the systems involved.

Ultimately, what damage was experienced here? We can throw out hypotheticals about what -could- have happened, but you can't sue every driver on the road because they -could- have hit you.

An insecure system served a useful purpose for years, got more secure, and continues ticking.

Re: Bypassing airport security via SQL injection

#299

Post by pajeets » Fri, Aug 30, 2024, 2:55 AM UTC

mvkel wrote: post #298

While this report is embarrassing for all involved, in a practical sense, I'd argue the security of this app was "fine." What I mean: security through obscurity is imo the best situation to be in. You can't attack something if you don't know it exists in the first place. That alone gives this system a leg up over more exposed (but hardened) platforms. Second, convenience always beats secure. Requiring password rotati…

I'm not sure I'd write this off because having a weak spot like this and information gained could lead to more discovery of the obscure. It's never a good security design to rely on someone never finding my secret API routes that I named after my co-workers that I despised

Re: Bypassing airport security via SQL injection

#300

Post by menthe » Fri, Aug 30, 2024, 2:55 AM UTC

mvkel wrote: post #298

While this report is embarrassing for all involved, in a practical sense, I'd argue the security of this app was "fine." What I mean: security through obscurity is imo the best situation to be in. You can't attack something if you don't know it exists in the first place. That alone gives this system a leg up over more exposed (but hardened) platforms. Second, convenience always beats secure. Requiring password rotati…

I am sorry, are you non-sarcastically arguing that being able to pass through airport security, potentially accessing cockpits and planting bombs onboard airplanes, with a high-school level SQL injection on a federal website used by dozens of airlines & airlines employees, is actually, "fine"?

Besides, I am not sure what sort of "security through obscurity" you are talking about? Ian and Sam found it, and frankly - with a public page, page title + first h1 tag clearly stating that this relates to a Cockpit Access system, this has got to show up in a shit ton of security research search engines instantly.