7 ms·

When eBPF meets TLS. Defeating TLS encryption with eBPF tricks [pdf]

112 points by guedou 4y ago

otterley 4y ago
If you have root access to a host, it's pretty much game over, unless the OS vendor doesn't trust even the owner of the hardware/licensee of the software and has taken effective countermeasures against diving deep into the software (Linux, of course, has not). You don't need "eBPF tricks" to observe processes on the host perform traffic decryption. It's just another mechanism for doing so. I wouldn't characterize it as "defeating TLS encryption" either, because it's not like you're decrypting traffic someplace other than on the host you already have privileged access to (and assuming you already have MITM capability, which is by no means assured).
- antmldr 4y ago
  Being at the author's talk earlier today, that wasn't really the spirit that it was given in. The author isn't really talking about "defeating" TLS as a technical control more as he is talking about "defeating" it as an annoyance when reverse engineering. It's meant more as a showcase of how eBPF can be applied to a technical challenge, as opposed to the author claiming they fundamentally broke TLS.
- zokier 4y ago
  > "defeating TLS encryption" I do point out that is editorializing on submitters part, the actual subtitle is "A security focused introduction to eBPF", which is much more descriptive of the content
  - frays 4y ago
    Exactly. As someone fairly new to these concepts, this was a fantastic read. The title just needs to be updated.
- deleted 4y ago
  [deleted]
- znpy 4y ago
  > unless the OS vendor doesn't trust even the owner of the hardware/licensee of the software and has taken effective countermeasures against diving deep into the software (Linux, of courage, has not). This is not entirely true. SELinux does allow you to lock down certain actions while leaving root access available. And of course you can configure selinux to prevent root user from disabling selinux. So you might have root access and the game would not be over.
- MrWiffles 4y ago
  This makes me wonder: what's the worst of side effects if I were to disable eBPF via, say, modifying the boot arguments for the kernel in something like /etc/default/grub.conf? Please correct me if I'm wrong here (I likely am), but isn't the fundamental design of eBPF engineered to allow injection of code into the kernel pertaining to MORE than just network-level stuff? Sure we see it at the network level primarily right now, but what's stopping that from being used for all kinds of things? Short of very specific server-side applications, I see that as all risk, and little-to-no reward, so I'd like it disabled, especially on my personal workstation. Thing is, I know next to jack $#!t about eBPF, so I'm not sure what'll happen to my network (or other stuff?) if I just throw down and do that. Any thoughts? Feasible? Bad idea(TM)?
  - amrb 4y ago
    Sounds like a good weekend project, investigate the effects of disabling ebpf.
  - pabs3 4y ago
    IIRC systemd uses eBPF for some of its sandboxing/security features, so probably some of your services would be more vulnerable to exploits. There are other tools that use eBPF to mitigate specific Linux kernel vulnerabilities, or to do Linux kernel observation/tracing. https://isovalent.com/blog/post/2022-05-16-tetragon/ https://isovalent.com/blog/post/2022-05-16-tetragon/
    - crtxcr 4y ago
      To clarify: systemd uses seccomp to filter system calls. Seccomp employs the older BPF, but not eBPF. There was some work done to make seccomp use eBPF, but so far nothing is merged. eBPF is used in systemd's firewall code though, which allows filtering the IP addresses a service can contact. If this feature is not needed, eBPF can probably be disabled without impacting the other sandboxing features of systemd.
antmldr 4y ago
Great presentation. Any thoughts on including these tricks directly into wireshark to allow fluid decryption at least on the Linux client where CAP_BPF is present?
- deleted 4y ago
  [deleted]
- amrb 4y ago
  Could be a good weekend project, they already allow importing keys for decryptions so most of the work is finding references where openssl, etc stores it.
tptacek 4y ago
Just to clarify what this is probably about, for people who don't do security research (that's what Quarkslab does) --- this is mostly valuable information for people who need to instrument apps under test to see what they're doing. Locked-down TLS is a pain for testers, because, of course, the whole idea is preventing third parties from seeing plaintext. But that's what app testers need to do (usually, to get enough information to write their own tooling-grade clients and servers to use to probe vulnerabilities with). There's a bunch of different tools people use for this purpose; Frida is probably the best-known example, for mobile and native clients. But if your target under test is Linux, modern eBPF gives you enough tooling to capture plaintext without directly instrumenting binaries, which is handy. This isn't, like, per se a vulnerability; they're not saying it is.
- CiPHPerCoder 4y ago
  > This isn't, like, per se a vulnerability; they're not saying it is. "Defeating" is a really poor choice of verb in the title for a post that isn't claiming a vulnerability.
  - tptacek 4y ago
    Meh, I don't think so, any more than "defeating" content protection is a poor choice for an article about testing game and video playback systems. Defeating these things is just a step you have to take to test them.
    - javajosh 4y ago
      "Inspecting TLS encryption with eBPF" would be better, IMHO, as it is less loaded. However the link is ~8 hours old so it is moot at this point.
      - dr_zoidberg 4y ago
        The subtitle for the talk is "a security focused introduction to eBPF". I guess they changed it to give a bit of a heads-up for those just reading the posts title, but it's not the subtitle chosen by the author.
farnulfo 4y ago
Another article about eBPF and TLS : "Debugging with eBPF Part 3: Tracing SSL/TLS connections" https://blog.px.dev/ebpf-openssl-tracing https://blog.px.dev/ebpf-openssl-tracing
kerng 4y ago
There is even a built in script that comes with bpfcc tools called sslsniff. sudo apt-get install bpfcc-tools Also, this might be useful: https://embracethered.com/blog/posts/2021/offensive-bpf-sniffing-traffic-bpftrace/ https://embracethered.com/blog/posts/2021/offensive-bpf-snif...
jay6000 4y ago
Just enable ktls and you can sniff all tls-encrypted data directly from the process

112 points by guedou 4y ago

If you have root access to a host, it's pretty much game over, unless the OS vendor doesn't trust even the owner of the hardware/licensee of the software and has taken effective countermeasures against diving deep into the software (Linux, of course, has not). You don't need "eBPF tricks" to observe processes on the host perform traffic decryption. It's just another mechanism for doing so. I wouldn't characterize it as "defeating TLS encryption" either, because it's not like you're decrypting traffic someplace other than on the host you already have privileged access to (and assuming you already have MITM capability, which is by no means assured).

antmldr 4y ago
Being at the author's talk earlier today, that wasn't really the spirit that it was given in. The author isn't really talking about "defeating" TLS as a technical control more as he is talking about "defeating" it as an annoyance when reverse engineering. It's meant more as a showcase of how eBPF can be applied to a technical challenge, as opposed to the author claiming they fundamentally broke TLS.
zokier 4y ago
> "defeating TLS encryption" I do point out that is editorializing on submitters part, the actual subtitle is "A security focused introduction to eBPF", which is much more descriptive of the content
- frays 4y ago
  Exactly. As someone fairly new to these concepts, this was a fantastic read. The title just needs to be updated.
deleted 4y ago
[deleted]
znpy 4y ago
> unless the OS vendor doesn't trust even the owner of the hardware/licensee of the software and has taken effective countermeasures against diving deep into the software (Linux, of courage, has not). This is not entirely true. SELinux does allow you to lock down certain actions while leaving root access available. And of course you can configure selinux to prevent root user from disabling selinux. So you might have root access and the game would not be over.
MrWiffles 4y ago
This makes me wonder: what's the worst of side effects if I were to disable eBPF via, say, modifying the boot arguments for the kernel in something like /etc/default/grub.conf? Please correct me if I'm wrong here (I likely am), but isn't the fundamental design of eBPF engineered to allow injection of code into the kernel pertaining to MORE than just network-level stuff? Sure we see it at the network level primarily right now, but what's stopping that from being used for all kinds of things? Short of very specific server-side applications, I see that as all risk, and little-to-no reward, so I'd like it disabled, especially on my personal workstation. Thing is, I know next to jack $#!t about eBPF, so I'm not sure what'll happen to my network (or other stuff?) if I just throw down and do that. Any thoughts? Feasible? Bad idea(TM)?
- amrb 4y ago
  Sounds like a good weekend project, investigate the effects of disabling ebpf.
- pabs3 4y ago
  IIRC systemd uses eBPF for some of its sandboxing/security features, so probably some of your services would be more vulnerable to exploits. There are other tools that use eBPF to mitigate specific Linux kernel vulnerabilities, or to do Linux kernel observation/tracing. https://isovalent.com/blog/post/2022-05-16-tetragon/ https://isovalent.com/blog/post/2022-05-16-tetragon/
  - crtxcr 4y ago
    To clarify: systemd uses seccomp to filter system calls. Seccomp employs the older BPF, but not eBPF. There was some work done to make seccomp use eBPF, but so far nothing is merged. eBPF is used in systemd's firewall code though, which allows filtering the IP addresses a service can contact. If this feature is not needed, eBPF can probably be disabled without impacting the other sandboxing features of systemd.

antmldr 4y ago

Great presentation. Any thoughts on including these tricks directly into wireshark to allow fluid decryption at least on the Linux client where CAP_BPF is present?

deleted 4y ago
[deleted]
amrb 4y ago
Could be a good weekend project, they already allow importing keys for decryptions so most of the work is finding references where openssl, etc stores it.

tptacek 4y ago

Just to clarify what this is probably about, for people who don't do security research (that's what Quarkslab does) --- this is mostly valuable information for people who need to instrument apps under test to see what they're doing. Locked-down TLS is a pain for testers, because, of course, the whole idea is preventing third parties from seeing plaintext. But that's what app testers need to do (usually, to get enough information to write their own tooling-grade clients and servers to use to probe vulnerabilities with). There's a bunch of different tools people use for this purpose; Frida is probably the best-known example, for mobile and native clients. But if your target under test is Linux, modern eBPF gives you enough tooling to capture plaintext without directly instrumenting binaries, which is handy. This isn't, like, per se a vulnerability; they're not saying it is.

CiPHPerCoder 4y ago
> This isn't, like, per se a vulnerability; they're not saying it is. "Defeating" is a really poor choice of verb in the title for a post that isn't claiming a vulnerability.
- tptacek 4y ago
  Meh, I don't think so, any more than "defeating" content protection is a poor choice for an article about testing game and video playback systems. Defeating these things is just a step you have to take to test them.
  - javajosh 4y ago
    "Inspecting TLS encryption with eBPF" would be better, IMHO, as it is less loaded. However the link is ~8 hours old so it is moot at this point.
    - dr_zoidberg 4y ago
      The subtitle for the talk is "a security focused introduction to eBPF". I guess they changed it to give a bit of a heads-up for those just reading the posts title, but it's not the subtitle chosen by the author.

farnulfo 4y ago

Another article about eBPF and TLS : "Debugging with eBPF Part 3: Tracing SSL/TLS connections" https://blog.px.dev/ebpf-openssl-tracing https://blog.px.dev/ebpf-openssl-tracing

kerng 4y ago

There is even a built in script that comes with bpfcc tools called sslsniff. sudo apt-get install bpfcc-tools Also, this might be useful: https://embracethered.com/blog/posts/2021/offensive-bpf-sniffing-traffic-bpftrace/ https://embracethered.com/blog/posts/2021/offensive-bpf-snif...

jay6000 4y ago

Just enable ktls and you can sniff all tls-encrypted data directly from the process