I reported this privilege escalation w/ arbitrary code execution vuln to @Backblaze in Oct 2019. Instead of following my recs to fix it, they apparently cheesed in some broken mitigations that made it worse? Bypasses were found in March & disclosed by someone else this week. 1/ https://twitter.com/JasonGeffner/status/1303707601662865410

The two main recommendations I gave to Backblaze were:
1. Stop using insecure world-writable filesystem directories for IPC between unprivileged and privileged processes; and
2. Add code signing to your updater.
11 months later, it seems they have decided not to do either? 2/

A temporary mitigation I suggested in my initial report was to add a domain allowlist, since this would break the obvious attack. I regret saying this, since they seem to have chosen it as their final solution, and managed to screw it up in a remarkably bad way. 3/

Per @JasonGeffner’s report, Backblaze changed their client to add an allowlist some time after my report, while also *intentionally* breaking their TLS code so it would accept INVALID TLS certificates. Thereafter, the local code execution vuln became a full blown RCE vuln. 4/

I say “remarkably bad” because this is not some coding error like a broken URL parser. Rather, it’s another instance where someone at Backblaze intentionally defeated a security mechanism for their own convenience. It took *extra work* to disable host certificate verification. 5/

(TBH, their TLS code *may* have always been broken and I just didn’t notice because my goal at the time was to find backup software, not huge vulnerabilities in backup software, sigh. Regardless, it was only broken through an intentional action.) 6/

Also in the new report: instead of adding code signing, they instead decided to write a *hardcoded magic string check*? I just can’t even. It actually breaks my brain to think about how someone could invent this and then get it through code review into production. 7/

(Though… since their production client ships with unit tests embedded in it, debug symbols, 20 copies of the same exe for “threading”, and dead code with names along the lines of `foo_DONOTUSEDEPRECATED2010`, I’m not sure they *have* an internal code quality review process?) 8/

When I submitted my report 11 months ago, they told me they already knew about the problem, downplayed its severity, dodged follow-up questions, didn’t seem to understand how CVE IDs work and refused to issue one after being asked four times. It was not confidence-inspiring. 9/

The CVE ID for the vulnerability I gave to them is CVE-2019-19904. They should’ve announced it, but they never did. Actually, they never seem to voluntarily disclose *any* security bugs… there are *a lot* of verified, closed, undisclosed bugs on their HackerOne account. 10/

In fact, here’s the product announcement for the version which fixed @JasonGeffner’s vulnerability: https://www.backblaze.com/blog/backblaze-cloud-backup-release-7-0-1/. No mention at all of a dangerous remotely exploitable root code execution vulnerability that users must upgrade immediately to patch. 11/

This is all in stark contrast to their security page ( https://www.backblaze.com/security.html ) which makes many claims about best practices, and their blog & social media which present a sense of radical openness. I used to like their blog, but it all feels so gross and dishonest to me now. 12/

Something else I saw and never investigated was the string `BACKDOOR_prefer.xml` in several places in their client. How does that even *happen*? The optics alone… “We literally put a ‘BACKDOOR’ in our client, but trust us with root access & all your data it’s fine OK?” 13/

Given the apparent disregard for software development best practices and the volume of unnecessary logs the client dumps to disk, I would be unsurprised if their server-side code is also accidentally dumping PEK passwords somewhere, but obviously I can’t check that. 14/

(n.b. Backblaze mislead users about PEK. The decryption key is sent to their server, and so is your password. The only way to restore data is to decrypt it on their servers first. It is not a zero-knowledge system. PEK data is not ‘inaccessible’ to them. They don’t care.) 15/

While I genuinely wish this weren’t the case (I could really use a solid backup system which also works for non-techies), my opinion is that Backblaze’s services are unsafe and they are not a trustworthy vendor. 16/

I also hope this story serves as a cautionary tale to any dev or executive who thinks it’s fine to just bodge fixes for security issues. If you don’t understand and fix the root cause, you’re just going to pay for it over and over again. 17/17

Update: @Backblaze just cancelled their public bug bounty programme one day after @FeifanZ tweeted this thread directly at their CEO & staff. That’s…

… hmm.

18/17