Windows X86 Executable Installer

[Elisabetta Buendia]

Adversariesmay execute their own malicious payloads by hijacking the binaries used by an installer. These processes may automatically execute specific binaries as part of their functionality or to perform other actions. If the permissions on the file system directory containing a target binary, or permissions on the binary itself, are improperly set, then the target binary may be overwritten with another binary using user-level permissions and executed by the original process. If the original process and thread are running under a higher permissions level, then the replaced binary will also execute under higher-level permissions, which could include SYSTEM.

Another variation of this technique can be performed by taking advantage of a weakness that is common in executable, self-extracting installers. During the installation process, it is common for installers to use a subdirectory within the %TEMP% directory to unpack binaries such as DLLs, EXEs, or other payloads. When installers create subdirectories and files they often do not set appropriate permissions to restrict write access, which allows for execution of untrusted code placed in the subdirectories or overwriting of binaries used in the installation process. This behavior is related to and may take advantage of DLL Search Order Hijacking.

Adversaries may use this technique to replace legitimate binaries with malicious ones as a means of executing code at a higher permissions level. Some installers may also require elevated privileges that will result in privilege escalation when executing adversary controlled code. This behavior is related to Bypass User Account Control. Several examples of this weakness in existing common installers have been reported to software vendors.[1] [2] If the executing process is set to run at a specific time or during a certain event (e.g., system bootup) then this technique can also be used for persistence.

Use auditing tools capable of detecting file system permissions abuse opportunities on systems within an enterprise and correct them. Toolkits like the PowerSploit framework contain PowerUp modules that can be used to explore systems for service file system permissions weaknesses.[3]

Turn off UAC's privilege elevation for standard users [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System] to automatically deny elevation requests, add: "ConsentPromptBehaviorUser"=dword:00000000. Consider enabling installer detection for all users by adding: "EnableInstallerDetection"=dword:00000001. This will prompt for a password for installation and also log the attempt. To disable installer detection, instead add: "EnableInstallerDetection"=dword:00000000. This may prevent potential elevation of privileges through exploitation during the process of UAC detecting the installer, but will allow the installation process to continue without being logged. [2]

Limit privileges of user accounts and groups so that only authorized administrators can interact with service changes and service binary target path locations. Deny execution from user directories such as file download directories and temp directories where able.

I've built a VI that runs without issue on my host computer (laptop running Win7, LabVIEW 2009) I'm installing onto a Windows XP machine. Install goes fine, but when the target computer is running the cDAQ doesn't run. Just sits there waiting. I have other hardware (MCC USB-ERB24 relay board) that works as expected, just not the cDAQ. The "Active" light never even flickers. Thoughts anyone?

Additional Installers tab, I'm checking all three of the NI-DAQmx instruments (Application Development Support, Core Runtime 9.0.2, and the MAX Configuration Support 9.0.2) and leaving the 2009 SP1 Run-Time Engine checked. For a total of four items checked.

Hardware Configuration tab, I'm checking the box to "Include hardware configuration from MAX", select the Configure button. This opens the Confiuration Export Wizard, I leave all of the settings on the first page as is, hit Next. On the Export Items page I select the unit needed for this application under Devices and Interfaces and select Export. I save the report and select Finish. Back at the Hardware Config tab, I check the Launch MAX Config Import Wizard after installation box.

Once it's built I transfer the whole file from C:builds to a jump drive, copy it to my target computer and install it. Restart the computer when prompted and try and run the application... again, still no joy on the cDAQ.

Am I missing a step? Maybe something I've done in one of my previous attempts? I did initally install the 2010 RTE, but one of the windows that popped up specifically said I needed the 2009 RTE so I downloaded that and installed it. Even though it's installing the 2009 RTE during the install maybe something from the 2010 version is interfering?? Thoughts anyone?

The target computer sees the cDAQ in MAX, no problem. Ran self test on each part, each one passes every time. Tried running the application again, still nothing from the cDAQ. I am talking to it through a USB hub, but that's never been an issue.

When the BC switch is turned on , a pair of PID loops are regulating a pair of 0-10VDC signals to ramp up/down two blowers based on feed back from a pressure sensor. Stage1 ramps first motor up to 80%, then Stage2 holds that motor and starts ramping up the second motor. Once both motors are at 80%, then ramps them up simultaneously to max. There's a LED on the front panel that tells me when they are both at 100%.

This is regulating airflow to a sidewall plenum. Currently it only runs in two states, Run or Stopped, the Closing state is a work in progress that I haven't finished yet. (I have pneumatic valves on most of my supply systems that will open/close that leg of the system. This particular leg doesn't have that feature and therefore I must close it with the control actuator. The Closing state didn't work correctly when I first built it and I haven't had time to finish messing with it yet.)

I've used the basic parts of this on several different sets of controls and have never had an issue when running off of my host machine. This is the first time I've tried to make a exe/installer in 2009. So I may be missing something. Thoughts are much appreciated!

This installer would allow you to select a target directory and some features from its user interface or the command line (if you know the magic words), and would generally install the full distribution with all entry points (shortcuts, etc.).

Unfortunately, due to the nature of how MSIs work, there are some limitations that affect the user experience. The most major of these is the fact that MSIs cannot decide whether elevate as part of the install - it has to be hardcoded. As a result, the old installer always requires administrative privileges just in case you choose to install for all users. This prevents installation of Python on machines where you do not have full control over the system.

Finally, some operations that are not simple file installations can be complicated. For example, when pip is installed or the standard library is precompiled, the MSI executes a background task rather than normally installing files. Without careful configuration of the MSI, these files will not be properly uninstalled or repaired, and issues in the extraction process can cause the entire task to fail. At worst, the uninstall step could fail, which can make it impossible to uninstall Python.

The issues described above have been addressed by the installers available since Python 3.5. However, there are also other uses for Python that do not lend themselves to a regular installer. For example, applications that want to include Python as a runtime dependency may not want to install a global copy of Python, build machines may require semi-public but non-conflicting installs of different versions, and platform-as-a-service web hosts may not allow normal installers.

Since Python 3.5.2, the official Python releases have been made available as executable installers, embeddable ZIP packages, nuget packages and Azure site extensions. There are also a range of third-party distributions that include the official Python binaries, along with other useful tools or libraries.

These installers provide the most flexible user interface, include all dependencies such as system updates and the Python launcher, generate shortcuts for the interpreter, the manuals and the IDLE editor, and correctly support upgrades without forgetting about feature selection.

Both executable installers result in identical installations and can be automated with identical command-line options. As I mentioned above, I think of this as the Python Developer Kit, which is why there are optional features to download debugging symbols or a complete debug build, which are not available in any other options. The Python Developer Kit provides everything necessary for someone to develop a complete Python application.

If the executable installer is the Python Developer Kit, then the embeddable package is the Python runtime redistributable. Rather than trying to be an easy-to-use installer, this package is a simple ZIP file containing the bare minimum of Python required to run applications. This includes the python[w].exe executables, the python35.dll (or later) and python3.dll modules, the standard library extension modules (*.pyd), and a precompiled copy of the standard library stored in another ZIP file.

Using the embeddable package allows you to distribute applications on Windows that use Python as a runtime without exposing it to your users. By default, a configuration file is also included to force the use of isolated mode and prevents environment variables and registry settings from affecting it (python36._pth on Python 3.6; pyvenv.cfg for Python 3.5). On Python 3.6 this file can also specify additional search paths. If your application is hosting Python, you can also choose not to distribute python.exe or any extension modules that are not used in your application.

3a8082e126