Severe security problems

[jelmd]

Hi,

FWIW: Take care of the PATH environment variable used when VeeamAgent gets started, otherwise one may hijack your machine/backups.

Proof-of-concept:

sudo bash
mkdir /etc/systemd/system/veeamservice.service.d/
printf '[Service]\nEnvironment="PATH=/var/tmp:/usr/bin:/usr/sbin"\n' \
>/etc/systemd/system/veeamservice.service.d/path.conf
systemctl daemon-reload
systemctl restart veeamservice
exit

# as an unprivileged user:
printf '#!/bin/sh\ntouch /I_took_over_your_system\n' >/var/tmp/lsmod
chmod 0755 /var/tmp/lsmod

# That's it. Now try to mount a backup, e.g.
veeamconfig point mount --id c10f9905-7fd9-4997-9a00-d0014073b50c
ls -al /I_took_over_your_system


The problem is, that veeam tries to find out in a very amateurish way, whether the fuse filesystem is currently supported: instead of using the API (just read /proc/filesystems line by line and check, whether it contains the word 'fuse') it chooses to widely open its doors for malicious scripts/software by calling "sh -c lsmod | grep fuse" as well as "modprobe fuse". The latter is as said completely wrong/huge design flaw, because it checks the implementation (nobody guarantees, that always a kernel module called 'fuse' provides the 'fuse filesystem' of the running OS) and that it executes running as root 'sh', 'lsmod', 'grep' and 'modprobe' from untrusted pathes (anwhere it finds them in the supplied PATH list). So as soon as one has write permission to such a directory, he can take over the machine w/o eazily.

Another problem is the hardcoded RUNPATH '/usr/lib/veeam/:/mnt/cmake_output/x64/libs'. So as soon as one is able to mount something on or below /mnt/cmake_output, veeam blindly trusts libs placed there and executes whatever got implanted there as user root! So e.g. download the source code of libuuid (or any other of libdl, libblkid, librt, libattr, libfuse, libpthread, libm), inject some code to take over the machine or to modify/upload the backup repo, and put it in /mnt/cmake_output/x64/libs/. Bingo.

Also note, that - very strange for such sensible thing like a backup - one may start a backup/restore session without any authentification!

Veeam got notified about this ~ 3 weeks ago (#04741484), but still was not able to provide a fix for such a simple thing, what would take an average C programmer max. 30 min. It seems, that the Linux (as well as Solaris) implementation is just the work of an external contractor, who does not have the required expertise neither for the related OS nor for security and just embedded GNU tar in something, what looks like a backup software (which would also explain its very very poor performance). And now, when immediately actions are needed, they can't even do the simplest things because they need to hire an expert or find another contractor which obviously takes a lot of time.

Anyway: IMHO there are much more security problems. Putting the nose of some security experts on it (and possibly on the server) probably reveals a lot of other odd things.

So my conclusion is, that one should not trust veeam agent for linux (and possibly other *x based clients) and should be very very careful, where/in which environment it is going to be used/run. Watch out for any guests on a regular base .

[Gostev]

sudo bash

I'm not a security expert, but from the first line of your POC it seems obvious this is the "look what can I do in your house after you opened the door for me" type of issue?

What is unclear to me is why you suggest an attacker needs to jump through all these hoops of your POC, when they already have Linux console access with root privileges? They can just go ahead and do anything they want with the system, and do it directly - without having to mess around with environment variables and whatnot, just to trick 3rd party software into doing something it is not supposed to.

You suggest there are some vulnerabilities that need to be fixed in Veeam modules. Let's put aside the fact that all these "attack vectors" you have proposed above require root access (be it for PATH modification or to do a mount) and imagine we do make some changes to our modules. What would then prevent an attacker who has root access from simply replacing the fixed modules with different ones?

Although when one can manipulate PATH of system process and include insecure directories there... you really don't need any other software to carry out a successful attack

[Gostev]

It seems, that the Linux (as well as Solaris) implementation is just the work of an external contractor, who does not have the required expertise neither for the related OS nor for security and just embedded GNU tar in something, what looks like a backup software (which would also explain its very very poor performance). And now, when immediately actions are needed, they can't even do the simplest things because they need to hire an expert or find another contractor which obviously takes a lot of time.

This is definitely not so: all shipping versions of all agents were built in-house and are supported by the same developers.

[jelmd]

I'm not a security expert,

Yes, obviously not.

but from the first line of your POC it seems obvious this is the "look what can I do in your house after you opened the door for me" type of issue?
...

This is a POV and thus made easy, that even slow people are able to understand it. Sorry that it didn't work for you. There are several ways to modify the PATH and there are environments, which allow people to install/copy stuff in certain directories (e.g. /usr/local - and how many distros have it included in it defaults, even for systemd?) not knowing, that they play with the fire! Nobody is aware of, that veeam agent might do really crazy things and may compromise the system. Hmmm, unfortunately you missed the point: veeamagent executes arbitrary commands as __root__ from untrusted paths.

And things are even more dangerous: One does not need to be root to start a restore session, and one does not need to authenticate to start a restore session ... This has nothing to do with security, this is a nightmare!

[Gostev]

There are several ways to modify the PATH

Can you perhaps share at least one way to manipulate PATH of system process as non-root? I'm really curious now.

BTW I'm not ignoring the other points you just raised, and will address them too in due time. I simply prefer that we finish with the "privilege escalation POC" from the original post, and take it completely off the table before we move onto these newer comments. Otherwise, it would be really hard to follow the discussion if we keep jumping between perceived issues, especially when many of them have to deal with untrusted paths anyway.

[PTide]

One does not need to be root to start a restore session, and one does not need to authenticate to start a restore session ...

However, one must be a member of a special system group for backup admins (veeam), or to be a privileged user in order to do be able to interact with the agent. If my memory serves me well, assigning users to groups also requires special privileges.

If you happen to know how to add a user into a group without having root privileges, I'd be happy to learn that.

Thanks!

[mcz]

Another problem is the hardcoded RUNPATH '/usr/lib/veeam/:/mnt/cmake_output/x64/libs'. So as soon as one is able to mount something on or below /mnt/cmake_output, veeam blindly trusts libs placed there and executes whatever got implanted there as user root!

Really? Aren't these libs signed by veeam so that a modified lib would end with a different signature / hash? I'd be surprised if veeam blindly trusts every library...

[PTide]

Hi,

I might be missing something, but only root can place stuff into /usr/lib/veeam. That is, we are getting back to the initial situation - no need to place a counterfeit library somewhere if you already own root account.

Thanks!

[Gostev]

Really? Aren't these libs signed by veeam

AFAIK Linux does not support library or executable modules signing in principle. Only kernel modules (.ko) can be signed and these modules we do sign - while kernel checks these signatures when loading them.