Updater is not secure

[trisquel]

Because of the recent security issue, I had a quick look at the updater.

The updater will get the new version like this:

• It downloads a rar file from a fixed address via HTTPS. However, the TLS/SSL certificate is not validated, so the updater can not be 100% sure if the host is actually the real one.
• After the file is downloaded, the rar file is extracted. No integrity checks are done. (Though I assume the rar library uses CRC, and in case of an error the updater will just crash because there is no error handling).
• The rar file is not signed, thus no signature is checked.
• It will then move the content of the rar file somewhere and run it, usually as admin

The lag of security checks is a serious vulnerability. An attacker could easily smuggle any code into the user's system and run it as admin.

I would suggest 2 possible solutions:

A) Sign every update and make the updater check the signature. This would protect users against MITM attacks and server security breaches.

B) Make the updater pin the public key. This would be much easier to implement, but it would not help if the update server gets compromise.

Since this is a hobby project, I would go for options B. It's very easy to implement and secure enough. You can find more information and a .NET example here: Certificate and Public Key Pinning - OWASP. This way, nobody could plant a virus just by hijacking the DNS server in the future.

Good luck!

[temghost03ajfksdf]

Was just about to create an issue for this. Honestly, the hijacking of the bnsbuddy DNS servers and the following releases of infected versions of BnS Buddy was a huge fuck up, full stop. Enormous breach of trust considering how many people use it; security should be built from the ground up, and not an after-thought (or not implemented at all in this case).

I agree with your solutions 100%. To validate the downloaded binaries, you should sign them with GPG and provide a companion .asc file with the binaries that the updater can validate against a hard-coded public key. That, along with validating the SSL certificate should sufficiently protect users (assuming the gpg private key is kept more secure than his godaddy account was :roll_eyes:).

This really should have been handled already.

[RedDot-3ND7355]

To clear up the confusion.

1: My dns was not breached. 2: My server is intact.

What happened then? Okay, let's talk of "Trust". This was never meant to be an "after-thought".

1: My OTP at godaddy was ignored by support.

2: The skid managed to 'pretend' to be me via fake #(spoof).

3: Support at godaddy was either new or did not knew how to handle or adress the situation properly.

4: My domain name was transferred out of my account without confirmafion(until it happened).

5: All leaded to my domain was transferred to another godaddy account.

6: Skid used his own cloudflare ns for domain and added his own rules to redirect the specified fetches to the skid's server. (gardner.unospace.net) because he wasn't able to breach my dns or server itself.

7: Resulting in Bns Buddy and updater fetching fake versions(build) and fake download.

8: This could have been easily avoided on user side by using a simple anti-virus(not blaming users, using a-v is a web standard). I'm using bitdefender total security 2018 myself on all my devices.

This would've never been an issue if it wasn't for godaddy. I had a confession from a godaddy 'pro support' that they had a call from me. and tried to verify my phone number and was unable to verify it. (i had 11 otp texts received)

I've been trying since day 1 to retrieve my domain back, I can't work faster than godaddy support 'pro support' not willing to give back my domain.

I've been trying to handle the situation the best i can. And new methods of verificafion has been applied for a new release, wich will only be released when this is fixed. Thanks for understanding.

[temghost03ajfksdf]

@RedDot-3ND7355 I see, my fault for misunderstanding the situation with what happened godaddy, it seems there was some misinformation circulating about what happened on the bns subreddit. Clearly you aren't at fault for that in particular.

I apologize if I came across as abrasive or not being sympathetic to the awkward situation you're in.

However, regardless of the errors on godaddy's end, this entire issue could have been circumvented if you used some kind of client-side validation (like I noted above) to make sure binaries are coming only from you, and not just blindly downloading, installing, and running whatever the update server tells it to.

The assertion you made that users should be required to use an anti-virus to protect themselves from your software inadvertently installing malware on their machines is outrageous and irresponsible.

Also, when I said "breach of trust," I wasn't implying you intentionally did anything to lose user trust, rather that people trust you to write secure software, and unfortunately this has shown that isn't the case (from the user's perspective). I'm not just being hyperbolic here either, I've seen many people on the bns subreddit and in-game saying they are never going to update above 5.8.8.0 after this incident. I mean, can you even blame them?

All that said, I'm glad to hear you've decided to add verification of new updates. Looking forward to seeing how it is implemented.

[RedDot-3ND7355]

Solved.