5 ms·

I am currently trying to combine my EDR agent that I wrote over the last 2 years for POSIX systems in Go + eBPF and the Hypathia project [1] which actually was

I am currently trying to combine my EDR agent that I wrote over the last 2 years for POSIX systems in Go + eBPF and the Hypathia project [1] which actually was very promising but is now inactive because the author gave up. So far the approach still seems promising, but I would need more devs to help me as I'm contributing in my free time and I won't accept funding for my cyber security related projects, ever. Would be nice if some other folks feel the same way as you and we can revive the Hypathia project to be better in the sense of eBPF process analysis, in-memory modification detection, and network analysis via XDP. [1] https://github.com/Divested-Mobile/Hypatia https://github.com/Divested-Mobile/Hypatia

saagarjha 2y ago
I don't have the time, sorry. Too much on my plate! But I (and I apologize in advance for this) can tell you that one of the reasons why I would not have that much time for this is that I don't think it is fundamentally interesting in the face of a sophisticated adversary. Scanning files and memory or whatever is largely irrelevant in the age of exploits that completely compromise the device, all the way to a privilege level higher than where the actual scanner operates. Signatures fall apart if it is very cheap to evade them (and it is, with trivial modifications to payloads). Typical approaches to catching malware do not apply to zero-day attacks. They may sometimes work but my point in the comment above was to point out that this is just luck rather than a sustainable practice. Someone who knows you are looking for them can hide and lie far harder than you can possibly imagine. And if they've broken the system, they can use those very protections that were supposed to keep them out to prevent you from going after them. Kind of like how a castle is designed to prevent people from storming it, up until they actually sneak in and all those defensive measures stop you from retaking it ;)
- cookiengineer 2y ago
  But the issues you're describing are literally where the eBPF kernel module chimes in and what the process analysis is about, no? You can detect a lot of malicious behaviour this way, where programs and processes deviate from their usual behaviour; e.g. trying to access files they're not supposed to.
  - saagarjha 2y ago
    Someone with a kernel-level exploit can completely neuter your eBPF detection. They can make it never return data, or return bogus/benign data. You can try to catch them in that lie, but it's really hard, and even if you do they can just stop your process from being able to report on it. Again, a real-life analogy might help: it is really, really hard to protect yourself against a criminal who has the cops on their side. You're definitely not going to be allowed to go into the crime scene yourself, so you have to trust what they're telling you. All your complaints are going through them. If a dirty cop doesn't like you your life can get a whole lot worse!
    - cookiengineer 2y ago
      The point of eBPF is that eBPF receives and processes data _before_ the kernel does.
      - stefan_ 2y ago
        Thats just not true? Your eBPF programs run in a VM in the kernel, occasionally JITed, but of course the kernel is free to feed them whatever data it wants.
        cookiengineer 2y ago
        Where does your hypothesis come from? Any architecture chart will point out that XDP will be processed before all other network modules. If XDP is not offloaded, the driver will always process the XDP hooks before the rest of the network stack is called. In your assumed concept, how else would offloading to a NIC that does not run a kernel work?
        h4ck_th3_pl4n3t 2y ago
        I think there is a misunderstanding of the two perspectives. Grandparent's assumption is that the kernel is compromised. Your assumption is that you can detect malicious behaviour before it happens (and before the kernel is compromised).

saagarjha 2y ago

I don't have the time, sorry. Too much on my plate! But I (and I apologize in advance for this) can tell you that one of the reasons why I would not have that much time for this is that I don't think it is fundamentally interesting in the face of a sophisticated adversary. Scanning files and memory or whatever is largely irrelevant in the age of exploits that completely compromise the device, all the way to a privilege level higher than where the actual scanner operates. Signatures fall apart if it is very cheap to evade them (and it is, with trivial modifications to payloads). Typical approaches to catching malware do not apply to zero-day attacks. They may sometimes work but my point in the comment above was to point out that this is just luck rather than a sustainable practice. Someone who knows you are looking for them can hide and lie far harder than you can possibly imagine. And if they've broken the system, they can use those very protections that were supposed to keep them out to prevent you from going after them. Kind of like how a castle is designed to prevent people from storming it, up until they actually sneak in and all those defensive measures stop you from retaking it ;)

cookiengineer 2y ago
But the issues you're describing are literally where the eBPF kernel module chimes in and what the process analysis is about, no? You can detect a lot of malicious behaviour this way, where programs and processes deviate from their usual behaviour; e.g. trying to access files they're not supposed to.
- saagarjha 2y ago
  Someone with a kernel-level exploit can completely neuter your eBPF detection. They can make it never return data, or return bogus/benign data. You can try to catch them in that lie, but it's really hard, and even if you do they can just stop your process from being able to report on it. Again, a real-life analogy might help: it is really, really hard to protect yourself against a criminal who has the cops on their side. You're definitely not going to be allowed to go into the crime scene yourself, so you have to trust what they're telling you. All your complaints are going through them. If a dirty cop doesn't like you your life can get a whole lot worse!
  - cookiengineer 2y ago
    The point of eBPF is that eBPF receives and processes data _before_ the kernel does.
    - stefan_ 2y ago
      Thats just not true? Your eBPF programs run in a VM in the kernel, occasionally JITed, but of course the kernel is free to feed them whatever data it wants.
      - cookiengineer 2y ago
        Where does your hypothesis come from? Any architecture chart will point out that XDP will be processed before all other network modules. If XDP is not offloaded, the driver will always process the XDP hooks before the rest of the network stack is called. In your assumed concept, how else would offloading to a NIC that does not run a kernel work?
        h4ck_th3_pl4n3t 2y ago
        I think there is a misunderstanding of the two perspectives. Grandparent's assumption is that the kernel is compromised. Your assumption is that you can detect malicious behaviour before it happens (and before the kernel is compromised).