CVE journey

Information

Seafilehub 12.0.10

Second Order Stored XSS: CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L - 6.3 Medium

Official security issue record: https://plus.seafile.com/wiki/publish/seafile-wiki/txzO/

TL;DR

Well, Mitre may be quite slow sometimes, but I hope this turns into a CVE in the near future.

First things first—this blog is more about the experience of getting my first CVE rather than the exploitation itself, since it isn’t a big deal (just a second-order XSS, lol). But I’m quite excited that I finally managed to translate my thoughts of “I want to get a CVE” into a real vulnerability.

To be honest, I’ve been feeling stuck since 2023. It felt like all that knowledge was slowly but surely fading from my brain. I was reading writeups about web challenges, learning new things like Active Directory, preparing for unnecessary certifications… it all felt like I wasn’t acquiring real skills.

So, I decided enough was enough. No more work that felt useless. I knew there were plenty of projects developed by small teams with limited security experience, and I thought I could actually be useful by helping them secure their software while I acquire new skills.

My experience

Why Seafile?

So here we are, looking for an application that is widely used and could have vulnerability flaws. A peer of mine just sent me a CVE in localsend that was INCREDIBLY easy to find, with high severity, in a HUGE application. So then I decided that an application that supports file uploads would be nice, because maybe and only maybe, we could get an RCE (we never did).

Looking for the vuln

To be fair, the main reason no one audits these applications might be that DEPLOYING AND UNDERSTANDING THEM can take hours. I probably wasted six hours of my life reading documentation just to deploy the correct component and host the page locally.

Then, there I was—staring at a gazillion lines of code written in different languages. It felt overwhelming, nothing like opening a CTF challenge where you only need to inspect 5-6 files for something suspicious.

My approach to this “greybox” audit was to first understand the application’s functionalities from a user’s perspective rather than a pentester’s. Once I checked what I could do, now I had to look for each component in the code.

Of course, I tried reading the code, but for someone unfamiliar with real-world applications, I was painfully slow Looking back, a better start would’ve been using source code analysis tools like Snyk. Instead, my solution was intercepting requests of a functionality which behaviour was strange. For example I would spam "><h1>test</h1> in every input, see if it gets reflected or interpreted, and look for the sink in VSCode.

Exploitation

The exploitation does not require any administrative privileges, just a normal user account. The first step is creating a new library

Once we create the library we have to share it with the target.

Now we have to create multiple files with a XSS payload.

This will result in the creation of a new activity in the “Activity” page of the target, even administrators.

Source details:

Conclusions

Honestly, there was no need to dive that deep into the source code. Just being stubborn and testing everything could’ve led anyone to this result. I also found some oddities in the code that I couldn’t exploit, and I’m sure there are more issues to fix. There’s a whole custom authorization process with internal headers that looks sketchy, plus some non-parameterized SQL queries. tbf I was feeling like this:

It felt rewarding because I’d never tackled a real application before, and I learnt a lot beyond just technical skills. Sure, I was familiar with deploying apps and hunting for vulns, but I also had to write a report, use CVSS, contact the Seafile team and report to Mitre. I even found myself more interested in mitigation strategies, now that I understood the app’s internals and potential vulnerability sinks.