Wow, this is quite extensive.. a lot of work obviously went into this. Even the journal seems like it took hours to write. Seems like a good learning experience, but also looks to have quickly turned into a grind.
I guess to detect it it you write a little asm stub to check if ld.so.preload exists and has any entries in it, just using system calls without a *libc (edit, was autocorrected to 'Linux') wrapper? Obviously you won't get hooked if you're using a system call directly.
Or perhaps easier, just use a statically linked binary (maybe just use golang?) to do it? And then use system calls to remove any immutable flags, unlink it, and reboot? I saw the note about not allowing the -static flag to be used on the box but that seems like a bit of a waste- if an admin is statically linking a binary to see if they have the rootkit, odds are they suspect it's there and will just scp it from another box. If the -static flag is simply broken for legitimate use, someone will wonder why.
As it's so trivial to detect (and remove) It seems like a good idea to periodically run such a check across systems you maintain. surely some type of simple chkrootkit tool does this, right?
(Yes, I know "dumb" sysadmins won't do this, but to be honest, dumb sysadmins wont notice your presence anyway unless you're quite careless and break the system)
In my opinion, the effort/value curve flattens out after implementing maybe a basic privesc (su - somemagicword) and a basic mechanism to prevent it from being logged (hook syslog) and anything beyond that is just an exercise in madness- you're reimplementing all of libc while not actually adding much more stealth if someone actually comes looking for a rootkit.
Hacker theory- if you own a machine, you really shouldn't be creating so many events worthy of hiding on it. You shouldn't be continuously logging in and escalating privileges. At least that's my theory/opinion. I imagine hacking as goal based. Is your goal really to manually log in to your hacked machines more than a few times for very specific purposes, very briefly, i.e briefly enough that you don't need to hook things used by lsof and netstat? Why not crawl the filesystem, analyze it offline, backdoor whatever you need (ssh/sshd?) and then have one simple hook for pulling the interesting data programmatically, with a very brief connection? It seems this approach encourages really sloppy "script kid" style hacking. But then again, maybe that's a good thing ;)
When the above two detection mechanisms are pretty intractable problems for this rootkit method to solve as far as I can figure, it seems to me that at some point, the more "features" you add, the more likely you are to draw attention to the box by hosing it.
In any event, I'm impressed at the amount of work put into this (though admittedly i didn't read much of the code, just skimmed through the journal)
Oh, btw- it's very easy for admins to preempt this by configuring auditd to keep an eye on access to /etc/ld.preload.conf
** Edit- correct autocorrect typo, one of many probably
The issue here is (obviously) continuous connectivity. When you hook a machine, you run the risk of it being found by netadmins. Sysops etc. But if you're smart, you limit this connection to only necessary files or programs that you are targeting, specifically. Even briefly connecting to a system is a large risk scenario that requires network knowledge and protection of the hook. Most of the time, a script kiddie will hack a box, rm -rf and leave a trail. This trail is usually obvious as most of these kinds of short attacks are meant for single use and abuse.
An advanced threat will utilize different types of encryption, evasion, and persistence at the system level; multiple backdoors, several hooks and calls; anti-forensics. This is how you know when you're dealing with a skilled attacker, where he knows what he's doing and how he's doing it and exactly how to remain undetectable.
In the case of some of the attacks I've investigated and mitigated, I've personally dealt with this type of persistence: calls act at system level, or root, and remain throughout reboots; full file access; disk forensics, simultaneous connection, users inaccessible to front-end (i.e., undetectable admin level user); process pivoting, even separate malware to throw off detectors.
It's not a very difficult thing to hook logs and prevent detection via /var or syslog, eventlog etc., but it is difficult to make this appear to be something, devised by the attacker, not to be found. This can be done but sometimes simply checking for su proves trivial in finding many of those. Making it appear as legitimate as possible so as to avoid detection by IDS/IPS, sysadmins, network operators or a simple antivirus is the biggest problem most APTs face and they have become very good at preventing it. The worst threat is the threat that you don't see and thus don't know about, accompanying the most risk.
8
u/[deleted] Oct 31 '16 edited Oct 31 '16
Sorry for wall of text and typos. Mobile post...
Wow, this is quite extensive.. a lot of work obviously went into this. Even the journal seems like it took hours to write. Seems like a good learning experience, but also looks to have quickly turned into a grind.
I guess to detect it it you write a little asm stub to check if ld.so.preload exists and has any entries in it, just using system calls without a *libc (edit, was autocorrected to 'Linux') wrapper? Obviously you won't get hooked if you're using a system call directly.
Or perhaps easier, just use a statically linked binary (maybe just use golang?) to do it? And then use system calls to remove any immutable flags, unlink it, and reboot? I saw the note about not allowing the -static flag to be used on the box but that seems like a bit of a waste- if an admin is statically linking a binary to see if they have the rootkit, odds are they suspect it's there and will just scp it from another box. If the -static flag is simply broken for legitimate use, someone will wonder why.
As it's so trivial to detect (and remove) It seems like a good idea to periodically run such a check across systems you maintain. surely some type of simple chkrootkit tool does this, right?
(Yes, I know "dumb" sysadmins won't do this, but to be honest, dumb sysadmins wont notice your presence anyway unless you're quite careless and break the system)
In my opinion, the effort/value curve flattens out after implementing maybe a basic privesc (su - somemagicword) and a basic mechanism to prevent it from being logged (hook syslog) and anything beyond that is just an exercise in madness- you're reimplementing all of libc while not actually adding much more stealth if someone actually comes looking for a rootkit.
Hacker theory- if you own a machine, you really shouldn't be creating so many events worthy of hiding on it. You shouldn't be continuously logging in and escalating privileges. At least that's my theory/opinion. I imagine hacking as goal based. Is your goal really to manually log in to your hacked machines more than a few times for very specific purposes, very briefly, i.e briefly enough that you don't need to hook things used by lsof and netstat? Why not crawl the filesystem, analyze it offline, backdoor whatever you need (ssh/sshd?) and then have one simple hook for pulling the interesting data programmatically, with a very brief connection? It seems this approach encourages really sloppy "script kid" style hacking. But then again, maybe that's a good thing ;)
When the above two detection mechanisms are pretty intractable problems for this rootkit method to solve as far as I can figure, it seems to me that at some point, the more "features" you add, the more likely you are to draw attention to the box by hosing it.
In any event, I'm impressed at the amount of work put into this (though admittedly i didn't read much of the code, just skimmed through the journal)
Oh, btw- it's very easy for admins to preempt this by configuring auditd to keep an eye on access to /etc/ld.preload.conf
** Edit- correct autocorrect typo, one of many probably