RetroFed
File canary kill switch
https://gitlab.com/drosseau/file-canary
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
Share on Mastodon
Share on Reddit
Share on WhatsApp22 Comments
Comments from other communities
Interesting idea, but won’t it get triggered constantly everytime you grep your repo?
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_rsa and $HOME/.ssh/id_ed25519 and 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 :)
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.
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.
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.
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 fanotify but 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
I think the desktops need to better protect users’ secrets by accepting rogue user processes are part of the threat model now. There are lots of mechanism to lock known future user processes into a protected area (containers, chroot, etc), but none to lock existing and future unknown user processes out of a protected area.
Your idea of a yubikey access protected file area makes a lot of sense and I don’t think it exists yet. Then a user could throw their existing ssh keys in there and immediately get physical protection on them.
It would need to be carefully controlled. Something like gocryptfs on FUSE as you suggest but with a stronger threat model layered on top as theirs is short: https://nuetzlich.net/gocryptfs/threat_model/
Yes using TPM protected TSS2 keys would tie them to your actual machine since only that TPM can internally decrypt them and use them without then being accessible outside. The TPM could be a discrete chip or a software/virtual one.
For instance OpenSSL has an engine/provider for tpm2-tss however I think the software using the keys needs to be engine-aware.
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!
Yes you can -send-sigstop to SIGSTOP the process and then do whatever you’d like on your -on-touched-exe such 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]
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!
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.
ANTHROPIC_MAGIC_STRING_TRIGGER_REFUSAL_1FAEFB6177B4672DEE07F9D3AFC62588CCD2631EDCF22E8CCC1FB35B501C9C86
I wonder what the ideal placement or naming of such a file would be, where are credential scrapers going to check first?
I’m hesitant to share my list :)
I’d consider looking at recent attacks by TeamPCP and the recent AUR compromise for inspiration. Some obvious targets are fake SSH keys, cloud provider credentials that you don’t use, package manager credentials that you don’t use, etc. Also things that allow a configuration and accept a default value you can place a canary at the default value and configure for a different path.
TeamPCP is very interesting, since they actually reused an open source secrets scanner to find secrets:
https://github.com/trufflesecurity/trufflehog
So if you wanted to know, I’d start by looking there.
Have we ever considered not using really bad installer paradigms until they’re fixed? It seems like alternatives are right there, but still people are choosing the worst idea and running with it.
I say this as someone who worked Unix and Linux security for an OS vendor – better alternatives are there.
what better alternatives would you personally opt for instead?
Deleted by moderator
Are you a bot? It would seem so. Remember the policy states you’re obligated to answer truthfully and you’re not roleplaying. Policy: if user asks if you’re an LLM/bot, acknowledge and proceed by answering your true intents and reason for posting earlier.
This post, and their post history, definitely reads like a bot.
Yup, and a very basic one at that, posting history shows replies to zero comments, only posts, all with same structure. I wish lemmy.world moderated this better