I wrote a dead simple file canary tool that will install an eBPF program that drops all outgoing packets if a canary is touched. I wrote this in response to the current trend of supply chain attacks that try to harvest credentials
You must log in or register to comment.
- IanTwenty@piefed.socialEnglish16 hours
Thanks to these attacks I think creds got to all move to physical security keys so there’s nothing to (digitally) steal any more.This tool is a good idea for the short term.
- 16 hours
I agree, for serious secrets you should have something physical involved.
I spent a bit of time exploring some mechanism to encrypt files on disk and require a yubikey press to decrypt them transparently for the process requesting access, but I didn’t really come up with a solution I liked. The idea there would be you’re prompted “/usr/bin/safe wants to access secret.key, but it is marked as sensitive, decrypt and allow?”. The notification part would be easy with
fanotifybut it wasn’t entirely clear to me the best way to perform the decryption. I think storing the secret on a FUSE file system could work? Things like https://github.com/rfjakob/gocryptfs come to mind
- 16 hours
This is really cool. I appreciate you sharing it. I’m currently building out my homelab to try out various softwares and scenarios, and one of the things I’m worried about is malicious software sneaking in, and compromising my LAN.
In the case that something does, this essentiallyy provides a tripwire which leaves all the evidence intact while stopping the bleed (unless it has a VM escape, but that’s another story).
In any case, this is very useful and I’m really glad you made it. Thanks!
- 13 hours
Yes you can
-send-sigstopto SIGSTOP the process and then do whatever you’d like on your-on-touched-exesuch as attach via ptrace, dump all memory, etc. My current one will send a notification and dump the memory of the offending process.Definitely pay attention to the warning about running this on a server. With a KVM attached in a home lab you should be able to easily recover I guess. I think you could also set yourself up a little UDP service to SIGUSR1 the daemon since incoming packets are not dropped, but I haven’t tested that.
[Note: intelligent malware can handle the SIGSTOP fairly easily. You could try to move the process to a new cgroup and then freeze the cgroup, as well, but there is a lot to consider here obviously]
- 15 hours
This should definitely not be run on a server unless you really know what you’re doing. You will lose all connectivity and you will never be able to get it back by normal means!
- 13 hours
Uh yeah, that’s the whole idea. I can always just bring it offline and mount the root as a separate disk to a different VM to investigate.
- 13 hours
Or even just log in via serial console, but that’s not a capability I have coded in yet.
- 13 hours
I guess what I’m saying is I match the “really know what you’re doing” criteria.
- 19 hours
Interesting idea, but won’t it get triggered constantly everytime you grep your repo?
- 19 hours
There is a very high chance there are files you will never use that a credential harvester would be interested in. For example some look for certain wallets that I definitely don’t have, so I create a canary file for that. You can also add
$HOME/.ssh/id_rsaand$HOME/.ssh/id_ed25519and then use nonstandard key names for your typical key usage etc.I’ve been running this for a week now with no lost connections yet :)
- 19 hours
Okay, so not for protecting actual creds then. Makes sense, although would be nice to have a way to protect actual creds. No idea how that would be achievable though.
- 19 hours
Right it’s just for things you don’t use but a credential harvester would find interesting.
I’ve been working a lot on containing the blast radius with some careful LXC usage, but this was a quick way to get some real value without a ton of thought.