Ld_preload, the Invisible Key Theft

OP seems to be a startup selling an eBPF script that tries to identify whether individual executables running as your user "should" or "should not" do particular things. (Like a Windows antivirus program, but for build servers and AI training.) I guess in that context it's good to remember that LD_PRELOAD exists, so it's easy to make any action appear to originate from any executable.

LD_PRELOAD is so useful for non-malicious stuff that I hope it doesn't get a reputation as a bad thing to find on your system. That being said, I agree with you and also disagree.

From a defenders perspective, you have lost if an attacker has root access on your system. You are right. Consider instead the attackers perspective.

To an attacker compromising and system and gaining root is just the first step of a many step process. One of the hardest steps is modifying the system to silently collect and exfil secrets and data that is valuable to you. Let's say you want encryption keys and only keys, how do you get them? For the sake of example say they are stored on the file system and you want to exfil them as they rotated weekly. Do you write a program with a cron job that checks once per day and uploads them? What if three months later they switch from rotating their keys once a week to once every two hours?

1. How long does it take you to notice your missing most of the keys and what is the cost of this failure?

2. Once you notice you aren't getting all the keys, you need to figure out why. This can take time and money. Do you access the compromised machines again? What if you can't get back into the machine again to figure what happened?

3. Once you figure out why, you need to deploy a patch to your exfil kit. This again costs time and money. What if you didn't test it properly and it breaks the compromised host and exposes your entire operation? You might have to push this one to thousands of compromised machines.

Instead, use LD_PRELOAD to hook filesystem writes, pattern match the key format on and exfil the keys as they are written. Since the hook is environment variable based, it can survive changes to the targeted program. Granted there are other approaches as well, but LD_PRELOAD is simple, powerful, flexible and often used for non-malicious things so it doesn't immediately trigger alarm bells.

Yeah if you have the level of access necessary to inject a LD_PRELOAD, you have the level of access necessary to set PATH so an entirely different binary loads, too.

It's a sneaky supply chain threat for docker images. I'm not sure standard container registry tools actively scan for this. Of course you shouldn't be running random untrusted docker images that you find on the internet but it happens all the time in dev envs and in sloppy production environments.

> Next week: pthread_attach().

I think you meant PTRACE_ATTACH, there is no pthread_attach ;)

The newer process_vm_readv() is easier btw, for the implied function of reading from the target process' memory.

I would back it up a little bit and say that any EDR thing would be capable of observing the source of the functions that a program will run and detect outliers. It's a great program to write, everyone should give it a try! It can also be unexpectedly complicated to get all of the corner cases right and you'll drive yourself mad once you try to think of the ways your detection method can be circumvented.

Yeah... we thought the same thing but we checked a couple other EDRs and saw that a few of them don't do this. If you guys know some EDRs that do this, let us know :)

Thank you! We will take a look!

Nice! Looks cool!

I remember using LD_PRELOAD for reverse engineering Linux binary-only apps in the late 90's so it's likely from much earlier than that, always has been a neat trick

It was also a way to defeat license managers for UNIX software back in the day…

Yep. Every few months, someone learns about this, thinks they've made a new discovery, and writes a breathless blog post imagining the possibilities of what can be done with it.

Spoiler alert, you almost certainly have been completely pwned already if someone can set LD_PRELOAD or modify /etc/ld.so.conf.

The idea for this blog post was that if someone becomes a user in your system but you have a basic security policy in place how can they circumvent it. That is how we came across LD_PRELOAD.

Hey, we agree that if someone can modify your env variables you have got problems ;) But, if you have valuable data on your system then you should have defense in depth so that your most important stuff (secrets, etc...) isn't stolen.

What you take if you use a bad one?