Kernel runtime security instrumentation
Kernel runtime security instrumentation
Posted Sep 4, 2019 22:41 UTC (Wed) by kpsingh (subscriber, #112411)In reply to: Kernel runtime security instrumentation by Cyberax
Parent article: Kernel runtime security instrumentation
Also "antivirus" is an overloaded term, I guess you mean it as something that detects and prevents malicious activity based on known signals?
As to what could go wrong? We will find out when we try it :)
Posted Sep 4, 2019 23:23 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (23 responses)
> mitigation based on the audited data
Posted Sep 6, 2019 13:40 UTC (Fri)
by cpitrat (subscriber, #116459)
[Link] (19 responses)
This could also be useful in honeypots.
Posted Sep 6, 2019 16:24 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (18 responses)
> Having ways to react automatically and limit attacker's possibilities is still useful.
Posted Sep 6, 2019 16:53 UTC (Fri)
by cpitrat (subscriber, #116459)
[Link] (17 responses)
This is just one scenario. This seems like a flexible solution that allows for some interesting tools.
Posted Sep 6, 2019 16:54 UTC (Fri)
by cpitrat (subscriber, #116459)
[Link] (1 responses)
Posted Sep 6, 2019 20:33 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Sep 6, 2019 16:58 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (13 responses)
> This is just one scenario. This seems like a flexible solution that allows for some interesting tools.
Posted Sep 6, 2019 18:19 UTC (Fri)
by cpitrat (subscriber, #116459)
[Link] (12 responses)
Posted Sep 6, 2019 20:35 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (11 responses)
Posted Sep 7, 2019 16:47 UTC (Sat)
by kpsingh (subscriber, #112411)
[Link] (10 responses)
Whether you chose to block the specific malicious activity or the host itself is a decision you can make.
Posted Sep 7, 2019 18:44 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (7 responses)
Posted Sep 7, 2019 18:58 UTC (Sat)
by kpsingh (subscriber, #112411)
[Link] (6 responses)
PS: I don't intend to reply further if your communication stays unprofessional.
Posted Sep 7, 2019 19:07 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (5 responses)
All I see is handwaving like:
> There could be dynamic whitelists or blacklists of various sorts, for kernel modules that can be loaded, for instance, to prevent known vulnerable binaries from executing, or stopping binaries from loading a core library that is vulnerable to ensure that updates are done.
For me personally the last thing I want is more of SELinux-style security theater that _will_ inevitably break in various exciting ways.
Posted Sep 7, 2019 19:21 UTC (Sat)
by kpsingh (subscriber, #112411)
[Link] (4 responses)
Patching / deleting a binary on a really huge number of servers cannot be done in seconds.
Can you audit environment variables with audit? No you cannot!
What do you need to do to add support? Change a lot of stuff, the policy language, auditd, parsers etc.
The development cycle for adding a new signal and then some new policy based on the signal, e.g. a permission error if you set the same environment variable twice, touches many components and this is an attempt to fix that.
Posted Sep 7, 2019 20:26 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
> Patching / deleting a binary on a really huge number of servers cannot be done in seconds.
> Can you audit environment variables with audit? No you cannot!
> The development cycle for adding a new signal and then some new policy based on the signal, e.g. a permission error if you set the same environment variable twice, touches many components and this is an attempt to fix that.
Posted Sep 7, 2019 20:52 UTC (Sat)
by kpsingh (subscriber, #112411)
[Link] (2 responses)
>> Patching / deleting a binary on a really huge number of servers cannot be done in seconds.
It's got to do with your statement: "If you have a "vulnerable binary" then why the hell it's not deleted?"
> Do environment variables actually pose a significant threat to warrant a new full-blown, user-controlled arbitrary code injection facility on the critical paths? Can it itself be abused to create livelocks/deadlocks? Can an adversary use it to frustrate efforts to recover? ....
Environment variables is one use case where one needs to use a signal that audit does not currently provide. We are **not** talking about unprivileged eBPF here, it needs CAP_SYS_ADMIN and CAP_MAC_ADMIN. If privileged users want to shoot themselves in their feet, they have plenty other opportunities.
> The development cycle for adding a new signal and then some new policy based on the signal, e.g. a permission error if you set the same environment variable twice, touches many components and this is an attempt to fix that.
I disagree. It's about building defense in depth. The more hoops an attacker has to jump to attack you, the slower and harder it gets for them. Anyways, I am happy to hear if you have a constructive solution. Otherwise, this discussion is simply leading nowhere.
Posted Sep 7, 2019 22:04 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
> It's got to do with your statement: "If you have a "vulnerable binary" then why the hell it's not deleted?"
> Environment variables is one use case where one needs to use a signal that audit does not currently provide.
> I disagree. It's about building defense in depth. The more hoops an attacker has to jump to attack you, the slower and harder it gets for them. Anyways, I am happy to hear if you have a constructive solution. Otherwise, this discussion is simply leading nowhere.
Posted Sep 7, 2019 22:17 UTC (Sat)
by kpsingh (subscriber, #112411)
[Link]
Feel free to go that route and suggest / make improvements to audit. Audit does not meet our other key requirement of having the MAC and signaling (auditing) possible with a single API, which is something that you are not constrained by (based on your comments)
Posted Sep 11, 2019 5:17 UTC (Wed)
by ssmith32 (subscriber, #72404)
[Link] (1 responses)
Posted Sep 11, 2019 5:48 UTC (Wed)
by cpitrat (subscriber, #116459)
[Link]
Otherwise, I can do it too:
Ok you said: "because you're knowingly providing connected resources to a bad actor." But anybody can have connected resources and it's very cheap. Look, I'm using one to answer you.
If you think about a botnet of honeypots, I think your either overestimating the number of honeypots, their lifespan or underestimating the number of hosts required for a useful botnet.
Posted Sep 11, 2019 4:54 UTC (Wed)
by ssmith32 (subscriber, #72404)
[Link]
Yeah, cheap shot, but toooo easy. I'll be quiet now.
Posted Sep 8, 2019 6:48 UTC (Sun)
by jezuch (subscriber, #52988)
[Link] (2 responses)
Posted Sep 8, 2019 7:08 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Unfortunately, the patch authors don't seem to have nearly enough experience with that kind of stuff. Modern Windows antiviruses have multiple layers or defenses, they intrude into the very heart of the OS. Windows itself scans and checksums its internal control structures (PatchGuard, CodeIntegrity), and antiviruses tune it up to 11. Which is kinda awe inspiring - it's like watching CoreWar.
Yet it's still not enough. All the OS protections have been bypassed ( https://www.symantec.com/content/dam/symantec/docs/securi... ) and malware now routinely bypasses antiviruses. This is because attacks don't get worse, they always keep getting better.
Posted Sep 11, 2019 5:05 UTC (Wed)
by ssmith32 (subscriber, #72404)
[Link]
Some rumblings about anti trust later, an API was provided, Symantec realized windows was a dying revenue stream, and you haven't seen much work in the area since. So it's a bit of an unknown.
Posted Sep 11, 2019 4:51 UTC (Wed)
by ssmith32 (subscriber, #72404)
[Link] (1 responses)
{rant}
In other words, there are a few differences too... ;)
Posted Sep 11, 2019 7:51 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Kernel runtime security instrumentation
The only valid mitigation for a detected intrusion is to bring down or isolate the host.
Kernel runtime security instrumentation
Kernel runtime security instrumentation
For example?
Then why not do it from the start?
Kernel runtime security instrumentation
Kernel runtime security instrumentation
Kernel runtime security instrumentation
Kernel runtime security instrumentation
1) A single critical server.
2) Accessible through the Internet.
3) To a script kiddie.
This seems like an overengineered solution for a non-problem.
Kernel runtime security instrumentation
I didn't say there was a single one. There can be multiple one and they all get compromised at (more or less) the same time by the same person.
2) Accessible through the Internet.
If the service is available through the Internet, that's unavoidable. The server could have been exploited through the service it provides.
3) To a script kiddie.
See 2)
Kernel runtime security instrumentation
Kernel runtime security instrumentation
Kernel runtime security instrumentation
And so why does this need yet even more eBPF crap?
Kernel runtime security instrumentation
Kernel runtime security instrumentation
If you have a "vulnerable binary" then why the hell it's not deleted?
Kernel runtime security instrumentation
Kernel runtime security instrumentation
And so will be eBPF. There's also a low-hanging fruit of using BPF to JIT-compile the audit rules.
What does it have to do with audit slowness?
> What do you need to do to add support? Change a lot of stuff, the policy language, auditd, parsers etc.
Do environment variables actually pose a significant threat to warrant a new full-blown, user-controlled arbitrary code injection facility on the critical paths? Can it itself be abused to create livelocks/deadlocks? Can an adversary use it to frustrate efforts to recover? ....
I contend that none of this is even needed, as it's going to be useless and trivial to bypass.
Kernel runtime security instrumentation
^^^^^^^^^^^^^^^^^^^
We are doing performance comparisons and it's not.
> What does it have to do with audit slowness?
> I contend that none of this is even needed, as it's going to be useless and trivial to bypass.
Kernel runtime security instrumentation
Then improve it. Translate audit rules into BPF and run them.
How do you recognize that a binary was used for nefarious purposes?
Then extend it, rather than create a completely new system. Is there anything else that is not covered by audit subsystem and that is not a trivial addition?
The constructive solution is simple - improve audit subsystem instead of adding more eBPF.
Kernel runtime security instrumentation
> Then improve it. Translate audit rules into BPF and run them.
Kernel runtime security instrumentation
Kernel runtime security instrumentation
If you don't isolate the host, you're not being a jerk.
Kernel runtime security instrumentation
Kernel runtime security instrumentation
Kernel runtime security instrumentation
Kernel runtime security instrumentation
Kernel runtime security instrumentation
On the other hand, KRSI is not attempting to call out to central servers, nor is it maintaining a large and ever-growing blacklist in something referred to as a "memory-mapped" file, which actually refers to home brewed code designed to swap memory contents to disk. A list from which nothing can be removed, even if designed to detect old DOS floppy malware, out of fear of failing some dog & pony show that putatively somehow relates to how effective it is. Nor does it incorporate code from a wide variety of engineers that is completely unreviewed and never QA'd. Nor does it attempt to do whatever it can to insert itself wherever it can in kernel memory. And, oh yeah, is produced and managed solely for profit.
{\rant}
Kernel runtime security instrumentation
In case of Kaspersky Antivirus this VM actually is (or used to be as of ~5 years ago) position-independent x86 code that is checked to not include loops or external calls. Kinda like JIT-compiled eBPF :)