Here's my beat up art class binder

CVE-2024-31317

Am I affected / can I exploit this to get system on my own device?

This was patched in source.android.com/docs/security/bulletin/2024-06-01

If your device runs a patch under 2024-06-01 you can use this. The "Google Play system update" date is irrevelant and you can (and should) update your google play.

How to exploit?

Visit the github

What can System do?

I will keep a detailed list of what it can do here

Why?

I wanted to make a package manager that would support as many linux environments as possible, including embedded devices, or containers where you cannot get root.

Installation

curl -sSL opm.oddbyte.dev/opminstall.sh > opminstall.sh && sh opminstall.sh

You can use bash, sh, or even busybox ash for the installer. Just replace sh with your desired shell.

Usage

opm@oddbyte:~$ opm help
=====================================
          OPM Package Manager
          By Oddbyte
=====================================

Usage:
    opm [command] [options]

Commands:
    help                                Show this help message
    install | add | i [pkg]             Install a package
    remove | uninstall | delete | rm    Remove a package
    repos                               List configured repositories
    addrepo [repo_url]                  Add a repository
    rmrepo [repo_url]                   Remove a repository
    list                                List all package names
    search [query]                      Search packages
    reinstall [package]                 Reinstalls the package, deleting all data
    upgrade [package1] [package2]...    Reinstalls packages, keeps config data
    update                              Update OPM
    upgradecheck                        Check for package updates
    show | info [package]               Show info about package
    postinstall [package]               Run post-install script for a package
    start [package]                     Start the package's service
    doctor | diagnose                   Run system diagnostics

Options:
    -y, --yes                           Automatic yes to prompts
    -p, --parallel                      Enable parallel installation
    -j, --jobs [n]                      Set number of parallel jobs (default: 4)
    --debug                             Enable debug messages
    --nocolor                           Disable colored output

Check out opm's webpage at opm.oddbyte.dev

Hello guys!

I have found multiple security issues in minehut. If you are not familiar, Minehut is a service that provides free minecraft server hosting. This is an exceptional service, and I support their goal. This being said, their code is complete garbage, and I genuinely think that ChatGPT could do better. For a company who's only service relies entirely on the internet, you'd think they would at least conduct regular red-hat penetration testing to ensure security of their platforms. My hope in writing this write-up is that they will go out and hire a professional penetration testing company to test them. If I could do this in a weekend, a decent penetration tester will have a field day with them.

Before we start

I will need to clarify a few things:

• Minehut runs on this architecture: Host Server -> VM -> CT

The CT is where your minehut server actually runs. This is the easiest to get access to, all you need is a half-decent /shell plugin.

The VM is used for booting the CT, running the file manager, and providing the minehut staff with a SSH server so they can log in if need be. This is harder to get access to, as it mounts all the files responsible for running the panel as read-only.

The Host server is the physical machine where everything runs on. This should (not tested) be extremely difficult to get access to.

In the CT, there are a few special folders:

• /app/, contains app.sh (the INIT process; very important) and env.sh (contains WAY to much information; can be reduced a LOT). These are writeable, however there is nothing to gain from modifying them, as rebooting your CT will wipe any changes.
• /home/minecraft/server/, this is the only place where files are actually stored. These files will not clear upon reboot. Your minehut server lives here.
• /home/minecraft/signal/, is where the start_cmd script (the script that boots up your server) lives. This is very important later in the writeup when I explain how to stop minehut from shutting down your server. There are also special files such as /home/minecraft/signal/shutdown. If you create this file, it will forcequit your server by telling app.sh (the INIT process) to quit. If you do not know why this is important, the INIT process is offered special protections against being killed, and also if the INIT process stops, the entire CT will shutdown. This folder also includes some funny files, such as /home/minecraft/signal/fifo/*, where there are STDIN, STDOUT, and STDERR. These fifo files are read by the minehut panel. They are mostly useless.
• /conf-ro/ contains an env.sh file. I dont get why this even exists, as it does literally nothing.

Lets break it down:

The issues

Their webpanel has many features, such as modifying server.properties, a console, and a file manager. We will mostly focus on the file manager, as this is the part that actually runs ON THE VM.

• Issue number one: Their minehut panel does NOT check if a file / folder is a symlink. This allows you to quite easily modify web requests via MITM Proxy to achieve write access onto the VM.
• Issue number two: Their app.sh can be hijacked. This means that you can make it IGNORE SHUTDOWN COMMANDS COMING FROM MINEHUT!!! This is something that is crazy to me. You can hijack the process responsible for shutting down your server, basically telling it to ignore minehut.
• Issue number three: Their minehut panel sends random information that the client does not need. Not only does this actively slow down the minehut panel for end users, this also provides valuable information to hackers. Also, it seems to re-send the same request 3 times, implying there are 3 loops running to get the same information from the same server.

Exploiting the panel

In this writeup, I will talk about all the 3 issues listed above. Lets start with issue number one.

Their file manager does not check the path you are accessing

This is actually only half true. The read and download endpoints seem to be protected against this, however the edit, move, and copy endpoints are not. While on topic of these endpoints, I would like to complain about move and copy. These endpoints do not even check if the operation was successful. They always return 200 no matter what actually happens.

Lets start with the good: The list endpoint. This endpoint should be used on a directory, and it will return a list of files that exist there. Issues: The list endpoint will hang forever if the folder contains an invalid symlink.

Here is an image showing the list endpoint returning 500 when trying to read outside server scope:

As you see, the list endpoint correctly stops me from accessing a symlink to /tmp/, which is outside the scope of the server folder.

And now we immediately go down from the "good", and into the half-decent territory with download endpoint. This endpoint is the only one that I found returns raw NodeJS errors. This endpoint perhaps provided the most valuable thing it could: a path to its files. Unfortunately for me, these files are mounted read-only, so I could not use them to get a shell :<

Now, I had to use some magic coding powers to get this screenshot, as regularly the download endpoint returns an empty json object with a code 500 if you are not calling it from the minehut panel:

And now here we start the bad endpoints. Let's ignore move and copy, as they are just worse edit endpoints. I will not mention the rename endpoint (which is for some reason a different endpoint than move?) because it is useless to us. The edit endpoint allows us to edit a file. This endpoint provides permission denied errors in the form of json:

{
   "error": {
       "code": "EACCES",
       "errno": -13,
       "path": "/home/minecraft/server/slash/e",
       "syscall": "open"
   }
}

where the slash folder is a symlink to /.

This endpoint allows us to arbitrarily write any file on the VM, as long as the user that runs the panel (a user named minecraft with the user id 100) can write to it. This endpoint does not feature any path checks outside the standard linux file permissions, meaning if we can find a shell script or config file that it reads from, we could edit it and might be able to break out of the CT.

Exploiting the server

Alrighty, this is all fun and games, but what can you actually do? Well unfortunately since the file manager is not running as root, and cannot access any folder in the CT (outside the server and signal folders), there is not much we can do with this kind of exploit. To abuse this, we would need to find either a config file or a script file that is actually pulled from, and one that we can edit. Unfortunately without read, we can't really do much, as the move and copy endpoints do check what file they pull from, but not the file they push to, we cant even use them to copy the source code for the minehut file manager.

So now what? We go back into the CT of course! First things first, you will probably want a paid server. All of this is running on a Custom server plan that includes only 24/7 hosting (so I dont need to be in a minecraft server while coding, and to get an open port to run sshd on). After I setup ssh (without root), I poked about in the app directory, reading all the code for the app.sh:

#!/bin/bash

source /app/env.sh

mkdir /app/certs/
touch /app/certs/ca.crt
curl -s -k --retry 5 --retry-delay 10 https://mojang-session-mitmproxy.minehut.svc:8080/auth > /app/certs/ca.crt

mod_java_certs() {
 JAVA_STUB=/opt/java/$1

 $JAVA_STUB/bin/keytool -import -trustcacerts -keystore $JAVA_STUB/lib/security/cacerts -storepass changeit -noprompt -alias proxykeystore -file /app/certs/ca.crt
}

/opt/java/8/bin/keytool -import -trustcacerts -keystore /opt/java/8/jre/lib/security/cacerts -storepass changeit -noprompt -alias proxykeystore -file /app/certs/ca.crt
mod_java_certs 11
mod_java_certs 16
mod_java_certs 17

watch_signals() {
   while true; do
       if [ -f "${SIGNAL_KILL}" ]; then
           echo "Forcefully killing downstream java process."
           pkill --signal 9 java # this might not always be java... potentially, we might want to capture the proc id
           rm -f "${SIGNAL_KILL}"
       elif [ -f "${SIGNAL_SHUTDOWN}" ]; then
           echo "Preparing for shutdown, killing downstream java process."
           pkill --signal 9 java
           return
       else
           sleep 0.5
       fi
   done
}

cd "$ROOT_SERVER"
watch_signals &

while true; do
   # Wait until server is ready to start
   while [ ! -e "${SIGNAL_SERVER_READY}" ]; do
       if [ -f "${SIGNAL_SHUTDOWN}" ]; then
           echo "Received shutdown signal from the sidecar. Exiting."
           break 2
       fi
       sleep 0.5
   done

   # Run
   exec 0<> "${SIGNAL_FIFO_STDIN}"
   bash ${SIGNAL_COMMAND} 1>${SIGNAL_FIFO_STDOUT} 2>${SIGNAL_FIFO_STDERR}

   # Mark done and wait until next start
   rm -f "${SIGNAL_SERVER_READY}"
   touch "${SIGNAL_SERVER_DONE}"
done

As you see, it runs source /app/env.sh, so lets take a look at that too:

#!/bin/bash

if [ -f /conf-ro/env.sh ]; then
   source /conf-ro/env.sh
fi

export ROOT_MANAGER="/home/minecraft/manager"
export ROOT_SERVER="/home/minecraft/server"
export ROOT_SERVER_PLUGINS="${ROOT_SERVER}/plugins"
export ROOT_SIGNAL="/home/minecraft/signal"
export ROOT_SIGNAL_FIFO="${ROOT_SIGNAL}/fifo"
export ROOT_TMP="/home/minecraft/tmp"

export SIGNAL_FIFO_STDIN="${ROOT_SIGNAL_FIFO}/stdin"
export SIGNAL_FIFO_STDOUT="${ROOT_SIGNAL_FIFO}/stdout"
export SIGNAL_FIFO_STDERR="${ROOT_SIGNAL_FIFO}/stderr"

export SIGNAL_SERVER_ID="${ROOT_SIGNAL}/server_id"
export SIGNAL_SERVER_READY="${ROOT_SIGNAL}/server_ready"
export SIGNAL_SERVER_DONE="${ROOT_SIGNAL}/server_done"
export SIGNAL_SUCCESSFUL_DOWNLOAD="${ROOT_SIGNAL}/successful_download"
export SIGNAL_SAVE_IN_PROGRESS="${ROOT_SIGNAL}/save_in_progress"
export SIGNAL_PERFORM_RESET_ALL="${ROOT_SIGNAL}/perform_reset_all"
export SIGNAL_PERFORM_RESET_WORLD="${ROOT_SIGNAL}/perform_reset_world"
export SIGNAL_PERFORM_FILE_REPAIR="${ROOT_SIGNAL}/perform_file_repair"
export SIGNAL_KILL="${ROOT_SIGNAL}/kill"
export SIGNAL_COMMAND="${ROOT_SIGNAL}/start_cmd"
export SIGNAL_SHUTDOWN="${ROOT_SIGNAL}/shutdown"

export VV_MINEHUT_KEY= # Removed, since I have no idea what it is or what it does.

if [ ! -d "${ROOT_SERVER_PLUGINS}" ]; then
   mkdir -p "${ROOT_SERVER_PLUGINS}"
fi

if [ ! -d "${ROOT_TMP}" ]; then
   mkdir -p "${ROOT_TMP}"
fi

As you see, there are a lot of variables set in here, most of which are never used. The source /conf-ro/env.sh can be ignored, it does nothing.

AFAIK, the only variables of consequence are:

• ROOT_SIGNAL. This is the signal directory, and is used in app.sh
• ROOT_SIGNAL_FIFO. This is where the fifo files responsible for letting minehut see and interact with the minecraft console are.
• SIGNAL_SERVER_READY. If this file exists, it will ignore the SIGNAL_SHUTDOWN and boot into minecraft. This file is created when you click start on the minehut panel. Funnily enough, it does not need to be a file, and if you make it a directory it fails to remove it, basically "locking" your server from being shut down.
• SIGNAL_COMMAND. This is the file it executes if SIGNAL_SERVER_READY is present, and it has finished executing the last command (you need to stop the minehut server in order for the app.sh to load SIGNAL_COMMAND. Fortunately for you, SIGNAL_COMMAND is only ever updated when you start your server from the minehut panel, so if you have stopped the server, you can run anything in here.
• ROOT_SERVER. This is where your files go.

Before we start injecting into app.sh, let me point out a few issues with how it works:

1. It uses pkill to kill java. This means that you can bypass SIGNAL_KILL by just using a custom java binary if you rename it to something else (like jarva). SIGNAL_SHUTDOWN will still kill the minecraft server, because it makes the app.sh exit (if SIGNAL_SERVER_READY does not exist) and when the app.sh quits, it takes the CT with it.
2. It has the watch_signals loop quit if it sees SIGNAL_SHUTDOWN. This means that if you first make SIGNAL_SERVER_READY, then make SIGNAL_SHUTDOWN, it not only quits the watch_signals loop, but it also runs whatever is in the start_cmd at the time. This is useful, because when watch_signals is quit, SIGNAL_KILL is completely ignored, and you get to inject into the app.sh's loop by making your own SIGNAL_COMMAND file with your own script.
3. If you create SIGNAL_SERVER_READY after modifying SIGNAL_COMMAND, it will execute SIGNAL_COMMAND without validation. This means you can hijack it to make it so you can control when you want the server to shutdown.

How to inject

First of all, you will want to pay attention to how it runs your script:

   # Run
   exec 0<> "${SIGNAL_FIFO_STDIN}"
   bash ${SIGNAL_COMMAND} 1>${SIGNAL_FIFO_STDOUT} 2>${SIGNAL_FIFO_STDERR}

As you can see here, it routes your STDIN (input) to SIGNAL_FIFO_STDIN (which is how the minehut panel sends commands to the minecraft server), and routes the output and error logs to their respective FIFO files. While this works fine for minehut, this causes the exec 0<> to hang if the FIFO files have nothing attached to them on the other end (aka the panel). The panel detaches itself after you stop the server, which is a pre-requisite to injection. So, you will need to delete all 3 files in ROOT_SIGNAL_FIFO, and make new, non-fifo files in their place to avoid a infinite hang. Before injection, edit SIGNAL_COMMAND to whatever you want, BUT MAKE SURE IT IS PERSISTENT. If you make a SIGNAL_COMMAND that exits, it will stop the app.sh with it, and when app.sh dies, so does the CT.

What to do after injection

Congrats! You have overridden minehut's app.sh (or maybe you haven't, and you just want to run custom servers). Now you can boot your own servers!

Pros:

• You can use any server software. Cons:
• If you do not include their Minehut Analytics plugin, /friend will not work.
• If you do not set up your server to limit its RAM usage, be warned that the container is preconfigured to auto-kill any process that exceeds the RAM limit, potentially leading to corruption. Generally, you can multiply your max ram in MB * 1.25, and use that safely (1 GB = 1024 MB, so you can set -Xmx1536M in your server's startup flags to limit its RAM usage to 1536 MB).

The end

Thank you for reading, and to the poor minehut devs who I will force to read all of this write-up, I hope you have a nice day.

Funnies

Here are some funny things the minehut panel does that I couldn't fit into anywhere else in the write-up.

Here is a MITM proxy screenshot of it sending the cliFlags of your server as a part of your all_data endpoint:

This is particularly bad because it actively slows down users with poor internet connections and / or bad computers. It returns ALL user data for ALL servers you own. This means that while you are looking at one of your servers, the minehut panel is requesting and parsing data for all your servers. This also means that if you manage to prevent the server from sending the all_data response (like by inviting and having a target account accept a subuser request to an attacker-controlled server, which may use a exploit to make it force any all_data request that includes it to hang forever), you can brick someones whole account, since the panel doesnt have any fallback.

EDIT (1/1/2025):

I have gotten a direct line to minehut staff.

EDIT (2/26/2025):

From what I can tell, the greater majority of everything in here is fully fixed! Good job minehut!

Intro

I own oddbyte.dev, and I like hacking. I specialize in XSS and other web vulnerabilities, as well as android. My goal is to become CISO of a mid-range company, or to do security research professionally, although I would love to do sysadmin and IT. I am 2(e^(iπ)) · 8.5 · cos(π) + isin(π) years old. Good luck!

Contact me

You can reach me through my discord server, where I go by @oddbyte.

You can send me an email at [email protected].

You can find my GitHub here: @oddbyte.

You can also message me on Signal, @oddbyte.01.

Coding stuffs

I know Java, C++, Python, HTML, CSS, JS, NodeJS, and bash. I own a Dell 5190 chromebook, which I have sideloaded the UEFI Bootloader & installed PureOS onto, and my main PC is currently running Windows 11 (because I play Rust, a game that does not have Linux support). My favorite editor is VSCode, but I use IntelliJ IDEA Community Edition for all Java needs (Android apps, Minecraft mods / plugins, Java standalone apps, etc).

Devices

My current main phone is a Samsung S23FE (which I disabled updates on, since USA versions cannot have their bootloaders unlocked). The S23FE is loaded with a older version of Android that is vulnerable to multiple Priv Esc CVES, all of which I exploit to gain System (UID 1000) access on my device. I also own a Raspberry Pi 400 (us), which I use for screwing around & selfhosting stuff.

Blog & Projects

You can read all about the fun I get up to in my blog, and all my projects on my projects page!

That is all, thanks for reading!