CasaOs is one of the go-to tools for home server setups among tech and cloud enthusiasts. It is a straight forward interface that simplifies the complexities of server management, allowing users to set up and manage their own servers via a user-friendly interface without the steep learning curve usually associated with traditional server setups. In this blog post, we will explore some of the features in CasaOs and how an attacker could abuse them to compromise the underlying host.

Catalog⌗

• Background
  • Support and Installation
  • Dashboard
  • App Store
  • File Manager
• It’s not a Bug, It’s a Feature
  • Attack Primitive 1 - Reading SSH Keys
  • Attack Primitive 2 - Password Cracking
  • Attack Primitive 3 - Arbitrary File Write
• POC or GTFO
• Mitigations

Background⌗

The option of setting up personal clouds is lucrative for people who don’t want to rely on external service providers and CasaOs offers the ability to do just that through a ton of self-hosting features to help you access all your favorite home lab servers without investing in extra hardware. CasaOs serves as a personal home cloud, a hub for hosting services, a control panel, and a container server, all wrapped up in an intuitive web interface that you can use from any device connected to your home network. Although it has “OS” in its name, it doesn’t operate as a traditional operating system; rather, it’s quite similar to Nextcloud, requiring installation over an existing operating system. CasaOs offers a variety of features including file management, docker support and an app store with pre-configured docker containers that are ready for rapid deployment.

Support and Installation⌗

CasaOs is lightweight and fully supports custom boards such as ZimaBoard, Intel NUC, and Raspberry Pi with support for amd64/x86-64, arm64 and armv7 architectures. Moreover, it is fully compatible with Ubuntu, Debian, Raspberry Pi OS, and CentOS allowing installation with a one-liner installation.

curl -fsSL https://get.casaos.io | sudo bash
#OR
wget -qO- https://get.casaos.io | sudo bash

In my case, I installed CasaOs in a kali vm and once successfully installed, the web interface can be accessed via the provided URLs displayed at the bottom. In my case, my CasaOs instance is available at http://192.168.56.109

Visiting the URL we come a registration page, pretty standard stuff. Create an account and you are set to go, I chose the credentials casaos:casaos here.

Dashboard⌗

After successful installation and login, you can now access the main dashboard which contain some metrics about the underlying host such as the CPU usage, RAM usage, utilized storage, network status and available interfaces, customizable widget settings, as well as the App Store, File Manager and installed applications.

App Store⌗

CasaOs also has an App Store which contains a ton of applications that can be installed via a one-click installation. These applications are pre-configured docker containers for the respective services with popular services such as nginxproxymanager, Gitea, MongoDB, Nextcloud, Memos, Pi-hole etc.

For each application, we get details, screenshots and a nifty install button to install the application.

CasaOs also supports deployment of custom containers by allowing you to import custom docker-compose files.

File Manager⌗

CasaOs also has a file manager which allows managing files on the host via the web interface. Through the file manager, a user can upload, download, create and delete files and folders. Data for all installed applications is stored in the DATA directory.

Using the file manager, we can also access files and directories stored on the host by accessing the ROOT directory.

The file manager also allows sharing folders to other devices on the same network allowing for fast and efficient file sharing.

It’s not a Bug, It’s a Feature⌗

While playing around with CasaOs, I noticed several attack primitives that an authenticated attacker could abuse to gain root privileges on the host server.

Attack Primitive 1⌗

Using this primitive an authenticated attacker could use the file manager to access the root user’s directory allowing them to access sensitive files and folders such as the .ssh folder.

An attacker could generate SSH key pairs and upload the public key to .ssh directory with the filename authorized_keys, then login using the private key. It is important to note that for this exploitation primitive to work, the server must have SSH running and is reachable by the attacker

The latest version of CasaOs does not display the contents of the root folder, unless they were created from the dashboard

When we try to create a folder that we know exists in the /root directory, we get a Folder already exists message.

After intercepting traffic in burp, I realized that the files and folders in the root directory are fetched by the API but are not displayed in the frontend. For example, the request below fetches the contents of the newly created directory test

When we edit the request to fetch the contents of the root directory, we get results.

Checking the .ssh folder, we see a private key and public key. All the attacker has to do is grab the private key and use it to login.

To read the contents of the public key, let’s find the request for reading files. I created a simple file, intercepted traffic, then opened it for reading.

This was the request sent to read a file. Let’s change it to read the private key

Swapping the filename with /root/.ssh/id_rsa we get the contents of the private key.

Since we did not see an authorized_keys file in the /root/.ssh folder, we can just create one and paste the contents of the public key file in it, we can then download the private key locally, give it the necessary permissions and login as root.

Attack Primitive 2⌗

A malicious actor could use the file manager to access the /etc folder. Using this primitive, an attacker could download the shadow file containing password hashes belonging to users.

Obtained password hashes can then be cracked offline using password cracking tools such as hashcat and John the Ripper

Just like in the previous example, the attacker could the use the cracked credentials to authenticate to the host server via services such as SSH.

Attack Primitive 3⌗

We know that the CasaOs web interface runs as root, well, since it requires root access to do some of the tasks required by CasaOs, such as open certain ports e.g. SMB for file sharing and managing docker containers. This also means that the file manager as well runs as root allowing us to add/edit/delete files. This feature can therefore be exploited to achieve an arbitrary file write

To exploit this primitive, we could download the /etc/passwd file, add an attacker controlled user and the password hash, and then re-upload the modified file. I recommend making a backup of the /etc/passwd file first, before overwriting the file. This attack is similar to the dirtycow exploit.

However for this demonstration, I decided to download the /etc/shadow file and change the password hash for the user kali to an attacker-controlled one, then login with the newly set password. First things first, let’s create a password hash for our new password hackerpass

Download the /etc/shadow file and replace the current hash with the new one.

Upload the modified file using the file manager.

Login as the user with the new password, and get a shell

Another approach would be to upload SSH Keys to the root directory then login as root.

Incase SSH is bound locally and is not accessible to the attacker publicly(via the internet), CasaOs implements a terminal feature that can be used for SSH logins via the web interface, how convenient!

Just log in with the new credentials and you get access to the terminal

POC or GTFO⌗

I created a simple proof of concept script to log in and upload an SSH key allowing us to execute commands as root on the underlying host 🥳

To get a fully interactive shell, just authenticate to the target using the new SSH Key as follows.

ssh -q -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -i /tmp/id_rsa root@192.168.56.109

This approach is not opsec safe and I do not recommend it, it’s just the easiest.

Mitigations⌗

While these can not be really considered as vulnerabilities but intended use cases, they can be detrimental to security and could lead to total compromise of the host leading to lateral movement, deployment of crypto miners or even ransomware. However, below are some methods to keep CasaOS instances secure.

• Make sure the latest CasaOS is installed and is regularly updated. Unpatched CasaOS instances are vulnerable to authorization bypass, as highlighted in this blog.
• Configure firewall rules e.g. UFW to only allow trusted IP address to access the web interfaces and do not expose the CasaOS web interface to public networks e.g. the internet.
• Set strong and secure passwords for the CasaOS web interfaces to prevent bruteforce.
• Restrict Root users from authenticating via SSH.