Hacker News Reader

Comment by tptacek | Hacker News Reader

Let's try a little exercise here. Stipulate that it's malice, and then generate the narrative in which malice makes sense.

Specifically:

You are whatever entity (I assume the FSB?) that can demand Kaspersky implant backdoors into its desktop antivirus software.

You decide to target that backdoor at the component of Kaspersky's software that gets, by design, unrestricted access to the plaintext of all TLS sessions on the machine, in addition to practically unrestricted access to every file on machine itself, and to the machine's memory in cpl0 and cpl3.

From that vantage point, you decide to...

... collide certificates?

Remember, your evil backdoor only impacts machines running your software already. From this thread, I'm wondering if that's maybe unclear to people.

View on HN

Let's continue your exercise. Your backdoor gets detected by any security researcher. You're busted, your business is near destroyed, you cause diplomatic stress between nations and, you face criminal charges. The stakes are way too high.

So instead you consider ways to introduce vulnerabilities that leave plausible deniability.

Indeed, from that vantage point, you decide to...

... collide certificates.

So you propose that they created a backdoor that regularly and sporadically breaks TLS for normal users because they are evil geniuses who needed a plausibly stupid backdoor in case they got caught.

Not only are there better plausibly deniable backdoors they could use from this vantage point, but there are NOBUS backdoors they could use from this vantage point. You propose an attacker so clever that they've carefully calibrated the sophistication of their backdoors, but not clever enough to know how to backdoor a TLS MITM (a TLS MITM installed by design) without leaving the absurd tracks this one does.

No. It's not a conspiracy. As usual: it's just a bug.

>Let's try a little exercise here. Stipulate that it's malice, and then generate the narrative in which malice makes sense.

Sure. Kaspersky creates security software. The FSB benefits from vulnerabilities in antivirus software. Kaspersky knows this and puts company resources into particular areas. ie how to spot the next stuxnet, rather than fix bugs like this.

The FSB does not need to write the source code (for Kaspersky Anti-virus) to benefit from vulnerabilities. In fact NSA, GCHQ, and FSB all benefit from subversion of https.

You can't stop at that point in my comment. You have to read the whole thing first. I'm not asking "does it ever make sense to backdoor Kaspersky AV". Clearly it does.

I did. You created a ridiculous narrative, that seems to amount to a strawman. No one ever said that FSB wrote the antivirus program.

My narrative has in fact nothing whatsoever to do with the FSB. That's why I said "whatever entity".

"your evil backdoor only impacts machines running your software already. " seems to assume that "whatever entity" can freely put in whatever code they want.

I agree that cert collisions is a strange way to backdoor, but to dismiss any questions as to possible malice as "conspiracy theories" seems to ignore many recent events (such as Juniper Networks)

Once again, you're responding to an argument I did not make. I'm not saying this bug doesn't make sense because nobody would want to backdoor Kaspersky AV. Clearly they would. I'm saying it doesn't make sense because it doesn't make sense as a backdoor. It provides the attacker with far less access than they already have, and does so in a way that leaves tracks all over the Internet even when the "backdoor" isn't "in use".

Know what else you said doesn't make sense as a backdoor, times a million?

And this makes way more sense than that one did. Not that I'm convinced that it is one. But if it is, it's a pretty good one IMO.

Did you read the link? It describes an attack where you only need to have access to the same network as the target. Perhaps through that smart lightbulb they just installed?

Yes, I did read the link. Do you understand the thread? The proposal is that this bug in Kaspersky's kernel code is a backdoor in Kaspersky's kernel code --- that is: an attacker that already owns your OS kernel is backdooring it to come up with an extremely convoluted and noisy way to get access to your TLS sessions --- by backdooring the part of their kernel code that already has access to every TLS session on the machine.

The described attack doesn't sound convoluted at all, it seems very practical.

Once again: the attacker here already controls TLS on the machines that are affected. They don't need to collide certificates. By design, they not only have the plaintext of every TLS session on the machine, but they are also the client side of every TLS session originating from the machine (they terminate TLS locally and proxy it over a new connection they control).

I feel like the people claiming this is a smoking gun backdoor don't really understand what it means that Kaspersky's software is designed to proxy TLS. Yes: it is batshit that they proxy TLS. It's so batshit that this particular bug makes absolutely no sense as a backdoor. That idea is Xzibit-level crazy.

I see what you mean now. If you wanted to make a backdoor and have plausable deniability, you'd make it a bug.

Yes, but you would not make it this bug, which (a) doesn't get you any access you don't already have, and (b) leaves a trail of sporadically broken TLS connections so obvious that they show up in CT logs.

No, you don't understand. They already had that access, but in order to exploit it they (hypothetically) need a sneaky way to do so. Hence the bug.

From the vantage point they have now they have approximately 18 bazillion ways to generate a backdoor that yields control of the entire machine to an arbitrary person on the network. The fact that virtually every backdoor ever created works this way, and not by creating an elaborate set of circumstances through which you can get access to specific TLS sessions, is not an accident.

But even in the bizarro world --- which I do not concede that we live in but will briefly stipulate to --- where you would backdoor kernel AV software that looks at TLS plaintext solely to give people the ability to get access to TLS plaintext, this still doesn't make sense. They terminate TLS locally. They are the client to every TLS session originating from the machine. They don't need to create a noisy 32 bit certificate collision, so noticeable to the Internet it shows up in CT logs, to accomplish this task. They can backdoor TLS itself in a zillion plausibly deniable ways that would give network observers access to plaintext.

What if they don't need control of the entire machine? Such a backdoor could be much more conspicuous. What if the NSL they were handed only called for intercepting TLS traffic as a means of surveillance?

Ironically, the backdoor that provided access to the whole machine would be far less conspicuous than this one. That's the thing about the human cognitive bias towards narratives: RCE vulnerabilities in AV are found routinely, and don't land on the top of HN. This bug did because it was so cosmically stupid, it's surprising nobody noticed it before --- something Ormandy repeatedly states in his writeup.

Which is all the more reason not to believe that it's enemy action.

Well, I don't know much about Windows and I don't know much about the design of this software, but let's speculate some more. I imagine that on Windows, you have to have escalated permissions to modify the certificate store. I also imagine that if you were writing a piece of software that could do this (i.e. AV), you wouldn't always be running everything as root (so to speak). I would guess that most RCEs wouldn't lead to being able to modify the certifiate store.

It's kernel code.

Sure. Presumably not all of it is, though. I'm guessing most RCEs for this software don't happen in the kernel. Ring 0 RCE certainly does make the news, I would imagine.

I'm lost. I literally don't even know what you're arguing about anymore.

We're arguing? In any case, I'm lost too. Have a good one!

Reply on news.ycombinator.com