Skip to main content

Recursive CVD

Source

About two years ago a few enthusiastic employees in the Security Operations team at $myJob did the right thing: They convinced management that we need a published Coordinated Vulnerability Disclosure (CVD) process (including safe haven for researchers) & a reporting path. They then set out to write the policy, comissioned a pretty basic website, and got everyone other company website to insert a link into the footer. The website, on paper, did everything right: Fully IAC, running on a centrally provided webapp producted managed by our Cloud team. No publicly reachable admin interface, every content change going through our CMS. Explicitly minimalistic. The requirements document was about 60% security requirements, mostly written by experienced pentesters & containing explicit how-tos on, for example, building a proper CSP.

Unfortunately the employees that drove the topic soon after got moved to a very different role, the topic remained with the Vulnerability Management area. Here... enthusiasm & understanding was lacking, so the site kinda... just sat there. The few actual reports that were received were handled without much urgency or care, to be honest, and I can't really fault them, it was a lot of crap for not a lot of gain & they were busy.

When I joined that team I... kinda just stole ownership of the topic because I do care. Things since then haven't been going great: I also am busy/handling too many topics, fixes are often slow, in some cases the business will do its best to just ignore or sit out pretty critical stuff, so many technical issues including us being unable to deploy any changes for months, and a complete lack of documentation making fixing anything hell (currently writing the first actual docs on this, 2 years after release, lol). But things are improving & this is one of the areas where I can truly call mine. Give it another 6 months & I am pretty certain I'll be able to call this "good enough".

What am I going to do in those 6 months? Well, stabilize deployment, iron out smaller technical issues, ... and fix the backlog of security issues that currently exist in the application.

The worst CSP I have ever seen

I am not going to include it here because reasons, but the highlights:

  • No default-src

  • unsafe-inline of course

  • script-src with both http: https:

  • One captcha providers requirements, correctly implemented

  • A second captcha provider, incorrectly implemented

  • A hardcoded nonce

This application was pentested. I know the pentester. I know the report. This isn't in there. I am thinking less of him now. There are, however, things in there that ... don't really apply...

File types

Submissions work via a standard form, PHP of course. Submitters can add attachments, the file types however are supposed to be restricted.

The websites PHP does a quick initial sanity check & will reject superficial discrepancies. The actual check, however, is done in the bash script doing the processing afterwards. This... isn't perfect either - it's just file -i.

So this became a "High" finding in that pentest - they were able to smuggle in a Frankensteined .png that, when explicitly run by the recipient with an interpreter not commonly found on our machines, could run code. I swear to god, this was it.

To this day I refuse to fix that one, at least until they give me an actual way to exploit this.

History repeats itself: we had an external red team engagement. For some reason they also looked at that site. They had a finding: They could upload arbitrary files by switching the extension, thus potentially tricking the staff handling the reports to execute malicious code. They never verified if the report was actually sent, they just saw the green "thank you for your report", not knowing that this was filtered further down the line. Do I fault them for not verifying? No. Do I fault the white team, some of which Built. This. Website. for not catching that? Yes.

Anyway, I am also ignoring that one.

Captchas & CSP redesign

Back to actual issues - remember the two captcha providers from the CSP? Doppelt haelt besser, as the Germans say, right? When rewriting the CSP I wanted to find out "what do I actually need", so I browsed the site, exported & parsed the HAR, did a quick search of our code... and ended up with default-src 'self' as being more than sufficient.

That means: Neither of them are being used. Fuck, even the 'unsafe-inline' was unnecessary. During development it was decided to switch from the correctly CSPed one to the other one, I guess for data protection reasons. The Jira ticket was marked as complete. I can find remains of the provider in our source code, they are however never actually called. There is no documentation on this whatsoever.

We fortunately still have three more layers of automation protection in place so this isn't super critical, but hey, at least this means I can implement automated end-to-end testing of the reporting...

Passwords in logs

While testing the new CSP I wanted to run a proper end-to-end test. This failed, the site couldn't forward the report due to authentication issues.

So I had a look at the debug logs, what was causing this.

Those logs? Hosted in the log management solution of our cloud provider.

People with access to those logs? 200 plus.

What gets echoed into those logs? The credentials.

This, also, was not in the pentest.

Closing notes

As you see, things are going great. I have lost trust in both the developer who wrote this shit & my trust in our pentesters has been shaken a bit.

One of the reports we rejected was... effectively telling us "yo, that other website of yours uses so many third party dependencies, thats insecure! Look at your CWD website, thats how that's done". I think about this more than I should.

I am also waiting for the day I receive a report for the CVD website...