“Know thy Linux” – The Satori Suite

I present you Satori (悟り). A tool for snapshoting and comparing Linux Directory Trees.

   ▄████████    ▄████████     ███      ▄██████▄     ▄████████  ▄█  
  ███    ███   ███    ███ ▀█████████▄ ███    ███   ███    ███ ███  
  ███    █▀    ███    ███    ▀███▀▀██ ███    ███   ███    ███ ███▌ 
  ███          ███    ███     ███   ▀ ███    ███  ▄███▄▄▄▄██▀ ███▌ 
▀███████████ ▀███████████     ███     ███    ███ ▀▀███▀▀▀▀▀   ███▌ 
         ███   ███    ███     ███     ███    ███ ▀███████████ ███  
   ▄█    ███   ███    ███     ███     ███    ███   ███    ███ ███  
 ▄████████▀    ███    █▀     ▄████▀    ▀██████▀    ███    ███ █▀   
                                                   ███    ███ 

First of all, you can find it here: Link (github repo) and it is under the well-known beerware license.

Now, let’s get started:

As in the README.md from the repo:

"Satori" is a Japanese Buddhist term for awakening, "comprehension;
understanding" [...] enlightment. en.wikipedia.org/wiki/Satori

So the tool is named after the spontaneous feeling of absolute knowledge, the spontaneous mindblow, a researcher feels when he/she finally understands what exactly is happening in a system or network!

I first heard that term (more like read it) in Tom Robbins’ book: “Tibetan Peach Pie: A True Account of an Imaginative Life“, where he (the author) felt the Satori while watching the movie : “Shoot the Piano Player“.

The rest of the tool (that is: all except the name) was inspired by the SPSE course I attended this year (and haven’t arranged the exams yet – the “Never do now what you can do later” syndrome).

<Typical paragraph about the course>

I believe it is a great course, and if you are on “Offensive” python and can spare the price (it hurts a bit), just buy it and get the cert. It’s gonna teach you many more things than python. For me, its title should have been “How to be MacGyver using only a PC and Python“. Movin’ on…

</Typical paragraph about the course>

 

The Satori’s Reason of Existence

I like CTFs. The day I found out that there is something called “Vulnhub” I cried out of joy and got lost in my bedroom for days. Must have lost some weight too. But Ι finally found a general pattern…

Every boot2root VM has a way to get the limited shell and then there is the Privilege Escalation part. There aren’t really many ways to get that limited shell though. Most of the time there is a web page with a glaring (or not so much) exploit or misconfiguration. There are some exception to this (/dev/random: Sleepy) is a great one – no spoils.

So assuming that we have a limited shell, the real game starts. The privesc part is really the heart of it all. Getting other users and the root is a matter of how well someone knows Linux fundamentals, reversing and the whole BOF bandwagon, service defaults, and other details. Most of the time a binary exploit (from exploit-db) does the thing, as the systems are heavily unpatched (as they are outdated) but this is what I name “cheating”, as those VMs are made for educational purposes and apart from cross-compiling binaries there aren’t many things to learn from auto-root exploits.

So how to get root? There is a different scenario every time. But generally there is a misconfiguration that can be exploited badly. A great example of this is the SickOS 1.1 VM. There is something there that can be misused. So where is it?

There is a way to find that little thing that will give you the # prompt. There are tools and cheatsheets that will highlight you some places to look first. An example is rebootuser’s Enumeration cheatsheet. They really do a good job, but they need your prior knowledge of how things “should be” for you to examine how “they are” and what is the exploitable difference.

An example here can be the find command for SUID executables. That is:

find / -perm -4000 2>/dev/null  # the famous "2>/dev/null" omits error output

and the output is :

/usr/bin/mount
/usr/bin/chage
/usr/bin/gpasswd
/usr/bin/newgrp
/usr/bin/chfn
/usr/bin/su
/usr/bin/chsh
/usr/bin/umount
/usr/bin/sudo
/usr/bin/pkexec
/usr/bin/crontab
/usr/bin/passwd
/usr/sbin/unix_chkpwd
/usr/sbin/usernetctl

This is the kind of answer expected from such cheatsheet commands. They return you raw data. Which execs are SUIDs? Here! Those are. Do whatever pleases you with them. You can’t know if su has a backdoor. Or if they are really old (exploitable?) versions (looking at you sudo). Are those the standards? Is there something that shouldn’t be there?

These are the question that Satori tries to answer. Generally speaking, the author of the VM has planted a misconfiguration in the Linux system, that wasn’t there by default. And the only way to find it is to be sure about what IS there and what ISN’T in the original distro installation. This needs some serious experience and knowledge of distro specifications. So if you haven’t been a Linux admin by now (say you are just 20 years old) how possibly can you get this knowledge? Can’t all that knowledge be extracted and used ?

Yes! It can! That’s what Satori does.

 

How?

Satori has 3-ish tools. It is more like a suite than a single tool. It is under heavy development (so many things can be done better) and is considered 30% alpha / 70% beta, but it works just fine now. It started as a Proof of Concept tool-chain, and now that it really works it needs some major rewrites. The developer’s sweet hell…

The tools are an “Imager”, a “Browser” and a “Differ”. There is also a “Remote” module that is nothing more than a module that runs the “Imager” tool to a remote system.

So, please welcome the stars of the show:

Satori-Imager

The Satori Imager crawls the whole file system and collects metadata in the whole directory structure. It excludes some directories by default but this is configurable. It finally packs all this data in a tree-structured dedicated format for use with the other Satori tools. The dedicated format is nothing more than serialized (pickled or json’ed) Python dicts compressed with gzip.

The information that gets collected is generally everything a file has except timestamps and inode info. So privilege bits, owner, group, size even a SHA2 hash are included. Optionally the output of file command and even its actual content (for text files) can be collected as well. The Satori images also contain metadata about the system such as user that did the image dump, date of the image dump, system ‘uname -a‘ and more.

Satori-Browser

Satori Browser is a tool that loads those image files and spawns a custom UNIX-like shell in the underlying File System. The user can freely ‘ls‘, ‘cd‘ and ‘stat‘ all files in the FileSystem image.

The shell’s capabilities depend on the choices made when creating the image, for example: if Satori Imager was configured to dump text content of files then, also, a ‘cat‘ command would be available.

{Satori} sickos@SickOs / $ 
{Satori} sickos@SickOs / $ 
{Satori} sickos@SickOs / $ ls
tmp    bin    sbin    lib    selinux    opt    mnt    etc    vmlinuz    srv    usr    var    lost+found    initrd.img
{Satori} sickos@SickOs / $ cd /etc
{Satori} sickos@SickOs /etc $ stat passwd
    SHA2 : N/A
    group : 0
    privileges : 0100644
    filename : passwd
    owner : 0
    path : /etc
    type : N/A
    size : 1103
{Satori} sickos@SickOs /etc $

and finally :

 

Satori-Differ

This tool needs 2 Satori images and finds the differences file by file. It outputs both a log with every changed file and the field that has been changed and a tree that visualizes those changes. The logs are created to be “greppable” (printed to stdout, contain keywords) while the tree is colored to indicate the type of change in every file (and printed to stderr to be unaffected by grep).

 

Ok, so let’s use it. Let’s root a machine with Satori.

We are gonna use the SickOS 1.1 Vulnhub VM for example of privesc with Satori. It is considered an easy VM, doesn’t need a debugger or sophisticated methods, but it demonstrates perfectly the “out of place” concept that Satori tries to tackle.

Here we go (screenshot mode: ON)

Screenshot from 2016-08-14 20-06-06

We do some magic to get to the SSH shell (this article is not a walkthrough, we need the shell to do the demonstration, walkthroughs are available in Vulnhub).

So hocus pocus SSH shell:

Screenshot from 2016-08-14 20-13-32.png

So this is the time for Satori-Imager through SSH. I present you Satori-Remote:

Screenshot from 2016-08-14 20-25-39.png

It uses the classic user@host argument for the SSH connection, prompts for a password, uses the standard -[q|v|d] verbosity flags and passes everything in the –argument flag to the real Satori-Imager, which will be to also collect all hashes from the remote filesystem. It also prints the remotely executed Satori-Imager’s output in a grey font color.

Screenshot from 2016-08-14 20-29-45.png

We got the Satori Image file! Did I mention how small these files are, comparing to the information they contain?

Ready for the diffing!

Wait… We don’t have any original Satori Image for Ubuntu 12.04 server! A bummer…

Luckily, I have created a repo in Github where I upload Images for heavily used Linux Distros. You can have it all: satori-images. They will be outdated soon, but they work. Configuration files do not change very often.

It just so happens that “satori-images/ubuntu_server/Linux-3.13.0-32-generic-i686-with-Ubuntu-12.04-precise_HASH.jsn.gz” is available.

Now we are ready:

Screenshot from 2016-08-14 20-30-13.png

First goes the Image filename that should be considered “Original“, next the “Dirty” one and finally the full path of the directory that should be diffed. Generally a “/” will do, but the difference tree will be huge (consider system updates, apt’s package folder, all those system files that change silently), so we need to specify a directory that contains most valuable info. “/etc/” that is! We also use quiet mode to omit the banner and “2>/dev/null” to omit the printed tree (for now). We have something like:

./satori-differ.py ../satori-images/ubuntu_server/Linux-3.13.0-32-generic-i686-with-Ubuntu-12.04-precise_HASH.jsn.gz Linux-3.11.0-15-generic-i686-with-Ubuntu-12.04-precise_HASH.jsn.gz /etc/ -q 2>/dev/null

Go:

Screenshot from 2016-08-14 20-57-36.png

A mess! What were we thinking? We asked for ALL changes in /etc/ folder. Here we are. We got them… The output is almost 3 pages. The screenshot contains only the last one.

Now let’s start filtering out useless log lines, so we will eventually find the useful info.

We can see many files in  /etc/ssl/certs that are not in the original Image. That is acceptable, no misconfiguration here. So let’s Unix Kung Fu through the results. (Actually just “grepminusVing” keywords).

./satori-differ.py ../satori-images/ubuntu_server/Linux-3.13.0-32-generic-i686-with-Ubuntu-12.04-precise_HASH.jsn.gz Linux-3.11.0-15-generic-i686-with-Ubuntu-12.04-precise_HASH.jsn.gz /etc/ -q 2>/dev/null  | grep -v "/ssl/certs"

Screenshot from 2016-08-14 21-06-25.png

2 Pages! What are all those font files? They have been installed afterwards. Maybe apache did that. Generally there are many apache conf files, while our Original image has no apache installed. So let’s omit all lines with “fonts” and “apache” in them. Also “mysql“, “squid“, and “php” fall under the same category.

./satori-differ.py ../satori-images/ubuntu_server/Linux-3.13.0-32-generic-i686-with-Ubuntu-12.04-precise_HASH.jsn.gz Linux-3.11.0-15-generic-i686-with-Ubuntu-12.04-precise_HASH.jsn.gz /etc/ -q 2>/dev/null  | grep -v "/ssl/certs" | grep -v "fonts" | grep -v "apache" | grep -v "mysql" | grep -v "squid" | grep -v "php"

And we get this output (with bold all changes that are considered bogus) :

[EXISTENCE] File '//etc/lvm' exists in the original but not in the given image!
[EXISTENCE] File '//etc/nologin' exists in the original but not in the given image!
[EXISTENCE] File '/etc/alternatives/cc' is not existent in the original image.
[EXISTENCE] File '/etc/alternatives/c89' is not existent in the original image.
[EXISTENCE] File '/etc/alternatives/c99' is not existent in the original image.
[EXISTENCE] File '/etc/alternatives/c89.1.gz' is not existent in the original image.
[EXISTENCE] File '/etc/alternatives/c99.1.gz' is not existent in the original image.
[EXISTENCE] File '/etc/alternatives/cpp' is not existent in the original image.
[EXISTENCE] File '/etc/alternatives/cc.1.gz' is not existent in the original image.
[ALTERATION] File '/etc/group' size differs. Original is of size 667 bytes and given is 712 !
[ALTERATION] File '/etc/group' has different hash !
[ALTERATION] File '/etc/popularity-contest.conf' has different hash !
[ALTERATION] File '/etc/init/network-interface.conf' size differs. Original is of size 1069 bytes and given is 803 !
[ALTERATION] File '/etc/init/network-interface.conf' has different hash !
[ALTERATION] File '/etc/console-setup/cached.kmap.gz' has different hash !
[ALTERATION] File '/etc/localtime' size differs. Original is of size 3519 bytes and given is 265 !
[ALTERATION] File '/etc/localtime' has different hash !
[ALTERATION] File '/etc/ssh/ssh_host_rsa_key' size differs. Original is of size 1679 bytes and given is 1675 !
[ALTERATION] File '/etc/ssh/ssh_host_dsa_key.pub' has different hash !
[ALTERATION] File '/etc/ssh/ssh_host_ecdsa_key.pub' has different hash !
[ALTERATION] File '/etc/ssh/ssh_host_rsa_key.pub' has different hash !
[ALTERATION] File '/etc/ssh/ssh_host_dsa_key' size differs. Original is of size 668 bytes and given is 672 !
[ALTERATION] File '/etc/shadow' size differs. Original is of size 774 bytes and given is 900 !
[ALTERATION] File '/etc/hosts' has different hash !
[EXISTENCE] File '/etc/update-motd.d/95-hwe-eol' exists in the original but not in the given image!
[ALTERATION] File '/etc/group-' size differs. Original is of size 663 bytes and given is 699 !
[ALTERATION] File '/etc/mailcap' size differs. Original is of size 2226 bytes and given is 2293 !
[ALTERATION] File '/etc/mailcap' has different hash !
[ALTERATION] File '/etc/issue' has different hash !
[ALTERATION] File '/etc/passwd-' size differs. Original is of size 1034 bytes and given is 1088 !
[ALTERATION] File '/etc/issue.net' has different hash !
[ALTERATION] File '/etc/fstab' size differs. Original is of size 690 bytes and given is 739 !
[ALTERATION] File '/etc/fstab' has different hash !
[ALTERATION] File '/etc/apt/sources.list' size differs. Original is of size 3357 bytes and given is 3353 !
[ALTERATION] File '/etc/apt/sources.list' has different hash !
[ALTERATION] File '/etc/apt/apt.conf.d/01autoremove-kernels' has different hash !
[ALTERATION] File '/etc/lsb-release' has different hash !
[ALTERATION] File '/etc/gshadow-' size differs. Original is of size 551 bytes and given is 584 !
[ALTERATION] File '/etc/rc.local' size differs. Original is of size 306 bytes and given is 343 !
[ALTERATION] File '/etc/rc.local' has different hash !
[ALTERATION] File '/etc/init.d/sudo' size differs. Original is of size 690 bytes and given is 700 !
[ALTERATION] File '/etc/init.d/sudo' has different hash !
[ALTERATION] File '/etc/apparmor.d/cache/.features' size differs. Original is of size 1332 bytes and given is 1095 !
[ALTERATION] File '/etc/apparmor.d/cache/.features' has different hash !
[ALTERATION] File '/etc/udev/rules.d/70-persistent-cd.rules' size differs. Original is of size 535 bytes and given is 803 !
[ALTERATION] File '/etc/udev/rules.d/70-persistent-cd.rules' has different hash !
[ALTERATION] File '/etc/udev/rules.d/70-persistent-net.rules' size differs. Original is of size 471 bytes and given is 659 !
[ALTERATION] File '/etc/udev/rules.d/70-persistent-net.rules' has different hash !
[CHMOD-ED] File '/etc/ssl/private' has different privileges! Originals are 040700 and given are 040710 !
[CHOWN-ED] File '/etc/ssl/private' has different group! Original group is 0 and the file's group is 113 !
[ALTERATION] File '/etc/default/grub' size differs. Original is of size 1225 bytes and given is 1224 !
[ALTERATION] File '/etc/default/grub' has different hash !
[ALTERATION] File '/etc/default/locale' size differs. Original is of size 19 bytes and given is 33 !
[ALTERATION] File '/etc/default/locale' has different hash !
[ALTERATION] File '/etc/gshadow' size differs. Original is of size 555 bytes and given is 594 !
[EXISTENCE] File '/etc/resolvconf/update-libc.d' is not existent in the original image.
[ALTERATION] File '/etc/resolvconf/resolv.conf.d/original' size differs. Original is of size 44 bytes and given is 23 !
[ALTERATION] File '/etc/resolvconf/resolv.conf.d/original' has different hash !
[ALTERATION] File '/etc/shadow-' size differs. Original is of size 677 bytes and given is 900 !
[ALTERATION] File '/etc/ca-certificates.conf' size differs. Original is of size 7464 bytes and given is 6961 !
[ALTERATION] File '/etc/ca-certificates.conf' has different hash !
[ALTERATION] File '/etc/timezone' size differs. Original is of size 17 bytes and given is 14 !
[ALTERATION] File '/etc/timezone' has different hash !
[EXISTENCE] File '/etc/logcheck/ignore.d.paranoid' is not existent in the original image.
[EXISTENCE] File '/etc/logcheck/ignore.d.workstation' is not existent in the original image.
[ALTERATION] File '/etc/hostname' has different hash !
[ALTERATION] File '/etc/os-release' has different hash !
[ALTERATION] File '/etc/initramfs-tools/conf.d/resume' has different hash !
[ALTERATION] File '/etc/passwd' size differs. Original is of size 1037 bytes and given is 1103 !
[ALTERATION] File '/etc/passwd' has different hash !
[ALTERATION] File '/etc/mtab' size differs. Original is of size 556 bytes and given is 510 !
[ALTERATION] File '/etc/mtab' has different hash !
[ALTERATION] File '/etc/ld.so.cache' size differs. Original is of size 15807 bytes and given is 18695 !
[ALTERATION] File '/etc/ld.so.cache' has different hash !
[EXISTENCE] File '/etc/cron.d/automate' is not existent in the original image.

The “rc.local” has changed! This means that a command runs at reboot. As we have SSH let’s read it!

Screenshot from 2016-08-14 21-33-02.png

It loads iptables firewall rules. We couldn’t care less. We are in now!

And what is this “automate“?

Screenshot from 2016-08-14 21-34-11.png

Boom! This python file will run as root once every minute… If only it is world-writable…

We could see that via the SSH shell, but let’s do it with Satori-Browser, just for the hell of it. Just like:

./satori-browser.py Linux-3.11.0-15-generic-i686-with-Ubuntu-12.04-precise_HASH.jsn.gz

Screenshot from 2016-08-14 21-42-49.pngThe beloved 777. The number of the beast plus 111… Consider the box pwned…

Plenty of possibilities here… Copy a SUID dash in /tmp, create another UID 0 user, change root passwd (generally bad idea). We will be Captain Obvious and get a reverse shell. A python one will do.

We ‘ll use oneliner-sh, a bash script that returns wildcard-ed reverse-shell oneliners (both Windows and Linux flavored), mainly from pentestmonkey, Nishang and other sources that I can’t remember right now but are referred from pentestmonkey website.

oneliner -i 192.168.56.1 -A lin -r

Screenshot from 2016-08-14 21-53-02.png

So now we are changing that python file while waiting for our shell:

Screenshot from 2016-08-14 22-04-36.png

It can arrive any minute…

Screenshot from 2016-08-14 22-05-47.png

Mission Accomplished!

(screenshot mode: OFF)

So this is Satori.

Ohh, almost forgot… The diff tree view I am so proud of!

(screenshot mode: ON again)

and as you can see, the “automate” file is marked green (added after the original) in the last page, in front of our eyes the whole time…

 

Afterthoughts: Satori’s whole philosophy of “Attack

Using this tool is a non-intrusive method of attack. It almost eliminates the interaction with the remote box by maximizing the Information Gathering phase and doing the Vulnerability Scanning completely offline. If you think of it we had no bash history left behind apart from the actual modification of the “connect.py” Python file and the read of the “automate” cronjob (which could be done locally too, if we used the Imager to also collect text files).

I don’t say, in any way, that this technique is forensically safe, considering that the Remote module just copies the whole Satori Suite to the target’s hard drive, runs it (talking about things that can get better!) and then wipes it. But it is a different approach to CTFs than firing up random exploits, googling service names and metasploiting. It is more educational and silent. We knew the vulnerability before we even logged in with SSH to get a machine prompt and actually DO something.

I don’t know if this is the best way, or the most effective one. I doubt it to be honest. But this is my approach to CTFing and maybe pentesting, as this is my approach to life! And as a tool I wrote, I poured some soul and my mindset in it. It wasn’t designed to be an autopwner.

 

Things that would be cool to happen in the future

  • Create a Satori-Remote module that will work with reverse/bind shells! SSH is great but not that usual.
  • HTMLify the results of the Remote-Differ. Maybe apache them to the local network for the whole CTF team to watch and check. Only better thing than a good pair of eyes is multiple pairs of eyes. Especially in privesc!
  • Include kernel config files and maybe build hashes. A badly configured recompiled kernel could be a major source of exploits!

 

 

 

Advertisement