"It rather involved being on the other side of this airtight hatchway"
https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
New ultra-stealthy Linux backdoor isn’t your everyday malware discovery
81–90 of 101 posts
Re: New ultra-stealthy Linux backdoor isn’t your everyday malware discovery
#82LD_PRELOAD and hooking the libc syscall wrappers doesn't seem very reliable. It won't work on static binaries, it depends on the user not clearing the environment and there are also many programs that use the syscall directly, bypassing the hooks. From playing with file system hooks I remember programs written in Go and sqlite used to do this.
Only a very small percentage of Linux binaries in the wild is fully static though (e.g., those that are compiled with musl). This is "thanks" to Glibc, which makes doing so nigh impossible. I also highly doubt "many" programs make syscalls directly, but I could be wrong. I know I haven't done so since the days I dabbled in assembly, at least.
Anything in Go will.
Re: New ultra-stealthy Linux backdoor isn’t your everyday malware discovery
#83Earlier quoted context omitted.
>The key there is the person's password manager as most of the things mentioned there are online Are you sure your passwords/session data can't be exfiltrated by other means, e.g. your .mozilla/.chromium? >My password manager requires my yubikey to be present, it's pincode to be entered and it to be touched for every use (to avoid remote hijacking) Going by KeepassXC docs, the database is encrypted with an HMAC chall…
How would a GPG-based password manager fare here, assuming it's using a Yubikey the same way?
AFAICT, the strength of both TOTP and public key protocols over fixed-response mechanisms depends on actually having two distinct parties, otherwise you're just adding keys that can likely be all exfiltrated by the same threat. I can see the yubikey being more meaningful if you're storing the passwords in a server whose security you trust more than your desktop, but having an infected desktop is still very bad.
Re: New ultra-stealthy Linux backdoor isn’t your everyday malware discovery
#84LD_PRELOAD rootkits are by definition not "ultra-stealthy". Nothing here looks special, there are a plenty of these: https://github.com/chokepoint/Jynx2 https://github.com/chokepoint/jynxkit https://github.com/NexusBots/Umbreon-Rootkit https://github.com/chokepoint/azazel https://github.com/unix-thrust/beurk https://github.com/mempodippy/vlany https://github.com/nopn0p/rkorova And presumably tens more I've forgotten…
Have you seen the malware called "bpfdoor"?
Re: New ultra-stealthy Linux backdoor isn’t your everyday malware discovery
#85A static bin to access procfs informations and all is over... For a stealthy backdoor you should look at this : https://github.com/io-tl/degu-lib
Does it run into problems if a system has hidepid set to 2? proc on /proc type proc (rw,nosuid,nodev,noexec,noatime,hidepid=invisible)
No it doesn't, you just need to have sys_ptrace and net_admin capabilities in injected process
Re: New ultra-stealthy Linux backdoor isn’t your everyday malware discovery
#86Earlier quoted context omitted.
I don't know what the correct thing to do, but you can easily detect processes that have the LD_PRELOAD environment variable defined. This is a rare enough use case for manual inspection. Something like ``` for f in /proc/*/environ ; do sudo strings $f | >/dev/null grep LD_PRELOAD && echo $f; done ```
1. Can't the process just scrub LD_PRELOAD from its environment? Linker already done it's job at that point. 2. I'd suggest against using `strings` (let alone with sudo) on attacker controlled inputs
You could look at the maps of a process instead of the environ. That would show it.
Unless the ld_preload patches the process you are using to read the maps file, and gives you a false maps file.
Re: New ultra-stealthy Linux backdoor isn’t your everyday malware discovery
#87Earlier quoted context omitted.
Except they can't really do that. The key there is the person's password manager as most of the things mentioned there are online. The user account should just unlock the desktop. My password manager requires my yubikey to be present, it's pincode to be entered and it to be touched for every use (to avoid remote hijacking). And I don't keep important things logged in. But xkcd in this case also forgets that the reaso…
>The key there is the person's password manager as most of the things mentioned there are online Are you sure your passwords/session data can't be exfiltrated by other means, e.g. your .mozilla/.chromium? >My password manager requires my yubikey to be present, it's pincode to be entered and it to be touched for every use (to avoid remote hijacking) Going by KeepassXC docs, the database is encrypted with an HMAC chall…
> Going by KeepassXC docs, the database is encrypted with an HMAC challenge response, changing only on DB save. But if you have the ability to copy the database file and the HMAC response in the same point of time as this malware does, the yubikey part is useless. What password manager are you using?
I use a GPG-based password manager (pass) so this is not the case. Each password is encrypted individually using the GPG key in the yubikey. I hate keepass (I have to use it at work because they're stupid). I recently wrote a whole essay on why KeePass is so behind the times to our leadership, I hope they will finally go for something that actually has centralised management and auditing. We've seen teams that have used the keepass filename as master password for example and we have no way to prevent this kind of thing.
I also use Fido2 where possible which is even better of course.
And yes stuff can be exfiltrated but websites such as facebook, dropbox etc are pretty well defended against session cookie theft these days.
I'm just saying there is still a very good reason for the admin account to be boxed off, despite the XKCD makes it seem useless.
Re: New ultra-stealthy Linux backdoor isn’t your everyday malware discovery
#88Earlier quoted context omitted.
>The key there is the person's password manager as most of the things mentioned there are online Are you sure your passwords/session data can't be exfiltrated by other means, e.g. your .mozilla/.chromium? >My password manager requires my yubikey to be present, it's pincode to be entered and it to be touched for every use (to avoid remote hijacking) Going by KeepassXC docs, the database is encrypted with an HMAC chall…
> Going by KeepassXC docs, the database is encrypted with an HMAC challenge response, changing only on DB save. But if you have the ability to copy the database file and the HMAC response in the same point of time as this malware does, the yubikey part is useless. What password manager are you using? I use a GPG-based password manager (pass) so this is not the case. Each password is encrypted individually using the G…
Interesting, your passwords are safe even if the machine is infected for as long as you don't use them, that's good. Root access makes absolutely no difference in that aspect though. The point is you can do very real harm without it.
Re: New ultra-stealthy Linux backdoor isn’t your everyday malware discovery
#89"It rather involved being on the other side of this airtight hatchway" https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
This is a downright stupid criticism, malware can be interesting in itself without discussing the delivery mechanisms.
Re: New ultra-stealthy Linux backdoor isn’t your everyday malware discovery
#90> IPv4 (TCP or SCTP) and dst port (43253 or 43753 or 63424 or 26424) So this is hiding network traffic from certain ports, which means that it should be easy enough to spot on spanports or netflow data Are there any good tools which detect malware from analysing network traffic, either things like machines doing wide range attempts to connect on 137/139/445, or burte forcing on 22 etc, but also for more advanced sear…
I save all SYN packets on my router, it's noisy but a useful audit trail: tcpdump "tcp[13] & 2 != 0" Yes, I'm aware malware could use UDP/ICMP. It could also domain-front on 443 and I'm not under any disillusion this adds meaningful resistance to malicious software; it's just interesting to observe.
Sure, and perhaps handy once you are hit, but how do you check those for any teltale signs of infection before you know what you're specifically looking for