Safest way of delivering apps outside of the App Store

So Transmissions servers were hacked and the DMG of Transmission was replaced with one containing the payload. This is something that we should as a community think about, what is the safest way of delivering software to customers outside of the App Store.
http://www.macrumors.com/2016/03/07/transmission-malware-downloaded-6500-times/

Currently we use a zip file for people downloading from the site and code signing pkg for our update system.

  1. are you suggesting that a dusk image is a less secure form of delivery than a .zip or a .pkg?
  2. can you, Sam, or anyone else explain why the code signature of Transmissions was not broken by the insertion of the malware, thus resulting in a gatekeeper warning.

Personaly I don’t like the .pkg files. During the installation process the .pkg installer asks for my sytem password and when I enter it, the installer could to strange and for me hidden changes on my system. I prefer to use sandboxed apps and copy the app file into the application folder.

It would be great if the system installer asks for every single additional permission which I then could grant if I think it is necessary. It’s not a good idea to allow the .pkg file to install the app with all rights after entering the system password.

before installing a pkg, I normally expand it manually with Unarchiver or at least look in the files list.

And sometimes I don’t even use the pkg installer and just copy app from unpacked archive.

The server of the Transmission people was hacked. All of the safety measures they and Apple had in place failed.

Let’s say I want to become Ms. Malicious Coder and do a Xojo plugin that phones home some data about the end users of the Xojo apps. How do you protect against this? You can’t.

You can use Tools like Little Snitch and Malware Scanners and so on, but Beatrix is right, you can’t always be 100% sure…

I also HATE pkg files and mostly do not install when this is used. DMG should be used only imo

About Transmission:
The hackers used the open source and added malware , compiled it, codesigned it with their own Apple ID (which is already blocked by Apple now), uploaded their compiled Transmission app to the original Transmission server.

So:
When your app isn’t open source this way of working is not applicable to you. Of course they can still hack your server and do nasty things.

I don’t think it is.

A PKG file, is the most unfavored, we use it for updates, because it can be verified by it’s code signature and it auto replaces a Sandboxed application.

The way I understood, is that it was re-signed by the naughty people with a different code signature, who checks to see if Transmission was signed by “Transmission Project” or that App Wrapper is signed by Ohanaware Co., Ltd.?

I guess in our applications, we should be checking that our apps are signed with our certificates, unless it’s downloaded from the App Store, in which case it’s Apple problem.

[quote=252041:@Sam Rowlands]
I guess in our applications, we should be checking that our apps are signed with our certificates, unless it’s downloaded from the App Store, in which case it’s Apple problem.[/quote]

Can this be done in-app with declares? If yes, how?

you can run codesign -v -v via shell class.

or digitally sign you own app and include the signature as a data file in the bundle.

If you use your own private key, nobody can fake it.

That would only work when the users has Xcode installed.
Surely the are declares for doing this savely.

[quote=252054:@Christian Schmitz]or digitally sign you own app and include the signature as a data file in the bundle.

If you use your own private key, nobody can fake it.[/quote]

Sam, wouldn’t this be a feature you can build in AppWrapper?

So presumably they would have removed the check for ‘signed by my own certifcate’ at the same time?
If someone replaces MyApp with MyApp (hacked or otherwise) on the server, then the thing you download isn’t going to use your built in checks.

Code signing should prevent an app being modified after you have it on your system.
But if the thing you download isnt the thing you thought it was, no amount of checking done by ‘the real thing’ is going to stop ‘the fake one’ from causing trouble.

In this case, a test needed to be done at the server end to ensure that what the developer uploaded still matches what is on the developer’s machine.

I like very much the idea of verifying that the digital signature is intact, and if not, stop execution with a prominent display of where to find the original and report the incident. Now, how can this be achieved ? Sam, Christian, any suggestion ?

your app can include a signature and a public key.
The public key should be card coded in the app somewhere.

than your app can on launch and later on specific activities check if signature matches with certificate/public key and the given binary.

[quote=252084:@Christian Schmitz]your app can include a signature and a public key.
The public key should be card coded in the app somewhere.

than your app can on launch and later on specific activities check if signature matches with certificate/public key and the given binary.[/quote]

What I was thinking was to verify if the digital signature made with App Wrapper using Apple digital certificate has not been replaced.

It seems it is possible to check if the codesign is broken or not. See code below.
But it would be better to see if the codesign is yours (name check?). Anyone?

  Declare Function SecCodeCopySelf Lib "Security" (flags as integer, byref proc as ptr) As Integer
  Declare Function SecCodeCheckValidity Lib "Security" (code as ptr, flags as integer, requirement as ptr) As Integer
  
  dim myProc as ptr
  dim res As integer
  
  res=SecCodeCopySelf(0,myProc)
  res=res+SecCodeCheckValidity(myProc,0,nil)
  
  if res<>0 then 
   // codesigning is broken
  end if

It’s absolutely possible to verify the name of the leaf certificate.

What I think we should is to verify the team I’d, as this remains the same no matter if you deploy via App Store or on your own site. I’m on holiday at the moment, but I can use code I’ve written for App Wrapper 4 to verify this.

The other thing I considered was verifying that your executable is the main executable of the bundle. It’s trivial to check, however if the signature is broken or not yours, I don’t see this step as needed. What do you think?

SecCodeCheckValidity

Will get the OS to validate that the trust of the signature is intact, in our case GatKeeper would do this before the app launches, it does force a Internet connection, so I don’t think this is needed.

Checking if the codesigning is still intact after it has been downloaded is usefull. This way you can check if something changed (patched etc…) the bundle after the initial download.
If we can also check the name, we can make sure the app is yours or codesigned by someone else.