VIM Config Simple Backdoor
In this section, we’ll continue our look at dotfiles by using the VIM text editor’s
configuration file to backdoor the editor and exploit an unsuspecting user.
The VIM editor is a widely used command line text editor on Linux
and it (or its predecessor vi)
is installed on nearly all Unix and Linux systems by default.
It is well known for its extensive functionality and, as a result,
presents us with an opportunity for exploitation.
On many Linux systems, user-specific VIM configuration settings
are located in a user’s home directory in the .vimrc file.
This file takes VIM-specific scripting commands and configures the VIM
environment when a user starts the application.
These commands can also be run from within the editor by typing a colon character,
followed by the desired command
For example, if we want to print a message to the user,
we can use the echo command.
The commands specified in the .vimrc file are executed when VIM is launched.
By editing this file, we can cause a user’s VIM session to perform unintended
actions on their behalf when VIM is run.
Let's begin by running unauthorized scripts.
If VIM is not set to use a restricted environment, we can use it to run
shell commands from within the config file by prepending the ! character.
For example, if we want to create a file somewhere on the system, we can enter
a bash command in the configuration file, prepended with an exclamation point.
Let’s create a new SSH session with this machine.
When we launch VIM,
our command is executed,
and the file is created.
Putting our commands directly into the user’s .vimrc file isn’t particularly
stealthy, as a user modifying their own settings may accidentally discover
the changes we’ve made.
There is, however, another option.
We can “source” a shell script using the bash source command.
This will load a specified shell script and run it for us during the normal
configuration process.
This approach provides only a slight level of obfuscation,
since a user is less likely to dig deeper into these referenced files.
We can also import other VIM configuration files into the user's current config,
with the :source command.
Note that the source call for loading a VIM configuration file is prepended with
a colon and not an exclamation point, which is used for shell commands.
As a more stealthy approach we can leverage the VIM plugin directory.
As long as the files have a .vim extension,
all VIM config files located in the users’s ~/.vim/plugin directory
will be loaded when VIM is run.
In our lab machine, let’s say we have compromised the offsec user,
and we have a working shell.
We can modify the user’s .vimrc file in their home directory,
and add a new line.
This will load and run a shell script,
called .vimrunscript from the user’s home directory.
In a real-world scenario, it might be useful to pick a file path outside
the user’s home directory but for simplicity, we’ll keep it here.
Next, we can create the shell script file.
This script echoes the word “hacked” to a file called /tmp/hacksrcout.txt.
If we try to run VIM now,
we get an obvious debug output message
explaining that we’re sourcing a configuration file.
This is obviously undesirable as it would tip off the user.
Luckily, VIM has a built-in command for this, the :silent command.
This command mutes any debug output which would normally be sent to the user
when running VIM.
We’ll change our line in the user’s .vimrc file to include the silent command.
With the file updated, let’s try again.
This time when we run VIM,
our file opens, and we don’t get any suspicious messages.
If we check the /tmp/ directory,
we find that our test output file was created successfully.
This is handy for triggering scripts when a user opens a file in VIM,
but it doesn’t really give us much more access than we already have.
We’ve got a shell as the user, so we can do most things they can.
However, if the user has sudo access, we may be able to do more.
In most cases, users with sudo rights are required to enter their password when
performing activities with elevated permissions via the sudo command.
We can’t perform activities as root via sudo
because we don’t know the user’s password.
We can weaponize this VIM vector to gain root privileges if the user runs VIM
as root or uses the visudo command.
Note that VIM handles its configuration files differently for a user in a sudo
context depending on the distribution of Linux.
In some systems such as Ubuntu and Red Hat, VIM will use the current user’s .vimrc
configuration file even in a sudo context.
In other distributions, such as Debian, in a sudo context,
VIM will use the root user’s VIM configuration.
In an assessment on an Ubuntu, Red Hat, or similar system, if the user runs VIM
via sudo, our script being sourced will also run as root.
Because of this, we will achieve root access without any extra effort.
On a Debian or similar system that does not persist the user’s shell environment
information when moving to a sudo context, we can add an aliasthe user’s .bashrc file
An alias is just a shortcut to substitute a different command when a specified
command is entered on the command line.
This alias replaces a standard sudo call with one that will force sudo to
persist the user’s VIM settings.
The shell script being loaded will then also run as root.
We will need to source our .bashrc file from the command line if we want the alias
changes to go into effect right away.
In some cases, users are given limited sudo rights to run only specific programs.
We can check this from a shell using the sudo -l command as the linuxvictim user.
This limited access can be set in the /etc/sudoers file,
with the same syntax as this highlighted line.
When a command is specified at the end of the line,
the user can run sudo only for that command.
In this case, the linuxvictim user has the ability to use VIM as sudo
only to open the important.conf file.
In this case, a password is not required for sudo access.
Because of this, we can run VIM with sudo,
and then enter :shell to gain a root shell automatically.
If a password was required, we could use the previously discussed alias vector
to gain root access with our backdoor script.
We’ve discussed a way to run scripts via a VIM backdoor, but what happens if the
environment is restricted and won’t allow shell access?
In the next section we'll examine a method for creating a rudimentary “keylogger”
through VIM that operates even in a restricted VIM session.