[HN Gopher] Show HN: Credentials dumper for Linux using eBPF
___________________________________________________________________
Show HN: Credentials dumper for Linux using eBPF
Author : citronneur
Score : 186 points
Date : 2022-07-05 14:44 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| frellus wrote:
| My ignorance, I had no idea eBPF tracing would make grabbing
| people's passwords so easy .. that's quite scary to me. I thought
| it was mostly good for telemetry and deep kernel metrics, but
| this seems like a serious security flaw to me.
|
| Anyone know of any tools to check for abuse?
| AntiRush wrote:
| Unless you enable unprivileged eBPF, root is required to load a
| module. If a user has root there are plenty of ways to get
| passwords.
| frellus wrote:
| Understood, and agreed once you have root access you can get
| passwords but I've not seen many that are this _easy_ , and
| I'm now thinking there's something I need to understand about
| how to detect if certain traces are happening so I can detect
| a potential breach.
|
| Also seems prudent to get rid of passwords and move to
| Kerberos and SSH keys + 2FA. Anything else I'm missing?
| mindwok wrote:
| Looking for specific traces like this is a difficult (but
| still worthwhile) way of detecting a breach, as there's
| potentially infinite things a root user could do once they
| have that level of access.
|
| Another approach is focusing on detecting the privilege
| escalation in the first place. You can use normal auth logs
| in Linux alongside things like auditd, or more complicated
| EDR tools that look for suspicious system calls etc to
| identify root logins that are suspicious, or when a process
| might have been exploited and elevated to root. Make sure
| you're shipping your logs somewhere remotely so they are
| protected from tampering.
| MPSimmons wrote:
| > Also seems prudent to get rid of passwords and move to
| Kerberos and SSH keys + 2FA. Anything else I'm missing?
|
| This is a good path to go down anyway, despite the fact
| that Kerberos, for instance, is totally susceptible to
| 'pass the hash'[1] type attacks. Concentrate on things like
| Yubikey-based authentication. You can do SAML/OIDC2/mTLS
| and SSH with Yubikeys.
|
| Eliminate passwords.
|
| [1] - https://www.beyondtrust.com/resources/glossary/pass-
| the-hash...
| jaimehrubiks wrote:
| Does it grab ssh passwords? (Not sshd password) when a user runs
| ssh from the target server itself to other servers
| amelius wrote:
| Usecases? What was it conceived for?
| citronneur wrote:
| Lateral movement for example
| pdonis wrote:
| So is this an exploit? Or are root privileges on the local
| machine needed to run it?
| mdaverde wrote:
| Root is still needed, so not an exploit. Still a simple
| straightforward example on how to use eBPF/libbpf to grab
| returned data from a userspace function call
| yebyen wrote:
| I've heard `eBPF` described as "like JavaScript for your
| kernel" if the kernel itself was being related to a web browser
| that runs embedded scripts, so, that should give an idea of how
| much and what type of power it brings, as well as the expected
| access level to be able to take advantage of it.
|
| Other uses I've seen for eBPF are inspectors that tell what is
| happening on encrypted connections and the request headers for
| any connection, including authentication details that you would
| expect to be protected. It's great to have this kind of
| capability on systems that you own!
| qdog wrote:
| Pretty much the same as loading an unsigned or untrusted kernel
| module, someone would have to get it loaded from a privileged
| account.
| sdmike1 wrote:
| It appears that you need root, at a minimum the demo gif uses
| sudo to run the program. At an absolute minimum you would need
| CAP_BPF[0] to execute the eBPF.
|
| [0] https://man7.org/linux/man-
| pages/man7/capabilities.7.html#:~...
| freedomben wrote:
| This is not an exploit in itself, but could be very useful for
| pivoting and privilege escalation (across the network). You
| have to have already achieved root on the target machine, but
| once you have obtained that you want to start pivoting to other
| machines which may not have vulnerabilities you can exploit.
|
| The first thing I usually do is dump the /etc/shadow file and
| start up hashcat on it. However this is a very slow and often
| unsuccessful approach. With a tool like this, I would still
| dump the /etc/shadow file but I would also fire this thing up
| so I can obtain passwords as people log in.
|
| The reason this is useful is because most people reuse
| passwords across other systems. If I can get the password they
| use for this system, chances are I just gained access to other
| systems. The mitigation/defense against this is to _always use
| unique passwords_. I 'm already root on this box so getting
| your password benefits me nothing if it's a unique password
| that you haven't used elsewhere.
| freedomben wrote:
| Whoa, awesome work OP this is super neat!
|
| Not only is it an actually useful tool for pen testers, and a
| remarkable PoC for abusing eBPF, but it's a sweet and simple
| example for how to write an eBPF module.
| mdaverde wrote:
| Great clean example of using libbpf.
|
| Latest of libbpf (which seems like you vendored) comes with
| ability to calculate symbol offset for you. Thoughts on using
| that instead of your custom logic?
| citronneur wrote:
| Thanks I will check that!
| sorcix wrote:
| > built as a static binary without any dependencies
|
| > As pamspy rely on libpam, we have to set the path where libpam
| is installed on your distribution.
|
| Confusing text in the readme. Does it have dependencies or not?
| alias_neo wrote:
| You could say libpam is the "target".
|
| Like pointing a disassembler at a shared library, it's not
| needed to run the disassembler, it's the thing you're
| disassembling.
| mdaverde wrote:
| I read this as, due to pamspy setting an eBPF probe, pamspy
| needs to know where libpam.so lives. Not that the pamspy needs
| libpam to be built
| citronneur wrote:
| Exactly, we have to found the address to hook on the system,
| so we need the path of the currently use of libpam by other
| process
| sorcix wrote:
| Oh, makes sense, thanks!
| nicce wrote:
| It is still quite confusing.
|
| > built as a static binary without any dependencies
|
| Static binaries are explicitly used for removing the need for
| specific dynamic runtime dependencies. It does not refer to
| build dependencies, which are not interesting here.
|
| Based on the terms, I would except that libpam is included
| for the final binary.
| freedomben wrote:
| If libpam was compiled in, then this tool would do nothing.
| libpam is not a library for this tool, it's a _target_ ,
| like an input file. libpam is a library for the _kernel_ of
| the target system. this tool hooks into it to do its work.
| nicce wrote:
| Exactly, it is the target. The later phrase pointed out
| in the original comment it to be some sort of dependency
| for runtime use, making the confusion. While it is not
| related to runtime code functionality at all.
| stevenhuang wrote:
| The entire point of this program is that it hooks the func
| inside the libpam.so actively being used by the system for
| auth...
| semiquaver wrote:
| When the author says it "has no dependencies" they are
| referring to build time dependencies (i.e. development headers)
| and runtime _library_ dependencies (dynamic libraries that will
| be linked and used at runtime).
|
| In this case the function of the program is to hook a library
| function in `libpam` using eBPF so it has libpam as a
| "dependency" in roughly the same way that a program which
| converts wav to mp3 depends on "the input wav file".
|
| Given that this is a somewhat unusual way to depend on a `.so`
| file it's reasonable for there to be some ambiguity in the
| language here.
| jeff_vader wrote:
| Can't you achieve same thing with uprobe[1]?
|
| [1]: https://brendangregg.com/blog/2015-06-28/linux-ftrace-
| uprobe...
| citronneur wrote:
| You need uretprobe but also need to read an arg by ref so no I
| don't think so... But thanks for the tip
| staticassertion wrote:
| Anyone know what the status is for enforcing signed eBPF
| programs?
| NavinF wrote:
| Why? eBPF is usually compiled at runtime (so there's no binary
| to sign) and running it inside your kernel requires root.
| mdaverde wrote:
| Running eBPF programs doesn't necessarily require compilation
| at runtime nor root privileges. Look into bpftool's skeleton
| generation as well as CAP_BPF.
|
| With that being said, because eBPF programs _can_ be compiled
| at runtime, it makes signing eBPF programs trickier. The
| kernel team doesn 't want efforts such as bpftrace to be
| stifled.
|
| It seems like the conversation on signing eBPF programs is
| still ongoing with an eye at looking at fsverity to help with
| the use cases here.
| NavinF wrote:
| Hmm I see. I'm still not sure what's the use case and
| threat model.
|
| Is this all for Secure Boot just like signed kernel
| modules?
| shaicoleman wrote:
| Related: TripleCross - A Linux eBPF rootkit with a backdoor, C2,
| library injection, execution hijacking, persistence and stealth
| capabilities.
|
| https://github.com/h3xduck/TripleCross
| citronneur wrote:
| You have also https://github.com/pathtofile/bad-bpf or
| https://github.com/Gui774ume/ebpfkit which are good references
| also
| GRBLDeveloped wrote:
| eBPF is one of those things that I feel like I ought to get in to
| but havent found the time yet. Great app, was it your first
| venture in to eBPF?
| citronneur wrote:
| Yes we also use for https://github.com/airbus-cert/dirtypipe-
| ebpf_detection which is a dirtypipe detection program!
| thedougd wrote:
| I love the animated GIF you included in the readme that shows two
| sessions at once. It made it perfectly clear in moments what it
| does, and how easy it is to use.
| citronneur wrote:
| Thanks!
| IncRnd wrote:
| Well done!
| citronneur wrote:
| thanks !
| Fnoord wrote:
| Back in the days at some point I realized how powerful strace
| was, and ran sshd with it. Fun times. But you can also just sniff
| (or snoop it was called back then) all input done on a tty.
___________________________________________________________________
(page generated 2022-07-05 23:00 UTC)