we are new at code signing, so im interested in your experiences how to use the sign tool without exposing the certificate to everyone in the company.
Can everyone in your company do code signing?
Do you give the certificate to every person in your company?
We want do some automatic workflow, like the developers drop theire files into a directory and every file get be signed.
Thanks for your advice.
My company has a VBScript wrapper that automates the signing and validation process. The VBScript, signtool.exe, capicom.dll and a PFX (containing the certificate chain and private key) all sit on a password protected network share.
Whenever someone needs to sign a binary, they can simply drag and drop the file onto the VBScript; and it handles the rest. Although, since our build process has become almost completely automated, it has fallen into disuse.
On the down side, it is a VBScript. So the password to the private key is visible, but that was the reason for password protecting the share.
Addendum
You could do something similar where it would sign any files within a folder/share and configure Windows Scheduled Tasks to execute the script every few minutes. After signing, it would need to move the files to a different folder, but that is easy enough. This would allow you to restrict access to the script, certificate, private key and the folder where files are signed.
Related
I am using an Inno Setup Tool to pack/setup all my files (dll, exe, jpg, etc).
But I found that there is a software called InnoExtractor which can really open my setup and read all the scripts and also extract all the files, since I need to hide/protect my files in setup I spent a lot of time/efforts to secure my setup.exe which was generated from Inno Setup, but I found some people saying add a password to Inno Setup Script, but this is also a wrong because the client knows that password and he can simply use InnoExtractor and extract everything even it was protected by Password! is not it!?
Now, I just ask if there someone can suggest me to solve this problem. In fact I embed XML files and DLL which is used to install specific files at client side according to the client machine, but if the client extract all DLLs to his machine then it will be a catastrophe! I need a way to prevent the client from seeing/extracting my setup.exe!
There's no way to protect code from an user, if you need to be able to run the same code on the user's machine. Once you deliver files to client's machine, no matter what method you used to pack them, the client can extract the files.
You can only make it harder, but there's no absolute solution.
More standard tools you use, more easy it is to decompile the code. If you want to make decompiling hard, make your custom installer, instead of relying on a standard installer tool (like Inno Setup).
Probably the only safe way is to use some online service.
You can encrypt the files with some very strong cipher (each file/DLL with a different encryption key). The installer will ask the user for some password, and will send the password to some online service. The online service, after verifying the password, will send back a decryption key for the DLL that you allow the client to install. This will allow the installer to decrypt only the DLL for that client.
Another alternative is that the installer will actually download the DLL from a server, only after you verify the client.
There's no way to 100% protect your installer from an attacker. If someone want to crack it then it can do it.
What you can do:
1) Encrypt the files with some custom (3rd party) system or use [Setup] Encryption directive
2) Modify Inno Setup - download sources, change them and compile again
3) Place sensitive files and data on server and download them during setup (+ encrypt)
4) [Code] section cannot be entirely unpacked, place some calculations or file operations there
In previous posts, I mentioned that I split my Access database project (Access 2016) in a front-end (Access) and back-end (MS-SQL). It was recommended that I save my front-end as an executable file, which I did. However, since it has macros and vba code, I always get a security warning.
I need a digital trust certificate, right? The problem is that, since I have Windows 10, I can't use the Office 2010/2013 tutorials about making a self-certificate for VBA. Can I buy one? I am confused, and would like to resolve this quickly because I intend to install the front-end exe file onto several computers at work.
Thank you very much for your time and help!
There are many sites that explain how to run signtool.exe on a .pfx certificate file, which boil down to:
signtool.exe sign /f mycert.pfx /p mypassword /t http://timestamp.server.com \
/d "My description" file1.exe file2.exe
I have a continuous integration CI process setup (using TeamCity) which like most CI processes, does everything: checks out source, compiles, signs all .exes, packages into an installer, and signs the installer .exe. There are currently 3 build agents, running identical VMs, and any of them can run this process.
Insecure implementation
To accomplish this today, I do a couple Bad Things(TM) as far as security is concerned: the .pfx file is in source control, and the password for it is in the build script (also in source control). This means that any developers with access to source code repository can take the pfx file and do whatever nefarious things they'd like with. (We're a relatively small dev shop and trust everyone with access, but clearly this still isn't good).
The ultimate secure implementation
All I can find about doing this "correctly", is that you:
Keep the pfx and password on some secure medium (like an encrypted USB drive with finger-based unlock), and probably not together
Designate only a couple of people to have access to sign files
Only sign final builds on a non-connected, dedicated machine that's kept in a locked-up vault until you need to bring it out for this code-signing ceremony.
While I can see merit in the security of this.. it is a very heavy process, and expensive in terms of time (running through this process, securely keeping backups of certificates, ensuring the code-signing machine is in a working state, etc).
I'm sure some people skip steps and just manually sign files with the certificate stored on their personal system, but that's still not great.
It also isn't compatible with signing files that are then used within the installer (which is also built by the build server) -- and this is important when you have an installed .exe that has a UAC prompt to get admin access.
Middle ground?
I am far more concerned with not presenting a scary "untrusted application" UAC prompt to users than proving it is my company. At the same time, storing the private key AND password in the source code repository that every developer (plus QA and high-tier tech support) have access to is clearly not a good security practice.
What I'd like is for the CI server to still sign during the build process like it does today, but without the password (or private key portion of the certificate) to be accessible to everyone with access to the source code repository.
Is there a way to keep the password out of the build or secure somehow? Should I be telling signtool to use a certificate store (and how do I do that, with 3 build agents and the build running as a non-interactive user account)? Something else?
I ended up doing a very similar approach to what #GiulioVlan suggested, but with a few changes.
MSBuild Task
I created a new MSBuild task that executes signtool.exe. This task serves a couple main purposes:
It hides the password from ever being displayed
It can retry against the timestamp server(s) upon failures
It makes it easy to call
Source: https://gist.github.com/gregmac/4cfacea5aaf702365724
This specifically takes all output and runs it through a sanitizer function, replacing the password with all *'s.
I'm not aware of a way to censor regular MSBuild commands, so if you pass the password on commandline directly to signtool.exe using it will display the password -- hence the need for this task (aside from other benefits).
Password in registry
I debated about a few ways to store the password "out-of-band", and ended up settling on using the registry. It's easy to access from MSBuild, it's fairly easy to manage manually, and if users don't have RDP and remote registry access to the machine, it's actually reasonably secure (can anyone say otherwise?). Presumably there are ways to secure it using fancy GPO stuff as well, but that's beyond the length I care to go.
This can be easily read by msbuild:
$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\1 Company Dev#CodeSigningCertPassword)
And is easy to manage via regedit:
Why not elsewhere?
In the build script: it's visible by anyone with source code
Encrypted/obfuscated/hidden in source control: if someone gets a copy of the source, they can still figure this out
Environment variables: In the Teamcity web UI, there is a detail page for each build agent that actually displays all environment variables and their values. Access to this page can be restricted but it means some other functionality is also restricted
A file on the build server: Possible, but seems a bit more likely it's inadvertently made accessible via file sharing or something
Calling From MSBuild
In the tag:
<Import Project="signtool.msbuild.tasks"/>
(You could also put this in a common file with other tasks, or even embed directly)
Then, in whichever target you want to use for signing:
<SignTool SignFiles="file1.exe;file2.exe"
PfxFile="cert.pfx"
PfxPassword="$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\1 Company Dev#CodeSigningCertPassword)"
TimestampServer="http://timestamp.comodoca.com/authenticode;http://timestamp.verisign.com/scripts/timstamp.dll" />
So far this works well.
One common technique is to leave keys and certificates in Version Control, but protect them with a password or passphrase. The password is saved in environment variables local to the machine, which can be easily accessed from scripts (e.g. %PASSWORD_FOR_CERTIFICATES%).
One must be careful not to log these values in plain text.
I am getting the error "Publisher could not be verified. Are you sure you want to run this software" while opening an exe from UNC path. when I am trying to open an exe from UNC path (\abcserver\apps). There were two possible solutions but didn't work as I want.
This is an application accessing by 50+ people from the network share. As per the given solutions on the forums, I've added the intranet security to the zone with all options on.
(------Open Internet Explorer | Tools | Internet Options | Security
selected Local Intranet | Sites
Check all of the three selection boxes.
Now add the server as: \abcserver------)
But we don't want each and every user to add the security on their local machines. Anyway added the same to \abcserver as well. Is there a way to fix this more efficiently?
Thanks you.
The warning is because your EXE is not digitally signed.
You can either
Copy the EXE locally (maybe create an install program?)
Change the user's security settings so there's no warning (you've found out about this already). You might be able to automate this, to reduce the user pain & chance of error.
Sign the EXE. More details here (general) and here (VB6-specific). Nb you will have to buy a certificate. Self-signing won't remove the security warning AFAIK unless perhaps you change the security settings to trust the certificate & it sounds like you're trying to avoid that.
Worked for me ...
Move the exe file to a non-ntfs volume (e.g. a USB flash drive (FAT)), then move it back again.
IT seems to be something to do with an NTFS property in the .exe file, which FAT does not have. So moving to a FAT drive removes it, and when moved back the propoerty is gone!.
See https://social.msdn.microsoft.com/Forums/vstudio/en-US/fc98080e-db2a-463f-a3a0-372acb3b6eab/disable-the-publisher-could-not-be-verified-for-a-certain-application?forum=windowssecurity
I've created an installer .exe for my app and made it available for download. When users download it they end up getting a message from Windows about the "publisher not verified". I'd like to see what is required to get rid of this.
I found articles indicating that different system settings would avoid it, however, I don't want to require users to change any settings. I'd rather see what I need to do on my end to avoid them from seeing the message in the first place.
I'm sure the answer has something to do with code signing, however, in order to sign my code doesn't that also mean I have to be Windows logo-certified? Not sure I want to go through that. Or is that a separate thing? Is there a way to sign it without being logo-certified?
"Logo-certified" involves obtaining a code signing certificate, but in your case no logo-certification is needed. You just purchase a code-signing certificate from one of certificate authorities (no, self-signed certificate won't work) and that's it.