Hacker News Reader

Comment by woodruffw | Hacker News Reader

The TSA's response here is childish and embarrassing, although perhaps unsurprising given the TSA's institutional disinterest in actual security. It's interesting to see that DHS seemingly (initially) handled the report promptly and professionally, but then failed to maintain top-level authority over the fix and disclosure process.

View on HN

It’s very hard for management, even IT managers, to fully understand what such things mean.

I’ve seen huge issues, like exposed keys, being treated as a small issue. While an outdated js library, or lack of ip6 support being escalated.

I’m sure TSA and their partners wants to downplay potential exposure, I’m also sure it’s hard for a lot of their managers to fully understand what the vulnerability entails (most likely their developers are downplaying their responsibility and pointing fingers at others)

This is the Transportation SECURITY Agency. If the managers involved here can't understand why this is a huge deal, they're exceptionally unqualified for their jobs.

Edit: Fixed a double negative (previously: This is the Transportation SECURITY Agency. If the managers involved here can't understand why this is a huge deal, they're not exceptionally unqualified for their jobs.)

> If the managers involved here can't understand why this is a huge deal

Was it a huge deal though?

It was the most humongous deal if we talk about IT security. SQL injection shouldn't be a thing in today's IT landscapes. And here we are giving everyone and their mother admin access to a database where the attackers can literally get not only on a plane but also in the fucking Cockpit. So yes, big big deal.

> where the attackers can literally get not only on a plane but also in the fucking Cockpit.

You can easily get on a plane, you buy a ticket to board it.

People try and succeed to get weapons through TSA checkpoints. I don't know what the idea is though. If you want to shoot and kill someone, do it at the security checkpoint, as happened at Domodedovo. People hijacked planes because the media covered it. You could also hijack busses. I don't know. What is the threat model?

Bag handlers smuggle drugs. I don't know. Airports are fairly porous.

I don't think this little SQL hack gets you into a cockpit. I suppose I could also buy an ordinary ticket, change in the bathroom into pilot clothes, and then bluff my way in. It should be obvious what personal facts about me make that easier for me than for someone else.

Do you see what I mean? This isn't a big deal. It's fun to be dramatic about that's for sure. IMO the large number of high drama personalities in the "security" field - when you are a customer, and on the other side, the technical person is high drama - is harmful to security goals.

Or you could buy a real ticket, bypass security with this (and whatever you have in your bags), then hijack an international flight full of fuel.

This isn’t hard to exploit.

TSA spends $6.3 billion per year on screening operations. Someone being able to bypass the entire apparatus of airport screening using a SQL injection attack is a really big deal.

It wasn’t an sql injection in their code. It was a third party issue.

So internally the question would probably how can you open it up responsibly.

Closing the api is probably a support nightmare; they probably gave too many rights and too little safety checks.

If this is not a huge deal, than we don’t really need the TSA at all.

Probably, they can and do understand it. They just have a deny/deflect culture.

Part of being a good manager is knowing how to get good folks to give you advice on things you don't understand, and knowing how to follow that advice. Yeah, its hard- but that's a huge part of the whole dang job!

No manager (or human) is perfect, mistakes happen- we need to be humble enough to listen and learn from mistakes.

Well said. One of my friends came to cyber management from a legal background. You'd better believe my buddy is calling the most respected nerd in the building when learning about a possible vulnerability. Knowing your technical limitations and where to go to get answers is an important skill for tech managers.

>> The TSA's response here is childish and embarrassing,

> It’s very hard for management, even IT managers,

I'm confident that the grandparent's comment is correct.

TSA is closer to the issue than HSA; I'd wager big that they sense embarrassment.¹²

TSA management would have immediate access to people capable of framing the issue correctly, including their own parent agency. Their reaction was never going to be held back by technical facts.

    ¹ US Sec/LEO/IC agencies have a long and unbroken history of attacking messengers that bring embarrassment. There is ~no crime they are more dedicated to punishing.

    ² The worlds easiest presupposition: Discussions took/are taking place on how they might leverage the CFAA to deploy revenge against the author.

TSA is security theater, it is there to give the illusion of security. In reality it seems more like the goal is the entrenchment of surveillance and the appearance of strength.

> It's interesting to see that DHS seemingly (initially) handled the report promptly...

I think DHS mid level manager yelled at a TSA mid level manager who reported this to the senior TSA officials and then their usual policy kicked in... deny/deflect/ignore

TSA is DHS, though. At some point, it's the same high-level manager...

What was surprising to me was that they didn't immediately do pre-dawn raids on the pentesters' homes and hold them without a lawyer under some provision of an anti-terror law.

that is apparently not a popular move anymore since people keep logs and have credentials, strong social media presence and readily available cloud enabled cameras. one email to any news org and whoever authorizes the raid will probably face some music. but knowing TSA, we can expect this any minute now...

They just add you to a secret watch list to annoy you when you travel when you're critical of them... or the current administration, so it would seem.

Why bother if they could just put everyone involved on the "dangerous terrorist" list which has zero controls and zero accountability because "national security"?

That's what happened to Tulsi Gabbard: https://www.racket.news/p/the-worm-turns-house-senate-invest...

That's not really how this works. TSA is maliciously incompetent, but there is a reporting pipeline and procedure for these things that's formalized and designed to protect exactly this kind of good-faith reporting[1].

(It's very easy to believe the worst possible thing about every corner of our government, since every corner of our government has something bad about it. But it's a fundamental error to think that every bad thing is always present in every interaction.)

[1]: https://www.cisa.gov/report

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?

The DoJ announced in 2022 that they would not prosecute "good faith" security researchers, but it's not binding, just internal policy: https://www.scmagazine.com/analysis/doj-wont-prosecute-good-...

The policy (https://www.justice.gov/jm/jm-9-48000-computer-fraud) explicitly states at the end that it's for guidance only / does not establish rights, and it includes a provision for additional consultation on cases involving terrorism or national security–terms which have both been overloaded by the government to justify overreach in the past.

Personally, given the history of the CFAA, I wouldn't want to be in a position to test out this relaxed guidance on prosecuting good-faith researchers, but perhaps I'm unnecessarily averse to the idea of federal prison.

> 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 talking to policy people: it's not 1993 (or even 2013) anymore, and there's a much better basal understanding of security researchers vs. someone trying to secure a "get out of jail free" card for doing something they shouldn't have. That doesn't mean the government can't mess up here, but I can't remember a prominent example of them throwing the book at a good faith report like this in the past decade.

(Swartz is who I think of as an example of an extreme miscarriage of justice under an overly broad interpretation of the CFAA. And, of course, there could be facts in this situation that I'm not aware of that would motivate a criminal or civil CFAA investigation here. But "pre-dawn raids" aren't really it in situations like this one.)

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

The FBI did raid this guy in 2016 after what was seemingly an attempt at responsible disclosure of leaked medical records: https://arstechnica.com/information-technology/2016/05/armed...

And this journalist last year, though the facts of this story are less clear and obviously not responsible-disclosure related: https://www.cjr.org/the_media_today/tim-burke-florida-journa...

Well yeah, I personally don't pen-test random websites without a clear terms or bug bounty program.

I generally agree with you, but I would worry that an overzealous agency would be fine with finding and reporting the SQL injection vulnerability but object to the author creating an obviously fake record. It's hard to know exactly where the line is.

the more safe way is to have a US congress member read the report into a hearing....as the funny thing is that US has a law and rule that a congress person is not breaking the law if reading something into a hearing...sort of US Congresses own SQL injection....

I can't decide whether it would be considered an SQL injection or a SSRF attack, actually. I'm leaning towards the latter. Or maybe even a reflected XSS?

Even better, it's not a law, it's a provision of the Constitution. Article 1, Section 6 lets members of Congress say whatever they want on the floor.

>'...there is a reporting pipeline and procedure...'

---

Here is the next YC: An app that uses AI to navigate all the Civil Injections and allow the easist way to contact, petition, complain, praise, poll, explain a law, measure etc ELI5.

Get OpenAI and/or Amazon (Given they run DataCenter Infra for CoIntelPro) - since they have/seek government contracts - and have Massive AI - make them create a USA-GPT.gov and its the most informed bot that will connect you to, explain, write-your-[representative/lobbiest/committee], and these companies have to provide these govGPTs in order to maintain any federal/defense contracts.

Yeah, I don't know if I would go testing such systems and then reporting the results under my own name (presumably)...

I didn't see any comment about them being contracted to do this at least.

There's still _plenty_ of time for that to happen. I wouldn't want to be this person right now. I like my dog alive.

I was thinking. They seem much more likely to react that way to public disclosure, and losing face as a result than from a professional looking private disclosure that they (either the org, or someone further up the org chart) can pretend never happened.

Reply on news.ycombinator.com