> A customer reported this to us on the morning of April 1, 2021. This customer was using the shasum that is available on our Bash Uploader to confirm the integrity of the uploader fetched from https://codecov.io/bash.
> Once the customer saw a discrepancy between the shasum on Github and the shasum calculated from the downloaded Bash Uploader, they reported the issue to us, which prompted our investigation.
shoutout to this user for actually checking the shasum
>Their Github Pages page was censored. They are unable to participate in the maintenance of an open source repository. This was done, according to Github, as a requirement to comply with the laws of its state.
Software export is restricted to varying degrees, mostly encryption but there are other circumstances where export control exists on software (they used to be far more severe but have become considerably reduced). The BIS - https://www.bis.doc.gov - handles this and other CCL items.
To export anything that contains encryption over 64 bits you have to register with the BIS and be reviewed before you export. Even open-source software requires that you notify the BIS.
> The Slack incident report doesn't specify what type of Github repos were accessed, so it is hard to judge if any sensitive code has been leaked.
This is so important. Saying “less than 1% of code” is not very useful as a passwords or config repo being leaked may only be a few bytes. It’s also not customer data. But it’s extremely important.
I think the fact that they are being not forthcoming means they are clueless, or something really bad happened and they are weaseling and hoping nothing bad happens (spoiler: it will).
> A customer reported this to us on the morning of April 1, 2021. This customer was using the shasum that is available on our Bash Uploader to confirm the integrity of the uploader fetched from https://codecov.io/bash.
> Once the customer saw a discrepancy between the shasum on Github and the shasum calculated from the downloaded Bash Uploader, they reported the issue to us, which prompted our investigation.
Just goes to show that checking published hashes is not as useless as it may seem.
> What likely happened here is a remote team was paid to generate docs with a directive like, “Smartcar has a good API,” and stole them directly.
They didn't steal the docs (not only the docs). They stole the whole public facing architecture as evidenced by the fact that they are using in some instances the exact same API resources names and method names.
Customer source code and production secrets from build processes were vulnerable, but no abuse was found after a third-party forensics.
At my request, the provider donated $10,000 to the Electronic Frontier Foundation in place of a bounty. I insisted on making the disclosure public but agreed to the provider’s wish not to be named in the report.
> Not wanting to support it is a strange argument for not documenting it.
Seriously, no. That happens all the time in all kinds of software environments. Someone adds a crazy hack in a product with an API. Do you add it to the API, even though bits of it may leak visibly into the stuff seen by the customer? Hell no. That's what happened here.
> Yes, I did. I also looked for bitbucket, gitlab, Google Code, etc. and found nothing.
No worries then.
I checked out their website - I can't see any links to source code. So in my opinion it's just yet another closed source pretending to be secure messaging service then...
> It is possible the original developer of the package had their account compromised and used by a malicious actor.
> whose maintainer's account was likely compromised by a malicious actor
Seems to still be speculating about the cause without diving deeper into the topic, or is there some cache invalidation of the article that is missing perhaps?
> What likely happened here is a remote team was paid to generate docs with a directive like, “Smartcar has a good API,” and stole them directly. Then the management team didn’t bother checking.
If a remote team is writing your API documentation by copying and pasting, then what is the actual implementation team building from?
> Also interesting - it's being touted as proprietary code, but View Source (which as we all know is a clever hacker tool only) revealed that it's a fork/instance of Mastodon. Complete with not changing the error page's sad cartoon. The theme was slightly different, and the "toot" button has been renamed to "truth"... This is probably a violation of Masto's license, to not say you're using it.
Mastodon is AGPL. If they really did just rip it off, at a bare minimum they have to provide the source upon request. From the AGPL:
It has one added requirement: if you run a modified program on a server and let other users communicate with it there, your server must also allow them to download the source code corresponding to the modified version running there.
That was the 2nd pararaph. The first paragraph was, "This is a huge update fixing many bugs and security issues, it also expands on the functionality of the new SandMan.exe UI component, Check out the full ChangeLog for more details."
Paragraphs 1 & 2 do not go well together, and I will never use this product, despite my having tested sandboxie itself in the past.
Odd Story: The single person listed on the github page also has a fork of the original DiskCryptor code. At a prior employers I had worked, we once wanted to embedd DC into a larger framework. After some time we were able to find people to contact. They were using some elaborate scheme to hide their identities and yet converse over the phone. Since it was an "Open Source" project, and we already had the source code, we had reached out to them as a courtesy and nothing more. In fact we had already found serious bugs that we had fixed interally. Yet, they demanded an astronomically high sum for the use of DC. What did we do? The room of us laughed at the DC folks on speaker phone, then we went off and finished our own framework without using DC.
There is a small segment of people on the fringes of the security industry who work for a government (trying to get people to use their product), are running from a government, have stolen code from a government, are involved with shady business dealings, etc. It's best to stay as far away from these people as possible at all times. I'm not saying the person who started this github falls into that category, but it's best to think about that before using what is a security product.
I'd love to hear more about that.
reply