Sandworm_Firejail

Firejail

---

Firejail has been a pain since the foothold. At the later stage, I discovered that the binary actually had SUID bit set

important thing is that the permission bit is set to root :jailer

The only user that is present inside the jailer group is the atlas user Now that I have made the lateral movement to the atlas user without being bound by the Firejail’s sandbox environment, I can finally get to the enumeration

atlas@sandworm:~$ /usr/local/bin/firejail --version
firejail version 0.9.68
 
compile time support:
	- always force nonewprivs support is disabled
	- AppArmor support is disabled
	- AppImage support is enabled
	- chroot support is enabled
	- D-BUS proxy support is enabled
	- file transfer support is enabled
	- firetunnel support is enabled
	- networking support is enabled
	- output logging is enabled
	- overlayfs support is disabled
	- private-home support is enabled
	- private-cache and tmpfs as user enabled
	- SELinux support is disabled
	- user namespace support is enabled
	- X11 sandboxing support is enabled

The installed instance is Firejail 0.9.68

Vulnerability

---

┌──(kali㉿kali)-[~/archive/htb/labs/sandworm]
└─$ searchsploit firejail
-------------------------------------------- ---------------------------------
 Exploit Title                              |  Path
-------------------------------------------- ---------------------------------
Firejail - Local Privilege Escalation       | linux/local/41022.md
[...REDACTED...]
-------------------------------------------- ---------------------------------
Shellcodes: No Results
Papers: No Results

One result shows up that matches the instance.

It dates back to Novemebr, 2016 This particuler exploit is likely outdated

Researching further into the subject, I came across an article published to seclists.org

Reading further into the article confirms that the target instance is highly likely to have this vulnerability; CVE-2022-31214 Moving on to the Privilege Escalation phase

more info can be found here