3

Scenario

I am currently developing an application which should automatically update (if applicable) every time it is executed. The update would involve replacing the main.exe and any assets in an assets folder.

My current design logic for 'MyApplication' is;

MyApplication


My question regards the update.exe subroutine, namely;

enter image description here

Problem
My concern is that the process can be boiled down to fetching an executable from a URL. I'm slightly cautious with the security of this as a) any updates are distributed to all clients b) the download is an executable and currently 'assumed' to be untampered.

If my website were hacked, any executable could be pointed to and downloaded, causing untold damage to all clients. I'm not as concerned about authenticating clients, but authenticating the server response as genuine.

Solutions

  • Is this a concern, as I think it is?
  • What client and/or server side measures should I implement?

If it is relevant, I have access to 2 (or more) web servers, backend MySQL databases and full control over the client and server side contents.


Thank you for any help, I can clarify aspects if it does not make sense!

Benjy1996
  • 33
  • 2
  • 2
    It's not an answer because I don't have a specific recommendation. But generally speaking, automatic updates are a common problem. Rather than implement it from scratch, look for some framework, library, or packaging tool that includes in-place updates as a feature. Depending on your platform (windows, android, linux, etc.) there's probably some free or very low cost library that implements most of the hard stuff for you. – Paco Hope Jan 31 '16 at 12:56
  • @PacoHope I've started to realise that now too, thank you for the pointer - I'll do some research! – Benjy1996 Jan 31 '16 at 13:02

1 Answers1

3

You have essentially two issues in your process: providing the update and having it installed.

Server Auth

Firstly, yes you need to authenticate the server. This means that communication to the server must be done on a secure encrypted channel. Make sure to take the time to understand attacks on SSL so you don't use something that's expired. Ship the certificate with your app, and encrypt all the exchanges. Ship an extra public key for verifying signatures, different from the one used to secure the channel.

Update distribution architecture

Secondly, you must ensure that clients can trust what is being served to them. Assuming the worst, your server could indeed be compromised. You can take two steps to mitigate this. Firstly, ensure that the server used for updates is dedicated. Don't go running that API of yours on a Web server that hosts your personal blog. Run only the update API and think carefully about how you maintain this server and connect to it. Keep it updated. Have a penetration tester break it for you.

Secondly, (thanks @Steffen-Ullrich for reminding me of this) ensure that the server only distributes content that you have validated. When you publish a software release, you should sign your release tarball / binary with a private key (the one for which you shipped the public key) and release the signature along with the tarball. So your process involves uploading signature and binary to the update server and then clients retrieving it from the server. If your server is compromised, clients will no longer receive updates but at least they will not receive bogus / malicious executables.

Replacing the binary on the OS

Surprise surprise. This is 2016, you don't just replace executables system-wide on an OS without permission from the user. You'll have to drive your users through a UAC permission dialog every time you want to change the binary. This is of course going to be annoying for them.

If you expect your clients to absolutely need the latest update every time it's released (and assuming you can't get your app to install with a Integrity Level like browser vendors do), it might be more transparent and pleasant for your users to update your app via Microsoft's app store (saying 'might' as I've never shipped an app there and am unsure about that point).

Community
  • 1
Steve Dodier-Lazaro
  • 6,798
  • 29
  • 45
  • 1
    Server authentication does not protect against a compromised server. The update should be signed before putting it onto the server and the signature must be verified after download. Signing should be done the usual way with public and private key, where the secret and well protected private key is used for signing the update offline and the public key is integrated known by the application to verify the signature. With this process you don't need to trust the server and can even send the data without encryption. – Steffen Ullrich Jan 31 '16 at 12:33
  • Very good point about signing pre-upload. I didn't want to discuss compromised servers because it felt obvious that the server must stay up and running, I'll extend a bit on that. – Steve Dodier-Lazaro Jan 31 '16 at 12:35
  • 1
    Thanks Steve DL for the comprehensive reply (and thanks @SteffenUllrich too!) I expected the UAC prompts part and I'm rereading your response and understanding the process more and more - I'll look into each of those aspects in greater detail! – Benjy1996 Jan 31 '16 at 12:47