Derailed Writeup

Recon/Scanning

Enumerating 3000…

Looks to be a app too add notes, we can post without signing up as Guest X_x

Directory Enumeration from behind the scenes…

Remember /administration, I am sure it will come in handy…

We can try unauthenticated testing. Ill play around with this to get a better feel for the app then create an account! Its important to always test both approaches!

A Ruby on Rails app? Derailed… makes sense

After authenticating, our Author name changed! Curious

CSRF protection, can’t stop XSS so nothing we still cannot automate through ;)

There is a report feature that allows us to report our clipnote, if we do we see “The note has been reported. Our admins will soon have a look at it”. Very Interesting… If we have Admin interaction, we have a good attack vector.

It is worth noting that our Cookie has the HttpOnly flag set. Therefore this means we cannot outright directly steal any cookies. We are going to have to go to insane measures to pop it

None of these wordlists are picking up anything so I created a custom wordlist against a site that talks about the Directory structure! We can brute force easily enough as each directory that does not exist is a 404 and gives “Not Found”. We can create a script that recursively checks to attempt to drill down.

Nice! So we are dealing with Ruby on Rails!

We were redirected too /routes

Playing around, I found XSS but I don’t think we can achieve anything through this current page because we have no other interaction or at least nothing I was able to find.

A little later the script found /rails/info/properties

Diving around the internet, I landed on this!

“certain configurations of Rails::Html::Sanitizer may allow an attacker to inject content if the application developer has overridden the sanitizer’s allowed tags to allow both select and style elements.Code is only impacted if allowed tags are being overridden.”

Working back to the author field (our username ;), XSS is exploited…

We need to overflow for the exploit to work, we can recv a callback

I can say that I have never seen a overflow into XSS… this is pretty damn cool

So now what? I am thinking CSRF… if this works, we can grab the admin page

Why do it in 20 minutes manually, when you can spend hours to automate it ;)

This was tricky, for this to work, we have to encode our payload as well as use onerror. I tried a few but ASCII ended up working. We will utilize a JS payload to get a callback. For example, this is how I automated my malicious user creation to get our admin callback…

This is a simple callback, the whole script on hacktricks is something well need

For our Char encoding, I just created a seperate function that will handle the encoding as well as wrapping our payload. Who doesn’t love to nestle JS into their Python ;)

Our new payload to steal the page

Told you I was lazy, but now I can easily test payloads

Never give into despair… The key was to make sure the admin triggers, not me

You should see the various output, base64 -d to reveal the admin page

There is a reports form that may be injectible, the value param…

<h3>Reports</h3>
      <form method="post" action="/administration/reports">
        <input type="hidden" name="authenticity_token" id="authenticity_token" value="<auth_token>" autocomplete="off" />
        <input type="text" class="form-control" name="report_log" value="report_14_12_2022.log" hidden>
        <label class="pt-4"> 14.12.2022</label>
        <button name="button" type="submit">
          <i class="fas fa-download me-2"></i>
          Download
        </button>
      </form>

Awesome! We can utilize all the information to gain access

If you are not following along, I highly recommend my CodeUps

Gaining Access

After conducting our tests, we discovered the potential for chaining XSS -> CSRF vulnerabilities. This occurs due to an interaction with the admin system when reporting our clipnote, which can lead to the compromise of the administrative session and provide unauthorized access to the administrative page.

We observed by accessing the /administration page, we noticed a possible injection vector. The final payload with a few tweaks should catch us our shell.

Automated user exploit… Damn I love automation! Did we get the flag?

A small recap

Privilege Escalation

We made it! That was exhilerating!

With no creds, Ill look at /opt as well as listening ports…

No luck here…

Quite a few interesting ports listening… going to poke around more

Inside this sqlite3 db I found a hash for toby and alice… litte too easy

The password works for openmediavault-webgui aka Toby…

Enum Enum Enum

As Toby, I got a sense to look at this openmediavault…

I see we have a config file that we can edit, looking through it…

We may be able to do some SSH trickery but I am unsure, need to delve into OMV

For smoother enumeration and editing, add SSH keys and get SSH access

A good read to study up on the OMW Internal Tools

So we we can edit this, but what can we do…

hmmmm… I wonder

We may be able to add SSH keys for root! Only way to know is to test

Generate a key, replace the test user with root and add our new sshpubkey…

A sure fire way to know this is working is we should see our new key in the confdbadm output

Its screaming about the format of the key…

ssh root@derailed.htb

Rooted! Victory Roar!!!!

Wrapping Up

With a patient and persistent approach, I eagerly embraced the challenge of the Insane box, fueled by my passion for automation. The dynamic nature of the site presented anticipated obstacles, urging me to deftly manipulate tokens and sessions to ensure it all worked properly.

XSS was found in the username field of our registered user! An unseen approach to overflow into XSS was very interesting. A curious mind would think to chain XSS into something, in this case the Administrators cookie was not obtainable so why not view what we can’t see.

Viewing the admin page pointed us to an RCE through the report form that we had to chain to execute. XSS -> CSRF -> RCE. This was serious work! This granted us a shell as rails.

The critical vulnerability lies in the ownership permissions of the config.xml file, which grants us the ability to modify it at will. Consequently, this empowers us to enable SSH access for any user on the machine, using a public key of our preference. By editing the config file within the system, we can effortlessly exploit this security loophole.

Shoutout to both of these creators! Perfect box!