3 ms·

This is a nice POC, but would be detected pretty fast in "real world". That "printf" hiding hook seems to be specifically tailored to one command (bash's "set"

by theamk 3y ago

This is a nice POC, but would be detected pretty fast in "real world". That "printf" hiding hook seems to be specifically tailored to one command (bash's "set"? "env"?). Any other command to look at environment which does not use printf would show LD_PRELOAD just fine. I, for example, routinely use "strings" to examine environ of desktop processes - try intercepting that. There is also sorted(os.environ.keys()) from Python, and env dump at the start of CI jobs... Not to mention that even if variable itself is perfectly hidden, the preload action itself is visible. LD_PRELOAD-ed libraries show up in "ldd" output, and in "strace" output as well, and in "gdb" outputs. The "propagation" part is just appending to ~/.bash_profile, which is trivially discoverable as well. You can "cat" the file and it'd be right there, or if you have some sort of VCS for you dotfiles, they will flag file as having been changed. With enough imagination, you can figure a way to bypass most of those detection method.. but that "most" is not going to be enough. In the hypothetical example of xz-like attack, you only need one slip-up for such worm to be quickly detected, brought to light, and countermeasures brought up. (targeted attacks are much scarier, but they aren't likely to use such a crude method anyway... even PATH mangling is more subtle that that!)

wolfendin 3y ago
The real world of 2024, or the real world when this software was written?
- theamk 3y ago
  Good point actually, the article says "late 1990's".. but most things would still work back then. I believe ldd, strace, procfs all existed back then. Python would not, but one could dump environment using perl or some unusual shell. Keeping dotfiles in version control was be much more rare, so that detection method would not work back then. But the shell variety was much greater back then, so the worm could end up on server with tcsh or ksh or rsh (the "restricted shell") which would render it inert. And there was a chance of ending up on Solaris box which would just throw errors about wrong architecture and cause immediate discovery. Also, there were many more shared systems, so granting "sudo" access to everyone was much less frequent back then. And we could have friendly sysadmins examine someone's configs file if they ask for help, which would lead to discovery as well.
  - wolfendin 3y ago
    I think thres’s also been a large sea change in the thinking that happens in finding the reason for anomalous behavior. Nowadays remote compromise is one of the first things on my mind when troubleshooting but, back in the 90s it was much lower on the list. I think the tooling would have been there to find it easy, but I think getting in the mindset where it needs to be found would be harder.
planede 3y ago
The "printf" hiding is probably too crude and tailored to bash. But I don't see why the so file couldn't just modify the environment once it's loaded.
cookiengineer 3y ago
> but would be detected pretty fast in "real world". I call bullshit on that one. When did you last cat your bashrc? Every morning? Probably not. Nobody ever knows what kind of environment variables are modified inside /proc fs. Nobody. The ones that do uninstall glibc.
- theamk 3y ago
  Maybe don't interpolate your experience so much? Not everyone is in the Web/AI space, there are still system programmers out there. My bashrc is under version control, so any changes would immediately appear if I do "status" command.. for me this was last week. (For the record, I have no desire to uninstall glibc, I like my DNS working than you very much.) The environment variables are pretty simple, and you should really take your time to learn them. When I help others troubleshoot their systems, one of my first steps is to look at their environments for anything suspicious, this is solving at least 30% of all the problems. And sure, sometimes they are somewhat mysterious ("UBUNTU_MENUPROXY=1"?) but you can often guess from context. But the most important thing is, a self-propagating worm has no idea which machine is it getting into - is it going to be old server which people want to touch as little as possible? Or is it a dev machine of a C++ programmer (or even worse, build engineer) who know every .so file and "strace" things daily? So while there might be specific orgs where such worm can live for a while, it will be found once it gets to a wider audience.

by theamk 3y ago

wolfendin 3y ago

The real world of 2024, or the real world when this software was written?

theamk 3y ago
Good point actually, the article says "late 1990's".. but most things would still work back then. I believe ldd, strace, procfs all existed back then. Python would not, but one could dump environment using perl or some unusual shell. Keeping dotfiles in version control was be much more rare, so that detection method would not work back then. But the shell variety was much greater back then, so the worm could end up on server with tcsh or ksh or rsh (the "restricted shell") which would render it inert. And there was a chance of ending up on Solaris box which would just throw errors about wrong architecture and cause immediate discovery. Also, there were many more shared systems, so granting "sudo" access to everyone was much less frequent back then. And we could have friendly sysadmins examine someone's configs file if they ask for help, which would lead to discovery as well.
- wolfendin 3y ago
  I think thres’s also been a large sea change in the thinking that happens in finding the reason for anomalous behavior. Nowadays remote compromise is one of the first things on my mind when troubleshooting but, back in the 90s it was much lower on the list. I think the tooling would have been there to find it easy, but I think getting in the mindset where it needs to be found would be harder.

planede 3y ago

The "printf" hiding is probably too crude and tailored to bash. But I don't see why the so file couldn't just modify the environment once it's loaded.

cookiengineer 3y ago

> but would be detected pretty fast in "real world". I call bullshit on that one. When did you last cat your bashrc? Every morning? Probably not. Nobody ever knows what kind of environment variables are modified inside /proc fs. Nobody. The ones that do uninstall glibc.

theamk 3y ago
Maybe don't interpolate your experience so much? Not everyone is in the Web/AI space, there are still system programmers out there. My bashrc is under version control, so any changes would immediately appear if I do "status" command.. for me this was last week. (For the record, I have no desire to uninstall glibc, I like my DNS working than you very much.) The environment variables are pretty simple, and you should really take your time to learn them. When I help others troubleshoot their systems, one of my first steps is to look at their environments for anything suspicious, this is solving at least 30% of all the problems. And sure, sometimes they are somewhat mysterious ("UBUNTU_MENUPROXY=1"?) but you can often guess from context. But the most important thing is, a self-propagating worm has no idea which machine is it getting into - is it going to be old server which people want to touch as little as possible? Or is it a dev machine of a C++ programmer (or even worse, build engineer) who know every .so file and "strace" things daily? So while there might be specific orgs where such worm can live for a while, it will be found once it gets to a wider audience.