[ 0. Summary ]─────────────────────────────────────────────────────────────//───
SugarVale is an intermediate rated practice linux machine with 2 flags, but in
practice is very straightforward. It features an authentication bypass,
unsanitised user input, and a simple privelage escalation through a custom
script.
[ 1. Recon ]───────────────────────────────────────────────────────────────//───
We start with a simple nmap scan, which reveals SSH on port 22, and a
web application on port 80. It also shows us that robots.txt contains 2 entries,
admin and backups. I start a gobuster to explore files and paths before
looking into these findings.
Exploring the web application, there's an admin panel, and I attempted some
default credentials, but no luck. We move on to the more interesting backups
directory, where we find some exciting files - an .env and config for the
production app. Between these files, it looks like I might have enough
information to forge an admin JWT, which could allow me to access administrator
features.
[ 2. Local Access ]────────────────────────────────────────────────────────//───
Let's try and grab a valid JWT by registering an account, and inspecting the
headers sent with each request. We do indeed have a JWT, sent as sv_token in the
Cookie header. Using jwt.io, I altered the token to have the admin role, and
ensured it was signed with the secret from the config files.
The new JWT does indeed allow me access to the Admin Panel - and what's more,
the preview funciton accepts a template which can contain valid HTML being
processed.
At this point, my spidey senses were tingling - the usage of the word 'template'
and the unsanitised HTML input being rendered suggests the application may be
vulnerable to SSTI. The value of the other cookie header, session, seems to
indicate we're working with a Flask app.
We can verify the vulnerability by sending {{7+7}} in the text field. We
can see this renders the expected value, 14, meaning this application is running
jinja2, and it is indeed vulnerable to template injection. There are a few other
template libraries with differing syntax we could have tried had the above
example not worked.
With the SSTI, we can easily achieve code execution after a bit of trial and
error with our payloads. The application errored out with some of the more
typical SSTI prompts, but this one worked, showing the user ID:
self.__init__.__globals__.__builtins__.__import__('os').popen('id').read()
With this, we can pop a reverse shell as appsvc and read the user flag.
[ 3. Root Access ]─────────────────────────────────────────────────────────//───
Looking at the web app directory, we see a .db file, which I'm thinking might
contain a reused password for one of the user accounts. Unfortunately, I was
unable to crack the admin hash. This also means we can't run sudo to find
possible escalation paths. The application source code also does not look to
contain any more useful secrets.
The application is stored in the /opt/ directory, and upon inspection there is
another folder in there, containing a backups subfolder, and in there a
logrotate.sh script. Looking at the contents, this is an easy avenue to root -
A comment informs us that this file is writeable by appsvc, but is invoked as
root via a cron. I edited the contents of the file to pop a second reverse shell
and shortly after received a connection back as root!
──[ EOF ]──────────────────────────────────────────────────────────────────//───