How I found my first CVE through hacktivity hunting?

So first what is hacktivity hunting?

Hacktivity = hack + activity

The main idea of hacktivity hunting is by looking at other hackers’ reports which are resolved by the vendor. We can then find ways to bypass their own fix.

For open-source applications, we can look at the git commits and changes from the developers to understand how they fixed the bug specifically. Then we can try to find a way around the fix.

Simple enough, let’s see a real life example.

The discovery of CVE-2023-0112

I was on Tet holiday at that time and had a lot of free time. So I decided to find something to hack. I stumbled upon a program on huntr (a bug bounty platform for open source applications) and decided to hunt on it to test out hacktivity hacking.

This application was called memos, a self-hosted note taking hub.

Scrolling through the hacktivity tab, I found a lot of XSS reports so maybe I can find another one ¯\_(ツ)_/¯

I took some time looking at each reports then this was the one that piqued my interest.

This is a simple XSS through uploading an svg file with the script tag.

1
<x:script xmlns:x="http://www.w3.org/1999/xhtml">alert(document.domain)</x:script>

Let’s see how the developer fix this bug. (╭ರ_•́)

One cool feature of huntr is that it will show the fixing commit of the developer.

https://github.com/usememos/memos/commit/c07b4a57caa89905e54b800f4d8fb720bbf5bf82

At first, in the old code, the developer is checking if the Content-Type of the uploaded file is text/html. If that is the case, the server will return it as text/plain and the HTML won’t be rendered.

But for some reason, in the new fix, he decided to set the server returned Content-Type to the same type as the uploaded file. This means we can upload a HTML file and the server will return it as text/html which will then be rendered by the browser.

Uploading the HTML file

HTML file is rendered as expected.

But if we try to upload an HTML file with the script tag this will happen.

1
<script>alert(document.domain)</script>

The error message states the Content Security Policy is preventing the <script> tag from being executed as JavaScript code.

Let’s have a look at the code.

The developer is preventing the execution of JavaScript code by setting the CSP rule to default-src 'self'.

You maybe asking. What is CSP?

Content Security Policy (CSP)

Content Security Policy (CSP) is a browser security mechanism that defines a set of rules that specify which sources are allowed to load content on a website which can be in the HTTP headers or in a meta tag.

From the mdn web docs

A CSP compatible browser will then only execute scripts loaded in source files received from those allowed domains, ignoring all other scripts (including inline scripts and event-handling HTML attributes)

One common scenerio is the developer wants all content to come from the site’s own origin. The Content Security Policy will look like this:

1
Content-Security-Policy: default-src 'self'

Which means any other sources including our inline script tag won’t be executed by the browser unless it is stored on the same origin site.

Let me repeat this again, OUR INLINE SCRIPT TAG WON’T BE EXECUTED BY THE BROWSER UNLESS IT IS STORED ON THE SAME ORIGIN SITE.

Piecing together the puzzle

Our pieces of puzzle:

  1. We can upload any type of file, the content type will be preserved and it will be stored on the server.
  2. The browser will render our uploaded HTML file.
  3. Our inline script tag won’t be executed by the browser unless it is stored on the same origin site.
    → What if we upload our own .js file onto the server, then force the server to execute that .js file?

First we upload a malicious js file onto the server.

1
2
// step1.js 
alert(document.domain);

Then we upload a html file which includes this script

1
2
// step2.html
<script src=/path/step1.js></script>

BOOM!!! The payload is executed because our malicious JavaScript file is stored on the server which satisfied the condition number 3.

Final thoughts

I think that hacktivity hunting is an important technique to add to your toolbelt as it will give you insights on how the developer is securing their application. Even if you can’t find any bugs, you would still better understand about the application.

Thanks for reading my first blog post. Hope that I can find another bug soon to continue writing 😁. Have a great day!