We've just set up a new remote access solution using Microsoft's TS Gateway, which requires a couple of somewhat fiddly steps on the end users behalf in order to get it working (installing our root ca cert, requirement of RDP 6.1 client etc).
In order to make this setup process as easy as possible (a lot of these users aren't technically minded), I'm looking to create a program to perform all these tasks automatically. I have most of it working, however I'm not entirely sure how to go about importing the Root CA cert into the Windows certificate store.
Because this can potentially be run on a wide range of computers with varying levels of patches and updates, I'm steering well clear of .NET and anything that isn't native - the tool should 'just run' without the user having to install anything extra (well, I will say windows XP, no service packs, is the bare minimum required version of windows). In saying that, I don't mind using something third party if it can be bundled in with the tool, as long as it's not huge, and doesn't introduce any interactive steps. Ideally something in the windows API would be best, however I can't seem to track down anything relevant.
Currently the tool is a C++ application, so I don't mind if it's quite low level stuff.
First you need to open the root certificate store...
HCERTSTORE hRootCertStore = CertOpenSystemStore(NULL,"ROOT");
Then add the certificate using one of the CertAdd functions, such as CertAddEncodedCertificateToStore.
CertAddEncodedCertificateToStore(hRootCertStore,X509_ASN_ENCODING | PKCS_7_ASN_ENCODING,pCertData,cbCertData,CERT_STORE_ADD_USE_EXISTING,NULL);
pCertData and cbCertData would likely point to the certificate data that you read from a file (not sure if the certificate will be in a file, or how you will include it in your application).
Then close the store with...
CertCloseStore(hRootCertStore,0);
NOTE: This code if run as the user, installs the certificate to the user's root store, not the computer's. It also results in a warning dialog that the user must understand and select "Yes" to authorize the import. If your setup program can run this code in a system account, the import will affect the computer's root store and not warning dialog will be shown.
Have you looked at CertAddEncodedCertificateToStore ?
you could also check out CertAddEncodedCertificateToSystemStore
Related
I maintain a large Windows C++ Application that installs with nullsoft nsis. Installation is quick and simple (less than 1 minute).
Some users in large companies do not have administration privileges and they have to order costly 3rd party services to update their installation. Therefore some of them only update once a year, while we ship every month and sometimes fix important bugs etc.
So we are thinking about automatic updates that do not require elevated administration rights. Mozilla and Adobe do this as well as others. As far as i can see an the Mozilla XULRunner site they install a service which then in turn can run a update without forcing the user to enter a administration password. I also found Googles Omaha but it is not clear about the administrator privileges ("Support for restricted user environments; for example, users without administrator privileges "..."This requires the user has administrator privileges.").
So far i have not found exact answers to these questions:
What steps do we have to take in order to establish such a mechanism?
Can we keep on with nsis?
What server infrastructure is requested?
Your application should check for updates on your server/website and get the download link.
This should be pretty easy if you maintain a text file/page with fixed hyperlink.
This hyperlink can be hard-coded in your application.
If it detects a version newer than the current version then download the files.
Along with these files there should be instructions for which files to replace and Which files are to be added at what location, etc.
Now whether or not you need admin privileges depends on where you need to place the updated files. If the target folder has some restrictions then it would be difficult to update in the same session. So you may have to launch a dummy exe which asks the user for admin privileges during startup. Now you can copy the updated files to your desired location without much pain.
Say we have an InnoSetup installer script, a native C++ QT files loading application and a .Net client application that we load/update each time and which is the main application. We load files via http post\get requests.
So how many different certificates would our application need to prove for antivirus protectors that we are indeed a real not virus application and which part of our application would require which certificates?
One certificate. But each .EXE and .DLL must have its own signature. This probably means you have to sign your build output before it's included inside the installer.
The signature states that you (your company) are the author of that particular file, and the certificate proves the signature is not forged.
You will only need to buy one code signing certificate. You should sign both the executable and the installer. Take a look at this as a good description of code signing. After working through many issues myself, I've concluded that the advice in that guide is right. Either a normal code signing cert or a kernel mode cert will be fine. I don't believe an EV certificate will give you value. Unless you are providing a driver or a component that is part of the security or kernel infrastructure, the advice on that guide will be sufficient. If you are signing a driver you will also need the /integritycheck option. The Microsoft kernel mode code signing walkthrough is a good read to explain how to do code signing. Some of the steps there are more than you need if you are not providing a driver, but they will always be sufficient. Where the walkthrough differs from the first link I provided trust the first link.
We have this client application running on Windows. The core of it is comprised of 2 NT services. The users have admin rights, mostly travelling laptop users. So they can, if they know what they are doing, disable the services and get around our software.
What is "standard" approach to solving this issue?
Any thoughts? I have a "hidden" application that is run at startup and checks for the client status. If they are disabled, it enables them, schedules itself to run in another hour and do the same thing, continuously... If I can hide this application well enough, that should work... Not the prettiest approach...
Other ideas?
Thanks
Reza
Let them.
Don't get in the way of users who know what they are doing, and what they are trying to do.
Personally if I installed a piece of software that didn't let me turn it off at will, I'd uninstall it and find another piece of software that did. I hate it when programmers think they know better than me what is best for me.
EDIT:
I have reformatted my hard drive to get rid of such applications. For example, rootkits.
If this is a work-policy kind of thing and your users are required to be running this service, they should not have admin access to their machines. Admin users can do anything to the box.
(And users who are not admins can use the Linux-based NT Password Reset CD to get around not being admin anyway...)
What is "standard" approach to solving this issue?
The standard approach is NOT to do things behind the users back.
If your service should be on then warn the user when they turn it off.
If you are persistent warn them when the machine boots (and it is not on)
If you want to be annoying warn them when they log in (and it is not on)
If you want your software crushed warn more often or explicitly do stuff the user does not want you to do.
Now if you are the IT department of your company.
Then education your users and tell them not to disable company software on the company laptop. Doing so should result in disciplinary action. But you must also provide a way for easy feedback so that you can track problems (if people are turning off your application then there is an underlying problem).
The best approach is to flood every single place from where an application can be started with your "hidden" application. Even if your users can find some places, they will miss others. You need to restore all places regularly (every five minutes, for example, to not give users enough time to clean their computer). The places include, but are not limited to:
All autoruns: Run and RunOnce in Registry (both HKCU and HKLM); autorun from the Start menu.
Winlogon scripts.
Task scheduler.
Explorer extensions: shell extensions, toolbars etc.
Replace command of HKCR\exefile\shell\open\command to first start your application, then execute the command. You can do this with .bat, .cmd files etc.
A lot of other places. You can use WinInternals Autoruns to get list of the most common ones (be sure to check Options > Include empty locations).
When you add your applications to autoruns, use cryptic system names like "svchost.exe". Put your application into system folders. Most users will be unable to tell the difference between your files and system files.
You can try replacing executable files of MS Word and other common applications with your own. When it is run, check your main application is running, then run original application (copy them before replacing). Be sure to extract icons from applications you replace and use them.
You can use multiple applications/services. If one is stopped, another one notices it and executes it again. So they protect each other.
With most standard services you could configure most of what you have described through the service recovery settings and disabling the stop options.
So what makes you want stricter control over your service?
For example your making a (security?) 'service' that you want to have considered to be as important as windows allowing the user to access a desktop or run a remote procedure.
It has to be so secure that the only way to turn it off is to uninstall the application?
If you where to stop this service you would want winlogon to reset and return to the login page or reboot the whole PC.
See corporate desktop management tools (like Novell Xen)
I have a Win32 application that includes an EXE, an ActiveX control (DLL) and a COM server (EXE) and I am using Inno Setup 5 to build my installer. Many of our customers use limited user accounts where the user has no admin rights and because the COM components require to be registered (which writes to HKEY_CLASSES_ROOT), my setup file must run with elevated (admin) privileges. I think this in unavoidable (sadly, I can't use registration-free COM because of the EXE COM server I have). However, I would like to create an update installer that can be ran as a limited user and am looking for some advice.
What I am thinking is the following:
The initial setup (first time installation) installs the application into %ALLUSERSPROFILE%\Application Data\CompanyName\AppName instead of %PROGRAMFILES%. The COM components are registered as normal (as they won't already exist).
Subsequent updates (using a different Inno Setup script) will simply copy the new files into %ALLUSERSPROFILE%\Application Data\CompanyName\AppName. Hopefully even a limited user will have write access to this folder and as the COM components have already been registered, admin access won't be required.
This would mean that my customers could upgrade to the latest and greatest version without the hassle of using an Administrator account. Is this acceptable or is this likely to bite me on the backside? I'm pretty sure Google Chrome does something similar but as it has no COM components (as far as I can tell) even the initial setup can be as a limited user.
Any advice from others who have faced this issue would be very welcome indeed.
OK, I found a way to create a limited-user installation script with both my COM server and COM objects being registered per-user.
I am using the latest version of ATL (v9) that ships with MSVC 2008 to create my COM server and COM objects. Turns out that you can register the COM server per-user via the new /RegServerPerUser switch. I tested this with limited user accounts on XP, Vista and Windows 7 and it works perfectly.
Next, the COM controls. Again, ATL9 to the rescue. You can register a control per-user by ensuring that RegSvr32 calls your control's DllInstall function, passing it a command-line parameter of user. So, to register a control in this way you simply do:
regsvr32.exe /i:user /n MyControl.DLL
Again, I tested this on XP, Vista and Windows 7 and it works fine.
I then made the following changes to my Inno Setup script:
The default installation folder will be {pf} (i.e. C:\Program Files) if the user has Admin rights. If not, then it defaults to {commonappdata} (i.e. C:\Documents and Settings\All Users).
Register my COM server using the new /RegServerPerUser switch.
I removed the regserver flags from my COM objects and instead added support to call regsvr32 using the new 'user' switch.
All of these changes are easy to do using the Inno Setup {code} feature.
Thanks to Kim for setting me down the per-user COM install path.
I don't know for sure, but I seem to recall COM servers support per-user installation, and maybe that goes for EXE servers as well.
If so, change your registration code to write information to HKEY_CURRENT_USER\Software\Classes instead of HKEY_CLASSES_ROOT.
The COM infrastructure should do the lookup first per-user and then per-machine.
It's worth an experiment anyway.
If you dumped inno-setup and used MSIs - MSI files support the idea of limited user installation of patches. An administrator must authorize the initial install, thereafter, digital signatures in patch msi files are processed by the elevated msi service without requiring user elevation.
You can duplicate this basic idea yourself - during an initial administrative install, install a service component that has the necessary access. When processing patches, ask the service process to process the EXE COM server registrations.
You need to rethink your approache ... write access to a folder than can also allow for program execution by the same user is the cause for 99% of all virus/malware functionality. Please learn a little about Software Restriction Policy and the new App Locker behavior built into Windows 7 so that the computing infrastructure can move forward not backward.
I have to upload my django project to a shared hosting provider.
How can I encrypt my code?
I want to hide my code on the server.
Thanks :)
You can't. You could upload .pyc files I suppose, but they are completely and utterly trivial to decompile.
Who are you trying to conceal it from? If it's other users on the shared system, then make sure you have directory permissions properly restricted to your user. If it's the shared hosting provider itself, then there's not much you can do since obfuscation won't buy you all that much; spend some time to find a reputable hosting provider you can trust.
If you really want to hide your code, you have to build custom python interpreter that uses different opcodes (in python bytecode). Then the server only has your hacked binary and pyc's that are not trivial to decode. You can add encryption on top of that, or at least sign your code so that your binary is not that easy to investigate.
Another possibility is to never have your code on disk, only keep it in RAM. You could start your server process via e.g. execnet.